Backwards compatibility

[Dick Hardt]

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 http://www.lifewiki.net/openid/ 
OpenIDChanges and grouped by issues for OpenID 1.1 IdP and OpenID 1.1  
RP.

XRI support and Yadis support:
	IdP: since this stage of the protocol is prior to any messages, no  
issue
	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  
issue

Extensions
	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 openid.net [mailto:specs-bounces at openid.net] On
> Behalf Of Josh Hoyt
> Sent: Wednesday, September 20, 2006 1:31 PM
> To: specs at openid.net
> 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 openid.net
> http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>