OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XRD Boostrap & Discovery of Email Addresses -- A Workflow?


In light of previous threads on this topic, I wrote out the following in an effort to better understand the workflow involved with XRD bootstrapping of email addresses, and how those fit into discovery.  I figured I'd provide it to the list to (1) make sure I understand how XRD is going to work (please comment on that), and (2) gather list input to see if this is the best way to make it work.  I think this is in-line with what Eran and Drummond have proposed, but feel free to chime in.

Otherwise, enjoy!

david

=======

XRD Boostrap & Discovery of Email Addresses

--
#1.) Bootstrapping takes a URI and turns it into a URL.  Common URI schemes are: http:, mailto:, ftp:, urn: etc.
    1a) Site-meta really only works with domain-based URI's (e.g., http:, mailto:, ftp:, but not with urn: and others)
    1b) Currently proposed is to utilize /site-meta with domain-based URI's (?)

#2.) URI beth@example.com is bootstrapped to be the URL http://example.com/site-meta (with fallback to http://www.example.com/site-meta), which if provided the proper header, will return me an XRD (Still not sure what format the XRD will be in -- I've seen the traditional XML version, and I've seen a Link-based version.  Not sure what the difference is).

Anyway, once I have an initial XRD retrieved via /site-meta, I can then start to "do stuff" relating to discovery.  Number 3 details what I can do.

#3a.) Site-wide Discovery (No Site-Wide Delegation)
For discovering services that are offered in a site-wide fashion (e.g., an OpenID auth endpoint, or where to find this site's portable conacts info per user), the XRD could have the following:

(1) Link: template=http://www.openid.com/auth rel=http://spec.openid.net/signon
or
(2) Link: template=http://www.example.com/user={uri} rel=http://poco-is-here.net

3a(1) says, "hey, for all URL's in the example.com domain, use http://www.openid.com/auth as your OpenID auth endpoint."
3a(2) says, "hey, to find a particular example.com user's POCO data, go to http://www.example.com/user={uri}.

#3b.) Site-Wide Discovery (with delegation)
Discovery can also be peformed by doing steps 1 and 2 above, resulting in an XRD with one or more of the following:

    (1) Link: template=http://www.site-delegate.com/site-meta; rel=xrd
    or
    (2) Link: template=http://www.site-delegate.com/xrd?uri={URI}; rel=xrd
    or
    (3) Link: template=http://www.example.com/xrd?uri={URI}; rel=xrd

3b(1) says, "hey, go to http://www.site-delegate.com/site-meta" and get a new site-wide XRD for example.com (full delegation), and start over at step 3a.
3b(2) says, "hey, go to http://www.site-delegate.com/xrd?uri=beth@example.com" and get an XRD for beth@example.com.  Oh, and that URL might give you a redirect, or it may resolve into an XRD.  If an XRD, start over with step 3a again. 
3b(3) says, "hey, go to http://www.example.com/xrd?uri=beth@example.com, and and get an XRD for beth@example.com (this time served up by example.com instead of site-delegate.com).  Again, resolving this URL might give you a redirect, or it may resolve into an XRD.  If an XRD, start over with step 3a again.

==

Given all of those options, it seems like I can fully delegate one or more portions of both my root XRD for site-wide services, as well as XRD files for individual users.  I could even delegate each individual user to a different XRD provider (imagine http://www.example.com/xrd?uri={URI} just redirects to a completely different domain for each discrete user).




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]