<HTML>
<HEAD>
<TITLE>Re: [OpenID] HTML-Based Discovery incompatibilities</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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&#8217;s will break with something as simple as someone putting &lt;link&gt; tags inside a comment on a blog&#8217;s front page, hijacking that identifier...<BR>
<BR>
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 &#8216;SO SO SIMPLE&#8217; exploit.<BR>
<BR>
EHL<BR>
<BR>
<BR>
On 1/8/09 11:08 AM, &quot;John Bradley&quot; &lt;<a href="john.bradley@wingaa.com">john.bradley@wingaa.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi Chris,<BR>
<BR>
Yes it is a problem I have detected with a number of RP libs. &nbsp;<BR>
<BR>
I did a test for openID delegation via rel links for the last OSIS interop<BR>
<a href="http://osis.idcommons.net/wiki/I5:FeatureTest-OpenID_2.0_Relying_Party_openID_2.0_delegations_via_rel_links">http://osis.idcommons.net/wiki/I5:FeatureTest-OpenID_2.0_Relying_Party_openID_2.0_delegations_via_rel_links</a><BR>
<BR>
One of the leading causes of delegation failure I have seen is using &lt;link rel=&quot;me openid.delegate&quot; href=&quot;<a href="http://thread-safe.net">http://thread-safe.net</a>&quot; /&gt;<BR>
<BR>
A number of the libs I discovered were trying to use regex to find the openid.delegate in a too restrictive way.<BR>
<BR>
I will expand the test cases for I5 and try to catch this behavior.<BR>
<BR>
Regards<BR>
=jbradley<BR>
<BR>
On 8-Jan-09, at 1:21 PM, <a href="general-request@openid.net">general-request@openid.net</a> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT SIZE="1"><FONT FACE="Helvetica, Verdana, Arial"><SPAN STYLE='font-size:9pt'>Message: 1<BR>
Date: Thu, 8 Jan 2009 00:58:45 -0800<BR>
From: &quot;Chris Messina&quot; &lt;<a href="chris.messina@gmail.com">chris.messina@gmail.com</a>&gt;<BR>
Subject: [OpenID] HTML-Based Discovery incompatibilities<BR>
To: &quot;<a href="general@openid.net">general@openid.net</a> List&quot; &lt;<a href="general@openid.net">general@openid.net</a>&gt;<BR>
Message-ID:<BR>
&lt;<a href="1bc4603e0901080058u2ae8f88dw87f268460e1605c8@mail.gmail.com">1bc4603e0901080058u2ae8f88dw87f268460e1605c8@mail.gmail.com</a>&gt;<BR>
Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<BR>
<BR>
I just read over SS 7.3.3 on HTML-Based Discovery [1], and considering my<BR>
experience today trying to re-delegate my OpenID, I've discovered that this<BR>
section needs to updated a clarified.<BR>
<BR>
It turns out that relying parties are not parsing HTML rel values in a<BR>
standard way. That is, if there is more than one rel value provided for a<BR>
link, some RPs fail, whereas others work fine.<BR>
<BR>
In other words, this:<BR>
<BR>
&nbsp;&nbsp;&lt;link rel=&quot;openid2.provider openid.server&quot; href=&quot;<BR>
<a href="http://factoryjoe.com/blog/">http://factoryjoe.com/blog/</a>&quot; /&gt;<BR>
&nbsp;&nbsp;&lt;link rel=&quot;openid2.local_id openid.delegate&quot; href=&quot;<BR>
<a href="http://factoryjoe.com/blog/">http://factoryjoe.com/blog/</a>&quot; /&gt;<BR>
<BR>
is not the same as this:<BR>
<BR>
&nbsp;&nbsp;&lt;link rel=&quot;openid2.provider&quot; href=&quot;<BR>
<a href="http://factoryjoe.com/blog/?openid_server=1">http://factoryjoe.com/blog/?openid_server=1</a>&quot; /&gt;<BR>
&nbsp;&nbsp;&lt;link rel=&quot;openid2.local_id&quot; href=&quot;<BR>
<a href="http://factoryjoe.com/blog/author/factoryjoe/">http://factoryjoe.com/blog/author/factoryjoe/</a>&quot; /&gt;<BR>
&nbsp;&nbsp;&lt;link rel=&quot;openid.server&quot; href=&quot;<BR>
<a href="http://factoryjoe.com/blog/?openid_server=1">http://factoryjoe.com/blog/?openid_server=1</a>&quot; /&gt;<BR>
&nbsp;&nbsp;&lt;link rel=&quot;openid.delegate&quot; href=&quot;<BR>
<a href="http://factoryjoe.com/blog/author/factoryjoe/">http://factoryjoe.com/blog/author/factoryjoe/</a>&quot; /&gt;<BR>
<BR>
It's my understanding that the rel attribute should be able to contain<BR>
several values.<BR>
But I can tell you that IntenseDebate, for example, failed when delegation<BR>
was setup using the former code. It only worked when I broke out the two<BR>
links into four.<BR>
<BR>
I'm not sure if this is an issue with the libraries or what, but I'd like to<BR>
know if other people have experienced this problem, and if we can improve<BR>
the language in the spec to make sure that people understand that they need<BR>
to look for the presence of an element in a rel value -- not that the<BR>
*entire* value is one element.<BR>
<BR>
Chris<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>