"openid." name space of KeyValue Form
John Bradley
john.bradley at wingaa.com
Mon Feb 8 14:59:46 UTC 2010
The Artifact binding will have to support a encrypted token type or types if it is going to be LoA 2+ compliant.
The question is if you are going to support 2 token types, should it be generalized to support arbitrary token types.
John B.
On 2010-02-08, at 8:16 AM, Nat Sakimura wrote:
> 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
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100208/809e7de2/attachment.htm>
More information about the specs
mailing list