Backwards compatibility

Recordon, David drecordon at
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.


-----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?

specs mailing list
specs at

More information about the specs mailing list