<HTML><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText56607 dir=ltr>
<DIV dir=ltr><FONT color=#000000>ok. lets go through this.</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>In the simplest, oldest case, a website distributes HTML resources, with openid metadata values. Said signals are control signals that are security critical to a security handshake protocol known as openid auth. Neither the client accessing said HTML nor the server providing it are yet engaged in openid auth.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Said website knows little or nothing about openids. It specifically does not know what is in the HTML resource. Only the end user controls the contents of the HTML, in the (normal case of the) UCI model. The site or any proxy between itself and the client may issue the usual set of redirects. No RP will be any the wiser as to just who or what issued said redirects or the accuracy or validity of these "link-related HTTP control signals". The user is certainly not responsible for said signals, in the UCI model. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>The website and RP complete openid discovery, noting that any OP will later necessarily be suspicious of both website and RP - both being relatively untrusted as far as the OP is concerned. Discovery using http is one technique, of course: XRI proxies are another. XRI proxies do not rely on HTTP protocol for resolution of openid having xri URI namespaces. Tho XRIs are URIs, they do not rely on http (or its "link-centric" redirects) for name resolution semantics. A hybrid of XRIs and HTTPS URI resolution are known as HXRNs, which leverage certain properties of SSL and trusted PKI roots to overcome some of the proxy problems associated with the insecure http approach (we are led to believe).</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>An OP agent on some server host (normally distinct from that providing the website for HTML discovery) then engages in openid auth, at the RP's request. The typical flow is solicited auth, which follows openid discovery. The consumer is partially trusted, by protocol design, to bind the state of the discovery protocol run to the state of the pending auth protocol run. It is trusted to map delegation openids, for example.</DIV></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Meantime, the OP agent works with provisioning agents (possiby itself), to bind a given user's auth data to one or more synomymous openids,possibly including directed openids featuring PPID fields.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>If the discovery website or some or other random http proxy had earlier issued a 301, whose semantics SHALL BY FIAT HENCEFORTH MEAN that a permanent change of openid has been factually provisioned, about the only parties who don't know about this fact are ...the OP agent responsible for making assertions, in regard to only provisioned openids, and , of course, the party who is the authority responsible for the act of provisioning openids at an OP agent.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Lets recall that, in the general case, there is just NO signalling between the website producing discovery info and the agent producing assertions based on an openid, provisioned earlier to said agent by some naming authority (possibly the agent itself, or the user). This property derives from the UCI model, and is fundamental to the adoption of openid (some here would have us believe).</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>If the website and consumer did in fact collude to express a change of "permanent openid" by some private semantic agreement about HTTP signals (and "restart" discovery for example) , the resulting claimed identifier may well then be normalized and ultimately will presumably be presented to the openid agent for validation, against user auth data associated with a provisioned openid. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>In the common case, the OP agent will have zero knowledge of that claimed openid value (given it is not yet provisioned) - and will be unable to make a positive assertion about something it has no authority to speak about. In the worst case, the claimed openid resulting from making an semantic leap about 301s will happenstance match an already provisioned case pertaining to another party. The end user in question SHOULD be unable to supply suitable authentication data in this case, leading the OP to conclude the same: it must issue a failure to provide positive assertion.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Now Ive know to be really really wrong, before now! It can and surely will happen again. But, the case of 301 is much more obviously shows up the architectural issues better than did the earlier 304 example. However, if 304 holds, so does 301 by symmetry, and 301 is looking pretty dodgy on the above grounds.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Before we decide if OpenID has bad design, lets decide if the above security model is even accurate. If we decide the model is accurate yet the design is arguably poor (on HTTP compliance grounds), a work item will have been identified for openid 2.fix.<BR></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Noah Slater<BR><B>Sent:</B> Wed 3/5/2008 7:17 PM<BR><B>To:</B> Peter Williams<BR><B>Cc:</B> Manger, James H; general@openid.net<BR><B>Subject:</B> Re: [OpenID] Calling OpenID 2.0 editors (was RE:Problems withOpenID and TAG httpRange-14)<BR></FONT><BR></DIV>
<DIV><PRE style="WORD-WRAP: break-word">On Wed, Mar 05, 2008 at 04:53:29PM -0800, Peter Williams wrote:
> But that is what following HTTP resource-centric semantics would mean.
Which, like it or not, is a consequence of choosing HTTP as a transport layer.
--
Noah Slater <http://bytesexual.org/>
</PRE></DIV></BODY></HTML>