Subject: RE: [dix] Federated Digest Auth

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

I think that there should be separate exchanges here for initiating a
relationship and re-establishing one.

I do not see a need for extensive attribute exchange every single time a
person reads an article in the NYT or posts to a blog. This should be
done once and the relying party should cache the details in a local
store.

We need two buttons, not just one. One button for create/update account,
a second one for login to the account.

Control can be a two edged sword, make it too easy for sites to ask for
social security numbers and idiots will be asking for them on their
blogs.

We need to do some mock ups of the proposed user interfaces, and yes I
do mean mock ups, not products. Mock ups are better, people are less
likely to complain if they think the code is written, they try to be
nice. You want grumpy curmudgeons.

> -----Original Message-----
> From: Dick Hardt [mailto:[email-masked]] 
> Sent: Thursday, March 02, 2006 11:36 AM
> To: Digital Identity Exchange
> Subject: Re: [dix] Federated Digest Auth
> 
> 
> On 2-Mar-06, at 7:10 AM, Hallam-Baker, Phillip wrote:
> 
> > I forgot to mention, you can use the standard HTTP content 
> negotiation 
> > mechanism to select form encoded or SAML assertions in the exchange 
> > between the relying party and the registry.
> >
> > A good way to think of it is that the exchange between the relying 
> > party and the registry is simply a standard HTTP 
> request/response. The 
> > only difference is that the authentication data is provided by a 
> > different party, the user that initiated the original 
> request rather 
> > than the relying party making the federated auth request.
> >
> >
> > The key advantage here is that the protocol is safe against 
> > man-in-the-middle attacks, provided that is the user 
> interface for the 
> > browser does not allow a downgrade attack to BASIC auth. This is of 
> > course a security failure that needs fixing regardless.
> >
> >
> > What this scheme does not provide is a way for the end user 
> to control 
> > the specific attributes that are released.
> 
> IMHO it is critical for the user to control the release.
> 
> LID et al have some mechanism for allowing site to query the 
> registry and have the user control the release (which I don't 
> fully understand)
> 
> I think there is something from your previous post though in 
> how a Rich Client can negotiate with the site leveraging 
> existing standards.
> 
> -- Dick
> 
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
> 
> 

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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 2 Mar 2006 10:24:55 -0800

> relationship and re-establishing one.

1) the site does not need to store the data if it only needs it in  
the transaction. The NYT is a perfect example. They receive profile  
data to increase demographic counters and potential serve targeted  
ads. No DB is required. No risk on losing the data.

2) the data is always fresh. I go to Amazon and give them my address.  
I change my address. I go back to Amazon and they have my latest  
address (with my permission)

3) the attributes may be TPC that have a short life. They have to be  
fresh

4) one button is easier then two

> nice. You want grumpy curmudgeons.

Write a comment on one of my blogs: http://identity20.com or http:// 
blame.ca and get an account and you can see the UX

-- Dick