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

Nat Sakimura sakimura at gmail.com
Fri Jun 15 13:50:37 UTC 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120615/d69dbdec/attachment-0001.html>


More information about the Openid-specs-ab mailing list