[Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope

Mike Jones Michael.Jones at microsoft.com
Thu Jun 7 08:07:02 UTC 2012


If there's not another token, it doesn't make logical sense to have another response type.  Each response type should correspond to a token being requested, if they're going to make much sense to developers.

                                                            -- Mike
From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Thursday, June 07, 2012 1:03 AM
To: Mike Jones
Cc: Ryo Ito; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope

Ryo is not suggesting to create another token, I think. He is suggesting to get those claims into id_token.

Is that correct, Ryo?

Nat
On Thu, Jun 7, 2012 at 4:55 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
Using a new response type would make the specification and implementations more complicated - not simpler.  That's why the working group decided to add the claims to the ID Token - not create yet another token.  We're already getting serious push-back on having a second one.  Adding a third one would cause many people to write us off as building something WAY too complex - at least as I see it.  Reread http://hg.openid.net/connect/issue/521 for one such comment we've already received that I transcribed.

It's a simplification to allow all claims to be returned in one token.  Suggesting three, while "logical", in practice, is probably more complexity than implementers will be willing to put up with!  I feel very strongly about this.

Complexity is the enemy of adoption.

                               -- Mike

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Ryo Ito
Sent: Thursday, June 07, 2012 12:41 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope

1. b)

2. b)

3. a)

I think that response_type params allows the flexible definition.
"id_token userinfo" means that id_token includes user claims.
If more detailed claims control is necessary, RP uses Request Object.

Ryo.

2012/6/7 Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>>:
> I would like to take this issue to a closure quickly.
> These issues were discussed at F2F on May 1.
> However, that was only among the f2f participant.
> I understand the current comments are from those who were not at F2F,
> and implementers' comments from those implementing it.
> I would appreciate a quick response to the following questions so to
> sum up a bit to help the progress in this issue:
>
> 1. Please indicate which is your preferred way.
>
>    a) Using claims_in_id_token switch in the "scope"
>    b) Using a new response type.
>
>    Note: on May 1 F2F, 1-a) was chosen. This is how the current draft
> was prepared. (cf. issue #561)
>
> 2. If 1-b) is chosen, which do you prefer:
>
>    a) A combined response type: e.g., id_token_with_userinfo
>    b) combination of id_token and userinfo
>
> 3. As a method for returning userinfo claims in the front channel,
> which do you prefer?
>
>     a) Claims in id_token
>     b) separate userinfo token with its metadata in id_token?
>
>     Note: At the F2F, a) was chosen.
>
> Thanks for your cooperation.
>
> Nat Sakimura
>
> On 2012/06/07, at 15:29, Roland Hedberg <roland.hedberg at adm.umu.se<mailto:roland.hedberg at adm.umu.se>> wrote:
>
>>
>> 7 jun 2012 kl. 07:40 skrev nov matake:
>>
>>> I'm OK with both making single "id_token_with_userinfo" response type or combination of "id_token" and "userinfo".
>>
>>
>> I'm definitely in favor of the later.
>> That is letting 'id_token' contain metadata about the userinfo and the authentication, and 'userinfo' pure user info.
>> Similar to the structure of the openid request object.
>>
>> -- Roland
>> ------------------------------------------------------
>> Roland Hedberg
>> IT Architect/Senior Researcher
>> ICT Services and System Development (ITS) Umeå University
>> SE-901 87 Umeå, Sweden
>> Phone +46 90 786 68 44<tel:%2B46%2090%20786%2068%2044>
>> Mobile +46 70 696 68 44<tel:%2B46%2070%20696%2068%2044>
>> www.its.umu.se<http://www.its.umu.se>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net<mailto: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<mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



--
====================
Ryo Ito
Email : ritou.06 at gmail.com<mailto:ritou.06 at gmail.com>
====================
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto: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<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120607/b7fb2364/attachment.html>


More information about the Openid-specs-ab mailing list