Page History

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
  • 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.
• SAML V2.0 Support
  • IdPs MUST include a 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 a SSL/TLS-protected endpoint that supports the SAML V2.0 HTTP-POST binding
  • SPs MUST include an encryption key
• SAML V1.1 Support
  • IdPs MUST include a 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 a SSL/TLS-protected endpoint that supports the SAML V1.1 Browser/POST profile
• SAML V2.0 Enhanced Client or Proxy (ECP) Support
  • 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?
• 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 "basic" attributes w/o admin involvement (via consent or otherwise)

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