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