SAML Version 2.0 Errata 05

1       Introduction

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.

This is yet another original specification sentence which contains an inappropriately long description.

2       Approved Errata

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, either via a digital signature (see Section 3.4.4.1) or by some independent means.

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.

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.

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. It is not possible for the service provider to specifically request that a particular kind of identifier be returned if it asks for encryption. The <md:NameIDFormat> metadata element (see [SAMLMeta]) or other out-of-band means MAY be used to determine what kind of identifier to encrypt and return.

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:

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.

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.

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.

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.

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

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.

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).

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.

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

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.

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).

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.

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).

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.

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 Error: Reference source not found8.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:

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

l 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>.

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.

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.

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.)

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.

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:names: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:names: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.

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

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.

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

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

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:

l 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.

l 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].

• 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 Error: Reference source not found, 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.

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

• Verify that the NotOnOrAfter attribute in the 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. Note that while multiple bearer <SubjectConfirmation> elements may be present, the successful evaluation of a single such element in accordance with this profile is sufficient to confirm an assertion. However, each assertion, if more than one is present, MUST be evaluated independently.

• If any the bearer <SubjectConfirmationData> includes an Address attribute, the service provider MAY check the user agent's client address against it.

• Any assertion which is not valid, or whose subject confirmation requirements cannot be met SHOULD be discarded and SHOULD NOT be used to establish a security context for the principal.

• If an <AuthnStatement> used to establish a security context for the principal contains a SessionNotOnOrAfter attribute, the security context SHOULD be discarded once this time is reached, unless the service provider reestablishes the principal's identity by repeating the use of this profile. Note that if multiple <AuthnStatement> elements are present, the SessionNotOnOrAfter value closest to the present time SHOULD be honored.

If the HTTP POST binding is used to deliver the <Response>, each assertion MUST be protected by a digital signature. This can be accomplished by signing each individual <Assertion> element or by signing the <Response> element.

Feature                                                                                          IdP          IdP Lite  SP           SP Lite   ECP
Request for Assertion by Identifier                       OPT        N/A         N/A         N/A         N/A
SAML URI Binding                                                      OPT        N/A         N/A         N/A         N/A

Encrypted data and zero or more encrypted keys MUST replace the plaintext information in the same location within the XML instance.

If no such RelayState data is included with a SAML request message, or if the SAML response message is being generated without a corresponding request ...

The SAML requester determines the SAML responder by examining the artifact, and issues a <samlp:ArtifactResolve> request containing the artifact to the SAML responder using a synchronous SAML binding, as in step 3.

Note that the URI syntax does not support the use of wildcards in such ID queries.

4.3.1 Required Information

Identification: urn:oasis:names:tc:SAML:2.0:profiles:SSO:idp-discovery

Contact information: security-services-comment@lists.oasis-open.org

Description: Given below.

Updates: None.

Specifies where the ECP is to send an error response. Also used to verify the correctness of the identity provider's response, by cross checking this location against the AssertionConsumerServiceURL in the ECP response header block. This value MUST be the same as the AssertionServiceConsumerURL (or the URL referenced in metadata) conveyed in the <AuthnRequest> and SHOULD NOT be a relative URL.

<paos:Request xmlns:paos="urn:liberty:paos:2003-08"
   responseConsumerURL="
https://ServiceProvider.example.com/ecp_assertion_consumer"

Namespace [Required]

A URI reference representing the namespace in which the name of the specified action is to be interpreted.

In any such sequence of indexed endpoints that share a common element name and namespace (i.e. all instances of <md:AssertionConsumerService> within a role), the default endpoint is the first such endpoint with the isDefault attribute set to true.

<SessionIndex> [Optional]

The index of the session between the principal identified by the <saml:BaseID>, <saml:NameID>, or <saml:EncryptedID> element, and the session authority. This must correlate to the SessionIndex attribute, if any, in the <saml:AuthnStatement> of the assertion used to establish the session that is being terminated.

If the requester is a session participant, it MUST include at least one <SessionIndex> element in the request. (Note that the session participant always receives a SessionIndex attribute in the <saml:AuthnStatement> elements that it receives to initiate the session, per Section 4.1.4.2 of the Web Browser SSO Profile.) If the requester is a session authority (or acting on its behalf), then it MAY omit any such elements to indicate the termination of all of the principal's applicable sessions.

<saml:Attribute
  xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML"
  xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP"
  xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"
  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
  Name="urn:oid:2.5.4.42" FriendlyName="givenName">
  <saml:AttributeValue xsi:type="xs:string"
  ldapprof:Encoding="LDAP">By-Tor</saml:AttributeValue>
</saml:Attribute>

As described in [XMLSig], each <ds:KeyInfo> element holds a key or information that enables an application to obtain a key. The holder of a specified key is considered to be an acceptable attesting entity for the assertion by the asserting party.

The ResponseLocation attribute is used to enable different endpoints to be specified for receiving request and response messages associated with a protocol or profile, not as a means of load-balancing or redundancy (multiple elements of this type can be included for this purpose). When a role contains an element of this type pertaining to a protocol or profile for which only a single type of message (request or response) is applicable, then the ResponseLocation attribute is unused. If the ResponseLocation attribute is omitted, any response messages associated with a protocol or profile may be assumed to be handled at the URI indicated by the Location attribute.

Feature                                                                                          Authn     Attrib       Authz      Requester
Authentication Query, SOAP                                     MUST     N/A         N/A         OPT
Attribute Query, SOAP                                                                N/A         MUST     N/A         OPT
Authorization Decision Query, SOAP                      N/A         N/A         MUST     OPT

6.2 Key and Data Referencing Guidelines

If an encrypted key is NOT included in the XML instance, then the relying party must be able to locally determine the decryption key, per [XMLEnc].

Implementations of SAML MAY implicitly associate keys with the corresponding data they are used to encrypt, through the positioning of <xenc:EncryptedKey> elements next to the associated <xenc:EncryptedData> element, within the enclosing SAML parent element. However, the following set of explicit referencing guidelines are suggested to facilitate interoperability.

If the encrypted key is included in the XML instance, then it SHOULD be referenced within the associated <xenc:EncryptedData> element, or alternatively embedded within the <xenc:EncryptedData> element. When an <xenc:EncryptedKey> element is used, the <ds:KeyInfo> element within <xenc:EncryptedData> SHOULD reference the <xenc:EncryptedKey> element using a <ds:RetrievalMethod> element of Type http://www.w3.org/2001/04/xmlenc#EncryptedKey.

In addition, an <xenc:EncryptedKey> element SHOULD contain an <xenc:ReferenceList> element containing a <xenc:DataReference> that references the corresponding <xenc:EncryptedData> element(s) that the key was used to encrypt.

In scenarios where the encrypted element is being “multicast” to multiple recipients, and the key used to encrypt the message must be in turn encrypted individually and independently for each of the multiple recipients, the <xenc:CarriedKeyName> element SHOULD be used to assign a common name to each of the <xenc:EncryptedKey> elements so that a <ds:KeyName> can be used from within the <xenc:EncryptedData> element’s <ds:KeyInfo> element.

Within the <xenc:EncryptedData> element, the <ds:KeyName> can be thought of as an “alias” that is used for backwards referencing from the <xenc:CarriedKeyName> element in each individual <xenc:EncryptedKey> element. While this accommodates a “multicast” approach, each recipient must be able to understand (at least one) <ds:KeyName>. The Recipient attribute is used to provide a hint as to which key is meant for which recipient.

The SAML implementation has the discretion to accept or reject a message where multiple Recipient attributes or <ds:KeyName> elements are understood. It is RECOMMENDED that implementations simply use the first key they understand and ignore any additional keys.

6.3 Examples

In the following example, the parent element (<EncryptedID>) contains <xenc:EncryptedData> and (referenced) <xenc:EncryptedKey> elements as siblings (note that the key can in fact be anywhere in the same instance, and the key references the <xenc:EncryptedData> element):

<saml:EncryptedID       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    Id="Encrypted_DATA_ID"
    Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:RetrievalMethod URI="#Encrypted_KEY_ID"
      Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>Nk4W4mx...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>

  <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    Id="Encrypted_KEY_ID">
    <xenc:EncryptionMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
    <xenc:CipherData>
    <xenc:CipherValue>PzA5X...</xenc:CipherValue>
    </xenc:CipherData>
    <xenc:ReferenceList>
      <xenc:DataReference URI="#Encrypted_DATA_ID"/>
    </xenc:ReferenceList>
  </xenc:EncryptedKey>

In the following <EncryptedAttribute> example, the <xenc:EncryptedKey> element is contained within the <xenc:EncryptedData> element, so there is no explicit referencing:

<saml:EncryptedAttribute
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    Id="Encrypted_DATA_ID"
    Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod
      Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <xenc:EncryptedKey Id="Encrypted_KEY_ID">
        <xenc:EncryptionMethod
          Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <xenc:CipherData>
          <xenc:CipherValue>SDFSDF... </xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>Nk4W4mx...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</saml:EncryptedAttribute>

The final example shows an assertion encrypted for multiple recipients, using the <xenc:CarriedKeyName> approach:

<saml:EncryptedAssertion
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    Id="Encrypted_DATA_ID"
    Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod
      Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:KeyName>MULTICAST_KEY_NAME</ds:KeyName>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>Nk4W4mx...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>

  <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    Id="Encrypted_KEY_ID_1" Recipient="https://sp1.org">
    <xenc:EncryptionMethod
      Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:KeyName>KEY_NAME_1</ds:KeyName>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>xyzABC...</xenc:CipherValue>
    </xenc:CipherData>
    <xenc:ReferenceList>
      <xenc:DataReference URI="#Encrypted_DATA_ID"/>
    </xenc:ReferenceList>

    <xenc:CarriedKeyName>MULTICAST_KEY_NAME</xenc:CarriedKeyName>
  </xenc:EncryptedKey>

  <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    Id="Encrypted_KEY_ID_2" Recipient="https://sp2.org">
    <xenc:EncryptionMethod
      Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:KeyName>KEY_NAME_2</ds:KeyName>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>abcXYZ...</xenc:CipherValue>
    </xenc:CipherData>
    <xenc:ReferenceList>
      <xenc:DataReference URI="#Encrypted_DATA_ID"/>
    </xenc:ReferenceList>

    <xenc:CarriedKeyName>MULTICAST_KEY_NAME</xenc:CarriedKeyName>
  </xenc:EncryptedKey>
</saml:EncryptedAssertion>

Either a set of class references or a set of declaration references can be used. If ordering is relevant to the evaluation of the request, then the set of supplied references MUST be evaluated as an ordered set, where the first element is the most preferred authentication context class or declaration. If none of the specified classes or declarations can be satisfied in accordance with the rules below, then the responder MUST return a <Response> message with a second-level <StatusCode> of urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext. For example, ordering is significant when using this element in an <AuthnRequest> message but not in an <AuthnQuery> message.

If Comparison is set to "better", then the resulting authentication context in the authentication statement MUST be stronger (as deemed by the responder) than one of the authentication contexts specified.

Note that multiple <AudienceRestriction> elements MAY be included in a single assertion, and each MUST be evaluated independently. The effect of this requirement and the preceding definition is that within a given <AudienceRestrictions>, the <Audience> elements form a disjunction (an "OR") while multiple <AudienceRestrictions> elements form a conjunction (an "AND").

If the <SubjectConfirmation> element in an assertion subject contains an identifier the issuer authorizes the attesting entity to wield the assertion on behalf of that subject. A relying party MAY apply additional constraints on the use of such an assertion at its discretion, based upon the identities of both the subject and the attesting entity.

If an assertion is issued for use by an entity other than the subject, then that entity SHOULD be identified in the <SubjectConfirmation> element.

The following schema fragment defines the <SubjectConfirmation> element and its SubjectConfirmationType complex type:

As described in [XMLSig], each <ds:KeyInfo> element holds a key or information that enables an application to obtain a key. The holder of one or more of the specified keys is considered to be the subject of the assertion by the asserting party.

If the <SubjectConfirmation> element in an assertion subject contains an identifier the issuer authorizes the attesting entity to wield the assertion on behalf of that subject. A relying party MAY apply additional constraints on the use of such an assertion at its discretion, based upon the identities of both the subject and the attesting entity.

If an assertion is issued for use by an entity other than the subject, then that entity SHOULD be identified in the <SubjectConfirmation> element.

Example: The holder of the key named "By-Tor" or the holder of the key named "Snow Dog" can confirm itself as the subject.

The subject of the assertion is considered to be an acceptable attesting entity for the assertion by the asserting party, subject to optional constraints on confirmation using the attributes that MAY be present in the <SubjectConfirmationData> element, as defined by [SAMLCore].

If the intended bearer is known by the asserting party to be an entity other than the subject, then the asserting party SHOULD identify that entity to the relying party by including a SAML identifier representing it in the enclosing <SubjectConfirmation> element.

If multiple attesting entities are to be permitted to use the assertion based on bearer semantics, then multiple <SubjectConfirmation> elements SHOULD be included.

For all other LDAP syntaxes, the attribute value is encoded, as the content of the <AttributeValue> element, by base64-encoding [RFC2045] the contents of the ASN.1 OCTET STRING-encoded LDAP attribute value (not including the ASN.1 OCTET STRING wrapper). The xsi:type XML attribute MUST be set to xs:base64Binary. The profile-specific Encoding XML attribute is provided, with a value of “LDAP”.

<AttributeValue> [Any Number]

Contains a value of the attribute. If an attribute contains more than one discrete value, it is RECOMMENDED that each value appear in its own <AttributeValue> element. If more than one <AttributeValue> element is supplied for an attribute, and any of the elements have a datatype assigned through xsi:type, then all of the <AttributeValue> elements must have the identical datatype assigned.

Attributes are identified/named by the combination of the NameFormat and Name XML attributes described above. Neither one in isolation can be assumed to be unique, but taken together, they ought to be unambiguous within a given deployment.

The SAML profiles specification [SAMLProf] includes a number of attribute profiles designed to improve the interoperability of attribute usage in some identified scenarios. Such profiles typically include constraints on attribute naming and value syntax. There is no explicit indicator when an attribute profile is in use, and it is assumed that deployments can establish this out of band, based on the combination of NameFormat and Name.

SAML V2.0 uses XML Signature [XMLSig] to implement XML signing and encryption functionality for integrity, and source authentication. SAML V2.0 uses XML Encryption [XMLEnc] to implement confidentiality, including encrypted identifiers, encrypted assertions, and encrypted attributes. The algorithms listed below as being required for SAML V2.0 conformance are based on the mandated algorithms in the W3C recommendations for XML Signature and for XML Encryption, but modified by the SSTC to ensure interoperability of conformant SAML implementations. While the SAML-defined set of algorithms is a minimal set for conformance, additional algorithms supported by XML Signature and XML Encryption MAY be used. Note, however, that the use of non-mandated algorithms may introduce interoperability issues if those algorithms are not widely implemented. As additional algorithms become mandated for use in XML Signature and XML Encryption, the set required for SAML conformance may be extended.

In any SAML V2.0 use of SSL 3.0 [SSL3] or TLS 1.0 [RFC 2246], servers MUST authenticate to clients using a X.509 v3 certificate. The client MUST establish server identity based on contents of the certificate (typically through examination of the certificate’s subject DN field). The set of algorithms required for SAML V2.0 conformance is equivalent to that defined in SAML V1.0 and SAML V1.1. These mandated algorithms were chosen by the SSTC because of their wide implementation support in the industry. While the algorithms defined below are the minimal set for SAML conformance, additional algorithms supported by SSL 3.0 and TLS 1.0 MAY be used.

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 confirmed by the relying party. It MAY contain an Address attribute limiting the client address from which the assertion can be delivered.

8.2 X.500/LDAP Attribute Profile – Deprecated

NOTE: This attribute profile is deprecated because of a flaw that makes it schema-invalid. The SSTC has replaced it with a separately published SAML V2.0 X.500/LDAP Attribute Profile specification that removes this flaw.

Directories based on the ITU-T X.500 specifications [X.500] and the related IETF Lightweight Directory Access Protocol specifications [LDAP] are widely deployed....

Furthermore, support for this profile MUST be specified in the HTTP PAOS Header field as a service value, with the value "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp".

GET /index HTTP/1.1
Host: identity-service.example.com
Accept: text/html; application/vnd.paos+xml
PAOS: ver="urn:liberty:paos:2003-08" ;
"urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"

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 using that identifier. The receiving provider can perform any maintenance with the knowledge that the relationship represented by the name identifier has been terminated.

If the service provider requests that its identifier for the principal be changed by including a <NewID> (or <NewEncryptedID>) element, the identity provider MUST include the element's content as the SPProvidedID when subsequently communicating to the service provider using the primary identifier.

If the identity provider requests that its identifier for the principal be changed by including a <NewID> (or <NewEncryptedID>) element, the service provider MUST use the element's content as the <saml:NameID> element content when subsequently communicating with the identity provider in any case where the identifier being changed would have been used.

The element's SPNameQualifier attribute, if present, MUST contain the unique identifier of the service provider or affiliation of providers for whom the identifier was generated (see Section 8.3.6). It MAY be omitted if the element is contained in a message intended only for consumption directly by the service provider, and the value would be the unique identifier of that service provider.

The element's SPProvidedID attribute MUST contain the alternative identifier of the principal most recently set by the service provider or affiliation, if any (see Section 3.6). If no such identifier has been established, then the attribute MUST be omitted.

In the scenario supported by the Name Identifier Management profile, an identity provider has exchanged some form of long-term identifier (including but not limited to identifiers with a Format of urn:oasis:names:tc:SAML:2.0:nameid-format:persistent) for a principal with a service provider, allowing them to share a common identifier for some length of time. 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. Alternatively the service provider may wish to attach its own "alias" for the principal in order to ensure that the identity provider will include it when communicating with it in the future using that identifier. Finally, one of the providers may wish to inform the other that it will no longer issue or accept messages using a particular identifier. To implement these scenarios, a profile of the SAML Name Identifier Management protocol is used.

[SAMLmime]                OASIS Security Services Technical Committee (SSTC),
                         "application/samlassertion+xml MIME Media Type Registration", IANA
                        MIME Media Types Registry application/samlassertion+xml, December
                        2004. See http://www.iana.org/assignments/media-
                        types/application/samlassertion+xml.

The providers MAY document the key(s) used to sign requests, responses, and assertions with <md:KeyDescriptor> elements with a use attribute of signing. When encrypting SAML elements, <md:KeyDescriptor> elements with a use attribute of encryption MAY be used to document supported encryption algorithms and settings, and public keys used to receive bulk encryption keys.

Note also that there is no mechanism defined to protect the integrity of the relationship between the artifact and the "RelayState" value, if any. That is, an attacker can potentially recombine a pair of valid HTTP responses by switching the "RelayState" values associated with each artifact. As a result, the producer/consumer of "RelayState" information MUST take care not to associate sensitive state information with the "RelayState" value without taking additional precautions (such as based on the information in the SAML protocol message retrieved via artifact).

Finally, note that the use of the Destination attribute in the root SAML element of the protocol message is unspecified by this binding, because of the message indirection involved.

The following SAML protocol constructs are intended specifically for use as extension points in an extension schema; the types listed are set to abstract, and are thus usable only as the base of a derived type:

• RequestAbstractType

• <SubjectQuery> and SubjectQueryAbstractType

A use value of "signing" means that the contained key information is applicable to both signing and TLS/SSL operations performed by the entity when acting in the enclosing role.

A use value of "encryption" means that the contained key information is suitable for use in wrapping encryption keys for use by the entity when acting in the enclosing role.

If the use attribute is omitted, then the contained key information is applicable to both of the above uses.

The following schema fragment defines the <KeyDescriptor> element and its KeyDescriptorType complex type:

Cookie syntax should be in accordance with IETF RFC 2965 [RFC2965] or [NSCookie]. The cookie MAY be either session-only or persistent. This choice may be made within a deployment, but should apply uniformly to all identity providers in the deployment. Note that while a session-only cookie can be used, the intent of this profile is not to provide a means of determining whether a user actually has an active session with one or more of the identity providers stored in the cookie. The cookie merely identifies identity providers known to have been used in the past. Service providers MAY instead rely on the IsPassive attribute in their <samlp:AuthnRequest> message to probe for active sessions.

Cookies posted by identity providers MAY be used to support this validation process, though LibertySAML V2.0 does not mandate a cookie-based approach.

If none of the specified classes or declarations can be satisfied in accordance with the rules below, then the responder MUST return a <Response> message with a top-level <StatusCode> value of urn:oasis:names:tc:SAML:2.0:status:Responder and MAY return a second-level <StatusCode> of urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext.

In profiles specifying an active intermediary, the intermediary MAY examine the list and return a

<Response> message with an error <Status> and optionally a second-level <StatusCode> of

Unless the identity provider can directly authenticate the presenter, it MUST return a <Response> message with a top-level <StatusCode> value of urn:oasis:names:tc:SAML:2.0:status:Responder and MAY return a second-level <StatusCode> value of urn:oasis:names:tc:SAML:2.0:status:ProxyCountExceeded.

If the responder does not recognize the principal identified in the request, it MAY respond with an error <Status>, optionally containing a second-level <StatusCode> of urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal.

It is RECOMMENDED that entities publish their resource records in signed zone files using [RFC2535] [RFC4035]

[RFC4035] R. Arends et al. Protocol Modifications for the DNS Security Extensions. IETF RFC 4035, March 2005. See http://www.ietf.org/rfc/rfc4035.txt.

The inclusion of multiple <KeyDescriptor> elements with the same use attribute (or no such attribute) indicates that any of the included keys may be used by the containing role or affiliation. A relying party SHOULD allow for the use of any of the included keys. When possible the signing or encrypting party SHOULD indicate as specifically as possible which key it used to enable more efficient processing.

The following schema fragment defines the <KeyDescriptor> element and its KeyDescriptorType complex type:

The <ds:KeyInfo> element is a highly generic and extensible means of communicating key material. This specification takes no position on the allowable or suggested content of this element, nor on its meaning to a relying party. As a concrete example, no implications of including an X.509 certificate by value or reference are to be assumed. Its validity period, extensions, revocation status, and other relevant content may or may not be enforced, at the discretion of the relying party. The details of such processing, and their security implications, are out of scope; they may, however, be addressed by other SAML profiles.

The following schema fragment defines the <KeyDescriptor> element and its KeyDescriptorType complex type:

values are equal in the sense of [http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt][RFC4122]. The

values are equal in the sense of [http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt][RFC4122]. The

[RFC4122] P. Leach et al. A Universally Unique IDentifier (UUID) URN Namespace. IETF RFC 4122, July 2005. See http://www.ietf.org/rfc/rfc4122.txt.

xs:

http://www.w3.org/2001/XMLSchema

This namespace is defined in the W3C XML Schema specification [Schema1]. In schema listings, this is the default namespace and no prefix is shown. For clarity, the prefix is generally shown in specification text when XML Schema-related constructs are mentioned.

In such a case, the identifier's physical content MAY be different, but it MUST refer to the same principal. If the identity provider cannot or will not produce assertions with a strongly matching subject, then it MUST return a <Response> with an error <Status>, and MAY return a second-level <StatusCode> that reflects the reason for the failure.

When not used as the root element of a metadata instance, a validUntil or cacheDuration attribute MAY be used to impose a shorter expiration or cache duration than that of the parent or root element, but never a longer one; the smaller value takes precedence.

A validUntil or cacheDuration attribute MAY be used to impose a shorter expiration or cache duration than that of the parent or root element, but never a longer one; the smaller value takes precedence.

A variety of extension points are also included to allow for the use of SAML metadata in non-SAML specifications, profiles, and deployments, and such use is encouraged.

SAML metadata is organized around an extensible collection of roles representing common combinations of SAML (and potentially non-SAML) protocols and profiles supported by system entities.

Persistent name identifier values MUST NOT exceed a length of 256 characters. A given value, once associated with a principal, MUST NOT be assigned to a different principal at any time in the future.

Indicates an upper bound on sessions with the subject derived from the enclosing assertion. The time value is encoded in UTC, as described in Section 1.3.3. There is no required relationship between this attribute and a NotOnOrAfter condition attribute that may be present in the assertion. It's left to profiles to provide specific processing rules for relying parties based on this attribute.

Any algorithm defined for use with the XML Signature specification MAY be used.

At least one child element SHOULD be present in a <ContactPerson> element.

Use of Exclusive Canonicalization facilitates the verification of signatures created over SAML messages when placed into a different XML context than present during signing.

Note that use of this algorithm alone does not guarantee that a particular signed object can be moved from one context to another safely, nor is that a requirement of signed SAML objects in general, though it MAY be required by particular profiles

If the Format value is omitted or set to urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified

Identity provider implementations SHOULD support the issuance of  <saml2p:Response> messages (with appropriate status codes) in the event of an error condition, provided that the user agent remains available and an acceptable location to which to deliver the response is available. The criteria for "acceptability" of a response location are not formally specified, but are subject to identity provider policy and reflect its responsibility to protect users from being sent to untrusted or possibly malicious parties.

Persistent name identifiers generated by identity providers MUST be constructed using values that have no discernible correspondence with the subject's actual identity (for example, username). They MAY be pseudo-random values, or generated in any other manner, provided there is no guessable relationship between the value and the subject's underlying identity, and that they are unique within the range of values generated by a given identity provider for a given service provider or affiliation of providers.

At most one <AttributeConsumingService> element can have the attribute isDefault set to true. The default element is the first element with the isDefault attribute set to true. If no such elements exist, the default element is the first element without the isDefault attribute set to false. If no such elements exist, the default element is the first element in the sequence.

One or more language-qualified names for the service that are suitable for human consumption.

If no NameFormat value is provided, the identifier urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified (see Section 8.2.1 of [SAMLCore]) is in effect.

Some bindings that define a "RelayState" mechanism do not provide for end to end origin authentication or integrity protection of the RelayState value. Most such bindings are defined in conjunction with HTTP, and RelayState is often involved in the preservation of HTTP resource state that may involve the use of HTTP redirects, or embedding of RelayState information in HTTP responses, HTML content, etc. In such cases, implementations need to beware of Cross-Site Scripting (XSS) and other attack vectors (e.g., Cross-Site Request Forgery, CSRF) that are common to such scenarios.

Implementations MUST carefully sanitize the URL schemes they permit (for example, disallowing anything but "http" or "https"), and should disallow unencoded characters that may be used in mounting such attacks. This caution applies to both identity and service provider implementations.

When using RelayState in conjunction with HTTP redirects or response information, implementations MUST carefully sanitize the URL schemes they permit (for example, disallowing anything but "http" or "https"), and should disallow unencoded characters that may be used in mounting such attacks.

Note that the use of unsolicited responses can lead to Cross-Site Request Forgery (CSRF) vulnerabilities due to the inability to ensure that a request from the client originated the SAML profile transaction. Service providers SHOULD have a means of disabling the acceptance of unsolicited responses if circumstances warrant. The use of solicited responses may also be vulnerable to such attacks, the use of cookies to correlate the issuance of SAML requests and responses with the same client being one possible solution. However, if unsolicited respones cannot be prevented, no improvement to the solicited case will be of use.

4.1.6 Use of Relay State

The RelayState feature of the various HTTP-based bindings defined for use with this profile MAY be used to preserve information about resources requested by the user agent prior to the use of the profile. As discussed in [SAMLBind], the lack of integrity protection in many scenarios, including the case of unsolicited responses, makes it essential for identity and service providers to perform appropriate sanitization of the RelayState value and any URLs derived from it. The URL scheme eventually derived SHOULD be limited to "https" or "http", and protection against unencoded executable content must be applied.

The RelayState header block defined for use with this profile MAY be used to preserve information about resources requested by the client prior to the use of the profile. As discussed in [SAMLBind], the lack of integrity protection in many scenarios, including the case of unsolicited responses, makes it essential for identity and service providers to perform appropriate sanitization of the RelayState value and any URLs derived from it. The URL scheme eventually derived SHOULD be limited to "https" or "http", and protection against unencoded executable content must be applied.

5.4.5 Object

The <ds:Object> element is not defined for use with SAML signatures, and SHOULD NOT be present. Since it can be used in service of an attacker by carrying unsigned data, verifiers SHOULD reject signatures that contain a <ds:Object> element.

3.1.5 Object

The <ds:Object> element is not defined for use with SAML metadata signatures, and SHOULD NOT be present. Since it can be used in service of an attacker by carrying unsigned data, verifiers SHOULD reject signatures that contain a <ds:Object> element.

SAML system entities SHOULD allow for reasonable clock skew between systems when interpreting time instants and enforcing security policies based on them. Tolerances of 3-5 minutes are reasonable defaults, but allowing for configurability is a suggested practice in implementations.

As noted in section 1.3.3, relying parties SHOULD allow for reasonable clock skew in the interpretation of both values.

As noted in section 1.3.3, relying parties SHOULD allow for reasonable clock skew in the interpretation of both values.

As noted in that same section, relying parties SHOULD allow for reasonable clock skew in the interpretation of this value.

6.2 Encryption and Integrity Protection

SAML allows for assertions containing encrypted elements to be integrity protected, and allows for encrypted assertions to be included inside protocol response elements that are themselves integrity protected (typically via XML Signature, or in some cases through binding-specific mechanisms such as TLS).

Recent practical attacks against the most common algorithms (at the time of this writing) used for bulk data encryption in [XMLEnc], which operate in CBC-mode, necessitate the enforcement of integrity protection by a relying party prior to processing encrypted data. As a result, when CBC-mode algorithms are used for data encryption, relying parties SHOULD require the presence of integrity protection before processing encrypted SAML assertions or assertions containing encrypted data. The most appropriate means of achieving this will vary by profile, but may involve the use of authenticated TLS requests, or a requirement for an authenticated digital signature at a layer above that of the encrypted elements.

The ability to protect the encryption layer via a signature or TLS is limited by the fact that one typically does not have the ability to relate the asserting party's key to the cipher key. Thus, while one can limit exposure to only trusted asserting parties (via their key), it will often be the case that any trusted party's key will be accepted for the purposes of exploiting this issue.

Other countermeasures, such as attempting to mitigate timing attacks, or limiting reuse of encryption keys, tend to be impractical for most implementations and the use of integrity protection, when properly implemented, is the suggested solution if authenticated encryption modes are unavailable.

It is RECOMMENDED that the HTTP requests in this step be made over either SSL 3.0 [SSL3] or TLS 1.0 [RFC2246] to maintain confidentiality and message integrity. For the purposes of the profile, either the <Response> or the <Assertion> element(s) in the <Response> MUST be signed, if the HTTP POST binding is used, and MAY be signed if the HTTP-Artifact binding is used. If an <EncryptedAssertion> element is present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore]).

Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore]). Some deployments may require both the <Response> and any <Assertion> elements be signed to address both the encryption issue and non-repudiation of the assertion (the latter being outside the scope of SAML).

The <AuthnRequest> message SHOULD be signed. Per the rules specified by the browser SSO profile, the assertions enclosed in the <Response>, or the <Response> itself, MUST be signed. The delivery of the response in the SOAP envelope via PAOS is essentially analogous to the use of the HTTP POST binding and security countermeasures appropriate to that binding are used.

Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore]). Some deployments may require both the <Response> and any <Assertion> elements be signed to address both the encryption issue and non-repudiation of the assertion (the latter being outside the scope of SAML).

Note that if <EncryptedAssertion> elements are present and a CBC-mode algorithm is used, then the <Response> SHOULD be signed to ensure the ciphertext is integrity protected (see section 6.2 of [SAMLCore]). Some deployments may require both the <Response> and any <Assertion> elements be signed to address both the encryption issue and non-repudiation of the assertion (the latter being outside the scope of SAML).

See section 4.6 for additional considerations related to the use of XML Encryption.

4.6 XML Encryption Considerations

The XML Encryption specification [XMLEnc] includes important information for implementers and deployers that should be reviewed in conjunction with the use of the specification. In addition, take note that subsequent to the publication of the original 1.0 specification, vunerabilities have been found with some of the algorithms defined as mandatory to implement and that are in common usage [Enc2011], [RFC3218].

For example, the use of PKCS 1.5 as a Key Transport algorithm is subject to attacks that require mitigation by implementations The use of RSA-OAEP as an alternative algorithm is recommended as a replacement, regardless of the type or size of symmetric key.

In addition, the use of CBC mode algorithms for data encryption have been found vulnerable to attacks when used without a surrounding layer of integrity protection. Mitigating these attacks is difficult and in some cases impractical, and it is strongly advised that data encrypted with these algorithms only be processed with integrity protection in place. The use of TLS or XML Signature is often used for this purpose. Alternatively, implementations may be able to migrate to newer algorithms that include integrity protection as a feature, such as Galois/Counter Mode [800-38D].

Implementers are encouraged to review all of the available literature to fully understand these issues.

Optional attribute indicates the maximum length of time a consumer should cache the metadata contained in the element and any contained elements before attempting to refresh it.

Document caching MUST be based on the duration indicated by the cacheDuration attribute of the subject element(s). If metadata elements have parent elements which contain caching policies, the parent element takes precedence. To properly process the cacheDuration attribute, consumers must retain the date and time when an instance was obtained.

Note that cache expiration does not imply a lack of validity in the absence of a validUntil attribute or other information; failure to update a cached instance (e.g., due to network failure) need not render metadata invalid, although implementations may offer such controls to deployers.

4.3.2 Metadata Instance Validity

Metadata MUST be considered invalid upon reaching the time specified in a validUntil attribute of the subject element(s). The effective expiration may be adjusted downward by parent element(s) with earlier expirations. Invalid metadata MUST NOT be used. This contrasts with "stale" metadata that may be beyond its optimum cache duration but is not explicitly invalid. Such metadata remains valid and MAY be used at the discretion of the implementation.

3        Acknowledgments