proposal for capabilities lookup

[David Recordon]

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