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