So I whipped up a delegated claimed identifier for Google.&nbsp; And guess what?! Google&#39;s OP is buggy.<br><br>This is my delegated OpenID page that delegates to Google&#39;s OP:<br><a href="http://nerdbank.org/RP/rpgoogle.html">http://nerdbank.org/RP/rpgoogle.html</a><br>
<br>It&#39;s magic contents are:<br>&lt;link rel=&quot;openid2.provider&quot; href=&quot;<a href="https://www.google.com/accounts/o8/ud">https://www.google.com/accounts/o8/ud</a>&quot;/&gt;<br>&lt;link rel=&quot;openid2.local_id&quot; href=&quot;<a href="https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU">https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU</a>&quot;/&gt;<br>
<br>This works just like any other delegated thing.&nbsp; Since Google provides pair-wise unique identifiers, I had to first log in to <a href="http://nerdbank.org/RP">nerdbank.org/RP</a> using google directly, find out what identifier Google assigned for me at that RP, and then stick that into the above local_id field.&nbsp; Then this delegated page will <i>only</i> work against that RP.<br>
<br>Or at least that&#39;s what should happen.&nbsp; In actuality Google changes the claimed_id though it shouldn&#39;t.&nbsp; This is what it asserts:<br><br>ClaimedIdentifier: <a href="https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU">https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU</a><br>
ProviderLocalIdentifier: <a href="https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU">https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU</a><br>ProviderEndpoint: <a href="https://www.google.com/accounts/o8/ud">https://www.google.com/accounts/o8/ud</a><br>
OpenID version: 2.0<br><br>And this is what was discovered at the delegated identity page:<br><br>ClaimedIdentifier: <a href="http://nerdbank.org/RP/rpgoogle.html">http://nerdbank.org/RP/rpgoogle.html</a><br>ProviderLocalIdentifier: <a href="https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU">https://www.google.com/accounts/o8/id?id=AItOawkBReSGLLy2neuRSMQEz7G8mWH311s8_FU</a><br>
ProviderEndpoint: <a href="https://www.google.com/accounts/o8/ud">https://www.google.com/accounts/o8/ud</a><br>OpenID version: 2.0<br><br>The ClaimedIdentifier has been tampered with.&nbsp; This Google&#39;s OP should note that the auth request was with its local_id but a 3rd party claimed_id and preserve the claimed_id so that delegation works.&nbsp; They don&#39;t, and delegation breaks.<br>
<br>So you see, it&#39;s not that they use directed identity that breaks delegation.&nbsp; It&#39;s that their OP doesn&#39;t preserve the openid.claimed_id parameter.&nbsp; I&#39;m not sure if this is a strict contradiction to the spec, but it breaks scenarios, which stinks.&nbsp; <br>
<br>I&#39;ll send this over to the Google folks and see what they have to say.<br><br><div class="gmail_quote">On Fri, Nov 7, 2008 at 7:17 PM, Andrew Arnott <span dir="ltr">&lt;<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><p>From the spec:<br></p><p>
                  Value: (optional) The Claimed Identifier.
                
</p>
<p>
                  &quot;openid.claimed_id&quot; and &quot;openid.identity&quot; SHALL
                  be either both present or both absent. If neither
                  value is present, the assertion is not about an
                  identifier, and will contain other information in
                  its payload, using
                  <a>extensions<span> (</span><span>Extensions</span><span>)</span></a>.
                
</p>So you can&#39;t include one without the other.&nbsp; And having neither doesn&#39;t provide any authentication at all.&nbsp; Delegation <i>should</i> work, if you had an openid identity page with a openid2.local_id tag that was exactly the opaque RP-specific identifier that Google would assign the RP that you are trying to log into.&nbsp; That would mean you&#39;d need a separate delegate page for every single RP you log into... but it&#39;s theoretically possible.&nbsp; It would just be a maintenance nightmare. It would be interesting to test just to see if Google actually implemented the spec correctly to handle <i>non</i>-directed identity scenarios.<div>
<div></div><div class="Wj3C7c"><br>
<br><div class="gmail_quote">On Fri, Nov 7, 2008 at 5:40 PM, Breno de Medeiros <span dir="ltr">&lt;<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>On Fri, Nov 7, 2008 at 4:48 PM, Allen Tom &lt;<a href="mailto:atom@yahoo-inc.com" target="_blank">atom@yahoo-inc.com</a>&gt; wrote:<br>
&gt; Deron Meranda wrote:<br>
&gt;&gt; Of course, from an OP usability perspective, it&#39;s not exactly straight<br>
&gt;&gt; forward for somebody to determine their actual Yahoo identity(-ies),<br>
&gt;&gt; although it is possible.<br>
&gt;&gt;<br>
&gt; We definitely can improve the usability, but you can list your Yahoo<br>
&gt; OpenID identifiers by going to <a href="http://openid.yahoo.com" target="_blank">http://openid.yahoo.com</a> and clicking on<br>
&gt; the &quot;OpenID Home link&quot; at the top of the page.<br>
&gt;<br>
&gt;&gt; And, just from curiosity, why are the randomly generated URIs<br>
&gt;&gt; (both Google and Yahoo!) so long?<br>
&gt; :)<br>
&gt;<br>
&gt;&gt; So, the current Google situation makes it almost impossible to use delegation!<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; Hmm, it does appear that it&#39;s impossible for someone to delegate their<br>
&gt; OpenID to Google.<br>
<br>
</div>The OpenID spec says that the op_local is an optional field. I think<br>
in practice libraries set identity=claimed_id in this case. I assume<br>
it is then unspecified how the OP validates that the user is<br>
authorized over that URL. That changes nothing from the RP<br>
perspective, because it always has to depend on the OP to make that<br>
judgment.<br>
<br>
Bottom line: The fact that the op_local technique is not available for<br>
usage with the Google OP does not mean that it cannot support<br>
delegation.<br>
<div><br>
&gt;<br>
&gt; Allen<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; general mailing list<br>
&gt; <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
&gt; <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
&gt;<br>
<br>
<br>
<br>
</div><div>--<br>
--Breno<br>
<br>
+1 (650) 214-1007 desk<br>
+1 (408) 212-0135 (Grand Central)<br>
MTV-41-3 : 383-A<br>
PST (GMT-8) / PDT(GMT-7)<br>
_______________________________________________<br>
</div><div><div></div><div>general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>