You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 43 Next »

This consultation on Baseline Practices for Trust in Federation is open from Wed. July 6, 2016 until Wed. August 10, 2016

We appreciate your review and feedback.

Please add your feedback in the "Change Proposals" table at the bottom of this page. Do not make changes or comments to the draft itself.

 

START OF DRAFT - Please provide your suggestions in the "Change Proposals and Feedback" table below. Do not make comments or changes to the draft.

Introduction

As the strategic value of Research and Education Trust Federations ever increases, from time to time it is important to reflect on, then assess and distill what forms the basis for sufficient trust by all participants. On that foundation we can understand gaps and agree to changes that may need to be implemented by various Federation actors in order to sustain trust in them.

What trust do we need to have in Federation? When we rely on Federation, we are partnering with other organizations to do something for us that we would otherwise do for ourselves or forgo altogether. And mostly the latter: Federation makes possible the integration of resources, services, and users across the globe into the myriad ways that the R&E mission is undertaken.

What are the most important expectations of how those partners behave? Is it important to know, fairly promptly, when any of those expectations no longer hold, or is it enough to know that the process by which partners become active in Federation ensures that those expectations are valid?

Below are three short lists of high-level expectations, one for each of three types of Federation actor: an Identity Provider, a Service Provider, and a Federation Operator. What is the gap between these and your expectations of each of them? How would you reframe these so they better express your expectations? Are there any more-detailed needs that must be in this picture, perhaps to be explicitly subsumed within one of the statements below?

Since different specific situations may have higher or lower risk and hence greater or lesser expectations, for this purpose let’s focus on establishing the baseline expectations that should be true of all, or almost all, transactions with Federation partners.

Baseline Expectations of Identity Providers

  1. The IdP is trustworthy enough to access the institution’s own enterprise systems

  2. The IdP is operated with institutional-level authority

  3. The IdP is treated as an enterprise system by institution-level security operations

  4. Federation metadata is accurate, complete, and includes site technical, admin, and security contacts, MDUI information, and privacy policy URL

Baseline Expectations of Service Providers

  1. Controls are in place to reasonably secure information and maintain user privacy

  2. Information received from IdPs is stored only when necessary for SP’s purpose

  3. Security incident response plan covers SP operations

  4. Federation metadata is accurate, complete, and includes site technical, admin, and security contacts, MDUI information, and privacy policy URL

  5. Attributes required to obtain service are appropriate and published

Baseline Expectations of Federation Operators

  1. Focus on trustworthiness of their Federation as a primary objective

  2. Good practices are followed to ensure accuracy and authenticity of metadata to enable secure and trustworthy federated transactions

  3. Internationally-agreed frameworks that improve trustworthy use of Federation, such as entity categories, are implemented and adoption by Members is promoted

  4. Work with other Federation Operators to help ensure that each Federation’s operational practices suitably promotes the realization of baseline expectations, as above, by all actors in all Federations

END OF DRAFT


Change Proposals and Feedback - We welcome your feedback/suggestions in this table

If you have comments that do not lend themselves well to the tabular format below, please create a new Google doc and link to it in the suggestion column.

Number
Current Text
Feedback / Proposed Text / Query / Suggestion
Proposer

+1 (add your name
here if you agree
with the proposal)

1IdP expectationsI'd swap expectation 1 and 2Thomas Lenggenhager, SWITCH

Scott Cantor, Ohio State

Maarten Kremers, SURFnet

2

IdP expectations

Add something like: The IdP only asserts faculty, staff and student affiliations backed by proper on- and off-boarding processes

Thomas Lenggenhager, SWITCH

Mikael Linden, CSC

E Yurick, Gettysburg

3IdP expectations #1 The approach may work for staff, faculty and students but my experience is that even trustworthy IdPs have also users (industry partiers, library walk-in, ...) whose accounts are less secure and wouldn't have access to the key enterprise systems. To make #1 useful for SPs, maybe introduce a tag for the trustworthy accounts (to enable SP side filtering) or make it explicit that #1 applies only to accounts with eP(S)A=staff, faculty or student (c.f. the comment above from Thomas).Mikael Linden, CSCMaarten Kremers, SURFnet
4IdP expectationsThe word "institution" should be replaced by the word "organization" to be inclusive of organizations that operate IdPs and that are not institutions, such as LIGO.Scott Koranda, LIGO 
5SP expectationsThe 5th bullet on attribute requirements is probably a bit over-specified for contractually negotiated situations where specific data exchanged will depend on the customer and the particular relationship, and isn't usable ad hoc. Maybe wording allowing for "or as negotiated by contract".Scott Cantor, Ohio State 
6FedOp expectationsI would add: "The federation operator makes the trustworthiness transparent to the participants."Scott Koranda, LIGO 
7IdP expectationsThe current POP (2008) states an expectation that IdPs will "provide authoritative and accurate attribute assertions to other Participants" but I don't see that covered in the text above.Jim Basney, NCSA/Illinois 
8IdP expectationsThe current POP (2008) states, "Sending passwords in 'clear text' is a significant risk, and all InCommon Participants are strongly encouraged to eliminate any such practice." If this is replacing the POP, are we losing an expectation about IdPs not using clear text passwords?Jim Basney, NCSA/Illinois 
9    
10    

 

See also:

Consultations Home

InCommon Assurance Home

InCommon Assurance Call of Nov 2015 on Baseline Practices

 

  • No


  • No labels