Subject: Re: [dix] Federated Digest Auth

From: Peter Davis <[email-masked]>
Date: Wed, 01 Mar 2006 09:32:28 -0500

On 2/28/2006 7:50 PM, "Robert Yates" <[email-masked]> wrote:

> Hallam-Baker, Phillip wrote:
> 
>>> From: Dick Hardt [mailto:[email-masked]]
>>> 
>>> There was an IETF BOF on Beyond Basic Auth that I had hoped
>>> would develop some richer Auth mechanisms within HTTP that
>>> could work with DIX.
>>>    
>>> 
>> 
>> How about Digest, it is supported inpractically every browser in use, it
>> is secure against man in the middle attack, it is a standard and a MUST
>> for HTTP/1.1
>> 
> +1 I would be a strong proponent of having an interop story for DIX and
> Digest.  Most feedreaders support Digest and RESTful webservices can use it.
> 

>From a protocol design standpoint, however, lets separate the 'act of
authenticating' with the 'act of sharing a security token with a relying
party'  they are different.  And in some cases, an RP to an assertion may
require the homesite to use a certain authentication mechansim or else,
don't bother.

This is a design pattern in SAML, of course, but can be applied elsewhere.

What's federated is not the digest auth, but (some form of) a token
indicating that digest auth occurred.

=peterd  (http://xri.net/=peterd)

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 3 Mar 2006 06:30:20 -0800

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-masked] [mailto:[email-masked]] 
	Sent: Thursday, March 02, 2006 3:28 PM
	To: [email-masked]
	Subject: Re: [dix] Federated Digest Auth

	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, 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="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. 
	> [email-masked] <mailto:dix%40ietf.org>  
	 
	_______________________________________________ 
	dix mailing list 
	[email-masked] <mailto:dix%40ietf.org>  
	https://www1.ietf.org/mailman/listinfo/dix