Reworked to take into account the comments received so far. There's
still a
couple of outstanding comments... and am waiting for those threads to
close
out... today I hope :-)
John
----
Proposed Charter for DIX Working Group
Digital Identity Exchange - DIX
Chairs
TBD
Applciations Area Director(s):
Ted Hardie <[EMAIL PROTECTED]>
Scott Hollenbeck <[EMAIL PROTECTED]>
Mailing Lists:
General Discussion: [email protected]
To Subscribe: [EMAIL PROTECTED]
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 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’s agents and relying parties maintain user privacy.
Any solution should support multiple transport layers, including, but
not limited to: HTTP, SOAP, 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. 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 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 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.
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
relying 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 protected]
https://www1.ietf.org/mailman/listinfo/dix
