RE: [dix] Proposed Charter for DIX Working Group

"Hallam-Baker, Phillip" <pbaker@verisign.com> Fri, 13 January 2006 16:18 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRdM-0004ea-AW; Fri, 13 Jan 2006 11:18:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExRdK-0004eT-8K for dix@megatron.ietf.org; Fri, 13 Jan 2006 11:18:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19170 for <dix@ietf.org>; Fri, 13 Jan 2006 11:17:07 -0500 (EST)
Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExRka-0001vx-U1 for dix@ietf.org; Fri, 13 Jan 2006 11:26:05 -0500
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k0DGINVh018710; Fri, 13 Jan 2006 08:18:23 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 08:18:22 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dix] Proposed Charter for DIX Working Group
Date: Fri, 13 Jan 2006 08:18:22 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD3787A7A2@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: [dix] Proposed Charter for DIX Working Group
Thread-Index: AcYX83v6j8pNYn9hQECEXzIjLrQ12gAWcA0g
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: John Merrells <MERRELLS@SXIP.COM>, dix@ietf.org
X-OriginalArrivalTime: 13 Jan 2006 16:18:22.0693 (UTC) FILETIME=[F9665950:01C6185C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f
Content-Transfer-Encoding: quoted-printable
Cc:
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Sender: dix-bounces@ietf.org
Errors-To: dix-bounces@ietf.org

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).

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. SAML has an authentication mechanism but it does
not have quite the structure people seem to want to see.

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.

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
alice@blogsrus.com with more clutter. 



> -----Original Message-----
> From: dix-bounces@ietf.org [mailto:dix-bounces@ietf.org] On 
> Behalf Of John Merrells
> Sent: Thursday, January 12, 2006 10:41 PM
> To: dix@ietf.org
> Subject: [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 <hardie@qualcomm.com>
> Scott Hollenbeck <sah@428cobrajet.net>
> 
> Mailing Lists:
> 
> General Discussion: dix@ietf.org
> To Subscribe: dix-request@ietf.org
> 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
> dix@ietf.org
> https://www1.ietf.org/mailman/listinfo/dix
> 
> 

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix