<HTML>
<HEAD>
<TITLE>Re: [OpenID] HTML-Based Discovery incompatibilities</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Oh I get that. You are not getting my point which is purely technical.<BR>
<BR>
If you can put this in your blog HTML:<BR>
<BR>
<link rel="openid2.provider" href="<a href="https://example.com">https://example.com</a>” /><BR>
<BR>
You can put this in your blog HTML:<BR>
<BR>
<link rel=”describedby” href=”<a href="https://example.com/discovery.xrds">https://example.com/discovery.xrds</a>” /><BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
EHL<BR>
<BR>
<BR>
On 1/8/09 2:44 PM, "Peter Williams" <<a href="pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>“The sole reason for the inclusion of <link> elements is to allow the end –user direct influence over the internals of the protocol.”<BR>
<BR>
No. The sole reason for the inclusion of <link> elements is to allow the end –user direct influence over the externals of the protocol.<BR>
<BR>
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.<BR>
<BR>
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).<BR>
<BR>
<BR>
</SPAN><FONT SIZE="2"><SPAN STYLE='font-size:10pt'><B>From:</B> <a href="general-bounces@openid.net">general-bounces@openid.net</a> [<a href="mailto:general-bounces@openid.net">mailto:general-bounces@openid.net</a>] <B>On Behalf Of </B>Eran Hammer-Lahav<BR>
<B>Sent:</B> Thursday, January 08, 2009 1:32 PM<BR>
<B>To:</B> Martin Atkins<BR>
<B>Cc:</B> <a href="general@openid.net">general@openid.net</a><BR>
<B>Subject:</B> Re: [OpenID] HTML-Based Discovery incompatibilities<BR>
</SPAN></FONT></FONT><FONT FACE="Times New Roman"><SPAN STYLE='font-size:12pt'> <BR>
</SPAN></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>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.<BR>
<BR>
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.<BR>
<BR>
EHL<BR>
<BR>
<BR>
On 1/8/09 1:05 PM, "Martin Atkins" <<a href="mart@degeneration.co.uk">mart@degeneration.co.uk</a>> wrote:<BR>
Eran Hammer-Lahav wrote:<BR>
><BR>
> If I will have any influence on future RP adoption, I will do my best to<BR>
> make them ignore HTML discovery completely. After all, in OpenID, it doesn't<BR>
> seem to matter what the spec says anyway (unfortunately).<BR>
><BR>
<BR>
Are there any protocols where this is not the case?<BR>
<BR>
There are bad implementations of every specification. The choice we need<BR>
to make as specification authors is whether to pretend all<BR>
specifications are perfect and continue adding more and more<BR>
requirements, or to instead write a specification that describes current<BR>
implementation practice.<BR>
<BR>
I think in most cases specifications should be driven by<BR>
implementations, rather than the other way around. A specification that<BR>
describes something that doesn't work in practice is of no use to<BR>
anyone, and writing new specs with even more stringent requirements<BR>
doesn't automatically fix all of the existing "broken" implementations.<BR>
<BR>
_______________________________________________<BR>
general mailing list<BR>
<a href="general@openid.net">general@openid.net</a><BR>
<a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>