[dix] Proposed Charter for DIX Working Group

[John Merrells <MERRELLS at SXIP.COM>]

Hello 'DIX mailing list member',

The following document is a proposed charter for a DIX Working Group.
Feedback to me, or discussion on this list, is most welcome.

This proposed charter will form part of a request to the application  
area
directors for a BOF at the next IETF meeting. At that meeting this  
charter
will be discussed, and if found to be acceptable, will become the  
working
group charter, should one be created.

John

-------------

Digital Identity Exchange - DIX

Chairs

TBD

Applciations Area Director(s):

Ted Hardie <hardie at qualcomm.com>
Scott Hollenbeck <sah at 428cobrajet.net>

Mailing Lists:

General Discussion: dix at ietf.org
To Subscribe: dix-request at ietf.org
In Body: In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/dix/

Description of Working Group:

The DIX group will work on the specification of the Digital Identity  
Exchange protocol. DIX is an Internet scale protocol for exchanging  
identity information between endpoints. The protocol architecture  
maintains a separation of control between all parties of the exchange  
and supports both compartmentalized and anonymous identities.

Problem Statement

The success of the Internet has led to a multitude of online  
information sources and services. A consequence of this has been the  
increasing demand for users to identify themselves and to provide  
information about them. The user is currently bearing the burden of  
managing their authentication credentials and is repeatedly having to  
provide their identity information. For example, signing in to web  
pages and completing user registration forms.

An illustrative example would be a website that accepts user  
generated content. A significant problem exists today that these  
sites attract the attention of spammers. Upon submission the site  
needs to determine both the identity of the submitter and that they  
are of good standing in the community. In other words, the site  
requires the reputation of the submitter. This is not possible  
without a protocol to identify a user across multiple sites and to  
move that reputation data around.

Goal

The goal of this group is to specify a protocol for moving identity  
information between parties and a system architecture that enables  
the development of software agents to manage a user’s identity  
information.

Method

An identity information exchange should involve just three parties:  
the user, their agent, and a relying party. The user’s agent is where  
they authenticate themselves and a repository where they store their  
identity information, and the relying party is an entity requesting  
identity information.

The protocol should be both simple and secure. Simple meaning that  
minimal modifications should be required to the user’s software and  
the relying party’s software to participate in an identity  
information exchange. The protocol should be inherently scalable,  
requiring no centralized services, beyond those that already exist,  
in order to operate.

The security of a protocol is well understood within the IETF to be  
the assurance of confidentiality and integrity of any transferred  
information. But, in the context of digital identity we wish to also  
be assured that user agents and relying parties maintain user privacy.

Any solution should support multiple transport layers, but it is  
anticipated that this working group will focus on a HTTP based  
solution. In this case the user’s software is a web browser, to which  
no modifications should be required, and the relying party would be a  
website. Continuing with the theme of simplicity a website should  
require minimal changes to support identity information exchange. For  
example, a web form could receive information the same way that a  
user would provide it, as if they typed it into the form themselves.

In moving identity information between parties it is expected that  
the messages of the protocol will include elements that bind property  
names and values to digital identities. How a digital identity is  
referred to is an important consideration. The properties an  
identifier could have are that it allows the user to concurrently  
maintain multiple personas, that it could allow for a separation  
between the digital identity and the identifier and that it allow for  
separation between the identifier and the user’s agent. In the  
interests of flexibility and interoperability we would suggest that  
the identifier be a string of characters. This working group may  
consider current best practice of what that string might be. For  
example, a URL or a UUID.


Work In Scope

A user-centric, simple, secure, interoperable protocol for digital  
identity information exchange.

An advanced work item for this working group would be consideration  
of how this protocol could operate over web services protocols (e.g.  
SOAP, XML-RPC, REST), or interoperate with existing web services  
protocols for security information (e.g. WS-Trust). The group must be  
careful not to preclude interoperation at a later date.

Although the data that represents the identity information is  
expected to be opaque it is worth mentioning that the data could be  
raw attributes of the digital identity, or could be third party  
claims. A third party claim is signed by an authoritative source so  
that the relying party can be assured of its authenticity. The  
benefit of third party claims, as supported by this protocol, is that  
the separation of claim acquisition from claim presentation provides  
both scalability and privacy benefits.

Out of Scope

How to federate identity namespaces.
How to manage digital certificates or certification authorities.
The mechanisms by which authentication and authorization are performed.

Goals and Milestones:

March 2006 – BOF meeting
June 2006 – First DIX Protocol Internet Draft
June 2006 – First DIX HTTP Transport Binding Internet Draft
July 2006 – Working Group meeting
November 2006 – Working Group meeting
December 2006 – Request Last Call for DIX Protocol
December 2006 – Request Last Call for DIX HTTP Transport Binding
March 2007 – Working Group meeting
April 2007 – Submit DIX Protocol to IESG for consideration as  
Proposed Standard
April 2007 – Submit DIX HTTP Transport Binding to IESG for  
consideration as Proposed Standard




_______________________________________________
dix mailing list
dix at ietf.org
https://www1.ietf.org/mailman/listinfo/dix