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 PROTECTED] > 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 protected] > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
