<br><br><div class="gmail_quote">On Mon, Dec 29, 2008 at 7:25 PM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p><span style="font-size:11.0pt;color:#1F497D">The following is rather academic. Bear with me; I'm making
a not so subtle point.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">Ok .Why would anyone believe such a(n academic) claim?</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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 lang="EN" style="color:black">User-Supplied Identifier.
</span><span style="font-size:11.0pt;color:#1F497D">Otherwise, there may well exist only "end-user user input".</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">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:11.0pt;color:#1F497D"></span></p></div></div></blockquote><div><br></div><div>Think about it from the RP's perspective: you get a (perhaps unsolicited) auth response, which is essentially a statement from a (self-identified) OP asserting that a certain browser session is linked to a claimed identity. How do you decide to trust that statement? </div>
<div><br></div><div>You're right in that discovery may not be the only option to infuse trust into such a statement - the RP might have a local database of who it trusts to make which statements. But discovery is certainly _one_ way to gain trust in the auth statements. So in that sense it is _a_ authorization and control point (not _the_ authorization and control point). </div>
<div><br></div><div>Having said that, I'm not sure how I feel about David's original ideas. :-)</div><div><br></div><div>Dirk.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple"><div><p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </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><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> 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:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p><span style="font-size:11.0pt;color:#1F497D">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:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> 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:11.0pt;color:#1F497D"> </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>
<br>_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br></blockquote></div><br>