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?
- From: "David Fuelling" <david.fuelling@cordance.net>
- To: "xri@lists.oasis-open.org" <xri@lists.oasis-open.org>
- Date: Mon, 15 Dec 2008 17:42:14 +0000
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]