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. _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
