Re: [xri] XRD trusted discovery workflow

[Dirk Balfanz <balfanz@google.com>]

On Wed, Dec 10, 2008 at 11:18 PM, David Fuelling <david.fuelling@cordance.net> wrote:

On Wed, Dec 10, 2008 at 5:08 PM, Dirk Balfanz <balfanz@google.com> wrote:

As for David's comment: If I remember EAUT correctly, it's a layer before any OpenID discovery would start, and would simply transform an email address into a URL (on which then to perform discovery). In fact, it is orthogonal to OpenID - you can use EAUT to transform an email address into a URL for all sorts of purposes, only one of which is OpenID discovery.

So putting a resource map as a direct child element of <XRD> and using that to get the meta data for the email URI would be equivalent to EAUT - putting the resource map inside the <Service> element of <Type> http://specs.openid.net/auth/2.0/server would not.

Can you elaborate a bit more here?  It seems like a resource map requires a <Service> to give it any context.  For example, if I have an email address 'beth@example.com', and bootstrap that (in some form or another) to get site-meta XRD at http://example.com/site-meta, then what would the URIMap element "map" if it's not inside a <Service> element?

I think a URI needs a <Service> context - it seems to me a resource map doesn't. 

The current proposal on the wiki says that a resource map is inside a service element of type "e-mail to URL translation". We could make that more generic, and call it "URI to URI translation", at which point it's saying the same thing as URIMap. To me it seems that the following three examples all mean the same thing:

[ my proposal: ]

<XRD>

  <URIMap>http://target.com/uri={URI}</URIMap>

</XRD>

[ what's currently on the wiki (well, almost): ]

<XRD>

  <Service>

  <Type>http://specs.xri.org/uri-to-uri-translation</Type>

  <URIMap>http://target.com/uri={URI}</URIMap>

  </Service>

</XRD>

[ what's in EAUT (well, almost; see below): ]

<XRD>

  <Service>

  <Type>http://specs.xri.org/uri-to-uri-translation</Type>

  <URI>http://target.com/uri={URI}</URI>

  </Service>

</XRD>

If you agree that these all mean the same thing, then the first one seems the easiest. 

With EAUT, there are actually two <xrd:Type> possibilities inside of the <Service> element.  First is a "template" type, which with a corresponding URITemplate URI can be used to transform the email address to a URL directly.  The other <xrd:Type> is a "mapping" type, which allows the domain controller to delegate to a mapping service, thereby allowing individual users to specify (via that mapping service) which URL their email address should map to. 

Yeah I'm not quite sure how these two types map onto what's shaping up on the wiki. Maybe one way to look at it is that we're here trying to figure out how to discover meta-data for an arbitrary URI (including mailto: URIs), while EAUT tries to transform a mailto: URI into an http: URI. What we're doing here (and what the three examples above all do) is closer to performing an EAUT transform (either by template _or_ mapping), and then finding out where the meta-data for the resulting HTTP URI is, but in one step.

 

 

Now I don't know whether equivalence with EAUT is something to strive for here...  

If we are going to address email addresses in the Discovery Bootstrapping, then I think we should consider EAUT (or something like it) over trying to define what should happen with a simple mailto:schemed URI.  Web-servers don't "do" anything with a mailto: schemed URI.  Some other mechanism is necessary to translate these URI's/email addresses into URL's, and that something probably needs to be more than just taking the "domain.tld" from an email address and trying to do discovery on that URL.

With all that said, however, are we really going to define URL mappings for every URI scheme in the XRD spec?  I doubt it.  Just thinking out loud, but should we consider calling email addresses out of scope here?  Why not let other specs figure out how to turn various URI schemes into URL's (like mailto:), and concentrate on the "URL Discovery Bootstrapping" part.

I would like us to come up with something that works with arbitrary URI schemes, because I would like to get the email use case to work. I don't think we necessarily need to call out every possible URI scheme in the spec. Something like URIMap would work fine, and isn't restricted to mailto: URIs, the mention of mailto: on the wiki is just an illustrative example.

Dirk.

P.S.: BTW, I'm new to all this. When I say "my proposal" I mean "can you tell me what's wrong with this so I can understand better what's going on here " :-)

 

Dirk.