<HTML><HEAD><TITLE>Re: [OpenID] Calling OpenID 2.0 editors (was RE:ProblemswithOpenID and TAG httpRange-14)</TITLE></HEAD>
<BODY>
<DIV id=idOWAReplyText42454 dir=ltr>
<DIV dir=ltr><FONT color=#000000>This argument is persuasive and cogently put, Brendan. It says: in light of n redirects, HTTP signals can and should control which "one" dominates in a given session. It contrasts with Noah's argument: the bit of paper known as HTTP says X, kowtow!</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>What I don't want is the HTTP's notion of link control (by providers) to have any impact on the provisioning status of openids - in the eyes of consumers. If consumer=plaxo has linked my openid to a plaxo account, we don't want plaxo to believe they have to now unlink me because of a 301! That a 301/302/303 may influence the current login session's state machine uniquely... is ok (ie. I don't care, given the whole model is UCI anyways). If the result is I am unable to auto-assert my Plax account linking on arrival at Plaxo because of those HTTP signals, so be it. Plaxo will have to allow to enable me to rebind my latest openid, or allow n openids to link to 1 plaxo account (good luck, plaxo!)</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Its fine to make users responsible for choosing a webserver provider for HTML and XRDs that correctly uses the right type of initial redirect to impose the USERS desire for signaling which of a series of redirects controls the id_req's claimed id, from consumers. Providers should be relatively free to also use 302, so they can move resources around without user involvement, as normal - provided there is no semantic implication on either the provisioning model or the string value a consumer ultimately relies upon , as delivered by id_res. That will surely almost always be actually bound to non-openid I&A models, imposing traditional, subscriber/records legal semantics - much as we saw in LIVE.com's multiple linking/legal controls, a thread or two ago..</DIV>
<DIV dir=ltr><FONT face=Terminal size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Terminal size=2></FONT> </DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Brendan Taylor<BR><B>Sent:</B> Thu 3/6/2008 5:23 PM<BR><B>To:</B> general@openid.net<BR><B>Subject:</B> Re: [OpenID] Calling OpenID 2.0 editors (was RE:ProblemswithOpenID and TAG httpRange-14)<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On Thu, Mar 06, 2008 at 02:16:52PM -0800, Johnny Bufu wrote:<BR>> Noah,<BR><BR>> You're arguing under the assumption that the string typed by the user <BR>> at the RP (the User-supplied ID) is also or should be the claimed_id. <BR>> This is not the case per the current OpenID 2.0 definitions.<BR><BR>No. The argument is that if URI-1 redirects to URI-2 with a 303 See<BR>Also, then URI-1 should be the claimed_id (according to HTTP's semantics).<BR><BR>> > If I claim <<A href="http://bytesexual.org/" target=_blank>http://bytesexual.org/</A>> as my OpenID<BR>> > and this 303s to some place else it is pretty clear what my <BR>> > "claimed id" is,<BR>><BR>> Yes - the URL after all redirects, unless you use a different <BR>> definition for claimed_id.<BR><BR>Yes — according to the OpenID spec, which should probably be changed.<BR><BR>Using a 303 redirect means that you don't want URI-2 to be substituted<BR>for URI-1.<BR></FONT></P></DIV></BODY></HTML>