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

Fri Jan 7 17:26:58 UTC 2011

Sending the identifier through the browser only works for low assurance cases eg LoA 1. 

It however was one of the features of Connect.   

I am not personally attached to it as it causes a bunch of problems.

In session synchronization calls any mutually agreed session identifier should work.  I don't think it necessarily needs to be the userID though that may be more convenient in some circumstances.

It is almost better to have a clearly separate session identifier on a per RP basis for the user.  That may make adding SLO easier in future.

John B.
On 2011-01-07, at 2:12 PM, Breno de Medeiros wrote:

> 
> 
> 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/145b5d36/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/145b5d36/attachment.p7s>