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

Sat Nov 14 17:11:36 UTC 2009

I think the current proposal has a single template element URI

You would do a GET to that URI with the input URI (acct or URL etc)  
replacing {URI} in the template.

If the host makes the template point to a script etc that takes the  
input URI as a parameter you they can return the XRD directly.

I think doing it with GET rather than POST is simpler.

Also staying with GET also allows the Host to just use plain files or  
redirects rather than something fancy if they like.

I think I see your point, however the current proposal covers it quite  
well I think.

I am not as involved in host-metta as John P. and others so they may  
have a different view.

John B.
On 2009-11-14, at 12:06 PM, Santosh Rajan wrote:

> Yes John, I can see that the template solution is a more elegant  
> solution. However the host-meta use case of this template seems to  
> be a bit of an overkill. Consider this (this is only for  
> illustrating the problem),
>
> I could take the current host-meta, find the template, take the  
> endpoint pointed to by the template, make a POST request to the  
> endpoint, with a string value in the body of the POST. eg. the body  
> of the request would contain a string "acct:john @ example.com". (I  
> have put some spaces around @ so that they don't get mangled just in  
> case").
>
> Now if the host-meta specification would specify, that in case there  
> is a POST request to the endpoint part of the template, the body of  
> the POST request should be taken as the {uri} substitution value of  
> the template. Voila! We don't need the template!
>
> Sorry for being dramatic. I hope I am making some sense here.
>
> On Sat, Nov 14, 2009 at 6:48 PM, John Bradley <ve7jtb at ve7jtb.com>  
> wrote:
> 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
>
>
>
>
> -- 
> http://hi.im/santosh
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091114/f7b6d45b/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/f7b6d45b/attachment.bin>