...
All deployments MUST support the SAML V2.0 Web Browser SSO Profile [ref] as specified in this document. A deployment indicates support for SAML V2.0 Web Browser SSO by including certain browser-facing SSO endpoints in metadata.
((What about SLOthe SAML V2.0 Single Logout Profile? Is a deployment required to support SLO? In any case, what endpoints in metadata are required and/or recommended?))
((Do we have anything to say about the SAML V2.0 Artifact Resolution Profile?))
SP-Initiated SSO
Service Providers must support the direct generation of authentication request messages conforming to the SAML Authentication Request Protocol [SAML Core, 3.4].
...
Addresses: Deployment Issue 9, 46; saml2int section: 8.1, 9.1
Keys in
...
Metadata
Public keys used for encryption and signature verification are bound to certificates in metadata. Certificates SHOULD be communicated using long-lived , unexpired, and self-signed certificates. This is recommended to To avoid problems with libraries that will not allow processing of expired certificatescertain non-conforming SAML implementations, certificates in metadata SHOULD NOT be expired.
Addresses: Deployment Issue 12; saml2int section: 5
Endpoints in Metadata
IdP metadata MUST include a SingleSignOnService endpoint that supports the SAML2 HTTP-Redirect binding. A SingleSignOnService endpoint that supports the SAML2 HTTP-POST binding SHOULD also be included in IdP metadata since some SAML SP deployments favor that particular binding. Support for both bindings is strongly RECOMMENDED.
An SP that supports SAML V2.0 Web Browser SSO MUST include at least one AssertionConsumerService endpoint that supports the SAML V2.0 HTTP-POST binding. Occasionally an IdP will prefer to respond with an artifact, and therefore an AssertionConsumerService endpoint that supports the SAML V2.0 HTTP-Artifact binding MAY also be included in SP metadata. Note: An SP that supports artifact resolution MUST have at least one use="signing" certificate in metadata.
Authentication Context requests
...