OASIS Charter Submission Discuss

Proposed Charter for OASIS Identity Metasystem Interoperability (IMI) TC

  • 1.  Proposed Charter for OASIS Identity Metasystem Interoperability (IMI) TC

    Posted 07-24-2008 19:19
    To OASIS Members:
    
      A draft TC charter has been submitted to establish the OASIS Identity
    Metasystem Interoperability (IMI) Technical Committee. In accordance with the
    OASIS TC Process Policy section 2.2: 
    (http://www.oasis-open.org/committees/process-2008-02-05.php#formation) the
    proposed charter is hereby submitted for comment. The comment period shall
    remain open until 11:45 pm ET on 7 August 2008. 
    
      OASIS maintains a mailing list for the purpose of submitting comments on
    proposed charters. Any OASIS member may post to this list by sending email to:
    mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly
    archived at: 
    http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to
    receive emails must join the group by selecting "join group" on the group home
    page:
    http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees
    of organizational members do not require primary representative approval to
    subscribe to the oasis-charter-discuss e-mail.
    
      A telephone conference will be held among the Convener, the OASIS TC
    Administrator, and those proposers who wish to attend within four days of the
    close of the comment period. The announcement and call-in information will be
    noted on the OASIS Charter Discuss Group Calendar.
    
      We encourage member comment and ask that you note the name of the proposed TC
    (IMI) in the subject line of your email message. 
    
    Regards,
    
    Mary
     
    ---------------------------------------------------
    Mary P McRae
    Manager of TC Administration, OASIS
    email: mary.mcrae@oasis-open.org  
    web: www.oasis-open.org
    phone: 603.232.9090
     
    
    ===========
    PROPOSED CHARTER FOR REVIEW AND COMMENT
    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) 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) The scope of the work of the TC.
    
    The TC will accept as input the July 2008 Identity Selector Interoperability
    Profile specification [1] and associated guides [2] [3] as published by
    Microsoft, the July 2008 Web Services Addressing Endpoint References and
    Identity specification [4] published by Microsoft and IBM, and the OSIS (Open
    Source Identity Systems) Feature Tests [5] published by Identity Commons (the
    Input documents).
    
    Other contributions and changes to the input documents will be accepted for
    consideration without any prejudice or restrictions and evaluated based on
    technical merit insofar as they conform to this charter. OASIS members with
    extensive experience and knowledge in these areas are particularly invited to
    participate.
    The following sub-sections describe the charter of the Identity Metasystem
    Interoperability (IMI) TC with respect to these areas. The scope of the TC's
    work is to continue further refinement and finalization of the Input Documents
    to produce specifications that standardize the concepts and XML Schema
    renderings of the areas described below in a form that is backward compatible
    with the input documents.
    
    ---- First Phase of TC Work
    The TC shall focus its initial activity on producing an Identity Selector
    Interoperability Profile and the supporting WS-Addressing Endpoint References
    and Identity specification. This is to be done in parallel with work on
    interoperability testing described in Ongoing Work below. Upon publication of
    the initial work, which is required to promote the interoperability testing
    work, the TC shall begin its second phase work below.
    
    ---- Identity Selector Interoperability Profile
    This profile defines an interoperable Information Card format and associated
    identity system components that allow users to manage their digital identities
    from different identity providers, and employ them in various contexts to access
    online services.
    
    ---- Information Card Format
    
    An Information Card represents a digital identity of a subject that can be
    issued by an identity provider. It is an artifact containing metadata that
    represents the token issuance relationship between an identity provider and a
    subject, and provides a visual representation of the digital identity. Multiple
    digital identities for a subject from the same identity provider are represented
    by multiple and different Information Cards. Subjects may obtain an Information
    Card from an identity provider, and may have a collection of Information Cards
    from various identity providers. A user controls her Information Cards through a
    software interface referred to as an Identity Selector.
    
    Information Cards contain the following information:
    
    * A language identifier to describe which language localizable elements have
    been localized.
    * A reference identifier to provide a specific reference for a card by which it
    can be uniquely identified within the scope of an issuer
    * A card name that is a friendly textual name for an issued Information Card.
    * An image element that contains a base64 encoded inline image that provides a
    graphical image for the issued Information Card, including MIME type information
    for the type of image format.
    * An issuer element that provides a logical name for the issuer of the
    Information Card.
    * Elements to indicate when an Information Card was issued and when it expires.
    * An element to specify an identity provider's supported token services as a
    list. This is an ordered list of Identity Provider (IP) / Security Token Service
    (STS) endpoints, and the corresponding credential type to be used, for
    requesting tokens. For each endpoint, the required credential type implicitly
    determines the authentication mechanism to be used. Each IP/STS endpoint
    reference in the Information Card includes the security policy metadata for that
    endpoint.
    * An element to specify an identity provider's supported token types as a list. 
    * An element to provide information that identifies the relying party where
    issued tokens for the Information Card will be used.
    * An element to describe the supported claim types offered including display and
    description information about the claim type. 
    * An element to indicate the location and version of the privacy statement of
    the identity provider.
    * Extensibility points to support future enhancements to the Information Card
    format.
    
    ---- Information Card Transfer Format
    
    This profile will define how collections of Information Cards are transferred
    between identity selectors. Rules are also defined that cover the portability of
    content in Information Cards through the use of defined extensibility points.
    
    ---- Information Card Issuance
    
    In order to provide the assurance that an Information Card is indeed issued by
    the identity provider expected by the user, the Information Card must be carried
    inside a digitally signed envelope that is signed by the identity provider. The
    signature on the digitally signed envelope provides data origin authentication
    assuring the user that it came from the right identity provider. The
    specification will describe a specific profile of XML Digital Signatures [6]
    that must be used to sign the envelope carrying the Information Card. An
    identity selector must verify the enveloping signature. The Information Card can
    then be extracted and stored in the Information Card collection.
    
    ---- Token Request and Response
    
    For any given Information Card, an Identity Selector can obtain a security token
    from the IP/STS for that Information Card using the "issuance binding" of
    WS-Trust [7].
    
    When requesting a security token from the IP/STS, an Identity Selector includes
    the Information Card reference element, and all of its content, in the body of
    the Request Security Token (RST) message as a top-level element. Generally an
    Identity Selector should not send token scope information to an identity
    provider to protect user privacy. When scope information is required by the
    identity provider this profile defines rules for the behavior of the identity
    selector. The profile also defines rules for use of client pseudonyms as PPIDs
    and the use of proof keys for issued tokens.
    
    This profile also defines an element that an Identity Selector may use as a top
    level element in an RST to request a display token. A display token contains a
    representation of the claims carried in the issued token that can be displayed
    in a user interface.
    
    ---- Identity Provider Requirements
    
    The Information Card schema includes the element content necessary for an
    identity provider to express what credential the user must use in order to
    authenticate to the IP/STS when requesting tokens. These include, but are not
    limited to, Username/Password, Kerberos, X.509 (WSS Security Token Profiles [8])
    and self issued tokens (see below).
    
    Identity Providers must make their security policy available at a URL using the
    HTTPS scheme. An Identity Selector may retrieve this policy using the mechanisms
    defined in WS-MetadataExchange [9].
    
    A policy assertion is defined to indicate that Information Cards, representing
    identities that may be federated, must be pre-provisioned before token requests
    can be made of the identity provider. This assertion is used in the IP/STS
    policy metadata.
    
    This profile also defines SOAP faults for use in error situations by an Identity
    Provider.
    
    ---- Relying Party Requirements
    
    A relying party specifies its security token requirements as part of its
    security policy using the primitives and assertions defined in WS-SecurityPolicy
    [10]. The claims requirement of a relying party can be expressed in its token
    policy by using the optional Claims parameter defined in WS-Trust. However, the
    Claims parameter has an open content model. This profile defines the ClaimType
    element for use as a child of the Claims element.
    
    This profile also defines SOAP faults for use in error situations by a Relying
    Party.
    
    ---- Self Issued Identity Provider
    
    The profile defines a simple identity provider, called the "Self Issued Identity
    Provider" (SIP). This is an identity provider which allows users to self assert
    identity in the form of self issued tokens. An identity selector may include a
    co-resident self issued identity provider that conforms to the Simple Identity
    Provider Profile. This profile allows self issued identities created within one
    identity selector to be used in another identity selector such that users do not
    have to re-register at a relying party when switching identity selectors. This
    profile defines the characteristics and behaviors of Self Issued Identity
    Providers and self issued tokens. 
    
    ---- Invoking Identity Selectors from Web Pages
    
    HTML extensions are used to signal to the browser when to invoke the Identity
    Selector. However, not all HTML extensions are supported by all browsers, and
    some commonly supported HTML extensions are disabled in browser high security
    configurations. For example, while the OBJECT tag is widely supported, it is
    also disabled by high security settings on some browsers. An alternative is to
    use an XHTML syntax . However, not all browsers provide full support for XHTML.
    Two HTML extension formats are specified, the OBJECT tag and XHTML. Both share
    the same set of optional parameters:
    * issuer: the URL of the STS from which to obtain a token. 
    * issuerPolicy, the URL of an endpoint from which the STS's WS-SecurityPolicy
    can be retrieved using WS-MetadataExchange.  This endpoint must use HTTPS.
    * tokenType: specifies the type of the token to be requested from the STS as a
    URI. This parameter can be omitted if the STS and the web site front-end have a
    mutual understanding about what token type will be provided or if the web site
    is willing to accept any token type.
    * requiredClaims: specifies the types of claims that must be supplied by the
    identity. If omitted, there are no required claims. 
    * optionalClaims: specifies the types of optional claims that may be supplied by
    the identity. If omitted, there are no optional claims. 
    * privacyUrl: specifies the URL of the human-readable privacy policy of the
    site, if provided.
    * privacyVersion: specifies the privacy policy version. This must be a value
    greater than 0 if a privacyUrl is specified. If this value changes, the Identity
    Selector UI notifies the user and allows them review the change to the privacy
    policy.
    The data types of these parameters are also defined for use with scripting.
    
    ---- WS-Addressing Endpoint References and Identity 
    
    This specification provides a mechanism to describe security-verifiable identity
    for endpoints by leveraging extensibility of the WS-Addressing [11]
    specification. 
    
    An element is defined for representing identity (as nested elements) that can be
    provided as part of a WS-Addressing Endpoint Reference. Elements are defined to
    identity claims for DNS name, Service Principal Name, User Principal Name and
    Key Info.
    
    These mechanisms enable messaging systems to support multiple trust models
    across networks that include processing nodes such as endpoint managers,
    firewalls, and gateways in a transport-neutral manner. These elements are used
    within Identity Metasystem components but are also of broader applicability.
    
    ---- Second Phase of TC Work
    
    The claim types defined in phase one must work with the Information Card format
    but should also compose with other claim type dialects, e.g. the common claims
    dialect defined in WS-Federation [12]. The TC will need to investigate
    integrating other claim dialects into the Information Card model. The TC may
    also look into issues around using specific sources of data, e.g.  LDAP or other
    network level information, as claims.
    
    The TC may also work on enhancements to the object tag described above, e.g. to
    improve the display of Information Cards on web sites.
    
    The TC may also work on improving how Information Cards can be used across a
    number of different devices, or roamed, beyond the export format defined above.
    This may require utilizing extensibility points in the protocols already in use
    or potentially new protocols.
    
    Utilizing the Trust 1.4 challenge/negation features and profiling schema for
    specific tokens used with Information Cards are also areas of interest for the
    second phase of TC work.
    
    ---- Ongoing TC Work
    
    The TC shall focus on interoperability test definitions and runs to validate its
    work on an ongoing basis. The TC will determine the feature areas to test and
    the specific interoperability scenarios. Initially this work shall focus on the
    first phase deliverables defined above. The TC is encouraged to use the OSIS
    Feature Tests as a basis for this work. When the TC begins its second phase of
    work new tests will need to be defined to support it.
    
    The TC shall also consider and assist in the work of other related OASIS TCs on
    an ongoing basis as agreed by the TC membership, e.g. assisting in the SAML
    Information Card Profile [13] definition and ensuring that the IMI work composes
    properly.
    
     ---- General Notes on Scope
    The output specifications will uphold the basic principles of other Web services
    specifications of independence and composition and be composable with the other
    specifications in the Web services architecture, such as the specifications
    listed in the References section. 
    Each of the protocol elements will use implementation and language neutral XML
    formats defined in XML Schema [14].
    
    The following is a non-exhaustive list. It is provided only for the sake of
    clarity. If some function, mechanism or feature is not mentioned here, and it is
    not mentioned in the Scope of Work section either, then it will be deemed to be
    out of scope.
    
    The TC will not define a mapping of the functions and elements described in the
    specifications to any programming language, to any particular messaging
    middleware, nor to specific network transports.
    
    ----- Out of Scope
       
    The following items are specifically out of scope of the work of the TC:
    
    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) 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, July 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, July 2008
    http://schemas.xmlsoap.org/ws/2005/05/identity
    
    [3] An Implementer?s Guide to the Identity Selector Interoperability Profile
    V1.5, July 2008
    http://schemas.xmlsoap.org/ws/2005/05/identity
    
    [4] Application Note: Web Services Addressing Endpoint References and Identity,
    July 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-SOAPMes
    sageSecurity.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-Usernam
    eTokenProfile.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.p
    df 
    
    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-Kerbero
    sTokenProfile.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-SAMLTok
    enProfile.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-prof
    ile-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-infocar
    d-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) 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) The anticipated audience or users of the work.
    
    The anticipated audience for this work includes:
    * 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) 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 regarding the startup of the TC: 
    (2)(a) 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:
    
    * 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
    
    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:
    * OASIS Web Services Security TC. The IMI TC will ensure that its specifications
    compose with the WSS TC specifications.
    * OASIS Web Services Secure Exchange TC. The IMI TC will ensure that its
    specifications compose with the WS-SX TC specifications.
    * OASIS Web Services Federation TC. The IMI TC will ensure that its
    specifications compose with the WS-FED TC specifications.
    * OASIS Security Services Federation TC. The IMI TC will ensure that its
    specifications compose with the SAML TC specifications.
    
    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) 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 10am Ditton Manor, UK (Co-located at OASIS Standards Forum
    2008: Security Challenges)
    
    (2)(c) The projected on-going 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) 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.
    
    Abbie Barbir (Nortel) abbieb@nortel.com
    Adnan Onart (Nortel) AONART@nortel.com
    Paul Knight (Nortel) paul.knight@nortel.com
    Marc Goodner (Microsoft) mgoodner@microsoft.com
    Michael McIntosh (IBM) mikemci@us.ibm.com
    Anthony Nadalin, (IBM ), drsecure@us.ibm.com
    John Bradley, (Individual), jbradley@mac.com
    Richard Brackney (US DoD), rcbrack@verizon.net
    
    (2)(e) The name of the Convener who must be an Eligible Person.
    Abbie Barbir, Nortel
    
    (2)(f) 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) 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, July 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, July 2008
    http://schemas.xmlsoap.org/ws/2005/05/identity
    
    [3] An Implementer's Guide to the Identity Selector Interoperability Profile
    V1.5, July 2008
    http://schemas.xmlsoap.org/ws/2005/05/identity
    
    [4] Application Note: Web Services Addressing Endpoint References and Identity,
    July 2008
    http://schemas.xmlsoap.org/ws/2006/02/addressingidentity 
    
    
    (2)(h) 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) Optionally, a proposed working title and acronym for the specification(s)
    to be developed by the TC. 
             None