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

Tue Feb 9 01:51:35 UTC 2010

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 listspecs at lists.openid.nethttp://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/95bcb795/attachment.htm>