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

Tue Feb 9 01:22:44 UTC 2010

I wasn't referring to the artifact itself.  I agree that should be opaque.

I am talking about the token that is returned from the direct communication.

That needs to be encrypted.

Encrypting it with the symmetric key works as a basic option.

The RP needs some way to signal the OP what token type it wants to get.

EG plain,  plane + symetric,  plane + asymetric,  jason + asymetric etc.

I don't know that overloading PAPE is the best thing.

John B.

On 2010-02-08, at 10:14 PM, Nat Sakimura wrote:

> 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> 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
>> 
>> 
>> _______________________________________________
>> 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
> _______________________________________________
> 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/df6785f4/attachment.htm>