Just one point. Support for the request object is not optional for the IdP. <div>It is only optional to the clients. </div><div><br></div><div>=nat</div><br><div class="gmail_quote">On Fri, Jun 15, 2012 at 6:21 AM, Brian Campbell <span dir="ltr"><<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've tried to articulate some thoughts before the call tomorrow - lots<br>
inline below...<br>
<div class="im"><br>
On Thu, Jun 7, 2012 at 11:11 AM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br>
> Yes the request object is the general case.  We have always been able to<br>
> return claims in the id_token using that.<br>
<br>
</div>You and Mike have both said that the request object is the general<br>
case throughout this discussion. Coming from the spec authors/editors,<br>
that statement needs to be given its due respect. But as an<br>
implementer I'd like to offer a somewhat different perspective. I'm<br>
building OP functionality into an existing OAuth AS product so, to me,<br>
the general case for everything is OAuth. Things that fit nicely<br>
within OAuth or extend easily from it are welcome as an implementer<br>
while things that crosscut existing concepts or functionality are<br>
unwelcome and cumbersome.<br>
<br>
Support for the OpenID Request Object  is an optional and, even after<br>
several readings of the spec, is frankly rather confusing. To me<br>
(again looking at it as an implementer), the Request Object is kind of<br>
an afterthought and something I'll try to back in support for later as<br>
needed and to the extent it doesn't interfere  with other<br>
functionality. I might be alone in this view but some other discussion<br>
suggest I'm not the only one - for example, 'By now we did not get<br>
down to the "request object"' from<br>
<a href="http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120604/002030.html" target="_blank">http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120604/002030.html</a>.<br>
<br>
I'm not trying to say one way or the other is right but only that<br>
there are different ways of looking at this which are likely informed<br>
by one's experience and what they're doing with this suite of specs.<br>
<div class="im"><br>
> The simple thing is to say that if you want claims in the id_token use the<br>
> request object.   No new response types required.<br>
><br>
> The question at the meeting was how do we do it without a request object<br>
> being required.<br>
<br>
</div>I'm starting to wonder if we even need a shorthand way to request claims in<br>
the id token. In many of the cases it seems like it is something that<br>
is ultimately up to the IdP/OP. Was not the impetus for this the so<br>
called 'self issued' OP on a phone that couldn't have a user info<br>
endpoint? In that case, does the client really need to request that<br>
the claims be returned in the id token? The AS can't do anything else<br>
with them (other than omit them, I guess).<br>
<div class="im"><br>
> I am against adding a new response type because there is no new response.<br>
<br>
</div>Agree.<br>
<div class="im"><br>
> If anything they are new scopes because they are returning the info from a<br>
> new endpoint.<br>
<br>
</div>I'm not sure I agree there. I guess it depends on how you interpret or<br>
define the scopes and, admittedly, that is left pretty open ended by<br>
the OAuth Framework. But I think about scopes as making more sense as<br>
being something an end user grants access to rather than about how<br>
that access might be exercised.  If, as an end user, I approve access<br>
to my profile information, I don't really care how the client access<br>
it (as long as it's not irresponsible).<br>
<div class="im"><br>
> Having a scope that modifies other scopes endpoints works, but has been<br>
> pointed out as awkward to program.<br>
><br>
> A new OAuth parameter just for this also seems a bit overkill.<br>
<br>
</div>From my perspective this seems like the simplest way to deal with it.<br>
<br>
This text could be added near the bottom of Messages §2.1.2<br>
<br>
claims_in_id_token<br>
    OPTIONAL. If this parameter is present and its value is true, the<br>
client is requesting that the voluntary claims requested with the<br>
profile, email, address, and phone scope values are returned in the ID<br>
Token, rather than from the UserInfo Endpoint. The default is false.<br>
<br>
And then add the following boilerplate text to Standard (BTW, is there<br>
a reason all these parameter are defined in one spec but registered in<br>
a different one?).<br>
<br>
9.1.X.  Authorization Request Parameter (claims_in_id_token)<br>
<br>
The following is a parameter registration request for the<br>
Authorization Request in this specification:<br>
<br>
    Parameter name: claims_in_id_token<br>
    Parameter usage location: Authorization Request<br>
    Change controller: IETF<br>
    Specification document(s): [[ this document ]]<br>
    Related information: None<br>
<div class="im"><br>
<br>
> So the options in preference from my perspective are:<br>
><br>
> 1)  New scopes specific to delivering the claims in the id_token.<br>
> 2)  Scope that modifies the existing scopes (profile, email, address, phone)<br>
> As we have it now.<br>
> 3)  Clients must user the request object to get claims in the id_token.<br>
><br>
> This is a convenience for Self Issued and other IdP who don't want to<br>
> support the extra round trip.<br>
<br>
</div>Again, if it's really for the IdP, do we need a shorthand way for the<br>
client to request it?<br>
<div class="im"><br>
> I don't want to complicate the common case by adding more OAuth parameters<br>
> or return types we have enough.<br>
<br>
</div>An optional parameter with a default that behaves as it already does<br>
when omitted seems like the simplest and least complicated.<br>
<div class="HOEnZb"><div class="h5"><br>
> John B.<br>
><br>
> On 2012-06-07, at 11:36 AM, Mike Jones wrote:<br>
><br>
> I have to respectfully disagree with your statement than an ID Token with<br>
> claims is a different kind of token from one which doesn’t include them.  I<br>
> believe that looking at the general case, which is using the OpenID Request<br>
> Object, will help illustrate why I believe that this is the case.<br>
><br>
> Both the ID Token and the UserInfo endpoint return claims.  There are<br>
> sections of the OpenID Request Object for requesting claims for each<br>
> location.  For instance, the following request object body requests that the<br>
> “email” and “email_verified” claims be returned in both locations:<br>
><br>
> {“id_token”:{<br>
>     “claims”:<br>
>         {“email”: null},<br>
>          “email_verified”: null}),<br>
> “userinfo”:{<br>
>     “claims”:<br>
>         {“email”: null,<br>
>          “email_verified”: null }}<br>
> }<br>
><br>
> Whether the “email” and “email_verified” claims are present in the ID Token<br>
> doesn’t make it a different kind of token.  It just changes the claims<br>
> present in the ID Token.  One thing that becomes apparent when considering<br>
> things in this manner is that no new response types are needed to return<br>
> requested claims in the ID token.<br>
><br>
> I think it would be useful for people to first work out their request<br>
> examples as OpenID Request Objects and *then* consider what shorthands we<br>
> want to have to achieve those same things for simple cases without using an<br>
> OpenID Request Object (if any).  The Request Object is the general case, and<br>
> the architecture should derive from it.  Anything expressible in the<br>
> shorthand syntax must also be (naturally) expressible in the general form.<br>
><br>
>                                                             -- Mike<br>
><br>
><br>
> From: matake, nov [mailto:<a href="mailto:nov@matake.jp">nov@matake.jp</a>]<br>
> Sent: Thursday, June 07, 2012 2:17 AM<br>
> To: Nat Sakimura<br>
> Cc: Mike Jones; <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
> Subject: Re: [Openid-specs-ab] Please respond: poll on claims_in_id_token<br>
> switch in the scope<br>
><br>
> Forgive me sending more in this ML.<br>
><br>
>> Mike<br>
> I feel id_token which includes userinfo is different kind of token from<br>
> which doesn't include it.<br>
><br>
>> Nat<br>
> I prefer<br>
> 1. b)<br>
> 2. a)<br>
> 3. a)<br>
><br>
> If we define new response_type, what we need is defining new 4 patterns<br>
> listed below.<br>
> From a ruby openid-connect library developer's view, those 4 is not so<br>
> complicated.<br>
><br>
> ===<br>
> # Current defined response types<br>
> code<br>
> token<br>
> id_token<br>
> code id_token<br>
> id_token token<br>
> code id_token token<br>
><br>
> # New response types<br>
> id_token_with_claims<br>
> code id_token_with_claims<br>
> id_token_with_claims token<br>
> code id_token_with_claims token<br>
><br>
> # Not defined<br>
> id_token id_token_with_claims<br>
> code id_token id_token_with_claims<br>
> id_token id_token_with_claims token<br>
>  :<br>
> ===<br>
><br>
> I don't think defining separate "userinfo" response_type introduces more<br>
> patterns (aka flexibility?) listed here.<br>
> At least I don't know any use-case except for ones listed above.<br>
> (ie. "userinfo token", which will require returning userinfo token separated<br>
> from id_token)<br>
><br>
> ps.<br>
> If we have call, I'll join.<br>
> Both early morning and night (after 10pm) in JST works for me.<br>
><br>
> 2012/6/7 Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>><br>
> OK. I seemed to have screwed up the list of options etc.<br>
><br>
> Also, as the list is terse and it did not include the precise definition of<br>
> each terms, it led to people talking about different things using the same<br>
> word. This is another screwing up on my part.<br>
><br>
> Rather than doing it through mailing list poll, it probably is better to<br>
> have a call on this issue in a very near future at a time where European<br>
> participants can also call in, e.g., 11pm JST, 4pm CDT (EU), 10am EDT, 7am<br>
> PDT. That will let people speak up, explain the meaning, etc. and a whole<br>
> lot more constructive. Perhaps we should do a doodle poll on the timing.<br>
><br>
> Nat<br>
><br>
> On Thu, Jun 7, 2012 at 4:42 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>><br>
> wrote:<br>
> This list left out the possibility that John discussed of having separate<br>
> scope request values such as email_id that specifically request that sets of<br>
> scope values be included in the ID Token.  (I'm not necessarily in favor of<br>
> this, but it was discussed at Yahoo and on the list, so should be part of<br>
> what people react to.)<br>
><br>
> This list left out the suggest of Brian's that a different request parameter<br>
> be defined to act as the switch that the profile, email, address, and phone<br>
> scope values return claims in the ID Token, rather than the switch being the<br>
> claims_in_id_token scope.  If we're reconsidering all options, this one<br>
> shouldn't be excluded.<br>
><br>
> I don't think there had been any discussion on the list to date since the<br>
> decisions at Yahoo proposing your option 1b (using a different response<br>
> type).  I've heard people discussing *how* claims should be directed to the<br>
> ID Token - not *whether* they should be.  I hope we don't try to reopen that<br>
> part of the decision as well, especially because no one has proposed<br>
> reopening it.  As such, I don't believe that it's productive to discuss 1b,<br>
> 2, or 3b, given that no one has suggested that they are dissatisfied with<br>
> the option to return claims in the ID token - only the syntax for saying to<br>
> do it.<br>
><br>
> My two cents worth...<br>
><br>
>                                -- Mike<br>
><br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>]<br>

> On Behalf Of Nat Sakimura<br>
> Sent: Wednesday, June 06, 2012 11:57 PM<br>
> To: Roland Hedberg<br>
> Cc: <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
> Subject: [Openid-specs-ab] Please respond: poll on claims_in_id_token switch<br>
> in the scope<br>
><br>
> I would like to take this issue to a closure quickly.<br>
> These issues were discussed at F2F on May 1.<br>
> However, that was only among the f2f participant.<br>
> I understand the current comments are from those who were not at F2F, and<br>
> implementers' comments from those implementing it.<br>
> I would appreciate a quick response to the following questions so to sum up<br>
> a bit to help the progress in this issue:<br>
><br>
> 1. Please indicate which is your preferred way.<br>
><br>
>    a) Using claims_in_id_token switch in the "scope"<br>
>    b) Using a new response type.<br>
><br>
>    Note: on May 1 F2F, 1-a) was chosen. This is how the current draft was<br>
> prepared. (cf. issue #561)<br>
><br>
> 2. If 1-b) is chosen, which do you prefer:<br>
><br>
>    a) A combined response type: e.g., id_token_with_userinfo<br>
>    b) combination of id_token and userinfo<br>
><br>
> 3. As a method for returning userinfo claims in the front channel, which do<br>
> you prefer?<br>
><br>
>     a) Claims in id_token<br>
>     b) separate userinfo token with its metadata in id_token?<br>
><br>
>     Note: At the F2F, a) was chosen.<br>
><br>
> Thanks for your cooperation.<br>
><br>
> Nat Sakimura<br>
><br>
> On 2012/06/07, at 15:29, Roland Hedberg <<a href="mailto:roland.hedberg@adm.umu.se">roland.hedberg@adm.umu.se</a>> wrote:<br>
><br>
>><br>
>> 7 jun 2012 kl. 07:40 skrev nov matake:<br>
>><br>
>>> I'm OK with both making single "id_token_with_userinfo" response type or<br>
>>> combination of "id_token" and "userinfo".<br>
>><br>
>><br>
>> I'm definitely in favor of the later.<br>
>> That is letting 'id_token' contain metadata about the userinfo and the<br>
>> authentication, and 'userinfo' pure user info.<br>
>> Similar to the structure of the openid request object.<br>
>><br>
>> -- Roland<br>
>> ------------------------------------------------------<br>
>> Roland Hedberg<br>
>> IT Architect/Senior Researcher<br>
>> ICT Services and System Development (ITS) Umeå University<br>
>> SE-901 87 Umeå, Sweden<br>
>> Phone <a href="tel:%2B46%2090%20786%2068%2044" value="+46907866844">+46 90 786 68 44</a><br>
>> Mobile <a href="tel:%2B46%2070%20696%2068%2044" value="+46706966844">+46 70 696 68 44</a><br>
>> <a href="http://www.its.umu.se" target="_blank">www.its.umu.se</a><br>
>><br>
>> _______________________________________________<br>
>> Openid-specs-ab mailing list<br>
>> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (=nat)<br>
> Chairman, OpenID Foundation<br>
> <a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
> @_nat_en<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
><br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
<br>