[OpenID] Reconsidering http://openid different from https://openid

[Peter Williams]

This is now true.

 

Using the delegation flow path, the owner can indirectly signal any URI one wants.  It doesn’t need to resolve.

 

The delegate value coming back can be http:///?PPDURI=ftp://user:passwrd@something.com/#me&query <http://?PPDURI=ftp:/user:passwrd@something.com/#me&query> =.... If one wants.

 

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Monday, September 24, 2007 4:06 AM
To: Stephane Bortzmeyer
Cc: OpenID List
Subject: Re: [OpenID]Reconsidering http://openid different from https://openid

 

The 2.0 Spec draft ( http://openid.net/specs/openid-authentication-2_0-12.html ) speaks about something different:


Abstract


OpenID Authentication uses only standard HTTP(S) requests and responses, so it does not require any special capabilities of the User-Agent or other client software. OpenID is not tied to the use of cookies or any other specific mechanism of Relying Party or OpenID Provider session management. Extensions to User-Agents can simplify the end user interaction, though are not required to utilize the protocol.

and throughout the specs:

Identifier:

An Identifier is either a "http" or "https" URI, (commonly referred to as a "URL" within this document), or an XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) <http://openid.net/specs/openid-authentication-2_0-12.html#XRI_Syntax_2.0>  [XRI_Syntax_2.0]. This document defines various kinds of Identifiers, designed for use in different contexts.

 


7.2.  Normalization


#  Otherwise, the input SHOULD be treated as an http URL; if it does not include a "http" or "https" scheme, the Identifier MUST be prefixed with the string "http://" <http://> . If the URL contains a fragment part, it MUST be stripped off. See Section 11.5.2 (HTTP and HTTPS URL Identifiers) for more information. 


11.5.2.  HTTP and HTTPS URL Identifiers


Relying Parties MUST differentiate between URL Identifiers that have different schemes. When end user input is processed into a URL, it is processed into a HTTP URL. If the same end user controls the same URL, differing only by scheme, and it is desired that the Identifier be the HTTPS URL, it is RECOMMENDED that a redirect be issued from the HTTP URL to the HTTPS URL. Because the HTTP and HTTPS URLs are not equivalent and the Identifier that is used is the URL after following redirects, there is no foreseen reduction in security when using this scheme. If an attacker could gain control of the HTTP URL, it would have no effect on the HTTPS URL, since the HTTP URL is not ever used as an Identifier except to initiate the discovery process. 

 

-- 

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

 




Stephane Bortzmeyer wrote: 

On Thu, Sep 20, 2007 at 03:55:14PM -0700,
 Paul C. Bryan <email at pbryan.net> <mailto:email at pbryan.net>  wrote 
 a message of 59 lines which said:
 
  

	OpenID is built on the HTTP(s) protocol,
	    

 
Checking the specification, it does not seem so. The specification
apparently only says that the identifier has to be resolvable (an URL,
not just any URI), which includes ftp:// URLs (and gopher:// :-)
 
That's why it would be a bad idea to make a special case for
http/https by saying that they must be the same. This would break the
simple rule that an identifier is any URL.
  

 

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