Subject: [dix] draft of proposed charter (#3)

From: John Merrells <[email-masked]>
Date: Mon, 23 Jan 2006 17:05:13 -0800

Added interoperability statement. Too general or too specific?

Reworked the definition of the parties involved. Do you prefer those  
terms?

John

----

Proposed Charter for DIX Working Group

Digital Identity Exchange - DIX

Chairs

TBD

Applciations Area Director(s):

Ted Hardie <[email-masked]>
Scott Hollenbeck <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
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.

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 the exchange of a user’s  
identity information.

Method

An identity information exchange involves two parties: the user, and  
another party, either relying or asserting. A relying party requests  
identity information and an asserting party provides identity  
information.

The identity information exchange protocol involves three principal  
computing endpoints: the agent, the client, and the server. The agent  
is where the user authenticates themselves and a repository where  
they store their identity information. The client is the device the  
user uses to initiate communication with the server and the server  
requests or provides identity information. Non-principal endpoints  
may participate in an information exchange by providing facilitating  
services, such as proxying, caching or agency.

The protocol should be both simple and secure. Simple in terms of  
implementation in that minimal modifications should be required to  
the user’s software and the third 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’s agents and the third parties maintain user  
privacy.

Any solution should allow DIX messages to be carried over multiple  
alternative transports, including, but not limited to: HTTP, XMPP,  
and SIP. It is anticipated that this working group will initially  
focus on a HTTP based solution.

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.

The identifier should be based on existing identifier and namespace  
mechanisms to ensure flexibility and interoperability, and the  
working group should consider current best practice. For example, a  
URI, 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 be used for 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 a 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.

Interoperation

To ensure interoperability the DIX Working Group will specify  
mandatory to implement transport bindings. An agent implementation  
must implement the mandatory transport binding for communication with  
both clients and servers. A client implementation must implement the  
client to agent protocol.  A server must implement the server to  
agent protocol. The protocol used between the client and the server,  
however, is application-dependent.

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.
The schema and type system for identity information.

Internet Drafts

The Working Group anticipates the authoring of at least three  
Internet Drafts, two of which are expected to be Standards Track  
documents.

DIX Use Cases – A catalogue of DIX protocol use cases to illustrate  
the problem being solved and to inform the decision making of the  
Working group. For example, an illustrative use case would be a  
website that accepts user generated content. A significant problem  
exists today that these sites attract the attention of spammers. The  
DIX protocol would allow that website to determine the identity of  
the submitter. A potential solution to the spam problem would be for  
the website to check that the submitter is of good standing in their  
community. In other words, the website would request the reputation  
of the submitter. The DIX protocol would allow that reputation data  
to be built up, aggregated, and moved between around.

DIX Protocol – A description of the DIX protocol.

DIX HTTP Transport Binding – How the DIX protocol will be mapped down  
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.

Goals and Milestones:

March 2006 – BOF meeting
April 2006 – DIX Use Cases Internet Draft
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 25 Jan 2006 00:59:08 -0700

John,
 
I took a stab at simplifying the charter (based on your initial #3). In some places, the details can be moved into I-D's. My changes excluded the front and back matter

I managed to pare it from 1000 words to 182, and dropped the fog index from 11.58 to 9.68. I think a bit more could be done (look for the <todo: ...> statements, but didn't want to step on your toes too much ;).
 
Take or leave all or parts at will.
 
Jim

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.

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

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

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.

<todo: further distillation)
An identifier will be chosen to refer to a digital identity. The identifier should be based on existing identifier schemes and namespace mechanisms to ensure flexibility and interoperability. The working group should consider current best practices in choosing this. For example, a URI, a URL or a UUID may be considered as a good fit for an identifier.
This identifier may include various properties including:
- that the user can concurrently maintain multiple personas, 
- that there is a separation between the digital identity and the identifier, and 
- that there be a separation between the identifier and the parties exchanging information.

The specification should be transport independent in general. Bindings to one particular transport may be carried out while other transports are left for future specifications.

<todo: make up our minds as to how much of the payload is talked about. Distill further>
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. 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 a receiving 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.

Work In Scope

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

<todo: distill this>
While any solution should allow DIX messages to be carried over multiple alternative transports, including, but not limited to: HTTP, XMPP, 
and SIP. It is anticipated that this working group will initially focus on a HTTP based solution. Doing this will help ensure interoperability among independent implementations. 

Support for both compartmentalized and anonymous identities.

<todo: does this warrant adding another I-D to the list below?>
An advanced work item would consider how to use this protocol for 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.

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. <todo: does this mean authentication between a protocol peers, or the use of DIX as part of an AuthN/AuthZ solution?>
- The schema and type system for identity information.

Internet Drafts

The Working Group anticipates the authoring of at least three Internet-Drafts. Two of these are expected to become Standards Track documents. <Todo: which two?>

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. 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.