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