Artifact Types (was: Re: "openid." name space of KeyValue Form)

[Nat Sakimura]

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


-- 
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100209/cd8925b5/attachment.htm>