[OpenID] Claimed Identifiers and Query String Parameters

[Andrew Arnott]

Say... I just checked to see if I have a Claimed Identifier for each blog
post I've written, courtesy of Google, who adds an openid.server tag to my
blog for free... (which I never use, but hey)...
Their solution, since they couldn't very well redirect every specific post
page back to my blog home page for the sake of openID, is to only include
the openid.server REL tag on my home page and not any other.

That leads me to an interesting suggestion: rather than OPs redirecting
identity pages to https: automatically, why not display their identity page
at http: the way the user typed it, but tell them "this page only functions
as your identity page when you use https:"  The redirect is fine, unless the
RP's DNS server is poisoned, then suddenly the user's "secure" identifier of
"aarnott.pip.verisign.com" is not secure any more because the http: that
would normally redirect could be hosted by a bad server that doesn't
redirect, pretend to be the OP and and phish the credentials from the user.


Contrast this to just not redirecting and not emitting openid identity tags
or XRDS references on the non-encrypted identity page.  Thus forcing the
user into the habit of typing https:// in front of their URL, and protecting
themselves always from a DNS poisoning attack... especially for when the
attack is actually in progress.

Thoughts?

On Wed, Sep 3, 2008 at 1:32 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

> Joe Tele wrote:
> >
> > --- On Wed, 9/3/08, 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.
> >
> > 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.  I'm
> eager to get our implementation correct, so I appreciate any other help to
> set me straight.  I actually like the model where the OP selects the claimed
> id.
>
> I think your understanding is correct. 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.
>
> >>> However, it seems that some sites have virtually infinite number of >
> >> claimed identifiers for the same OP Local Id.
> >
> >> 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.
> >
> > Got it.  Our URLs are following the normalization rules.
> >
> > It seems that the OPs have a much greater obligation than they may
> realize to normalize their claimed identifiers.  It will be to their user's
> detriment if they do not.  I guess a power of OpenId is when the OPs which
> behave well to their users survive and the others whither.
> >
>
> It is true that many OPs are currently not doing much if any
> normalization on identifiers. However, since it is the OP that is
> responsible for parsing the identifier or otherwise mapping it onto a
> user account it seems to me to be most correct for the OP to be
> responsible for normalizing it too.
>
> This can cause some pain if the OP doesn't do it from the start; when
> LiveJournal.com initially implemented OpenID its users all had two or
> three different identifiers that were all distinct as per the OpenID
> specification. LiveJournal later switched to normalizing to a particular
> URL scheme, which caused pain for users that had already used the
> "wrong" URL scheme and were no longer able to access their accounts at RPs.
>
> This would be a good topic to address in a hypothetical "OP best
> practices" document. Hopefully it's being included in the OpenID book(s)
> that are currently being written.
>
>
> _______________________________________________
> 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/29ac12a8/attachment-0002.htm>