Re: [xri] XRD Boostrap & Discovery of Email Addresses -- A Workflow?

[George Fletcher <george.fletcher@corp.aol.com>]

Nice write up of the possibilities. I have one question relating to 
3b(2) and 3b(3) supporting redirects and Brian's trust profiles 
(specifically the "resource name to document binding rules").

In the case of following redirects... which URL is supposed to end up in 
the final XRD document to maintain a valid binding between the resource 
identifier and the document?

If we use the initial resource identifier 
(http://www.site-delegate.com/xrd?uri=beth@example.com) as the 
CanonicalID and end up because of redirects on 
http://www.other-site.com/xrd/beth, then the XRD needs to be signed with 
a cert that is valid for site-delegate.com (use the SubjectAltName field 
with multiple entries?). Seems like this would be problematic from a CA 
issuance perspective. Maybe if this kind of trusted delegation is 
required, the mechanism would just use XRD for delegation instead of 
HTTP redirects? Though this does require the intermediate sites to each 
sign their XRD use in the delegation path.

If we use the final URL (after redirects), then the resolution is 
subject to redirect spoofing. This could be mitigated by ensuring that 
all fetches and redirects are done over SSL.

Did I miss the obvious somewhere?

Thanks,
George

David Fuelling wrote:
> 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 <mailto:beth@example.com> is bootstrapped to 
> be the URL http://example.com/site-meta (with fallback to 
> http://www.example.com/site-meta) <http://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} 
> <http://www.example.com/user=%7Buri%7D> rel=http://poco-is-here.net
>
> 3a(1) says, "hey, for all URL's in the example.com 
> <http://example.com> domain, use http://www.openid.com/auth as your 
> OpenID auth endpoint."
> 3a(2) says, "hey, to find a particular example.com 
> <http://example.com> user's POCO data, go to 
> http://www.example.com/user={uri} <http://www.example.com/user=%7Buri%7D>.
>
> #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} 
> <http://www.site-delegate.com/xrd?uri=%7BURI%7D>; rel=xrd
>     or
>     (3) Link: template=http://www.example.com/xrd?uri={URI} 
> <http://www.example.com/xrd?uri=%7BURI%7D>; 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 <http://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 <mailto: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 <mailto:beth@example.com> (this time served up by 
> example.com <http://example.com> instead of site-delegate.com 
> <http://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} 
> <http://www.example.com/xrd?uri=%7BURI%7D> just redirects to a 
> completely different domain for each discrete user).
>
>