Backwards compatibility

Drummond Reed drummond.reed at
Thu Sep 21 00:11:43 UTC 2006

FWIW, I've been assuming (2), mostly because I've been assuming there would
be a separate XRDS service endpoint (SEP) type for OpenID Authentication

So if my IdP supported both OpenID Authentication 1.1 (for which the SEP
type is actually still "") and OpenID
Authentication 2.0, my XRDS document would advertise both SEP types.

That doesn't mean that (1) can't be done, i.e., that OpenID 2.0 can't
support the same set of messages as OpenID 1.1. It just means that it
doesn't have to, because (2) allows an RP can differentiate between an IdP
that supports OpenID Authentication 1.1 and 2.0.

Is my assumption correct?

And if so, how do others answer Josh's question?


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