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

[John Bradley]

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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/3093e6c8/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/3093e6c8/attachment.p7s>