[OpenID] Claimed Identifiers and Query String Parameters

[Andrew Arnott]

Ah.  I think I understand where you're coming from a bit better now.
FYI, many non-anonymous Providers support directed identity -- I daresay any
2.0 OP either does or wants to support it for its convenience to users
whether or not the claimed id becomes "anonymous".  For example, I can type
in "myopenid.com" to a RP 2.0 site and end up having logged in as "
https://andrewarnott.myopenid.com".  In fact I never type in my claimed id
any more.

Directed Identity can scale all the way from obvious-identity (like
myopenid.com returning andrewarnott.myopenid.com) to yahoo.com's
totally-crazy-looking-identity, to completely
one-time-use-no-good-for-returning-to-this-RP claimedId, and an RP has no
way of knowing which it is based on the OpenID protocol alone.
 Whitelist/blacklist of OPs is the only way to filter out OPs that make
generating claimed ids too easy.

FWIW, in my opinion yahoo.com isn't any more 'anonymous' than
myopenid.com Yahoo's claimed ids
look scarier, but user account names with myopenid.com could be just as
meaningless.  Although mine is andrewarnott, it could have been
noGuy1.myopenid.com, which wouldn't help you any more than
https://me.yahoo.com/a/cJASAdp4x5Rx6CU9olKi7rMkG1TX_7Yl1kQ- to figure out
who this guy is or whether he's just trying to take advantage of your RP.
 In fact Yahoo can issue ordinary-looking claimed IDs.  It just recommends
to its users when they first set up their OpenID account that the users opt
out of that option.

What you're attempting in heuristically finding anonymous claimed ids is
definitely interesting and in OpenID 1.x probably would have worked really
well.  I can't right now think of how to carry it over into 2.0 meaningfully
though. :(

On Wed, Sep 3, 2008 at 3:34 PM, SitG Admin
<sysadmin at shadowsinthegarden.com>wrote:

>  >No, heavens no!  To consider the user-supplied identifier their identity
> opens up huge security holes.
>
> Yet that was my expectation, after looking at version 1.
>
> >And as in the case of directed identity,
>
> Yes, that was one of the terms! Thanks!
>
> >the user who types in "yahoo.com" has not revealed anything about their
> "real identity" to the RP before the OP asserts some "anonymous" URL to the
> RP.
>
> Exactly the problem, if I want to discourage "anonymous" URI's; and I can
> track this sort of thing by looking for multiple entries in the database
> that all share the same typed-in URI, enabling me to identify URL's that are
> being used for Directed Identity, and mark them to be filtered before
> getting to the Consumer process. This lets me explain things to the user
> *before* making them go through their authentication with Yahoo! or whoever
> (and whoever may be using one-time passwords, which would *really* annoy the
> user).
>
> >You certainly don't want to consider "yahoo.com" as the user's "real"
> identity URL in this case or else all Yahoo users will share one account on
> your RP.
>
> If that were the *only* URL that I was using, yes ;)
>
> >You really must use the OP's "use this instead" URL.  You'll never get the
> fragment if you ignore the OP's assertion,
>
> I assure you that I'm not ignoring it. I'm just using a standard that suits
> my inadequate understanding by adding sanity checks and erring in favor of
> not recognizing the same user when they switch OP's. I figured this approach
> would give me time to improve my understanding, and I wouldn't need to worry
> about things until I found more than one entry with the same "use this
> instead" URL and 2 radically different "typed-in" URL's.
>
> As described in my first reply to Joe Tele, the idea is to look for (a hash
> of) the typed-in ("claimed") ID *and* the Directed ("final") ID, requiring a
> match on *both* of those strings to proceed. I designed mine this way
> because I didn't understand what was going on with Directed Identity well
> enough to be *certain* there weren't any risks in relying on just the
> Directed identifier.
>
> -Shade
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openid.net/pipermail/general/attachments/20080903/71ac4526/attachment.htm