This document was last revised or approved by the SSTC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC by using the “Send A Comment” button on the TC’s web page at http://www.oasis-open.org/committees/security.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the IPR section of the TC web page (http://www.oasis-open.org/committees/security/ipr.php.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

1Introduction

This document lists the approved errata to the SAML V2.0 OASIS Standard. Each one has been given an Enn designation. Numbers in the sequence are missing wherever a reported problem (a “proposed erratum”, or PE) resulted in a TC decision not to issue an erratum to any V2.0 specification text.

This document is ultimately intended to be confirmed as a formal Approved Errata document. To see the full list of reported problems and additional background on the approved errata, see the Errata Working Document for SAML V2.0 [SAMLErrWork].

As required by the OASIS Technical Committee Process, the approved errata represent changes that are not “substantive”. The changes focus on clarifications to ambiguous or conflicting specification text, where different compliant implementations might have reasonably chosen different interpretations. The intent of the Security Services TC has been to resolve such issues in service of improved interoperability based on implementation and deployment experience.

In this document, errata change instructions are presented with surrounding context as necessary to make the intent clear. Original specification text is often presented as follows, with problem text highlighted in bold:

This is an original specification sentence. The second sentence needs to be changed, removed, or replaced.

New specification text is typically presented as follows, with new or changed text highlighted in bold:

This is a highly original specification sentence. This is the wholly new content to replace the old second sentence. It runs on and on and on.

In a few cases, text needs only to be struck, in which case the change is shown as follows, with text to be removed both highlighted in bold and struck through:

This is yet another original specification sentence which contains a~~n inappropriately~~ long description.

In addition to this normative document, non-normative “errata composite” documents have been provided that combine the prescribed corrections with the original specification text, illustrating the changes with margin change bars, struck-through original text, and highlighted new text.

Of the SAML V2.0 specifications, only the following have approved errata:

Assertions and Protocols (original [SAMLCore], errata composite [SAMLCoreErr])
Bindings (original [SAMLBind], errata composite [SAMLBindErr])
Conformance Requirements (original [SAMLConf], errata composite [SAMLConfErr])
Metadata (original [SAMLMeta], errata composite [SAMLMetaErr])
Profiles (original [SAMLProf], errata composite [SAMLProfErr])

All cited line numbers refer to the PDF forms of the original OASIS Standard specifications in question, not to line numbers in this document or in the errata composite documents.

1.1Normative References

In general, the latest revisions of all errata-related documents will be listed and linked from the TC home page at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security. Links for the revisions corresponding to this Committee Draft have been provided below.

[SAMLBind] S. Cantor et al. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. See http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.

[SAMLBindErr] S. Cantor et al. Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. OASIS SSTC, January 2007. Revision 04 corresponds to this Committee Draft; see http://www.oasis-open.org/committees/download.php/22381/sstc-saml-bindings-errata-2.0-wd-04-diff.pdf.

[SAMLConf] P. Mishra et al. Conformance Requirements for the OASIS Security Assertion Mark Markup Language (SAML) V2.0. OASIS SSTC, March 2005. See http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf.

[SAMLConfErr] P. Mishra et al. Conformance Requirements for the OASIS Security Assertion Mark Markup Language (SAML) V2.0 – Errata Composite. OASIS SSTC, January 2007. Revision 03 corresponds to this Committee Draft; see http://www.oasis-open.org/committees/download.php/22383/sstc-saml-conformance-errata-2.0-wd-03-diff.pdf.

[SAMLCore] S. Cantor et al. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. See http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.

[SAMLCoreErr] S. Cantor et al. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. OASIS SSTC, January 2007. Revision 04 corresponds to this Committee Draft; see http://www.oasis-open.org/committees/download.php/22385/sstc-saml-core-errata-2.0-wd-04-diff.pdf.

[SAMLErrWork] E. Maler. Errata Working Document for SAML V2.0. OASIS SSTC, January 2007. Revision 39 corresponds to this Committee Draft; see http://www.oasis-open.org/committees/download.php/22378/sstc-saml-errata-2.0-draft-39.pdf.

[SAMLMeta] S. Cantor et al. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. See http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.

[SAMLMetaErr] S. Cantor et al. Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. OASIS SSTC, January 2007. Revision 03 corresponds to this Committee Draft; see http://www.oasis-open.org/committees/download.php/22387/sstc-saml-metadata-errata-2.0-wd-03-diff.pdf.

[SAMLProf] S. Cantor et al. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. See http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.

[SAMLProfErr] S. Cantor et al. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. OASIS SSTC, January 2007. Revision 05 corresponds to this Committee Draft; see http://www.oasis-open.org/committees/download.php/22389/sstc-saml-profiles-errata-2.0-wd-05-diff.pdf.

2Approved Errata

Following are the approved errata to the SAML V2.0 OASIS Standard.

E0: Incorrect Section Reference

Change [SAMLCore] at line 2660 to refer to section 3.7.3 rather than 3.6.3 for Reason codes. This was a typographical error.

E1: Relay State for HTTP Redirect

Change [SAMLBind] Section 3.4.3 at lines 551-553 to reflect the fact that, indeed, the RelayState parameter is covered by the query string signature described in Section 3.4.4.1 (DEFLATE encoding). Note that Section 3.5.3, which has similar original wording, remains correct for its case.

Original:

RelayState data MAY be included with a SAML protocol message transmitted with this binding. The value MUST NOT exceed 80 bytes in length and SHOULD be integrity protected by the entity creating the message. Signing is not realistic given the space limitation, but because the value is exposed to third-party tampering, the entity SHOULD insure that the value has not been tampered with by using a checksum, a pseudo-random value, or similar means.

New:

E2: Metadata Clarifications for HTTP Artifact Binding

Change [SAMLBind] Section 3.6.7 at lines 1188-1191 to clarify metadata requirements on profiles using the HTTP Artifact binding.

Original:

Support for the HTTP Artifact binding SHOULD be reflected by indicating URL endpoints at which requests and responses for a particular protocol or profile should be sent. Either a single endpoint or distinct request and response endpoints MAY be supplied. One or more indexed endpoints for processing <samlp:ArtifactResolve> messages SHOULD also be described.

New:

Support for receiving messages using the HTTP Artifact binding SHOULD be reflected by indicating URL endpoints at which requests and responses for a particular protocol or profile should be sent. Support for sending messages using this binding SHOULD be accompanied by one or more indexed <md:ArtifactResolutionService> endpoints for processing <samlp:ArtifactResolve> messages.

E4: No Role for SAML V1.1 Artifacts in SAML V2.0

Change [SAMLBind] Section 3.6.4 at line 1067 to clarify that SAML V1.1 artifacts have no role in SAML V2.0.

New:

The following describes the single artifact type defined by SAML V2.0. Although the general artifact structure resembles that used in prior versions of SAML and the type code of the single format described below does not conflict with previously defined formats, there is explicitly no correspondence between SAML V2.0 artifacts and those found in any previous specifications, and artifact formats not defined specifically for use with SAML V2.0 MUST NOT be used with this binding.

E6: Clarify Constraints on Encrypted NameID

Change [SAMLCore] Section 3.4.1.1 at line 2139 to clarify that, if encrypted name identifiers are chosen, no further description of the type of name identifier will be available in SAML messages..

New:

E7: Metadata for Agreeing to Sign Authentication Requests

Change [SAMLMeta] Section 2.4.3 at line 710, 741-742, and 744-747 to remove ambiguity about how to accomplish signing when the IdP SSO descriptor includes the setting WantAuthnRequestsSigned and the SP SSO descriptor includes the setting AuthnRequestsSigned. .

New at line 710:

The WantAuthnRequestsSigned attribute is intended to indicate to service providers whether or not they can expect an unsigned <AuthnRequest> message to be accepted by the identity provider. The identity provider is not obligated to reject unsigned requests nor is a service provider obligated to sign its requests, although it might reasonably expect an unsigned request will be rejected. In some cases, a service provider may not even know which identity provider will ultimately receive and respond to its requests, so the use of this attribute in such a case cannot be strictly defined.

Furthermore, note that the specific method of signing that would be expected is binding dependent. The HTTP Redirect binding (see [SAMLBind]) requires that the signature be applied to the URL-encoded value rather than placed within the XML message, while other bindings generally permit the signature to be within the message in the usual fashion.

The following schema fragment defines the <IDPSSODescriptor> element and its IDPSSODescriptorType complex type:

New at lines 741-742:

Optional attribute that indicates whether the <samlp:AuthnRequest> messages sent by this service provider will be signed. If omitted, the value is assumed to be false. A value of false (or omission of this attribute) does not imply that the service provider will never sign its requests or that a signed request should be considered an error. However, an identity provider that receives an unsigned <samlp:AuthnRequest> message from a service provider whose metadata contains this attribute with a value of true MUST return a SAML error response and MUST NOT fulfill the request.

New at lines 744-747:

Optional attribute that indicates a requirement for the <saml:Assertion> elements received by this service provider to be signed. If omitted, the value is assumed to be false. This requirement is in addition to any requirement for signing derived from the use of a particular profile/binding combination. Note that an enclosing signature at the SAML binding or protocol layer does not suffice to meet this requirement, for example signing a <samlp:Response> containing the assertion(s) or a TLS connection.

E8: SLO and NameID Termination

Change [SAMLCore] Section 3.6.3 at lines 2479-2480 to clarify the rules around SP single logout behavior when a name identifier has been terminated.

Original:

The receiving provider can perform any maintenance with the knowledge that the relationship represented by the name identifier has been terminated. It can choose to invalidate the active session(s) of a principal for whom a relationship has been terminated.

New:

The receiving provider can perform any maintenance with the knowledge that the relationship represented by the name identifier has been terminated. In general it SHOULD NOT invalidate any active session(s) of the principal for whom the relationship has been terminated. If the receiving provider is an identity provider, it SHOULD NOT invalidate any active session(s) of the principal established with other service providers. A requesting provider MAY send a <LogoutRequest> message prior to initiating a name identifier termination by sending a <ManageNameIDRequest> message if that is the requesting provider’s intent (e.g., the name identifier termination is initiated via an administrator who wished to terminate all user activity). The requesting provider MUST NOT send a <LogoutRequest> message after the <ManageNameIDRequest> message is sent.

E10: Logout Request Reason Mismatch with Schema

Change [SAMLCore] Section 3.7.1 at line 2540 to resolve an apparent conflict between the specification text and the schema. (Note that although in this case the schema could have been more specific, text in SAML specifications is allowed to impose further restrictions on syntactic constraints imposed by a schema, and this technique has been used here to resolve the issue without a substantive change.)

New:

An indication of the reason for the logout, in the form of a URI reference. The Reason attribute is specified as a string in the schema. This specification further restricts the schema by requiring that the Reason attribute MUST be in the form of a URI reference.

E11: Improperly Labeled Feature

Change [SAMLConf] in Section 3.2 (Table 2) to make the labels in feature rows 6 through 9 consistent.

Original labels:

Name Identifier Management, HTTP Redirect (IdP-initiated)
Name Identifier Management, SOAP (IdP-initiated)
Name Identifier Management, HTTP Redirect
Name Identifier Management, SOAP

New labels:

Name Identifier Management (IdP-Initiated), HTTP Redirect
Name Identifier Management (IdP-Initiated), SOAP
Name Identifier Management (SP-Initiated), HTTP Redirect
Name Identifier Management (SP-Initiated), SOAP

E12: Clarification on ManageNameIDRequest

Change [SAMLCore] Section 3.6 at lines 2412-2413 and 2438, and change [SAMLProf] Section 4.5 at lines 1320-1321, to remove incorrect implications that the name identifier format can be changed in the course of the protocol.

New [SAMLCore] at lines 2412-2413:

After establishing a name identifier for a principal, an identity provider wishing to change the value ~~and/or format~~ of the identifier that it will use when referring to the principal, or to indicate that a name identifier will no longer be used to refer to the principal, informs service providers of the change by sending them a <ManageNameIDRequest> message.

New [SAMLCore] at line 2438:

If the requester is the identity provider, the new value will appear in subsequent <NameID> elements as the element's content. In either case, if the <NewEncryptedID> is used, its encrypted content is just a <NewID> element containing only the new value for the identifier (format and qualifiers cannot be changed once established).

New [SAMLProf] at lines 1320-23121:

Subsequently, the identity provider may wish to notify the service provider of a change in the ~~format and/or~~ value that it will use to identify the same principal in the future.

E13: Inaccurate Description of Authorization Decision

Change [SAMLCore] Section 2 at lines 357-358 to complete the list of potential results from an authorization decision.

New:

Authorization Decision: A request to allow the assertion subject to access the specified resource has been granted or denied or is indeterminate.

E14: AllowCreate

Change [SAMLCore] at lines 2123-2129, 2130, 2143-2147, 2419-2420, and 2480, and change [SAMLProf] at lines 521-524, to clarify the semantics of AllowCreate.

Original at [SAMLCore] Section 3.4.1.1, lines 2123-2129:

A Boolean value used to indicate whether the identity provider is allowed, in the course of fulfilling the request, to create a new identifier to represent the principal. Defaults to "false". When "false", the requester constrains the identity provider to only issue an assertion to it if an acceptable identifier for the principal has already been established. Note that this does not prevent the identity provider from creating such identifiers outside the context of this specific request (for example, in advance for a large number of principals).

New at [SAMLCore] Section 3.4.1.1, lines 2123-2129:

A Boolean value used to indicate whether the requester grants to the identity provider, in the course of fulfilling the request, permission to create a new identifier or to associate an existing identifier representing the principal with the relying party. Defaults to "false" if not present or the entire element is omitted.

New at [SAMLCore] Section 3.4.1.1, line 2130 (just after the above changes):

The AllowCreate attribute may be used by some deployments to influence the creation of state maintained by the identity provider pertaining to the use of a name identifier (or any other persistent, uniquely identifying attributes) by a particular relying party, for purposes such as dynamic identifier or attribute creation, tracking of consent, subsequent use of the Name Identifier Management protocol (see Section 3.6), or other related purposes.

When “false”, the requester tries to constrain the identity provider to issue an assertion only if such state has already been established or is not deemed applicable by the identity provider to the use of an identifier. Thus, this does not prevent the identity provider from assuming such information exists outside the context of this specific request (for example, establishing it in advance for a large number of principals).

A value of “true” permits the identity provider to take any related actions it wishes to fulfill the request, subject to any other constraints imposed by the request and policy (the IsPassive attribute, for example).

Generally, requesters cannot assume specific behavior from identity providers regarding the initial creation or association of identifiers on their behalf, as these are details left to implementations or deployments. Absent specific profiles governing the use of this attribute, it might be used as a hint to identity providers about the requester’s intention to store the identifier or link it to a local value.

A value of “false” might be used to indicate that the requester is not prepared or able to do so and save the identity provider wasted effort.

Requesters that do not make specific use of this attribute SHOULD generally set it to “true” to maximize interoperability.

The use of the AllowCreate attribute MUST NOT be used and SHOULD be ignored in conjunction with requests for or assertions issued with name identifiers with a Format of urn:oasis:names:tc:SAML:2.0:nameid-format:transient (they preclude any such state in and of themselves).

Original at [SAMLCore] Section 3.6, lines 2419-2420:

A service provider also uses this message to register or change the SPProvidedID value to be included when the underlying name identifier is used to communicate with it, or to terminate the use of a name identifier between itself and the identity provider.

Note that this protocol is typically not used with “transient” name identifiers, since their value is not intended to be managed on a long-term basis.

New at [SAMLCore] Section 3.6, lines 2419-2420:

A service provider also uses this message to register or change the SPProvidedID value to be included when the underlying name identifier is used to communicate with it, or to terminate the use of a name identifier between itself and the identity provider.

This protocol MUST NOT be used in conjunction with the urn:oasis:names:tc:SAML:2.0:nameidformat:transient <NameID> Format.

New at [SAMLCore] Section 3.6.3, line 2480 (note that E8 and E55 specify additional changes to the original text shown here):

If the <Terminate> element is included in the request, the requesting provider is indicating that (in the case of a service provider) it will no longer accept assertions from the identity provider or (in the case of an identity provider) it will no longer issue assertions to the service provider about the principal. The receiving provider can perform any maintenance with the knowledge that the relationship represented by the name identifier has been terminated. It can choose to invalidate the active session(s) of a principal for whom a relationship has been terminated.

If the receiving provider is maintaining state associated with the name identifier, such as the value of the identifier itself (in the case of a pair-wise identifier), an SPProvidedID value, the sender’s consent to the identifier’s creation/use, etc., then the receiver can perform any maintenance with the knowledge that the relationship represented by the name identifier has been terminated.

Any subsequent operations performed by the receiver on behalf of the sender regarding the principal (for example, a subsequent <AuthnRequest>) SHOULD be carried out in a manner consistent with the absence of any previous state.

Termination is potentially the cleanup step for any state management behavior triggered by the use of the AllowCreate attribute in the Authentication Request protocol (see Section 3.4). Deployments that do not make use of that attribute are likely to avoid the use of the <Terminate> element or would treat it as a purely advisory matter.

Note that in most cases (a notable exception being the rules surrounding the SPProvidedID attribute), there are no requirements on either identity providers or service providers regarding the creation or use of persistent state. Therefore, no explicit behavior is mandated when the <Terminate> element is received. However, if persistent state is present pertaining to the use of an identifier (such as if an SPProvidedID attribute was attached), the <Terminate> element provides a clear indication that this state SHOULD be deleted (or marked as obsolete in some fashion).

Original at [SAMLProf] Section 4.1.4.1, lines 521-524:

If the identity provider cannot or will not satisfy the request, it MUST respond with a <Response> message containing an appropriate error status code or codes.

If the service provider wishes to permit the identity provider to establish a new identifier for the principal if none exists, it MUST include a <NameIDPolicy> element with the AllowCreate attribute set to "true". Otherwise, only a principal for whom the identity provider has previously established an identifier usable by the service provider can be authenticated successfully.

New at [SAMLProf] Section 4.1.4.1, lines 521-524:

If the identity provider cannot or will not satisfy the request, it MUST respond with a <Response> message containing an appropriate error status code or codes.

This profile does not provide any guidelines for the use of AllowCreate; see [SAMLCore] for normative rules on using AllowCreate.

E15: NameID Policy Adherence

Change [SAMLCore] Section 3.4.1.1 at line 2139 to clarify that the expressed name identifier policy must be adhered to.

New (note that E6 specifies additional changes to the original text shown here):

The special Format value urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted indicates that the resulting assertion(s) MUST contain <EncryptedID> elements instead of plaintext. The underlying name identifier's unencrypted form can be of any type supported by the identity provider for the requested subject.

When a Format defined in Section 8.3 other than urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted is used, then if the identity provider returns any assertions:

 the Format value of the <NameID> within the <Subject> of any <Assertion> MUST be identical to the Format value supplied in the <NameIDPolicy>, and

 if SPNameQualifier is not omitted in <NameIDPolicy>, the SPNameQualifier value of the <NameID> within the <Subject> of any <Assertion> MUST be identical to the SPNameQualifier value supplied in the <NameIDPolicy>.

E17: Authentication Response IssuerName vs. Assertion IssuerName

Change [SAMLProf] Section 4.1.4.2 at lines 541-543 to accurately reflect the conditions under which issuer information is required and how issuer information at the different levels must correlate.

Original:

The <Issuer> element MAY be omitted, but if present it MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity.

New:

If the <Response> message is signed or if an enclosed assertion is encrypted, then the <Issuer> element MUST be present. Otherwise it MAY be omitted. If present it MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity.

E18: Reference to Identity Provider Discovery Service in ECP Profile

Change [SAMLProf] Section 4.2.2 at lines 725-726 to remove the incorrect implication that an ECP is a direct participant in the identity provider discovery profile.

New:

In step 3, the ECP obtains the location of an endpoint at an identity provider for the authentication request protocol that supports its preferred binding. The means by which this is accomplished is implementation-dependent. ~~The ECP MAY use the SAML identity provider discovery profile described in Section 4.3.~~

E19: Clarification on Error Processing

Change [SAMLBind] Section 3.2.2.1 at lines 310-317 and Section 3.2.3.3 at line 378 to clarify SAML error processing and its relationship to SOAP error processing.

Original at Section 3.2.2.1, lines 310-317:

The SAML responder MUST return either a SAML response element within the body of another SOAP message or generate a SOAP fault. The SAML responder MUST NOT include more than one SAML response per SOAP message or include any additional XML elements in the SOAP body. If a SAML responder cannot, for some reason, process a SAML request, it MUST generate a SOAP fault. SOAP fault codes MUST NOT be sent for errors within the SAML problem domain, for example, inability to find an extension schema or as a signal that the subject is not authorized to access a resource in an authorization query. (SOAP 1.1 faults and fault codes are discussed in [SOAP11] Section 4.1.)

New at Section 3.2.2.1, lines 310-317:

The SAML responder SHOULD return a SOAP message containing either a SAML response element in the body or a SOAP fault. The SAML responder MUST NOT include more than one SAML response per SOAP message or include any additional XML elements in the SOAP body. SOAP fault codes SHOULD NOT be sent for errors within the SAML problem domain, for example, inability to find an extension schema or as a signal that the subject is not authorized to access a resource in an authorization query. See Section 3.2.3.3 for more information about error handling. (SOAP 1.1 faults and fault codes are discussed in [SOAP11] Section 4.1.)

Original at Section 3.2.3.3, line 378:

In the case of a SAML processing error, the SOAP HTTP server MUST respond with "200 OK" and include a SAML-specified <samlp:Status> element in the SAML response within the SOAP body.

New at Section 3.2.3.3, line 378:

In the case of a SAML processing error, the SOAP HTTP server SHOULD respond with "200 OK" and include a SAML-specified <samlp:Status> element in the SAML response within the SOAP body.

E20: ECP SSO Profile and Metadata

Change [SAMLProf] at line 1081 to add a new subsection, Section 4.2.6, in order to add metadata considerations to the ECP profile.

New (small portion of previous subsection shown):

The ECP SHOULD be authenticated to the identity provider, such as by maintaining an authenticated session. Any HTTP exchanges subsequent to the delivery of the <AuthnRequest> message and before the identity provider returns a <Response> MUST be securely associated with the original request.

4.2.6 Use of Metadata

The rules specified in the browser SSO profile in Section 4.1.6 apply here as well. Specifically, the indexed endpoint element <md:AssertionConsumerService> with a binding of urn:oasis:namees:tc:SAML:2.0:bindings:PAOS MAY be used to describe the supported binding and location(s) to which an identity provider may send responses to a service provider using this profile. IN addition, the endpoint <md:SingleSignOnService> with a binding of urn:oasis:namees:tc:SAML:2.0:bindings:SOAP MAY be used to describe the supported binding and location(s) to which an service provider may send requests to an identity provider using this profile.

E21: PAOS Version

Change [SAMLBind] Section 3.3.3 at line 474 to clarify the PAOS version required. New:

 The HTTP PAOS Header field MUST be present and specify the PAOS version with "urn:liberty:paos:2003-08" ~~at a minimum~~.

E22: Error in Profile/ECP

Change [SAMLProf] Section 4.2.4.1 at line 907 to refer to the AssertionConsumerServiceURL attribute rather than the AssertionServiceConsumerURL attribute. This was a typographical error.

E24: HTTPS in URI Binding

Change [SAMLBind] Section 3.7 at lines 1349-1351 to make the HTTP support requirements more appropriate in the context of the URI binding.

Original:

Like SOAP, URI resolution can occur over multiple underlying transports. This binding has transport-independent aspects, but also calls out the use of HTTP with SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] as REQUIRED (mandatory to implement).

New:

Like SOAP, URI resolution can occur over multiple underlying transports. This binding has protocol-independent aspects, but also calls out as mandatory the implementation of HTTP URIs.

E25: Metadata Feature in Conformance

Change [SAMLConf] in Section 3.2 (Tables 2 and 4) to add feature rows, and at line 231 to add two subsections, Sections 3.6 and 3.7, in order to reflect conformance aspects of the SAML metadata feature.

New in Table 2:

Feature IdP IdP Lite SP SP Lite ECP
Metadata Structures OPT OPT OPT OPT N/A
Metadata Interoperation OPT OPT OPT OPT N/A

New in Table 4:

Feature Authn Attrib Authz Requester
Metadata Structures OPT OPT OPT OPT
Metadata Interoperation OPT OPT OPT OPT

New at line 231 (small portion of previous subsection shown):

If a SAML authority uses SSL 3.0 or TLS 1.0, it MUST use a server-side certificate.

3.6 Metadata Structures

Implementations claiming conformance to SAML V2.0 may declare each operational mode's conformance to SAML V2.0 Metadata [SAMLMeta] through election of the Metadata Structures option.

With respect to each operational mode, such conformance entails the following:

 Implementing SAML metadata according to the extensible SAML V2.0 Metadata format in all cases where an interoperating peer has the option, as stated in SAML V2.0 specifications, of depending on the existence of SAML V2.0 Metadata. Electing the Metadata Structures option has the effect of requiring that such metadata be available to the interoperating peer. The Metadata Interoperation feature, described below, provides a means of satisfying this requirement.

 Referencing, consuming, and adhering to the SAML metadata, according to [SAMLMeta], of an interoperating peer when the known metadata relevant to that peer and the particular operation, and the current exchange, has expired or is no longer valid in cache, provided the metadata is available and is not prohibited by policy or the particular operation and that specific exchange.

3.7 Metadata Interoperation

Election of the Metadata Interoperation option requires the implementation to offer, in addition to any other mechanism, the well-known location publication and resolution mechanism described in the SAML metadata specification [SAMLMeta].

E26: Ambiguities Around Multiple Assertions and Statements in the SSO Profile

Change [SAMLProf] Section 4.1.4.2 at lines 541-572, Section 4.1.4.3 at lines 576-591, and Section 4.1.4.5 at lines 600-601 to resolve ambiguities around the usage of multiple assertions and multiple statements within an assertion in the SSO profile.

Original at Section 4.1.4.2, lines 541-572:

The <Issuer> element MAY be omitted, but if present it MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity.
It MUST contain at least one <Assertion>. Each assertion's <Issuer> element MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity.
The set of one or more assertions MUST contain at least one <AuthnStatement> that reflects the authentication of the principal to the identity provider.
At least one assertion containing an <AuthnStatement> MUST contain a <Subject> element with at least one <SubjectConfirmation> element containing a Method of urn:oasis:names:tc:SAML:2.0:cm:bearer. If the identity provider supports the Single Logout profile, defined in Section 4.4, any such authentication statements MUST include a SessionIndex attribute to enable per-session logout requests by the service provider.
The bearer <SubjectConfirmation> element described above MUST contain a <SubjectConfirmationData> element that contains a Recipient attribute containing the service provider's assertion consumer service URL and a NotOnOrAfter attribute that limits the window during which the assertion can be delivered. It MAY contain an Address attribute limiting the client address from which the assertion can be delivered. It MUST NOT contain a NotBefore attribute. If the containing message is in response to an <AuthnRequest>, then the InResponseTo attribute MUST match the request's ID.
Other statements and confirmation methods MAY be included in the assertion(s) at the discretion of the identity provider. In particular, <AttributeStatement> elements MAY be included. The <AuthnRequest> MAY contain an AttributeConsumingServiceIndex XML attribute referencing information about desired or required attributes in [SAMLMeta]. The identity provider MAY ignore this, or send other attributes at its discretion.
The assertion(s) containing a bearer subject confirmation MUST contain an <AudienceRestriction> including the service provider's unique identifier as an <Audience>.
Other conditions (and other <Audience> elements) MAY be included as requested by the service provider or at the discretion of the identity provider. (Of course, all such conditions MUST be understood by and accepted by the service provider in order for the assertion to be considered valid.) The identity provider is NOT obligated to honor the requested set of <Conditions> in the <AuthnRequest>, if any.

The identity provider is NOT obligated to honor the requested set of <Conditions> in the <AuthnRequest>, if any.

New at Section 4.1.4.2, lines 541-572 (note that E17 specifies additional changes to the first bullet item shown here):

The <Issuer> element MAY be omitted, but if present it MUST contain the unique identifier of the issuing identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity.
It MUST contain at least one <Assertion>. Each assertion's <Issuer> element MUST contain the unique identifier of the responding identity provider; the Format attribute MUST be omitted or have a value of urn:oasis:names:tc:SAML:2.0:nameid-format:entity. Note that this profile assumes a single responding identity provider, and all assertions in a response MUST be issued by the same entity.
If multiple assertions are included, then each assertion's <Subject> element MUST refer to the same principal. It is allowable for the content of the <Subject> elements to differ (e.g. using different <NameID> or alternative <SubjectConfirmation> elements).

Any assertion issued for consumption using this profile MUST contain a <Subject> element with at least one <SubjectConfirmation> element containing a Method of urn:oasis:names:tc:SAML:2.0:cm:bearer. Such an assertion is termed a bearer assertion. Bearer assertions MAY contain additional <SubjectConfirmation> elements.
Assertions without a bearer <SubjectConfirmation> MAY also be included; processing of additional assertions or <SubjectConfirmation> elements is outside the scope of this profile.
At lease one bearer <SubjectConfirmation> element MUST contain a <SubjectConfirmationData> element that itself MUST contain a Recipient attribute containing the service provider's assertion consumer service URL and a NotOnOrAfter attribute that limits the window during which the assertion can be [PE52]confirmed by the relying party. It MAY also contain an Address attribute limiting the client address from which the assertion can be delivered. It MUST NOT contain a NotBefore attribute. If the containing message is in response to an <AuthnRequest>, then the InResponseTo attribute MUST match the request's ID.
The set of one or more bearer assertions MUST contain at least one <AuthnStatement> that reflects the authentication of the principal to the identity provider. Multiple <AuthnStatement> elements MAY be included, but the semantics of multiple statements is not defined by this profile.
If the identity provider supports the Single Logout profile, defined in Section , any authentication statements MUST include a SessionIndex attribute to enable per-session logout requests by the service provider.

Other statements MAY be included in the bearer assertion(s) at the discretion of the identity provider. In particular, <AttributeStatement> elements MAY be included. The <AuthnRequest> MAY contain an AttributeConsumingServiceIndex XML attribute referencing information about desired or required attributes in [SAMLMeta]. The identity provider MAY ignore this, or send other attributes at its discretion.
Each bearer assertion MUST contain an <AudienceRestriction> including the service provider's unique identifier as an <Audience>.
Other conditions (and other <Audience> elements) MAY be included as requested by the service provider or at the discretion of the identity provider. (Of course, all such conditions MUST be understood by and accepted by the service provider in order for the assertion to be considered valid.) The identity provider is NOT obligated to honor the requested set of <Conditions> in the <AuthnRequest>, if any.

The identity provider is NOT obligated to honor the requested set of <Conditions> in the <AuthnRequest>, if any.

Original at Section 4.1.4.3, lines 576-591:

• Verify that the Recipient attribute in any bearer <SubjectConfirmationData> matches the assertion consumer service URL to which the <Response> or artifact was delivered

• Verify that the NotOnOrAfter attribute in any bearer <SubjectConfirmationData> has not passed, subject to allowable clock skew between the providers

• Verify that the InResponseTo attribute in the bearer <SubjectConfirmationData> equals the ID of its original <AuthnRequest> message, unless the response is unsolicited (see Section 4.1.5 ), in which case the attribute MUST NOT be present

• Verify that any assertions relied upon are valid in other respects.