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)
  • (see comment below)
• Appropriate Contacts in Metadata
  • Strawman: Each <md:EntityDescriptor> element SHOULD contain both an <md:ContactPerson> element with contactType="support" and an <md:ContactPerson> element with contactType="technical". The <md:ContactPerson> elements SHOULD contain at least one <md:EmailAddress> element. If a contact (either support or technical) is a real person, the <md:givenName> and <md:surName> elements SHOULD reflect the person's real name. If a contact is a non-person (such as a mailing list), the <md:givenName> and <md:surName> elements SHOULD be omitted.
• Security Incident Response Policy
  • (see comment below)
• IdP Terms of Use (targeted at the user)
  • (see the Participation Agreement for basic requirements)
• SP Privacy Policy (targeted at the user)
  • included in User Interface Elements in SP Metadata
• Attribute Release Policy

Technical Basics

• Metadata Consumption
  • refresh metadata daily
  • verify the XML signature
  • check the expiration date
• X.509 Certificates in Metadata
  • use of self-signed certificates with 2048-bit keys
  • no unexpired certificates in metadata
  • controlled migration of keys
• User Interface Elements in IdP/SP Metadata
• Requested Attributes in SP Metadata
• In general, it is RECOMMENDED that all service endpoints be protected with SSL/TLS.
• Support for SAML V1.1 Web Browser SSO (optional)
  • IdPs MUST include an SSL/TLS-protected endpoint that supports the Shibboleth 1.x AuthnRequest protocol
  • IdPs MUST support the urn:mace:shibboleth:1.0:nameIdentifier transient name identifier format
  • SPs MUST include an SSL/TLS-protected endpoint that supports the SAML V1.1 Browser/POST profile
• Support for SAML V2.0 Web Browser SSO (required)
  • IdPs MUST include an SSL/TLS-protected endpoint that supports the SAML V2.0 HTTP-Redirect binding
  • IdPs MUST support the urn:oasis:names:tc:SAML:2.0:nameid-format:transient name identifier format
  • SPs that support SAML V2.0 should indicate so in metadata (be specific)
  • SPs MUST include an SSL/TLS-protected endpoint that supports the SAML V2.0 HTTP-POST binding
  • SAML V2.0 SPs MUST include an encryption key
• Support for SAML V2.0 Enhanced Client or Proxy (optional)
  • IdPs MUST include an endpoint that supports the SAML V2.0 SOAP binding
    • does this endpoint need to be SSL/TLS-protected?
  • SPs MUST include an endpoint that supports the SAML V2.0 Reverse SOAP (PAOS) binding
    • does this endpoint need to be SSL/TLS-protected?

Operational Maturity

• Maintaining Supported Software
• Operational Compliance with Metadata IOP
• Federation a "First Order" UI
• Discovery
  • Choices offered should result in an "acceptable" experience
• SP User Interface
  • Guidance for the flow through SP, DS, IdP
    • Visual "branding" (e.g., InCommon logo in appropriate places)
    • Appropriate help links/contacts at each step.
  • Error Handling
    • Look and Feel
    • Useful Contacts
• 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 disadvantages with each approach)
• IdPs SHOULD support the urn:oasis:names:tc:SAML:2.0:nameid-format:transient encrypted name identifier format (requires Shib IdP 2.3)
  • since this identifier can be reversed, it is especially useful for security incident response
• 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