Subject: [dix] proposed charter (draft #4)

From: John Merrells <[email-masked]>
Date: Sun, 26 Feb 2006 21:28:44 -0800

This rewrite is based on Jim's editing down of draft #3 and the  
conversations on the list over the past couple of weeks.

I'll work on some use cases / scenarios next.

John

----

Description of Working Group:

The Digital Identity Exchange (DIX) group will specify an Internet- 
scale identity information exchange protocol. A system architecture  
will be defined such that a separation of control may be maintained  
between all parties of the exchange.

Problem Statement

The Internet is host to many online information sources and services.  
There is a growing demand for users to identify, and provide  
information about themselves. Users bear the burden of managing their  
own authentication materials and repeatedly providing their identity  
information. Signing in to web pages and completing user registration  
forms is an example.

Goals

To specify a protocol for moving identity information between  
parties, and a system architecture that enables the development of  
software agents to manage this exchange.

To specify a protocol with minimal adoption barriers, for which the  
following aspects of the protocol should be considered:

Deployment of DIX-aware services and solutions should require minimal  
modifications to existing software to enable participation in an  
identity information exchange.

The end-user should have control over their identity information and  
always be providing consent for the exchange of any of their  
information.

Initiation of an exchange between two parties should be possible  
without any
pre-established relationship.

A naming scheme for user identifiers should be considered that allows  
the user to concurrently maintain multiple personas, to separate  
their digital identity from their identifier, and to separate the  
parties exchanging information from their identifier.

Naming schemes for user attributes should be considered.

The data that represents the identity information is expected to be  
opaque. It is expected that the messages of the protocol will include  
elements that associate property descriptors and their values to  
digital identities.

Security should be considered (confidentiality and data integrity of  
any transferred information must be in place). Also, non-user parties  
should maintain the user's privacy.

Existing techniques and technologies should be considered to ensure  
ease of adoption, implementation, and interoperability.

Extensibility should be considered for each aspect of the protocol to  
ensure flexibility for future uses.

The protocol should be scalable, requiring no centralized services  
beyond those that already exist (i.e. DNS).

Out of Scope

- How to federate identity namespaces.
- How to use or issue digital certificates.
- The schema and type system for identity information.
- The mechanisms by which authentication is performed, (e.g. username/ 
password, one-time password devices). The scope is constrained to the  
movement of the authentication result between parties.

Internet Drafts

The Working Group anticipates the authoring of at least three  
Internet-Drafts.

DIX Use Cases * A catalogue of DIX protocol use cases which  
illustrate the problems being solved, and to inform the decision  
making of the Working Group. For example, one use case could  
illustrate how DIX would be used by a website to check the reputation  
of potential posters to an online forum. Another use case could show  
how form fill-in could be automated.

DIX Protocol * A description of the DIX protocol. It is expected that  
the protocol will be composed of discovery, exchange and  
verification; discovery of endpoints and negotiation of capabilities,  
exchange of identity information, and verification of the  
authenticity of identity information. This document should specify  
the protocol elements in a transport-independent manner.

DIX HTTP Transport Binding * How the DIX protocol will be mapped onto  
HTTP as a transport layer. In this case the user's software is a HTTP  
client, to which no modifications should be required, and the third  
party would be a HTTP server. Continuing with the theme of simplicity  
a HTTP server should require minimal changes to support identity  
information exchange. For example, a HTML form could receive  
information the same way that a user would provide it, as if they  
typed it into the form themselves.

It is anticipated that both the protocol and transport binding  
documents will be on the standards track.

These documents provide a foundation layer for protocol extensions  
such as support for one party acting as an agent for another (e.g.  
Web Services), interoperation with existing protocols for movement of  
security information (e.g. WS-Trust, SAML), acquisition and  
presentation of third-party claims (e.g. XML-DSIG), alternative  
transport bindings (e.g. XMPP, SIP).

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix