[OpenID] OpenID 2.1 clarification on use of LocalID

John Bradley john.bradley at wingaa.com
Sat Apr 11 03:14:19 UTC 2009


Good point.

Delegation via XRDS is equally broken.

The work we are doing with discovery in XRD will help with that, if it  
is adopted in openID 2.1.

In XRD the user will specify that they have a relation to a OP.  It is  
the OP that specifies the endpoints for the services it is providing  
the user.

We did have a cleaner way of dealing with delegating services in XRI  
but that was not adopted by XRDS Simple.

Now we have a unified approach that allows users to specify  
relationships with providers and the providers to describe the  
endpoints for the protocols.

This will be the same for all URI including URL and XRI identifiers.

So in XRD 1.0 you get your wish Eran has been doing a good job getting  
us all in line:)

John Bradley

On 10-Apr-09, at 8:01 PM, Allen Tom wrote:

> 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 break.
> 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.
> Allen
> 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 discovered.
>> 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

More information about the general mailing list