[OpenID] HTML-Based Discovery incompatibilities

Thu Jan 8 18:40:49 UTC 2009

This firmness seems to suggest a hard edge, perhaps leaving out the grace of transition...if we applied same rules to the the web, not wanting people to edit the raw contents, tags, etc. it may not exist in it's dominant form.

Hand coding entities (web sites) by people allowed experimentation, creativity, and development of businesses.   It's still common practice used today even with Dreamweaver, etc.     Isn't that in a way, hand-coding of tomorrow.

Is another way to say it is that it should be a design goal to avoid people having to 'code' their identities as part of the experience.   But controlling them and managing them is a goal as well, why shouldn't I be able to throw around my options as it all evolves.   It's a given that the namespace in the middle of discovery is yet to be filled in.   It needs to be free to get it there, rather than formed into a currently conceived app (even the mighty FB struggles in this experience with all the options)

Opinion: core protocol benefit if it could be applied in command line, browser, app, container, widget, scan, or handwritten word...

--Mike (=eek!:public:opinion:idCommons:reply:eran)

________________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Eran Hammer-Lahav [eran at hueniverse.com]
Sent: Thursday, January 08, 2009 9:55 AM
To: Andrew Arnott
Cc: general at openid.net List
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

That is a completely wrong approach. ANY need to manually edit HTML or XRDS is a failure on part of the OpenID (or even blog platform) provider. Users should use a UI, not code XML/HTML/XRDS to manage their identity.

The people today who want vanity OpenID URIs can all edit XRDS. In fact, they are more likely to get it right than editing HTML. When the market for vanity URIs for grandmas is ready, so will the sleek UI to enable it.

EHL

From: Andrew Arnott [mailto:andrewarnott at gmail.com]
Sent: Thursday, January 08, 2009 9:40 AM
To: Eran Hammer-Lahav
Cc: Chris Messina; general at openid.net List
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

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.

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.

--
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:16 AM, Eran Hammer-Lahav <eran at hueniverse.com<mailto: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<mailto:andrewarnott at gmail.com>]
Sent: Thursday, January 08, 2009 9:04 AM
To: Eran Hammer-Lahav
Cc: Chris Messina; general at openid.net<mailto: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<mailto: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> [mailto: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<mailto: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

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