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

Tue Feb 9 18:52:19 UTC 2010

I can see different security requirements requiring different encryption.  

In a LoA 3 situation using a asymmetric key may be a requirement. 

The Key value token format is simple to process but has limitations.  

It may be that using a structured Simple Web Token, JASON Web Token or XML format may work better in some applications.

I thought it was you that raised the Jason formatted token idea.

I don't necessarily want to define a bunch of token types now.   

I do however think we should plan for it if it is something we will want to do later.

I do think that there needs to be a symmetrically  or asymmetrically encrypted token type.  

The alternatives to make openID LoA 2+ are much more painful.

John B.
On 2010-02-08, at 10:51 PM, Nat Sakimura wrote:

> If the usecase is real, I am all for it, but I am not sure why RP wants to have a specific type of OP token. Could you elaborate a little more? 
> 
> =nat
> 
> P.S., since we are talking about use cases etc., I am assuming it is still safe to do this at spes at . 
> 
> On Tue, Feb 9, 2010 at 10:22 AM, John Bradley <john.bradley at wingaa.com> wrote:
> 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
> 
> 
> _______________________________________________
> 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

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