There are a number of protocols where there are placeholders or
places for user identity to appear. I'm most familiar with how this
works in WebDAV though it certainly crops up in other areas. WebDAV
then, as an example, has <href/> tags for containing URLs that refer
to principals. For example, the holder of a lock could advertise
their identity with a URL in such an <href/> tag, but if it were not
a URL, we'd have to invent something new.
One of the exciting applications for something like DIX, in WebDAV,
is the possibility to share with people across organizations
properly. If I wanted to share my OSAF calendar with you, Phillip,
but not share it publicly, how could I do that? Right now some
WebDAV servers have a solution that would horrify security experts --
they have tickets such that I could ask the server for a ticket
granting read access to the calendar, and the bearer of that ticket
gets access. Then I send the ticket to you over email, attached to a
URL to the calendar, and you use that to see my calendar. Obviously
not very secure.
Instead, imagine that I could enter your federated identity URL into
my calendar permissions configuration page, and grant read access to
that identity. Then when I send you the URL to my calendar, or you
browse to it, my server asks "who are you" and you provide the same
identity URL. My server checks that with your identity provider and
allows read access to the calendar. Much better than a publicly
readable calendar, much better than tickets. Reasonably usable. And
it might even work without any protocol changes to WebDAV ACL.
I am quite sure there are a lot of ways to simplify user interfaces
while also supporting URL format. For example, a very simple Web
signup form could look like this:
"If you have an account elsewhere that you can log in here,
please enter:
Username: ___lisa______
Identity domain: ___osafoundation.org_____"
This might be too simple because it doesn't allow any substructure
inside one domain but it's certainly a possibility. The code
handling this form would follow whatever rules DIX specifies to put
this together into a URL: e.g. lookup osafoundation.org's identity
server in DNS and discover that it's "users.osafoundation.org",
concatenate the user name as "users.osafoundation.org/lisa", prefix
with a scheme to have "dix://users.osafoundation.org/lisa", and now
you're ready to go with a URL.
lisa
On Mar 2, 2006, 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
