[Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope
Michael.Jones at microsoft.com
Thu Jun 7 07:55:12 UTC 2012
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.
From: 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
Subject: Re: [Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope
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.
2012/6/7 Nat Sakimura <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> 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
>> Mobile +46 70 696 68 44
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
Email : ritou.06 at gmail.com
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab