[OpenID] Calling OpenID 2.0 editors (was RE:Problems withOpenID and TAG httpRange-14)

[Peter Williams]

If your argument concerning HTTP compliance holds for redirect X, then it holds for Y (and vice versa). 

The basis of the argument has evolved usefully, we can note - from the issue in "Problems with OpenID and TAG httpRange-14)" to an issue concerning any and all redirect-based semantics. This latter is much more interesting, as its analyzing the openid discovery security model - something I've long chirped about, to be countered only by journalistic flummoxing.

The argument that HTTP compliance must trump openid for a 301 is suspect - in that it seems to very clearly defy the fundamental security model of openid -- the very (non-web) identity semantics that  openid imposes (as any upper layer is entitled) upon HTTP (which has its own identity model for "web resources"). However, you have heard from an architect, that whilst an URL an openid is not TREATED as a web resource. The argument that your logic holds for the general case (which includes 303) is therefore suspect. Therefore, the case for 303  is suspect (without regard to whatever a 303 (or a 304) may or may not mean).

Nothing required me to look at 303's definition to conclude this. If the general rule doesn't hold for 301, it cannot be applied to a 303...at least not on the grounds given so far.

Lets also examine your phrase "controlling party of the OpenID identity has made the conscious decision to provide a HTTP redirect". Its telling.

I think the phrase is the rub - as you are apparently challenging the "authority" component of the openid security model. The controlling party of the OpenID is the user writing HTML and XRDs in the openid model, not some website doing HTTP protocol. That is a central tenet of openid's UCI doctrine.

I do think - from your choice of phrasing (quoted above) - you disagree with that central tenet. Im guessing you believe that any webserver that hosts an end-user's HTML file can claim to be "the controlling party", as can the site's ISP proxy, and as can the user's ISP proxy or the system proxy spying on the users' desktop. Any party capable of intercepting and modifying the http request/response chain is similarly entitled to _usurp_ the end users UCI authority. Anyone can thus claim to be "the" controlling party. Its not as if the RP site can tell the difference between who made the claim via HTTP signals, given the insecure nature of http proxying.

Furthermore, the one that party that has not been involved in ANY of the above (the OP) is - in your apparent conception -specifically NOT the controlling party - even "when instructed" by the user to be the controlling party - by virtue of a "provisioning" relationship.

Now don't give up on your argument. Mainstream folks in much higher standing than me here (e.g. Hearns) have repudiated (classical) security engineering arguments from me before - as openid is a 'unique, nuveau art': the art of identity (vs the science of security engineering). If I follow that line of claims, folk will surely claim that the art of identity is distinct from the science of web-resource identification, too. So, who cares what HTTP semantics are. Neither security engineering nor web engineering will ever trump the desired semantics associated with UCI.

Its an interesting discussion. It gets to heart of UCI and openid - the fundamental vision.

(If I read between the architectural lines, Im guessing folks want to ensure that the identity and authority semantics applied to XRIs are consistent to those that are applied to the http:// namespace. Therefore one doesn't want the communication medium to interfere with the uniformity of their treatments.)



From: Noah Slater
Sent: Thu 3/6/2008 7:23 AM
To: Peter Williams
Cc: Manger, James H; general at openid.net
Subject: Re: [OpenID] Calling OpenID 2.0 editors (was RE:Problems withOpenID and TAG httpRange-14)


On Wed, Mar 05, 2008 at 08:20:43PM -0800, Peter Williams wrote:
> 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.

You're language was confusing for me, so sorry if I have misinterpreted but
there is no symmetry between 301 and 303 (not 304) responses as clearly defined
in the HTTP RFC section that I keep citing.

Also, as has already been mentioned, the redirects do not happen by chance, the
controling party of the OpenID identity has made the conscious decision to
provide a HTTP redirect and ignoring the semantics of this breaks HTTP.

--
Noah Slater <http://bytesexual.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080306/167c9165/attachment-0002.htm>