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 <[email protected]> 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
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
