Subject: [dix] draft-merrells-dix-01

From: John Merrells <[email-masked]>
Date: Tue, 17 Jan 2006 14:05:27 -0800

DIX-ers,

Here's an individual submission of a draft specification of a  
'Digital Identity eXchange' protocol.

This should further clarify the constrained scope we envisage for  
this group.

As ever, your comments will be most gratefully received. Please take  
care though to be clear about what your comments apply to: the  
proposed charter (charter), this individual submission (draft- 
merrells), an alternative individual draft (draft-xxx), or to the  
ultimate output of a working group (um, draft-ietf?).

John

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

---

From: Pete Rowley <[email-masked]>
Date: Fri, 20 Jan 2006 11:48:38 -0800

> 'Digital Identity eXchange' protocol.

The draft identifies the user via a persona url, and there is a 
parameter in the fetch request that may request the persona url (and 
another which requests multiple persona urls).  To clarify, the 
intention is that after/during homesite user authentication that the 
persona-url is resolved for the homesite i.e. that the user chooses the 
persona-url at some point or alternatively it is chosen for them by the 
homesite based on their local credentials.  To clarify further - it is 
not a requirement that this persona-url be resolvable in any meaningful 
sense other than as an arbitrary identifier.

Also, what responsibilities does the homesite have for the validity of 
the information supplied?  Should it only return information from a 
trusted source or is it acceptable to ask the user for data it doesn't 
know about?  Should this be a protocol level decision?  Assuming some 
level of trust has been established between the homesite and the 
membersite it might be useful to be able to specify this on an 
individual attribute basis.  Or maybe I am way off base here, and the 
intent is that the homesite gives what it can and it is up to the 
homesite to get the rest, possibly resulting in a store-request?

-- 

Pete

---

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

On 20-Jan-06, at 11:48 AM, Pete Rowley wrote:

> parameter in the fetch request that may request the persona url  
> (and another which requests multiple persona urls).  To clarify,  
> the intention is that after/during homesite user authentication  
> that the persona-url is resolved for the homesite i.e. that the  
> user chooses the persona-url at some point or alternatively it is  
> chosen for them by the homesite based on their local credentials.   
> To clarify further - it is not a requirement that this persona-url  
> be resolvable in any meaningful sense other than as an arbitrary  
> identifier.

Dmd1 defines the Persona URL to be a URL... so it's syntax is limited  
to that of a URL, so it's not totally arbitrary.

Does it have to be resolvable? Well it's optional whether the  
Membersite fetches the Persona Page at the end of the Persona URL to  
check for the Delegation Tag to ensure that the Homesite stated in  
the fetch-response message really has been delegated authority to  
authenticate that Persona URL.... so in theory if the Membersite  
didn't do that then it wouldn't really be optional... but the  
Homesite doesn't know if the Membersite is going to perform that part  
of the Verification Process so it must provide a resolvable Persona  
URL for the user. Of course if that were a useful feature then we  
could have a capability for the Membersite to declare that it wasn't  
going to verify the Persona URL...

Interesting question... Do you have a cunning idea that motivated  
that? Perhaps a use case for the DIX Use Case ID?

> Also, what responsibilities does the homesite have for the validity  
> of the information supplied?

None.

Dmd1 doesn't cover claims, just permits them to be moved around.

In the charter discussions we've said that an asserting party can make
claims about an identity... which can be acquired by the user, stored
in their agent, and presented to relying parties upon request.

> Should it only return information from a trusted source or is it  
> acceptable to ask the user for data it doesn't know about?

The Homesite can ask the user for self asserted attribute values.

It's up to the Membersite whether self asserted attribute values or  
third party asserted attribute values are acceptable. It does this in  
the fetch request by listing the properties it requires... self  
asserted and third party asserted have different names.

> Should this be a protocol level decision?

MS decision, by the protocol facilitates it.

> Assuming some level of trust has been established between the  
> homesite and the membersite it might be useful to be able to  
> specify this on an individual attribute basis.

Indeed. The above explains how that happens I think.

> Or maybe I am way off base here, and the intent is that the  
> homesite gives what it can and it is up to the homesite

think you must mean membersite there.

> to get the rest, possibly resulting in a store-request?

Assuming the above change: Exactly!

Cheers

John

---

From: Pete Rowley <[email-masked]>
Date: Fri, 20 Jan 2006 13:37:20 -0800

John Merrells wrote:

> authenticate that Persona URL....

Isn't it the _user_ that delegates that authority by providing the 
homesite-url in the first place?  And hasn't the membersite shown its 
willingness to do so by actually performing the function?  And the proof 
that it did in fact perform the function is the next part of the 
verification process - ensuring  it sent the fetch-response message.

> that? Perhaps a use case for the DIX Use Case ID?

I am looking at how a DMD1 homesite can be implemented using an external 
data source / identity authority (say, an LDAP directory server) using 
existing http server features (apache).  So purely from that view point 
I would like to avoid having to have a file for each "persona".

> asserted and third party asserted have different names.
Different names?  So, are you saying the sxip#1 capabilities only come 
from sxip and if I want to supply say, a user first name, from some 
other authority I would need to name the property differently?

-- 
Pete

---

From: Pete Rowley <[email-masked]>
Date: Fri, 20 Jan 2006 14:25:12 -0800

Pete Rowley wrote:

> willingness to do so by actually performing

ack s/membersite/homesite/

> the function?  And the proof that it did in fact perform the function 
> is the next part of the verification process - ensuring  it sent the 
> fetch-response message.
>
> I am looking at how a DMD1 homesite can be implemented using an 
> external data source / identity authority (say, an LDAP directory 
> server) using existing http server features (apache).  So purely from 
> that view point I would like to avoid having to have a file for each 
> "persona".
>
>> third party asserted attribute values are acceptable. It does this 
>> in  the fetch request by listing the properties it requires... self  
>------------------------------------------------------------------------
>

-- 
Pete

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 14:30:10 -0800

On 20-Jan-06, at 1:37 PM, Pete Rowley wrote:

>> Membersite fetches the Persona Page at the end of the Persona URL  
>> to  check for the Delegation Tag to ensure that the Homesite  
>> stated in  the fetch-response message really has been delegated  
>> authority to  authenticate that Persona URL....
>
> homesite-url in the first place?  And hasn't the membersite shown  
> its willingness to do so by actually performing the function?  And  
> the proof that it did in fact perform the function is the next part  
> of the verification process - ensuring  it sent the fetch-response  
> message.

The verification process has two steps: delegation check and message  
verification. Both are there to guard against different kinds of man- 
in-the-middle attacks. The security considerations calls those out.

> server) using existing http server features (apache).  So purely  
> from that view point I would like to avoid having to have a file  
> for each "persona".

Ah, OK. Two options I think.

1) The user already has a page, to which there's a url, that's their  
persona url. The directory then has an attribute on the user's entry  
containing that persona url. The user then adds a delegation tag to  
their page delegating auth to your DS-as-a-HS server.

2) The user doesn't have a page, so your DA-as-a-HS effectively has  
to provide one. How about you provide a virtual page for each user...  
so everything below a base path is mapped onto the same simple page  
that just delegates auth to your server. That would make sense for an  
enterprise, since they own the enterprise.com domain that both the DS- 
as-a-HS runs on and where all the persona urls are hosted.

>> It's up to the Membersite whether self asserted attribute values  
>> or  third party asserted attribute values are acceptable. It does  
>> this in  the fetch request by listing the properties it  
>> requires... self  asserted and third party asserted have different  
>> names.
>>
> Different names?  So, are you saying the sxip#1 capabilities only  
> come from sxip and if I want to supply say, a user first name, from  
> some other authority I would need to name the property differently?

With dmd1yes. The query mechanism is super brain dead simple... you  
can reference a property value and that's it.

My name as a self asserted attribute value might be:

dix:/central-naming-authority/name/first

And, my name as a digitally signed third party attribute value might be

dix:/central-naming-authority/signed/name/first
or
dix:/central-naming-authority/name/first.signed
or
something else.

Or we could extend the query language to make this type part of the
request, but I'm trying to avoid yet another query language...

John

---

From: Pete Rowley <[email-masked]>
Date: Fri, 20 Jan 2006 16:15:28 -0800

>> Different names?  So, are you saying the sxip#1 capabilities only  
come from sxip and if
 >> I want to supply say, a user first name, from  some other authority 
I would need to
 >> name the property differently?

> can reference a property value and that's it.
So, what is a home site to do if sxip attributes are requested?  Run off 
to sxip.net with an intermediate request (utilizing a previously agreed 
trust), or send the user as a membersite with a fetch-request, fail the 
request?  Seems to me that the membersite ought to be getting those 
attributes from sxip.net, who is acting as a home site, nobody else 
needs to be involved - not even the draft :)

> request, but I'm trying to avoid yet another query language...

Perhaps this is the missing dix#1 capabilities, but the benefits of this 
are substantially reduced if instead of identity silos, we end up with 
attribute silos.  The example attributes that are sxip#1 in that 
document are prime candidates for dix#1, and sxip#1 if anything, should 
be a separate draft detailing that schema - and btw, where do the dix#1 
capabilities fit into this model, who supplies those, or is dix#1 the 
(to come) common schema as I am hoping?

I have to say I am not sold on the idea of compartmentalizing properties 
first by source.  I would rather see a property type schema where the 
source of the property is not tied down, only its meaning.  The source 
of the property can be disclosed (as a signature) for those membersites 
that care, then user supplied attributes may simply not be signed.  In 
fact, in many common cases the source _will_ be the user anyway.

dix use case:

About 10 years ago I realized amazon basically had the monopoly on my 
book buying, then video buying, then whatever because the barrier for me 
was filling out another form with a bunch of details I don't have 
memorized.  Nothing has changed in those 10 years.  So, I want to go to 
Barnes and Noble and buy a book without filling out any forms, and 
without "joining" the website in any way, I want a one time transaction 
just like I get in a store, and given that I am authenticated with my 
homesite I want a one click transaction.  All details supplied are no 
more or less trustworthy than those I would type in myself even if my 
browser were acting as the homesite.

This doesn't work if I have amazon#1 properties and B&N want B&N#1 
properties.  It should be hard for that situation to arise, and the 
least path of resistance should be an ietf draft detailing the generic 
schema.

-- 

Pete

---

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

On 20-Jan-06, at 4:15 PM, Pete Rowley wrote:

>> With dmd1yes. The query mechanism is super brain dead simple...  
>> you  can reference a property value and that's it.
>>
> So, what is a home site to do if sxip attributes are requested?   
> Run off to sxip.net with an intermediate request (utilizing a  
> previously agreed trust), or send the user as a membersite with a  
> fetch-request, fail the request?  Seems to me that the membersite  
> ought to be getting those attributes from sxip.net, who is acting  
> as a home site, nobody else needs to be involved - not even the  
> draft :)

There's no connection between the names of the attributes and where  
the attribute values are actually stored. I can store 'dix://sxip.net/ 
name=john' anywhere I want to. The idea of the authority in the name  
is to provide anyone with a domain name their own piece of namespace  
to create whatever property names they want.

> Perhaps this is the missing dix#1 capabilities, but the benefits of  
> this are substantially reduced if instead of identity silos, we end  
> up with attribute silos.  The example attributes that are sxip#1 in  
> that document are prime candidates for dix#1, and sxip#1 if  
> anything, should be a separate draft detailing that schema - and  
> btw, where do the dix#1 capabilities fit into this model, who  
> supplies those, or is dix#1 the (to come) common schema as I am  
> hoping?
>
> I have to say I am not sold on the idea of compartmentalizing  
> properties first by source.

I think most of this comment was based on your misunderstanding  
above... so no silos....

> I would rather see a property type schema where the source of the  
> property is not tied down, only its meaning.  The source of the  
> property can be disclosed (as a signature) for those membersites  
> that care, then user supplied attributes may simply not be signed.   
> In fact, in many common cases the source _will_ be the user anyway.

That's exactly what I think we need and what I believe dmd1 enables.

> dix use case:
>
> About 10 years ago I realized amazon basically had the monopoly on  
> my book buying, then video buying, then whatever because the  
> barrier for me was filling out another form with a bunch of details  
> I don't have memorized.  Nothing has changed in those 10 years.   
> So, I want to go to Barnes and Noble and buy a book without filling  
> out any forms, and without "joining" the website in any way, I want  
> a one time transaction just like I get in a store, and given that I  
> am authenticated with my homesite I want a one click transaction.   
> All details supplied are no more or less trustworthy than those I  
> would type in myself even if my browser were acting as the homesite.
>
> least path of resistance should be an ietf draft detailing the  
> generic schema.

Great example of the rathole I don't want this group to go down.  
There are various social models for working out agreements for the  
names of things. Standards bodies seem to be a pretty bad one. XML  
dodged this one quite nicely, creating a schema language and   
devolving the problem to those who cared most about resolving them. I  
don't really want to get too into this now though. Another great  
conversation best handled over a beer?

John

---

From: Pete Rowley <[email-masked]>
Date: Fri, 20 Jan 2006 19:23:18 -0800

> I think most of this comment was based on your misunderstanding  
My misunderstanding is based on the fact that the sxip attributes are in 
the document yet apparently only sxip.net can supply the values (no 
matter where they are stored).

In that case I don't understand

a) why they are documented since there does not appear to be point of 
interoperability (these are for your website?),

b) why a homesite would need to explicitly "support" the sxip#1 
capability and advertise that support, since for the homesite they are 
opaque attributes and it can either choose to allow the storage of 
opaque random attributes or not, and any one user either has those 
attributes or not - or is this a crude form of access control for 
homesite storage?, where is the capable in capability?

and c) what exactly is the homesite expected to do to "tailor its 
response" when presented with the dix:/membersite-accept when it has no 
real knowledge of the attributes involved beyond what they are called 
(and presumably the membersite requests only what it does understand.)

Sorry to bang on about this, but I am actually trying to cut code here :)

> That's exactly what I think we need and what I believe dmd1 enables.
What I mean by "meaning" is really the "universally understood meaning" 
- not one meaning that only one entity understands .   Without 
universally understood meanings for a set of defined attributes dix 
would merely be a means to use somebody elses hard drive for data 
storage.  There may be value in that for all parties, but the greater 
value is when everyone talks the same language, not just the same protocol.

> names of things. 

None of which work terribly well once you switch on the computer, but 
I'll agree not to mention it again until you buy me a pint.

-- 
Pete

---

From: John Merrells <[email-masked]>
Date: Fri, 20 Jan 2006 19:56:41 -0800

On 20-Jan-06, at 7:23 PM, Pete Rowley wrote:

> My misunderstanding is based on the fact that the sxip attributes  
> are in the document

There are some example property names from the sxip.net authority,  
but you can use anything you want.
I could publish the ones we've been using as another ID, or in an  
appendix of a revision of this ID... but
I don't want to mandate that anyone should use them. It'd be nice if  
they did of course.

> yet apparently only sxip.net can supply the values (no matter where  
> they are stored).

Nope. What in dmd1 gives you that impression? It might be the  
capabilities definition
stuff... only sxip.net can tell you the type information for that  
property name.

> a) why they are documented since there does not appear to be point  
> of interoperability (these are for your website?),

They're not, but could be. I could publish them as a document on  
sxip.org... then you could take a look at them and see if they make  
sense for your application.

> capability and advertise that support, since for the homesite they  
> are opaque attributes and it can either choose to allow the storage  
> of opaque random attributes or not, and any one user either has  
> those attributes or not - or is this a crude form of access control  
> for homesite storage?, where is the capable in capability?

Well a capability is both services and properties. I think you mean  
why would a homesite want to advertise that it knew about a  
particular family of properties.

But, yes. In a sense the Homesite is advertising what schema it knows  
about. It could choose to operate in such a way that it only stores  
properties that it knows about. Personally I think that'd suck. But,  
given a set of Homesites a Membersite could chose the one most  
appropriate for fetching or storing a particular property. Key to  
Homesite popularity will be the UI/UX and that will be strongly tied  
to what the properties are. As a user I'd want my DVD wish list at  
the Homesite with the best UX/UI for that rather than for the one  
with none at all.

> response" when presented with the dix:/membersite-accept when it  
> has no real knowledge of the attributes involved beyond what they  
> are called (and presumably the membersite requests only what it  
> does understand.)

Accept is mostly for the services part of the capabilities. For  
example the authentication mechanisms used. Maybe the Membersite can  
say that it can deal with particular security tokens...

> Sorry to bang on about this, but I am actually trying to cut code  

Which is why your questions are so excellent :)

> What I mean by "meaning" is really the "universally understood  
> meaning" - not one meaning that only one entity understands .    
> Without universally understood meanings for a set of defined  
> attributes dix would merely be a means to use somebody elses hard  
> drive for data storage.  There may be value in that for all  
> parties, but the greater value is when everyone talks the same  
> language, not just the same protocol.

Amen, and I refer you to our friends in the semantic web community....

However, people have over time come to agreement over what things are  
called.
I think it's out of scope for this group what things are called, or  
even how people
should come to agreement on that. It'll happen, but not here.

Don't get me wrong I want this to happen... and I'll publish the  
names we're using
in sxip.net... and I hope lots of people will use them.

>>  There are various social models for working out agreements for  
>> the  names of things.
>
> None of which work terribly well once you switch on the computer,  
> but I'll agree not to mention it again until you buy me a pint.

Sure, after that we can sort out the whole world peace and hunger  
thing too ;-)

John