[OpenID] HTML-Based Discovery incompatibilities

[Eran Hammer-Lahav]

Long rant inline. Nothing important so if you are busy feel free to ignore.

EHL


On 1/8/09 10:35 AM, "Chris Messina" <chris.messina at gmail.com> wrote:

>
> On Thu, Jan 8, 2009 at 9:39 AM, Andrew Arnott <andrewarnott at gmail.com> wrote:
>> True.  You and I don't need <link> tags with the OpenID URI and can write
>> XRDS docs.  But if you want the average user to be able to set up a vanity
>> URL, they need those simpler tags.
>
> + f.
>
> I will fight tooth and nail to keep basic <link>-based OpenID discovery in the
> spec. I had a hard enough time delegating my own OpenID yesterday. You'd think
> that I'm not your average user and could figure this out -- and if *I* had a
> hard time with it, I can't imagine how normal folks who give a crap about our
> beautiful fucking snowflake technologies will figure it out.
>
> MySpace theming is the perfect counterpoint to your example Eran -- people
> figured out how to skin their MySpace profile by dumping CSS into their
> "About" profile. Browser, designed leniently, fortunately did what they're
> supposed to do, and responded to user intent.

This is a silly example. Just because both MySpace and the browsers build
poor software that allowed so many unforeseen side-effects does not prove
that this is a productive way for technology to evolve.

It's like saying that just because some OpenID RP code will accept email
addresses today and tread it like a domain name for directed identity
(simply because they have FAILED to perform basic input cleanup), it is a
welcomed feature.

The web would be years ahead from the crappy state it is in today if
browsers actually chocked on bad input. The fact that early web agents were
catering to incompetent HTML authors and perpetuated this pattern with every
new version of their browser, is the real reason why HTML is in such a bad
place.

Your argument fails because if you applied it to pretty much any other
critical technology the world will stop working. Should TPC be more flexible
with badly formed packets? How about fluctuation in battery voltage
(significant, like 1.9v instead of 1.5v)?

It's like saying, if you are able to force a "battery" into a "socket",
things should work because you expect them to. Screw voltage, capacity,
temperature, chemical stability, and general safety.

Until people recognize that web technologies must be treated with the same
care and respect as any other technology, we will continue to encourage
people to mess with stuff they are simply not qualified for.

You want them to be qualified for? Great. Educate them and offer them better
tools. It used to be that batteries were all the same size and shape but
with different properties. This is especially true for smaller ones (like
hearing aids and watches). So instead of teaching people about basic
electronic concepts, the industry came up with unique shapes and a
letter/number system.

> When I see people try to mark up their pages with microformats and get it
> wrong (let alone basic HTML), it suggest that we need to make this stuff SO SO
> SIMPLE. If we can say "edit your homepage and add these two lines", that wins
> versus "edit your homepage, add this one line, fire up your text editor,
> create this XML document... blah blah blah. FAIL."

Yeah FAIL, but not because the technology is too complicated but because you
are trying to sell the wrong product to the wrong people. Making stuff
simple must not mean making it limited or poorly designed. It means building
higher layers so that people don't need to mess around with the lower, more
complex layers.

In 1991 I build a TCP based file upload system for schools to send their
data to the central office. I has to use a specific network card that worked
over DOS with the Kermit protocol, but over a TCP network. It was really
ugly stuff that took delicate balance to get to work. 18 years later and you
don't even know what sockets are to get online. Ask Windows users about
their problems configuring winsock as recent as 1998.

As the audience using TCP grew, we didn't make TCP 'SO SO SIMPLE'. That
would have been devastating to the development of modern networks. What we
did was wrap it and hide it from the end user so it Just Worked (tm).

OpenID, Portable Contacts, etc. should NOT follow the example set by
Microformats which promoted individuals to mess around with layers of the
web they have no interest or business messing with. I don't fuck around with
TCP parameters even though I know how to (I served my time writing reliable
UDP multicast protocols from scratch). It is a layer I should not need or
want to operate at. I leave it to others to build wrappers for me so I don't
have to. See, I *can* and don't want to.

>> My parents and sisters, who know almost nothing about HTML, still manage to
>> keep blogs on Blogger.  They could, with help, add two LINK tags to their
>> blog to managed their own OpenIDs, but they could not be expected to author
>> an XRDS doc.  And even if they could, where would they host it?  Blogger
>> doesn't allow hosting of arbitrary files like that.  Nor would the
>> Content-Type HTTP response header likely be the correct one for said XRDS
>> doc.
>
> While I appreciate Eran's point that XRDS should be produced automatically and
> OpenID should just "happen", that's not how we get web-wide adoption. We get
> web-wide adoption with one or two lines of HTML added to an HTML template. And
> nothing more.

Yeah, this has been working GREAT! Get some real numbers but I would bet
that the number of people using HTML links for OpenID delegation are well
below any significant percentage.

> We should certainly accommodate more advanced situations -- and develop the
> full potential of XRD and XRDS, but it should not come at the expense of
> OpenID delegation or adoption.
>
> To echo Andrew's point, folks on shared/hosted services like WordPress.com or
> Blogger often let you tweak your templates (to a certain degree). Uploading
> arbitrary XML files is often prohibited, or worse, rewritten as HTML files.

Using a limited system is not an excuse or a valid design feature. The
argument that "OpenID must work on the world most limited hosting service"
has not proved itself, but made the protocol ugly, inconsistent, and very
VERY hard to implement correctly.

The reason why you are having such a hard time with using <link> elements is
that <link> is actually a very sophisticated and complex mechanism that
offers far too much flexibility for the average web user to grasp. It seems
that many developers are also having an issue with it and the spec is way
too loose to offer any help.

It is time we recognized that the super flexible discovery workflow for
OpenID is one of the main reasons why it is failing the compliance and
interoperability test. It is just too much fucking work (like trying to
parse bad HTML which is far more than 80% of the web).

> Furthermore, HTML-based delegation enables services (like DandyID:
> http://twitter.com/DandyId/status/1100104072) to allow OpenID delegation
> without the need to host an XRDS document for all of its users; it just
> changes its HTML output.

If services cannot host an XRDS document for all users or generate it
dynamically, maybe they should not be allowed to serve anything at all. What
cost are they trying to save exactly? Where is the engineering complexity of
service another set of resource representation (HTTP servers are pretty
awesome doing just that). If XRDS has real deployment issues, we should
discuss it with full attention. But using hacks and shortcut as a building
block of critical web infrastructure is really bad.

> So, I'm sympathetic to your desires, Eran, but I don't think forcing people to
> upload/reference another file is a viable solution. It does mean that the
> OpenID libraries need to be more complicated and more robust, but really, the
> OpenID libraries should be doing the brunt of the work anyway. Our emphasis
> should be on making this stuff excruciatingly easy to implement. Consider
> that, for the most part, Facecbook Connect can be setup with a line of
> JavaScript (same with Google Friend Connect). We need that level of simplicity
> if we're going to stand a chance on the open web.

EXACTLY! And Facebook Connect have not accomplished that by making their
technology ugly, messy, broken, or changed the underlying layers super
simple. They wrote beautiful higher layers that any idiot with a keyboard
can use correctly. This is how good products are designed. Same with
OpenSocial.

OpenID identifier delegation is a very complicated concept. If done wrong,
and it is usually the case, it leads to enormous security risks and
problems. One tiny typo in the cut/paste <link> elements you are fighting so
hard to defend and your identity is completely broken.

Just think about the support nightmare of someone trying to fix their
delegation asking how-to on an IRC channel. "Oh, just paste this ___ into
your blog page" someone will offer, which will give them control over your
web-wide accounts using your OpenID. If OpenID isn't secure, it is
worthless, and security cannot be made 'SO SO SIMPLE', and yes, delegation
is a complex security concept most people do now understand (I would dare
say most people on this mailing list).

Oh, and Facebook connect users don't care about vanity URIs or hosting their
own identity... OpenID's ability to allow anyone to host their own identity
provider is great, but let's not kid ourselves that it is a feature 99.99%
of the web users give a crap about. It is not even true for blogs (far more
hosted between Facebook, MySpace, TypePad, Blogger, Twitter, etc. than self
hosted WP or MT).

If <link> elements are a critical part of the OpenID solutions for the
reasons you offer, OpenID is doomed.

EHL

> Chris
>
>>
>>
>> On Thu, Jan 8, 2009 at 9:16 AM, Eran Hammer-Lahav <eran at hueniverse.com>
>> wrote:
>>> It is. I am just saying we don't need so many options (like <link> elements
>>> with the OpenID URI). Simply point everything to just an XRDS file.
>>>
>>>
>>>
>>> EHL
>>>
>>>
>>>
>>> From: Andrew Arnott [mailto:andrewarnott at gmail.com]
>>> Sent: Thursday, January 08, 2009 9:04 AM
>>> To: Eran Hammer-Lahav
>>> Cc: Chris Messina; general at openid.net List
>>> Subject: Re: [OpenID] HTML-Based Discovery incompatibilities
>>>
>>>
>>>
>>> Eran,
>>>
>>>
>>>
>>> Maybe I misunderstand you, but isn't adding a link to your XRDS file from
>>> HTML in fact one aspect of HTML discovery?
>>>
>>>
>>>
>>> I mean, html discovery can result in an XRDS doc reference, finding
>>> openid.server (et. al) tags, or nothing at all.
>>> --
>>> Andrew Arnott
>>> "I [may] not agree with what you have to say, but I'll defend to the death
>>> your right to say it." - Voltaire
>>>
>>> On Thu, Jan 8, 2009 at 8:55 AM, Eran Hammer-Lahav <eran at hueniverse.com>
>>> wrote:
>>>
>>> I would like to see HTML-Based discovery removed from the spec completely.
>>> There is no reason to have it anymore since you can simply add a link to
>>> your XRDS file from HTML and get it all done there in a consistent way.
>>>
>>>
>>>
>>> In my upcoming discovery spec I spell out that resource-consumers must
>>> support multiple values in the rel attribute.
>>>
>>>
>>>
>>> EHL
>>>
>>>
>>>
>>> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
>>> Behalf Of Chris Messina
>>> Sent: Thursday, January 08, 2009 12:59 AM
>>> To: general at openid.net List
>>> Subject: [OpenID] HTML-Based Discovery incompatibilities
>>>
>>>
>>>
>>> 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
>>>
>>> [1] http://openid.net/specs/openid-authentication-2_0.html#html_disco