proposal for capabilities lookup

[Ernst Johannes]

If consumer knows "local convention", it's only one fetch to get the  
capabilities.
Otherwise it's two -- and they can be cached independently (e.g. on  
different time frames) and cleanly.

If we package the public key into the capabilities document, then  
this does not add another fetch for the signed ping use case.

Other stuff after the capabilities have been retrieved -- like SSO,  
profile queries, whatever -- counts separately. Depending on that, it  
might be more.

In my mind, that's a good tradeoff.


On Nov 17, 2005, at 13:23, David Recordon wrote:

> One thing with the proposal to keep in mind is that it now means there
> will always be at least two fetches, and three with delegation.
>
>
>
> -----Original Message-----
> From: yadis-bounces at lists.danga.com
> [mailto:yadis-bounces at lists.danga.com] On Behalf Of Ernst Johannes
> Sent: Thursday, November 17, 2005 12:27 PM
> To: Discussion OpenID
> Subject: proposal for capabilities lookup
>
> So I think what we've established so far is that:
>   - the capabilities lookup needs to be orthogonal to the content type
>   - we should use what we can learn from other people who have  
> addressed
> similar problems with XML and XML schema, for example.
>   - we all think that establishing universal filename conventions  
> is not
> going to work. The reasons that were brought up are all similar to the
> ones listed on http://en.wikipedia.org/wiki/Favicon (look for  
> "conflicts
> with the Architecture of the World Wide Web").
>
> We also have the goals:
>   - we should not introduce new HTTP verbs (too messy, too hard)
>   - we should stay with common practice where established in similar
> domains
>   - we should not use mechanism that may create caching problems with
> intermediate caches outside of our control (or even knowledge)
>   - we need to minimize the number of HTTP requests, and the bandwidth
> consumed
>   - we need to support users who want to be YADIS-enabled with a non-
> cooperative service provider, and service providers who want to YADIS-
> enable their users without them necessarily knowing what that is or
> having to do anything special to their part of the puzzle (http server
> vs. content)
>
> There's also this goal, which I'm not sure we discussed this on this
> list, but certainly it has been discussed in person:
>
> if possible, we should allow high-volume consumers (think Yahoo,  
> Google
> etc.) to shortcut the protocol for those YADIS identity hosts where  
> the
> YADIS identity host has decided on a (local, not universal) convention
> and the consumer is aware of the local convention. For example, if  
> site
> highvolumebloghost.example.com hosts one zillion YADIS identifiers,  
> but
> their "j-meta" information can always be retrieved from
> http://highvolumebloghost.example.com/some/very/
> specific/j-meta/path, then a high volume consumer of YADIS identifiers
> should be able to write special-purpose code just for this site, and
> just for the time period that highvolumebloghost.example.com does not
> change its mind on its local proprietary convention. (If the high- 
> volume
> consumer does not want to write special-purpose code -- and certainly
> for everybody else who isn't a high-volume consumer --
> highvolumebloghost.example.com will still need to support the
> general-purpose protocol, and YADIS will only standardize that)
>
> All of this seems to point strongly to a separate URL (or URI, or IRI,
> or XRI, ... I will just use the term URL for simplicity from
> here) from which the "j-meta" data should be retrieved, rather than
> "hiding it" behind the same URL as pretty much all of us on this list
> -- me included :-( -- have suggested so far.
>
> So my proposal boils down to something very simple: all we need to
> define is how a given YADIS URL can return another URL that points to
> its "j-meta" data. We don't even have to request it specifically -- it
> could always do it, because it's fairly cheap: it's just a single URL.
>
> [For those of you who remember when "reflection" or "run-time type
> identification" was introduced to OO languages like C++: I'm basically
> suggesting to add a pointer from the instance to the type aka j-meta
> data, just like they did to make that possible]
>
> Because of the two different deployment scenarios -- user wants  
> YADIS in
> spite of service provider (that controls web server), and vice  
> versa --
> we need two mechanisms for getting this 'j-meta" URL across:
> one on the HTTP protocol level, and one on the content level.
>
> Which, revealingly enough, is very similar to the HTML META http-  
> equiv
> tags: "Dear user, if for whatever reason you can't change the behavior
> of your web server in spite of the fact that this is really a  
> matter of
> HTTP, not HTML, then we grudgingly give you the workaround to say the
> stuff you want to say inside an HTML document using http-equiv".
>
> What remains to define is the field name. Pick any one you like ;-) J-
> Meta comes to mind, or better not ;-) I have no problem with  
> "Meta", you
> might have different suggestions ... Using X-Meta from here.
>
>
> So this is how it would work (leaving out any potential, site-  
> specific
> shortcuts that are left as an exercise for the reader)
>
> 1) User visits Identity Consumer (aka Relying Party) http://
> consumer.example.com, enters their YADIS-enabled URL such as http://
> yadis.example.net/johnny
>
> 2) Consumer performs a regular HTTP GET or HEAD on http://
> yadis.example.net/johnny, nothing special
>
> 3) YADIS URL http://yadis.example.net/johnny returns the following  
> HTTP
> response header:
>
> HTTP/1.1 200 OK
> Date: ....
> Server: ....
> Transfer-Encoding: ...
> Content-Type: text/html (or whatever pleases the web server)
> X-Meta: http://capabilities.example.biz/walter
>
> (note there is no problem with caching)
>
> 4) Identity consumer now performs an HTTP GET on http://
> capabilities.example.biz/walter to get the capabilities document
>
> Alternatively:
>
> In step 3, the X-Meta header is not present, but the content type is
> text/html. Then:
> In step 4, Identity consumer parses HTML document for special tag  
> inside
> HTML HEAD -- that could be a link tag, or -- what I'd like better  
> given
> the parallels with http-equiv -- looks for <meta http-equiv="X-Meta"
> content="http://capabilities.example.biz/
> walter" />
> in the HTML document and proceeds as before.
>
> Regardless of whether you like my proposal or not (I hope you do ...)
> -- are there any requirements that I'm not addressing with this
> proposal?
>
>
>
> Johannes Ernst

Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051117/cbd3ec55/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst