Specification URIs:

This Version:

http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.html

http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.doc (Authoritative)

http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.pdf

Previous Version:

http://docs.oasis-open.org/imi/identity/v1.0/cs/identity-1.0-spec-cs-01.html

http://docs.oasis-open.org/imi/identity/v1.0/cs/identity-1.0-spec-cs-01.doc (Authoritative)

http://docs.oasis-open.org/imi/identity/v1.0/cs/identity-1.0-spec-cs-01.pdf

Latest Version:

http://docs.oasis-open.org/imi/identity/v1.0/identity.html

http://docs.oasis-open.org/imi/identity/v1.0/identity.doc

http://docs.oasis-open.org/imi/identity/v1.0/identity.pdf

Technical Committee:

OASIS Identity Metasystem Interoperability (IMI) TC

Chair(s):

Marc Goodner

Anthony Nadalin

Editor(s):

Michael B. Jones

Michael McIntosh

Related work:

This specification replaces or supersedes:

·         None

This specification is related to:

·         WS-Trust

·         WS-SecurityPolicy

·         WS-Addressing

Declared XML Namespace(s):

http://docs.oasis-open.org/imi/ns/identity-200810

http://schemas.xmlsoap.org/ws/2005/05/identity

http://schemas.xmlsoap.org/ws/2006/02/addressingidentity

http://schemas.xmlsoap.org/ws/2007/01/identity

Abstract:

This document is intended for developers and architects who wish to design identity systems and applications that interoperate using the Identity Metasystem Interoperability specification.

An Identity Selector and the associated identity system components allow users to manage their Digital Identities from different Identity Providers, and employ them in various contexts to access online services.  In this specification, identities are represented to users as “Information Cards”.  Information Cards can be used both at applications hosted on Web sites accessed through Web browsers and rich client applications directly employing Web services.

This specification also provides a related mechanism to describe security-verifiable identity for endpoints by leveraging extensibility of the WS-Addressing specification.  This is achieved via XML [XML 1.0] elements for identity provided as part of WS-Addressing Endpoint References.  This mechanism enables messaging systems to support multiple trust models across networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.

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

Copyright © OASIS® 2008-2009. All Rights Reserved.

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 names "OASIS",  are trademarks 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.

1        Introduction. 7

1.1 Notational Conventions. 7

1.2 Namespaces. 7

1.3 Schema. 9

1.4 Terminology. 9

1.5 Normative References. 10

1.6 Non-Normative References. 12

2        Relying Party Interactions. 13

2.1 Expressing Token Requirements of Relying Party. 13

2.1.1 Issuer of Tokens. 13

2.1.2 Type of Proof Key in Issued Tokens. 14

2.1.3 Claims in Issued Tokens. 14

2.2 Expressing Privacy Policy of Relying Party. 15

2.3 Employing Relying Party STSs. 17

3        Identity Provider Interactions. 17

3.1 Information Card. 17

3.1.1 Information Card Format 17

3.1.2 Issuing Information Cards. 25

3.2 Identity Provider Policy. 27

3.2.1 Require Information Card Provisioning. 27

3.2.2 Policy Metadata Location. 27

3.3 Token Request and Response. 27

3.3.1 Information Card Reference. 28

3.3.2 Claims and Other Token Parameters. 28

3.3.3 Token Scope. 28

3.3.4 Client Pseudonym.. 29

3.3.5 Proof Key for Issued Token. 30

3.3.6 Display Token. 35

3.3.7 Token References. 36

4        Authenticating to Identity Provider 36

4.1 Username and Password Credential 37

4.2 Kerberos v5 Credential 37

4.3 X.509v3 Certificate Credential 37

4.4 Self-issued Token Credential 38

5        Faults. 38

5.1 Relying Party. 39

5.2 Identity Provider 39

5.2.1 Identity Provider Custom Error Messages. 40

6        Information Cards Transfer Format 41

6.1 Pre-Encryption Transfer Format 41

6.1.1 PIN Protected Card. 43

6.1.2 Computing the ic:IssuerId. 44

6.1.3 Computing the ic:IssuerName. 45

6.1.4 Creating the ic:HashSalt 45

6.2 Post-Encryption Transfer Format 45

7        Simple Identity Provider Profile. 47

7.1 Self-Issued Information Card. 47

7.2 Self-Issued Token Characteristics. 47

7.3 Self-Issued Token Encryption. 51

7.4 Self-Issued Token Signing Key. 52

7.4.1 Processing Rules. 53

7.5 Claim Types. 55

7.5.1 First Name. 55

7.5.2 Last Name. 55

7.5.3 Email Address. 55

7.5.4 Street Address. 55

7.5.5 Locality Name or City. 55

7.5.6 State or Province. 56

7.5.7 Postal Code. 56

7.5.8 Country. 56

7.5.9 Primary or Home Telephone Number 56

7.5.10 Secondary or Work Telephone Number 56

7.5.11 Mobile Telephone Number 56

7.5.12 Date of Birth. 57

7.5.13 Gender 57

7.5.14 Private Personal Identifier 57

7.5.15 Web Page. 57

7.6 The PPID Claim.. 57

7.6.1 Relying Party Identifier and Relying Party PPID Seed. 58

7.6.2 PPID.. 60

7.6.3 Friendly Identifier 60

8        Relying Parties without Certificates. 61

8.1 Relying Party Identifier and Relying Party PPID Seed. 61

8.2 AppliesTo Information. 61

8.3 Token Signing and Encryption. 62

9        Using WS-SecurityPolicy 1.2 and WS-Trust 1.3. 62

9.1 Overview of Differences. 62

9.2 Identity Selector Differences. 62

9.3 Security Token Service Differences. 63

10      Browser Behavior with Information Cards. 64

10.1 Basic Protocol Flow when using an Information Card at a Web Site. 64

10.2 Protocol Flow with Relying Party STS. 65

10.3 User Perspective and Examples. 66

10.4 Browser Perspective. 67

10.5 Web Site Perspective. 67

11      Invoking an Identity Selector from a Web Page. 68

11.1 Syntax Alternatives:  OBJECT and XHTML tags. 68

11.1.1 OBJECT Syntax Examples. 68

11.1.2 XHTML Syntax Example. 69

11.2 Identity Selector Invocation Parameters. 70

11.2.1 issuer 70

11.2.2 issuerPolicy. 70

11.2.3 tokenType. 70

11.2.4 requiredClaims. 70

11.2.5 optionalClaims. 70

11.2.6 privacyUrl 70

11.2.7 privacyVersion. 70

11.3 Data Types for Use with Scripting. 70

11.4 Detecting and Utilizing an Information Card-enabled Browser 71

11.5 Behavior within Frames. 71

11.6 Invocation Using the Document Object Model (DOM) 71

11.7 Auditing, Non-Auditing, and Auditing-Optional Cards. 71

12      Endpoint Reference wsai:Identity Property. 72

12.1 Default Value. 72

12.2 Identity Representation. 72

12.2.1 DNS Name. 72

12.2.2 Service Principal Name. 72

12.2.3 User Principal Name. 72

12.2.4 KeyInfo. 73

12.2.5 Security Token. 73

12.2.6 Security Token Reference. 74

13      Security Considerations. 75

13.1 Protection of Information Cards by Identity Selectors. 75

13.2 Relying Parties Without Certificates. 75

13.3 Endpoint References. 75

14      Conformance. 76

A.      HTTPS POST Sample Contents. 77

B.      Acknowledgements. 80

 

The Identity Metasystem Interoperability specification prescribes a subset of the mechanisms defined in [WS-Trust 1.2], [WS-Trust 1.3], [WS-SecurityPolicy 1.1], [WS-SecurityPolicy 1.2], and [WS-MetadataExchange] to facilitate the integration of Digital Identity into an interoperable token issuance and consumption framework using the Information Card Model.  It documents the Web interfaces utilized by browsers and Web applications that utilize the Information Card Model.  Finally, it extends WS-Addressing’s endpoint reference by providing identity information about the endpoint that can be verified through a variety of security means, such as https or the wealth of WS-Security specifications.

This profile constrains the schema elements/extensions used by the Information Card Model, and behaviors for conforming Relying Parties, Identity Providers, and Identity Selectors.

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 Table 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 might not be described in the corresponding text.

1.2 Namespaces

Table 1 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	This document
ic07	http://schemas.xmlsoap.org/ws/2007/01/identity	Namespace for additional elements also defined by this document
ic08	http://docs.oasis-open.org/imi/ns/identity-200810	Namespace for new elements defined by this document
S	May refer to either http://schemas.xmlsoap.org/soap/envelope or http://www.w3.org/2003/05/soap-envelope since both may be used	SOAP
S11	http://schemas.xmlsoap.org/soap/envelope	SOAP 1.1 [SOAP 1.1]
S12	http://www.w3.org/2003/05/soap-envelope	SOAP 1.2 [SOAP 1.2]
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
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]
wsai	http://schemas.xmlsoap.org/ws/2006/02/addressingidentity	Addressing Identity extension for WS-Addressing also defined by this document
wsdl	May refer to either http://schemas.xmlsoap.org/wsdl/ or http://www.w3.org/TR/wsdl20 since both may be used	Web Services Description Language
wsdl11	http://schemas.xmlsoap.org/wsdl/	Web Services Description Language [WSDL 1.1]
wsdl20	http://www.w3.org/TR/wsdl20	Web Services Description Language [WSDL 2.0]
wsp	http://schemas.xmlsoap.org/ws/2004/09/policy	WS-Policy [WS-Policy]
wsse	http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd	WS-Security Extensions [WS-Security]
wst	May refer to either http://schemas.xmlsoap.org/ws/2005/02/trust or http://docs.oasis-open.org/ws-sx/ws-trust/200512 since both may be used	WS-Trust
wst12	http://schemas.xmlsoap.org/ws/2005/02/trust	WS-Trust 1.2 [WS-Trust 1.2]
wst13	http://docs.oasis-open.org/ws-sx/ws-trust/200512	WS-Trust 1.3 [WS-Trust 1.3]
wsu	http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd	WS-SecurityUtility
wsx	http://schemas.xmlsoap.org/ws/2004/09/mex	WS-MetadataExchange [WS-MetadataExchange]
xs	http://www.w3.org/2001/XMLSchema	XML Schema [Part 1, 2]

Note that the versions identified in the above table supersede versions identified in referenced specifications.

1.3 Schema

A copy of the XML Schemas for this document can be found at:

1.4 Terminology

The following definitions establish the terminology and usage in this document.

Information Card Model – The “Information Card Model” refers to the use of Information Cards containing metadata for obtaining Digital Identity claims from Identity Providers and then conveying them to Relying Parties under user control.

Information Card – An Information Card provides a visual representation of a Digital Identity for the end user.  Information Cards contain a reference to an IP/STS that issues Security Tokens containing the Claims for that Digital Identity.

Digital Identity – A “Digital Identity” is a set of Claims made by one party about another party.

Claim – A “Claim” is a piece of information about a Subject that an Identity Provider asserts about that Subject.

Subject – A “Subject” is an individual or entity about whom claims are made by an Identity Provider.

Service Requester – The term “Service Requester” means software acting on behalf of a party who wants to obtain a service through a digital network.

Relying Party – The term “Relying Party” (RP) means a network entity providing the desired service, and relying upon Digital Identity.

Identity Provider – The term “Identity Provider” (IP) means a network entity providing the Digital Identity claims used by a Relying Party.

Security Token Service – The term “Security Token Service” (STS) refers to a WS-Trust endpoint.

Identity Provider Security Token Service – The term “Identity Provider Security Token Service” (IP/STS) refers to the Security Token Service run by an Identity Provider to issue tokens.

Relying Party Security Token Service – The term “Relying Party Security Token Service” (RP/STS) refers to a Security Token Service run by a Relying Party to accept and issue tokens.

Identity Selector – The term “Identity Selector” (IS) refers to a software component available to the Service Requester through which the user controls and dispatches her Digital Identities.

Trust Identity – A trust identity is a verifiable claim about a principal (e.g. name, identity, key, group, privilege, capability, etc).

Security Token – A security token represents a collection of claims.

Signed Security Token – A signed security token is a security token that is asserted and cryptographically endorsed by a specific authority (e.g. an X.509 certificate, a Kerberos ticket, or a self-issued Information Card).

Unsigned Security Token – An unsigned security token is a security token that is not cryptographically endorsed by a specific authority (e.g. a security token backed by shared secrets such as usernames and passwords).

Proof-of-Possession – The proof-of-possession information is data that is used in a proof process to demonstrate the sender's knowledge of information that should only be known to the claiming sender of a security token.

Integrity – Integrity is the process by which it is guaranteed that information is not modified in transit.

Confidentiality – Confidentiality is the process by which data is protected such that only authorized actors or security token owners can view the data

Digest – A digest is a cryptographic checksum of an octet stream.

Signature - A signature is a cryptographic binding of a proof-of-possession and a digest.  This covers both symmetric key-based and public key-based signatures.  Consequently, non-repudiation is not always achieved.

Certificate – Uses of the term certificate in this specification refer to X.509 certificates unless otherwise qualified. Usage of certificates is dictated by the underlying protocols, e.g. HTTPS or WS-Security, except where noted.

1.5 Normative References

[DOM]

“Document Object Model (DOM)”, November 2000.  http://www.w3.org/DOM/

[EV Cert]

CA / Browser Forum, “Guidelines for the Issuance and Management of Extended Validation Certificates, Version 1.1”, April 2008.  http://cabforum.org/EV_Certificate_Guidelines_V11.pdf

[HTTP]

R. Fielding et al., “IETF RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1”, June 1999.  http://www.ietf.org/rfc/rfc2616.txt

[HTTPS]

E. Rescorla, “RFC 2818: HTTP over TLS”, May 2000.  http://www.ietf.org/rfc/rfc2818.txt

[RFC 1274]

P. Barker and S. Kille, “RFC 1274: The COSINE and Internet X.500 Schema”, November 1991.  http://www.ietf.org/rfc/rfc1274.txt

[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

[RFC 2256]

M. Wahl, “RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3”, December 1997.  http://www.ietf.org/rfc/rfc2256.txt

[RFC 2459]

R. Housley, W. Ford, W. Polk, and D. Solo, “RFC 2459: Internet X.509 Public Key Infrastructure - Certificate and CRL Profile”, January 1999.  http://www.ietf.org/rfc/rfc2459.txt

[RFC 2898]

B. Kaliski, “PKCS #5: Password-Based Cryptography Specification, Version 2.0”, September 2000.  http://www.ietf.org/rfc/rfc2898.txt

[RFC 3066]

H. Alvestrand, “Tags for the Identification of Languages”, January 2001.  http://www.faqs.org/rfcs/rfc3066.html

[SOAP 1.1]

W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000.  http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

[SOAP 1.2]

M. Gudgin, et al., “SOAP Version 1.2 Part 1: Messaging Framework”, June 2003.  http://www.w3.org/TR/soap12-part1/

[URI]

T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.  http://www.ietf.org/rfc/rfc2396.txt

[WS-Addressing]

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

[WS-MetadataExchange]

“Web Services Metadata Exchange (WS-MetadataExchange), Version 1.1”, August 2006.  http://specs.xmlsoap.org/ws/2004/09/mex/WS-MetadataExchange.pdf

[WSDL 1.1]

W3C Note, "Web Services Description Language (WSDL 1.1)," 15 March 2001.  http://www.w3.org/TR/wsdl

 [WSDL 2.0]

“Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language”, June 2007.  http://www.w3.org/TR/wsdl20

[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-Security]

A. Nadalin et al., “Web Services Security: SOAP Message Security 1.0”, May 2004.  http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.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, “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, “WS-Trust 1.3”, March 2007.  http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf

[XML 1.0]

W3C Recommendation, “Extensible Markup Language (XML) 1.0 (Fourth Edition)”, September 2006.  http://www.w3.org/TR/xml/

[XMLDSIG]

Eastlake III, D., Reagle, J., and Solo, D., “XML-Signature Syntax and Processing”, March 2002.  http://www.ietf.org/rfc/rfc3275.txt

[XMLENC]

Imamura, T., Dillaway, B., and Simon, E., “XML Encryption Syntax and Processing”, August 2002.  http://www.w3.org/TR/xmlenc-core/

[XML Schema, Part 1]

H. Thompson et al., “XML Schema Part 1: Structures”, May 2001.  http://www.w3.org/TR/xmlschema-1/

[XML Schema, Part 2]

P. Biron et al., “XML Schema Part 2: Datatypes”, May 2001.  http://www.w3.org/TR/xmlschema-2/

1.6 Non-Normative References

[Addressing-Ext]

J. Alexander et al., “Application Note: Web Services Addressing Endpoint References and Identity”, July 2008.  http://schemas.xmlsoap.org/ws/2006/02/addressingidentity

[ISIP]

A. Nanda and M. Jones, “Identity Selector Interoperability Profile V1.5”, July 2008.  http://www.microsoft.com/downloads/details.aspx?FamilyID=b94817fc-3991-4dd0-8e85-b73e626f6764&DisplayLang=en

[ISIP Guide]

Microsoft Corporation and Ping Identity Corporation, “An Implementer’s Guide to the Identity Selector Interoperability Profile V1.5”, July 2008.  http://www.microsoft.com/downloads/details.aspx?FamilyID=b94817fc-3991-4dd0-8e85-b73e626f6764&DisplayLang=en

[ISIP Web Guide]

M. Jones, “A Guide to Using the Identity Selector Interoperability Profile V1.5 within Web Applications and Browsers”, July 2008.  http://www.microsoft.com/downloads/details.aspx?FamilyID=b94817fc-3991-4dd0-8e85-b73e626f6764&DisplayLang=en

This section defines the constructs used by a Relying Party Web service for specifying and conveying its Security Token requirements to the Service Requester.

2.1 Expressing Token Requirements of Relying Party

A Relying Party specifies its Security Token requirements as part of its Security Policy using the primitives and assertions defined in WS-SecurityPolicy. The primary construct in the Security Policy of the Relying Party used to specify its requirement for a Security Token from an Identity Provider is the sp:IssuedToken policy assertion. The basic form of the issued token policy assertion as defined in WS-SecurityPolicy is as follows.

The attributes and elements listed in the schema fragment above are described in WS-SecurityPolicy.

The ensuing subsections describe special parameters added by this profile as extensions to the sp:IssuedToken policy assertion that convey additional instructions to the Identity Selector available to the Service Requester.

2.1.1 Issuer of Tokens

The sp:IssuedToken/sp:Issuer element in an issued token policy specifies the issuer for the requested token. More specifically, it SHOULD contain the endpoint reference of an Identity Provider STS that can issue the requested token.

A Relying Party MUST specify the issuer for a requested token in one of the following ways:

§  Indicate a specific issuer by specifying the issuer’s endpoint as the value of the sp:Issuer/wsa:Address element.

§  Indicate that the issuer is unspecified by omitting the sp:Issuer element, which means that the Service Requester should determine the appropriate issuer for the requested token with help from the user if necessary.

When requiring a specific issuer, a Relying Party MAY specify that it will accept self-issued Security Tokens by using the special URI below as the value of the wsa:Address element within the endpoint reference for the issuer.

URI:

Following is an example of using this URI within an issued token policy.

Example:

A Relying Party MAY specify the value of the sp:Issuer/wsa:Address element in policy as a “logical name” of the token issuer instead of an actual network address where the token is issued. An Identity Selector SHOULD resolve the logical name to an appropriate endpoint for the token issuer by matching the issuer name in Information Cards available to it.

If a Relying Party specifies the token issuer as a network endpoint in policy, then it MUST also specify the location of issuer metadata from where the issuer’s policy metadata can be obtained. This is done using the mechanism defined in [WS-Addressing] for embedding metadata within an endpoint reference. The following example shows a token policy where the issuer endpoint and its corresponding metadata location are specified.

Example:

2.1.2 Type of Proof Key in Issued Tokens

If no explicit key type is specified by the Relying Party, then an Identity Selector SHOULD request an asymmetric key token from the Identity Provider to maximize user privacy and security.

A Relying Party MAY explicitly request the use of an asymmetric or symmetric key in the requested token by using the wst:KeyType element within its issued token policy assertion. The key type URIs are defined in [WS-Trust]. The following example illustrates the use of this element in the Relying Party’s Security Policy to request a symmetric key in the issued token.

Example:

2.1.3 Claims in Issued Tokens

The claims requirement of a Relying Party can be expressed in its token policy by using the optional wst:Claims parameter defined in [WS-Trust 1.2] and [WS-Trust 1.3]. However, the wst:Claims parameter has an open content model. This profile defines the ic:ClaimType element for use as a child of the wst:Claims element. A Relying Party MAY use this element to specify an individual claim type requested. Further, each requested claim MAY be specified as being required or optional. Multiple ic:ClaimType elements can be included to specify multiple claim types requested.

The outline for the ic:ClaimType element is as follows:

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

/ic:ClaimType

Indicates the requested claim type.

/ic:ClaimType/@Uri

The unique identifier of the requested claim type.

/ic:ClaimType/@Optional

Indicates if the claim can be absent in the Security Token. By default, any requested claim type is a required claim and MUST be present in the issued Security Token.

Two <ic:ClaimType> elements refer to the same claim type if and only if the values of their XML attribute named Uri are equal in a case-sensitive string comparison.

When the ic:ClaimType element is used within the wst:Claims parameter in a token policy to specify claims requirement, the wst:Dialect attribute on the wst:Claims element MUST be qualified with the URI value below.

Dialect URI:

The above dialect URI value indicates that the specified claim elements are to be processed according to this profile.

Following is an example of using this assertion within an issued token policy to require two claim types where one claim type is optional.

Example:

This profile also defines a standard set of claim types for common personal information about users that may be requested by Relying Party Web services in Security Tokens and supported by any Identity Provider. These standard claim types are defined in Section 7.5.

2.2 Expressing Privacy Policy of Relying Party

A Relying Party Web service SHOULD publish its “Privacy Policy”.  Users might decide to release tokens and interact further with that service based on its Privacy Policy. No assumptions are made regarding the format and content of the Privacy Policy and an Identity Selector is NOT REQUIRED to parse, interpret or act on the Privacy Policy programmatically.

To express the location of its privacy statement, a Web service MUST use the optional policy assertion ic:PrivacyNotice defined below:

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

/ic:PrivacyNotice

This element is used to express the location of the privacy statement of a Web service.

/ic:PrivacyNotice/@Version

This optional attribute provides a version number for the privacy statement allowing changes in its content to be reflected as a change in the version number. If present, it MUST have a minimum value of 1.

Following is an example of using this policy element to express the location of the privacy statement of a Web service.

Example:

An Identity Selector MUST be able to accept a privacy statement location specified as an URL using the [HTTP] scheme (as illustrated above) or the [HTTPS] scheme.

Because the Privacy Policy assertion points to a “privacy statement” that applies to a service endpoint, the assertion MUST apply to [Endpoint Policy Subject]. In other words, a policy expression containing the Privacy Policy assertion MUST be attached to a wsdl:binding in the metadata for the service.

Further, when an Identity Selector can only render the privacy statement document in a limited number of document formats (media types), it MAY use the HTTP request-header field “Accept” in its HTTP GET request to specify the media-types it can accept. For example, the following request-header specifies that the client will accept the Privacy Policy only as a plain text or a HTML document.

Similarly, if an Identity Selector wants to obtain the privacy statement in a specific language, it MAY use the HTTP request-header field “Accept-Language” in its HTTP GET request to specify the languages it is willing to accept. For example, the following request-header specifies that the client will accept the Privacy Policy only in Danish.

A Web service, however, is NOT REQUIRED to be able to fulfill the document format and language requests of an Identity Selector. It MAY publish its privacy statement in a fixed set of document formats and languages.

2.3 Employing Relying Party STSs

The Security Policy of a Relying Party MAY require that an issued token be obtained from a Relying Party STS.  This can create a chain of STSs.  The Identity Selector MUST follow the RP/STS chain, contacting each referenced STS, resolving its Policy statements and continuing to the STS it refers to.

When following a chain of STSs, when an STS with an ic:RequireFederatedIdentityProvisioning declaration is encountered as per Section 3.2.1, this informs the Identity Selector that the STS is an IP/STS and therefore ends the STS chain, rather than a member of the RP/STS chain.  Furthermore, if an RP or RP/STS provides an incomplete Security Policy, such as no issuer or no required claims, the Identity Selector MUST be invoked so a card and requested claims can be selected by the user, enabling a Request for Security Token (RST) to be constructed and sent to the selected IP/STS.

The RP/STS’s Policy is used for card matching. If the RP/STS requests a private personal identifier (PPID) claim (see Section 7.5.14), the RP/STS’s certificate is used for calculating PPID, Signing Key, and Client Pseudonym (see Section 3.3.4) values – not the certificate of the Relying Party. This enables a single RP/STS to service multiple Relying Parties while always receiving the same PPID value for a given user from the Identity Selector.

Identity Selectors MUST enable users to make Relying Party trust decisions based on the identity of the Relying Party, possibly including displaying attributes from its certificate.  By trusting the RP, the user is implicitly trusting the chain of RP/STSs that the RP employs.

Each RP/STS endpoint MUST provide a certificate.  This certificate MAY be communicated either via Transport (such as HTTPS) or Message (such as WS-Security) Security.  If Message Security is employed, transports not providing security (such as HTTP) MAY be used.

Like IP/STSs, RP/STSs publish endpoint metadata.  This metadata MAY be retrieved via either WS-MetadataExchange or HTTPS GET in the same manner that IP/STS metadata can be, as described in Section 3.1.1.2.

Like IP/STSs, no changes to the syntax used to specify metadata locations occurs when RP/STS metadata is published by the Relying Party STS as a page retrievable using HTTPS GET.  Relying Parties and Identity Providers MAY consequently support either or both retrieval methods for the same metadata addresses.

3      Identity Provider Interactions

This section defines the constructs used by an Identity Selector for interacting with an Identity Provider to obtain Information Cards, and to request and obtain Security Tokens.

3.1 Information Card

An Information Card represents a Digital Identity of a Subject that can be issued by an Identity Provider. It is an artifact containing metadata that represents the token issuance relationship between an Identity Provider and a Subject, and provides a visual representation of the Digital Identity. Multiple Digital Identities for a Subject from the same Identity Provider are represented by different Information Cards. Subjects may obtain an Information Card from an Identity Provider, and may have a collection of Information Cards from various Identity Providers.

3.1.1 Information Card Format

An Information Card is represented as a signed XML document that is issued by an Identity Provider. The XML schema for an Information Card is defined below:

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

/ic:InformationCard

An Information Card issued by an Identity Provider.

/ic:InformationCard/@xml:lang

A required language identifier, using the language codes specified in [RFC 3066], in which the content of localizable elements have been localized.

/ic:InformationCard/ic:InformationCardReference

This required element provides a specific reference for the Information Card by which it can be uniquely identified within the scope of an issuer. This reference MUST be included by an Identity Selector in all token requests sent to the Identity Provider based on that Information Card. The detailed schema of this element is defined in Section 3.1.1.1.

/ic:InformationCard/ic:CardName

This optional  element provides a friendly textual name for the issued Information Card. The content of this element MAY be localized in a specific language.

/ic:InformationCard/ic:CardImage

This optional element contains a base64 encoded inline image that provides a graphical image for the issued Information Card. It SHOULD contain an image within the size range of 60 pixels wide by 40 pixels high and 240 pixels wide by 160 pixels high.  It is RECOMMENDED that the image have an aspect ratio of 3:2 and the image size be 120 by 80 pixels.

/ic:InformationCard/ic:CardImage/@MimeType

This required attribute provides a MIME type specifying the format of the included card image. This value MUST be one of the five image formats:  image/jpeg, image/gif, image/bmp, image/png, or image/tiff.

/ic:InformationCard/ic:Issuer

This required element provides a logical name for the issuer of the Information Card. If a Relying Party specifies a token issuer by its logical name, then the content of this element MUST be used to match the requested token issuer with an Information Card.

/ic:InformationCard/ic:TimeIssued

This required element provides the date and time when the Information Card was issued.

/ic:InformationCard/ic:TimeExpires

This optional element provides the date and time after which the Information Card SHOULD be treated as expired and invalid.

/ic:InformationCard/ic:TokenServiceList

This required element provides an ordered list of Security Token Service (IP/STS) endpoints, and corresponding credential descriptors (implying the REQUIRED authentication mechanisms), where tokens can be requested. Each service endpoint MUST be tried in order by the Service Requester when requesting tokens.

/ic:InformationCard/ic:SupportedTokenTypeList

This optional element contains the list of token types that are offered by the Identity Provider.

/ic:InformationCard/ic:SupportedClaimTypeList

This optional element contains the list of claim types that are offered by the Identity Provider.

/ic:InformationCard/ic:RequireAppliesTo

This optional element indicates that token requests MUST include information identifying the Relying Party where the issued token will be used. The Relying Party information MUST be included as the content of a wsp:AppliesTo element in the token request.

/ic:InformationCard/ic:PrivacyNotice

This optional element provides the location of the privacy statement of the Identity Provider.

/ic:InformationCard/ic07:RequireStrongRecipientIdentity

This optional element informs the Identity Selector that it MUST only allow the card to be used at a Relying Party that presents a cryptographically protected identity, for example, an X.509v3 certificate.

/ic:InformationCard/ic07:IssuerInformation

This optional element provides information from the card issuer about the card that can be displayed by the Identity Selector user interface.

.../ic:InformationCard/@{any}

This is an extensibility point to allow additional attributes to be specified.  While an Identity Selector MAY ignore any extensions it does not recognize it SHOULD preserve those that it does not recognize and emit them in the respective ic:InformationCard element of an ic:RoamingStore when representing the card in the Information Cards Transfer Format in Section 6.1.

.../ic:InformationCard/{any}

This is an extensibility point to allow additional metadata elements to be specified.  While an Identity Selector MAY ignore any extensions it does not recognize it SHOULD preserve those that it does not recognize and emit them in the respective ic:InformationCard element of an ic:RoamingStore when representing the card in the Information Cards Transfer Format in Section 6.1.

3.1.1.1 Information Card Reference

Every Information Card issued by an Identity Provider MUST have a unique reference by which it can be identified within the scope of the Identity Provider. This reference is included in all token requests sent to the Identity Provider based on that Information Card.

The card reference MUST be expressed using the following schema element within an Information Card.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:InformationCardReference

A specific reference for an Information Card.

.../ic:InformationCardReference/ic:CardId

This required element provides a unique identifier in the form of a URI for the specific Information Card. The identifier provider MUST be able to identify the specific Information Card based on this identifier.

.../ic:InformationCardReference/ic:CardVersion

This required element provides a versioning epoch for the Information Card issuance infrastructure used by the Identity Provider. The minimum value for this field MUST be 1. Note that it is possible to include version information in CardId as it is a URI, and can have hierarchical content.  However, it is specified as a separate value to allow the Identity Provider to change its issuance infrastructure, and thus its versioning epoch, independently without changing the CardId of all issued Information Cards. For example, when an Identity Provider makes a change to the supported claim types or any other policy pertaining to the issued cards, the version number allows the Identity Provider to determine if the Information Card needs to be refreshed. The version number is assumed to be monotonically increasing. If two Information Cards have the same CardId value but different CardVersion values, then the one with a higher numerical CardVersion value SHOULD be treated as being more up-to-date.

3.1.1.2 Token Service Endpoints and Authentication Mechanisms

Every Information Card issued by an Identity Provider MUST include an ordered list of IP/STS endpoints, and the corresponding credential type to be used, for requesting tokens. The list MUST be in a decreasing order of preference.  Identity Selectors SHOULD attempt to use the endpoints in the order listed, using the first endpoint in the list for which the metadata is retrievable and the endpoint is reachable.  For each endpoint, the credential type implicitly determines the authentication mechanism to be used. Each credential descriptor is personalized for the user to allow an Identity Selector to automatically locate the credential once the user has selected an Information Card.

Further, each IP/STS endpoint reference in the Information Card MUST include the Security Policy metadata for that endpoint. The policy metadata MAY be specified as a metadata location within the IP/STS endpoint reference. If a metadata location URL is specified, it MUST use the [HTTPS] transport. An Identity Selector MAY retrieve the Security Policy it will use to communicate with the IP/STS from that metadata location using the mechanism specified in [WS-MetadataExchange].

The ordered list of token service endpoints MUST be expressed using the following schema element within an Information Card.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:TokenServiceList

This required element provides an ordered list of Security Token Service endpoints (in decreasing order of preference), and the corresponding credential types, for requesting tokens. Each service endpoint MUST be tried in order by a Service Requester.

.../ic:TokenServiceList/ic:TokenService

This required element describes a single token issuing endpoint.

.../ic:TokenServiceList/ic:TokenService/wsa:EndpointReference

This required element provides the endpoint reference for a single token issuing endpoint. For the Self-issued Identity Provider, the special address value defined in Section 2.1.1 MAY be used. The wsai:Identity extension element (see Section 12) for endpoint references MAY be used to include the protection token for this endpoint to secure communications with it.

.../ic:TokenServiceList/ic:TokenService/ic:UserCredential

This required element indicates the credential type to use to authenticate to the token issuing endpoint.

.../ic:TokenServiceList/ic:TokenService/ic:UserCredential/ic:DisplayCredentialHint

This optional element provides a hint (string) to be displayed to the user to prompt for the correct credential (e.g. a hint to insert the right smart card). The content of this element MAY be localized in a specific language.

.../ic:TokenServiceList/ic:TokenService/ic:UserCredential/<credential descriptor>

This required element provides an unambiguous descriptor for the credential to use for authenticating to the token issuing endpoint. The schema to describe the credential is specific to each credential type. This profile defines the schema elements ic:UsernamePasswordCredential, ic:KerberosV5Credential, ic:X509V3Credential or ic:SelfIssuedCredential later in Section 4 corresponding to username/password, Kerberos v5, X.509v3 certificate and self-issued token based credential types. Other credential types MAY be introduced via the extensibility point defined in the schema within this element.

Alternatively, Identity Providers MAY publish metadata for Information Cards as WSDL documents that can be retrieved by Identity Selectors via HTTPS GET operations on URLs using the HTTPS scheme.  An endpoint’s metadata URL is communicated to Identity Selectors in a token service wsx:MetadataReference element in an Information Card using exactly the same syntax as when WS-MetadataExchange is employed to retrieve the metadata.  No change occurs in the card.

The metadata documents published via HTTPS GET SHOULD contain the WSDL for the endpoint as the top-level element of the document without any SOAP or WS-MetadataExchange elements enclosing it.

Identity Providers MAY publish endpoint metadata via both the HTTPS GET and WS-MetadataExchange methods at the same metadata location.  If they publish the metadata via multiple mechanisms, the metadata delivered via both mechanisms SHOULD be the same.  Likewise, Identity Selectors MAY attempt to retrieve metadata via multiple mechanisms, either in sequence or in parallel.

The following example illustrates an Identity Provider with two endpoints for its IP/STS, one requiring Kerberos (higher priority) and the other requiring username/password (lower priority) as its authentication mechanism. Further, each endpoint also includes its policy metadata location as a URL using the [HTTPS] scheme.

Example:

3.1.1.3 Token Types Offered

Every Information Card issued by an Identity Provider SHOULD include an unordered list of token types that can be issued by the Identity Provider. The set of token types offered by the Identity Provider MUST be expressed using the following schema element within an Information Card.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:SupportedTokenTypeList

This optional element contains the set of token types offered by the Identity Provider.

.../ic:SupportedTokenTypeList/wst:TokenType

This required element indicates an individual token type that is offered.

The following example illustrates an Identity Provider that offers both SAML 1.1 and SAML 2.0 tokens.

Example:

3.1.1.4 Claim Types Offered

Every Information Card issued by an Identity Provider SHOULD include an unordered list of claim types that can be issued by the Identity Provider. The set of claim types offered by the Identity Provider MUST be expressed using the following schema element within an Information Card.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:SupportedClaimTypeList

This  optional element contains the set of claim types offered by the Identity Provider.

.../ic:SupportedClaimTypeList/ic:SupportedClaimType

This required element indicates an individual claim type that is offered.

.../ic:SupportedClaimTypeList/ic:SupportedClaimType/@Uri

This required attribute provides the unique identifier (URI) of this individual claim type offered.

.../ic:SupportedClaimTypeList/ic:SupportedClaimType/ic:DisplayTag

This optional element provides a friendly name for this individual claim type. The content of this element MAY be localized in a specific language.

.../ic:SupportedClaimTypeList/ic:SupportedClaimType/ic:Description

This optional element provides a description of the semantics for this individual claim type. The content of this element MAY be localized in a specific language.

The following example illustrates an Identity Provider that offers two claim types.

Example:

3.1.1.5 Requiring Token Scope Information

An Identity Selector, by default, SHOULD NOT convey information about the Relying Party where an issued token will be used (i.e., target scope) when requesting Security Tokens. This helps safeguard user privacy. However, an Identity Provider MAY override that behavior.

Every Information Card issued by an Identity Provider MAY include a requirement that token requests include token scope information identifying the Relying Party where the token will be used. The requirement to submit token scope information MUST be expressed using the following schema element within an Information Card.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:RequireAppliesTo

This optional element indicates a requirement for a token requester to submit token scope information in the request. Absence of this element in an Information Card means that the token requester MUST NOT submit any token scope information.

.../ic:RequireAppliesTo/@Optional                                                             

This optional attribute indicates whether the token scope information is required or is optional by the Identity Provider. An attribute value of “true” indicates that the token scope information is not required, but will be accepted by the Identity Provider if submitted. An attribute value of “false” (default) indicates that the token scope information is required.

The following example illustrates the use of this element.

Example:                                                                                                                

If token scope information is required by an Identity Provider, an Identity Selector MUST include the Relying Party identity as the content of the wsp:AppliesTo element in the token request. The actual behavior of an Identity Selector vis-à-vis the possible requirements that can be expressed by the above element is specified in Section 3.3.3.

3.1.1.6 Privacy Policy Location

Every Information Card issued by an Identity Provider SHOULD include a pointer to the privacy statement of the Identity Provider. The location of the privacy statement MUST be expressed using the following schema element within an Information Card.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:PrivacyNotice

This optional element provides the location of the privacy statement of the Identity Provider.

.../ic:PrivacyNotice/@Version

This optional attribute indicates a version number that tracks changes in the content of the privacy statement. This field MUST have a minimum value of 1 when present.

The following example illustrates the use of this element.

Example:

An Identity Selector MUST be able to accept a privacy statement location specified as an URL using the [HTTP] scheme (as illustrated above) or the [HTTPS] scheme.

3.1.1.7 Prohibiting Use at Relying Parties Not Identified by a Cryptographically Protected Identity

Information Cards issuers MAY specify that a card MUST NOT be used at Relying Parties that do not present a cryptographically protected identity, such as an X.509v3 certificate.  This would typically be done when the issuer determines that the use of HTTP without Message Security would not provide a sufficiently secure environment for the use of the card.

Syntax:

.../ic07:RequireStrongRecipientIdentity

This optional element informs the Identity Selector that it MUST only allow the card to be used at a Relying Party that presents a cryptographically protected identity, such as an X.509v3 certificate.

3.1.1.8 Providing Custom Data to Display with the Card

Card issuers MAY supply a set of information about the card that MAY be displayed by the Identity Selector user interface.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic07:IssuerInformation

This optional element provides a set of information from the card issuer about the card that can be displayed by the Identity Selector user interface.

.../ic07:IssuerInformation/IssuerInformationEntry

This required element provides one item of information about the card.

.../ic07:IssuerInformation/IssuerInformationEntry/EntryName

This required element provides the name of one item of information about the card.

.../ic07:IssuerInformation/IssuerInformationEntry/EntryValue

This required element provides the value of one item of information about the card.

The following example illustrates the use of this feature.

Example:

3.1.2 Issuing Information Cards

An Identity Provider can issue Information Cards to its users using any out-of-band mechanism that is mutually suitable.

In order to provide the assurance that an Information Card is indeed issued by the Identity Provider expected by the user, the Information Card MUST be carried inside a digitally signed envelope that is signed by the Identity Provider. For this, the “enveloping signature” construct (see [XMLDSIG]) MUST be used where the Information Card is included in the ds:Object element. The signature on the digitally signed envelope provides data origin authentication assuring the user that it came from the right Identity Provider.

The specific profile of XML digital signatures [XMLDSIG] that is RECOMMENDED for signing the envelope carrying the Information Card is as follows.  Usage of other algorithms is not described.

·         Use enveloping signature format when signing the Information Card XML document.

·         Use a single ds:Object element within the signature to hold the ic:InformationCard element that represents the issued Information Card. The ds:Object/@Id attribute provides a convenient way for referencing the Information Card from the ds:SignedInfo/ds:Reference element within the signature.

·         Use RSA signing and verification with the algorithm identifier given by the URI http://www.w3.org/2000/09/xmldsig#rsa-sha1.

·         Use exclusive canonicalization with the algorithm identifier given by the URI http://www.w3.org/2001/10/xml-exc-c14n#.

·         Use SHA1 digest method for the data elements being signed with the algorithm identifier http://www.w3.org/2000/09/xmldsig#sha1.

·         There MUST NOT be any other transforms used in the enveloping signature for the Information Card other than the ones listed above.

·         The ds:KeyInfo element MUST be present in the signature carrying the signing key information in the form of an X.509 v3 certificate or a X.509 v3 certificate chain specified as one or more ds:X509Certificate elements within a ds:X509Data element.

The following example shows an enveloping signature carrying an Information Card that is signed by the Identity Provider using the format outlined above. Note that whitespace (newline and space character) is included in the example only to improve readability; they might not be present in an actual implementation.

Example:

An Identity Selector MUST verify the enveloping signature. The ic:InformationCard element can then be extracted and stored in the Information Card collection.

3.2 Identity Provider Policy

This section specifies additional policy elements and requirements introduced by this profile for an IP/STS policy metadata.

3.2.1 Require Information Card Provisioning

In the Information Card Model, an Identity Provider requires provisioning in the form of an Information Card issued by it which represents the provisioned identity of the user. In order to enable an Identity Selector to learn that such pre-provisioning is necessary before token requests can be made, the Identity Provider MUST provide an indication in its policy.

An Identity Provider issuing Information Cards MUST specify this provisioning requirement in its policy using the following schema element.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:RequireFederatedIdentityProvisioning

This element indicates a requirement that one or more Information Cards, representing identities that can be federated, MUST be pre-provisioned before token requests can be made to the Identity Provider.

The following example illustrates the use of this policy element.

Example:

3.2.2 Policy Metadata Location

In the Information Card Model, an Identity Provider MUST make the Security Policy metadata for its IP/STS endpoints available. If a metadata location is used for this purpose, the location URL MUST use the [HTTPS] scheme. An Identity Selector MAY retrieve the Security Policy it will use to communicate with the IP/STS from that metadata location using the mechanism specified in [WS-MetadataExchange].

3.3 Token Request and Response

For any given Information Card, an Identity Selector can obtain a Security Token from the IP/STS for that Information Card. Tokens MUST be requested using the “Issuance Binding” mechanism described in [WS-Trust 1.2] and [WS-Trust 1.3]. This section specifies additional constraints and extensions to the token request and response messages between the Identity Selector and the IP/STS.

The WS-Trust protocol requires that a token request be submitted by using the wst:RequestSecurityToken element in the request message, and that a token response be sent using the wst:RequestSecurityTokenResponse element in the response message. This profile refers to the “Request Security Token” message as RST and the “Request Security Token Response” message as RSTR in short.

The WS-Trust protocol allows for a token response to provide multiple tokens by using the wst:RequestSecurityTokenResponseCollection element in the response message. This profile, however, requires that an Identity Provider MUST NOT use the wst:RequestSecurityTokenResponseCollection element in the response. The token response MUST consist of a single wst:RequestSecurityTokenResponse element.

3.3.1 Information Card Reference

When requesting a Security Token from the IP/STS, an Identity Selector MUST include the Information Card reference in the body of the RST message as a top-level element information item. The ic:InformationCardReference element in the Information Card, including all of its [children], [attributes] and [in-scope namespaces], MUST be copied as an immediate child of the RST element in the message as follows.

The following example illustrates the Information Card reference included in a RST message.

Example:

The IP/STS MAY fault with ic:InformationCardRefreshRequired to signal to the Service Requester that the Information Card needs to be refreshed.

3.3.2 Claims and Other Token Parameters

A Relying Party’s requirements of claims and other token parameters are expressed in its policy using the sp:RequestSecurityTokenTemplate parameter within the sp:IssuedToken policy assertion (see Section 2.1). If all token parameters are acceptable to the Identity Selector, it MUST copy the content of this element (i.e. all of its [children] elements) into the body of the RST message as top-level element information items.  However, if optional claims are requested by the Relying Party, requests for optional claims not selected by the user MUST NOT be copied into the RST message.

3.3.3 Token Scope

The WS-Trust protocol allows a token requester to indicate the target where the issued token will be used (i.e., token scope) by using the optional  element wsp:AppliesTo in the RST message. By default, an Identity Selector SHOULD NOT send token scope information to the Identity Provider in token requests to protect user privacy. In other words, the element wsp:AppliesTo is absent in the RST message.

However, if the Identity Provider requires it (see the modes of the ic:RequireAppliesTo element described in Section 3.1.1.5), or if the Relying Party’s token policy includes the wsp:AppliesTo element in the sp:RequestSecurityTokenTemplate parameter, then an Identity Selector MUST include token scope information in its token request as per the behavior summarized in the following table.

<RequireAppliesTo> mode in Information Card	<AppliesTo> element present in RP policy	Resulting behavior of Identity Selector
Mandatory	Yes	Send <AppliesTo> value from RP policy in token request to IP.
Mandatory	No	Send the RP endpoint to which token will be sent as the value of <AppliesTo> in token request to IP.
Optional	Yes	Send <AppliesTo> value from RP policy in token request to IP.
Optional	No	Do not send <AppliesTo> in token request to IP.
Not present	Yes	Fail
Not present	No	Do not send <AppliesTo> in token request to IP.

The following example illustrates the token scope information included in a RST message when it is sent to the Identity Provider.

Example:

3.3.4 Client Pseudonym

A private personal identifier (PPID) claim, defined in Section 7.5.14, identifies a Subject to a Relying Party in a way such that a Subject’s PPID at one Relying Party cannot be correlated with the Subject’s PPID at another Relying Party.  If an Identity Provider offers the PPID claim type then it MUST generate values for the claim that have this prescribed privacy characteristic using data present in the RST request.

When a Relying Party requests a PPID claim, an Identity Selector MUST provide a Client Pseudonym value via an ic:PPID element in the RST request that can be used by the IP/STS as input when computing the PPID claim value in the issued token.  The Client Pseudonym SHOULD be produced as described in Section 3.3.4.1.  It is RECOMMENDED that the IP/STS combine this Client Pseudonym value with information specific to the entity to which the card was issued as well as a secret known only by the IP/STS and pass the combination through a cryptographically non-invertible function, such as a cryptographic hash function, to generate the PPID claim value sent in the token.  Alternatively, when target scope information is sent in the token request using the wsp:AppliesTo element, the IP/STS MAY instead choose to use that information to generate an appropriate PPID value.

When Client Pseudonym information is included by an Identity Selector in a token request, it MUST be sent using the following schema element.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:ClientPseudonym                   

This optional  top-level element contains the Client Pseudonym information item.

.../ic:ClientPseudonym/ic:PPID

This optional element contains the Client Pseudonym value that the client has submitted for use in computing the PPID claim value for the issued token. The IP/STS MAY use this value as the input (a seed) to a custom cryptographically non-invertible function, with the result used as the PPID claim value in the issued token.

The following example illustrates the Client Pseudonym information sent in a RST message.

Example:

When the target scope information is not sent in the token request to an IP/STS, the Identity Provider MUST NOT record any Client Pseudonym values included in the RST message. It likewise MUST NOT record the PPID claim value that it generates.

3.3.4.1 PPID

When a token request for a PPID claim is sent to an IP/STS, an Identity Selector SHOULD compute the Client Pseudonym PPID information it sends in the RST message as follows:

·         Construct the RP PPID Seed as described in Section 7.6.1.

·         Decode the base64 encoded value of the ic:HashSalt element of the Information Card (see Section 6.1) to obtain SaltBytes.

·         Decode the base64 encoded value of the ic:MasterKey element of the Information Card (see Section 6.1) to obtain MasterKeyBytes.

·         Hash the concatenation of MasterKeyBytes, RP PPID Seed, and SaltBytes using the SHA256 hash function to obtain the Client Pseudonym PPID value.

Client Pseudonym PPID = SHA256 (MasterKeyBytes + RP PPID Seed + SaltBytes)

·         Convert Client Pseudonym PPID to a base64 encoded string and send as the value of the ic:PPID element in the RST request.

3.3.5 Proof Key for Issued Token

An issued token can have a symmetric proof key (symmetric key token), an asymmetric proof key (asymmetric key token), or no proof key (bearer token). If no key type is specified in the Relying Party policy, then an Identity Selector SHOULD request an asymmetric key token from the IP/STS by default.

The optional  wst:KeyType element in the RST request indicates the type of proof key desired in the issued Security Token. The IP/STS MAY return the proof key and/or entropy towards the proof key in the RSTR response. This section describes the behaviors for how each proof key type is requested, who contributes entropy, and how the proof key is computed and returned.

3.3.5.1 Symmetric Proof Key

When requesting a symmetric key token, an Identity Selector MUST submit entropy towards the proof key by augmenting the RST request message as follows:

·         The RST SHOULD include a wst:KeyType element with one of the two following URI values, depending upon the version of WS-Trust being used:

http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey

http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey

·         The RST MUST include a wst:BinarySecret element inside a wst:Entropy element containing client-side entropy to be used as partial key material. The entropy is conveyed as raw base64 encoded bits.

The size of the submitted entropy SHOULD be equal to the key size requested in the Relying Party policy. If no key size is specified by the Relying Party, then an Identity Selector SHOULD request a key at least 256-bits in size, and submit an entropy of equal size to the IP/STS.

Following is a sample RST request fragment that illustrates a symmetric key token request.

Example:

When processing the token request, the IP/STS MAY:

a)     accept the client entropy as the sole key material for the proof key,

b)    accept the client entropy as partial key material and contribute additional server-side entropy as partial key material to compute the proof key as a function of both partial key materials, or

c)     reject the client-side entropy and use server-side entropy as the sole key material for the proof key.

For each of the cases above, the IP/STS MUST compute and return the proof key by augmenting the RSTR response message as follows.

For case (a) where IP/STS accepts client entropy as the sole key material:

·         The RSTR MUST NOT include a wst:RequestedProofToken element. The proof key is implied and an Identity Selector MUST use the client-side entropy as the proof key.

For case (b) where IP/STS accepts client entropy and contributes additional server entropy:

·         The RSTR MUST include a wst:BinarySecret element inside a wst:Entropy element containing the server-side entropy to be used as partial key material. The entropy is conveyed as raw base64 encoded bits.

·         The partial key material from the IP/STS MUST be combined (by each party) with the partial key material from the client to determine the resulting proof key.

·         The RSTR MUST include a wst:RequestedProofToken element containing a wst:ComputedKey element to indicate how the proof key is to be computed. It is RECOMMENDED that an Identity Selector support the P_SHA1 computed key mechanism defined in [WS-Trust 1.2] or [WS-Trust 1.3] with the particulars below.  Usage of other algorithms is not described.

ComputedKey Value	Meaning
http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1 or http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1	The key is computed using P_SHA1 from the TLS specification to generate a bit stream using entropy from both sides.  The exact form is:    key = P_SHA1 (EntropyREQ, EntropyRES)

Following is a sample RSTR response fragment that illustrates a token response with partial key material from the IP/STS and a computed proof key.

Example:

For case (c) where IP/STS contributes server entropy as the sole key material:

·         The RSTR MUST include a wst:BinarySecret element inside a wst:RequestedProofToken element containing the specific proof key to be used. The proof key is conveyed as raw base64 encoded bits.

Following is a sample RSTR response fragment that illustrates a token response with fully specified proof key from the IP/STS.

Example:

The following table summarizes the symmetric proof key computation rules to be used by an Identity Selector:

3.3.5.2 Asymmetric Proof Key

When requesting an asymmetric key token, it is RECOMMENDED that an Identity Selector generate an ephemeral RSA key pair.  Usage of other algorithms is not described.  The generated RSA key pair MUST be at least 1024-bits in size for use as the proof key. It MUST submit the public key to the IP/STS by augmenting the RST request as follows:

·         The RST MUST include a wst:KeyType element with one of the two following URI values, depending upon the version of WS-Trust being used:

http://schemas.xmlsoap.org/ws/2005/02/trust/PublicKey

http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey

·         The RST SOAP body MUST include a wst:UseKey element containing the public key to be used as proof key in the returned token. The public key is present as a raw RSA key in the form of a ds:RSAKeyValue element inside a ds:KeyValue element.

·         The RST SOAP security header SHOULD include a supporting signature to prove ownership of the corresponding private key. The ds:KeyInfo element within the signature, if present, MUST include the same public key as in the wst:UseKey element in the SOAP body.

·         The supporting signature, if present, MUST be placed in the SOAP security header where the signature for an endorsing supporting token would be placed as per the security header layout specified in WS-SecurityPolicy.

Following is a sample RST request fragment that illustrates an asymmetric key based token request containing the public key and proof of ownership of the corresponding private key.

Example:

If a supporting signature for the submitted proof key is not present in the token request, the IP/STS MAY fail the request. If a supporting signature is present, the IP/STS MUST verify the signature and MUST ensure that the public key included in the wst:UseKey element and in the supporting signature are the same. If verification succeeds and the IP/STS accepts the submitted public key for use in the issued token, then the token response MUST NOT include a wst:RequestedProofToken element. The proof key is implied and an Identity Selector MUST use the public key it submitted as the proof key.

The following table summarizes the asymmetric proof key rules used by an Identity Selector:

3.3.5.3 No Proof Key

When requesting a token with no proof key, an Identity Selector MUST augment the RST request message as follows:

·         The RST MUST include a wst:KeyType element with the following URI value if [WS-Trust 1.2] is being used:

http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey

or the RST MUST include a wst:KeyType element with the following URI value if [WS-Trust 1.3] is being used:

http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer

Following is a sample RST request fragment that illustrates a bearer token request.

Example:

When processing the token request, if the IP/STS issues a SAML v1.1 bearer token then:

·         It MUST specify “urn:oasis:names:tc:SAML:1.0:cm:bearer” as the subject confirmation method in the token.

·         It SHOULD include a saml:AudienceRestrictionCondition element restricting the token to the target site URL submitted in the token request.

3.3.6 Display Token

An Identity Selector MAY request a Display Token – a representation of the claims carried in the issued Security Token that can be displayed in an user interface – from an IP/STS as part of the token request. To request a Display Token, the following element MUST be included in the RST message as a top-level element information item.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

/ic:RequestDisplayToken

This optional element is used to request an Identity Provider to return a Display Token corresponding to the issued token.

/ic:RequestDisplayToken/@xml:lang

This optional attribute indicates a language identifier, using the language codes specified in [RFC 3066], in which the Display Token content SHOULD be localized.

An IP/STS MAY respond to a Display Token request. If it does, it MUST use the following element to return a Display Token for the issued Security Token in the RSTR message.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

/ic:RequestedDisplayToken

This optional element is used to return a Display Token for the Security Token returned in the response.

/ic:RequestedDisplayToken/ic:DisplayToken

The returned Display Token.

/ic:RequestedDisplayToken/ic:DisplayToken/@xml:lang

This required attribute indicates a language identifier, using the language codes specified in [RFC 3066], in which the Display Token content is localized.

/ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim

This required element indicates an individual claim returned in the Security Token.

/ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim/@Uri

This required attribute provides the unique identifier (URI) of the individual claim returned in the Security Token.

/ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim/ic:DisplayTag

This optional element provides a friendly name for the claim returned in the Security Token.

/ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim/ic:Description

This optional element provides a description of the semantics for the claim returned in the Security Token.

/ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayClaim/ic:DisplayValue

This optional element provides the displayable value for the claim returned in the Security Token.

/ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayTokenText

This optional element provides an alternative textual representation of the entire token as a whole when the token content is not suitable for display as individual claims.

/ic:RequestedDisplayToken/ic:DisplayToken/ic:DisplayTokenText/@MimeType

This required attribute provides a MIME type specifying the format of the Display Token content (e.g., “text/plain”).

The following example illustrates a returned Display Token corresponding to a Security Token with two claims.

Example:

3.3.7 Token References

When an IP/STS returns the token requested by an Identity Selector, it MUST also include an attached and an un-attached token reference for the issued security token using the wst:RequestedAttachedReference and wst:RequestedUnattachedReference elements, respectively, in the RSTR response message.

An Identity Selector is truly a conduit for the security tokens issued by an IP/STS and requested by an RP, and it should remain agnostic of the type of the security token passing through it. Furthermore, a security token issued by an IP/STS MAY be encrypted directly for the RP, thus preventing visibility into the token by the Identity Selector. However, an Identity Selector (or a client application) needs to be able to use the issued security token to perform security operations (such as signature or encryption) on a message sent to an RP and thus needs a way to reference the token both when it is attached to a message and when it is not. The attached and unattached token references returned by an IP/STS in the RSTR message provide the necessary references that can be used for this purpose.

4      Authenticating to Identity Provider

The Information Card schema includes the element content necessary for an Identity Provider to express what credential the user must use in order to authenticate to the IP/STS when requesting tokens. This section defines the schema used to express the credential descriptor for each supported credential type.

4.1 Username and Password Credential

When the Identity Provider requires a username and password as the credential type, the following credential descriptor format MUST be used in the Information Card to specify the required credential.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:UsernamePasswordCredential

This element indicates that a username/password credential is needed.

.../ic:UsernamePasswordCredential/ic:Username

This optional  element provides the username part of the credential for convenience. An Identity Selector MUST prompt the user for the password. If the username is specified, then its value MUST be copied into the username token used to authenticate to the IP/STS; else an Identity Selector MUST prompt the user for the username as well.

Furthermore, the actual Security Policy of the IP/STS (expressed in its WSDL) MUST include the sp:UsernameToken assertion requiring a username and password value.

4.2 Kerberos v5 Credential

When the Identity Provider requires a Kerberos v5 service ticket for the IP/STS as the credential type, the following credential descriptor format MUST be used in the Information Card to specify the required credential.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:KerberosV5Credential

This element indicates that a Kerberos v5 credential is needed.

To enable the Service Requester to obtain a Kerberos v5 service ticket for the IP/STS, the endpoint reference of the IP/STS in the Information Card or in the metadata retrieved from it MUST include a “service principal name” identity claim (i.e. a wsai:Spn element) under the wsai:Identity tag as defined in Section 12.

Furthermore, the actual Security Policy of the IP/STS (expressed in its WSDL) MUST include the sp:KerberosToken assertion requiring a Kerberos service ticket.

4.3 X.509v3 Certificate Credential

When the Identity Provider requires an X.509 v3 certificate for the user as the credential type, where the certificate and keys are in a hardware-based smart card or a software-based certificate, the following credential descriptor format MUST be used in the Information Card to specify the required credential.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:DisplayCredentialHint

This optional  element provides a user hint string which can be used to prompt the user, for example, to insert the appropriate smart card into the reader.

.../ic:X509V3Credential

This element indicates that a X.509 certificate credential is needed.

.../ic:X509V3Credential/ds:X509Data/wsse:KeyIdentifier

This element provides a key identifier for the X.509 certificate based on the SHA1 hash of the entire certificate content expressed as a “thumbprint.” Note that the extensibility point in the ds:X509Data element is used to add wsse:KeyIdentifier as a child element.

Furthermore, the actual Security Policy of the IP/STS, expressed in its WSDL, MUST include the sp:X509Token assertion requiring an X.509v3 certificate.

4.4 Self-issued Token Credential

When the Identity Provider requires a self-issued token as the credential type, the following credential descriptor format MUST be used in the Information Card to specify the required credential.

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

.../ic:SelfIssuedCredential

This element indicates that a self-issued token credential is needed.

.../ic:SelfIssuedCredential/ic:PrivatePersonalIdentifier

This required element provides the value of the PPID claim asserted in the self-issued token used previously to register with the IP/STS (see Section 7.5.14).

Furthermore, the actual Security Policy of the IP/STS (expressed in its WSDL) MUST include the sp:IssuedToken assertion requiring a self-issued token with exactly one claim, namely, the PPID.

5      Faults

In addition to the standard faults described in WS-Addressing, WS-Security and WS-Trust, this profile defines the following additional faults that MAY occur when interacting with an RP or an IP. The binding of the fault properties (listed below) to a SOAP 1.1 or SOAP 1.2 fault message is described in [WS-Addressing]. If the optional [Detail] property for a fault includes any specified content, then the corresponding schema fragment is included in the listing below.

5.1 Relying Party

The following faults MAY occur when submitting Security Tokens to an RP per its Security Policy.

[action]	http://www.w3.org/2005/08/addressing/soap/fault
[Code]	S:Sender
[Subcode]	ic:RequiredClaimMissing
[Reason]	A required claim is missing from the Security Token.
[Detail]	[URI of missing claim] <ic:ClaimType Uri="[Claim URI]" />

 

[action]	http://www.w3.org/2005/08/addressing/soap/fault
[Code]	S:Sender
[Subcode]	ic:InvalidClaimValue
[Reason]	A claim value asserted in the Security Token is invalid.
[Detail]	[URI of invalid claim] <ic:ClaimType Uri="[Claim URI]" />

5.2 Identity Provider

The following faults MAY occur when requesting Security Tokens from an IP using Information Cards.

[action]	http://www.w3.org/2005/08/addressing/soap/fault
[Code]	S:Sender
[Subcode]	ic:MissingAppliesTo
[Reason]	The request is missing Relying Party identity information.
[Detail]	(None defined.)

 

[action]	http://www.w3.org/2005/08/addressing/soap/fault
[Code]	S:Sender
[Subcode]	ic:InvalidProofKey
[Reason]	Invalid proof key specified in request.
[Detail]	(None defined.)

 

[action]	http://www.w3.org/2005/08/addressing/soap/fault
[Code]	S:Sender
[Subcode]	ic:UnknownInformationCardReference
[Reason]	Unknown Information Card reference specified in request.
[Detail]	[Unknown Information Card reference] <ic:InformationCardReference>  <ic:CardId>[card ID]</ic:CardId>  <ic:CardVersion>[version]</ic:CardVersion> </ic:InformationCardReference>

 

[action]	http://www.w3.org/2005/08/addressing/soap/fault
[Code]	S:Sender
[Subcode]	ic:FailedRequiredClaims
[Reason]	Could not satisfy required claims in request; construction of token failed
[Detail]	[URIs of claims that could not be satisfied] <ic:ClaimType Uri="[Claim URI]" /> ...

 

[action]	http://www.w3.org/2005/08/addressing/soap/fault
[Code]	S:Sender
[Subcode]	ic:InformationCardRefreshRequired
[Reason]	Stale Information Card reference specified in request; Information Card SHOULD be refreshed
[Detail]	[Information Card reference that needs refreshing] <ic:InformationCardReference>  <ic:CardId>[card ID]</ic:CardId>  <ic:CardVersion>[version]</ic:CardVersion> </ic:InformationCardReference>

5.2.1 Identity Provider Custom Error Messages

Identity Providers MAY return custom error messages to Identity Selectors via SOAP faults that can be displayed by the Identity Selector user interface.  The error message MUST be communicated as an S:Text element within the S:Reason element of a SOAP fault message.  Multiple S:Text elements MAY be returned with different xml:lang values and the Identity Selector SHOULD use the one matching the user’s locale, if possible.

Example:

6      Information Cards Transfer Format

This section defines how collections of Information Cards are transferred between Identity Selectors. The cards collection is always transferred after encrypting it with a key derived from a user specified password. Section 6.1 describes the transfer format of the collection in the clear, whereas Section 6.1.2 describes the transfer format after the necessary encryption is applied.

6.1 Pre-Encryption Transfer Format

Each Information Card in the transfer stream will contain metadata and key material maintained by the originating Identity Selector in addition to the original Information Card metadata.  If an Identity Selector includes a co-resident Self-issued Identity Provider (described in Section 7), an exported self-issued card MAY also contain any associated claims information.

The XML schema used for the transfer format is defined below:

Syntax:

The following describes the attributes and elements listed in the schema outlined above:

/ic:RoamingStore

The collection of Information Cards selected for transfer.

/ic:RoamingStore/ic:RoamingInformationCard (one or more)

An individual Information Card within the transfer stream.

For brevity, the prefix string “/ic:RoamingStore/ic:RoamingInformationCard” in the element names below is shortened to “...”.

.../ic:InformationCardMetaData

This required element contains the metadata for an Information Card.

.../ic:InformationCardMetaData/[Information Card]

The original content of the Information Card as issued by the Identity Provider (described in Section 3.1.1).

.../ic:InformationCardMetaData/ic:IsSelfIssued

This required element indicates if the card is self-issued (“true”) or not (“false”).

.../ic:InformationCardMetaData/ic:PinDigest

This optional  element contains a digest of the user-specified PIN information if the card is PIN-protected. The digest contains the base64 encoded bytes of the SHA1 hash of the bytes of the user-specified PIN represented using Unicode encoding UTF-16LE with no byte order mark.  Usage of other algorithms is not described.

.../ic:InformationCardMetaData/ic:HashSalt

This optional element contains a random per-card entropy value used for computing the Relying Party specific PPID claim when the card is used at a Relying Party and for computing the Client Pseudonym PPID value sent an Identity Provider.

.../ic:InformationCardMetaData/ic:TimeLastUpdated

This required element contains the date and time when the card was last updated.

.../ic:InformationCardMetaData/ic:IssuerId

This required element contains an identifier for the Identity Provider with which a self-issued credential descriptor in a card issued by that Identity Provider can be resolved to the correct self-issued card. The element content SHOULD be the empty string for self-issued cards.

.../ic:InformationCardMetaData/ic:IssuerName

This required element contains a friendly name of the card issuer.

.../ic:InformationCardMetaData/ic:BackgroundColor

This required element contains the background color used to display the card image.  This value is a 3-byte RGB color value in the sRGB color space used by HTML.

.../ic:InformationCardMetaData/{any}

This is an extensibility point to allow additional metadata to be included.

.../ic:InformationCardPrivateData

This required element contains the private data for an Information Card.

.../ic:InformationCardPrivateData/ic:MasterKey

This required element contains a base64 encoded 256-bit random number that provides a “secret key” for the Information Card.  This key is used for computing the Relying Party specific PPID claim when the card is used at a Relying Party and for computing the Client Pseudonym PPID value sent to an Identity Provider.  This element is present both for self-issued and managed Information Cards.

.../ic:InformationCardPrivateData/ic:ClaimValueList

This optional element is a container for the set of claim types and their corresponding values embodied by a self-issued card.

.../ic:InformationCardPrivateData/ic:ClaimValueList/ic:ClaimValue (one or more)

This required element is a container for an individual claim, i.e., a claim type and its corresponding value.

.../ic:InformationCardPrivateData/ic:ClaimValueList/ic:ClaimValue/@Uri

This required attribute contains a URI that identifies the specific claim type.

.../ic:InformationCardPrivateData/ic:ClaimValueList/ic:ClaimValue/ic:Value

This required element contains the value for an individual claim type.

…/@{any}

This is an extensibility point to allow additional attributes to be specified.  While an Identity Selector MAY ignore any extensions it does not recognize it SHOULD preserve those that it does not recognize and emit them in the respective ic:RoamingStore/ic:RoamingInformationCard element when updating information using the Information Cards Transfer Format.

…/{any}

This is an extensibility point to allow additional metadata elements to be specified.  While an Identity Selector MAY ignore any extensions it does not recognize it SHOULD preserve those that it does not recognize and emit them in the respective ic:RoamingStore/ic:RoamingInformationCard element when updating information using the Information Cards Transfer Format.

/ic:RoamingStore/@{any}

This is an extensibility point to allow additional attributes to be specified.  While an Identity Selector MAY ignore any extensions it does not recognize it SHOULD preserve those that it does not recognize and emit them in the respective ic:RoamingStore element when updating information using the Information Cards Transfer Format.

/ic:RoamingStore/{any}

This is an extensibility point to allow additional metadata elements to be specified.  While an Identity Selector MAY ignore any extensions it does not recognize it SHOULD preserve those that it does not recognize and emit them in the respective ic:RoamingStore element when updating information using the Information Cards Transfer Format.

6.1.1 PIN Protected Card

When an Information Card is PIN protected, in addition to storing a digest of the PIN in the card data, the master key and claim values associated with the card MUST also be encrypted with a key derived from the user-specified PIN.

It is RECOMMENDED that the PKCS-5 based key derivation method be used with the input parameters summarized in the table below for deriving the encryption key from the PIN.  Usage of other algorithms is not described.

The encryption method and the corresponding parameters that MUST be used are summarized in the table below.

In a PIN-protected card, the encrypted content of the master key and the claim value fields are described below.

.../ic:InformationCardPrivateData/ic:MasterKey

This element MUST contain a base64 encoded byte array comprised of the encryption parameters and the encrypted master key serialized as per the binary structure summarized in the table below.

.../ic:InformationCardPrivateData/ic:ClaimValueList/ic:ClaimValue/ic:Value

This element MUST contain a base64 encoded byte array comprised of the encrypted claim value. The encryption parameters used are taken from those serialized into the master key field and summarized in the table above.

6.1.2 Computing the ic:IssuerId

The ic:IssuerId value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider.  Specifically:

·         Compute IP PPID Seed in the same manner as RP PPID Seed in Section 7.6.1, except that the certificate from ds:KeyInfo is used, rather than the Relying Party’s.

Use the IP PPID Seed as the ic:IssuerId value.

The ic:IssuerId value SHOULD be the empty string for self-issued cards.

6.1.3 Computing the ic:IssuerName

The ic:IssuerName value used for a card when representing it in the Information Cards Transfer Format SHOULD be computed as a function of the ds:KeyInfo field of the envelope digitally signed by the Identity Provider.  Specifically, if the certificate from ds:KeyInfo is an extended validation (EV) certificate [EV Cert], then set ic:IssuerName to the organizationName (O) field value from the certificate, otherwise set ic:IssuerName to the commonName (CN) field value from the certificate.

6.1.4 Creating the ic:HashSalt

A random ic:HashSalt value for a card SHOULD be created by the Identity Selector when that card is created from the ic:InformationCard data provided by an Identity Provider.

6.2 Post-Encryption Transfer Format

The transfer stream MUST be encrypted with a key derived from a user specified password.  The XML schema used for the encrypted transfer stream is defined below:

Syntax:

The following describes the elements listed in the XML schema outlined above:

Byte-order-mark

The first three bytes in the stream containing the values {0xEF, 0xBB, 0xBF} constitutes a “byte order mark”.

/ic:EncryptedStore

The top-level container element for the encrypted transfer stream.

/ic:EncryptedStore/ic:StoreSalt

This required element contains the random salt used as a parameter for the key derivation function to derive the encryption key from a user-specified password.

/ic:EncryptedStore/xenc:EncryptedData/xenc:CipherData/xenc:CipherValue

This element contains a base64 encoded byte array containing the ciphertext corresponding to the clear text transfer stream described in Section 6.1.

@{any}

This is an extensibility point to allow additional attributes to be specified.  While an Identity Selector MAY ignore any extensions it does not recognize it SHOULD preserve those that it does not recognize and emit them when updating information using the Information Cards Transfer Format.

{any}

This is an extensibility point to allow additional metadata elements to be specified.  While an Identity Selector MAY ignore any extensions it does not recognize it SHOULD preserve those that it does not recognize and emit them when updating information using the Information Cards Transfer Format.

The remainder of this section describes the element content of the xenc:CipherValue element in the schema outline above. Specifically, it describes the encryption method used and the format of the encrypted content.

The following table defines two symbolic constants, namely EncryptionKeySalt and IntegrityKeySalt, and their corresponding values used by the key derivation and the encryption methods described below to encrypt the transfer stream.

The transfer stream content is encrypted with a key derived from a user-specified password. It is RECOMMENDED that the PKCS-5 based key derivation method be used with the input parameters summarized in the table below for deriving the key from the password.  Usage of other algorithms is not described.

The PKCS-5 key derived as per the preceding table MUST be further hashed with a 16-byte salt using the SHA256 hash function, and the resulting value used as the encryption key. The order in which the values used MUST be hashed is as follows:

Encryption Key = SHA256 (EncryptionKeySalt + PKCS5-derived-key)

Further, to provide an additional integrity check at the time of import, a “hashed integrity code” MUST be computed as follows and included along with the encrypted transfer stream content.

·         The PKCS-5 key derived as per the preceding table MUST be further hashed with a 16-byte salt using the SHA256 hash function, and the resulting value used as the integrity key. The order in which the values used MUST be hashed is as follows:

Integrity Key = SHA256 (IntegrityKeySalt + PKCS5-derived-key)

·         The last block of the clear text transfer stream MUST be captured and further hashed with the integrity key (IK) and the initialization vector (IV) using the SHA256 hash function, and the resulting value used as the hashed integrity code. The order in which the values used MUST be hashed is as follows:

Hashed Integrity Code = SHA256 (IV + IK + Last-block-of-clear-text)

The encryption method and the corresponding parameters that MUST be used to encrypt the transfer stream are summarized in the table below.

The element content of xenc:CipherValue MUST be a base64 encoded byte array comprised of the initialization vector used for encryption, the hashed integrity code (as described above), and the encrypted transfer stream. It MUST be serialized as per the binary structure summarized in the table below.

7      Simple Identity Provider Profile

A simple Identity Provider, called the “Self-issued Identity Provider” (SIP), is one which allows users to self-assert identity in the form of self-issued tokens. An Identity Selector MAY include a co-resident Self-issued Identity Provider that conforms to the Simple Identity Provider Profile defined in this section. This profile allows self-issued identities created within one Identity Selector to be used in another Identity Selector such that users do not have to reregister at a Relying Party when switching Identity Selectors. Because of the co-location there is data and metadata specific to an Identity Provider that need to be shareable between Identity Selectors.

7.1 Self-Issued Information Card

The ic:Issuer element within an Information Card provides a logical name for the issuer of the Information Card. An Information Card issued by a SIP (i.e., a self-issued Information Card) MUST use the special URI below as the value of the ic:Issuer element in the Information Card.

URI:

7.2 Self-Issued Token Characteristics

The self-issued tokens issued by a SIP MUST have the following characteristics:

·         The token type of the issued token MUST be SAML 1.1 which MUST be identified by either of the following token type URIs:

o    urn:oasis:names:tc:SAML:1.0:assertion, or

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

·         It is RECOMMENDED that the signature key used in the issued token be a 2048-bit asymmetric RSA key which identifies the issuer.  Usage of other algorithms is not described.

·         The issuer of the token, indicated by the value of the saml:Issuer attribute on the saml:Assertion root element, MUST be identified by the following URI defined in Section 2.1.1 representing the issuer “self”.

http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self

·         The issued token MUST contain the saml:Conditions element specifying:

o    the token validity interval using the NotBefore and NotOnOrAfter attributes, and

o    the saml:AudienceRestrictionCondition element restricting the token to a specific target scope (i.e., a specific recipient of the token).

·         The saml:NameIdentifier element SHOULD NOT be used to specify the Subject of the token.

·         The subject confirmation method MUST be specified as one of:

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

o    urn:oasis:names:tc:SAML:1.0:cm:bearer (for Browser based applications).

·         When the subject confirmation method is “holder of key”, the subject confirmation key (also referred to as the proof key) MUST be included in the token in the ds:KeyInfo child element under the saml:SubjectConfirmation element. The proof key MUST be encoded in the token as follows:

o    For symmetric key tokens, the proof key is encrypted to the recipient of the token in the form of a xenc:EncryptedKey child element. It is RECOMMENDED that an AES key with a default size of 256 bits be used, but a different size MAY be specified by the Relying Party.  Usage of other algorithms is not described.

o    For asymmetric key tokens, it is RECOMMENDED that the proof key be a public RSA key value specified as a ds:RSAKeyValue child element under the ds:KeyValue element. The default size of the key is 2048 bits.  Usage of other algorithms is not described.

·         The issued token MUST contain a single attribute statement (i.e., a single saml:AttributeStatement element) containing the subject confirmation data and the requested claims (called attributes in a SAML token).

·         The claim types supported by the self-issued token SHOULD include those listed in Section7.5.

·         The claims asserted in the saml:AttributeStatement element of the issued token MUST be named as follows using the claim type definitions in the XML schema file referenced in Section7.5. For each claim represented by a saml:Attribute element,

o    the AttributeName attribute is set to the NCname of the corresponding claim type defined in the XML schema file, and

o    the AttributeNamespace attribute is set to the target namespace of the XML schema file, namely

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

It is RECOMMENDED that the XML digital signature [XMLDSIG] profile used to sign a self-issued token be as follows.  Usage of other algorithms is not described.

·         Uses the enveloped signature format identified by the transform algorithm identifier “http://www.w3.org/2000/09/xmldsig#enveloped-signature”. The token signature contains a single ds:Reference containing a URI reference to the AssertionID attribute value of the root element of the SAML token.

·         Uses the RSA signature method identified by the algorithm identifier “http://www.w3.org/2000/09/xmldsig#rsa-sha1”.

·         Uses the exclusive canonicalization method identified by the algorithm identifier “http://www.w3.org/2001/10/xml-exc-c14n#” for canonicalizing the token content as well as the signature content.

·         Uses the SHA1 digest method identified by the algorithm identifier “http://www.w3.org/2000/09/xmldsig#sha1” for digesting the token content being signed.

·         No other transforms, other than the ones listed above, are used in the enveloped signature.

·         The ds:KeyInfo element is always present in the signature carrying the signing RSA public key in the form of a ds:RSAKeyValue child element.

Following is an example of a self-issued signed Security Token containing three claims.

Example:

The content of the saml:Subject element in the self-issued token differs based on the subject confirmation method and the type of proof key used. The following examples illustrate each of the three variations of the content of this element.

The following example illustrates the content of the saml:Subject element when subject confirmation method is “holder of key” using a symmetric proof key.

Example:

The following example illustrates the content of the saml:Subject element when subject confirmation method is “holder of key” using an asymmetric proof key.

Example:

The following example illustrates the content of the saml:Subject element when subject confirmation method is “bearer” using no proof key.

Example:

7.3 Self-Issued Token Encryption

One of the goals of the Information Card Model is to ensure that any claims are exposed only to the Relying Party intended by the user. For this reason, the SIP SHOULD encrypt the self-issued token under the key of the Relying Party. This guarantees that a token intended for one Relying Party cannot be decoded by nor be meaningful to another Relying Party. As described in Section 8.3, when the Relying Party is not identified by a certificate, because no key is available for the Relying Party in this case, the token can not be encrypted, but SHOULD still be signed.

When a self-issued token is encrypted, the XML encryption [XMLENC] standard MUST be used. The encryption construct MUST use encrypting the self-issued token with a randomly generated symmetric key which in turn is encrypted to the Relying Party’s public key taken from its X.509 v3 certificate. The encrypted symmetric key MUST be placed in an xenc:EncryptedKey element within the xenc:EncryptedData element carrying the encrypted Security Token.

It is RECOMMENDED that the XML encryption [XMLENC] profile that is used for encrypting the key and the token be as follows.  Usage of other algorithms is not described.

·         Uses the RSA-OAEP key wrap method identified by the algorithm identifier “http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p” for encrypting the encryption key.

·         Uses the AES256 with CBC encryption method identified by the algorithm “http://www.w3.org/2001/04/xmlenc#aes256-cbc” for encrypting the token. The padding method used is as per the PKCS-7 standard in which the number of octets remaining in the last block is used as the padding octet value.

·         The ds:KeyInfo element is present in the encrypted key specifying the encryption key information in the form of a Security Token reference.

Following is an illustration of a self-issued token encrypted to a Relying Party using the encryption structure described above.

Example:

7.4 Self-Issued Token Signing Key

The key used to sign a self-issued token presented to a Relying Party also represents a unique identifier for the Subject of the token. In order to prevent the key from becoming a correlation identifier across relying parties, a SIP SHOULD use a different key to sign a self-issued token for each Relying Party where the card is used. In other words, the key used to sign the self-issued token is pair-wise unique for a given Information Card and RP combination. To allow self-issued identities created by a SIP within one Identity Selector to be used in another, the signing keys used by the two SIPs SHOULD be the same.

It is RECOMMENDED that the signing key be an RSA key.  Usage of other algorithms is not described.

This section specifies the “processing rules” that SHOULD be used by a SIP to derive the RSA key used to sign the self-issued token for a combination of an Information Card and an RP where the card is used. Each self-issued Information Card contains a 256-bit secret random number, called the “master key” (see Section 6.1), that is used as the secret entropy in deriving the token signing RSA key.  (Managed Information Cards also have a master key that is used in the Client Pseudonym PPID calculation, as per Section 3.3.4.1.)

Key derivation is done according to the ANSI X9.31 standard for key generation which starts with requiring the use of six random values denoted by X_p1, X_p2, X_q1, X_q2, X_p, and X_q. The processing rules described here enunciate how to transform the master key in an Information Card into the six random inputs for the X9.31 key generation process. The actual key computation algorithm in the X9.31 standard is not reproduced here.

The values X_p and X_q are REQUIRED to be at least 512 bits and each independently carries the full entropy of any Information Card master key of up to 512 bits in length.  The values X_p1, X_p2, X_q1, and X_q2 have a length of only 100 to 121 bits and therefore will be shorter than the Information Card master key and hence cannot each independently carry the full master key entropy. The details of the X9.31 protocol, however, ensure that for reasonably sized master keys, full entropy will be achieved in the generated asymmetric key pair.

7.4.1 Processing Rules

This key generation mechanism can be used to generate 1024 or 2048-bit RSA keys.

Notation: If H is an n-bit big-endian value, the convention H[1..p] denotes bits 1 through p in the value of H where p ≤ n, and bit-1 is the rightmost (least significant) bit whereas bit-n is the leftmost (most significant) bit in the value of H. Also, the convention X + Y denotes the concatenation of the big-endian bit value of X followed by the big-endian bit value of Y.

Assume that the master key for the selected Information Card (see Section 6.1) is M and the unique RP Identifier (derived as per Section 7.6.1) is T. The following processing rules SHOULD be used to derive the inputs for the X9.31 key generation process.

1.     Define 32-bit DWORD constants C_n as follows:

C_n = n,  where n = 0,1,2,...,15

2.     Compute SHA-1 hash values H_n as follows:

If the requested key size = 1024 bits, compute

H_n = SHA1 (M + T + C_n)  for n = 0,1,2,...,9

If the requested key size = 2048 bits, compute

H_n = SHA1 (M + T + C_n)  for n = 0,1,2,...,15

3.     Extract the random input parameters for the X9.31 protocol as follows:

For all key sizes, compute

X_p1 [112-bits long] = H₀[1..112]

X_p2 [112-bits long] = H₁[1..112]

X_q1 [112-bits long] = H₂[1..112]

X_q2 [112-bits long] = H₃[1..112]

If the requested key size = 1024 bits, compute

X_p [512-bits long] = H₄[1..160] + H₅[1..160] + H₆[1..160] + H₀[129..160]

X_q [512-bits long] = H₇[1..160] + H₈[1..160] + H₉[1..160] + H₁[129..160]

If the requested key size = 2048 bits, compute

X_p  [1024-bits long] = H₄[1..160] + H₅[1..160] + H₆[1..160] + H₀[129..160] +

  H₁₀[1..160] + H₁₁[1..160] + H₁₂[1..160] + H₂[129..160]

X_q  [1024-bits long] = H₇[1..160] + H₈[1..160] + H₉[1..160] + H₁[129..160] +

  H₁₃[1..160] + H₁₄[1..160] + H₁₅[1..160] + H₃[129..160]

4.     The X9.31 specification (Section 4.1.2) requires that the input values X_p1, X_p2, X_q1, X_q2 MUST satisfy the following conditions.

·         The large prime factors p₁, p₂, q₁, and q₂ are the first primes greater than their respective random X_p1, X_p2, X_q1, X_q2 input values. They are randomly selected from the set of prime numbers between 2¹⁰⁰ and 2¹²⁰, and each SHALL pass at least 27 iterations of Miller-Rabin.

To ensure that the lower bound of 2¹⁰⁰ is met, set the 101^th bit of X_p1, X_p2, X_q1, X_q2 to ‘1’ (i.e. X_p1[13^th byte] |= 0x10, X_p2[13^th byte] |= 0x10, X_q1[13^th byte] |= 0x10, X_q2[13^th byte] |= 0x10).

5.     The X9.31 specification (Section 4.1.2) requires that the input values X_p and X_q MUST satisfy the following conditions.

·         If the requested key size = 1024 bits, then

X_p ≥ (√2)(2⁵¹¹)  and  X_q ≥ (√2)(2⁵¹¹)

·         If the requested key size = 2048 bits, then

X_p ≥ (√2)(2¹⁰²³)  and  X_q ≥ (√2)(2¹⁰²³)

To ensure this condition is met, set the two most significant bits of X_p and X_q to ‘1’ (i.e. X_p[most significant byte] |= 0xC0, X_q[most significant byte] |= 0xC0).

6.     Compute 1024 or 2048-bit keys as per the X9.31 protocol using {X_p1, X_p2, X_q1, X_q2, X_p, X_q} as the random input parameters.

7.     Use a 32-bit DWORD size public exponent value of 65537 for the generated RSA keys.

There are three conditions as follows in the X9.31 specification which, if not met, require that one or more of the input parameters MUST be regenerated.

·         (Section 4.1.2 of X9.31)  |X_p-X_q| ≥ 2⁴¹² (for 1024-bit keys) or |X_p-X_q| ≥ 2⁹²⁴ (for 2048-bit keys). If not true, X_q MUST be regenerated and q recomputed.

·         (Section 4.1.2 of X9.31)  |p-q| ≥ 2⁴¹² (for 1024-bit keys) or |p-q| ≥ 2⁹²⁴ (for 2048-bit keys). If not true, X_q MUST be regenerated and q recomputed.

·         (Section 4.1.3 of X9.31)  d > 2⁵¹² (for 1024-bit keys) or d > 2¹⁰²⁴ (for 2048-bit keys). If not true, X_q1, X_q2, and X_q MUST be regenerated and key generation process repeated.

When it is necessary to regenerate an input parameter as necessitated by one or more of the conditions above, it is essential that the regeneration of the input parameter be deterministic to guarantee that all implementations of the key generation mechanism will produce the same results. Furthermore, input regeneration is a potentially unlimited process. In other words, it is possible that regeneration MUST be performed more than once.  In theory, one MAY need to regenerate input parameters many times before a key that meets all of the requirements can be generated.

The following processing rules MUST be used for regenerating an input parameter X of length n-bits when necessary:

a.     Pad the input parameter X on the right, assuming a big-endian representation, with m zero-bits where m is the smallest number which satisfies ((n+m) mod 128 = 0).

b.    Encrypt the padded value with the AES-128 (Electronic Code Book mode) algorithm using the 16-byte constant below as the encryption key:

c.     Use the leftmost n-bits of the result above as the REQUIRED regenerated parameter.

If a regenerated parameter does not satisfy the necessary conditions, then repeat the 3-step process above (call it RegenFunction) to generate the parameter again by using the output of one iteration as input for the next iteration. In other words, if the output of the i^th iteration of the regeneration function above for an input parameter X is given by X_i then

X_i+1 = RegenFunction (X_i)

7.5 Claim Types

This section specifies a set of claim (attribute) types and the corresponding URIs that is defined by this profile for some commonly used personal information. These claim types MAY be used by a SIP, in self-issued tokens, or by other Identity Providers. Note that, wherever possible, the claims included here reuse and refer to the attribute semantics defined in other established industry standards that deal with personal information. A SIP SHOULD support these claim types at a minimum. Other Identity Providers MAY also support these claim types when appropriate. The URIs defined here MAY be used by a Relying Party to specify requested claims in its policy.

The base XML namespace URI that is used by the claim types defined here is as follows:

For convenience, an XML Schema for the claim types defined here can be found at:

7.5.1 First Name

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

Type:  xs:string

Definition:  (givenName in [RFC 2256]) Preferred name or first name of a Subject. According to RFC 2256: “This attribute is used to hold the part of a person’s name which is not their surname nor middle name.”

7.5.2 Last Name

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Type:  xs:string

Definition:  (sn in [RFC 2256]) Surname or family name of a Subject. According to RFC 2256: “This is the X.500 surname attribute which contains the family name of a person.”

7.5.3 Email Address

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Type:  xs:string

Definition:  (mail in inetOrgPerson) Preferred address for the “To:” field of email to be sent to the Subject, usually of the form <user>@<domain>. According to inetOrgPerson using [RFC 1274]: “This attribute type specifies an electronic mailbox attribute following the syntax specified in RFC 822.”

7.5.4 Street Address

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress

Type:  xs:string

Definition:  (street in [RFC 2256]) Street address component of a Subject’s address information. According to RFC 2256: “This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery.” Its content is arbitrary, but typically given as a PO Box number or apartment/house number followed by a street name, e.g. 303 Mulberry St.

7.5.5 Locality Name or City

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality

Type:  xs:string

Definition:  (l in [RFC 2256]) Locality component of a Subject’s address information. According to RFC 2256: “This attribute contains the name of a locality, such as a city, county or other geographic region.” e.g. Redmond.

7.5.6 State or Province

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince

Type:  xs:string

Definition:  (st in [RFC 2256]) Abbreviation for state or province name of a Subject’s address information. According to RFC 2256: “This attribute contains the full name of a state or province. The values SHOULD be coordinated on a national level and if well-known shortcuts exist - like the two-letter state abbreviations in the US – these abbreviations are preferred over longer full names.” e.g. WA.

7.5.7 Postal Code

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode

Type:  xs:string

Definition:  (postalCode in X.500) Postal code or zip code component of a Subject’s address information. According to X.500(2001): “The postal code attribute type specifies the postal code of the named object. If this attribute value is present, it will be part of the object’s postal address - zip code in USA, postal code for other countries.”

7.5.8 Country

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country

Type:  xs:string

Definition:  (c in [RFC 2256]) Country of a Subject. According to RFC 2256: “This attribute contains a two-letter ISO 3166 country code.”

7.5.9 Primary or Home Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone

Type:  xs:string

Definition:  (homePhone in inetOrgPerson) Primary or home telephone number of a Subject. According to inetOrgPerson using [RFC 1274]: “This attribute type specifies a home telephone number associated with a person.” Attribute values SHOULD follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

7.5.10 Secondary or Work Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone

Type:  xs:string

Definition:  (telephoneNumber in X.500 Person) Secondary or work telephone number of a Subject. According to X.500(2001): “This attribute type specifies an office/campus telephone number associated with a person.” Attribute values SHOULD follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

7.5.11 Mobile Telephone Number

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone

Type:  xs:string

Definition:  (mobile in inetOrgPerson) Mobile telephone number of a Subject. According to inetOrgPerson using [RFC 1274]: “This attribute type specifies a mobile telephone number associated with a person.” Attribute values SHOULD follow the agreed format for international telephone numbers, e.g. +44 71 123 4567.

7.5.12 Date of Birth

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth

Type:  xs:date

Definition:  The date of birth of a Subject in a form allowed by the xs:date data type.

7.5.13 Gender

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender

Type:  xs:token

Definition:  Gender of a Subject that can have any of these exact string values – ‘0’ (meaning unspecified), ‘1’ (meaning Male) or ‘2’ (meaning Female). Using these values allows them to be language neutral.

7.5.14 Private Personal Identifier

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier

Type:  xs:base64binary

Definition:  A private personal identifier (PPID) that identifies the Subject to a Relying Party. The word “private” is used in the sense that the Subject identifier is specific to a given Relying Party and hence private to that Relying Party. A Subject’s PPID at one Relying Party cannot be correlated with the Subject’s PPID at another Relying Party. Typically, the PPID SHOULD be generated by an Identity Provider as a pair-wise pseudonym for a Subject for a given Relying Party. For a self-issued Information Card, the Self-issued Identity Provider in an Identity Selector system SHOULD generate a PPID for each Relying Party as a function of the card identifier and the Relying Party’s identity. The processing rules and encoding of the PPID claim value is specified in Section 7.6.

Compatibility Note:  Some existing Identity Selectors omit listing the PPID claim as an ic:SupportedClaimType from the ic:SupportedClaimTypeList when saving a self-issued Information Card in the Information Cards Transfer Format defined in Section 6.1, even though the PPID claim is supported by the card.  This behavior is deprecated, as all supported claims SHOULD be listed.  Nonetheless, Identity Selectors MAY choose to recognize this case and support the PPID claim for self-issued cards not explicitly listing this claim.

7.5.15 Web Page

URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/webpage

Type:  xs:string

Definition:  The Web page of a Subject expressed as a URL.

7.6 The PPID Claim

The PPID claim for a Subject user represents a unique identifier for that user at a given Relying Party that is different from all identifiers for that user at any other Relying Party. In other words, the PPID is a pair-wise unique identifier for a given user identity and Relying Party combination. Since an Information Card represents a specific user identity and a Relying Party is the organization behind a Web service or site that the user interacts with, the PPID claim is logically a function of an Information Card and the organizational identity of the Relying Party.

This section describes the processing rules that SHOULD be used by a SIP to derive a PPID claim value for a combination of an Information Card and a Relying Party where it is used.

7.6.1 Relying Party Identifier and Relying Party PPID Seed

In order to derive the PPID and Signing Key as functions of the RP’s organizational identity, a stable and unique identifier for the RP, called the RP Identifier, is needed. In the Information Card Model, the identity of a Relying Party (RP) possessing an X.509v3 certificate is presented in the form of that certificate. Therefore the organizational identity of the RP is obtained by applying a series of transformations to the identity information carried in the X.509 certificate.  (See Section 8 for the specification of how to compute these values for Relying Parties not possessing a certificate.)

As specified in [RFC 2459], the subject field inside an X.509 certificate identifies the entity associated with the public key stored in the subject public key field. Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer name field.

The subject field contains a DN of the form shown below:

CN=string, [OU=string, ...,] O=string, L=string, S=string, C=string

The Object Identifiers for these attributes from the DN are as follows:

Note that the field names and abbreviations used in this specification may not correspond to those used by particular software but the underlying Object Identifiers (OIDs) of the attributes are unambiguous.

For an end-entity certificate, the values of the attribute types O (organizationName), L (localityName), S (stateOrProvinceName) and C (countryName) together uniquely identify the organization to which the end-entity identified by the certificate belongs. These attribute types are collectively referred to as the organizational identifier attributes here. The RP Identifier is constructed using these organizational identifier attributes as described below.

The RP Identifier value is used as an input to the Signing Key computation.  A closely related value called the Relying Party PPID Seed is also computed, which is used as an input to the PPID claim and Client Pseudonym PPID computations.  In many cases these are the same but in one case they differ.

There are four cases of how the RP Identifier and RP PPID Seed are constructed depending on which organizational identifier attributes the RP’s certificate contains, if it is an extended validation (EV) certificate [EV Cert] with respect to the organizational identifier attributes, and if it chains to a trusted root certificate.

Case 1: RP’s certificate is EV for organizational identifier attributes and chains to a trusted root certificate authority

·         Convert the organizational identifier attributes in the end-entity certificate into a string, call it OrgIdString, of the following form:

|O="string"|L="string"|S="string"|C="string"|

The vertical bar character (ASCII 0x7C) is used as a delimiter at the start and end of the string as well as between the attribute types. Further, the string values of the individual attribute types are enclosed within double quote characters (ASCII 0x22). If an attribute type is absent in the subject field of the end-entity certificate, then the corresponding string value is the empty string (""). Following is an example OrgIdString per this convention.

|O="Microsoft"|L="Redmond"|S="Washington"|C="US"|

·         Encode all the characters in OrgIdString into a sequence of bytes, call it OrgIdBytes, using Unicode encoding UTF-16LE with no byte order mark.

·         Hash OrgIdBytes using the SHA256 hash function, and use the resulting value as the RP Identifier and RP PPID Seed.

RP PPID Seed = RP Identifier = SHA256 (OrgIdBytes)

Case 2: RP’s certificate is not EV for organizational identifier attributes, has a non-empty organizationName (O) value, and chains to a trusted root certificate authority

·         Convert the organizational identifier attributes in the end-entity certificate into a string, call it OrgIdString, in the same manner as employed for Case 1 above.

·         Let QualifierString be the string:

|Non-EV

·         Let QualifiedOrgIdString be the concatenation of QualifierString and OrgIdString.

QualifiedOrgIdString = QualifierString + OrgIdString

·         Encode all the characters in QualifiedOrgIdString into a sequence of bytes, call it QualifiedOrgIdBytes, using Unicode encoding UTF-16LE with no byte order mark.

·         Hash QualifiedOrgIdBytes using the SHA256 hash function, and use the resulting value as the RP Identifier.

RP Identifier = SHA256 (QualifiedOrgIdBytes)

·         Encode all the characters in OrgIdString into a sequence of bytes, call it OrgIdBytes, using Unicode encoding UTF-16LE with no byte order mark.

·         Hash OrgIdBytes using the SHA256 hash function, and use the resulting value as the Relying Party PPID Seed.

RP PPID Seed = SHA256 (OrgIdBytes)

Case 3: RP’s certificate has an empty or no organizationName (O) value and has an empty or no commonName (CN) or does not chain to a trusted root certificate authority

·         Take the subject public key in the end-entity certificate, call it PublicKey, as a byte array.

·         Hash PublicKey using the SHA256 hash function, and use the resulting value as the RP Identifier and RP PPID Seed.

RP PPID Seed = RP Identifier = SHA256 (PublicKey)

Case 4: RP’s certificate has an empty or no organizationName (O) value but has a non-empty commonName (CN) value and chains to a trusted root certificate authority

·         Convert the commonName attribute value in the end-entity certificate into a string, call it CnIdString, of the following form:

|CN="string"|

Following is an example CnIdString per this convention:

|CN="login.live.com"|

·         Encode all the characters in CnIdString into a sequence of bytes, call it CnIdBytes, using Unicode encoding UTF-16LE with no byte order mark.

·         Hash CnIdBytes using the SHA256 hash function, and use the resulting value as the RP Identifier and RP PPID Seed.

RP PPID Seed = RP Identifier = SHA256 (CnIdBytes)

7.6.2 PPID

The PPID value SHOULD be produced as follows using the card identifier and the RP PPID Seed (specified in Section 7.6.1):

·         Encode the value of the ic:CardId element of the Information Card into a sequence of bytes, call it CardIdBytes, using Unicode encoding UTF-16LE with no byte order mark.

·         Hash CardIdBytes using the SHA256 hash function to obtain the canonical card identifier CanonicalCardId.

CanonicalCardId = SHA256 (CardIdBytes)

·         Hash the concatenation of RP PPID Seed and CanonicalCardId using the SHA256 hash function to obtain the PPID.

PPID = SHA256 (RP PPID Seed + CanonicalCardId)

7.6.3 Friendly Identifier

The PPID provides an RP-specific identifier for a Subject that is suitable for programmatic processing, but is not a user-friendly identifier. The simple transformation rules specified in this section MAY be used by a SIP, or any other Identity Provider supporting the PPID claim, to create a friendly identifier for use within a Display Token accompanying a Security Token carrying the PPID claim.

The Friendly Identifier has the following characteristics:

·         It is encoded as a 10-character alphanumeric string of the form “AAA-AAAA-AAA” grouped into three groups separated by the ‘hyphen’ character (e.g., the string “6QR-97A4-WR5”). Note that the hyphens are used for punctuation only.

·         The encoding alphabet does NOT use the numbers ‘0’ and ‘1’, and the letters ‘O’ and ‘I’ to avoid confusion stemming from the similar glyphs used for these numbers and characters. This leaves 8 digits and 24 letters – a total of 32 alphanumeric symbols – as the alphabet for the encoding.

The processing rules used for deriving a Friendly Identifier from a PPID are as follows:

·         The PPID value is conveyed as a base64 encoded string inside tokens. Start with the base64 decoded PPID value as input.

·         Hash the PPID value using the SHA1 hash function to obtain a hashed identifier.

HashId = SHA1 (PPID)

·         Let the Friendly Identifier be the string “A₀ A₁ A₂– A₃ A₄ A₅ A₆– A₇ A₈ A₉” where each A_i is an alphanumeric character from the encoding alphabet described above.

·         For i := 0 to 9,  each A_i is determined as below:

o    Take the i^th octet of HashId (denoted as HashId[i])

o    Find RawValue = HashId[i] % 32  (where % is the remainder operation)

o    A_i = EncodedSymbol obtained by mapping RawValue to EncodedSymbol using the table below

 

Raw Value	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Encoded Symbol	Q	L	2	3	4	5	6	7	8	9	A	B	C	D	E	F

 

Raw Value	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Encoded Symbol	G	H	J	K	M	N	P	R	S	T	U	V	W	X	Y	Z

 

8      Relying Parties without Certificates

While Relying Parties are typically identified by presenting a cryptographically protected identity, such as an X.509v3 certificate, the Information Card Model is also applicable in situations in which no Relying Party certificate is available.  This section specifies how Information Cards are used at Relying Parties with no certificate: specifically, Web sites using the [HTTP] scheme.  Also see ic07:RequireStrongRecipientIdentity in Section 3.1.1.7 for a means whereby card issuers can prohibit the use of cards at Relying Parties not identified by a certificate.

8.1 Relying Party Identifier and Relying Party PPID Seed

The Relying Party Identifier and Relying Party PPID Seed values for Relying Parties without certificates are computed in this manner:

·         Set the string OrgIdString to be the fully qualified DNS host name in lowercase characters specified in the URI of the Relying Party, or if a numeric IP address was used, then a string representation of the IP address of the server.  For IPv4 addresses, this string is the standard 4-byte dotted decimal representation of the address with no leading zeros, such as 131.107.55.210.  For IPv6 addresses, this string is the hexadecimal representation of the address in eight groups of four hex digits each using uppercase for the letters, with each group of four digits separated by a colon, all enclosed by square brackets, such as [0000:1234:0000:0000:0000:000A:00BC:0DEF].

·         Encode all the characters in OrgIdString into a sequence of bytes, call it OrgIdBytes, using the Unicode encoding UTF-16LE with no byte order mark.

·         Hash OrgIdBytes using the SHA256 hash function, and use the resulting value as both the RP Identifier and the RP PPID Seed.

The RP Identifier and RP PPID Seed are then used in the same manner as for Relying Parties identified by certificates when computing PPID claim and Client Pseudonym PPID values.

8.2 AppliesTo Information

Under the circumstances described in Section 3.3.3 that the RP endpoint to which the token will be sent is supplied as the wsp:AppliesTo value to the IP, when the RP possesses no certificate, the URL of the RP is supplied as that wsp:AppliesTo value.

Example:

8.3 Token Signing and Encryption

When the Relying Party is not identified by a certificate, tokens sent from the Self-issued Identity Provider are not encrypted, although they are still signed in the manner described in Section 7.2.  Tokens generated by Identity Providers for Relying Parties not identified by a certificate are also typically not encrypted, as no encryption key is available.  However, the token MAY still be encrypted if the Identity Provider has a pre-existing relationship with the Relying Party and they have mutually agreed on the use of a known encryption key.  The token SHOULD still typically be signed, even when not encrypted.

9      Using WS-SecurityPolicy 1.2 and WS-Trust 1.3

Software implementing the Information Card Model SHOULD utilize the OASIS standard versions of WS-SecurityPolicy and WS-Trust – [WS-SecurityPolicy 1.2] and [WS-Trust 1.3] and MAY utilize the previous draft versions – [WS-SecurityPolicy 1.1] and [WS-Trust 1.2].  This section describes the differences between the old and standard versions of these protocols that MAY affect software implementing the Information Card Model.

9.1 Overview of Differences

The following changes between the protocol versions affect software implementing this specification:

·         Namespace changes:
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 replaces http://schemas.xmlsoap.org/ws/2005/07/securitypolicy.
http://docs.oasis-open.org/ws-sx/ws-trust/200512 replaces http://schemas.xmlsoap.org/ws/2005/02/trust.

·         Use of RequestSecurityTokenResponseCollection:  A wst:RequestSecurityTokenResponseCollection element encloses the wst:RequestSecurityTokenResponse when WS-Trust 1.3 is used.

·         Use of SecondaryParameters:  An Identity Selector sends some information received from the Relying Party to the Identity Provider in a wst:SecondaryParameters element.

·         Bearer Token Request Syntax:  The new wst:KeyType value http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer is used to request a bearer token.

9.2 Identity Selector Differences

Identity Selectors MUST determine the WS-Trust versions used by Identity Provider STSs and Relying Party STSs using their Security Policy.

Identity Selectors supporting WS-Trust 1.3 MUST understand the new WS-Trust 1.3 elements and syntax such as wst13:RequestSecurityTokenResponseCollection and new URIs such as http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer.  They MUST also understand that typical properties of an RST like Claims and KeyType MAY be either a direct child of the top level wst13:RequestSecurityToken element or contained within a wst13:SecondaryParameters element in the RST.

When constructing an RST for an Identity Provider using WS-Trust 1.3, the Identity Selector SHOULD send parameters received from the Relying Party in a wst13:SecondaryParameters element within the wst13:RequestSecurityToken, with these exceptions:

·         The user chooses not to send optional claims. In this scenario, no SecondaryParameters element is sent in order to hide this user decision.

·         No wsp:AppliesTo is being sent in the RST. In this scenario, no wst13:SecondaryParameters element is sent so that the Identity Provider does not obtain any identifying information about the Relying Party.

Example:

The wst13:RequestSecurityTokenResponse constructed MUST be enclosed within a wst13:RequestSecurityTokenResponseCollection element.

Example:

9.3 Security Token Service Differences

To utilize WS-Trust 1.3, an Identity Provider STS and Relying Party STSs MUST express their Security Policy using WS-SecurityPolicy 1.2.

STSs using WS-Trust 1.3 MUST understand the new WS-Trust 1.3 elements and syntax such as wst13:RequestSecurityTokenResponseCollection and new URIs such as http://docs.oasis-open.org/ws-sx/wstrust/200512/Bearer.  They MUST also understand that typical properties of an RST like Claims and KeyType MAY be either a direct child of the top level wst13:RequestSecurityToken element or contained within a wst13:SecondaryParameters element in the RST.

This section explains the steps that a Web browser takes when using an Information Card to authenticate to a Web site.  Two cases are described.  The basic case is where the Web site provides all the Relying Party functionality via HTML extensions transported over HTTPS.  The second case is where the Relying Party employs a Relying Party Security Token Service (STS), which it references via HTML extensions transported over HTTPS.

10.1 Basic Protocol Flow when using an Information Card at a Web Site

This section explains the protocol flow when using an Information Card to authenticate at a Web site where no Relying Party STS is employed.

Figure 1. Basic protocol flow when using an Information Card to authenticate at a Web site

 

Figure 1 gives an example of the basic protocol flow when an Information Card is used to authenticate at a Web site that employs no Relying Party STS.  Steps 1, 2, and 5 are essentially the same as a typical forms-based login today:  (1) The user navigates to a protected page that requires authentication.  (2) The site redirects the browser to a login page, which presents a Web form.  (5) The browser posts the Web form that includes the login credentials supplied by the user back to the login page.  The site then validates the contents of the form including the user credentials, typically writes a client-side browser cookie to the client for the protected page domain, and redirects the browser back to the protected page.

The key difference between this scenario and today’s site login scenarios is that the login page returned to the browser in step (2) contains an HTML tag that allows the user to choose to use an Information Card to authenticate to the site.  When the user selects this tag, the browser invokes an Identity Selector, which implements the Information Card user experience and protocols, and triggers steps (3) through (5).

In Step (3), the browser Information Card support code invokes the Identity Selector, passing it parameter values supplied by the Information Card HTML tag supplied by the site in Step (2).  The user then uses the Identity Selector to choose an Information Card, which represents a Digital Identity that can be used to authenticate at that site.  Step (4) retrieves a Security Token that represents the Digital Identity selected by the user from the STS at the Identity Provider for that identity.

In Step (5), the browser posts the token obtained back to the Web site using a HTTPS/POST.  The Web site validates the token, completing the user’s Information Card-based authentication to the Web site.  Following authentication, the Web site typically then writes a client-side browser cookie and redirects the browser back to the protected page.

It is worth noting that this cookie is likely to be exactly the same cookie as the site would have written back had the user authenticated via other means, such as a forms-based login using username/password.  This is one of the ways that the goal of “minimal impact on Web sites” is achieved.  Other than its authentication subsystem, the bulk of a Web site’s code can remain completely unaware that Information Card-based authentication is even utilized.  It just uses the same kinds of cookies as always.

10.2 Protocol Flow with Relying Party STS

In the previous scenario, the Web site communicated with the client Identity Selector using only the HTML extensions enabling Information Card use, transported over the normal browser HTTPS channel.  In this scenario, the Web site also employs a Relying Party STS to do part of the work of authenticating the user, passing the result of that authentication on to the login page via HTTPS POST.

There are several reasons that a site might factor its solution this way.  One is that the same Relying Party STS can be used to do the authentication work for both browser-based applications and smart client applications that are using Web services. Second, it allows the bulk of the authentication work to be done on servers dedicated to this purpose, rather than on the Web site front-end servers.  Finally, this means that the front-end servers can accept site-specific tokens, rather than the potentially more general or more complicated authentication tokens issued by the Identity Providers.

Figure 2.  Protocol flow when using an Information Card to authenticate
at a Web site, where the Web site employs a Relying Party STS

This scenario is similar to the previous one, with the addition of steps (3) and (6).  The differences start with the Information Card information supplied to the browser by the Web site in Step (2).  In the previous scenario, the site encoded its WS-SecurityPolicy information using Information Card HTML extensions and supplied them to the Information Card-extended browser directly.  In this scenario, the site uses different Information Card HTML extensions in the Step (2) reply to specify which Relying Party STS SHOULD be contacted to obtain the WS-SecurityPolicy information.

In Step (3), the Identity Selector contacts the Relying Party STS specified by the Web site and obtains its WS-SecurityPolicy information via WS-MetadataExchange.  In Step (4) the Identity Selector user interface is shown and the user selects an Information Card, which represents a Digital Identity to use at the site.  In Step (5), the Identity Provider is contacted to obtain a Security Token for the selected Digital Identity.  In Step (6), the Security Token is sent to the Web site’s Relying Party STS to authenticate the user and a site-specific authentication token is returned to the Identity Selector.  Finally, in Step (7), the browser posts the token obtained in Step (6) back to the Web site using HTTPS/POST.  The Web site validates the token, completing the user’s Information Card-based authentication to the Web site.  Following authentication, the Web site typically then writes a client-side browser cookie and redirects the browser back to the protected page.

10.3 User Perspective and Examples

The Information Card user experience at Web sites is intended to be intuitive and natural enough that users’ perspective on it will simply be “That’s how you log in”.  Today, Web sites that require authentication typically ask the user to supply a username and password at login time.  With Information Cards, they instead ask users to choose an Information Card.  Some sites will choose to accept only Information Cards whereas others will give users the choice of Information Cards or other forms of authentication.

A site that accepts Information Cards typically has a login screen that contains button with a label such as “Sign in with an Information Card” or “Log in using an Information Card”.  Upon clicking this button, the user is presented with a choice of his Information Cards that are accepted at the site, and is asked to choose one.  Once a card is selected and submitted to the site, the user is logged in and continues using the site, just as they would after submitting a username and password to a site.

Sites that accept both Information Cards and other forms of authentication present users with both an Information Card login choice and whatever other choices the site supports.  For instance, a site login screen might display both “Sign in with your username and password” and “Sign in with an Information Card” buttons.

10.4 Browser Perspective

Very little additional support is needed from today’s Web browsers to also support Information Cards.  The main addition is that they MUST recognize special HTML and/or XHTML tags for invoking the Identity Selector, pass encoded parameters on to the Identity Selector on the platform, and POST back the token resulting from the user’s choice of an Information Card.

10.5 Web Site Perspective

Web sites that employ Information Card-based authentication MUST support two new pieces of functionality:  adding HTML or XHTML tags to their login page to request an Information Card-based login and code to log the user into the site using the POSTed credentials.  In response to the Information Card-based login, the Web site typically writes the same client-side browser cookie that it would have if the login had occurred via username/password authentication or other mechanisms, and issue the same browser redirects.  Thus, other than the code directly involved with user authentication, the bulk of a Web site can remain unchanged and oblivious to the site’s acceptance of Information Cards as a means of authentication.

11.1 Syntax Alternatives:  OBJECT and XHTML tags

HTML extensions are used to signal to the browser when to invoke the Identity Selector.  However, not all HTML extensions are supported by all browsers, and some commonly supported HTML extensions are disabled in browser high security configurations.  For example, while the OBJECT tag is widely supported, it is also disabled by high security settings on some browsers, including Internet Explorer.

An alternative is to use an XHTML syntax that is not disabled by changing browser security settings.  However, not all browsers provide full support for XHTML.

To address this situation, two HTML extension formats are specified.  Browsers MAY support one or both of the extension formats.

11.1.1 OBJECT Syntax Examples

An example of the OBJECT syntax is as follows:

This is an example of a page that requests that the user log in using an Information Card.  The key portion of this page is the OBJECT of type “application/x-informationCard”.  Once a card is selected by the user, the resulting Security Token is included in the resulting POST as the xmlToken value of the form.  Appendix A shows a sample POST resulting from using a login page similar to the preceding one.  If the user cancels the authentication request, the resulting POST contains an empty xmlToken value.

Parameters of the Information Card OBJECT are used to encode the necessary WS-SecurityPolicy information in HTML.  In this example, the Relying Party is requesting a SAML 1.0 token from a Self-issued Identity Provider, supplying the requested claims “emailaddress”, “givenname”, and “surname”.  This example uses the basic protocol described in Section 2.1 (without employing a Relying Party STS).

A second example of the OBJECT syntax is as follows:

This example uses the enhanced protocol described in Section 2.3, which employs a Relying Party STS.  Note that in this case, the “issuer” points to a Relying Party STS.  The “issuerPolicy” points to an endpoint where the Security Policy of the STS (expressed via WS-SecurityPolicy) is to be obtained using WS-MetadataExchange.  Also, note that the “tokenType” parameter requests a custom token type defined by the site for its own purposes.  The “tokenType” parameter could have been omitted as well, provided that the Web site is capable of understanding all token types issued by the specified STS or if the STS has prior knowledge about the token type to issue for the Web site.

The object parameters can be set in normal script code.  This is equivalent to setting them using the “PARAM” declarations in the previous example.

11.1.2 XHTML Syntax Example

An example of the XHTML syntax is as follows:

11.2 Identity Selector Invocation Parameters

The parameters to the OBJECT and XHTML Information Card objects are used to encode information in HTML that is otherwise supplied as WS-SecurityPolicy information via WS-MetadataExchange when an Identity Selector is used in a Web services context.

11.2.1 issuer

This optional parameter specifies the URL of the STS from which to obtain a token.  If omitted, no specific STS is requested.  The special value “http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self” specifies that the token SHOULD come from a Self-issued Identity Provider.

11.2.2 issuerPolicy

This optional parameter specifies the URL of an endpoint from which the STS’s WS-SecurityPolicy can be retrieved using WS-MetadataExchange.  This endpoint MUST use HTTPS.

11.2.3 tokenType

This optional parameter specifies the type of the token to be requested from the STS as a URI.  This parameter can be omitted if the STS and the Web site front-end have a mutual understanding about what token type will be provided or if the Web site is willing to accept any token type.

11.2.4 requiredClaims

This optional parameter specifies the types of claims that MUST be supplied by the identity.  If omitted, there are no required claims.  The value of requiredClaims is a space-separated list of URIs, each specifying a required claim type.

11.2.5 optionalClaims

This optional parameter specifies the types of optional claims that MAY be supplied by the identity.  If omitted, there are no optional claims.  The value of optionalClaims is a space-separated list of URIs, each specifying a claim type that can MAY be submitted.

11.2.6 privacyUrl

This optional parameter specifies the URL of the human-readable Privacy Policy of the site, if provided.

11.2.7 privacyVersion

This optional parameter specifies the Privacy Policy version.  This MUST be a value greater than 0 if a privacyUrl is specified.  If this value changes, the UI notifies the user and allows them review the change to the Privacy Policy.

11.3 Data Types for Use with Scripting

The object used in the Information Card HTML extensions has the following type signature, allowing it to be used by normal scripting code:

11.4 Detecting and Utilizing an Information Card-enabled Browser

Web sites MAY choose to detect browser and Identity Selector support for Information Cards and modify their login page contents depending upon whether Information Card support is present, and which of the OBJECT and/or XHTML syntaxes are supported by the browser and supported by the Web site.  This allows Information Card capabilities to be shown when available to the user, and to be not displayed otherwise.

Detecting an Information Card-enabled browser may require detecting specific browser and Identity Selector versions and being aware of the nature of their Information Card support.

11.5 Behavior within Frames

When the object tag is specified in an embedded frame, the certificate of the frame is compared to that of the root frame. For this configuration to work, the scheme, domain, and security zone (for example https, microsoft.com, and Intranet) of the URL of the embedded frame MUST be the same as that of the root frame.  If they do not match, the object tag SHOULD NOT be acted upon.  This prevents a form of cross-site scripting attacks.

11.6 Invocation Using the Document Object Model (DOM)

In addition to being invokable using static HTML tags and script code, Identity Selectors can be invoked from script injected into the page using the Document Object Model [DOM].  Invocation from dynamically generated script allows the Web site’s requirements to be set dynamically.

11.7 Auditing, Non-Auditing, and Auditing-Optional Cards

·         Auditing Card:  When a managed card with an ic:RequireAppliesTo element and no Optional attribute or Optional=false attribute is used at a Web site, the Request Security Token (RST) sent to the Identity Provider contains a wsp:AppliesTo element.

·         Non-Auditing Card:  When a managed card with no ic:RequireAppliesTo element is used at a Web site, the Request Security Token (RST) sent to the Identity Provider contains no wsp:AppliesTo element.

·         Auditing-Optional Card:  When a managed card with an ic:RequireAppliesTo element with Optional=true attribute is used at a Web site, the Request Security Token (RST) sent to the Identity Provider contains a wsp:AppliesTo element.

This section adds the wsai:Identity property to an Endpoint Reference [WS-Addressing] and leverages extensibility of the wsa:EndpointReferenceType schema to include a wsai:Identity element as described below:

The wsai:Identity element inside a wsa:EndpointReference can hold any of the identity representations defined in Section 12.2 below.

12.1 Default Value

If a wsa:EndpointReference does not contain a wsai:Identity element, a DNS Name representation can be assumed by extracting the hostname from the Address URI.

If the URI does not have a hostname, it does not have an implicit identity value and can not be verified by the mechanisms defined in this document.

12.2 Identity Representation

12.2.1 DNS Name

The DNS Name representation implies that the remote principal is trusted to speak for that DNS name. For instance the DNS Name representation could specify “fabrikam.com”. When challenged, the endpoint contacted MUST be able to prove its right to speak for “fabrikam.com”. The service could prove its right by proving ownership of a certificate containing a reference to fabrikam.com and signed by a trusted Certificate Authority. The following element of type xs:string can be used to represent a DNS Name representation within a wsai:Identity element.

 

 

12.2.2 Service Principal Name

The SPN representation implies that the remote principal is trusted to speak for that SPN, a mechanism common in intranet domains.  Its format is <serviceClass>/<host>. For example, the SPN for a generic service running on “server1.fabrikam.com” would be “host/server1.fabrikam.com”. The client could confidentially speak to the service and verify replies back from the service by obtaining a Kerberos ticket from the realm’s domain controller. The following element of type xs:string can be used to represent an SPN representation within a wsai:Identity element.

 

12.2.3 User Principal Name

The UPN representation implies that the remote principal is a particular user in a domain. Its format is: <user>@<domain>. For example, the UPN for a user “someone” at a domain “example.com” would be “someone@example.com”.  A service could prove its UPN by providing the password for the user associated with “someone@example.com”. The following element of type xs:string can be used to represent a UPN representation within a wsai:Identity element.

 

12.2.4 KeyInfo

This identity value is similar to the previous three, but rather than describing an attribute of the target, this mechanism describes a reference (embedded or external) to key material associated with the target. This allows confirmation of the target trust identity through encryption. These values can also be used to compare authenticated identities similar to the basic trust identity values by comparing the hash of the specified trust identity value with a hash of the authenticated identity of the service. The ds:KeyInfo element defined in [XMLDSIG] can be used.

 

12.2.4.1 Example specifying an RSA Public Key

The PublicKey representation states the public key of the remote principal.  A service could prove its ownership of the key by signing some data with the private key.

 

12.2.4.2 Example specifying an X509 Certificate

This example shows a certificate of the remote principal being used as the identity value.

 

 

12.2.5 Security Token

A security token can be an identity value representing statements about the identity of an endpoint. E.g.:

 

12.2.6 Security Token Reference

Similarly to ds:KeyInfo, wsse:SecurityTokenReference element can be used within a wsai:Identity element to reference a token representing a collection of statements about the identity of an endpoint. E.g.:

           

13.1 Protection of Information Cards by Identity Selectors

It is RECOMMENDED that Identity Selectors encrypt or otherwise secure the Information Card data held by them to help protect cards from being stolen and then used by an attacker.  This is particularly important for self-issued Information Cards, where possession of the unencrypted contents of a card could enable an attacker to gain access to Relying Parties accounts associated with that card.

13.2 Relying Parties Without Certificates

Because claims sent to relying parties without certificates are not encrypted, it is RECOMMENDED that sensitive claims not be released to these relying parties.  Identity Providers holding sensitive user data that can be released as claim values are encouraged to issue cards containing an ic07:RequireStrongRecipientIdentity element to prevent transmission of sensitive claim values over an unencrypted channel.

13.3 Endpoint References

It is RECOMMENDED that Endpoint Reference elements be signed to prevent tampering.

An Endpoint Reference SHOULD NOT be accepted unless it is signed and have an associated security token to specify the signer has the right to “speak for” the endpoint. That is, the relying party SHOULD NOT use an endpoint reference unless the endpoint reference is signed and presented with sufficient credentials to pass the relying parties acceptance criteria.

It is RECOMMENDED that an endpoint reference be encrypted when it contains claims and other sensitive information.

When included in a SOAP message, endpoint references are RECOMMENDED to be protected using the mechanisms described in WS-Security [WS-Security]

An implementation conforms to this specification if it satisfies all of the MUST or REQUIRED level requirements defined within this specification for the portions of the specification implemented by that implementation.  Furthermore, when an implementation supports functionality in which there is a RECOMMENDED algorithm or set of parameter choices, conforming implementations MUST support the RECOMMENDED algorithm and parameter choices.  A SOAP Node MUST NOT use the XML namespace identifiers for this specification (listed in Section 1.2) within SOAP Envelopes unless it is compliant with this specification.

This specification references a number of other specifications.  In order to comply with this specification, an implementation MUST implement the portions of referenced specifications necessary to comply with the required provisions of the portions of this specification that it implements. Additionally, the implementation of the portions of the referenced specifications that are specifically cited in this specification MUST comply with the rules for those portions as established in the referenced specification.

Additionally, normative text within this specification takes precedence over normative outlines (as described in Section 1.1), which in turn take precedence over the XML Schema [XML Schema Part 1, Part 2] and WSDL [WSDL 1.1] descriptions. That is, the normative text in this specification further constrains the schemas and/or WSDL that are part of this specification; and this specification contains further constraints on the elements defined in referenced schemas.

If an OPTIONAL message is not supported, then the implementation SHOULD Fault just as it would for any other unrecognized/unsupported message. If an OPTIONAL message is supported, then the implementation MUST satisfy all of the MUST and REQUIRED sections of the message.

The contents of an HTTPS POST generated by a page like the first example in Section 4.1.1 follow:

An un-escaped and reformatted version of the preceding xmlToken value, with the encrypted value elided, is as follows:

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Original Authors of the initial contributions:

Arun Nanda, Microsoft Corporation

Michael B. Jones, Microsoft Corporation

Jan Alexander, Microsoft

Giovanni Della-Libera, Microsoft

Martin Gudgin, Microsoft

Kirill Gavrylyuk, Microsoft

Tomasz Janczuk, Microsoft

Michael McIntosh, IBM

Anthony Nadalin, IBM

Bruce Rich, IBM

Doug Walter, Microsoft

Participants:

John Bradley, Individual

Norman Brickman, Mitre Corporation

Jeffrey Broberg, CA

Scott Cantor Internet2

Ruchith Fernando, WSO2

Marc Goodner, Microsoft Corporation (Chair)

Patrick Harding, Ping Identity

Andrew Hodgkinson, Novell

Mario Ivkovic, A-SIT, Zentrum für Sichere Informationstechnologie - Austria

Michael B. Jones, Microsoft Corporation (Editor)

Mike Kirkwood, Polka Networks

Herbert Leitold, A-SIT, Zentrum für Sichere Informationstechnologie - Austria

Michael McIntosh, IBM (Editor)

Dale Olds, Novell

Anthony Nadalin, IBM (Chair)

Drummond Reed, Cordance

Bruce Rich ,IBM

Darran Rolls, SailPoint Technologies

Prabath Siriwardena, WSO2