[OpenID] Claimed Identifiers and Query String Parameters

[Drummond Reed]

+1 to RPs using the normalized Claimed Identifier returned by the OP as
their persistent key. As SitG says, this is the only way to realistically
deal with the OpenID recycling problem - for the Claimed Identifier to have
a fragment if it's a URL or for it to be an i-number if its an XRI.

 

=Drummond 

 

  _____  

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Andrew Arnott
Sent: Wednesday, September 03, 2008 8:53 AM
To: SitG Admin
Cc: general at openid.net
Subject: Re: [OpenID] Claimed Identifiers and Query String Parameters

 

SitG said: make a hash of each claimed ID *and* final ID (since Yahoo will
declare a different actual ID) for lookup.

SitG, I'm concerned about your terminology here.  The Claimed Identifier is
the canonical identifier, and the only ID that Yahoo! or any other OP
asserts/declares.  I don't know what this final ID is that you're talking
about, or what this "different actual ID" is either.  But there are a few
IDs defined in the OpenID spec:

*	User-supplied identifier: the actual string entered by the user,
which may just be "yahoo.com"
*	Normalized identifier (7.2): applying some set rules to the
user-supplied identifier, including adding scheme and following redirects,
this may be: "http://www.yahoo.com"
*	Claimed Identifier: This is typically the normalized identifier if
it is a URI.  But the OP may add a #fragment to it in the assertion in which
case that is the Claimed Identifier.  And in the case of an XRI, the
i-number is the claimedId.

 

On Wed, Sep 3, 2008 at 8:28 AM, SitG Admin <sysadmin at shadowsinthegarden.com>
wrote:

>We are using the claimed identifier as a key in our database to
>identify credentials for a user.

Ouch. This will make things confusing (and potentially a security
risk) in the case of, for example, https://me.yahoo.com/ - I've been
worrying over the same problem recently, and recommend borrowing an
idea from MemCache: make a hash of each claimed ID *and* final ID
(since Yahoo will declare a different actual ID) for lookup. This
won't matter for collisions because you're just using the hash to
save time that would otherwise be spent searching all those long text
fields; if you get 5 results, you just check 5 entries^1 (with two
fields apiece) for the full text. You can put a check in regular
maintenance for lots of users with the same claimed ID but different
final ID to detect users who are doing that kind of system.

^1) If you get five HUNDRED results, it might be time to use a longer hash
:)


>However, it seems that some sites have virtually infinite number of
>claimed identifiers for the same OP Local Id.

I remember this headache. OpenID follows the URL standard, so the
user can vary capitalization when they type in their URI, and since
this *may* be a different page on the server hosting their Identity,
it's important to preserve case-sensitivity in keeping track of their
identifier!

I'm experimentally using this method for a sanity check: lower-case
the claimed ID, lower-case the final ID, look for the claimed ID *in*
the final ID, and if there's no match, worry. (The exact definition
of "worry" is, in my case, is to complain and then promptly die -
you'd probably want yours to be more sophisticated.)

There was a thread last month (from the 3rd to the 5th) about "URI
normalization and capitalization", I recommend that you look in the
list archives and read that too.

-Shade

_______________________________________________
general mailing list
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/20080903/a8cc66c6/attachment-0002.htm>