<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:18px">I am not seeing a wave of adoption at anything like the scale the Internet needs.</span><div><span style="font-family:arial,sans-serif;font-size:18px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:18px">I gather that you are talking about the wave of adoption of OpenID Connect. </span></div><div style><span style="font-family:arial,sans-serif;font-size:18px">One of the thing that Eric has been pointing out was that for authentication, just being able to cope with HTTP is not enough since password remains in other protocols like IMAP and so on. In this respect, I think the bindings of OpenID Connect for other protocols are quite important. </span></div>
<div style><font face="arial, sans-serif">Not doing it does not help the adoption of OpenID Connect. </font></div><div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Also, it is important to note that even if we do not do it here, it will happen somewhere else </font><span style="font-family:arial,sans-serif">as long as there is a demand. It will be </span><span style="font-family:arial,sans-serif">resulting in fragmented / ad hoc implementations. This is not desirable. </span></div>
<div style><span style="font-family:arial,sans-serif"><br></span></div><div style><span style="font-family:arial,sans-serif">FYI, the AB/Connect work actually is rooted in Contract Exchange (CX) Working group, which gathered requirements from bunch of companies. It is essentially a contract / payment protocol. In the due course, the CX WG figured out that factoring out a portion of it would have a more general applicability, and started Artifact Binding working group, which is this working group. CX WG actually is waiting the current AB/C work to be complete so that they can start off from there. </span></div>
<div style><span style="font-family:arial,sans-serif"><br></span></div><div style><span style="font-family:arial,sans-serif">When we analyse the cause of slow adoption etc., we should not base it on the conjecture but on the fact / figures. </span></div>
<div style><span style="font-family:arial,sans-serif">If we do not have a we should deduce from the adjacent cases. </span></div><div style><span style="font-family:arial,sans-serif">In our case, it is OAuth. OAuth is still building other profiles and extensions, but it is not slowing the adoption. So, as I said before, the argument that extensions will slow the adoption has little ground. </span></div>
<div style><span style="font-family:arial,sans-serif">We would have to find other causes. </span></div><div style><span style="font-family:arial,sans-serif"><br></span></div><div style><span style="font-family:arial,sans-serif">Possible causes are: </span></div>
<div style><span style="font-family:arial,sans-serif"><br></span></div><div style><span style="font-family:arial,sans-serif">1. Low awareness figure: We could do some survey on the awareness of OpenID Connect. </span></div>
<div style><span style="font-family:arial,sans-serif"> Outside of the identity community, it probably is virtually unknown. </span></div><div style><span style="font-family:arial,sans-serif"> Then, how could applications adopt it? We have to go to their community and tell about it. </span></div>
<div style><font face="arial, sans-serif">2. Bad developer documentation: Spec is needed for the real interchangeability, but the developers </font></div><div style><span style="font-family:arial,sans-serif"> would not read it. There has to be an easy to read introductory document with sample codes. </span></div>
<div style><span style="font-family:arial,sans-serif"> We do not have it now. </span></div><div style><font face="arial, sans-serif">3. Chicken and Egg problem: if there is not enough RP that supports it, OP would not support it, </font></div>
<div style><font face="arial, sans-serif"> and if there is not enough users covered by OpenID Connect, there is no reason for RPs to adopt. </font></div><div style><font face="arial, sans-serif"> We need a strategic expansion plan in this front. We do not have it either. </font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">These are the things that needs to be addressed in terms of adoption. Stopping the development of the extensions and bindings does not help. </font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Nat</font></div><div style><span style="font-family:arial,sans-serif"><br></span></div><div style><span style="font-family:arial,sans-serif"><br>
</span></div><div style><span style="font-family:arial,sans-serif"><br></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/13 Tim Bray <span dir="ltr"><<a href="mailto:tbray@textuality.com" target="_blank">tbray@textuality.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I think Mike's argument from marketing reasons is pretty strong. I am not seeing a wave of adoption at anything like the scale the Internet needs.</p>
<p dir="ltr">There's also an argument from humility. It is obvious to me that we need an interoperable basic authentication protocol. Once we start getting deployment on that, we'll be in a position to learn from observation what the next most important unmet need is; my confidence that we actually know know, right now, what's most important, is not high.</p>
<p dir="ltr">-T</p>
<div class="gmail_quote"><div><div class="h5">On May 10, 2013 10:44 PM, "Mike Jones" <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> wrote:<br type="attribution">
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<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.”<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> -- Mike<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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""> <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>]
<b>On Behalf Of </b>Nat Sakimura<br>
<b>Sent:</b> Friday, May 10, 2013 2:59 AM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> [Openid-specs-ab] Next steps: Extension ideas<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></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. <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I have three things in my mind. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1. granular purpose statement per claims<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2. privacy level certified request object <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">3. link/rel metadata for the responses<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1. granular purpose statement per claims<u></u><u></u></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/" target="_blank">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. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></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. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">2. privacy level certified request object<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></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.) <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">3. link/rel metadata for the responses<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Basically, something like <a href="http://tools.ietf.org/html/draft-sakimura-oauth-meta-02" target="_blank">http://tools.ietf.org/html/draft-sakimura-oauth-meta-02</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Any additional ideas welcome. <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<u></u><u></u></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<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<br></div></div>_______________________________________________<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></blockquote></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>
</div>