[OpenID] OpenID 2.1 clarification on use of LocalID
Breno de Medeiros
breno at google.com
Thu Apr 9 23:46:03 UTC 2009
My vote that the 2.1 spec includes three example flows, one
traditional, one directed identity through delegation, and one
directed identity through OP identifier. My experience is that when
Yahoo & Google launched directed-identity flows most libraries had
On Thu, Apr 9, 2009 at 4:40 PM, Peter Williams <pwilliams at rapattoni.com> wrote:
>> -----Original Message-----
>> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
>> Behalf Of John Bradley
>> Sent: Thursday, April 09, 2009 11:51 AM
>> To: Andrew Arnott
>> Cc: openid General
>> Subject: Re: [OpenID] OpenID 2.1 clarification on use of LocalID
>> Yes that has come up in the XRD 1.0 work.
>> The <LocalID> is a string and can be a XRI, URI, e-mail or any other
>> thing that the OP uses to identify the user.
>> In most cases that is a URL or a XRI but it could be anything.
>> Delegation is a term that carried over from openID 1.0 and probably is
>> not accurate any more.
>> The provider you are asserting is your provider.
>> If for some reason you provider knows you by some identifier other
>> than the claimed_id then you can use the local_id to send an arbitrary
>> string in the openid.identity.
>> The only identifier that the RP should discover is the claimed_id. If
>> in the returned assertion by the OP the claimed_id and the
>> openid.identity are not equal (less hash) the openid.identiy must be
>> the <LocalID> in the discovered information.
> If the values are not equal, the RP must perform discovery on the value supplied. This requirement provides the openid 1.1 delegation semantics, expressed now through localid (whose value is supplied from the initial XRD discovery).
> We went through this ad nauseum during the review of openid2.0. It works fine for delegation through directed identity mode, too.
>> RP's not properly verifying that is an issue where someone delegates
>> to a OP doing "Identifier Select". (By issue I mean gaping security
>> That is a RP problem that can only occur when the User delegates there
>> Someone delegating a URI to a iName would be entering a XRI like
>> =jbradley as the <LocalID>.
>> It is also possible that someone delegating might not include the
>> scheme ie ve7jtb.pip.verisignlabs.com as the <LocalID> that should
>> John Bradley
>> On 9-Apr-09, at 11:27 AM, 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
>> general mailing list
>> general at openid.net
> general mailing list
> general at openid.net
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
More information about the general