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 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 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 protected]
https://www1.ietf.org/mailman/listinfo/dix
