Subject: [dix] Proposed Charter for DIX Working Group

From: John Merrells <[email-masked]>
Date: Thu, 12 Jan 2006 19:40:34 -0800

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Jan 2006 19:25:09 -0800

> From: John Merrells [mailto:[email-masked]] 

> On 13-Jan-06, at 1:56 PM, Hallam-Baker, Phillip wrote:
> 
> >
> >> What did it mean to you when you read it? My understanding, and I 
> >> think the general understanding, is that 'identity' is a 
> thing that a 
> >> person has.
> >
> > Not to be too picky but your definition seems pretty close to the 
> > definition Douglas Adams suggested for 'life'. The same thing could 
> > apply to his glasses should he be wearing them.
> 
> Identity is a philosophical thing... 

I agree, that is why I spent a considerable time studying semiotics when
I was working on the Web fundamentals.

> i think people get that. 
> 'Digital Identity' seems to be the colloquial term people use 
> for online identity. I'm content that it means what I think it means.

As a philosopher I am not content unless I can have a clearly defined
meaning.

As a pragmatist I worry that unless we can get the term locked down to
the point where we can reasonably claim that it is an established term
of art we get a confused IESG.

> Yes, we're in agreement. There's a paragraph in the charter 
> that explicitly points out that a fundamental thing to work 
> out is what an appropriate identifier is.

The problem with that approach is that the charter is quite likely to be
filed as 'research' and the group told to go and talk to the IRTF chair.

The problem with presenting a Identity 2.0 type sales pitch at the IETF
is that most of the people have already seen the Identity 0.1, and 1.0
series talks. It's a hard sell.

> > Reputation is part of the accountability approach. In 
> slashdot you are 
> > accountable to your reputation.
> >
> > The three components of an accountability scheme are 
> authentication, 
> > accreditation and consequences. You have to have a way of 
> knowing who 
> > to hold accountable, you have to know whether you are likely to be 
> > able to hold them accountable, you have to know that if they defect 
> > they will face consequences.
> >
> > Loss of reputation is one accountability strategy. However the SSL 
> > scheme hangs together through the threat of legal 
> consequences in the 
> > case of a defection (at least with the high assurance CAs).
> 
> The text you're discussing is just an example. You seem to be 
> saying that there's a more general solution than the 
> reputation one I'm suggesting... fine... but for the purposes 
> of an example I'd rather it were more specific than more 
> general. Yeah?

What I am saying here is that 'reputation' schemes are a proper subset
of accountability schemes. You asserted that we were doing reputation
NOT accountability.

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 15 Jan 2006 22:28:31 +0100

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 
> 
> 
> the development of software agents to manage a user's identity  
> information.
> 
> Method
> 
> the user, their agent, and a relying party. The user's agent 
> is where  
> minimal modifications should be required to the user's software and  
> the relying party's software to participate in an identity  
> solution. In this case the user's software is a web browser, 
> to which  
> separation between the identifier and the user's agent. In the  
> 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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 15 Jan 2006 22:28:32 +0100

hi phillip, 
 
please find my comments inline:

> Auftrag von Hallam-Baker, Phillip
> Gesendet: Freitag, 13. Januar 2006 17:18
> An: John Merrells; [email-masked]
> Betreff: RE: [dix] Proposed Charter for DIX Working Group 
> 
> The charter is somewhat more detailed than is usual.
> 
> I am not sure that the term 'identity' is going to be understood by
> those who read it in the same sense as intended by those who wrote it.
> 
> I prefer to use the terms 'identifier' and assertions concerning an
> identifier.
> 
> I would also suggest that the application in the blog world is
> accountability based rather than permissions based.
> 
> 
> As I see it the problem divides up into two major parts, 
> authentication
> and attributes.
> 
> I think that the DIX group should only address the 
> authentication part.
> There are already good standards based protocols for exchange of
> attributes, SAML for example. I don't see any value to revisiting that
> area, at the end of the day the issuer and the recipient of that
> information will both have to implement code. It is a back end office
> application that is going to require custom code whatever way 
> you slice
> it. 
> 
> If someone does think that there is a major technical advance possible
> over SAML attribute assertions I would prefer to work that 
> back into the
> SAML spec (there is a WG still operating).

i agree with you. 

> 
> The other reason for avoiding attributes is that that is where all the
> rat-holes lie. The Liberty org has spent years working up 
> business rules
> to govern transfer of personal data through closely coupled bilateral
> agreements. The IETF is not a good venue for such discussions, it is a
> technical organization, not a legal one.  
> 
> Where I think that we need to look at something different is on the
> authentication side. 

why do you think so? there is plenty of work on authentication. 
you are concerned about duplicated work in the are of security information exchange (namely saml in your case) but you are not concerned about the huge amount of authentication work out there. 

to be more specific with my question: 

a) do you want to define new authentication and key exchange protocols? 

b) do you want to work on mechanisms to transport (or encapsulate) authentication and key exchange protocols? 

> SAML has an authentication mechanism but it does
> not have quite the structure people seem to want to see.

saml does not have an authentication mechanism. 

> 
> In SAML the federation is closely coupled, it is assumed that there is
> an a-priori federation agreement in place before the authentication
> transaction takes place. At the time it seemed like this was the
> inevitable, the correct approach. I now think that open federation is
> possible and the way forward.
the term federation is just a fancy new term for an old concept. you can compare this with the aaa infrastructure. 

to make it simple: if the relying party does not directly or indirectly trust the asserting party then the whole concept does not work. (note that i particularly use the fuzzy term 'trust' here.) 

that's the same with the aaa infrastructure where the relationship between the different domains is typically based on business relationships. 

i got lost from here on...

> 
> On the attributes side of thing I think that one of the 
> points that has
> to be made here is that a lot of the personal information that flies
> around the web is not actualy needed at all. Publishers do 
> not actually
> care who reads their publication, it's the advertisers who 
> care. And the
> advertisers are in most cases looking to buy page views by particular
> demographic groups rather than looking for detailed information.
> 
> 
> The best way to get chartered to do the most urgent work is to propose
> to address only the authentication component and state that the group
> will rely on existing mechanisms (which do not even 
> necessarily need to
> be enumerated) to address attributes.
> 
> 
> The problem as I see it in the federated identity space is 
> that there is
> no simple, open federation protocol that allows a user to 
> easily use an
> identity across multiple sites that do not have prior interchange
> agreements (or rule book structure if you like) in place.
> 
> This is a very different application area to the one being 
> considered by
> Liberty. In bloggish applications I expect that the main application
> will be simply the authentication component, laying claim to an
> identifier.
> 
> 
> The term 'simple' really needs to be qualified. Simple FOR WHOM?
> 
> For a project to succeed in this space it must not exceed the 
> complexity
> requirement of any party invovled. However the complexity requirements
> of the different parties are very different:
> 
> 	Authentication service provider (user's agent)
> 	Relying party (blogger)
> 	User
> 
> I believe that for a scheme to be successful the user 
> experience myst be
> dramatically simpler than any that has been proposed to date. 
> In fact I
> do not think that we can expect any mechanism that involves an
> identifier that is any more complex than an email address is 
> going to be
> successful. 
> 
> Traditionally the approach has been to try to minimize complexity for
> all parties, I think that this is a mistake. The parties 
> responsible for
> administering the scheme at blogs or at authentication 
> service providers
> are going to be several orders of magnitude more 
> sophisticated than the
> least sophisticated users.
> 
> The Internet has a billion users, the point of DIX is not to serve the
> most sophisticated 10%, it is to serve the least 
> sophisticated. I think
> that it is well worth a marginal increase in sophistication on the
> administrator side if we can reduce complexity for the end user.
> 
> 
> The term 'secure' is going to get pounced on by the security people.
> Don't be surprised if you are required to write a threat 
> model. Although
> the group is looking to be chartered in applications that 
> will not stop
> the security people weighing in. In fact it may well be 
> considered that
> the group should be under security.
> 
> The issue that is most likely to get pounced on here is the problem of
> man in the middle and phishing attacks. The IETF has a policy that all
> new protocol standards MUST NOT require en-clair password 
> transmission.
> I suspect in this case the bar will be higher and the group will be
> required to produce a protocol that guarantees that the 
> password is not
> revealled to ANY party.
> 
> I think that this problem can be overcome but I have not yet completed
> my own security analysis.
> 
> 
> Finally I think that the charter must make clear that the 
> protocol will
> not involve the creation of any new registry. The Internet has one
> federated namespace - the DNS. If DIX is to be an Internet 
> protocol then
> the federation must be based on the DNS, either explicitly or
> implicitly.
> 
> The point here is enfranchisement and control, the whole rack 
> of layer 9
> issues that ICANN gets wrapped up in. To control your name on the
> Internet you have to own the domain name you rely on. If your web site
> is alice.blogsrus.com you are inevitably dependent on the continued
> terms of service of whoever owns the name blogsrus.com.
> 
> To be an Internet citizen rather than a serf you have to own your own
> domain name.
> 
> By implicit I mean a URI. The URIs used in YADIS/LID/OpenID/etc.
> ultimately rely on the DNS. Whoever owns the embedded DNS name can
> redefine the semantics for the rest of the name any way they 
> like. From
> a control point of view 
> http://yadis.blogsrus.com/people/alice is simply
> [email-masked] with more clutter. 
> 
> 

ciao
hannes
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of John Merrells
> > Sent: Thursday, January 12, 2006 10:41 PM
> > To: [email-masked]
> > Subject: [dix] Proposed Charter for DIX Working Group 
> > 
> > 
> > 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
> > 
> > -------------
> > 
> > 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
> > 
> > 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.
> > 
> > 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
> > 
> > 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.
> > 
> > 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
> > 
> > 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
> > 
> > 
> > 
> >