Subject: RE: [dix] Proposed Charter for DIX Working Group

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Jan 2006 10:37:18 -0800

I think that the real problem is that we have all the components its just that they don't fit together.

Its like the car that the guy made by taking one piece at a time home in his lunchbox. He ended up with a gearbox from one year, an engine from another, etc. etc. Nothing fit together.

I think that most of the problems of the Internet protocols today are problems of integration rather than base technology.

The part that is dealt with worst is the user experience. The bits on the screen are quite properly left to implementations, but there is still something missing.

I am not suggesting that we redo authentication or redo attributes. What we need is:

1) a model that shows how all the pieces can fit together in a consistent and coherent fashion.

2) A deployment strategy for getting the model into common use.

(2) is much more important (and difficult) than (1).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tschofenig, Hannes
> Sent: Sunday, January 15, 2006 4:29 PM
> To: John Merrells; [email-masked]
> Subject: AW: [dix] Proposed Charter for DIX Working Group 
> 
> hi all, 
> 
> i am not quite sure what you are trying to accomplish. 
> 
> from the text i get the impression that you want to work on a 
> new saml version. 
> from the feedback provided by Phillip Hallam-Baker i 
> understood that he suggests to work on authentication 
> mechanis. i don't think that this is the right approach 
> either. (saml comment: saml does not define any 
> authentication mechanisms) there is already plenty of work on 
> authentication approaches out there. 
> 
> ciao
> hannes
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von 
> > John Merrells
> > Gesendet: Freitag, 13. Januar 2006 04:41
> > An: [email-masked]
> > Betreff: [dix] Proposed Charter for DIX Working Group
> > 
> > 
> > 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 <[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.
> > 
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dix
> > 
> 
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
> 
> 

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Dick Hardt <[email-masked]>
Date: Mon, 16 Jan 2006 17:43:51 -0800

Phillip, that resonates in why I got involved in kicking off DIX.

I agree that deployment is the more difficult problem. Partly because  
it is NOT technical.

For deployment to happen, not only does it need to be simple and  
solve a real problem. There is the proverbial Chicken and Egg issue,  
which in this case is user and site. No site wants to deploy until  
there are users that have the functionality, and the users are not  
motivated until there are sites that accept the functionality.

Fortunately, IETF only has to solve the technical issues, albeit in a  
manner that has low barriers to adoption.

-- Dick

On 16-Jan-06, at 10:37 AM, Hallam-Baker, Phillip wrote:

> Its like the car that the guy made by taking one piece at a time  
> home in his lunchbox. He ended up with a gearbox from one year, an  
> engine from another, etc. etc. Nothing fit together.
>
> I think that most of the problems of the Internet protocols today  
> are problems of integration rather than base technology.
>
> The part that is dealt with worst is the user experience. The bits  
> on the screen are quite properly left to implementations, but there  
> is still something missing.
>
>