Some implementations don't process the HEAD element correctly

Wed Aug 26 15:24:24 UTC 2009

There is talk of removing HTML discovery in future.

It is a known security problem.

Yadis requires the X-XRDS meta tag to be inside the <head> element.

OpenID 2.0 is silent on it.

Getting rid of the meta http-eqiv tag from the HTML will be a  
challenge, and a point for debate.

I think the other elements will go except for backwards compatibility  
with older RPs.

John B.
On 26-Aug-09, at 10:51 AM, Andrew Arnott wrote:

> Thanks, Thomas.  I hadn't meant to drop the list with my reply.
>
> You're points are all correct too.  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.  So far, the  
> community seems satisfied with "mostly there" implementations.  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.
>
> BTW, missing HEAD tags is just one bug, and it seems  
> disproportionate to stress this one over all the others.  Some of  
> which are perhaps more serious.  I imagine many RPs don't ignore  
> LINK tags that appear within HTML <!-- comments -->.  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 "-->" in it.
>
> Just some more thoughts.  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.
> --
> Andrew Arnott
> "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
>
>
> On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <huehn at arcor.de> wrote:
> [you mailed off-list, was that intentional?]
>
> Andrew Arnott schrieb:
>
>
> > The difference is "<LINK>" might appear somewhere in the <BODY> of  
> the > page
>
> Not in a valid HTML document. :-)
>
> Of course you have to think about invalid ones as well, because  
> browsers accept them.
>
> But that doesn't have anything to do with whether there is a <HEAD>  
> tag.
>
> The security implications are totally independent from having or  
> omitting HEAD tags.
>
> 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.
>
> Google even recommends omitting them: http://code.google.com/speed/articles/optimizing-html.html
>
>
> I agree with Shade.  It's sub-optimal security for OpenID RPs to try  
> grokking HTML in the first place.  I'm sure if you tried everything
>
> Of course parsing HTML is hell, but you have specified it.
>
>
> "legal", you'd likely find dozens of ways that RPs are imperfect.   
> 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.
>
> That doesn't change anything.
>
> 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.
>
> My example is *valid*, by the OpenID specification. I have placed  
> LINK elements inside the HEAD element. That's what the OpenID spec  
> demands.
>
> The implementation is *buggy*. Yes, that's a fringe case. I can't  
> really blame the author for not thinking about this.
>
> And the spec is fine by itself but could be improved for the benefit  
> of developers and users.
>
> So there are several ways to handle it:
>
> 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.
>
> 2. making clear in the spec that the HEAD element does not  
> necessarily correspond to HEAD tags and that a simple grep is *wrong*.
>
> 3. re-wording the spec so that it is clear that only a subset of  
> HTML is supported, requiring the HEAD tag(s).
>
> I'd prefer 2., just adding a non-normative note to the spec.
>
> Thomas
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090826/f2266396/attachment-0001.htm>