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

[Breno de Medeiros]

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