Page History

...

• 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?
• Service Endpoints in Metadata

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

...

• 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.

...