[OpenID] HTML-Based Discovery incompatibilities

Thu Jan 8 18:12:12 UTC 2009

Ah, you mean the culture of the internet/web to let interworking happen with any  old crap that satisfies the 80% interworking rule? Hmm. I used to rail against that too. Then, I got converted.

The biggest point is that user _vanity_ services (in UCI/Openid culture) are not controlled by anyone except the user. I could not care less if the user uses textedit on a template or applies a wizard on a website to help build that XRDS file, so long as the user then copies the result onto his vanity website(s) as a file.

The point is not editing (and obvious usability) but that the ENTIRE content must be "under the control" of the user, and is NOT controlled by any OP (or RP, or SP). Of course, the OP may well have its own XRDS for its "subscribers", associated with the subscriber's identity page. But that's up to the user to address, when considering the OP's terms of service, and whether or not the user chooses to delegate or not to that OP.

If the user want to have its hard-crafted "VANITY" XRDS file copied on 10 different free ISP vanity websites (because one of them might invoke its terms of service tomorrow and interfere with the user's distribution if the user's (openid-signed) metadata, so be it.

This control issue is an important part of the openid model. (I really don't know if it is or is not a part of the culture of OAUTH.) The number of folks who will apply full power UCI will be as small as the f#olks who bother with anonymity, but they CAN, by architecture and culture. The nature of openid discovery today supports that world. I would not want to lose it as specs get updated, or protocols (hopefully) merge.

From: Eran Hammer-Lahav [mailto:eran at hueniverse.com]
Sent: Thursday, January 08, 2009 9:58 AM
To: Andrew Arnott; Peter Williams
Cc: general at openid.net List
Subject: RE: [OpenID] HTML-Based Discovery incompatibilities

This problem gets worse because people have been educated by irresponsible browser vendors to expect broken HTML to simply work.

EHL

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Andrew Arnott
Sent: Thursday, January 08, 2009 9:38 AM
To: Peter Williams
Cc: general at openid.net List
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

Peter,

I'd say what you're missing is that not all HTML is well-formed XML.  If I shot all HTML that dotnetopenid downloaded through an XML parser, dotnetopenid code would look wonderful and perfect... and only 20% of HTML pages with OpenID tags would even be discoverable because the HTML in the other 80% is not well-formed.

--
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 9:05 AM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

I'm missing something (big, obviously).

If DotNetOpenID can delegate to the platform for https, why cannot it delegate to the platform for XML:  just treat the HTML as an XML stream, and build a DOM tree using .NET libraries?

From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net<mailto:general-bounces at openid.net>] On Behalf Of Andrew Arnott
Sent: Thursday, January 08, 2009 8:56 AM
To: Chris Messina
Cc: general at openid.net<mailto:general at openid.net> List
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

Chris,

While you bring up a good issue, and it is a problem with the libraries, I would be against building this into the OpenID spec because this is just following the HTML spec, as you point out.  There are many more rules in HTML that a good RP discovery library should follow (like ignoring commented out HTML tags, javascript, etc.), and these rules don't belong in the OpenID spec either, IMO.

FWIW, dotnetopenid is one library that can handle both formats you listed.  But I do not claim that it has a full browser-quality HTML parser.  Just like every library, I imagine, I had to choose how much time to invest in HTML discovery.  Unless there's a decent open-source HTML parser available for C#, I don't think any C# openid library will ever have "perfect" html discovery by the HTML spec anyway.

--
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 12:58 AM, Chris Messina <chris.messina at gmail.com<mailto:chris.messina at gmail.com>> wrote:

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

--
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com<http://factoryjoe.com> # diso-project.org<http://diso-project.org>
citizenagency.com<http://citizenagency.com> # vidoop.com<http://vidoop.com>
This email is:   [ ] bloggable    [X] ask first   [ ] private

_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090108/bc7b93a0/attachment-0002.htm>