<div>No where in the OpenID 1.x or 2.0 spec (that I can find) is the user's LocalID (openid.identity) mandated to be a URI. Yes, it's a "local identifier", but the OP might choose to let that be simply the local username like "andrew". In this case, the OP hosted identity page might include something like this:</div>
<div><br></div><link rel="openid2.provider" href="<a href="http://provider/opendpoint">http://provider/opendpoint</a>"><div><link rel="openid2.local_id" href="andrew"></div>
<div><br></div><div>So this <i>looks</i> like delegation because a local_id is given, but in this case it's not. It just causes the RP to customize the openid.identity parameter to be 'andrew', 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've seen many libraries assume that local_id is a URI and treat it as such. I've even heard ideas of performing discovery on the local_id. Now, there'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't even know if any OP out there uses non-URIs for local_id's. But since it'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>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
</div>