...
((What about the SAML V2.0 Single Logout Profile? Is a deployment required to support for SLO required or recommended? In any case, what endpoints in metadata are required and/or recommended?))
((We included HTTP POST in the implementation profile, possibly could include that as a MAY))
((Do we have anything to say about the SAML V2.0 Artifact Resolution Profile? No, we left out all the SOAP stuff out of the implementation 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].
...
Applications that support deep linking and direct addressability of protected resources MUST be maintain support for such links in the presence of Web Browser SSO. That is, it MUST be possible to request an arbitrary protected resource and (authorization permitting) have it supplied as the result of a successful SAML SSO profile exchange. In addition, it is RECOMMENDED that Service Providers support the preservation of POST bodies across a successful SSO profile exchange, subject to size limitations dictated by policy or implementation constraints.
...
Addresses: Deployment Issue 9, 46; saml2int section: 8.1, 9.1
Keys and Certificates in Metadata
Public keys used for encryption and signature verification are bound to certificates in metadata [ref].
These certificates . Certificates SHOULD be long-lived and self-signed. To avoid problems with certain non-conforming SAML implementations, certificates in metadata SHOULD NOT be expired.((Do we need an equivalent statement around certificate signature algorithm?))
IdP metadata MUST include at least one signing certificate.
Addresses: Deployment Issue 12; saml2int section: 5
Key and Certificate "Rollover"
SP deployments MUST support multiple signing certificates in IdP metadata. This makes it possible for the IdP to seamlessly migrate to a new signing key.
If the SP publishes an encryption certificate in metadata, the SP deployment MUST be configurable with multiple decryption keys. This makes it possible for the SP to seamlessly migrate to a new decryption key.
Addresses: Deployment issue 11
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.
((We included HTTP POST in the implementation profile, possibly could include that as a MAY))
mdui Elements in Metadata
Metadata for SAML entities MUST include UI elements for mdui:DisplayName, mdui:Logo, mdui:InformationURL, and mdui:PrivacyStatementURL.
The content of the mdui:Logo element SHOULD be a HTTPS URL and MUST NOT be a HTTP URL.
At least one mdui:Logo element SHOULD have a height attribute of 60 and a width attribute of 80.
An entity MAY include a mdui:Logo element with a height attribute of 16 and a width attribute of 16.
Authentication Context requests
...
When consuming attributes with standard definitions, Service Providers SHOULD NOT impose constraints that are not part of the definitions of those attributes.
This may imply supporting extra long attribute values, attributes that contain multiple attribute values, broad character set support, and the likeetc.
Addresses: Deployment Issue 16, 44; saml2int section: 6, 7
...
Addresses: Deployment Issue 45, 48; saml2int section: 7, 9.2
Subject ID (Identifier) Opaqueness
SPs MUST be able to accept and function reasonably through accepting opaque identifiers. Where necessary, in addition to accepting the user subject ID identifier SPs SHOULD accept one or more relatively unique, human-readable "directory" attributes for use in cases where users are required to identify one another, such as in user searches, user pick-lists, and other interface elements.
Addresses: N/A (identified during identifiers discussions in workgroup)
XML Encryption
((Note: we stopped here for the meeting. Tom raised the concern that InCommon doesn't support encryption keys for IdPs.))
IdPs MUST support encryption of assertions and SPs must support decryption of assertions using XML Encryption for the Web SSO profile.
Deployments that support SLO MUST support encryption (for SPs) and decryption (for IdPs) of NameIDs using XML Encryption for the SLO Profile.
Encryption MUST support the AES-GCM cipher for this encryption (XMLENC: http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/)
Addresses: Deployment Issue 10; saml2int section: 5, 9.1
Provisioning and Authorization of SAML-only Users (speculative) - NOT ADDED TO SAML2INT YET
Applications that creates new user profile when new a SubjectID is received ("Just In Time", or "On the Fly" provisioning) SHOULD also rely on a separate attribute's value(s) to trigger provisioning of user access. Conversely, absence of that separate attribute, or specific values thereof, should cause user deprovisioning (or deauthorization) to occur.
...
Addresses: Deployment Issue 7, 8; saml2int section:n/a
...
I think we still have open questions on how to formulate the Metadata requirements.
Support for Multiple IdPs
...
When more than one Identity Provider authenticates the same resource URL, IdP selection SHOULD be supported using the OASIS SSTC SAML v2.0 Identity Provider Discovery Profile.
((Any comments we should add about discovery bypass?))
Addresses: Deployment Issue 13, 14, 43; saml2int section:8 (or new)
Forced Re-authentication
Identity providers must MUST ensure that a request for forced reauthentication (ForceAuthn="true") results in the Subject being required to authenticate in a way that proves that the Subject is present. ((When this condition is met, the IdP MUST reflect this by updating the AuthnInstant in its assertion.))
If the IdP cannot prove subject presence, the IdP MUST [respond with an error?] [respond with the previous authninstant?]NOT generate a successful response.
Service Providers SHOULD test the currency of the AuthnInstant value contained in the IdP's assertion to verify that it is in fact based on a recent user authentication event.
Addresses: Deployment Issue 35; saml2int section:n/a
IdP Authentication Request Presentation
Service Providers MUST NOT issue authentication requests inside a frame or via any mechanism that would require the use of third-party cookies by the Identity Provider to establish or recover a session with the user agent.
((Is there something broader we want to say about how it SHOULD be presented?))
Addresses: Deployment issue 6
Metadata and Metadata Refresh
Service Providers and Identity Providers MUST regularly verify their SAML peer configurations by validating them against those peers' current metadata. Metadata used for this configuration validation MUST itself be signed and validated with a key distributed (verified? validated?) separately from the metadata itself.
Addresses: Deployment issues 1, 2; saml2int section: 5
SAML EntityIDs
The EntityID of a SAML entity MUST be scoped to the domain of the organization that the owner of the application, in the case of an SP; or the owner of the organization whose users are represented by the IdP, in the case of an IdP.
Specifically, hosted applications must have entityIDs scoped to the client organization's domain, not the host's domain.
((Probably needs more clarity.))