Agree that URIs may not always be very user friendly.
I have a couple public URIs. http://blame.ca and http://
Identity20.com ... but I there are many aspects of my online
interactions where I would not want to expose those URIs, or it may
be a unique URI for many sites so that I have a pair-wise or
unidirectional relationship vis-a-vis the innovations from Liberty.
These latter URIs are not user managable. I envisioned the UX would
wrap the URI with a nice, user created labels for personas like
"home", "work" or "nym"
Lisa brings up an important point around admin that we have been
pondering. How to you make it easy for users to restrict access to a
set of people.
A unique, public identifier is a good solution for that this. Email
or easy URLs map well to this as it is easy for the resource owner to
type in the identifier. Email has an advantage as it can be used to
notify that permission has been granted.
Assertions that the user is a certain identifier is then required to
gain access.
Taking this concept further, an assertion of a hash of the identifier
allows the user to prove they are an identifier, without disclosing
the identifier. IE, I can prove that I am [EMAIL PROTECTED], without
giving a site my email address.
On 2-Mar-06, at 10:32 AM, Hallam-Baker, Phillip wrote:
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
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
