> 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.
Suggested Change: The protocol should be both simple to implement and secure. > Any solution should support multiple transport layers, including, but > not limited to: HTTP, SOAP, XMPP, and SIP. Not to quibble but I don't consider SOAP to be a transport protocol but a messaging protocol. OTOH I could see SOAP, as a message envelope format, to be used within one of the mentioned transport protocols. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Merrells Sent: Thursday, January 19, 2006 12:46 PM To: Digital Identity Exchange Subject: [dix] draft of proposed charter (#2) 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 _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
