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

matake, nov nov at matake.jp
Thu Jun 7 09:16:39 UTC 2012


Forgive me sending more in this ML.

> Mike
I feel id_token which includes userinfo is different kind of token from
which doesn't include it.

> Nat
I prefer
1. b)
2. a)
3. a)

If we define new response_type, what we need is defining new 4 patterns
listed below.
>From a ruby openid-connect library developer's view, those 4 is not so
complicated.

===
# Current defined response types
code
token
id_token
code id_token
id_token token
code id_token token

# New response types
id_token_with_claims
code id_token_with_claims
id_token_with_claims token
code id_token_with_claims token

# Not defined
id_token id_token_with_claims
code id_token id_token_with_claims
id_token id_token_with_claims token
 :
===

I don't think defining separate "userinfo" response_type introduces more
patterns (aka flexibility?) listed here.
At least I don't know any use-case except for ones listed above.
(ie. "userinfo token", which will require returning userinfo token
separated from id_token)

ps.
If we have call, I'll join.
Both early morning and night (after 10pm) in JST works for me.

2012/6/7 Nat Sakimura <sakimura at gmail.com>

> OK. I seemed to have screwed up the list of options etc.
>
> Also, as the list is terse and it did not include the precise definition
> of each terms, it led to people talking about different things using the
> same word. This is another screwing up on my part.
>
> Rather than doing it through mailing list poll, it probably is better to
> have a call on this issue in a very near future at a time where European
> participants can also call in, e.g., 11pm JST, 4pm CDT (EU), 10am EDT, 7am
> PDT. That will let people speak up, explain the meaning, etc. and a whole
> lot more constructive. Perhaps we should do a doodle poll on the timing.
>
> Nat
>
> On Thu, Jun 7, 2012 at 4:42 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:
>
>> This list left out the possibility that John discussed of having separate
>> scope request values such as email_id that specifically request that sets
>> of scope values be included in the ID Token.  (I'm not necessarily in favor
>> of this, but it was discussed at Yahoo and on the list, so should be part
>> of what people react to.)
>>
>> This list left out the suggest of Brian's that a different request
>> parameter be defined to act as the switch that the profile, email, address,
>> and phone scope values return claims in the ID Token, rather than the
>> switch being the claims_in_id_token scope.  If we're reconsidering all
>> options, this one shouldn't be excluded.
>>
>> I don't think there had been any discussion on the list to date since the
>> decisions at Yahoo proposing your option 1b (using a different response
>> type).  I've heard people discussing *how* claims should be directed to the
>> ID Token - not *whether* they should be.  I hope we don't try to reopen
>> that part of the decision as well, especially because no one has proposed
>> reopening it.  As such, I don't believe that it's productive to discuss 1b,
>> 2, or 3b, given that no one has suggested that they are dissatisfied with
>> the option to return claims in the ID token - only the syntax for saying to
>> do it.
>>
>> My two cents worth...
>>
>>                                -- Mike
>>
>> -----Original Message-----
>> From: openid-specs-ab-bounces at lists.openid.net [mailto:
>> openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
>> Sent: Wednesday, June 06, 2012 11:57 PM
>> To: Roland Hedberg
>> Cc: openid-specs-ab at lists.openid.net
>> Subject: [Openid-specs-ab] Please respond: poll on claims_in_id_token
>> switch in the scope
>>
>> 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
>> > www.its.umu.se
>> >
>> > _______________________________________________
>> > 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
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120607/989d02db/attachment-0001.html>


More information about the Openid-specs-ab mailing list