<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D">{“id_token”:{<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D"> “claims”:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D"> {“email”: null},<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D"> “email_verified”: null}),<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D">“userinfo”:{<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D"> “claims”:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D"> {“email”: null,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D"> “email_verified”: null }}<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1F497D">}<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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
<i>no new response types are needed to return requested claims in the ID token</i>.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think it would be useful for people to first work out their request examples as OpenID Request Objects and *<b>then</b>* 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> matake, nov [mailto:nov@matake.jp]
<br>
<b>Sent:</b> Thursday, June 07, 2012 2:17 AM<br>
<b>To:</b> Nat Sakimura<br>
<b>Cc:</b> Mike Jones; openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Please respond: poll on claims_in_id_token switch in the scope<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">Forgive me sending more in this ML.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">> Mike<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">I feel id_token which includes userinfo is different kind of token from which doesn't include it.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">> Nat<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">I prefer<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">1. b)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">2. a)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">3. a)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span class="apple-style-span"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">If we define new response_type, what we need is defining new 4 patterns listed below.</span></span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">From a ruby openid-connect library developer's view, those 4 is not so complicated.<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">===<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""># Current defined response types<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">code<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">token<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">id_token<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">code id_token<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">id_token token<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">code id_token token<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""># New response types<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">id_token_with_claims<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">code id_token_with_claims<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">id_token_with_claims token<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">code id_token_with_claims token<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""># Not defined<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">id_token id_token_with_claims<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">code id_token id_token_with_claims<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">id_token id_token_with_claims token<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""> :<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">===<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">I don't think defining separate "userinfo" response_type introduces more patterns (aka flexibility?) listed here.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">At least I don't know any use-case except for ones listed above.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">(ie. "userinfo token", which will require returning userinfo token separated from id_token)<o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">ps.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">If we have call, I'll join.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">Both early morning and night (after 10pm) in JST works for me.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2012/6/7 Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>><o:p></o:p></p>
<p class="MsoNormal">OK. I seemed to have screwed up the list of options etc. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">Nat<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Jun 7, 2012 at 4:42 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
My two cents worth...<br>
<span style="color:#888888"><br>
-- Mike</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
-----Original Message-----<br>
From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>] 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" target="_blank">openid-specs-ab@lists.openid.net</a><br>
Subject: [Openid-specs-ab] Please respond: poll on claims_in_id_token switch 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 implementers' comments from those implementing it.<br>
I would appreciate a quick response to the following questions so to sum up 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 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 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" target="_blank">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 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 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" target="_blank">+46 90 786 68 44</a><br>
> Mobile <a href="tel:%2B46%2070%20696%2068%2044" target="_blank">+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" target="_blank">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" target="_blank">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>
<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>