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

Sun Nov 15 13:34:33 UTC 2009

I am more or less convinced we don't need the URITemplate in the host-meta.
Instead what we need is a service endpoint for what we can call "A Resource
Map Proxy".

We take all those XRD's that share the same domain name in their respective
Subject elements, and aggregate them into one Resource Map conceptually (we
can't do this physically). We now create a Resource Map Proxy as the
physical representation of the Resource map, which is an application that
retrieves the specific XRD based on its subject.

All the host-meta needs to do, is to point to the endpoint of the proxy, and
describe how the XRD can be resolved. I have already shown a couple of ways
this can be done earlier in this thread.

On Sat, Nov 14, 2009 at 10:41 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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}<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
>
>
>
>

-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091115/78b2f643/attachment.htm>