[OpenID] HTML-Based Discovery incompatibilities

Thu Jan 8 20:45:52 UTC 2009

Eran,

Over a year a go I started looking at problems RP libs were having  
with XRDS discovery for XRI.

As it turns out I found more problems on the URI side.  It is not that  
libs  didn't appear to work 90% of the time, it was more that corner  
cases and exceptions lead to what could best be described as  
unpredictable results.

That is what got me started developing OSIS tests for openID so that  
OPs and RPs could test those corner cases and attack surfaces.

I have a deep sympathy with the UCI goal of someone having control  
over there identity.

That was the idea motivating the creation of XRI iBrokers to that  
hosted users XRDS file and openID authentication service.
The idea was to provide those high level interfaces for users to  
configure and manage there identities.

The other alternative of encouraging people to use there blog and  
openID delegation has for the most part been a security nightmare.  It  
is too expensive for the average user to purchase a SSL cert to secure  
there blog if they are running there own site.  That has forced us to  
continue allowing non ssl openIDs by people without a real concept of  
the consequences of that.

I think that where the new XRD spec is going with signed XRDs will be  
a big improvement once there is adoption.

I however don't see a move to deprecate the rel tags being acceptable  
to the community at this point.

My suspicion is that as secure forms of discovery are made available  
in future openID specs,  RP's will exercise there option not to accept  
insecure openIDs this will cause the natural demise of delegated  
openID's by people who may not be up to the challenge.

As an example I believe that Andrew Arnott's DNOI has a secure mode  
that enforces SSL for a RP and Microsoft's health vault only supports  
secure discovery.  I suspect this will be a trend for RP's that need  
to secure personal information.

I do think that there will eventually be a market for User controlled  
openID's however there will probably be some cost to the user.  The  
reality is that at a free service the OP is serving some other  
master.   The XRI iBrokers are a bit a head of the market and that has  
been hard on them.

I think it is incumbent on us to make rel links work as well as they  
can for discovery,  but I think that they will become the last place a  
RP looks rather than the first when it tries discovery on identifiers.

Regards
=jbradley

On 8-Jan-09, at 5:04 PM, Eran Hammer-Lahav wrote:

> And there you have it. It is *impossible* to have a secure  
> implementation of OpenID if you allow parsing of non-compliant HTML  
> using fully-compliant HTML parsers (obeying every single rule). I am  
> sure some RP’s will break with something as simple as someone  
> putting <link> tags inside a comment on a blog’s front page,  
> hijacking that identifier...
>
> If it was up to me, RPs would not be allowed to try and make sense  
> out of ANY HTML page that is not fully compliant (that includes any  
> unknown element, attribute and even bad scripts). Obviously, it is  
> not up to me. And because HTML is so inherently broken, I will not  
> trust myself to get it right (not my hosting service) and will never  
> use HTML discovery with an OpenID I identify myself with. This is  
> not extreme, just common-sense. I am not afraid of a MITM attack. I  
> am afraid of a simple comment on my blog used to hijack my identity.  
> The ‘SO SO SIMPLE’ exploit.
>
> EHL
>
>
> On 1/8/09 11:08 AM, "John Bradley" <john.bradley at wingaa.com> wrote:
>
> Hi Chris,
>
> Yes it is a problem I have detected with a number of RP libs.
>
> I did a test for openID delegation via rel links for the last OSIS  
> interop
> http://osis.idcommons.net/wiki/I5:FeatureTest-OpenID_2.0_Relying_Party_openID_2.0_delegations_via_rel_links
>
> One of the leading causes of delegation failure I have seen is using  
> <link rel="me openid.delegate" href="http://thread-safe.net" />
>
> A number of the libs I discovered were trying to use regex to find  
> the openid.delegate in a too restrictive way.
>
> I will expand the test cases for I5 and try to catch this behavior.
>
> Regards
> =jbradley
>
> On 8-Jan-09, at 1:21 PM, general-request at openid.net wrote:
>
> Message: 1
> Date: Thu, 8 Jan 2009 00:58:45 -0800
> From: "Chris Messina" <chris.messina at gmail.com>
> Subject: [OpenID] HTML-Based Discovery incompatibilities
> To: "general at openid.net List" <general at openid.net>
> Message-ID:
> <1bc4603e0901080058u2ae8f88dw87f268460e1605c8 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I just read over SS 7.3.3 on HTML-Based Discovery [1], and  
> considering my
> experience today trying to re-delegate my OpenID, I've discovered  
> that this
> section needs to updated a clarified.
>
> It turns out that relying parties are not parsing HTML rel values in a
> standard way. That is, if there is more than one rel value provided  
> for a
> link, some RPs fail, whereas others work fine.
>
> In other words, this:
>
>   <link rel="openid2.provider openid.server" href="
> http://factoryjoe.com/blog/" />
>   <link rel="openid2.local_id openid.delegate" href="
> http://factoryjoe.com/blog/" />
>
> is not the same as this:
>
>   <link rel="openid2.provider" href="
> http://factoryjoe.com/blog/?openid_server=1" />
>   <link rel="openid2.local_id" href="
> http://factoryjoe.com/blog/author/factoryjoe/" />
>   <link rel="openid.server" href="
> http://factoryjoe.com/blog/?openid_server=1" />
>   <link rel="openid.delegate" href="
> http://factoryjoe.com/blog/author/factoryjoe/" />
>
> It's my understanding that the rel attribute should be able to contain
> several values.
> But I can tell you that IntenseDebate, for example, failed when  
> delegation
> was setup using the former code. It only worked when I broke out the  
> two
> links into four.
>
> I'm not sure if this is an issue with the libraries or what, but I'd  
> like to
> know if other people have experienced this problem, and if we can  
> improve
> the language in the spec to make sure that people understand that  
> they need
> to look for the presence of an element in a rel value -- not that the
> *entire* value is one element.
>
> Chris
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090108/ffba70b2/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090108/ffba70b2/attachment-0002.bin>