[OpenID] HTML-Based Discovery incompatibilities

Thu Jan 8 23:44:54 UTC 2009

100% No objection to adding that. Could not care less (as as user). If it improves RP interoperability, by pointing to my XRDS file, then wonderful.

(Would not take _away_ the older form, tho.)

Happy just so long as the user has a "user block" in the XRDS, that is free form (and intended for users to put user-defined material in there, without hurting core interoperability). Im pretty sure XRDS already allows for that. I want *my* copyright notices (and possibly an openid unsolicited assertion hyperlink) in the file that is actually transferred...not merely the HTML file that references it.

------

Unless MSN spaces has changed  its policy note, your variant proposal is as useless to me personally as the earlier HTML specs... as MSN Spaces won't allow the user to specify ANY metadata link values!

I can host my XRDS on MSN's file server for end-users tho, using that file URL as my vanity URL.

This is what I analogously do today (using my "vanity openid") for my SAML IDP metadata.

https://gkt09w.bay.livefilestore.com/y1pO26pp1NJGPMADWnUCSV1kK0_YB14GgjZktcKs8iYxEwDpLp8Ja8LNDulqEr8wcCPWmeSetJt1po/metadata.xml

I have a wizard that made that SAML IDP discovery data (which certain SAML SP can auto discovery, just like OpenID does). Perhaps someone in open source will now write a tool for me that makes an XRDS, similarly. That would be cute.

yes that url is awful... But at least its mine. I can have https://cacert.at/homepw redirect there, easily, if I want. Unlike the HTML pointer, the redirect point actually works (well... it does at OIDF and pbwiki, but not at DNOI...as the long https saga discussed).

From: Eran Hammer-Lahav [mailto:eran at hueniverse.com]
Sent: Thursday, January 08, 2009 3:18 PM
To: Peter Williams; Martin Atkins
Cc: general at openid.net
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

Oh I get that. You are not getting my point which is purely technical.

If you can put this in your blog HTML:

<link rel="openid2.provider" href="https://example.com" />

You can put this in your blog HTML:

<link rel="describedby" href="https://example.com/discovery.xrds" />

Then in the XRDS file you can accomplish the same level of control. Removing support for direct configuration in HTML does not take away ANY FUNCATIONALITY from the user. But it does make it more complex for users to manually do it as it requires more knowledge of syntax and architecture.

So the point is, the majority of users will never mess around with <links> to begin with, and the very few who will, will still be able to control it but will have one more step to deal with. Considering the great security, interoperability, and simplicity benefits to the protocol, I want to drop the HTML duplicated mechanism. To argue that my proposal takes any capabilities away is simply wrong.

EHL

On 1/8/09 2:44 PM, "Peter Williams" <pwilliams at rapattoni.com> wrote:
"The sole reason for the inclusion of <link> elements is to allow the end -user direct influence over the internals of the protocol."

No. The sole reason for the inclusion of <link> elements is to allow the end -user direct influence over the externals of the protocol.

That's what I'm not sure you are getting. The User is Supposed to be able to control discovery. And by user I mean user - not "subscriber" of an OP. The user can subscribe to several OPs, and gets to direct which one is used. Presumably OPs will hate this, but tough. The only issue for users is which is easier to configure: an HTML or XML blob. Obivously in either case, the reality is that wizards will do both.

Im sympathetic  to folk who argue that HTML on a blog site MUST remain is a simple fall back for vanity openids, and backwards compatibility with HTML should not be lost. At the  same time, I know my own blob provider wont allow me as a user to amend metadata/link values (as metadata in HTML is deemed insecure, in the Microsoft opinion of the web). As vendor, they got to impose their view on me about what is and is not secure - and obviously my opinions as a user are irrelevant. But, that's what openid is here to address: be "user centric" (vs  portal centric).

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, January 08, 2009 1:32 PM
To: Martin Atkins
Cc: general at openid.net
Subject: Re: [OpenID] HTML-Based Discovery incompatibilities

Exactly. Look at what has been working properly and what has not and clean up the spec. The problem with OpenID, unlike most other protocols in this space is that it is too close to the end-user surface. The sole reason for the inclusion of <link> elements is to allow the end -user direct influence over the internals of the protocol. So if this feature is not widely adopted, it leads directly to breaking the faith the end-user has in the entire protocol. When you use a Yahoo feature that doesn't work, you don't blame HTTP for it. But if you use OpenID directly, and it doesn't work you do blame OpenID more than anything else.

While your approach is correct, I think the issue is the sample size you are using to decide what is "common-practice". In reality, most of the spec should be dropped due to lack of consistent implementation.

EHL

On 1/8/09 1:05 PM, "Martin Atkins" <mart at degeneration.co.uk> wrote:
Eran Hammer-Lahav wrote:
>
> If I will have any influence on future RP adoption, I will do my best to
> make them ignore HTML discovery completely. After all, in OpenID, it doesn't
> seem to matter what the spec says anyway (unfortunately).
>

Are there any protocols where this is not the case?

There are bad implementations of every specification. The choice we need
to make as specification authors is whether to pretend all
specifications are perfect and continue adding more and more
requirements, or to instead write a specification that describes current
implementation practice.

I think in most cases specifications should be driven by
implementations, rather than the other way around. A specification that
describes something that doesn't work in practice is of no use to
anyone, and writing new specs with even more stringent requirements
doesn't automatically fix all of the existing "broken" implementations.

_______________________________________________
general mailing list
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/f0b46cda/attachment-0002.htm>