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

Ryo Ito ritou.06 at gmail.com
Thu Jun 7 10:02:49 UTC 2012


> 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.

Oh, I misunderstood it.
It is simple to add new Token Type like 2-a.

+1
> 1. b)
> 2. a)
> 3. a)

Ryo

2012/6/7 matake, nov <nov at matake.jp>:
> 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
>>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



-- 
====================
Ryo Ito
Email : ritou.06 at gmail.com
====================


More information about the Openid-specs-ab mailing list