"openid." name space of KeyValue Form
Will Norris
will at willnorris.com
Mon Feb 8 06:03:43 UTC 2010
On Feb 7, 2010, at 8:45 PM, Nat Sakimura wrote:
> (2010/02/08 10:50), Will Norris wrote:
>> I've never thought of the "openid." prefix as part of the parameter name, even in URL form encoded messages... it's simply a namespace prefix to ensure URL parameters don't collide. It's completely unnecessary in KVF encoded messages, and would add nothing but extra size to the payload.
>
> That's what I was thinking. But after Hideki's message, I started to doubt that a bit.
> Currently, we only use Direct Response in a very limited way: (1) association response and (2) direct verification. In both case, we actually only send openid.* parameters in the request, so we do not need any name space qualifier in the response.
Not necessarily. What about when the OpenID server's URL is "http://example.com/?service=openid" ? This was actually the case for the WordPress OpenID plugin for a long time, and is still true for certain deployments, I believe. You can't make any assumptions about what the base URL will be, or what additional parameters may be present, hence why the "openid." is certainly necessary in those cases.
> If we do not send anything but openid parameters on the request, openid.* as a part of url is redundant.
> If there is value in having openid.* in the request, then that is to send parameters in other name-spaces, in which case, the response may include other parameters as well, and we need name-space qualifier.
allowing non-OpenID parameters in a direct response has never been a design goal, nor do I believe that it should be. KVF encoding is a new format defined by the OpenID spec, so it is perfectly acceptable to state that it is only for OpenID related parameters. This is not the case for URL parameters.
More information about the specs
mailing list