Hmmm. OK. Got it. So, it probably is the topic that we might want to revisit when we introduce new response type like JSON in v.next, if we ever do, I suppose. There may be some cases that we might want to respond to the request at once. (Do not know if there would be.)
Thanks. =nat On Mon, Feb 8, 2010 at 3:03 PM, Will Norris <[email protected]> wrote: > > 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 > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
