[OpenID] Claimed Identifiers and Query String Parameters

[Andrew Arnott]

Inline...

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

> I don't undersand your distinction between claimed Id and final ID. In the
>> case of https://me.yahoo.com/ my understanding is that URL is not the
>> claimed id.  The claimed id will be returned in the positive assertion.
>>
>
> My understanding of what Yahoo! has done is limited, but the basic
> objection my mind gave to the logic was when, in transition from v1 to v2,
> we started losing track of what the user originally entered. I use (and
> insist on) cookies to keep track of the user so this can be remembered,
> because it just seems wrong to me that the user can type in a value that is
> critical to identifying them, and then we forget what that was by the time
> we have the new value that we're now being told is their *real* identity.

There are multiple methods besides cookies one can use to remember the
user-supplied identifier. And there is value in doing so, but only for user
convenience in recognizing what they originally typed in.  For example, if I
type in "=arnott" to an RP, it's nice to see "you're logged in as =arnott"
on the page instead of "you're logged in as =!30ds!30df!30df!30df".  The
claimed identifier will never give you =arnott back, so it's nice to
remember the user-supplied identifier.
I personally store the user-supplied identifier in the return_to URL as a
query parameter.  Security of it possibly being changed doesn't matter
because the user typed it in in the first place, and because changing it
would only change the appearance on the web page anyway...

>
>
> My understanding now seems incorrect in light of what Martin Atkins said:
>
>  The specification distinguishes between an OpenID Identifier and an "OP
>> Identifier"; http://me.yahoo.com/ is the latter. As the spec describes,
>> when the user enters an OP identifier the user's identifier temporarily
>> becomes a magic value given in the spec and is later set to be the
>> identifier provided by the OP in the positive assertion.
>>
>
> The trick here is this - how do we ascertain when the user has entered a
> string into the single field we provide them with, that they have just
> entered an "OP Identifier" instead of their OpenID Identifier?

That's what OpenID 2.0 spec goes in depth on.  The answer is in there. OPs
that support this feature are required to publish an XRDS doc that publish a
service type URI that will tell the RP that it's an OP Identifier instead of
a user identity.

>
>
> My expectation is that the value entered will BE their OpenID Identifier
> (or URI), and I can keep track of them this way even if their OP later (in
> the process) says "Actually, use *this* instead." (an anonymity trick, but
> one that shouldn't work since the user only gets to that point after
> explicitly admitting its original URI to our RP!)

No, heavens no!  To consider the user-supplied identifier their identity
opens up huge security holes.  You cannot consider anything the user types
in as their user-supplied identifier to be security safe or legally binding.
 And as in the case of directed identity, 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.  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.
You really must use the OP's "use this instead" URL.  You'll never get the
fragment if you ignore the OP's assertion, and your users will be vulnerable
to URL recycling attacks and many many other issues.

Please, read the 2.0 spec and study the areas that discuss the security
ramifications and re-discovery requirements that RPs must fulfill. It may
save you and your users a lot of headache and potential bad press.

>
>
> -Shade
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080903/607b5e93/attachment-0002.htm>