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. What it does very well is to provide transparent authentication, there is no need for the user to log in because the browser will do that automatically using the existing cache mechanism once it recognizes that the site has already been visited. The user only needs to provide credentials once per session, unlike cookies however the user is required to resupply the credentials at least once and the browser knows that the data is credential data. > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 01, 2006 10:30 PM > To: Digital Identity Exchange > Subject: RE: [dix] Federated Digest Auth > > > From: Dick Hardt [mailto:[EMAIL PROTECTED] > > > How would this move around other identity data? My interest > in DIX is > > to be able to move around all kinds of identity data. To me, that > > means that the site needs to be able to say "here is what I > want", the > > user has an opportunity to select what to release, and then > it is sent > > to the site. > > Here are some fake messages I created for the design. I can > generate some genuine data tommorow (server is upstairs). > > OK three parties: > > Client (user), Relying party and Registry > > Following the Digest auth spec the protocol begins with a > request from the client which results in a refused response > containing a challenge: > > HTTP/1.0 401 Unauthorised > Server: SokEvo/0.9 > Date: Sun, 10 Apr 2005 20:26:47 GMT > WWW-Authenticate: Digest realm="[EMAIL PROTECTED]" > qop="auth,auth-int", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > Content-Type: text/html > Content-Length: 311 > > The client responds using standard Digest Auth > > GET /dir/index.html HTTP/1.0 > Host: localhost > Authorization: Digest username="[EMAIL PROTECTED]", > realm="[EMAIL PROTECTED]", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > uri="/dir/index.html", > qop=auth, > nc=00000001, > cnonce="0a4f113b", > response="6629fae49393a05397450978507c4ef1" > > The relying party locates the registry server to authenticate > users in sxip.com using the SRV mechanism. > > The response from the user is now relayed to the registry. > The uri value, realm &ct are replaced by the ha2 hash value: > > GET / HTTP/1.0 > Host: localhost > Authorization: Digest username="[EMAIL PROTECTED]", > realm="[EMAIL PROTECTED]", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > ha2="39aff3a2bab6126f332b942af96d3366", > qop=auth, > nc=00000001, > cnonce="0a4f113b", > response="6629fae49393a05397450978507c4ef1" > > The registry replies either 200 OK or 401 unauthorized. > > HTTP/1.0 200 Accept > Server: SokEvo/0.9 > Date: Sun, 10 Apr 2005 20:27:42 GMT > > If you want attributes with that you simply add content to > the request and response: > > > GET /?ask=name+ZIP+ShoeSize HTTP/1.0 > Host: localhost > Authorization: Digest username="[EMAIL PROTECTED]", > realm="[EMAIL PROTECTED]", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > ha2="39aff3a2bab6126f332b942af96d3366", > qop=auth, > nc=00000001, > cnonce="0a4f113b", > response="6629fae49393a05397450978507c4ef1" > > HTTP/1.0 200 OK > Server: SokEvo/0.9 > Date: Sun, 10 Apr 2005 20:27:42 GMT > > Name=Dick+Hardt&zip=90210&ShoeSize=10 > > > Or you can return a SAML token or use POST or whatever. You > can use the rest of DIX at this point. > > Although this is limited to username/password type auth it is > still possible to use a one time password token provided that > the registry can access the list of expected password values. > > If you are doing PKI based auth then you are going to need a > new client anyway. The way I would handle this is using a > prefixed TXT record: > > _authprot.sxip.com TXT "T=AUTHPROT P=DIGEST,SAML,DIX" > _digest.tcp.sxip.com SRV 1,1,1,1, 80, digestreg.sxip.com > > > It may be possible to use NAPTR. Although this is not > supported in certain DNS servers it is already required by > SIP. Given the critical nature of SIP it is arguable that > NAPTR will deploy. > > _______________________________________________ > dix mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
