Or, with this approach modified, to be more along the lines of dmd0
Hallam-Baker, Phillip wrote:
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
The username passed is the persona-url
Authorization: Digest username="dix:/sxip.com/employees/dick",
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
Rob
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
