Agreed. <a href="http://openidconnect.com/#associations">http://openidconnect.com/#associations</a><div><br><br><div class="gmail_quote">On Tue, May 25, 2010 at 11:11 AM, Monroe, Grant <span dir="ltr">&lt;<a href="mailto:grant@janrain.com">grant@janrain.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">As long as the technology supports dynamic associations, and<br>
preregistration isn&#39;t the status quo for authentication, I&#39;ll be<br>
happy. I think that these basic facts have allowed OpenID to be even<br>
remotely successful.<br>
<font color="#888888">-- Grant<br>
</font><div><div></div><div class="h5"><br>
On Tue, May 25, 2010 at 10:00 AM, David Recordon &lt;<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>&gt; wrote:<br>
&gt; Grant, I don&#39;t disagree with you. I have however seen this sort of<br>
&gt; whitelisting requirement from both the provider (i.e. AOL initially) and<br>
&gt; consumer (i.e. Federal Government) sides. OpenID 1.0 and 2.0 allowed them to<br>
&gt; do this. As Eran said, it&#39;s really not about the technology but rather<br>
&gt; trust, liability, and policy. I also believe that most large providers will<br>
&gt; support dynamic associations for accessing at least basic information and<br>
&gt; others will not have any form of preregistration at all.<br>
&gt; --David<br>
&gt;<br>
&gt; On Tue, May 25, 2010 at 10:35 AM, Eran Hammer-Lahav &lt;<a href="mailto:eran@hueniverse.com">eran@hueniverse.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; It isn&#39;t much different from white listing providers, or using buttons<br>
&gt;&gt; instead of an input box as is common today. Reality is that until we solve<br>
&gt;&gt; the legal issues around trust and liability, the technical solution doesn&#39;t<br>
&gt;&gt; matter. Standard machine readable TOS is just the first step. Figuring out<br>
&gt;&gt; the issue of liability is a much bigger issue which is key to any meaningful<br>
&gt;&gt; OpenID adoption.<br>
&gt;&gt;<br>
&gt;&gt; I view the OpenID Connect proposal as a to-do list for the OAuth community<br>
&gt;&gt; to fill in the missing pieces. For example, OAuth needs to support endpoint<br>
&gt;&gt; discovery, unregistered clients, basic immediate mode and username support,<br>
&gt;&gt; and request and response signatures with either symmetric or asymmetric<br>
&gt;&gt; secrets. These are all *OAuth* elements that should be standardized by the<br>
&gt;&gt; OAuth community in the IETF.<br>
&gt;&gt;<br>
&gt;&gt; However, putting these components together for a coherent identity<br>
&gt;&gt; framework is what I expect from the OpenID community. It will probably mean<br>
&gt;&gt; that the OpenID WG will need to work closely with the OAuth WG and provide<br>
&gt;&gt; feedback and requirements. But at the end, someone will need to write a spec<br>
&gt;&gt; that puts this all together and that should be the OpenID foundation, even<br>
&gt;&gt; if this spec is not much more than glue.<br>
&gt;&gt;<br>
&gt;&gt; EHL<br>
&gt;&gt;<br>
&gt;&gt; &gt; -----Original Message-----<br>
&gt;&gt; &gt; From: <a href="mailto:openid-specs-bounces@lists.openid.net">openid-specs-bounces@lists.openid.net</a> [mailto:<a href="mailto:openid-specs-">openid-specs-</a><br>
&gt;&gt; &gt; <a href="mailto:bounces@lists.openid.net">bounces@lists.openid.net</a>] On Behalf Of Monroe, Grant<br>
&gt;&gt; &gt; Sent: Tuesday, May 25, 2010 5:36 AM<br>
&gt;&gt; &gt; To: David Recordon<br>
&gt;&gt; &gt; Cc: Joseph Smarr; OpenID Board (public); <a href="mailto:openid-specs@lists.openid.net">openid-specs@lists.openid.net</a><br>
&gt;&gt; &gt; Subject: Re: Why Connect?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt; Eran Hammer-Lahav (with a +1 from Chuck Mortimore):<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; My guess is that an OAuth identity layer will not be a good thing for<br>
&gt;&gt; &gt; &gt;&gt; OpenID adoption. OAuth providers will get it for free.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; You know what&#39;s not good for adoption? Having to go to 20 different<br>
&gt;&gt; &gt; developer portals. Trying to figure out how to create an OAuth<br>
&gt;&gt; &gt; application in<br>
&gt;&gt; &gt; 20 different ways. Verifying your domain in 20 different ways. Agreeing<br>
&gt;&gt; &gt; to 20<br>
&gt;&gt; &gt; different terms of service.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I know that the OpenID Connect proposal mentions an association step,<br>
&gt;&gt; &gt; but<br>
&gt;&gt; &gt; if all the major providers wind up requiring preregistration, it is a<br>
&gt;&gt; &gt; moot point.<br>
&gt;&gt; &gt; My gut is that using OAuth as the base will be very good for a few<br>
&gt;&gt; &gt; players,<br>
&gt;&gt; &gt; and bad for identity on the whole.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Grant Monroe<br>
&gt;&gt; &gt; JanRain, Inc.<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; specs mailing list<br>
&gt;&gt; &gt; <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
&gt;&gt; &gt; <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; specs mailing list<br>
&gt;&gt; <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
&gt;&gt; <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>