[OpenID] OpenID 2.1 clarification on use of LocalID
atom at yahoo-inc.com
Sat Apr 11 03:01:40 UTC 2009
On a related note, I think that HTML delegation in OpenID 2.0 is broken
because it doesn't use discovery to discover the OP's endpoint. If the
OP ever changes its endpoint, all sites delegating to it using HTML will
Ideally, you could delegate to an OpenID by just specifying the OpenID
that you're delegating to, without knowing anything about the OP's
endpoint, or the local_id.
Andrew Arnott wrote:
> 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:
> <link rel="openid2.provider" href="http://provider/opendpoint">
> <link rel="openid2.local_id" href="andrew">
> So this /looks/ 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.
> 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
> 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.
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the
> death your right to say it." - Voltaire
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the general