Subject: RE: [dix] Federated Digest Auth

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 2 Mar 2006 10:32:31 -0800

> The username passed is the persona-url
> Authorization: Digest username="dix:/sxip.com/employees/dick",

Sure we could do that.

But why are folk so intent on using a URL when it is guaranteed to
result in a shitty user experience?

What additional information is there in the URL you give that could not
be returned as an attribute?

I agree that the canonical form of the identifier should be
dix:{something that includes dick, sxip.com} but why are you so intent
on exposing that to the user?

We didn't even use fully qualified URIs in the HTTP protocol until v1.1.
We don't expose URIs to the user in SMTP, NNTP or FTP.

URIs are a machine interface. They are NOT a USER interface.

> >	realm="low@portableidentifier",
> >	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
> >	uri="/dir/index.html",
> >	qop=auth,
> >	nc=00000001,
> >	cnonce="0a4f113b",
> >	response="6629fae49393a05397450978507c4ef1"
> >
> The relying party locates a homesite-url for the persona-url 
> using the persona document.  (What if there is more than one 
> homesite?)
> 
> The relying party makes a call to the homesite-url with a 
> "dix:/message-type" of "dix:/verify-digest-request".  It also 
> passes parameters for realm, nonce, ha2, qop, nc, cnonce and response.
> 
> The homesite responds with a dix:/true or dix:/false as 
> outlined in section 5.10.3.4. of dmd0

I agree that using a separate result code from the HTTP result code may
well be a good thing. We have had some issues with registry services
going offline and the host server reporting '200 success' for all
queries as a result.

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

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 2 Mar 2006 11:09:42 -0800

There are a number of protocols where there are placeholders or  
places for user identity to appear.  I'm most familiar with how this  
works in WebDAV though it certainly crops up in other areas.  WebDAV  
then, as an example, has <href/> tags for containing URLs that refer  
to principals.  For example, the holder of a lock could advertise  
their identity with a URL in such an <href/> tag, but if it were not  
a URL, we'd have to invent something new.

One of the exciting applications for something like DIX, in WebDAV,  
is the possibility to share with people across organizations  
properly.  If I wanted to share my OSAF calendar with you, Phillip,  
but not share it publicly, how could I do that?  Right now some  
WebDAV servers have a solution that would horrify security experts --  
they have tickets such that I could ask the server for a ticket  
granting read access to the calendar, and the bearer of that ticket  
gets access.  Then I send the ticket to you over email, attached to a  
URL to the calendar, and you use that to see my calendar.  Obviously  
not very secure.

Instead, imagine that I could enter your federated identity URL into  
my calendar permissions configuration page, and grant read access to  
that identity.  Then when I send you the URL to my calendar, or you  
browse to it, my server asks "who are you" and you provide the same  
identity URL.  My server checks that with your identity provider and  
allows read access to the calendar.  Much better than a publicly  
readable calendar, much better than tickets.  Reasonably usable.  And  
it might even work without any protocol changes to WebDAV ACL.

I am quite sure there are a lot of ways to simplify user interfaces  
while also supporting URL format.  For example, a very simple Web  
signup form could look like this:

    "If you have an account elsewhere that you can log in here,  
please enter:
	Username: ___lisa______
	Identity domain: ___osafoundation.org_____"

This might be too simple because it doesn't allow any substructure  
inside one domain but it's certainly a possibility.  The code  
handling this form would follow whatever rules DIX specifies to put  
this together into a URL: e.g. lookup osafoundation.org's identity  
server in DNS and discover that it's "users.osafoundation.org",  
concatenate the user name as "users.osafoundation.org/lisa", prefix  
with a scheme to have "dix://users.osafoundation.org/lisa", and now  
you're ready to go with a URL.

lisa

---

From: Robert Yates <[email-masked]>
Date: Thu, 02 Mar 2006 14:42:35 -0500

>result in a shitty user experience?
how is this "gmail.com/robyates" any different to this 
"[email-masked]"?  is the user experience that different? sure sites 
could give out hard to remember "shitty" persona-urls but will they 
catch on?  There are many technical advantages to having URLs as 
identifiers and if the user experience doesn't suffer then why not?

Rob

p.s. As blogging and personal web sites become more the norm won't users 
actually find it a very natural experience to be entering "their" URL as 
"their" identifier.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 2 Mar 2006 11:56:15 -0800

Agree that URIs may not always be very user friendly.

I have a couple public URIs. http://blame.ca and http:// 
Identity20.com ... but I there are many aspects of my online  
interactions where I would not want to expose those URIs, or it may  
be a unique URI for many sites so that I have a pair-wise or  
unidirectional relationship vis-a-vis the innovations from Liberty.  
These latter URIs are not user managable.  I envisioned the UX would  
wrap the URI with a nice, user created labels for personas like  
"home", "work" or "nym"

Lisa brings up an important point around admin that we have been  
pondering. How to you make it easy for users to restrict access to a  
set of people.

A unique, public identifier is a good solution for that this.  Email  
or easy URLs map well to this as it is easy for the resource owner to  
type in the identifier. Email has an advantage as it can be used to  
notify that permission has been granted.

Assertions that the user is a certain identifier is then required to  
gain access.

Taking this concept further, an assertion of a hash of the identifier  
allows the user to prove they are an identifier, without disclosing  
the identifier. IE, I can prove that I am [email-masked], without  
giving a site my email address.

---

From: [email-masked]
Date: Thu, 02 Mar 2006 15:27:33 -0500

This discussion of Federated Auth has moved us too far away from one of the key drivers of the DIX effort (in my opinion).  The identity exchange protocol needs to support the case where there no account or other profile data stored at the relying party.  Every attribute of the identity of the user (client) needs to be sent to the relying party as part of the current interaction.  In addition, it should not be required to send an identifier as one of the attributes.  The federated auth discussion has put too much weight on an attribute that is a unique identifier.
 
In a previous email Phillip proposed a definition for identity: "An identity is a set of assertions concerning a particular subject identifier."  I disagree with this.  Later on in the same email, he "factored out" the identifier in a collection of statements, which resulted in statements like "That dude is Canadian" and "That dude has blood group Z".  I believe these statements form the identity that DIX is dealing with.  To those statements you can add "That dude authenticated as [email-masked]" (which essentially a SAML authentication assertion).
 
In the example that Lisa gives for a shared calendar, the attribute of the identity that needs to be transferred is "That dude is allowed to look at Lisa's calendar".  From the DIX point of view this is a third party assertion but in most cases will have been issued by the relying party (the calendar service) to be used by itself.  Maybe what we need to talk about are self-issued and non-self-issued assertions.
 
The most direct representation of the required attribute is the bearer ticket that Lisa described.  It needs to be handled carefully, but it also has the ability to provide anonymous access to the service and continues to work even if my email address changes.  A different approach would be to tie the assertion to some other attribute of the identity, which would then need to be shown separately.  This requires more information to be released to the relying party, but may be acceptible in many cases.
 
DIX needs to define how to exchange identity attributes.  It does not need to define a way to federate a credential-based authentication scheme.
 
Terry

-----Original Message-----
From: Lisa Dusseault <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Thu, 2 Mar 2006 11:09:42 -0800
Subject: Re: [dix] Federated Digest Auth

There are a number of protocols where there are placeholders or places for user identity to appear. I'm most familiar with how this works in WebDAV though it certainly crops up in other areas. WebDAV then, as an example, has <href/> tags for containing URLs that refer to principals. For example, the holder of a lock could advertise their identity with a URL in such an <href/> tag, but if it were not a URL, we'd have to invent something new. 
 
One of the exciting applications for something like DIX, in WebDAV, is the possibility to share with people across organizations properly. If I wanted to share my OSAF calendar with you, Phillip, but not share it publicly, how could I do that? Right now some WebDAV servers have a solution that would horrify security experts -- they have tickets such that I could ask the server for a ticket granting read access to the calendar, and the bearer of that ticket gets access. Then I send the ticket to you over email, attached to a URL to the calendar, and you use that to see my calendar. Obviously not very secure. 
 
Instead, imagine that I could enter your federated identity URL into my calendar permissions configuration page, and grant read access to that identity. Then when I send you the URL to my calendar, or you browse to it, my server asks "who are you" and you provide the same identity URL. My server checks that with your identity provider and allows read access to the calendar. Much better than a publicly readable calendar, much better than tickets. Reasonably usable. And it might even work without any protocol changes to WebDAV ACL. 
 
I am quite sure there are a lot of ways to simplify user interfaces while also supporting URL format. For example, a very simple Web signup form could look like this: 
 
  "If you have an account elsewhere that you can log in here, please enter: 
  Username: ___lisa______ 
  Identity domain: ___osafoundation.org_____" 
 
This might be too simple because it doesn't allow any substructure inside one domain but it's certainly a possibility. The code handling this form would follow whatever rules DIX specifies to put this together into a URL: e.g. lookup osafoundation.org's identity server in DNS and discover that it's "users.osafoundation.org", concatenate the user name as "users.osafoundation.org/lisa", prefix with a scheme to have "dix://users.osafoundation.org/lisa", and now you're ready to go with a URL. 
 
lisa 
 
On Mar 2, 2006, at 10:32 AM, Hallam-Baker, Phillip wrote: 
 
> What additional information is there in the URL you give that could > not 
> We didn't even use fully qualified URIs in the HTTP protocol until > v1.1. 
>> passes parameters for realm, nonce, ha2, qop, nc, cnonce and >> response. 
>> 
> I agree that using a separate result code from the HTTP result code > may