(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. This led me to these question:
"Why are we putting openid.* in those request? / Why are we not putting
openid.* to the response? "
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.
You certainly don't need to add the prefix to KVF message to have
consistency within an OpenID library. For example, in the Internet2
library that logic is entirely encapsulated within the message encoder
and decoder. Compare URLFormCodec[0] to KeyValueFormCodec[1].
Everywhere else in the library, all message are treated exactly the
same, regardless of how they were encoded on the wire.
[0]:
http://svn.middleware.georgetown.edu/view/java-openid/trunk/src/main/java/edu/internet2/middleware/openid/message/encoding/impl/URLFormCodec.java?view=markup
[1]:
http://svn.middleware.georgetown.edu/view/java-openid/trunk/src/main/java/edu/internet2/middleware/openid/message/encoding/impl/KeyValueFormCodec.java?view=markup
No, we do not. I have never seen a library that puts openid.* in KVF. My
curiosity after seeing Hideki's mail was not the current implementation
issue but about the future consistency and a little bit of historical
perspective.
On Feb 7, 2010, at 4:22 AM, Paul E. Jones wrote:
For use in Key-Value Form, I didn't see it as necessary when I
implemented
the spec. It seemed logical not the be there.
The only reason why one might want to use this is to include some
kind of
non-standard information. Is that something folks would want to
encourage?
Anyway, changing the spec to have "openid." there now would break
things, so
I would not recommend it unless there was a really good reason.
Paul
-----Original Message-----
From: [email protected] [mailto:openid-specs-
[email protected]] On Behalf Of Nat Sakimura
Sent: Monday, February 01, 2010 12:14 AM
To: [email protected]
Subject: Re: "openid." name space of KeyValue Form
Hmmm
That's a good question. The reason we put openid.* in the request and
response is that there may be other applications sharing the same
request/response. If so, it would be more consistent if we put openid.*
prefix to the keys of the direct response as well...
Is it just an oversight, or did it have a good reason for it?
=nat
(2010/02/01 13:49), nara hideki wrote:
Hello all,
I'm thinking of the good reason why "openid." name space to keys of
Key-Value Form Encoding used for direct responses is dropped.
I think that we MAY use "openid." name space.
I'm very happy if someone give me a good cue to understand the
reason.
Thanks in advance.
----
hdknr
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
--
Nat Sakimura ([email protected])
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
_______________________________________________
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
_______________________________________________
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
