<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)">
<style>
<!--
/* Font Definitions */
@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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EmailStyle19
{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;}
/* List Definitions */
@list l0
{mso-list-id:17197432;
mso-list-type:hybrid;
mso-list-template-ids:-588755336 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</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 style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There are two issues.<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=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The spec does not obviously say that the OP needs to determine
the “validity” of the request parameters (particularly for the XRI.XRD.cid
and XRI.XRD.SEP.LocalID case). And, Andrew picked up my point straightaway:
that conformance does not require an OP to “validate” the request
parameters before responding. <br>
<br>
But, im pretty sure that as “value-add,” certain OPs are in fact
doing that, and it seems to be based on the OP using the XRI “canonical-id
validity” process –doing XRI resolution (not “discovery”
formally) on the inbound cid. Those are OPs are TRUSTING the XRI apparatus, to
gauge the trustworthiness of authorities.<br>
<br>
Since this not a standardized handling requirement, I believe that its appropriate
that other OPs might use equally valid but distinct validity tests. For example
googles test is, apparently: if certain parameter forms are present, just refuse
service. A second example would be when the OP opts to use the trusted
resolution mode of XRI resolution, in which it tests the signed XRDs as the
basis for its validity model. The advantage here is that those XRD’s served
by an XRI server whose canonical-IDs are https URI (per the spec), can now ALSO
be validated (because the signature process is more generalize than validity
logics based on testing that (provider+localid = cid) , as one walks the tree
of name servers.<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=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>As the UI of the OP does not know which synonym the user typed
at the RP (it only knows the i-number, typically), it cannot even show the user
the list of synonyms for that i-number. The RP and the OP may not infact even be
using the same XRI servers (the RP may be using a walled garden install). The user
and RP may together be using synonyms that are not visible/resolvable by the typical
OP being intentionally private from that OP – yet which are tied to the
public i-number server hierarchy. This I feel is a good feature of openid, as
it sets the line – beyond which the OP is not allowed to go spidering/correlating
resources and identities (because this is actively prevented by the “better”
class of RP, by operational design).<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>
<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"'>
openid-general-bounces@lists.openid.net
[mailto:openid-general-bounces@lists.openid.net] <b>On Behalf Of </b>John
Bradley<br>
<b>Sent:</b> Wednesday, August 26, 2009 6:14 AM<br>
<b>To:</b> openid-general@lists.openid.net<br>
<b>Subject:</b> [OpenID] is it true?<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Yes,<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>The OP receives the cannonicalID from the XRDS as the
openid.claimed_id and the LocalID as the openid.identity. The user input
is not passed.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>This also happens with URL identifiers and delegation if
there are http redirects involved.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>I have argued in the past that the two fields we have in
openID 2.0 are problematic for identifiers other than URL and even for them not
always sufficient.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Don't quite know where you are going with this, but it
is a known issue.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>John B.<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal>On 26-Aug-09, at 12:43 AM, <a
href="mailto:openid-general-request@lists.openid.net">openid-general-request@lists.openid.net</a>
wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<p class=MsoNormal><span class=apple-style-span><span style='font-size:13.5pt;
font-family:"Courier New";color:black'>Date: Tue, 25 Aug 2009 21:10:00 -0700</span></span><span
style='font-size:13.5pt;font-family:"Courier New";color:black'><br>
<span class=apple-style-span>From: Peter Williams <<a
href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span><br>
<span class=apple-style-span>Subject: [OpenID] is it true?</span><br>
<span class=apple-style-span>To: "<a
href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a>"</span><br>
<span class=apple-tab-span> </span><span
class=apple-style-span><<a href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a>></span><br>
<span class=apple-style-span>Message-ID:</span><br>
<span class=apple-tab-span> </span><span
class=apple-style-span><<a
href="mailto:BFBC0F17A99938458360C863B716FE463DCDF238FD@simmbox01.rapnt.com">BFBC0F17A99938458360C863B716FE463DCDF238FD@simmbox01.rapnt.com</a>></span><br>
<span class=apple-style-span>Content-Type: text/plain;
charset="us-ascii"</span><br>
<br>
<span class=apple-style-span>User types "@blog*lockbox" at RP</span><br>
<br>
<span class=apple-style-span>Discovery determines that XRD.canonicalid is
!1234, and the XRD.SEP has local-id=homepw.myopenid.com</span><br>
<br>
<span class=apple-style-span>This form of SEP implies that the user desires
openid2-style openid-delegation</span><br>
<br>
<span class=apple-style-span>On receiving a request in which cid=!1234 and
identifier=homepw.myopenid.com, the OP ONLY responds IF it does a discovery on
!1234, validates that cid-verification=true (and sees that there exists
SEP.local-id == request.openid.identity).</span><br>
<br>
<span class=apple-style-span>Is it true that the OP does NOT know that the user
typed @blog*lockbox at the RP?</span><br>
<br>
<br>
<br>
</span><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>