[OpenID] HTML-Based Discovery incompatibilities

Thu Jan 8 17:26:55 UTC 2009

Would you support an XRDS extension, where users can control the contents?

For example, I can see a user including an URL in some (to be defined, free-form) XRDS "user-block.". The form of a link in that area could be itself be an openid assertion, bearing a multi-value AX attribute, whose values are macs over the other n other service sections in the XRDS.

I would not expect XRDS discovery resources generated by OPs to do this note. Id only expect it for those XRDS files that users explicitly maintain  (at vanity OpenIDs, allowing for the world of multi-OP delegation).

If I type https://cacert.at/homepw/terms1 vs  https://cacert.at/homepw/terms2 at an RP , only then would I expect different XRDS extension values in the "user block" to be affixed by my user's "discovery resource server" to the XRDS streamed actually to the  RP. In the simplest case, the choice of vanity url just picks up and streams 1 of 2 prepared XRDS file located  on  the webserver.

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

Do whatever you want in HTML. Just keep OpenID configuration in the XRDS document and nowhere else.

EHL

From: Peter Williams [mailto:pwilliams at rapattoni.com]
Sent: Thursday, January 08, 2009 9:16 AM
To: Eran Hammer-Lahav; Chris Messina; general at openid.net List
Subject: RE: [OpenID] HTML-Based Discovery incompatibilities

In HTML supporting vanity openid URLs, users get to add their copyrights and legal notices (just like the OPs do). Its much harder to do that in XML, particularly since XRDS which is a highly constrained profile of XML.

Perhaps we can standardize in the XRDS an extension for (vanity) users to apply: free form extension encapsulating a blob of HTML?

Whatever practice is right for an OP or RP or SP, is right for a user (in UCI).

That rule not the case for all multi-party (shared) control systems, however. It's not true in public CA trust networks typically (though CAcert is a notable exception ...which  typically gets that community blackballed for being overly-user-centric).

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, January 08, 2009 8:56 AM
To: Chris Messina; general at openid.net List
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

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

--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090108/20ab929d/attachment-0002.htm>