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

[Santosh Rajan]

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}<http://example.com/getxrd?q=%7Buri%7D>
>>> <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/705a3329/attachment-0001.htm>