[OpenID] Claimed Identifiers and Query String Parameters

SitG Admin sysadmin at shadowsinthegarden.com
Wed Sep 3 22:34:44 UTC 2008


>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 "<http://yahoo.com>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 "<http://yahoo.com>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://lists.openid.net/pipermail/openid-general/attachments/20080903/017797dd/attachment-0002.htm>


More information about the general mailing list