[OpenID] OpenID 2.1 clarification on use of LocalID

Fri Apr 10 00:57:44 UTC 2009

From: John Bradley [mailto:john.bradley at wingaa.com]
Sent: Thursday, April 09, 2009 5:41 PM
To: Peter Williams
Cc: Andrew Arnott; openid General
Subject: Re: [OpenID] OpenID 2.1 clarification on use of LocalID

It works fine if the RP performs the discovery on the returned claimed_id and makes certain that if the openid.identity  is not == openid.clamed_id it is in the discovered information as the <LocalID>

The user supplied value is only used for the first discovery.   The second discovery if there is one uses the returned.clamed_id.
If the calimed_id doesn't change then you don't need a second discovery because you already have the discovery info.

So logically if the claimed_id that is returned by the OP is the same one that is sent, (as it would be for delegation) if ANY of the other three parameters are changed in the  assertion from the OP, that assertion must be rejected.

I have found RPs that were only checking for the openid.claimed_id changing.

yes. That is consistent with the rule that defined the requirement, discussed during the review - as I recall. Request assertion about a claim. Receive an assertion about a different claim. Thus,  discover actual claim asserted and establish user ownership, to ensure owner authorizes said claim to be evidence supporting the actual openid that the RP will know the user by - as retrieved from the user supplied id and its supporting (unsigned) XRD.

This allowed me to get a OP to assert a claimed_id for a delegated ID while logging in with any valid ID at the OP.

Checking the values in the returned assertion against the discovery information is critical.

[Peter Williams] But until now, only when the OP returns claim != requested claim. There were no other conditions, originally.

FYI Google and Yahoo are treating the combination of delegation and directed identity differently.

[Peter Williams] I always thought it was cute that an RP could get the user's vantity XRD , be given thereby a localid1 and be directed to use directed mode,  have request claim = OP Identifier, receive claim via assertion where specific claim value != requested value (OP Identifier), and thus be required to perform discovery on the specific claim value from assertion, which would induce RP to consult the (non vanity) XRD at the OP - which supports the ownerhip of specific claim (may establish a second localid(2) relevant to the OP.)

Now my assumption is that the openid bound to an  RP's account in the above case is localid1, not localid2.

If the form of localid1 is an XRI, http/https or HXRI form openid, one has (with directed id based resolution of evidence of id control) achieved delegation and portability, VERY much as it was in openid 1.x.

The key thing is the obligation of the OP to do RP discovery (to ensure the realm is authorized), and the RP to do claim discovery according to the "changed" rules.

[Peter Williams] If any of the above is not sensible , don't study it too hard. I'm recalling it from my mental model formed several months ago, when I last thought I understood the security andcontrol model underlying openid auth v2.

John Bradley

On 9-Apr-09, at 4:40 PM, Peter Williams wrote:

-----Original Message-----
From: general-bounces at openid.net<mailto: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.

Nah.

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
hole)

That is a RP problem that can only occur when the User delegates there
identity.

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
work.

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<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090409/7aae7c3f/attachment.htm>