drummond.reed at cordance.net
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 "http://openid.net/signon/1.0") 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?
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