<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=us-ascii">
<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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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’ve thought about this today and while my reaction may surprise you, I feel pretty strongly about it. I think that we *<b>should not</b>* jump right into
defining new Connect extensions because it would send the wrong message to the marketplace. It would be easy for us to stall adoption by having people think “Connect is fine but I’ll wait until extension X is done before deploying”. Rather, we should be
clearly communicating that “OpenID Connect is done – build it, deploy it, and it will solve problems for you now.”<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">If we want to move on to new work, I’d suggest that many of us focus our energies on *<b>finishing</b>* something else important that we’ve already started
– Account Chooser. In particular, while there is a site and a JavaScript file, there isn’t a standard. That needs to happen. Let’s do that before any Connect extensions.<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">We need to establish a reputation for finishing what we start. That’s far more important than starting more things.<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""> openid-specs-ab-bounces@lists.openid.net [mailto:openid-specs-ab-bounces@lists.openid.net]
<b>On Behalf Of </b>Nat Sakimura<br>
<b>Sent:</b> Friday, May 10, 2013 2:59 AM<br>
<b>To:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> [Openid-specs-ab] Next steps: Extension ideas<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Now that the core connect is largely done, we may want to start discussing a little bit about what we may want to do as the next steps. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I have three things in my mind. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. granular purpose statement per claims<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. privacy level certified request object <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3. link/rel metadata for the responses<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. granular purpose statement per claims<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">As of now, OpenID Connect has a facility to indicate the purpose of the use for the entire request object. It should cover 80% of the cases, but sometimes, some of the individual attribute request is not obvious why that is needed. It will
be beneficial to be able to show the user how the individual claims are being used. It was discussed in the METI report that was published today. (See <a href="http://nat.sakimura.org/2013/05/10/info-label-win/">http://nat.sakimura.org/2013/05/10/info-label-win/</a> for
more details). It is possible that it becomes a part of new guideline in Japan. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The implementation of it is simple. We just need to define the per claim usage. It could go into individual claims as the "purpose" member. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2. privacy level certified request object<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The idea is simple. The privacy commissioner or privacy trust framework assessor signs the request object after determining that it is following the privacy principles such as data minimization. Then, we may be able to skip the consent
dialogue. (Sending the notification should be coupled with it.) <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3. link/rel metadata for the responses<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Basically, something like <a href="http://tools.ietf.org/html/draft-sakimura-oauth-meta-02">http://tools.ietf.org/html/draft-sakimura-oauth-meta-02</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Any additional ideas welcome. <o:p></o:p></p>
</div>
<div>
<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>
</div>
</div>
</div>
</body>
</html>