At the November TAC F2F, we discussed having a matrix of best practices by which to evaluate registered sites to help set expectations and create peer pressure. This is a preliminary set of suggested criteria.
Policy
- Participant Operational Practices (POP)
- Appropriate Contacts in Metadata
- Security Incident Response Policy
- IdP Terms of Use (targeted at the user)
- (see the Participation Agreement for basic requirements)
- SP Privacy Policy (targeted at the user)
- Attribute Release Policy
Technical Basics
Operational Maturity
- Metadata Consumption
- Maintaining Supported Software
- Federation User Experience
- Discovery Best Practices
- SP User Interface
- Guidance for the flow through SP, DS, IdP
- Visual "branding"
- Appropriate help links/contacts at each step.
- Error Handling
- Identity attributes
- Regular (event-driven? nightly?) synchronization with systems of record
- Documentation of locally-defined attributes
- Education
- For end-users
- Privacy
- Appropriate use
- Protection of secrets
- For service providers
- Privacy requirements
- Good UI practice
Maximizing the Federation
- Documented Attribute Release Process
- IdPs SHOULD support the
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
name identifier format and/or the eduPersonTargetedID
attribute
- stored or computed? (there are advantages and disadvantages with each approach)
- Release of attributes w/o admin involvement (via consent or otherwise)
- Strawman: It is RECOMMENDED that
eduPersonScopedAffiliation
, eduPersonEntitlement
, and eduPersonTargetedID
be released across the board, to all SPs. The five (5) remaining attributes listed on the InCommon Federation Attribute Summary page SHOULD be released to all SPs provided user consent is obtained. In both cases, we're referring to all SPs in the InCommon Federation.
Parked Items
- Keys of less than a certain age
- We should consider what, if any, age is actually "too old"
- Full saml2int conformance
- InCommon Implementation Profile conformance
- Could identify "exceptions to conformance" to highlight specific missing capabilities or could break profile into separate features in the matrix
Meeting Notes
Meeting Notes - April 21, 2011