<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">There is talk of removing HTML discovery in future.<div><br></div><div>It is a known security problem.</div><div><br></div><div>Yadis requires the X-XRDS meta tag to be inside the &lt;head&gt; element.</div><div><br></div><div>OpenID 2.0 is silent on it. &nbsp;</div><div><br></div><div>Getting rid of the meta http-eqiv tag from the HTML will be a challenge, and a point for debate.</div><div><br></div><div>I think the other elements will go except for backwards compatibility with older RPs.</div><div><br></div><div>John B.<br><div><div>On 26-Aug-09, at 10:51 AM, Andrew Arnott wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Thanks, Thomas. &nbsp;I hadn't meant to drop the list with my reply.<div><br></div><div>You're points are all correct too. &nbsp;I guess my only argument is: a fully compliant HTML parser in an OpenID RP library would be very heavyweight, and anything less would mean it's buggy. &nbsp;So far, the community seems satisfied with "mostly there" implementations. &nbsp;I agree it's not perfect, but in the next major OpenID spec, HTML discovery is likely to be removed anyway, so I don't think any implementers have motivation to fix these bugs that can easily be worked around.</div> <div><br></div><div>BTW, missing HEAD tags is just one bug, and it seems disproportionate to stress this <i>one</i>&nbsp;over all the others. &nbsp;Some of which are perhaps more serious. &nbsp;I imagine many RPs don't ignore LINK tags that appear within HTML &lt;!-- comments --&gt;. &nbsp;And to properly respect comments requires Javascript parsing (I think!) in order to avoid ending the comment when a javascript function contains a string with "--&gt;" in it.</div> <div><br></div><div>Just some more thoughts. &nbsp;As an RP implementer myself, I do fix some HTML discovery bugs that come in, but not all of them for the reasons given above.<br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br> <br><br><div class="gmail_quote">On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <span dir="ltr">&lt;<a href="mailto:huehn@arcor.de">huehn@arcor.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> [you mailed off-list, was that intentional?]<br> <br> Andrew Arnott schrieb:<div class="im"><br> <br> &gt; The difference is "&lt;LINK&gt;" might appear somewhere in the &lt;BODY&gt; of the &gt; page<br> <br></div> Not in a valid HTML document. :-)<br> <br> Of course you have to think about invalid ones as well, because browsers accept them.<br> <br> But that doesn't have anything to do with whether there is a &lt;HEAD&gt; tag.<br> <br> The security implications are totally independent from having or omitting HEAD tags.<br> <br> Look, it's perfectly clear at any point in the HTML text whether this point belongs to HEAD or to BODY. The HEAD tags are irrelevant.<br> <br> Google even recommends omitting them: <a href="http://code.google.com/speed/articles/optimizing-html.html" target="_blank">http://code.google.com/speed/articles/optimizing-html.html</a><div class="im"><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I agree with Shade. &nbsp;It's sub-optimal security for OpenID RPs to try grokking HTML in the first place. &nbsp;I'm sure if you tried everything <br> </blockquote> <br></div> Of course parsing HTML is hell, but you have specified it.<div class="im"><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> "legal", you'd likely find dozens of ways that RPs are imperfect. &nbsp;But since delegation is a relatively rare scenario anyway (hundreds of millions of OpenIDs out there today, only a few actually delegate since it's an advanced user scenario) I think it's very reasonable to put a few restrictions on it so that RPs can be more secure and written more easily.<br> </blockquote> <br></div> That doesn't change anything.<br> <br> Everything you're saying is absolutely right. But it doesn't have anything to do with whether the HEAD element is surrounded by HEAD tags.<br> <br> My example is *valid*, by the OpenID specification. I have placed LINK elements inside the HEAD element. That's what the OpenID spec demands.<br> <br> The implementation is *buggy*. Yes, that's a fringe case. I can't really blame the author for not thinking about this.<br> <br> And the spec is fine by itself but could be improved for the benefit of developers and users.<br> <br> So there are several ways to handle it:<br> <br> 1. The status quo -- don't do anything: perfectly okay, but probably many more implementations will be buggy, without the developers even knowing about the pitfall.<br> <br> 2. making clear in the spec that the HEAD element does not necessarily correspond to HEAD tags and that a simple grep is *wrong*.<br> <br> 3. re-wording the spec so that it is clear that only a subset of HTML is supported, requiring the HEAD tag(s).<br> <br> I'd prefer 2., just adding a non-normative note to the spec.<br><font color="#888888"> <br> Thomas<br> </font></blockquote></div><br></div> _______________________________________________<br>specs mailing list<br><a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a><br></blockquote></div><br></div></body></html>