<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: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.hoenzb
        {mso-style-name:hoenzb;}
span.EmailStyle18
        {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">If there’s not another token, it doesn’t make logical sense to have another response type.  Each response type should correspond to a token being requested,
 if they’re going to make much sense to developers.<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"><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""> Nat Sakimura [mailto:sakimura@gmail.com]
<br>
<b>Sent:</b> Thursday, June 07, 2012 1:03 AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> Ryo Ito; 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>
<p class="MsoNormal">Ryo is not suggesting to create another token, I think. He is suggesting to get those claims into id_token. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Is that correct, Ryo? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Nat<o:p></o:p></p>
<div>
<p class="MsoNormal">On Thu, Jun 7, 2012 at 4:55 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">Using a new response type would make the specification and implementations more complicated - not simpler.  That's why the working group decided to add the claims to the ID Token - not create yet another token.  We're already getting serious
 push-back on having a second one.  Adding a third one would cause many people to write us off as building something WAY too complex - at least as I see it.  Reread
<a href="http://hg.openid.net/connect/issue/521" target="_blank">http://hg.openid.net/connect/issue/521</a> for one such comment we've already received that I transcribed.<br>
<br>
It's a simplification to allow all claims to be returned in one token.  Suggesting three, while "logical", in practice, is probably more complexity than implementers will be willing to put up with!  I feel very strongly about this.<br>
<br>
Complexity is the enemy of adoption.<br>
<span style="color:#888888"><br>
<span class="hoenzb">                               -- Mike</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><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>] On Behalf Of Ryo Ito<br>
Sent: Thursday, June 07, 2012 12:41 AM<br>
To: <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 switch in the scope<br>
<br>
1. b)<br>
<br>
2. b)<br>
<br>
3. a)<br>
<br>
I think that response_type params allows the flexible definition.<br>
"id_token userinfo" means that id_token includes user claims.<br>
If more detailed claims control is necessary, RP uses Request Object.<br>
<br>
Ryo.<br>
<br>
2012/6/7 Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>>:<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,<br>
> and implementers' comments from those implementing it.<br>
> I would appreciate a quick response to the following questions so to<br>
> 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<br>
> 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,<br>
> 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">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">+46 90 786 68 44</a><br>
>> Mobile <a href="tel:%2B46%2070%20696%2068%2044">+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>
Ryo Ito<br>
Email : <a href="mailto:ritou.06@gmail.com">ritou.06@gmail.com</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>
<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>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</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>
</body>
</html>