Cover Pages Logo 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

CFP: OASIS Identity Metasystem Interoperability (IMI) TC

Call for Participation: OASIS Identity Metasystem Interoperability (IMI) TC

Date:      Tue, 12 Aug 2008 19:13:58 -0400
From:      Mary McRae <mary.mcrae@oasis-open.org>
To:        members@lists.oasis-open.org,
           tc-announce@lists.oasis-open.org
Cc:        imi@lists.oasis-open.org
Subject:   Call for Participation: OASIS Identity Metasystem Interoperability (IMI) TC

To: OASIS members and interested parties

A new OASIS technical committee is being formed. The OASIS Identity Metasystem Interoperability (IMI) Technical Committee has been proposed by the members of OASIS listed below. The proposal, below, meets the requirements of the OASIS TC Process [a]. The TC name, statement of purpose, scope, list of deliverables, audience, and language specified in the proposal will constitute the TC's official charter. Submissions of technology for consideration by the TC, and the beginning of technical discussions, may occur no sooner than the TC's first meeting.

This TC will operate under the OASIS IPR Policy [b]. The eligibility requirements for becoming a participant in the TC at the first meeting (see details below) are that:

  1. you must be an employee of an OASIS member organization or an individual member of OASIS
  2. the OASIS member must sign the OASIS membership agreement [c]
  3. you must notify the TC chair of your intent to participate at least 15/7 days prior to the first meeting, which members may do by using the "Join this TC" button on the TC's public page at [d]
  4. you must attend the first meeting of the TC, at the time and date fixed below

Of course, participants also may join the TC at a later time. OASIS and the TC welcomes all interested parties.

Non-OASIS members who wish to participate may contact us about joining OASIS [c]. In addition, the public may access the information resources maintained for each TC: a mail list archive, document repository and public comments facility, which will be linked from the TC's public home page at [d].

Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your feedback.

Regards,

Mary

Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org

References:
[a] http://www.oasis-open.org/committees/process.php
[b] http://www.oasis-open.org/who/intellectualproperty.php
[c] http://www.oasis-open.org/join/
[d] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=imi

IMI TC Charter: Call For Participation

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; tThe 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:

  1. Definition of the form and content of privacy statements
  2. The establishment of trust between two or more business parties
  3. Definition of new key derivation algorithms
  4. 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]

CFP Source

See also:

Prepared by Robin Cover for The XML Cover Pages archive. See additional details in the 2008-09-23 Cover Pages news story: OASIS Identity Metasystem Interoperability TC Advances Information Card Use.
Globe Image

Document URI: http://xml.coverpages.org/IMI-CFP.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org