(Obviously still draft at this point)
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].
Service Providers that want to bypass user-initiated discovery then Service Providers SHOULD support this profile http://docs.oasis-open.org/security/saml/Post2.0/sstc-request-initiation.html
Requiring the use of unsolicited responses (or so called “IdP-initiated SSO requests) is not a substitute for this requirement.
Addresses: Issue 4
saml2int section: 8.1
SP Deep Link support
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.
The SAML binding-specific RelayState feature is typically used to maintain state required to satisfy both of these requirements, the exact detail of which is left to implementations.
Support for unsolicited responses (or so-called IdP-initiated SSO) is not a substitute for this requirement.
Addresses: Issue 5
saml2int section: n/a
Clockskew support
Deployers MUST support a minimum of three (3) and a maximum of five (5) minutes of clock skew – in either direction -- when interpreting xsd:dateTime values in assertions and enforcing security policies based thereupon.
The following is a non-exhaustive list of items to which this directive applies: NotBefore, NotOnOrAfter, and validUntil XML attributes found on Conditions, SubjectConfirmationData, LogoutRequest, EntityDescriptor, EntitiesDescriptor, RoleDescriptor, and AffiliationDescriptor elements.
Keys in metadata
Public keys used for encryption and signature verification SHOULD be communicated using long-lived, unexpired, self-signed certificates.
This is recommended to avoid problems with libraries that will not allow processing of expired certificates.
Authentication Context requirements
SPs that require specific authncontextclassref values to be asserted by IdPs MUST have an authentication-related business requirement for that restriction.
<IIRC, the intent of this paragraph is to keep SPs from requiring custom values, such as Microsoft's "password" instead of "PPT". I don't know if this language would affect
Microsoft's use of that context>
Authentication Context requirement
An SP that has an authentication-related business requirement to require authncontextclassref values in assertions MUST specify the allowable values in the RequestedAuthnContext element of authnrequests it generates. Conversely, if an SP does not specify RequestedAuthnContext values in authnrequests it generates, or if the SP does not support the generation of authentication requests (reference to SP-initiated, above), then the SP MUST NOT restrict allowable authcontextclassref values in IdP assertions.
<If the SP does not support the generation of authentication requests, then it is not compliant with this profile. So perhaps the "or if the SP does not support" phrase should be removed?>
String Attribute Value--
Service Providers MUST support the consumption of <saml2:Attribute> elements containing any arbitrary xs:string value in the Name attribute and any arbitrary xs:anyURI value in the NameFormat attribute.
<This was taken directly from the Fed Interop profile. In this context, it's not clear whether this is expecting the SP itself to support arbitrary lengths and values, or if it's referring to the application behind the SP. If the latter, then this perhaps should be restated as a "SHOULD" with wording along the lines of "very long values and identifiers...">
IdP Error URLs
IdP deployers MUST provide a working error URL in published metadata
Relying parties SHOULD direct clients to this URL when an authentication error occurs that cannot be resolved locally.
<Is this still a best practice?>