Peter,<br><br>Wow! These are great questions you're bringing up.<br>See more replies inline....<br><br><div class="gmail_quote">On Tue, Dec 30, 2008 at 3:25 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">The following is rather academic. Bear with me; I'm making
a not so subtle point.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">I don't see anything in openid auth v2 that mandates that
the consumer MUST respect the XRDS. That is, if there exists local means to
locate the OP, a consumer may vector the user's browser there. There is
nothing non-conforming in sending the user to an OP that is missing from the
XRDS. Therefore the XRDS is not a control apparatus. In any case the https cert
of the endpoint at which the XRDS is located may not be valid –
given validity is a subjective metric of the RP – denying validity to the
(unsigned) XRDS on the grounds of lack of assured integrity.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p></div></div></blockquote><div>Technically, you are correct that an XRDS can be ignored, but I think the spec is pretty clear that there are only 3 "paths through which to do discovery": XRDS via XRI; XRDS via URL, or HTML Discovery.
Given that dictum, it would seem that if the XRDS is to be ignored, it can only be done so by utilizing HTML based discovery.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Ok .Why would anyone believe such a(n academic) claim?</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">First off, the requirement to display the form to collect the
openid is only noted as a SHOULD. That is, per any SHOULD conformance constraint,
there exist good reasons to do otherwise. Furthermore, critical failures do not
occur merely as a result of following any such (good) reasons. Only in the case
of following the SHOULD counsel will there exist a </span><span style="color: black;" lang="EN">User-Supplied Identifier.
</span><span style="font-size: 11pt; color: rgb(31, 73, 125);">Otherwise, there may well exist only "end-user user input".</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p></div></div></blockquote><div>Still, the spec clear that whatever the "user-input" is, it must be normalized into an Identifier, which is clearly defined in the Terminology sections to be either a URL or an XRI.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">While 7.2 procedures are uniformly expressed in terms of MUST (and
they address any and all "end-user user input") they are contingent
of user "input" (which may not exist). A user may have, by way of
contrast to "input", a existing user session (created by
means unknown) and the consumer MAY (absent denial) initiate openid auth from
that state, for example. This proposition is generally consistent with the
notion of "unsolicited" assertions - which a consumer may legitimately
(and outside of OpenID Auth) "induce".</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div>I would argue that if the user "input" doesn't exist, then OpenID cannot be used -- you can't create an authentication assertion on a non-existent input. If I'm correct, then the non-existence of "user input", whatever the form, necessitates the non-use of OpenID. <br>
<br>Right?<br><br>Also, an existing "session" implies an existing user-input, normalized into an Identifier, because I would assert that you can't have an OpenID Auth "session" without an Identifier.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">7.3 appears normative, but absent a single MUST is not
mandatory. That is: openid discovery is optional.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div>Even if discovery is optional, you must agree that *if* any sort of Discovery is going to be utilized in OpenID-land, then it must abide by 7.3, yes?<br>
Though I would concede that Discovery does appear to be optional -- but only in the case where the RP already knows the OP Endpoint.<br><br>Here's my logic:<br><ol><li>Discovery is the process of taking an OpenID Identifier (XRI or URL) and determining various things, most importantly is the OP Endpoint.</li>
<li>The only way to determine the OP Endpoint is:</li><ol><li>OpenID Discovery (7.3)</li><li>Reading an already discovered OpenID endpoint.</li></ol></ol>If the only way to get an OpenID endpoint is via the above two methods, then *somebody* has to have done Discovery (per 7.3) in order to populate the mechanism being used in my number 2.2 above.<br>
<br>To my way of thinking, this should be clarified in OpenID auth 2.1 -- at the least, if an RP is going to use some non-7.3 mechansim to get an OP Endpoint URL, then that "mechanism" MUST be populated via traditional Discovery. <br>
<br>Otherwise, if Discovery is optional, then that breaks OpenID Auth (IMHO). The point of OpenID Auth is the user saying, "I control this identifier", and "I can prove this by setting up Discovery meta-data that an RP can use to verify the assertion that I control this URL/XRI". If Discovery is optional, then an RP would never be able to "trust" the OpenID assertion.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">7.3.2 has a clear IF… which implies that "not if"
is a normative possibility. That is: XRI resolution and YADIS are
optional implementation areas.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div>Yes, but 7.3.2 is a subsection of 7.3, which defines the "not if" possibility, which is HTML Based discovery.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">7.3.3 has states in which absence of an HTML discovery document is
…an entirely "legitimate" state. What happens in that state
is not defined (compounded in the case that there has been no use of XRI/YADIS)</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p></div></div></blockquote><div>My opinion is that if 7.3.3 has an "absence of HTML discovery" state, you must still fallback on 7.3, which says there are only 3 states to pick from. So, if I can only pick 3 states/paths, and I can't pick HTML-Based Discovery, and I can't pick XRI/XRDS, and I can't pick URL/Yadis, then there are *no* other valid states to pick from.<br>
<br>Using that logic, there is no legitimate "fourth state" (that being one which is not defined). It is defined out of existence by 7.3.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">I thus fail to find that XRDS/HTML is intended to be an authorization/control
framework. If it is supposed to be, its badly specified. I suspect from the
phrasing, it supposed to be convenient metadata.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div>See above. I'm very confident that *if* Discovery is to be performed, then it must be done via one of the three paths in 7.3. <br>
<br>I'm less confident about Discovery not being optional since the wording is unclear, but I think the intent was for Discovery to be non-optional (keep in mind that mandated Discovery could still allow an RP use a lookup table, or some other mechanism, so long as the lookup table is initially populated via 7.3 Discovery).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US"><div><p><span style="font-size: 11pt; color: rgb(31, 73, 125);"></span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;">
<div>
<div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">
<p><b><span style="font-size: 10pt;">From:</span></b><span style="font-size: 10pt;"> David Fuelling
[mailto:<a href="mailto:sappenin@gmail.com" target="_blank">sappenin@gmail.com</a>] <br><div class="Ih2E3d">
<b>Sent:</b> Monday, December 29, 2008 10:12 AM<br>
<b>To:</b> Peter Williams<br>
</div><b>Cc:</b> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a> List<br>
<b>Subject:</b> Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1</span></p>
</div>
</div><div class="Ih2E3d">
<p> </p>
<p>Peter,<br>
<br>
Thanks for your input...see my replies inline. <br>
<br>
david<br>
<br>
On Mon, Dec 29, 2008 at 4:36 PM, Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>> wrote:</p>
<div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">The main problem I have is
…you are changing the character of XRDS (and XRI 2.0 resolution).</span></p>
</div>
</div>
</blockquote>
<div>
<p>Yes, but I'd be open to accomplishing these ideas without
doing so.</p>
</div>
<blockquote style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); border-width: medium medium medium 1pt; padding: 0in 0in 0in 6pt; margin-left: 4.8pt; margin-right: 0in;">
<div>
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> In 1, you are turning
metadata discovery into a authorization/control framework. Won't be long before
you will want a "#include QXRI" line in the XRDS, that imports XRDs
from a superior policy authority, and require the XRI client resolver to now to
"augment" the XRDs with those from the control authority. If OpenID
needs an policy-based authorization framework, let's consider that in its own
right (and there is LOTS AND LOTS of previous work to draw on). Let's not break
the (nicely working) metadata model, tho.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
</div>
</div>
</blockquote>
<div>
<p style="margin-left: 5.25pt;">Well, it already is an authorization/control
framework. The value of the OP endpoint in your XRDS document is what
controls what your OP is. Proposal #1 merely extends this to say that you
need 2 OP's instead of one, and possibly only for certain sites.<br>
<br>
</p>
</div>
</div>
<p> </p>
</div></div>
</div>
</div>
</blockquote></div><br>