drecordon at verisign.com
Fri Sep 22 18:01:51 UTC 2006
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.
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
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
I've been focused on maintaining (1). How do you see it?
specs mailing list
specs at openid.net
More information about the specs