<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<title>Re: [OpenID] HTML-Based Discovery incompatibilities</title>
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>“The
sole reason for the inclusion of <link> elements is to allow the end
–user direct influence over the internals of the protocol.”<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>No.
The sole reason for the inclusion of <link> elements is to allow the end
–user direct influence over the externals of the protocol.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <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> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] HTML-Based Discovery incompatibilities<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>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:</span><o:p></o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>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></span><o:p></o:p></p>
</div>
</div>
</body>
</html>