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

Brian Campbell bcampbell at pingidentity.com
Fri Jun 15 13:53:25 UTC 2012


Can you point me to the spec text that says that? I didn't see it.

On Fri, Jun 15, 2012 at 7:50 AM, Nat Sakimura <sakimura at gmail.com> wrote:
> Just one point. Support for the request object is not optional for the IdP.
> It is only optional to the clients.
>
> =nat
>
> On Fri, Jun 15, 2012 at 6:21 AM, Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>>
>> I've tried to articulate some thoughts before the call tomorrow - lots
>> inline below...
>>
>> On Thu, Jun 7, 2012 at 11:11 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> > Yes the request object is the general case.  We have always been able to
>> > return claims in the id_token using that.
>>
>> You and Mike have both said that the request object is the general
>> case throughout this discussion. Coming from the spec authors/editors,
>> that statement needs to be given its due respect. But as an
>> implementer I'd like to offer a somewhat different perspective. I'm
>> building OP functionality into an existing OAuth AS product so, to me,
>> the general case for everything is OAuth. Things that fit nicely
>> within OAuth or extend easily from it are welcome as an implementer
>> while things that crosscut existing concepts or functionality are
>> unwelcome and cumbersome.
>>
>> Support for the OpenID Request Object  is an optional and, even after
>> several readings of the spec, is frankly rather confusing. To me
>> (again looking at it as an implementer), the Request Object is kind of
>> an afterthought and something I'll try to back in support for later as
>> needed and to the extent it doesn't interfere  with other
>> functionality. I might be alone in this view but some other discussion
>> suggest I'm not the only one - for example, 'By now we did not get
>> down to the "request object"' from
>>
>> http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120604/002030.html.
>>
>> I'm not trying to say one way or the other is right but only that
>> there are different ways of looking at this which are likely informed
>> by one's experience and what they're doing with this suite of specs.
>>
>> > The simple thing is to say that if you want claims in the id_token use
>> > the
>> > request object.   No new response types required.
>> >
>> > The question at the meeting was how do we do it without a request object
>> > being required.
>>
>> I'm starting to wonder if we even need a shorthand way to request claims
>> in
>> the id token. In many of the cases it seems like it is something that
>> is ultimately up to the IdP/OP. Was not the impetus for this the so
>> called 'self issued' OP on a phone that couldn't have a user info
>> endpoint? In that case, does the client really need to request that
>> the claims be returned in the id token? The AS can't do anything else
>> with them (other than omit them, I guess).
>>
>> > I am against adding a new response type because there is no new
>> > response.
>>
>> Agree.
>>
>> > If anything they are new scopes because they are returning the info from
>> > a
>> > new endpoint.
>>
>> I'm not sure I agree there. I guess it depends on how you interpret or
>> define the scopes and, admittedly, that is left pretty open ended by
>> the OAuth Framework. But I think about scopes as making more sense as
>> being something an end user grants access to rather than about how
>> that access might be exercised.  If, as an end user, I approve access
>> to my profile information, I don't really care how the client access
>> it (as long as it's not irresponsible).
>>
>> > Having a scope that modifies other scopes endpoints works, but has been
>> > pointed out as awkward to program.
>> >
>> > A new OAuth parameter just for this also seems a bit overkill.
>>
>> From my perspective this seems like the simplest way to deal with it.
>>
>> This text could be added near the bottom of Messages §2.1.2
>>
>> claims_in_id_token
>>    OPTIONAL. If this parameter is present and its value is true, the
>> client is requesting that the voluntary claims requested with the
>> profile, email, address, and phone scope values are returned in the ID
>> Token, rather than from the UserInfo Endpoint. The default is false.
>>
>> And then add the following boilerplate text to Standard (BTW, is there
>> a reason all these parameter are defined in one spec but registered in
>> a different one?).
>>
>> 9.1.X.  Authorization Request Parameter (claims_in_id_token)
>>
>> The following is a parameter registration request for the
>> Authorization Request in this specification:
>>
>>    Parameter name: claims_in_id_token
>>    Parameter usage location: Authorization Request
>>    Change controller: IETF
>>    Specification document(s): [[ this document ]]
>>    Related information: None
>>
>>
>> > So the options in preference from my perspective are:
>> >
>> > 1)  New scopes specific to delivering the claims in the id_token.
>> > 2)  Scope that modifies the existing scopes (profile, email, address,
>> > phone)
>> > As we have it now.
>> > 3)  Clients must user the request object to get claims in the id_token.
>> >
>> > This is a convenience for Self Issued and other IdP who don't want to
>> > support the extra round trip.
>>
>> Again, if it's really for the IdP, do we need a shorthand way for the
>> client to request it?
>>
>> > I don't want to complicate the common case by adding more OAuth
>> > parameters
>> > or return types we have enough.
>>
>> An optional parameter with a default that behaves as it already does
>> when omitted seems like the simplest and least complicated.
>>
>> > John B.
>> >
>> > On 2012-06-07, at 11:36 AM, Mike Jones wrote:
>> >
>> > I have to respectfully disagree with your statement than an ID Token
>> > with
>> > claims is a different kind of token from one which doesn’t include
>> > them.  I
>> > believe that looking at the general case, which is using the OpenID
>> > Request
>> > Object, will help illustrate why I believe that this is the case.
>> >
>> > Both the ID Token and the UserInfo endpoint return claims.  There are
>> > sections of the OpenID Request Object for requesting claims for each
>> > location.  For instance, the following request object body requests that
>> > the
>> > “email” and “email_verified” claims be returned in both locations:
>> >
>> > {“id_token”:{
>> >     “claims”:
>> >         {“email”: null},
>> >          “email_verified”: null}),
>> > “userinfo”:{
>> >     “claims”:
>> >         {“email”: null,
>> >          “email_verified”: null }}
>> > }
>> >
>> > Whether the “email” and “email_verified” claims are present in the ID
>> > Token
>> > doesn’t make it a different kind of token.  It just changes the claims
>> > present in the ID Token.  One thing that becomes apparent when
>> > considering
>> > things in this manner is that no new response types are needed to return
>> > requested claims in the ID token.
>> >
>> > I think it would be useful for people to first work out their request
>> > examples as OpenID Request Objects and *then* consider what shorthands
>> > we
>> > want to have to achieve those same things for simple cases without using
>> > an
>> > OpenID Request Object (if any).  The Request Object is the general case,
>> > and
>> > the architecture should derive from it.  Anything expressible in the
>> > shorthand syntax must also be (naturally) expressible in the general
>> > form.
>> >
>> >                                                             -- Mike
>> >
>> >
>> > From: matake, nov [mailto:nov at matake.jp]
>> > Sent: Thursday, June 07, 2012 2:17 AM
>> > To: Nat Sakimura
>> > Cc: Mike Jones; openid-specs-ab at lists.openid.net
>> > Subject: Re: [Openid-specs-ab] Please respond: poll on
>> > claims_in_id_token
>> > switch in the scope
>> >
>> > 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
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>


More information about the Openid-specs-ab mailing list