Backwards compatibility

[Drummond Reed]

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

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?

=Drummond 

-----Original Message-----
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
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
specs at openid.net
http://openid.net/mailman/listinfo/specs