I changed the Subject to fit the discussion.
It is not me who decides what but the WG so this is just my personal
opinion,
but to me, Artifact is an opaque string to the RP. i.e., it can be
anything, and it does not matter.
It is up to the OP to create and consume artifact. Only requirement in
the contributed
document is that it has to be constructed partly from RFC1750
pseudorandom number sequence
to thwart guessing. Since it is OP who creates and consume it, the OP
can encrypt it by
his symmetric key.
If you wanted to express whether it was encrypted or not, there are two
ways of doing it, IMHO.
One is as you suggested, to do it in the AB itself. In this case, I
would support the idea of
arbitrary token types.
The other is to do it through PAPE.
If it were just for LoA, I feel that keeping the Artifact completely
opaque and
using PAPE for LoA purpose is the right way to do.
=nat
(2010/02/08 23:59), John Bradley wrote:
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]
<mailto:[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] <mailto:[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] <mailto:[email protected]>
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
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
