"openid." name space of KeyValue Form

[Nat Sakimura]

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 <will at willnorris.com> 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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100208/c8cd3aa7/attachment.htm>