Super all-comprehensive specs/overview page

[Martin Atkins]

Brad Fitzpatrick wrote:
> Money, fast cars, diamond rings, gold chains and champagne --- Shit, every
> damn thing....
> 
>     http://www.openid.net/specs.bml
> 
> It's got it all.  (well: overview, terminology, detailed specs, notes, ....)
> 

A couple of concerns...


Regarding the identity delegation stuff, it says that in order to
declare delegation you must include the following:
<link rel="openid.server"
      href="http://www.livejournal.com/openid/server.bml">
<link rel="openid.delegate"
      href="http://bob.livejournal.com/">

However, not much detail is given other than that. Am I right that the
consumer then just proceeds as normal but asks for
http://bob.livejournal.com/ instead of http://bob.com/? There are no
extra requests to fetch http://bob.livejournal.com/, right?

So now it's the consumer's responsibility to remember that
http://bob.livejournal.com/ really wants to be called http://bob.com/,
even though the identity server is going to come back talking about
http://bob.livejournal.com/. This is kinda backwards from how it worked
with the old protocol, but I see the logic here.

Also, this sentence confuses me:
    The consumer then parses the head section and finds the
    openid.server and (optionally) the openid.delegate declarations.

Surely all consumers must support openid.delegate? If they don't, then
any users using it will be screwed because livejournal.com won't know
anything about bob.com. I'm guessing that what is meant is that the
openid.delegate specification is optional, but the way this sentence is
written makes the "optionally" be for the parsing, not for the including
of it in the first place. It might be better to write:
    The consumer then parses the head section and finds the
    openid.server delcaration and the optional openid.delegate
    declaration.

If I'm wrong about any of this, please correct me. Either way, please
include more detail about this in the spec, as I just guessed all of
this. I think as it's currently written implementors are likely to get
bits of it wrong, especially if (like me) they were familiar with the
old protocol.

----------------------

Also, for check_authentication:
    Send all the openid.* response parameters you'd previously gotten
    back from a "checkid_*" request, with their values being exactly
    what you got back. For example, send "openid.identity",
    "openid.assoc_handle", "openid.issued", "openid.valid_to",
    "openid.return_to", "openid.signed", "openid.sig", ...

I'm not sure I like this "send back whatever you got" thing. Am I
supposed to check all of the request args and see which ones start with
openid., or is it sufficient just to use the ones listed here?

In the former case, I'm sure there are some places where this will be
difficult. For example, I seem to remember from before that the Consumer
perl module can accept a closure which returns a value given a key name.
How do you implement this "wildcard" parameter in that case? There's
nowhere to get a list of "all parameters".

-----------------------

There are also a few places where "client" is used where "consumer" is
more appropriate. I think avoiding the word "client" altogether is best,
as it's often confusing as to whether the consumer or the user-agent are
being the client at this point.