[Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope
nov at matake.jp
Thu Jun 7 09:16:39 UTC 2012
Forgive me sending more in this ML.
I feel id_token which includes userinfo is different kind of token from
which doesn't include it.
If we define new response_type, what we need is defining new 4 patterns
>From a ruby openid-connect library developer's view, those 4 is not so
# Current defined response types
code id_token token
# New response types
code id_token_with_claims token
# Not defined
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)
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.
> 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>
>> > 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
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab