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

[Peter Williams]

The absurdity is based on your conception that a higher layer protocol entity is duty bound to interpret the signals of a lower layer in a conforming manner. This is just not so. You are being perhaps far to religious about protocol stacks!

 

Take an example from secure X.400 military email. The so called proof of delivery control is generated by a delivery MTA upon “delivering” a mail to a user agent or msg store. The whole point of distinguishing this “delivery” from the alternative “proof of receipt” security services is that the delivery semantics is not under the control of the user, unlike the assertion of proof of receipt. X.435 EDI/X12 built yet further semantics above and beyond receipt, concerned with “handling” signals – taking formal “responsibility for processing”.

 

Now, do all MTAs abide by the requirement to send out  a signature, proving the act of delivery when its requested? NO. Receiver’soperational  security policy dictates that said act is a violation of policy, concerning information containment rules and covert channels. The operational policy-based deployment is thus made “non- complying” in this sense, even tho the software libraries are in fact complying (because it has been tested to correctly work, when used “in conforming mode”).

 

Openid is simply a (defined) non-conforming mode of HTTP. This fact alone is not an absurd state of affairs. Its quite common when profiling stacks of layer entities.

 

Now I do agree that openid discovery is woefully under analyzed. And, one can argue that openid discovery over http is not right yet. I personally feel in my gut its done mostly right – because of the way the designers ARE able to rationalize its intended controls in terms of low level signals. However the security professional in me really wants to see a formal model/spec that has proven all the case. Its important for the next phase of adoption, by corporate types wanting assurance of correctness etc.

 

 

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Thursday, March 06, 2008 11:58 AM
To: Eddy Nigg (StartCom Ltd.); John Kemp; general at openid.net
Subject: Re: [OpenID] Calling OpenID 2.0 editors (was RE:Problems withOpenID and TAG httpRange-14)

 

Noah Slater: 

 
It's not an assumption, it's bordering on the absurd that I have requote:
 
RFC 2616 § 10.3.4:
 
  The new uri is not a substitute reference for the originally requested resource.
  

No, but neither does the "originally requested resource" must be the claimed_id







 
In this specific case, normalising to http://example.com/ is fine but if this
produces a chain of 302/303/307 redirects to http://john.example.com/ the HTTP
RFC explicitly states that http://example.com/ is the correct URI.
 
  

http://john.example.com/ is the claimed_id, not a redirect. Of course one might submit http://john.example.com/ as the claimed_id from the beginning, but it's not required. 

-- 

Regards 

 

Signer: 

Eddy Nigg, StartCom Ltd. <http://www.startcom.org> 

Jabber: 

startcom at startcom.org

Blog: 

Join the Revolution! <http://blog.startcom.org> 

Phone: 

+1.213.341.0390

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080307/94693e51/attachment-0002.htm>