[Openid-specs-ab] Connect Question: Variable "signed" in the response

[Nat Sakimura]

Well, the initial token sounds like a "code".

I prefer opaque "code" to the b64url encoded combination of user_id etc., as
it has a chance of leaking the information unnecessarily.

So, to paraphrase, the question is whether the User Authorization Endpoint
should return the "code" or more information, I suppose. I prefer "code"
approach, but I am probably biased as that is how things were done in AB
drafts up to now.

=nat

On Sat, Jan 8, 2011 at 1:00 AM, Breno de Medeiros <breno at google.com> wrote:

> There's an alternative proposal (I just made in another thread) to simply
> do away with the token-in-token and also how to encode a token in the
> response.
>
> The proposal is to return a regular OAuth2 token and a standard OAuth2
> response. The token is opaque, not JWT.
>
> The UserInfo endpoint would return both plaintext user data and a signed
> JWT token including a subset of the user information that can be used as a
> cookie.
>
> This adds a round-trip to initial sign-in, but subsequent 'pings' for
> confirmation of session presence can be made directly to the
> UserInfoEndpoint, using the access token as before.
>
> This approach works identically for WebServer and UserAgent flows. In both
> cases, the UserInfo endpoint is a standard OAuth2-protected resource, with a
> set of specified fields it must return (including signed JWT).
>
> What do you think about this?
>
>
> On Fri, Jan 7, 2011 at 07:39, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
>> Yes I think it is a restricted form of access token.   The main difference
>> is that you can require a shared secret to be sent with code,  where there
>> seems to be no oAuth 2.0 way to do the same with an access token.
>>
>> I think that is something that should be rationalized in oAuth 2.0.
>>
>> John B.
>>
>> On 2011-01-07, at 4:50 AM, Nat Sakimura wrote:
>>
>> In fact, the difference between code and access_token seems to be as
>> follows:
>>
>> code:
>>     applicable endpoint: One Predefined Endpoint Only (token endpoint)
>>     cardinality of the use: Only Once.
>> access_token:
>>     applicable endpoint: Potentially Many Endpoints
>>     cardinality of the use: Many.
>>
>> So, "code" in fact is a restricted form of access_token.
>>
>> =nat
>>
>> On Thu, Jan 6, 2011 at 4:55 PM, hideki nara <hdknr at ic-tact.co.jp> wrote:
>>
>>> access_token is enough.
>>> If the other token format than JWT can be allowed,  we need some way
>>> to negotiate.
>>>
>>> "code" looks like an artifact. But if tokens are forced to be in
>>> self-describing forms,  "code" seems to be ok.
>>> ---
>>> hdknr
>>>
>>> 2011/1/6 Breno de Medeiros <breno at google.com>:
>>> > +1
>>> > Everything about the response content should be signed. It just makes
>>> things
>>> > simpler to process.
>>> >
>>> > On Wed, Jan 5, 2011 at 02:40, Nat Sakimura <sakimura at gmail.com> wrote:
>>> >>
>>> >> Hi.
>>> >> The current openidconnect.com page has a variable "signed" in the
>>> >> response.
>>> >> It is a new variable which is not present in the current OAuth draft.
>>> >> The "signed" includes access_token and user_id among other things. It
>>> >> probably should be a JWT.
>>> >> Should we continue to use "signed" or other variable name?
>>> >> The reason why I am asking this are:
>>> >> 1. It looks a lot like a structured "code" or "access_token". Perhaps
>>> >> should we call it "access_token" (or "code") instead?
>>> >> 2. If we are to introduce a new variable, "signed" seem to be a little
>>> too
>>> >> generic. Is there a better name for it? (Perhaps "openid"?)
>>> >>
>>> >> --
>>> >> Nat Sakimura (=nat)
>>> >> http://www.sakimura.org/en/
>>> >> http://twitter.com/_nat_en
>>> >>
>>> >> _______________________________________________
>>> >> Openid-specs-ab mailing list
>>> >> Openid-specs-ab at lists.openid.net
>>> >> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > --Breno
>>> >
>>> > _______________________________________________
>>> > Openid-specs-ab mailing list
>>> > Openid-specs-ab at lists.openid.net
>>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
>>  _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>
>
> --
> --Breno
>



-- 
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-ab/attachments/20110108/a7671899/attachment.html>