This profile describes a set of rules for Identity Providers and Relying Parties to follow when using SAML V1.1 assertions as managed Information Card security tokens, so that interoperability and security is achieved commensurate with other SAML authentication profiles.

Status:

This document was last revised or approved by the Identity Metasystem Interoperability TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

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

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 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/imi/ipr.php).

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/imi/.

Notices

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.

Table of Contents

1 Introduction. 5

1.1 Notational Conventions. 5

1.2 Namespaces. 5

1.3 Normative References. 6

1.4 Non-Normative References. 7

2 SAML V1.1 Information Card Token Profile. 8

2.1 Required Information. 8

2.2 Profile Overview. 8

2.3 Identity Provider Requirements. 8

2.3.1 Token Types. 8

2.3.2 Identifying Token Issuers. 8

2.3.3 General Assertion Requirements. 9

2.3.4 Claim Type Encoding. 9

2.3.5 Proof Keys and Subject Confirmation. 9

2.3.6 Conditions. 10

2.3.7 Encryption. 10

2.4 Relying Party Requirements. 10

2.4.1 Token Types. 10

2.4.2 Identifying Token Issuers. 10

2.4.3 Identifying Relying Parties. 10

2.4.4 Identifying Claim Types. 11

2.4.5 Assertion Validity. 11

2.5 Security Considerations. 11

2.5.1 Unconstrained Bearer Assertions. 11

2.5.2 Encryption. 12

2.6 Examples. 12

3 Conformance. 14

A. Acknowledgements. 15

B. Revision History. 16

1 Introduction

OASIS has standardized a set of profiles for acquiring and delivering security tokens, collectively referred to as "Information Card" technology. These profiles are agnostic with respect to the format and semantics of a security token, but interoperability between Issuing and Relying Parties cannot be achieved without additional rules governing the creation and use of the tokens exchanged. This document describes a set of rules for the use of SAML V1.1 assertions, as defined in [SAMLCore], as security tokens within the Information Card architecture.

1.1 Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119].

This specification uses the following syntax to define outlines for assertions:

The syntax appears as an XML instance, but values in italics indicate data types instead of literal values.
Characters are appended to elements and attributes to indicate cardinality:

"?" (0 or 1)
"*" (0 or more)
"+" (1 or more)

The character "|" is used to indicate a choice between alternatives.
The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.
The characters "[" and "]" are used to call out references and property names.
Ellipses (i.e., "...") indicate points of extensibility. Additional children and/or attributes MAY be added at the indicated extension points but MUST NOT contradict the semantics of the parent and/or owner, respectively. By default, if a receiver does not recognize an extension, the receiver SHOULD ignore the extension; exceptions to this processing rule, if any, are clearly indicated below.
XML namespace prefixes (see Section 1.2) are used to indicate the namespace of the element being defined.

Elements and Attributes defined by this specification are referred to in the text of this document using XPath 1.0 expressions. Extensibility points are referred to using an extended version of this syntax:

An element extensibility point is referred to using {any} in place of the element name. This indicates that any element name can be used, from any namespace other than the namespace of this specification.
An attribute extensibility point is referred to using @{any} in place of the attribute name. This indicates that any attribute name can be used, from any namespace other than the namespace of this specification.

Extensibility points in the exemplar may not be described in the corresponding text.

This specification uses the following typographical conventions in text: <SAMLElement>, <ns:ForeignElement>, Attribute, Datatype, OtherCode.

1.2 Namespaces

This table lists the XML namespaces that are used in this document.

Prefix	XML Namespace	Specification(s)
ds	http://www.w3.org/2000/09/xmldsig#	XML Digital Signatures
ic	http://schemas.xmlsoap.org/ws/2005/05/identity	IMI 1.0
saml	urn:oasis:names:tc:SAML:1.0:assertion	SAML 1.0
sp	May refer to either http://schemas.xmlsoap.org/ws/2005/07/securitypolicy or http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 since both may be used	WS-SecurityPolicy 1.1 [WS-SecurityPolicy 1.1] or WS-SecurityPolicy 1.2 [WS-SecurityPolicy 1.2]
sp11	http://schemas.xmlsoap.org/ws/2005/07/securitypolicy	WS-SecurityPolicy 1.1 [WS-SecurityPolicy 1.1]
sp12	http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702	WS-SecurityPolicy 1.2 [WS-SecurityPolicy 1.2]
wsa	http://www.w3.org/2005/08/addressing	WS-Addressing [WS-Addressing]
wsp	http://schemas.xmlsoap.org/ws/2004/09/policy	WS-Policy [WS-Policy]
wst	May refer to any of http://schemas.xmlsoap.org/ws/2005/02/trust, http://docs.oasis-open.org/ws-sx/ws-trust/200512, or http://docs.oasis-open.org/ws-sx/ws-trust/200802, since all may be used	WS-Trust1.2 [WS-Trust 1.2], WS-Trust 1.3 [WS-Trust 1.3], or WS-Trust 1.4 [WS-Trust 1.4]

It should be noted that the versions identified in the above table supersede versions identified in referenced specifications.

1.3 Normative References

[IMI]

OASIS Standard, “Identity Metasystem Interoperability V1.0”, July 2009. http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.pdf

[RFC 2119]

S. Bradner, “RFC 2119: Key words for use in RFCs to Indicate Requirement Levels”, March 1997. http://www.ietf.org/rfc/rfc2119.txt

[SAMLCore]

OASIS Standard, “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V1.1”, September 2003. http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf

[WS-Addressing]

W3C Recommendation, “Web Service Addressing (WS-Addressing)”, 9 May 2006. http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/

[WS-Policy]

“Web Services Policy Framework (WS-Policy), Version 1.2”, March 2006. http://specs.xmlsoap.org/ws/2004/09/policy/ws-policy.pdf

[WS-SecurityPolicy 1.1]

“Web Services Security Policy Language (WS-SecurityPolicy), Version 1.1”, July 2005. http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf

[WS-SecurityPolicy 1.2]

OASIS Standard, “WS-SecurityPolicy 1.2”, July 2007. http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf

[WS-Trust 1.2]

“Web Services Trust Language (WS-Trust)”, February 2005. http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf

[WS-Trust 1.3]

OASIS Standard, “WS-Trust 1.3”, March 2007. http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf

[WS-Trust 1.4]

OASIS Standard, “WS-Trust 1.4”, February 2009. http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.pdf

1.4 Non-Normative References

[SAML2Sec]

OASIS Standard, “Security Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0”, March 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

[SAML2IMI]

OASIS Committee Draft, “SAML V2.0 Information Card Token Profile Version 1.0”, July 2010. http://docs.oasis-open.org/imi/identity/cd/imi-saml2.0-profile-cd-03.pdf

2 SAML V1.1 Information Card Token Profile

2.1 Required Information

Identification: http://docs.oasis-open.org/imi/ns/token/saml1_1/200912

Contact Information: imi-comment@lists.oasis-open.org

Description: Given below

Updates: None

2.2 Profile Overview

Identity Providers and Relying Parties employing the Identity Metasystem Interoperability [IMI] profile to request and exchange security tokens are able to use arbitrary token formats, provided there is agreement on the token's syntax and semantics, and a way to connect the token's content to the supported protocol features.

This profile provides a set of requirements and guidelines for the use of SAML V1.1 assertions as security tokens that, where possible, emulates existing SAML V1.1 token usage with Information Cards, so as to limit the amount of new work that must be done by existing software to support the use of Information Cards.

This profile does not seek to alter the required behavior of existing Identity Selector software, or conflict with the profile defined by [IMI].

2.3 Identity Provider Requirements

The Identity Provider functions as an Identity Provider/Security Token Service (IP/STS) and issues assertions in response to <wst:RequestSecurityToken> messages [WS-Trust12] or [WS-Trust13] or [WS-Trust14].

As defined by [IMI], the request contains information that provides input into the assertion creation process. The following sections outline requirements for interpreting this input and the resulting assertion content.

2.3.1 Token Types

Identity Providers SHOULD support all of the following token type strings in conjunction with this profile:

· http://docs.oasis-open.org/imi/ns/token/saml1_1/200912

· urn:oasis:names:tc:SAML:1.0:assertion

· http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

Information Cards issued by the Identity Provider SHOULD indicate support for the token types above.

2.3.2 Identifying Token Issuers

Information Cards produced by Identity Providers MUST contain the Identity Provider's unique name as the value of the <ic:Issuer> element. This name corresponds to the SAML concept of an “entityID” and may correspond to an actual entityID in the SAML sense of the term, or a logically equivalent name for the Identity Provider.

2.3.3 General Assertion Requirements

Assertions issued in accordance with this profile MUST contain a single <saml:AttributeStatement> that carries one or more <saml:Attribute> elements reflecting the claims requested by the Relying Party, in the manner specified by [IMI].

Claim type URIs are encoded using the AttributeNamespace and AttributeName attributes of a <saml:Attribute> statement in the manner described in Section 2.3.4. Claim values MUST be transmitted as the value of a <saml:AttributeValue> element.

A <saml:NameID> element SHOULD NOT be included in the assertion's <saml:Subject> element.

The assertion's <saml:Subject> element MUST contain at least one <saml:SubjectConfirmation> element, the details of which are defined in Section 2.3.5 below.

Finally, the assertion MUST be signed.

2.3.4 Claim Type Encoding

The Simple Identity Provider (SIP) Profile in Section 7 of the [IMI] specifies that its claims shall be encoded in SAML 1.1 tokens by breaking the claim type URL into two parts: the final component of the URL, which is encoded as the SAML 1.1 AttributeName, and all components before the final slash, which are encoded as the SAML 1.1 AttributeNamespace. Likewise, the claim type URI is constructed from a SAML 1.1 token by concatenating the AttributeNamespace + "/" + AttributeName. When encoding a claim type that is a URL containing a non-empty final component (that is distinct from the hostname portion of the URL), implementations SHOULD encode claim types using the SIP convention.

However, the SIP algorithm does not admit the possibility of claim types that are URIs but not URLS, such as those used by the Internet2 EduPerson schemas, for instance, “urn:mace:dir:attribute-def:givenName”. For claim types that are not URLs with a non-empty terminal component, implementations MAY encode claim names using a convention borrowed from SAML 2.0 to handle this case. In this alternate encoding, the AttributeNamespace value is set to “urn:oasis:names:tc:SAML:2.0:attrname-format:uri” and the AttributeName is set to the entire claim type URI. However, it should be noted that this convention is not widely implemented as of the date of this profile, and so maximum interoperability is likely to be achieved by either utilizing claim types that can be encoded using the SIP convention, or by using a different token type, such as SAML 2.0. (See [SAML2IMI] for the SAML 2.0 token profile.)

2.3.5 Proof Keys and Subject Confirmation

[IMI] defines three classes of "proof keys" that bind the issued token to key material controlled by the client: symmetric, asymmetric, and no key. The notion of a proof key maps directly to a <saml:SubjectConfirmation> element in the issued assertion.

Per [WS-Trust], if a token request does not include a <wst:KeyType> element, the Identity Provider SHOULD assume that a symmetric proof key is required.

Both symmetric and asymmetric proof key types generally correspond to the "holder-of-key" confirmation method. For the proof key types and algorithms specified by [IMI], the resulting assertion MUST contain a <saml:SubjectConfirmation> element with a Method of:

urn:oasis:names:tc:SAML:1.0:cm:holder-of-key

The accompanying <ds:KeyInfo> element MUST identify the proof key. In the case of an RSA asymmetric proof key, the key SHOULD be represented as a <ds:RSAKeyValue> element within a <ds:KeyValue> element.

Proof key algorithms defined outside of [IMI] MAY specify alternate <saml:SubjectConfirmation> content, if necessary.

The "no key" proof key type corresponds to the SAML "bearer" confirmation method. The resulting assertion MUST contain a <saml:SubjectConfirmation> element with a Method of:

urn:oasis:names:tc:SAML:1.0:cm:bearer

Other <saml:SubjectConfirmation> elements MAY be included at the discretion of the Identity Provider.

2.3.6 Conditions

Assertions MAY contain a <saml:Conditions> element with NotBefore and NotOnOrAfter attributes. This validity period can be independent of the window during which the client can present the assertion to a Relying Party as a security token, but of course must be a superset of that window.

If the request contains a <wsp:AppliesTo> element, then a <saml:AudienceRestriction> containing a <saml:Audience> element MUST be included with the value of that element.

Other conditions MAY be included at the discretion of the Identity Provider.

2.3.7 Encryption

If a suitable key belonging to the Relying Party is known, the Identity Provider SHOULD encrypt the resulting assertion.

If a public key belonging to the Relying Party is communicated to the Identity Provider in the <wst:RequestSecurityToken> request message in the <wsp:AppliesTo> element, this key SHOULD be used in preference to any other key known to the Identity Provider through others means.

2.4 Relying Party Requirements

A Relying Party uses the mechanisms defined by [IMI] to request security tokens in the form of SAML 1.1 assertions issued by particular or arbitrary Identity Providers. The following sections outline requirements for describing a Relying Party's needs based on this profile.

2.4.1 Token Types

Relying Parties SHOULD use the following token type string when requesting a token in conjunction with this profile:

· http://docs.oasis-open.org/imi/ns/token/saml1_1/200912

This string appears in various content produced by a Relying Party, such as (but not limited to) the <wst:TokenType> element.

For backward compatibility, Relying Parties MAY alternatively use the following token type strings:

· urn:oasis:names:tc:SAML:1.0:assertion

· http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

When using the legacy token types, Relying Parties should be aware that the resulting assertions may or may not conform to this profile. If such a guarantee is required, the newer token type SHOULD be used instead.

2.4.2 Identifying Token Issuers

When identifying a requirement for a specific token issuer, the Relying Party SHOULD use the Identity Provider's unique name (i.e., its “entityID”) either as the value of the <sp:Issuer>/<wsa:Address> element in its security policy or as the value of the issuer OBJECT tag parameter.

2.4.3 Identifying Relying Parties

If the Relying Party provides security policy metadata (see Section 3.1 of [IMI]), it MAY include a <wsp:AppliesTo> element inside a <sp:RequestSecurityTokenTemplate> element that refers to its own unique name (i.e., its "entityID") in the <wsa:Address> element.

If it does include a <wsp:AppliesTo> element, it MAY identify itself using a logical name, rather than using the location of its endpoint.

2.4.4 Identifying Claim Types

Implementations MUST accept claim types encoded using the conventions in the Simple Identity Provider (SIP) profile. In this case, the claim type URI is the concatenation of the AttributeNamespace value, a slash (“/”), and the AttributeName.

Implementations MAY accept claim types encoded using the convention where the AttributeNameSpace is “urn:oasis:names:tc:SAML:2.0:attrname-format:uri”. In this case, the claim type is the value of the AttributeName attribute.

Finally, for backwards compatibility, implementations MAY also accept claim types encoded using the convention where the AttributeNameSpace is “urn:mace:shibboleth:1.0:attributeNamespace:uri”. As in the previous case, the claim type is the value of the AttributeName attribute.

2.4.5 Assertion Validity

Relying Parties SHOULD evaluate assertions using the rules defined by [SAMLCore]. Invalid assertions SHOULD NOT be used to authenticate clients that present them.

In assessing validity, a Relying Party MUST verify the signature over the assertion, evaluate any conditions present, and successfully evaluate at least one <saml:SubjectConfirmation> element in the assertion based on the presentation of the assertion.

In the case of the "holder-of-key" method, the Relying Party MUST establish proof of possession by the client of the key identified by the accompanying <ds:KeyInfo> element, such as through the use of a message signature or authentication over a secure transport. The exact means are out of scope of this profile.

In the case of the "bearer" method, the Relying Party SHOULD ensure that assertions are not replayed, by maintaining the set of used ID values for the length of time for which the assertion would be considered valid based on the NotOnOrAfter attribute in the <saml:Conditions> element.

2.5 Security Considerations

2.5.1 Unconstrained Bearer Assertions

The Information Card model's support for hiding the identity of the Relying Party from the Identity Provider, combined with constraints on the implementation of the model for use with web browsers, leads to requests for "unconstrained" bearer assertions with no audience or subject confirmation conditions on use. While all uses of bearer assertions are subject to certain threats and attacks (see [SAML2Sec]), the lack of conditions on such assertions introduces additional serious threats to consider.

Ordinarily, the threat of a stolen assertion is mitigated by the fact that it can only be used to authenticate to a particular Relying Party. Without conditions on use, an attacker that successfully steals such an assertion has many more targets of opportunity. Essentially, the ability to mount an attack against a user's interactions with any single Relying Party become effective against all parties that are willing to accept such an assertion. Consider that some low value services may choose to forgo the use of TLS/SSL, leaving the assertions issued for their use much more vulnerable to theft. A successful attacker can then impersonate the intended user even with Relying Parties that choose to deploy such protection, rendering their investment moot.

Perhaps more seriously, Relying Parties that choose to accept such assertions are in turn empowered with the opportunity to impersonate the user for the duration of the subject confirmation window with any other like-minded Relying Parties. This threat looms larger when one considers that a compromised Relying Party could expose all its users to this risk if an attacker can tap the flow of incoming assertions. With traditional constraints in place, this threat is mitigated by the fact that a compromise, while potentially exposing user data, does not extend beyond the scope of access to the affected Relying Party.

Note that one of the only mitigating mechanisms to these threats are to enforce restrictions on use of assertions based on an IP address placed into the assertion by the Identity Provider. While moderately effective, this practice often proves impractical for services offered to large user populations, many of whom are likely to encounter proxies and network configurations that result in inability to satisfy the restriction.

As a result, this profile recommends against the use of unconstrained bearer assertions as a general matter, and urges implementations to provide deployers with the ability to control this behavior. The privacy advantages of such a model need to be carefully weighed against the risks to users and Relying Parties.

2.5.2 Encryption

Identity Providers should generally make every attempt to encrypt the assertions they produce if a key for the Relying Party can be established. If encryption is not used, then the Identity Provider should be aware of the potential for exposure of the assertion's contents, both to the requester and potentially to network observers if TLS/SSL is not used (particularly between the requester and the eventual Relying Party).

Caution, however, should be exercised in relying solely on the TLS/SSL certificate found at a Relying Party's endpoint to identify the key. In particular, the key has to be authenticated in order to ensure that it actually belongs to the eventual endpoint used by the client. Furthermore, there can be no guarantee that the software responsible for decrypting the security token will have access to the corresponding private key.

2.6 Examples

Following is an example of a signed SAML 1.1 Security Token containing two claims:

<saml:Assertion MajorVersion="1" MinorVersion="1"

AssertionID="_6d784c94-50fb-490a-9ca2-697d9c10ea95"

Issuer=

"http://ruchibserver7-2.redmond.corp.microsoft.com/adfs/services/trust"

IssueInstant="2009-12-15T00:39:52.118Z"

xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

<saml:Conditions NotBefore="2009-12-15T00:39:52.026Z"

NotOnOrAfter="2009-12-15T01:39:52.026Z">

<saml:AudienceRestrictionCondition>

<saml:Audience>

https://infocard.ntdev.corp.microsoft.com/site/SubmitCard.htm

</saml:Audience>

</saml:AudienceRestrictionCondition>

</saml:Conditions>

<saml:AttributeStatement>

<saml:Subject>

<saml:SubjectConfirmation>

<saml:ConfirmationMethod>

urn:oasis:names:tc:SAML:1.0:cm:bearer

</saml:ConfirmationMethod>

</saml:SubjectConfirmation>

</saml:Subject>

<saml:Attribute AttributeName="givenname" AttributeNamespace=

"http://schemas.xmlsoap.org/ws/2005/05/identity/claims">

<saml:AttributeValue>Jane</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName="surname" AttributeNamespace=

"http://schemas.xmlsoap.org/ws/2005/05/identity/claims">

<saml:AttributeValue>Doe</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

<saml:AuthenticationStatement

AuthenticationMethod="urn:federation:authentication:windows"

AuthenticationInstant="2009-12-15T00:39:52.023Z">

<saml:Subject>

<saml:SubjectConfirmation>

<saml:ConfirmationMethod>

urn:oasis:names:tc:SAML:1.0:cm:bearer

</saml:ConfirmationMethod>

</saml:SubjectConfirmation>

</saml:Subject>

</saml:AuthenticationStatement>

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

<ds:SignatureMethod

Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />

<ds:Reference URI="#_6d784c94-50fb-490a-9ca2-697d9c10ea95">

<ds:Transforms>

<ds:Transform

Algorithm=

"http://www.w3.org/2000/09/xmldsig#enveloped-signature" />

<ds:Transform

Algorithm=

"http://www.w3.org/2001/10/xml-exc-c14n#" />

</ds:Transforms>

<ds:DigestMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />

<ds:DigestValue>

99uSAzkPUQFKVddfYrmY7fE8OkuKM3LExs0hfEMb9Ig=

</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>LOWVW7uvGkSf0c4c ... J9nQ==</ds:SignatureValue>

<X509Certificate>MIIDEDCCAfigAwIB ... TRQA=</X509Certificate>

</X509Data>

</KeyInfo>

</ds:Signature>

</saml:Assertion>

3 Conformance

An Identity Provider implementation conforms to this profile if it can produce assertions consistent with the normative text in Section 2.3.

A Relying Party implementation conforms to this profile if it can accept assertions consistent with the normative text of Section 2.4.

A. Acknowledgements

The editors would like to acknowledge the contributions of the OASIS Identity Metasystem Interoperability Technical Committee, whose voting members at the time of publication were:

Participants:

John Bradley, Individual

Scott Cantor, Internet2

Marc Goodner, Microsoft (Chair)

Michael B. Jones, Microsoft (Editor)

Dale Olds, Novell

Anthony Nadalin, Microsoft (Chair)

Drummond Reed, Cordance

B. Revision History

Revision	Date	Editor	Changes Made
cd-02	7 July 2010	Michael B. Jones	Committee draft for promotion to committee specification.
ed-04	10 June 2010	Michael B. Jones	Incorporate feedback from public review. Changes made are non-normative. They keep the references between the SAML 1.1 and SAML 2.0 profiles in sync.
cd-01	31 March 2010	Michael B. Jones	Committee draft for public review.
ed-03	2 February 2010	Michael B. Jones	Typographic corrections.
ed-02	1 February 2010	Michael B. Jones	Resolved IMI-28 per committee decision by making the saml:Audience required when a wsp:AppliesTo element is present.
ed-01	15 December 2009	Michael B. Jones	Created editor’s draft from input documents. This specification addresses issue IMI-23.