[OpenID] Is a URI Template really required for host-meta?

[John Bradley]

Remember that host-meta files are cacheable via http:.

It is  up to that site publishing the host-meta to determine how to do  
the mapping.   At IIW we did have conversations around the complexity  
of the template language.

The direction that people seem to be favouring is a single parameter  
of URI.

This allows a site to have a service that returns a XRD or do some  
processing on the URI and return a redirect to the actual XRD or place  
the XRD in the file returned by the GET.

In all cases except the redirect the XRD could can be retrieved by the  
RP with a single GET after host-meta is cached.

This gives the site a fair amount of flexibility.

I think what you are proposing is supported in the current host-meta  
draft without adding a new document type to parse.

John B.
On 2009-11-14, at 5:43 AM, Santosh Rajan wrote:

> Thanks, thats more or less what I am trying to figure. Except that  
> this protocol will be part of the host-meta spec itself and we avoid  
> any extra round trip. Once the host meta is retrieved, the client  
> can construct effectively the same uri that you would have otherwise  
> got by expanding the uri template.
>
> On Sat, Nov 14, 2009 at 1:32 PM, John Panzer <jpanzer at google.com>  
> wrote:
> I think you're proposing a simple protocol to handle mapping from  
> the subject to another URI that contains the actual XRD you want.
>
> So for example, as a straw man, you could say "take the URI with rel http://ietf.org/service/resolve/xrd 
> , append a query parameter subject=<uri escaped value of subject>,  
> and do a GET on the resulting URI.  The response, if successful, is  
> a 200 whose body consists of the URI to the actual desired XRD  
> document".
>
> The benefit of this would be that you would avoid the need for a  
> URITemplate element and client binding of the {uri} variable to the  
> subject.
>
> The drawbacks are that you incur the need for an extra HTTP round  
> trip, rather than just a client side template expansion, to discover  
> the URI of the actual XRD you want; you need to define yet another  
> protocol, albeit a small one, to do the retrieval; you need to run  
> another service, albeit a trivial one, to do the mappings server  
> side; and you need to answer some tricky questions about trust and  
> security (if the resolver is not done over SSL and certs checked,  
> this becomes another vector for MITM and DNS poisoning attacks).
>
> --
> John Panzer / Google
> jpanzer at google.com / abstractioneer.org / @jpanzer
>
>
>
> On Fri, Nov 13, 2009 at 6:18 PM, Santosh Rajan <santrajan at gmail.com>  
> wrote:
> One of the purposes of the host-meta is to map a given URI to its  
> XRD available on the server. Currently this is done by using a  
> URITemplate.
> <URITemplate>http://example.com/getxrd?q={uri}<URITemplate>
>
> Instead can the host-meta define a resolver service on the host,  
> that returns an XRD given the Subject URI? eg. The host-meta can  
> define a service on the server that accepts a GET or POST request  
> with a single parameter passed whose key is "subject", and "value"  
> is the subject URI to be resolved. In this case we only need a URI  
> to the service on the server and can be written like this.
>
> <link rel="http://ietf.org/service/resolve/xrd"
>     type="application/xrd+xml"
>     href="http://example.com/getxrd"/>
>
> (the rel value is just an example)
>
> Advantages of this being
> 1) No need for template and template mapping
> 2) The idea is consistent with the host-meta being an aggregator of  
> the XRD's available on the host.
>
> Any reason this could be a bad idea?
>
> -- 
> http://hi.im/santosh
>
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
>
> -- 
> http://hi.im/santosh
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091114/cccd0855/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2468 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091114/cccd0855/attachment.bin>