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

[Noah Slater]

On Thu, Mar 06, 2008 at 08:58:22AM -0800, Peter Williams wrote:
> If your argument concerning HTTP compliance holds for redirect X, then it
> holds for Y (and vice versa).

Sure, I never refuted this. I said that 303 is not symmetric with 301.

301 says "X is now Y" and 303 says "go look at X instead of Y"

> 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.

To be honest, I'm not really that conversant with OpenID and all these
mentionings of OPs, RPs, APs and Tipis ;) is quite confusing for me. I really
don't see how it's related to the security model though.

> The argument that HTTP compliance must trump openid for a 301 is suspect

Not at all. If you want to use HTTP, fine, but you must obey it's semantics,
absolutely or else you are just using it as a dumb tunneling protocol in much
the same way that XML-RPC and SOAP abuse it for tunneling RPC commands.

OpenID claims to use HTTP and URIs but this claim is false unless the standards
are adhead to absolutely, there is no room for compromise.

Nothing suspect about that.

> in that it seems to very clearly defy the fundamental security model of openid

I couldn't possibly comment on this, you know far more about it than I do.

However, if this is true then it seems that the security model needs to be fixed.

> 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").

No, upper layers of technology are absolutely NOT allowed to break identity semantics.

Enhance, yes, that's great, but break, no.

> However, you have heard from an architect, that whilst an URL an openid is not
> TREATED as a web resource.

An architect? What does that mean? Also, this statement is false. Given that
OpenID uses HTTP and URIs to dereference and canonicalise URIs it seems pretty
clear to me that OpenIDs are very deeply intertwined with HTTP resources.

> 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).

Not at all. You cannot claim that OpenID doesn't make use of HTTP resources, it
does, this is explicit in the specification. Also, you can not reasonably assert
that it is correct to break a non-vague/controversial section of the HTTP RFC.

> Nothing required me to look at 303's definition to conclude this.

Yes, it shows.

> 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.

Of course my arguments apply to 301, but considering that the semantics are
different for that redirect my specific suggestions do not apply.

> I do think - from your choice of phrasing (quoted above) - you disagree with
> that central tenet.

As previously mentioned, I know nothing of OpenID security. This however is
completely beside the point. I do not need to understand OpenID security to see
that OpenID is breaking a very fundamental aspect of HTTP.

> 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.

False, the HTTP RFC I have cited clearly makes statements about identity.

> So, who cares what HTTP semantics are.

Authors of a specification that bulids opon HTTP, I hope.

> Neither security engineering nor web engineering will ever trump the desired
> semantics associated with UCI.

Of course they do.

--
Noah Slater <http://bytesexual.org/>