The scope of the work of the TC.
The TC will accept as input the August 2008 Identity Selector Interoperability Profile specification [1] and associated guides [2][3] as published by Microsoft, the August 2008 Web Services Addressing Endpoint References and Identity specification [4] published by Microsoft and IBM, and the OSIS (Open Source Identity Systems) Feature Tests [5] published by Identity Commons (the Input documents).
Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit insofar as they conform to this charter. OASIS members with extensive experience and knowledge in these areas are particularly invited to participate.
The following sub-sections describe the charter of the Identity Metasystem Interoperability (IMI) TC with respect to these areas. The scope of the TC's work is to continue further refinement and finalization of the Input Documents to produce specifications that standardize the concepts and XML Schema renderings of the areas described below in a form that is backward compatible with the input documents.
First Phase of TC Work
The TC shall focus its initial activity on producing an Identity Selector Interoperability Profile and the supporting WS-Addressing Endpoint References and Identity specification. This is to be done in parallel with work on interoperability testing described in Ongoing Work below. Upon publication of the initial work, which is required to promote the interoperability testing work, the TC shall begin its second phase work below.
Identity Selector Interoperability Profile
This profile defines an interoperable Information Card format and associated identity system components that allow users to manage their digital identities from different identity providers, and employ them in various contexts to access online services.
Information Card Format
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 multiple and 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. A user controls her Information Cards through a software interface referred to as an Identity Selector.
Information Cards contain the following information:
-
A language identifier to describe which language localizable elements have been localized.
-
A reference identifier to provide a specific reference for a card by which it can be uniquely identified within the scope of an issuer
-
A card name that is a friendly textual name for an issued Information Card.
-
An image element that contains a base64 encoded inline image that provides a graphical image for the issued Information Card, including MIME type information for the type of image format.
-
An issuer element that provides a logical name for the issuer of the Information Card.
-
Elements to indicate when an Information Card was issued and when it expires.
-
An element to specify an identity provider's supported token services as a list. This is an ordered list of Identity Provider (IP) / Security Token Service (STS) endpoints, and the corresponding credential type to be used, for requesting tokens. For each endpoint, the required credential type implicitly determines the authentication mechanism to be used. Each IP/STS endpoint reference in the Information Card includes the security policy metadata for that endpoint.
-
An element to specify an identity provider's supported token types as a list.
-
An element to provide information that identifies the relying party where issued tokens for the Information Card will be used.
-
An element to describe the supported claim types offered including display and description information about the claim type.
-
An element to indicate the location and version of the privacy statement of the identity provider.
-
Extensibility points to support future enhancements to the Information Card format.
Information Card Transfer Format
This profile will define how collections of Information Cards are transferred between identity selectors. Rules are also defined that cover the portability of content in Information Cards through the use of defined extensibility points.
Information Card Issuance
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. The signature on the digitally signed envelope provides data origin authentication assuring the user that it came from the right identity provider. The specification will describe a specific profile of XML Digital Signatures [6] that must be used to sign the envelope carrying the Information Card. An identity selector must verify the enveloping signature. The Information Card can then be extracted and stored in the Information Card collection.
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 using the "issuance binding" of WS-Trust [7].
When requesting a security token from the IP/STS, an Identity Selector includes the Information Card reference element, and all of its content, in the body of the Request Security Token (RST) message as a top-level element. Generally an Identity Selector should not send token scope information to an identity provider to protect user privacy. When scope information is required by the identity provider this profile defines rules for the behavior of the identity selector. The profile also defines rules for use of client pseudonyms as PPIDs and the use of proof keys for issued tokens.
This profile also defines an element that an Identity Selector may use as a top level element in an RST to request a display token. A display token contains a representation of the claims carried in the issued token that can be displayed in a user interface.
Identity Provider Requirements
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. These include, but are not limited to, Username/Password, Kerberos, X.509 (WSS Security Token Profiles [8]) and self issued tokens (see below).
Identity Providers must make their security policy available at a URL using the HTTPS scheme. An Identity Selector may retrieve this policy using the mechanisms defined in WS-MetadataExchange [9].
A policy assertion is defined to indicate that Information Cards, representing identities that may be federated, must be pre-provisioned before token requests can be made of the identity provider. This assertion is used in the IP/STS policy metadata.
This profile also defines SOAP faults for use in error situations by an Identity Provider.
Relying Party Requirements
A relying party specifies its security token requirements as part of its security policy using the primitives and assertions defined in WS-SecurityPolicy [10]. The claims requirement of a relying party can be expressed in its token policy by using the optional Claims parameter defined in WS-Trust. However, the Claims parameter has an open content model. This profile defines the ClaimType element for use as a child of the Claims element.
This profile also defines SOAP faults for use in error situations by a Relying Party.
Self Issued Identity Provider
The profile defines a simple identity provider, called the "Self Issued Identity Provider" (SIP). This is an identity provider 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. 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 re-register at a relying party when switching identity selectors. This profile defines the characteristics and behaviors of Self Issued Identity Providers and self issued tokens.
Invoking Identity Selectors from Web Pages
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. An alternative is to use an XHTML syntax . However, not all browsers provide full support for XHTML. Two HTML extension formats are specified, the OBJECT tag and XHTML. Both share the same set of optional parameters:
-
issuer: the URL of the STS from which to obtain a token.
-
issuerPolicy, the URL of an endpoint from which the STS's WS-SecurityPolicy can be retrieved using WS-MetadataExchange. This endpoint must use HTTPS.
-
tokenType: 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.
-
requiredClaims: specifies the types of claims that must be supplied by the identity. If omitted, there are no required claims.
-
optionalClaims: specifies the types of optional claims that may be supplied by the identity. If omitted, there are no optional claims.
-
privacyUrl: specifies the URL of the human-readable privacy policy of the site, if provided.
-
privacyVersion: specifies the privacy policy version. This must be a value greater than 0 if a privacyUrl is specified. If this value changes, the Identity Selector UI notifies the user and allows them review the change to the privacy policy.
The data types of these parameters are also defined for use with scripting.
WS-Addressing Endpoint References and Identity
This specification provides a mechanism to describe security-verifiable identity for endpoints by leveraging extensibility of the WS-Addressing [11] specification.
An element is defined for representing identity (as nested elements) that can be provided as part of a WS-Addressing Endpoint Reference. Elements are defined to identity claims for DNS name, Service Principal Name, User Principal Name and Key Info.
These mechanisms enable 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. These elements are used within Identity Metasystem components but are also of broader applicability.
Second Phase of TC Work
The claim types defined in phase one must work with the Information Card format but should also compose with other claim type dialects, e.g. the common claims dialect defined in WS-Federation [12]. The TC will need to investigate integrating other claim dialects into the Information Card model. The TC may also look into issues around using specific sources of data, e.g. LDAP or other network level information, as claims.
The TC may also work on enhancements to the object tag described above, e.g. to improve the display of Information Cards on web sites.
The TC may also work on improving how Information Cards can be used across a number of different devices, or roamed, beyond the export format defined above. This may require utilizing extensibility points in the protocols already in use or potentially new protocols.
Utilizing the Trust 1.4 challenge/negation features and profiling schema for specific tokens used with Information Cards are also areas of interest for the second phase of TC work.
Ongoing TC Work
The TC shall focus on interoperability test definitions and runs to validate its work on an ongoing basis. The TC will determine the feature areas to test and the specific interoperability scenarios. Initially this work shall focus on the first phase deliverables defined above. The TC is encouraged to use the OSIS Feature Tests as a basis for this work. When the TC begins its second phase of work new tests will need to be defined to support it.
The TC shall also consider and assist in the work of other related OASIS TCs on an ongoing basis as agreed by the TC membership, e.g. assisting in the SAML Information Card Profile [13] definition and ensuring that the IMI work composes properly.
General Notes on Scope
The output specifications will uphold the basic principles of other Web services specifications of independence and composition and be composable with the other specifications in the Web services architecture, such as the specifications listed in the References section. Each of the protocol elements will use implementation and language neutral XML formats defined in XML Schema [14].
The following is a non-exhaustive list. It is provided only for the sake of clarity. If some function, mechanism or feature is not mentioned here, and it is not mentioned in the Scope of Work section either, then it will be deemed to be out of scope.
The TC will not define a mapping of the functions and elements described in the specifications to any programming language, to any particular messaging middleware, nor to specific network transports.
Out of Scope
The following items are specifically out of scope of the work of the TC:
-
Definition of the form and content of privacy statements.
-
The establishment of trust between two or more business parties.
-
Definition of new key derivation algorithms.
-
Definition of claim type transformation rules or mappings to other formats
The TC will not attempt to define concepts or renderings for functions that are of wider applicability including but not limited to:
-
Addressing
-
Policy language frameworks and attachment mechanisms
-
Reliable message exchange
-
Transactions and compensation
-
Secure Conversations
-
Metadata Exchange
-
Resource Transfer
Where required these functions are achieved by composition with other Web services specifications.
The TC will not attempt to define functionality duplicating that of any normatively referenced specification in the input specifications.
