<div>No where in the OpenID 1.x or 2.0 spec (that I can find) is the user&#39;s LocalID (openid.identity) mandated to be a URI.  Yes, it&#39;s a &quot;local identifier&quot;, but the OP might choose to let that be simply the local username like &quot;andrew&quot;.  In this case, the OP hosted identity page might include something like this:</div>
<div><br></div>&lt;link rel=&quot;openid2.provider&quot; href=&quot;<a href="http://provider/opendpoint">http://provider/opendpoint</a>&quot;&gt;<div>&lt;link rel=&quot;openid2.local_id&quot; href=&quot;andrew&quot;&gt;</div>
<div><br></div><div>So this <i>looks</i> like delegation because a local_id is given, but in this case it&#39;s not.  It just causes the RP to customize the openid.identity parameter to be &#39;andrew&#39;, which the OP will use to look up the username that should control the claimed_id.</div>
<div><br></div><div>The reason I bring this up is because I&#39;ve seen many libraries assume that local_id is a URI and treat it as such.  I&#39;ve even heard ideas of performing discovery on the local_id.  Now, there&#39;s no reason to perform discovery on the local_id... only the claimed_id needs to be discovered.  </div>
<div><br></div><div>I don&#39;t even know if any OP out there uses non-URIs for local_id&#39;s.  But since it&#39;s not a contradiction in the OpenID 1.1 or 2.0 specs, I think that the 2.1 spec should call out EITHER that it MUST be a URI (and indicate whether discovery is required to succeed) OR that it CAN be any string at all that the OP is expecting.</div>
<div><br clear="all">--<br>Andrew Arnott<br>&quot;I [may] not agree with what you have to say, but I&#39;ll defend to the death your right to say it.&quot; - Voltaire<br>
</div>