The distinction you appear to be drawing here is between
schemes where the identifier itself is exposed to the relying party and schemes
where it is not.
We are still at the requirements stage AFIK, lets get all
the optionson the table and see where we would like to go.
The problem with the pure attributes approach (which I
certainly endorse as a goal in some cases) is that in most of the use cases in
the Web the relying party is interested in unique visitors.
Very early on in the Web people started to want tracking
data bound to a unique identifier. I proposed a mechanism (95 for prior art
purposes, so the patent trolls need not bother to get their perjuring hats on
today) for an unlinkable identifier bound into the browser. The basic idea was
to use MD5 (username, relyingparty) as a fixed unlinkable
identifier.
There
are better schemes we could use but the patent issues would be very
complex. I don't think the group wants to go there.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 02, 2006 3:28 PM
To: [email protected]
Subject: Re: [dix] Federated Digest AuthThis 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 PROTECTED]" (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 PROTECTED]>
To: Digital Identity Exchange <[email protected]>
Sent: Thu, 2 Mar 2006 11:09:42 -0800
Subject: Re: [dix] Federated Digest AuthThere 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, an d 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 y ou 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:
>
>> 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="[EMAIL PROTECTED]",
>>> 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 protected]
> https://www1.ietf.org/mailman/listinfo/dix
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
_______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
