Page History

...

• A top-level, third-party assertion MUST be signed. A relying party MUST validate the signature on a top-level, third-party assertion.
• If the Subject of a top-level, third-party assertion is not the Subject of the certificate, the assertion SHOULD contain a SubjectConfirmation element with subject confirmation method holder-of-key .
• If the Subject of a top-level, third-party assertion is the Subject of the certificate, the assertion MUST contain a SubjectConfirmation element with subject confirmation method holder-of-key . In this case, the relying party MUST confirm the subject, that is, the relying party MUST verify that the subject (who is also the requester) possesses the corresponding private key.
• Regardless of its content, an SSO assertion MUST be bound to a certificate by inserting the <saml:Assertion> element into the <saml:Advice> element of a self-issued assertion. Thus an SSO assertion is a nested assertion (unlike a top-level assertion).
• A nested assertion SHOULD be signed. A relying party MAY reject an unsigned nested assertion, subject to policy. If the nested assertion is signed, a relying party MAY validate the signature or not, subject to policy.
• An entity that binds an SSO assertion to a certificate MUST authenticate the !IdP that issued the assertion. In particular, the entity MUST validate the signature on the <samlp:Response> element (if it exists) before stripping the <samlp:Response> element and binding the enclosed assertion to the certificate.
• An entity that binds an SSO assertion to a certificate SHOULD set the SIA extension of the certificate to the entityID of the SAML issuer. A relying party MAY query the !IdP based on the entityID in the SIA extension.

{html}<hr />{html}