<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";
color:#1F497D'>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.
<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>(Would not take _<i>away</i>_ the older form, tho.)<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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 *<b>my</b>* copyright notices (and possibly an openid
unsolicited assertion hyperlink) in the file that is actually transferred…not
merely the HTML file that references it.<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>------<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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!<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I can host my XRDS on MSN’s file server for end-users tho,
using that file URL as my vanity URL.<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This is what I analogously do today (using my “vanity
openid”) for my SAML IDP metadata.<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><a
href="https://gkt09w.bay.livefilestore.com/y1pO26pp1NJGPMADWnUCSV1kK0_YB14GgjZktcKs8iYxEwDpLp8Ja8LNDulqEr8wcCPWmeSetJt1po/metadata.xml">https://gkt09w.bay.livefilestore.com/y1pO26pp1NJGPMADWnUCSV1kK0_YB14GgjZktcKs8iYxEwDpLp8Ja8LNDulqEr8wcCPWmeSetJt1po/metadata.xml</a><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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>yes that url is awful… But at least its mine. I can have <a
href="https://cacert.at/homepw">https://cacert.at/homepw</a> 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).<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>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><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"'> Eran Hammer-Lahav
[mailto:eran@hueniverse.com] <br>
<b>Sent:</b> Thursday, January 08, 2009 3:18 PM<br>
<b>To:</b> Peter Williams; 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"'>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:</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"'>“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><b><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Calibri","sans-serif"'> <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><br>
<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:<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></span><o:p></o:p></p>
</div>
</div>
</body>
</html>