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

Fri Jan 7 17:12:16 UTC 2011

On Fri, Jan 7, 2011 at 08:58, John Bradley <ve7jtb at ve7jtb.com> wrote:

> I thought part of the use case was that the RP could directly verify the
> signed response and get the user ID without making a second call if they are
> pre-registerd and don't need additional info?
>

I think this is crucial in frequent session synchronization-like calls to
ensure the user is still logged in at the provider, but not as essential in
initial login (by which I mean there's no session at the RP).

Sending the identifier through the browser adds a fair amount of complexity.

>
> So the user ID needs to be there in some signed portion.
>
> I suppose we could send a JWT that included code but that seems like
> duplication.
>
> John B.
>
> On 2011-01-07, at 1:41 PM, Nat Sakimura wrote:
>
> 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
>
>
>

-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/72167b25/attachment.html>