SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| OASIS Identity Metasystem Interoperability TC Advances Information Card Use. |
Contents
OASIS has announced the formation of a new Identity Metasystem Interoperability (IMI) Technical Committee, chartered to increase the quality and number of interoperable implementations of Information Cards and associated identity system components to enable the Identity Metasystem. The goal of IMI is to provide the interoperability support that will enable Information Card use to become ubiquitous.
The first meeting of the TC will be held as a F2F on September 29 2008 at Ditton Manor, UK, co-located with the OASIS Standards Forum 2008, "Security Challenges for the Information Society." The IMI TC will be affiliated with the IDTrust Member Section and will operate under the OASIS 'RF (Royalty Free) on RAND Terms' IPR mode. Initial TC members include representatives from A-SIT, Zentrum für sichere Informationstechnologie Austria, CA, Cordance, IBM, Internet2, Microsoft, Mitre, Novell, Polka Networks, and WSO2.
According to one of the key Microsoft specifications to be contributed as input to the IMI TC, "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. The Information Cards provide visual representations of Digital Identities for the end user. This profile constrains the schema elements/extensions used by the Information Card Model, and behaviors for conforming relying parties, Identity Providers, and Identity Selectors."
The Implementer's Guide input document: "Digital Identities are used to authenticate parties to each other in the online world. Knowing, with a high degree of assurance, who one is interacting with is a key element in deciding whether to trust the other party and for what... A Digital Identity of a Subject is defined as a set of Claims asserted by a Claims Authority about the Subject. Claims are communicated in signed Security Tokens, and may represent identifying and other personal information about a Subject... The Information Card Model allows users to manage a portfolio of Digital Identities from various authorities, and employ them in various contexts where they are accepted to access online services. The model embodies the patterns and messages of WS-Trust, but can be implemented using lightweight protocols like HTTP POST as well as the SOAP-based WS protocols. A crucial application for this model is to establish a framework in which consumers of user identities can ask for exactly what they need, and providers of identities can furnish the needed identity with intermediation by the user when appropriate..."
"In the Identity Metasystem, identities are represented to users as Information Cards which enable users to manage their digital identities from different identity providers and employ them in various contexts to access online services. Information Cards have a number of characteristics that help to improve user privacy and security when accessing online services. Broad interoperability across platforms and services is needed so that Information Card support is ubiquitous to realize the goals of the Identity Metasystem."
Specifications, schemas, and interoperability guides produced by the IMI Technical Committee are expected to be valuable for several audiences, including: (1) vendors offering Web services products; (2) Telecom providers with identity enabled communication enabled telecom services; (3) other specification authors that need identity capabilities for Web services; (4) software architects and programmers, who design, write or integrate applications for Web services; (5) end users implementing Web services-based solutions that require identity based mechanisms.
As defined in the IMI TC 'Scope', five specifications will be accepted as 'Input Documents,'
where TC work will continue further refinement and finalization of these Input Documents to produce specifications that standardize the concepts and XML Schema renderings in a manner that is backward compatible with the input documents. Other contributions and changes to the input documents will be accepted for consideration insofar as they conform to the charter. The five principal contributions are:
- Identity Selector Interoperability Profile V1.5. Microsoft Corporation. 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.
- Interoperability Profile V1.5 within Web Applications and Browsers. Microsoft Corporation. This paper documents the Web interfaces utilized by browsers and Web applications that support the Identity Metasystem; the information in this document is not specific to any one browser or platform.
- An Implementer's Guide to the Identity Selector Interoperability Profile V1.5. Microsoft Corporation and Ping Identity Corporation. The mechanisms described in this document elaborate on the Identity Selector Interoperability Profile Version 1.5. The interactions between a conforming Identity Selector and a Relying Party or an Identity Provider are illustrated, and the message exchanges with an Identity Provider are described in detail.
- Application Note: Web Services Addressing Endpoint References and Identity. Microsoft and IBM. This note provides a mechanism to describe security-verifiable identity for endpoints by leveraging extensibility of the WS-Addressing specification; Web Services Addressing Identity extends WS-Addressing's endpoint reference by providing identity information about the endpoint that can be verified through a variety of security means.
- OSIS (Open Source Identity Systems) Feature Tests. Identity Commons. Interop tests relevant to an identity layer for the Internet from open-source and commercial participants, including interoperability work for Information Card.
Specifications to be developed by the IMI TC address functionality required for user-centric identity that is not addressed in other security related activities. The IMI TC will be informed by the related work that includes
- Info Card Foundation (ICF) — a group of thoughtful designers, architects, and companies who want to make the digital world easier by building better products that help control of users personal information [see: Information Card Foundation (ICF)]
- OSIS (Open Source Identity Systems), where many identity related projects that are both open-source and commercial use this forum for defining tests and identifying public forums to demonstrate interoperability, particularly around Information Cards
- OpenID, a decentralized framework for a shared identity service to allow Internet users to log on to many different web sites using a single digital identity
- Project Concordia, an initiative designed to drive interoperability across identity protocols in use today
- Higgins, an open source framework for integratein identity, profile, and relationship information across multiple heterogeneous systems
- ITU-T SG 17 and SG 13, conducting work relating to digital wallet interoperability platform, entity authentication and common IdM data model, addressing especially NGN interoperability, threats and security
An excellent introduction to key elements of the Identity Metasystem is found in the IMI TC Charter itself (Scope), and especially in these sections:
Deliverables identified in the IMI TC's charter include (1) a revised Identity Selector Interoperability Profile Version 1.6 set of specifications and associated Schemas.; (2) A revised Web Services Addressing Endpoint References and Identity specification and associated Schemas; (3) Any Interoperability Guides targeted for completion within eighteen (18) months from the time of the first TC meeting.
IMI TC work is expected to take place in two phases. In Phase 1 the TC will 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. Upon publication of the initial work, which is required to promote the interoperability testing work, the TC begin its second phase work.
For Phase 2: claim types defined in Phase 1 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. 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 seek to improve upon how Information Cards can be used across a number of different devices, or roamed, beyond the defined export format.
As chartered, the OASIS Identity Metasystem Interoperability (IMI) Technical Committee will accept as input the following five specifications:
Identity Selector Interoperability Profile V1.5. Authors: Arun Nanda (Microsoft Corporation) and Michael B. Jones (Microsoft Corporation). July 2008. 60 pages. Copyright © 2006-2008 Microsoft Corporation. From the reference page ('August, 2008'). With XML Schema (XSD). The Identity Selector Interoperability Profile V1.5 is backwards compatible with V1.0. See Identity Selector Interoperability Profile specification and companion guides, Version 1.0.
Abstract: "This document is intended for developers and architects who wish to design identity systems and applications that interoperate using the Identity Selector Interoperability Profile V1.5. 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." Definition: 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.
Note, from the Microsoft web site, "Identity Selector Interoperability Profile Specification and Companion Guides," a.k.a. Information Card profile documents: "These documents are intended for people building software that implements any of the roles in the Information Card ecosystem. Namely: Identity Providers to issue cards, Relying Parties to accept cards, and Identity Selectors to put the person in control by enabling them to employ Information Cards when and where they choose. They are also intended for those who want to look under the hood and understand how it all works... Interoperability Profile V1.5 within Web Applications and Browsers. Author: Michael B. Jones (Microsoft Corporation). July 2008. 15 pages. Copyright © 2006-2008 Microsoft Corporation. From the reference page ('August, 2008').
Abstract: "The Identity Metasystem allows users to manage their Digital Identities from various Identity Providers and employ them in different contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as 'Information Cards' (a.k.a. InfoCards). One important class of applications where Information Cards can be used is applications hosted on Web sites and accessed through Web browsers. This paper documents the Web interfaces utilized by browsers and Web applications that support the Identity Metasystem. The information in this document is not specific to any one browser or platform.
This document supplements the information provided in two other Identity Selector Interoperability Profile references: the Identity Selector Interoperability Profile V1.5, which provides the normative schema definitions and behaviors for Information Cards and the interoperable Identity Selectors that use them and An Implementer's Guide to the Identity Selector Interoperability Profile V1.5, which provides a non-normative description of the overall Information Card Model." An Implementer's Guide to the Identity Selector Interoperability Profile V1.5. Authors: Microsoft Corporation and Ping Identity Corporation. July 2008. 83 pages. Copyright © 2006-2008 Microsoft Corporation. From the reference page ('August, 2008').
Abstract: This document is intended for developers and architects who wish to design identity systems and applications that interoperate using the Identity Selector Interoperability Profile V1.5 built upon the mechanisms described in Web Services Trust Language (WS-Trust), WS-Trust 1.3, Web Services Security Policy Language (WS-SecurityPolicy), Version 1.1, and WS-SecurityPolicy 1.2. An Identity Selector and the associated identity system components using the Information Card Model allow users to manage their Digital Identities from different Identity Providers, and employ them in various contexts to access services.
The mechanisms described in this document elaborate on the Identity Selector Interoperability Profile V1.5. The interactions between a conforming Identity Selector and a Relying Party or an Identity Provider are illustrated, and the message exchanges with an Identity Provider are described in detail. This document is intended to be read alongside the document entitled Identity Selector Interoperability Profile V1.5 which specifies the normative profile of the definitions and behaviors referenced by this document. Additionally, A Guide to Using the Identity Selector Interoperability Profile V1.5 within Web Applications and Browsers describes how Information Cards can be used within applications hosted on web sites and accessed through web browsers." Application Note: Web Services Addressing Endpoint References and Identity. Authors: 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). August 26, 2008. 7 pages. Copyright © 2001-2008 International Business Machines Corporation and Microsoft Corporation. From the reference document Application Note: Web Services Addressing Endpoint References and Identity (WS-AddressingAndIdentity), 'August 2008', [where] "This document describes a directory of links to resources related to WS-AddressingAndIdentity. This version is an errata from the previous version that corrects element names and provides schema." With XML Schema (XSD). Canonical source: http://schemas.xmlsoap.org/ws/2006/02/addressingidentity/WS-AddressingAndIdentity.pdf.
Abstract: "This note provides a mechanism to describe security-verifiable identity for endpoints by leveraging extensibility of the WS-Addressing specification [Web Services Addressing 1.0 — Core, W3C Recommendation]. Specifically, this note introduces XML (XML 1.0, XML Namespaces) elements for identity that can be provided as part of WS-Addressing Endpoint Reference. 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."
A Web service endpoint is a (referenceable) entity, processor, or resource where Web service messages can be targeted. WS-Addressing's Endpoint references convey the information needed to reference a Web service endpoint, and may be used in several different ways: endpoint references are suitable for conveying the information needed to access a Web service endpoint, but are also used to provide addresses for individual messages sent to and from Web services.
Web Services Addressing Identity extends WS-Addressing's endpoint reference by providing identity information about the endpoint that can be verified through a variety of security means. These means include transport security technologies like HTTPS or the wealth of WS-Security specifications... OSIS (Open Source Identity Systems) Feature Tests published by Identity Commons. "OSIS (Open Source Identity Systems) "brings together many identity-related projects and synchronizes and harmonizes the construction of an interoperable identity layer for the Internet from open-source and commercial parts. Current projects [2008-09] include interoperability work for both Information Card and OpenID implementations.
Participants (Individuals, Companies, and Organizations) taking part in OSIS Interop events worked on I4 from May 2008 through September 8-10, 2008 "to test features of their user-centric identity software implementations, with the goal of testing the interoperability of both OpenID and Information Card software solutions and helping implementers improve their implementations. I4 builds on the results obtained in I3, but focuses primarily on feature tests, rather than cross-solution results." The I4:Overall Results available online include I4:Information Card Identity Selector FeatureTest Results, I4:Information Card Browser Add-On FeatureTest Results, I4:Information Card Relying Party FeatureTest Results, and I4:Information Card Identity Provider FeatureTest Results. Specific branded software products and services participating in a given role in an interop event are identified.
Charter Table of Contents
OASIS Identity Metasystem Interoperability (IMI) Technical Committee
(1) The Charter of the TC, which includes only the following items:
(1)(a) The Name of the TC
OASIS Identity Metasystem Interoperability (IMI) Technical Committee
(1)(b) Purpose
A statement of purpose, including a definition of the problem to be solved:
The purpose of the Identity Metasystem Interoperability (IMI) Technical
Committee (TC) is to increase the quality and number of interoperable
implementations of Information Cards and associated identity system components
to enable the Identity Metasystem. In the Identity Metasystem, identities are
represented to users as "Information Cards." Information Cards enable users to
manage their digital identities from different identity providers and employ
them in various contexts to access online services. Information Cards have a
number of characteristics that help to improve user privacy and security when
accessing online services. Broad interoperability across platforms and services
is needed so that Information Card support is ubiquitous to realize the goals of
the Identity Metasystem.
(1)(c) Scope
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 TC 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.
(1)(d) Deliverables
A list of deliverables, with projected completion dates:
The TC has the following set of deliverables:
A revised Identity Selector Interoperability Profile v1.6 set of
specifications and associated Schemas. A Committee Specification is scheduled
for completion within 12 months of the first TC meeting. A revised Web Services Addressing Endpoint References and Identity
specification and associated Schemas. A Committee Specification is scheduled for
completion within 12 months of the first TC meeting. Any Interoperability Guides expected in 18 months from the first TC meeting.
These specifications will reflect refinements, corrections or material
technological improvements with respect to the input documents and in accordance
with this charter.
Ratification of the above specifications as OASIS standards, including a brief
period to address any errata will mark the end of the TC's lifecycle. The TC may
decide to recharter when complete to continue maintenance activities on an
ongoing basis rather than permanently disband.
****** References ******
[1] Identity Selector Interoperability Profile V1.5, August 2008
http://schemas.xmlsoap.org/ws/2005/05/identity
[2] A Guide to Using the Identity Selector Interoperability Profile V1.5 within Web Applications and Browsers, August 2008
http://schemas.xmlsoap.org/ws/2005/05/identity
[3] An Implementer's Guide to the Identity Selector Interoperability Profile V1.5, August 2008
http://schemas.xmlsoap.org/ws/2005/05/identity
[4] Application Note: Web Services Addressing Endpoint References and Identity, August 2008
http://schemas.xmlsoap.org/ws/2006/02/addressingidentity
[5] OSIS (Open Source Identity Systems) Feature Tests
http://osis.idcommons.net/wiki/Category:I4_FeatureTests
[6] XML-Signature Syntax and Processing, W3C Recommendation, 2002
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
[7] WS-Trust 1.3, OASIS Standard, March 2007
http://docs.oasis-open.org/ws-sx/ws-trust/200512
WS-Trust 1.4, OASIS Committee Draft, June 2008
http://docs.oasis-open.org/ws-sx/ws-trust/200802
[8] OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), OASIS Standard, March 2004
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004), OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
Web Services Security: UsernameToken Profile, OASIS Standard, March 2004
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
Web Services Security: UsernameToken Profile 1.1, OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf
Web Services Security X.509 Certificate Token Profile, OASIS Standard, March 2004
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf
Web Services Security X.509 Certificate Token Profile, OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf
Web Services Security Kerberos Token Profile 1.1, OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf
Web Services Security: SAML Token Profile, OASIS Standard, December 2004
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
Web Services Security: SAML Token Profile 1.1, OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf
Web Services Security Rights Expression Language (REL) Token Profile, OASIS Standard, December 2004
http://docs.oasis-open.org/wss/oasis-wss-rel-token-profile-1.0.pdf
Web Services Security Rights Expression Language (REL) Token Profile 1.1, OASIS Standard, February 2006
http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token-profile-1.1.pdf
[9] Web Services Metadata Exchange (WS-MetadataExchange), Version 1.1, August 2006
http://specs.xmlsoap.org/ws/2004/09/mex
[10] WS-SecurityPolicy 1.2, OASIS Standard, December 2006
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
WS-SecurityPolicy 1.3, OASIS Committee Draft, June 2007
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/
[11] "Web Services Addressing (WS-Addressing)", W3C Recommendation May 2006
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509
[12] WS-Federation, OASIS Committee Draft, June 2008
http://docs.oasis-open.org/wsfed/federation/200706
[13] SAML Information Card Profile, Editor Draft
http://www.oasis-open.org/committees/download.php/28626/draft-sstc-saml2-infocard-01.pdf
[14] XML Schema Part 1: Structures Second Edition, W3C Recommendation, October 2004
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
XML Schema Part 2: Datatypes Second Edition, W3C Recommendation, October 2004
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
(1)(e) IPR Mode
Specification of the IPR Mode under which the TC will operate:
This TC will operate under the "RF (Royalty Free) on RAND Terms" IPR Mode as
defined in the OASIS Intellectual Property Rights (IPR) Policy, effective 15-April-2005.
(1)(f) Audience
The anticipated audience or users of the work:
- Vendors offering Web services products
- Telecom providers with identity enabled communication enabled telecom services
- Other specification authors that need identity capabilities for Web services
- Software architects and programmers, who design, write or integrate applications for Web services
- End users implementing Web services-based solutions that require identity based mechanisms
(1)(g) Language
The language in which the TC shall conduct business.
This TC will use English as the language for conducting its operations.
(2) Non-Normative Information
Non-normative information regarding the startup of the TC
(2)(a) Similar or Applicable Work
Identification of similar or applicable work that is being done in other
OASIS TCs or by other organizations, why there is a need for another effort in
this area and how this proposed TC will be different, and what level of liaison
will be pursued with these other organizations.
The IMI TC will be performing new work activities that are currently not covered by any other OASIS TC.
The TC co-chairs will coordinate closely with other bodies in order to inform
them about the progress of the work and also in order to count on their
expertise in the development of the work.
*** Related Work ***
Similar Work
The specifications developed by the IMI TC address functionality required for
user centric identity that is not addressed in other security related
activities. The IMI TC will be informed by the following:
Info Card Foundation (ICF)
http://www.informationcard.net/
The Information Card Foundation is a group of thoughtful designers, architects,
and companies who want to make the digital world easier by building better
products that help control of users personal information. OSIS
http://osis.idcommons.net/wiki/Main_Page
Many identity related projects that are both open-source and commercial use this forum for defining tests and identifying public forums to demonstrate interoperability, particularly around Information Cards. OpenID
http://openid.net/
OpenID is a decentralized framework for a shared identity service to allow Internet users to log on to many different web sites using a single digital identity. Concordia
http://projectconcordia.org/
Project Concordia is an initiative designed to drive interoperability across identity protocols in use today. Higgins
http://www.eclipse.org/higgins/
An open source framework for integratein identity, profile, and relationship information across multiple heterogeneous systems ITU-T SG 17 and SG 13
http://www.itu.int/ITU-T/
In ITU-T SG 17 there are work relating to digital wallet interoperability platform, entity authentication and common IdM data model. In ITU-T SG 13, Q15/13 addresses NGN interoperability, threats, and security.
The proposers of this TC recognize there are other possible approaches to user
centric identity and believe that the defined Scope of Work of this TC addresses
many functional use cases of these parallel efforts. The proposers of this TC
seek involvement from authors of other such activities and the contribution of
their expertise and experience, and intend to work in harmony with them in the
creation of the product of this technical committee.
Applicable Work
The TC may decide to establish liaisons with other groups as needed.
Responsibilities for such liaison will be defined by the TC at that time.
(2)(b) First Meeting
The date, time, and location of the first meeting, whether it will be
held in person or by phone, and who will sponsor this first meeting. The first
meeting of a TC shall occur no less than 30 days after the announcement of its
formation in the case of a telephone or other electronic meeting, and no less
than 45 days after the announcement of its formation in the case of a
face-to-face meeting.
September 29th 2008 2pm — 5pm Ditton Manor, UK (Co-located at OASIS Standards Forum 2008: Security Challenges for the Information Society). A dial-in bridge will be made available,
sponsored by Nortel.
(2)(c) Meeting Schedule
The projected ongoing meeting schedule for the year following the
formation of the TC, or until the projected date of the final deliverable,
whichever comes first, and who will be expected to sponsor these meetings.
It is anticipated the IMI Technical Committee will meet via teleconference every
week at a time determined by the TC members during the TC's first meeting.
It is anticipated that the IMI Technical Committee will meet face to face every
quarter at a time and location to be determined by the TC members.
Actual pace of face to face and teleconference meetings will be determined by TC
members.
One of the proposers, as listed below, will sponsor the teleconferences unless
other TC members offer to donate their own facilities. If no other TC proposers
offer to sponsor teleconference facilities, Microsoft, IBM, or Nortel will donate
their facilities. If OASIS establishes a phone bridge system as is being
discussed, the TC will consider use of that bridge system.
(2)(d) Proposers
The names, electronic mail addresses and membership affiliations of at least Minimum Membership who support this proposal and are committed to the Charter and projected meeting schedule.
(2)(e) Convenor
The name of the Convenor who must be an Eligible Person.
Abbie Barbir, Nortel
(2)(f) Affiliated Member Section
The name of the Member Section with which the TC intends to affiliate with:
The TC will be affiliated with the IDTrust Member Section.
(2)(g) Existing Technical Work
Optionally, a list of contributions of existing technical work that the proposers anticipate will be made to this TC.
Documents are listed below:
[1] Identity Selector Interoperability Profile V1.5, August 2008
http://schemas.xmlsoap.org/ws/2005/05/identity
[2] A Guide to Using the Identity Selector Interoperability Profile V1.5 within Web Applications and Browsers, August 2008
http://schemas.xmlsoap.org/ws/2005/05/identity
[3] An Implementer's Guide to the Identity Selector Interoperability Profile V1.5, August 2008
http://schemas.xmlsoap.org/ws/2005/05/identity
[4] Application Note: Web Services Addressing Endpoint References and Identity, August 2008
http://schemas.xmlsoap.org/ws/2006/02/addressingidentity
(2)(h) FAQ Document
Optionally, a draft Frequently Asked Questions (FAQ) document regarding
the planned scope of the TC, for posting on the TC's website.
[None]
(2)(i) Working Titles
Optionally, a proposed working title and acronym for the specification(s) to be developed by the TC.
[None]
Boston, MA, USA. September 23, 2008.
OASIS, the international open standards consortium, has formed a new group to enable the use of Information Cards to universally manage personal digital identities. The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards. A rapidly-developing, Web 2.0-friendly method for shared light authentication, Information Cards let people authenticate themselves on multiple web sites without maintaining passwords for each site.
Information Cards offer tremendous potential for people to access online services with greater privacy, security, and ease. To realize the full benefits of Information Cards, however, broad interoperability across platforms and services is crucial. The goal of IMI is to provide the interoperability support that will enable Information Card use to become ubiquitous.
Each Information Card provides a visual snapshot of a person's digital identity and a description of the individual's relationship to the provider that issued the card. A person may have a collection of Information Cards from various providers. Individuals organize their Information Cards through an Identity Selector and choose which card they want to use for each type of online interaction.
"IMI will assure the portability of Information Card content by defining a standard method of transferring collections of Information Cards between Identity Selectors," explained Abbie Barbir of Nortel, convenor of the OASIS IMI Technical Committee. "Our work has relevance for many Web 2.0 use cases as well as a host of consumer and corporate applications."
The new Committee intends to base its work on contributed specifications including the Identity Selector Interoperability Profile from Microsoft, the Web Services Addressing Endpoint References and Identity specification from IBM and Microsoft, and the OSIS (Open Source Identity Systems) Feature Tests from Identity Commons.
"We're very excited to have the IMI work advanced through OASIS," noted James Bryce Clark, director of standards development at OASIS. "The new Committee brings together a truly impressive array of commercial and open source providers in the identity space. They're putting aside competitive differences in an effort to develop what is essentially a key semantic capability that everybody needs."
IMI will be offered for implementation on a royalty-free basis. Participation in the OASIS IMI Technical Committee remains open to all interested parties. Archives of the work will be accessible to both members and non-members, and OASIS will offer a mechanism for public comment. The first meeting will be held September 29, 2008, near London, in conjunction with the OASIS Security Standards Forum.
Support for IMI
CA
"We believe that the formation of the OASIS IMI Technical Committee is a critical step in the evolution and success of a new paradigm. CA recognizes the importance of a user-centric Identity Metasystem and will work with other industry leaders to move this paradigm forward," said Jeffrey Broberg, Senior Director, Security Product Management at CA.
Microsoft
"It's exciting that so many companies and projects have come together to standardize the protocols and data formats for interoperable Information Cards. The OASIS technical committee will build on the substantial interoperability work done within OSIS and apply the lessons learned there. All this will help bring the benefits of claims-based digital identity to enterprises and the Internet, on any platform and on any device," said Kim Cameron, chief architect of identity at Microsoft.
Novell
"Information Card systems provide an important advancement to online identity capabilities. Such systems can increase users' understanding and convenience in online transactions, while giving them better privacy and security. Both Novell and OSIS look forward to working with the IMI Committee to produce open standards that maximize the benefits of Information Card systems," said Dale Olds, distinguished engineer at Novell and steward of the OSIS working group of Identity Commons.
Additional Information
OASIS IMI Technical Committee
http://www.oasis-open.org/committees/imi/
OASIS Security Forum
http://events.oasis-open.org/home/forum/2008
This extract is taken from one of the IMI TC input documents, Interoperability Profile V1.5 within Web Applications and Browsers, by Michael B. Jones (Microsoft Corporation). July 2008.
The Identity Metasystem allows users to manage their Digital Identities, whether they are self-issued or issued by third-party Identity Providers, and employ them in contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as Information Cards (a.k.a. InfoCards). One important class of applications where Information Cards can be used is applications hosted on Web sites and accessed through Web browsers.
This paper documents the Web interfaces utilized by browsers and Web applications that support the Identity Metasystem. The information in this document applies to all platforms, browsers, and Identity Selectors. These mechanisms are documented here to enable Web sites and browsers on all platforms to implement and use these mechanisms so they can utilize Information Cards.
Design Goals: Numerous alternatives were considered for ways of bringing Information Cards to Web sites. The choices described in this document are an attempt to balance among all the sometimes-competing goals and to achieve all of them as well as possible, given the realities of how the Web is used today. The design goals that led to the eventual decisions described in this document are:
- Browser independent: A goal was to ensure that the protocols developed for using Information Cards on Web sites could be implemented by a broad range of Web browsers on the platforms of their choice.
- Web server independent: A closely-related goal was to ensure that the protocols developed for Information Cards on Web sites could be used by Web-based applications running on a broad range of Web servers on the platforms of their choice.
- Minimal impact on Web sites: A goal was to facilitate the adoption of Information Cards on existing Web sites by requiring as few changes to them as possible.
- Seamless browser integration: A goal was that Information Cards should be viewed as a seamless security feature that is a natural extension of the browser(s) being used.
- Seamless user experience: A goal was that the Information Card Web integration design should permit graceful fall-back when a browser or platform does not have Information Card support available.
- Work with browser high security settings: A goal was that the mechanisms chosen should remain enabled even when browser security settings are set to 'high'.
This extract is taken from one of the IMI TC input documents, An Implementer's Guide to the Identity Selector Interoperability Profile V1.5, published by Microsoft Corporation and Ping Identity Corporation.
Identity is fundamental to enabling interactions in everyday life. The same is true of the digital world as well where Digital Identity is fundamental to enabling digital interactions in an interconnected online world. Digital Identities are used to authenticate parties to each other in the online world. Knowing, with a high degree of assurance, who one is interacting with is a key element in deciding whether to trust the other party and for what.
A Digital Identity of a Subject is defined as a set of Claims asserted by a Claims Authority about the Subject. Claims are communicated in signed Security Tokens, and may represent identifying and other personal information about a Subject. Users will typically have a portfolio of Digital Identities analogous to the multiple forms of identities they employ in the physical world — drivers' licenses, other government-issued identity cards, credit cards, company affiliation cards such as frequent flyer cards, etc.
The use and acceptance of a Digital Identity in any given context is usually an intersection of a user's choice to offer an identity based on its appropriateness to the context, and the recipient's choice to accept that identity based on its requirements and willingness to trust the Claims Authority that is making the claims inherent in the Digital Identity. Hence it is important to create a system that allows users to employ Digital Identities issued by different authorities in contexts of their choosing through a consistent and understandable user interface. The system should be capable of handling all forms of Digital Identities regardless of the underlying identity technologies at play.
The Information Card Model allows users to manage a portfolio of Digital Identities from various authorities, and employ them in various contexts where they are accepted to access online services. The model embodies the patterns and messages of WS-Trust, but can be implemented using lightweight protocols like HTTP POST as well as the SOAP-based WS protocols. A crucial application for this model is to establish a framework in which consumers of user identities can ask for exactly what they need, and providers of identities can furnish the needed identity with intermediation by the user when appropriate.
In the Information Card Model, Digital Identities are encoded as Security Tokens containing claims about a user made by an Identity Provider (IP) and presented to a Relying Party (RP). The Security Token presented may be used for authenticating the user and/or providing authorized access to services offered by the Relying Party. Furthermore, relying parties can express their identity and other security requirements in the form of Security Policy that can be queried by client applications through which the user desires to access the services offered by the Relying Party.
It should be noted that just as claims about users may be asserted by a third party Identity Provider, some claims could be self-asserted by users acting as their own Identity Providers. Ultimately, it is up to the Relying Party to determine if it is willing to trust and accept it. It turns out that such self-issued identities are commonly used and find applicability in many everyday online interactions. For example, when users visit an online retailer site and must create new user accounts in order to purchase merchandise from that site, they would typically fill in one or more online forms divulging personal information to the site. In these circumstances, the online retailer site is usually willing to accept the users' self asserted personal information to register and create accounts for them. Usually, what is important for the Relying Party in such scenarios is that a user can prove on a repeat visit that she is the same user that registered...
To help users organize their various Digital Identities, the Information Card Model introduces the notion of an Information Card which is an embodiment of a Digital Identity that the user can visualize, examine and reason about in user interfaces. Each Information Card corresponds to an Identity Provider and represents a Digital Identity for the user issued by that Identity Provider. Multiple Digital Identities for a user from the same Identity Provider would be represented by different Information Cards. Users may have a collection of Information Cards representing the various Digital Identities they have, some self-issued and others issued by third party Identity Providers.
Note that an Information Card itself is not the Security Token that is used to carry identity claims in Web service protocols; rather it is an artifact that represents the token issuance relationship of the user with the corresponding Identity Provider. An actual Security Token with specific claims can be requested from the Identity Provider when needed based on the Information Card. In other words, Information Cards help to provide a concrete visualization of a user's identities on a user interface in digital interactions much like the cards one carries inside one's wallet/purse for everyday physical interactions.
Further, to help users select from their various Digital Identities in different contexts, the Information Card Model introduces the notion of an Identity Selector as an architectural component in the Identity Metasystem. It is the processing engine that determines which of a user's Information Cards are capable of meeting a Relying Party's requirements. It also provides a consistent user interface for users to visualize, examine and reason about their Digital Identities, and select one for use. When a client application (i.e., the user agent) needs a suitable Security Token to satisfy the security requirements of a target service it interacts with, it invokes the Identity Selector component to obtain the appropriate Security Token representing the user identity. The Identity Selector puts users in control of the use of their identities by applications in various contexts...
The following list identifies the key goals of the Information Card Model:
- Enable use of Digital Identity in the form of Security Tokens carrying claims as authentication and/or authorization data using Web service mechanisms.
- Allow users flexibility in their choice of Digital Identities they wish to employ, and put users squarely in control of the use of their identities in digital interactions.
- Support cryptographically verifiable but human-friendly identification of the recipients of a user's Digital Identities.
- Enable interoperability with Identity Providers and relying parties using open protocols to allow an identity ecosystem to thrive.
- Remain agnostic of specific Security Token types and claim types so as to effectively be a conduit for flow of identity information between Identity Providers and relying parties under user control.
This summary is extracted from Microsoft's paper Online Identity Theft: Changing the Game Protecting Personal Information on the Internet.
Information Cards are not physical cards; rather, they are sets of data pointers that sit on a PC or a mobile phone. They are analogous to tangible cards in a person's wallet. In much the same way that a person might use a student ID card to get free admission to a museum or a frequent-shopper card to get a discount on groceries, a digital Information Card issued by one entity can be used to verify the card owner's identity with another entity, as long as the card includes the necessary data.
How does this work? The creation and use of Information Cards involves three parties. The first party is the entity that issues the card. In the case of a card for use in sensitive interactions, the issuer might be a government, business or nonprofit organization. For less sensitive uses, individuals might issue themselves a card. The second party, or relying party, is whoever needs to accept the card during a transaction. The third party is the cardholder, who decides which card to present in a given transaction.
How does the use of Information Cards reduce the risk of identity theft? For starters, the person's username and password aren't transmitted when an Information Card is presented to a Web site, so they can't be stolen. Information Card technology also supports a range of robust encryption methods that help prevent tampering with the data on the card or snooping to intercept it in transit. Information Cards also allow relying parties to request the minimum amount of personal information needed to authenticate an identity in a given transaction. For example, a particular card might have 10 fields — for name, address, birth date, credit card number, frequent flyer number and so on — but depending on the situation, a relying party might need only two fields of information to complete the transaction (such as name and birth date).
Information Cards are designed to prevent data that is shared in one context from being reused in a different context. This is accomplished through creating a unique set of keys for each combination of Information Card and relying party. Through the use of this security technique, the information used for transactions on one Web site is not available to other Web sites. Finally, because Information Cards allow the user to supply additional authoritative information (such as name and e-mail address) on demand to Web sites for authentication or other purposes, there is less need for organizations to store this data in their systems for long periods of time — and thereby run the risk of it being stolen.
To further advance the interoperability and adoption of this technology, Microsoft and an array of other prominent companies recently formed the non-profit Information Card Foundation. Members of this foundation — including Equifax, Google, Novell, Oracle, and PayPal — share Microsoft's commitment to fostering a simpler, more secure and more open digital identity on the Internet, increasing users' control over their personal information, and enabling mutually beneficial digital relationships between people and businesses..."
From the news story "Information Card Foundation Formed to Support User-Centric Digital Identity":
On June 24, 2008, Equifax, Google, Microsoft, Novell, Oracle, and PayPal issued an announcement the formation of the Information Card Foundation (ICF) as an independent, not-for-profit organization designed to advance the adoption and use of Information Cards across the Internet. ICF's mission is to advance the use of the Information Card metaphor as a key component of an open, interoperable, royalty-free, user-centric identity layer spanning both the enterprise and the Internet.
Information about ICF is provided through a 2008-06-24 press release, in web site documents, as well as through blogs and mailing lists. ICF is is working with or is planning to work with other supporting organizations, including: Concordia, The Fraunhofer Institute FOKUS, Identity Commons, Liberty Alliance, OpenID Foundation, and Open Source Identity Systems (OSIS). In principle, ICF working groups will collaborate with other identity-related organizations: "(1) Protocol, specifications and standards groups; (2) Organizations that promote user-centric identity principles; (3) Other groups to perform iteroperability certification tests in a pragmatic, inclusive process wherever possible to minimize cost and time-to-market, while meeting a quality metric." ICF is also affiliated with Identity Commons as a working group; this means ICF agrees to operate under the shared principles of all Identity Commons working groups.
The founding members of the Information Card Foundation "represent a wide range of technology, data, and consumer companies. Equifax, Google, Microsoft, Novell, Oracle, and PayPal, are founding members of the Information Card Foundation Board of Directors. Individuals also serving on the board include ICF Chairman Paul Trevithick of Parity, Patrick Harding of Ping Identity, Mary Ruddy of Meristic, Ben Laurie, Andrew Hodgkinson of Novell, Drummond Reed, Pamela Dingle of the Pamela Project, Axel Nennker, and Kim Cameron of Microsoft. Additional founding members are Arcot Systems,Aristotle, A.T.E. Software, BackgroundChecks.com, CORISECIO, FuGen Solutions, the Fraunhofer Institute, Fun Communications, the Liberty Alliance, Gemalto, IDology, IPcommerce, ooTao, Parity, Ping Identity, Privo, Wave Systems, and WSO2."
Published ICT ByLaws, IPR Policy, and Contribution Agreements govern the activities of ICT Working Groups. Working Groups may be proposed by Steering and Sponsor level members. All members may participate in a Working Group. Working Groups are designed to be temporary, and stay formed until the deliverables specified in their application are completed. "The IPR Policy covers the activities conducted by working groups. The ByLaws and IPR Policy stipulate that it requires a unanimous vote by the Board of Directors to create a specification. The IPR Process stipulates that it takes a supermajority (two-thirds - 2/3) to reference a specification (which would typically not be created by the ICF) as an ICF Recommendation. Normal working groups can be created by a simple majority board vote, and will produce whitepapers, reports, best practices documents, and other deliverables."
Information Cards, according to the ICF FAQ document, are the "digital, online equivalents of your physical identification credentials such as a drivers license, passport, credit card, club card, business card or a social greeting card. Users control the distribution of their personal information through each Information Card. Information Cards are stored in a user's own online wallet (called a 'selector') and 'handed out' with a mouse click just like a physical ID card."
Information Cards can be used to "log in to websites with a single click, create relationships with those you want to do business with, manage your personal data in one place that only you and those you allow have access, wield the claims that other people and institutions say about you, and prove that you are who you say you are without revealing details using trusted identity providers."
"For example, when logging into an alumni web site, an Information Card-carrying alumnus can simply click on his or her school alumni Information Card, rather than trying to remember his/her user name and password. When buying wine on-line, a user can present a 'I am over 21' card to the wine merchant backed by age verification from a trusted identity provider, e.g., a driver's license issuer or an age verification service. The actual birthdate information need not be revealed or recorded by the merchant."
"Information Cards can be issued to users by organizations for general or specific use.
Users can also create their own Information Cards as a shortcut to avoid the endless
process of filling out web forms. But more importantly, the infastructure behind the
cards allows for trusted sources (a bank, a credit union, a government office, etc.) to
verify specific information ('claims') made by a user. In other words, Information Cards
give users the ability to make claims about themselves, verified by qualified third parties,
while using the Internet."
- IMI TC Announcements:
- OASIS IMI TC:
- OASIS Identity Metasystem Interoperability (IMI) Technical Committee
- Initial TC Officers (2008-09): Co-Chairs Anthony Nadalin and Marc Goodner; Secretaries: Michael Jones and Michael McIntosh.
- IMI TC member list. As of 2008-09-23, members from the following companies were listed: A-SIT Zentrum für sichere Informationstechnologie Austria, CA, Cordance, IBM, Internet2, Microsoft, Mitre, Novell, Polka Networks, and WSO2.
- Obligated Members
- IMI TC IPR Statement. The TC operates under the RF on RAND Terms Mode: "With TCs operating under the RF on RAND Terms IPR Mode, license terms that are fair, reasonable, and non-discriminatory beyond those specifically mentioned in Section 10.2.1 may also be included, and such additional RAND terms are left to the Licensees and Obligated Parties involved."
- IMI TC Wiki
- IMI TC (Kavi) document repository
- IMI TC discussion list archives
- IMI TC comment list archives. One must subscribe before posting to this list; see the instructions.
- IMI TC news
- IMI TC input documents from Microsoft, with posting by Marc Goodner, 2008-09-29. See the file listing for the ten files in the ZIP archive. The ISIP Profile, Implementer's Guide, Browsers and WebApps document, and Application Note are supplied in both DOC and PDF format; schemas 'isip-identity.xsd' and 'wsa-identity.xsd' are included.
- General references:
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
