Subject: [dix] draft proposed charter - consensus?

From: John Merrells <[email-masked]>
Date: Wed, 18 Jan 2006 17:55:10 -0800

Can I ask for a virtual show of hands on the draft proposed charter?
(See below if you missed it first time around.)

The question is: Would you support the creation of a working
group based on this charter?

Email a (yes/no + optional comment) to me. (Or the list if you wish,
but I don't want it to get too noisy.)

The next step is to request a BOF at IETF 65... but I'd like us to
get the proposed charter well and truly bashed before we get there.

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: "Suresh Venkatraman" <[email-masked]>
Date: Wed, 18 Jan 2006 20:02:30 -0800

Before putting forth a show of hands, I think we should hammer out the
proposed vocabulary, the scenarios, and specified methods in the charter
before a vote. In fact, is that not the purpose of this forum? I will start
with my take on the charter.

Vocabulary

	Identity or Digital Identity is not precisely defined - it should
be.

	User's Agent sounds too much like user-agent in HTTP terminology.
Potential Terms: User Agent Server (from SIP), Identity Authority, or
	User Identity Server

	Reputation Data - We should clarify this within the scenario...

Scenarios - Web sign-on and forms is not the only time user identity needs
to be asserted. XMPP and SIP sessions are important and different scenarios
that require identity and profiles. Not to discount logging into weblogs but
non-HTTP scenarios are just as important. This protocol should not be
service specific.

The HTTP binding spec is separate from the protocol spec (core). I would
suggest removing this section of the charter (it's another scenario):

> 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 general I think this charter should be slimed down to the essence of
digital identity exchange. Negotiation of authentication should be part of
the solution offered by this group so I would remove or change the

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
Merrells
Sent: Wednesday, January 18, 2006 5:55 PM
To: Digital Identity Exchange
Subject: [dix] draft proposed charter - consensus?

John

-----

Chairs

TBD

Mailing Lists:

Problem Statement

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.

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  

Work In Scope

Out of Scope

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

---

From: John Merrells <[email-masked]>
Date: Wed, 18 Jan 2006 20:29:46 -0800

> with my take on the charter.

On vocabulary... I don't mind what things are called just that we  
agree on
what they are... which could be an endless debate. I used the  
terminology
from this lexicon... even though I don't agree with all their  
definitions...

http://www.identitygang.org/Lexicon

Scenarios... There's aren't any in the charter. I think there's one  
example.
I felt that one illustrative one would make the document more  
accessible.

> 	Reputation Data - We should clarify this within the scenario...

I'm happy to remove it... as the rest of the text is fine without it.  
A reasonable
work item for a working group would be to document a set of motivating
use cases to inform the decisions of the group. Would that be  
preferable?

> that require identity and profiles.

A good example for a draft. I'm sure others on the list have good  
ideas too.
Not sure what we'd call this: 'Use Cases'? Or who'd write it? I'm kinda
swamped myself. Suresh? Anyone?

> Not to discount logging into weblogs but

The draft proposed charter makes that clear doesn't it?

"Any solution should support multiple transport layers,
but it is anticipated that this working group will focus on
a HTTP based solution. "

How would you change that statement?

> suggest removing this section of the charter (it's another scenario):

I think we have to say there's going to be at least one transport... and
HTTP is the most obvious one. I could call out this piece of text so  
that
it's clear that it applies to the HTTP transport binding.

>> solution.
>> require

I think that it is. Are you asking for an in-scope statement to that  
effect?

>> The mechanisms by which authentication and authorization are  

To me negotiation and mechanism are different things. Perhaps we are
misunderstanding each other. For example:

Authentication Mechanism:

username / password

Authentication Negotiation:

HS to MS: 'I can authenticate using mechanisms: username-password, 2- 
factor device, dna test'
MS to HS: 'Please authenticate the user with mechanism: 2-factor  
device.'

Does that clarify that out of scope statement?

John

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Wed, 18 Jan 2006 21:09:32 -0800

> I felt that one illustrative one would make the document more  

Yes, I meant examples - "For example, signing in to web pages and completing
user registration forms."

> A reasonable work item for a working group would be to document a set of
> motivating use cases to inform the decisions of the group. Would that be  
> preferable?

A use case document is a good for keeping the proposed WG on track - like
the following for p2p-sip:

http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.txt

> Does that clarify that out of scope statement?

Yes it does.

I was looking at a couple of charters when I stated "simplicity" although
the proper term may be clarity:

http://www.xmpp.org/wg-charter.html
http://www.ietf.org/html.charters/manet-charter.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
Merrells
Sent: Wednesday, January 18, 2006 8:30 PM
To: Digital Identity Exchange
Subject: Re: [dix] draft proposed charter - consensus?

username / password

John

---

From: John Merrells <[email-masked]>
Date: Wed, 18 Jan 2006 21:23:07 -0800

> http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.txt

A nice piece of work. We did something similar in the LDUP WG.

Should a use case draft be added to the charter milestones?
I think it's worthy, but want to make sure there's sufficient interest
from the group, and someone willing to step up to editing the
draft.

> http://www.ietf.org/html.charters/manet-charter.html

I could wordsmith the text so that the word 'simple' isn't used, but
it seems like a worthy overriding goal to me. Maybe if I drill into
what simple means? Simplicity in the order of... for the user,  for
  the relying party, and finally for the agent implementor. (I think
I offered that up an other email to this list earlier in the week.)

(BTW: I agree that Agent and User Agent is unfortunate naming...)

John

---

From: Ben Laurie <[email-masked]>
Date: Thu, 19 Jan 2006 13:27:10 +0000

John Merrells wrote:
> 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.

This seems overly prescriptive. In particular, it would appear to
exclude any kind of temporary certificate. It also excludes proxies. Oh,
and the case where authentication occurs elsewhere.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Peter Davis <[email-masked]>
Date: Thu, 19 Jan 2006 11:32:26 -0500

> the development of software agents to manage a user¹s identity
> information.
Perhaps you mean management of the exchange of user attributes and
authentication states between parties.  'managing identities' implies to my
read as a sw which manages the storage of user data

> the user, their agent, and a relying party. The user¹s agent is where

+1 on Ben's comment wrt this paragraph

> solution. In this case the user¹s software is a web browser, to which
> no modifications should be required,
Well, it's an HTTP client.

> and the relying party would be a
> website.

Well, it's an HTTP aware server, which listens for HTPP messages.

> Continuing with the theme of simplicity a website should
> separation between the identifier and the user¹s agent. In the

How about simply that it is in scope to establish a 'uniform addressing
mechanism', such as a URI.
 
> March 2006  BOF meeting

Definitely need use cases milestone, IMHO

=peterd

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jan 2006 10:01:58 -0800

> and the case where authentication occurs elsewhere.

Hey Ben, would you take the time to write up simple use cases for  
your three points so that we (or at least I) can understand them?

-- Dick

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 11:45:00 -0800

> Definitely need use cases milestone, IMHO

There seems to be plenty of support for this.
I've added a 'Dix Use Cases ID' milestone.

John

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 11:53:58 -0800

> Well, it's an HTTP aware server, which listens for HTPP messages.

Rewritten this paragraph so that it's more formal:

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

---

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

> read as a sw which manages the storage of user data

A subtle point, but a good one. It will enable 'storage of', but that's
not the only thing, and not the main thing. How about...

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

John

---

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

> mechanism', such as a URI.

To which piece of the above does that apply? The last three sentences?

The term 'addressing' worries me a little. That might just be a knee
jerk reaction from me though, based on my LDAP experience. A
key aspect of any information/data model is the separation between
addressing things and identifying things. In LDAP the DN was
both, which caused me lots of pain trying to solve the distribution
and replication problems... which lead to adding the entryUUID
attribute, so that we had immutable names for entries....
(I could ramble on for hours about that...)

I'd be happier with 'uniform naming mechanism', which could be a
URI... people may want something other than an URI.

John

---

From: Ben Laurie <[email-masked]>
Date: Thu, 19 Jan 2006 22:02:15 +0000

Dick Hardt wrote:
> Hey Ben, would you take the time to write up simple use cases for your
> three points so that we (or at least I) can understand them?

Temporary certificate

This is to satisfy the minimality requirement. User has cert including
date of birth, say, and wants to prove he's over 21. So, he (or his
agent) shows the cert to some CA that produces a temporary cert for him
saying he's over 21, which he or his agent then shows to the relying party.

Note that this only half gets you unlinkability if the certs are
anything conventional because the CA can link the permanent and
temporary certs.

The CA is, of course, a fourth party in the transaction.

Proxy

Not sure exactly what to say about this, except that a proxy could sit
between any of these parties, and the language above assumes that it can
do so both transparently and securely. Which may not be so (that is, it
may have to be non-transparent to remain secure) if it adds
functionality, like caching, or anonymising.

Authentication Elsewhere

It may turn out that for whatever reason I have to use multiple agents,
so I'd like to authenticate them via my meta-agent. Unlinkably.

Cheers,

Ben.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jan 2006 14:16:12 -0800

On 19-Jan-06, at 2:02 PM, Ben Laurie wrote:

>> your

I understand this one.

> functionality, like caching, or anonymising.

I understand what you are saying here as well (proxy has a number of  
meanings)

> so I'd like to authenticate them via my meta-agent. Unlinkably.

I would say that the meta-agent is  your agent.

I think that John's identity exchange description above needs fleshed  
out some more.

The obvious missing party that *may* be in the transaction is a 3rd  
party making a claim about the user, that is part of the transaction  
when viewed holistically.

-- Dick

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 17:49:21 -0800

>> The CA is, of course, a fourth party in the transaction.

I think of that as two transactions. One to acquire the claim, the other
to present the claim, even if the claim if thrown away after it's  
presented.

But I can see why my wording appears to exclude that.

> I understand what you are saying here as well (proxy has a number  
> of meanings)

Yeah... I just assumed that was part of the infrastructure that the  
protocol
ran over... so I should call that out.

> I would say that the meta-agent is  your agent.

Yeah.

John

---

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

On the topic of three parties.... I think this covers the case of  
authoritative sources of claims... and the possibility of proxy  
services...

"An identity information exchange should involve just three principal  
parties: the user, their agent, and a third party. The user’s agent  
is where they authenticate themselves and a repository where they  
store their identity information and the third party is a relying  
party requesting identity information or an authoritative source  
providing identity information. Non-principal parties may participate  
in an information exchange by providing facilitating services, such  
as proxying or caching."

John

---

From: Ben Laurie <[email-masked]>
Date: Fri, 20 Jan 2006 04:34:03 +0000

> I would say that the meta-agent is  your agent.

Err, you have made the agent the place where you authenticate and the
place where your stuff is stored, so you might like to, but you can't.

Cheers,

Ben.

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 20:55:04 -0800

> place where your stuff is stored, so you might like to, but you can't.

mmm... how about I add agency as a non-principal party...

"Non-principal parties may participate in an information exchange by  
providing facilitating services, such as proxying, caching or agency."

John

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jan 2006 22:23:08 -0800

> place where your stuff is stored, so you might like to, but you can't.

Picky, picky -- and correct. Both are acting as agent though are they  
not? You may have your stuff stored in a few places.

---

From: "Haripriya S" <[email-masked]>
Date: Fri, 20 Jan 2006 00:05:59 -0700

I think the original wording - 'relying party' is more appropriate than
'third party' because a third-party does not actually tell me that the
party has is a required entity in this transaction.

Thanks,
Haripriya S.
 
>>> [email-masked] 01/20/06 9:42 am >>> 

parties: the user, their agent, and a third party. The user's agent 

is where they authenticate themselves and a repository where they  
store their identity information and the third party is a relying  
party requesting identity information or an authoritative source  
providing identity information. Non- principal parties may participate 

John

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 23:24:39 -0800

> party has is a required entity in this transaction.

Yeah, 'relying party' was good, but as Ben pointed out (and Peter
supported) that it didn't really cover the case of a party providing
the user with some identity information, either an attribute value
assertion or a digitally signed claim. A 'relying party', by the  
Identity
Gang lexicon is a consumer rather than a producer of identity
information. They use the term 'claimant' for something that
creates claims.... I don't really like that very much, so wrote
'authoritative source' instead. Hopefully that explains why I'm
proposing that change.

John

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jan 2006 23:36:52 -0800

> 'authoritative source' instead. Hopefully that explains why I'm

I'm confused.

Relying Party = Membersite

Authorative Source = 3rd party = Authorative Site

---

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

> Authorative Source = 3rd party = Authorative Site

Yes, but I think that the same protocol can be used between the
user's agent (homesite) and a relying party (membersite) or
authoritative source (authoritative site).

John

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Jan 2006 23:43:54 -0800

> authoritative source (authoritative site).

When going from HS -> AS, the AS is really a MS.

When going from AS -> HS (store), then it is an AS, and at that time  
is party to the transaction

I think there is BIG value to us in AS being 3rd party and MS NOT  
being 3rd party -- as it clearly makes the AS not be part of the  
primary transaction

-- Dick

---

From: John Merrells <[email-masked]>
Date: Thu, 19 Jan 2006 23:56:37 -0800

On 19-Jan-06, at 11:43 PM, Dick Hardt wrote:

> When going from AS -> HS (store), then it is an AS, and at that  
> time is party to the transaction
>

Ah yes, 'Third Party' is commonly taken to refer to a party outside  
the transaction whom has given the first party something for  
presentation to the second party. Goodness this is fun. I'll ponder  
on an agreeable term for the second party. Oh, maybe that's the term?  
Maybe we define FP, SP, and TP... 1P, 2P, 3P... where 1P is the  
user's agent, 2P is the relying party, and 3P is the authoritative  
source.

John

---

From: Ben Laurie <[email-masked]>
Date: Fri, 20 Jan 2006 11:22:40 +0000

> not? You may have your stuff stored in a few places.

That was my point, but the proposal limits you to one.

---

From: Peter Davis <[email-masked]>
Date: Fri, 20 Jan 2006 09:54:42 -0500

On 1/20/2006 2:24 AM, "John Merrells" <[email-masked]> wrote:

> A 'relying party', by the Identity

s/authoritative source/asserting party/

It's up to the relying party to decide how ' authoritative' the claim is

=peterd  (http://public.xdi.org/=peterd)

---

From: Peter Davis <[email-masked]>
Date: Fri, 20 Jan 2006 10:37:12 -0500

> To which piece of the above does that apply? The last three sentences?

Yeah, the identifier part.

> jerk reaction from me though, based on my LDAP experience.

But that is what you get whenever you make a string (even opaque) in some
namespace. When I give my dog a name, it's really just virgil.peterdavis
(using, at least, a DNS like delegation notation).

This WG should not invent new identifiers.  Use one of the (too) many we've
got already.  

But I agree wrt the terms use here.  s/address/identifier/;  but we'll get
both in the end.  With the identifier alice, when asserted by foo, you kinda
always end up with an address alice@foo (or if you prefer alice!fred ;-)

> A

Yes, I fully agree.  We tend to overload the identifier with other duties.
 
> URI... people may want something other than an URI.

That works too.

---

From: Peter Davis <[email-masked]>
Date: Fri, 20 Jan 2006 10:39:15 -0500

On 1/19/2006 3:06 PM, "John Merrells" <[email-masked]> wrote:

> user¹s identity information."

Yes, improved.

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 20 Jan 2006 14:18:40 -0500

It is clearer, but I think the charter still needs to be
clearer about what is meant by "digital identity".  Is
the purpose to be able to access *any* stored data about
a person, or *specific* stored data?

In many regards, saying "any" is easier; sort out the format
for expressing attribute/values, and you're done.  However,
then there are issues of interoperability (is there a minimum
set of identity data that is mandatory to provide?).

And, if it is "any", then how is this not a directory service
with additional labelling (addresses/names/identifiers) on top?

Leslie.

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 12:03:08 -0800

> It's up to the relying party to decide how ' authoritative' the  

Ack.

John

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 12:07:43 -0800

On 19-Jan-06, at 11:56 PM, John Merrells wrote:

> on an agreeable term for the second party. Oh, maybe that's the  
> term? Maybe we define FP, SP, and TP... 1P, 2P, 3P... where 1P is  
> the user's agent, 2P is the relying party, and 3P is the  
> authoritative source.

OK...

We have principal and non-principal parties, which gets Ben his  
useful intermediaries.

And, now i use 'the other party' to refer to the party at the other  
end... and then state clearly that it's either a relying party or an  
asserting party. (Thanks Peter)

"An identity information exchange should involve just three principal  
parties: the user, their agent, and another party. The user’s agent  
is where they authenticate themselves and a repository where they  
store their identity information and the other party is either a  
relying party requesting identity information or an asserting party  
providing identity information. Non-principal parties may participate  
in an information exchange by providing facilitating services, such  
as proxying, caching or agency."

John

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 12:17:46 -0800

> (using, at least, a DNS like delegation notation).

Grumble... probably best as a beer based conversation. I award you one
beer token for redemption at the Dallas IETF.

> This WG should not invent new identifiers.  Use one of the (too)  

Agree.

> always end up with an address alice@foo (or if you prefer alice! 

Good.

>> URI... people may want something other than an URI.

OK

Was...

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.

Is now...

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.

John

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 17:36:22 -0800

> a person, or *specific* stored data?

'any'... but the relying party has to know the name of
the thing it's asking for.

> for expressing attribute/values, and you're done.

Yes, that's been the plan so far. Other's can provide the
names of the attributes and the syntax and semantics of
the values. That could be done in the IETF, or in another
standards body, or by industry consortia, or just be a
free for all folksonomy kind of thing

> However,

Mmm, I'd say 'no', but Scott might say 'yes'. I'm reluctant
to end up down the schema rathole arguing over things
like mobilephone versus cellphone... for example.

> with additional labelling (addresses/names/identifiers) on top?

I think that the DIX and LDAP information models will
turn out to be very similar indeed. But I don't think that's
what distinguishes user's agent from a directory service.

In the directory centric model the user informs the
relying party of their DS and the RP does a search
against the DS for the user's attributes, perhaps
using some credentials provided by the user, or
with some credentials provided to the RP by the
DS beforehand.

In the user centric model the RP requests some
data from the user who forwards the request to
their agent, selecting the data items, providing
consent for their release and then forwards them
to the RP.

Same parties, different protocol flow... with greater
user privacy. Kim Cameron's 'Seven Identity Laws',
make it pretty clear why the directory centric model
doesn't work for digital identity, and explains why
Microsoft Passport was not widely adopted outside
of the MSN universe.

John

---

From: Phil Hunt <[email-masked]>
Date: Fri, 20 Jan 2006 20:13:40 -0800

John

Directory Centric Model doesn't work?  I agree completely.  Pretty  
amazing for an LDAP guy!  However, I would argue strongly that both  
the directory repository (database or whatever) and the user centric  
model are needed.  Example, you have your driver's license, but the  
government has a database that has all the details on all licenses  
issued and whether it is revoked and how many points you have lost  
(gee...starting to sound like PKI  all over again ;-) ).

Also, no matter what happens with directory or identity exchange,  
there will always be the application that has to store data.  Where  
this all breaks down is what happens when the application needs to  
maintain context.  In this sense, I'm worried about what happens when  
the user chooses to present a different credential each time.  This  
actually makes life for the application programmer even more  
difficult.  In the end he has to ask more questions like what is your  
social sec number or SIN. Hmmm....pretty soon we end  up repeating  
history.

The key is NOT to build a system that is 100% one way or the other.   
The huge uber directory definitely won't work. Neither will the  
"user" uber-card. What we need is an easy-to-use and manage and safe  
system that combines the 7-laws and the correct mix of technologies.   
Just like routers made it easy to inter-connect discreet networks  
into the huge global network we take for granted, we really need an  
ecosystem to link assertions and authorities in verifiable, portable,  
and secure ways.

I think there are really two macro profiles to think about --  
"Session" and "Storage" modes.   Session mode is really where we see  
SAML, SXIP and others playing (the 2.0 team) - where one application  
wants to pass data or assertions on to another service with a  
portable assertion.  The still important "storage mode" is where all  
the authoritative stores that comprise the permanent data goes to and  
comes from when the session based application needs to assert or  
consume something.

Phil Hunt

Note: These comments represent my own personal opinions and do not  
necessarily represent those of Oracle.

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 21:04:39 -0800

On 20-Jan-06, at 8:13 PM, Phil Hunt wrote:

> John
>
> Directory Centric Model doesn't work?

Well, I didn't make quite as bold a statement as that, but within the  
context of end users roaming about on Internet it hasn't helped them  
create a portable digital identity...

> I agree completely.  Pretty amazing for an LDAP guy!  However, I  
> would argue strongly that both the directory repository (database  
> or whatever) and the user centric model are needed.

Yes indeed.

> Example, you have your driver's license, but the government has a  
> database that has all the details on all licenses issued and  
> whether it is revoked and how many points you have lost  

Maybe not the best example, but if I were a government agency then  
the DCM might work for me because I have the connections and the  
expertise to establish the trust and federation relationships to make  
it work. But if I'm putting up website to be an intermediary between  
users and insurance companies then the UCM is probably better... I  
might ask the user to provide me with a claim that within a year  
they've held a clean license. The user might already have one... or  
they can go get one from the state government from where ever they  
reside. Much quicker and cheaper and possibly as realtime as needed  
to get an insurance quote... right now that's all self asserted... so  
this is better.

> maintain context.

Don't really grok that. They app can store it's session or user  
associated state local to itself, on the users client if it allows it  
(cookie), in it's own property in the agent (if the user allows it).  
(In dmd1 we even allow state to be added to the request message for  
return with the response message.)

> In this sense, I'm worried about what happens when the user chooses  
> to present a different credential each time.

Do you mean identifier? That's a good thing for the user.

> This actually makes life for the application programmer even more  
> difficult.

Makes no difference. Makes it harder for them to track the user  
across space and time, which is a good thing. If they want to do that  
they should negotiate it with the users like the supermarkets do in  
meat space. Customer tracking card for a 5% discount, sir? yes please  
don't mind if I do.

> In the end he has to ask more questions like what is your social  
> sec number or SIN. Hmmm....pretty soon we end  up repeating history.

User's won't accept that, so app programmer won't do it. They'll have  
to offer the users something in return for tracking them.

> The key is NOT to build a system that is 100% one way or the  
> other.  The huge uber directory definitely won't work. Neither will  
> the "user" uber-card.

Sure, horses for courses.

> What we need is an easy-to-use and manage and safe system that  
> combines the 7-laws and the correct mix of technologies.  Just like  
> routers made it easy to inter-connect discreet networks into the  
> huge global network we take for granted, we really need an  
> ecosystem to link assertions and authorities in verifiable,  
> portable, and secure ways.

Here here.

> "Session" and "Storage" modes.   Session mode is really where we  
> see SAML, SXIP and others playing (the 2.0 team) - where one  
> application wants to pass data or assertions on to another service  
> with a portable assertion.  The still important "storage mode" is  
> where all the authoritative stores that comprise the permanent data  
> goes to and comes from when the session based application needs to  
> assert or consume something.

Well yes, there's protocols, and there's endpoints.... that's pretty  
much a given.

Do you work for a storage company Phil? :-P

John

---

From: "Tom Doman" <[email-masked]>
Date: Tue, 24 Jan 2006 10:23:03 -0700

Yes, Leslie, taking your thought further, it makes me wonder, how does the DIX protocol end up being much different from SAML?  Dick, I know you like to discount SAML due to RSA licensing issues (which is a very relevant point), but I'd like to have you weigh in on the other material differences you might anticipate in the DIX protocol itself.  In other words, where else do you think SAML is lacking or perhaps inappropriate for digital identity information exchange?
 
Regards,
Tom

>>> [email-masked] 1/20/2006 12:18:40 pm >>>

Leslie.

---

From: "Tom Doman" <[email-masked]>
Date: Tue, 24 Jan 2006 10:47:58 -0700

Replying to myself here ... I'll have to reread the charter and get deeper into the draft but, perhaps the intent here is not to worry about the data model, just how to pass "whatever it is" around.
 
Tom

>>> [email-masked] 1/24/2006 10:23:03 am >>>
 
Regards,
Tom

Leslie.

---

From: Boris Mann <[email-masked]>
Date: Tue, 24 Jan 2006 10:37:01 -0800

On 24-Jan-06, at 9:47 AM, Tom Doman wrote:

> Replying to myself here ... I'll have to reread the charter and get  
> deeper into the draft but, perhaps the intent here is not to worry  
> about the data model, just how to pass "whatever it is" around.

Theoretically, DIX could be SAML-compliant, if passed the correct  
"whatever it is" around.

--
Boris Mann

> Yes, Leslie, taking your thought further, it makes me wonder, how  
> does the DIX protocol end up being much different from SAML?  Dick,  
> I know you like to discount SAML due to RSA licensing issues (which  
> is a very relevant point), but I'd like to have you weigh in on the  
> other material differences you might anticipate in the DIX protocol  
> itself.  In other words, where else do you think SAML is lacking or  
> perhaps inappropriate for digital identity information exchange?
>
> Regards,
> Tom
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 25 Jan 2006 00:13:31 -0800

> perhaps inappropriate for digital identity information exchange?

Hey Tom

I think the SAML authors did a great job of standardizing a language  
to represent assertions to be moved between systems, and was driven  
by vendors wanting to enable interop with between their enterprise  
solutions.  I think it is/was difficult from that point of reference  
to think of how to move digital identity around at Internet scale, or  
to scale down the required technological footprint for low risk, low  
value identity transactions. Processing digitally signed XML is much  
harder then fetching an HTML page and working with name/pairs. SAML  
is pretty heavy to move my name, email address and blog URL. It also  
does not integrate well into existing applications. The ID submitted  
allows an existing form to use DIX with the addition of HTML, and no  
change to the existing form processing code (assuming the required  
fields are available)

Given the growing number of solutions that produce and consume SAML ,  
it would be *good* for DIX to be able to move around SAML tokens,  
just as Microsoft states they will do with their meta-system / Infocard.

Summary: The token part of the SAML specs map to a type of thing that  
can be moved around DIX, the protocol part is missing chunks and is  
not light enough.

-- Dick