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

Mike Jones Michael.Jones at microsoft.com
Fri Jun 15 16:20:09 UTC 2012


+1 to making clear MTI statements in the specs

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Friday, June 15, 2012 8:38 AM
To: Brian Campbell
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope

Everything in the Standard, especially the request, needs to be understood by an IdP.
A parameter marked "OPTIONAL" just means that it is optional per request.
It does not mean that it is optional for an IdP to implement.
An IdP MUST at least understand them.
Obviously, a client can choose to implement only a subset of it, as it is the client which is making the request.

I will file a bug to define MTI clearly as a separate section.

Best,

Nat

On Fri, Jun 15, 2012 at 10:53 PM, Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>> wrote:
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<mailto: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<mailto: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<mailto: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<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<mailto: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<mailto: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<mailto: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> [mailto: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<mailto: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<mailto: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<tel:%2B46%2090%20786%2068%2044>
>> >> Mobile +46 70 696 68 44<tel:%2B46%2070%20696%2068%2044>
>> >> www.its.umu.se<http://www.its.umu.se>
>> >>
>> >> _______________________________________________
>> >> Openid-specs-ab mailing list
>> >> Openid-specs-ab at lists.openid.net<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
>



--
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/4838e475/attachment-0001.html>


More information about the Openid-specs-ab mailing list