Backwards compatibility

Dick Hardt dick at
Mon Sep 25 10:44:54 UTC 2006

If we are maintaining message compatibility, then we likely need to  
back out a number of the changes in D9
(if we do not have to maintain 100% compatibility, then we should  
address any issues in this spec)

Going through the changes at 
OpenIDChanges and grouped by issues for OpenID 1.1 IdP and OpenID 1.1  

XRI support and Yadis support:
	IdP: since this stage of the protocol is prior to any messages, no  
	RP: will not know how to process an iname nor a Yadis file

IdP-driven identifier:
	IdP: Clearly an OpenID 1.1 IdP will not be able to support this
	RP: will not know how to process

Optional Identifier
	IdP: will not understand it being blank
	RP: no issue

HTML Form-Based Redirection
	IdP: 1.1 spec says that it is a GET, this breaks the protocol
	RP: will be sending everything as a GET

New Associations
	IdP/RP: this feature is negotiated in Yadis file, so compatible - no  

	IdP/RP: negotiated feature, so no issue

Nonce and TIme stamp
	IdP: will not generate
	RP: spec says that it is required, 2.0 RP will not get it from a 1.1  
IdP, so would fail according to spec

URI Normalization
	no issue

New Field Name
	RP specific, no issue

Base Namespace
	IdP/RP: 1.1 will not understand, behaviour for unknown parameters  
not specified in 1.1 draft

On 22-Sep-06, at 11:01 AM, Recordon, David wrote:

> Like Josh, I believe it is important to maintain number 1.
> My intention would be that someone could read OpenID Authentication  
> 2.0,
> never having read 1.1, implement a library, and have it work with an
> implementation from someone who has only read 1.1 and not 2.0.  This
> means that in 2.0 we need to both continue making the conscious effort
> to only change what is required, as well as to mark things which have
> been deprecated though are still required in implementations for
> backwards compatibility.  While I agree that the number of deployments
> is relatively small, we should do everything possible to maintain
> compatibility with them.
> --David
> -----Original Message-----
> From: specs-bounces at [mailto:specs-bounces at] On
> Behalf Of Josh Hoyt
> Sent: Wednesday, September 20, 2006 1:31 PM
> To: specs at
> Subject: Backwards compatibility
> When making and evaluating proposals, there have been many  
> references to
> backwards compatibility. I'm not sure that everyone has the same idea
> what it means to be backwards compatible.
> There are at least two meanings that I can see:
> 1. Messages that are valid OpenID 2.0 messages are also valid OpenID
> 1.1 messages
> 2. It is possible for implementations to differentiate between OpenID
> 1.1 and 2.0 and to construct appropriate messages. In essence, it's a
> different protocol.
> I've been focused on maintaining (1). How do you see it?
> Josh
> _______________________________________________
> specs mailing list
> specs at
> _______________________________________________
> specs mailing list
> specs at

More information about the specs mailing list