Backwards compatibility

Dick Hardt dick at
Fri Sep 22 00:22:34 UTC 2006

This is clearly an important design decision for OpenID 2.0, and I  
think draft 9 violates (1) already.

Would not the parameter:


break an OpenID 1.1 IdP?  Perhaps I am not understanding how the  
messages id D9 are compatible.

Also, I thought OpenID 2.0 was moving to POST instead of GET, so that  
will likely cause some incompatibilities.

Currently there are very few OpenID deployments when looked at in the  
context of all the web sites out there that are doing identity  
related transactions, and I would imagine that most OpenID 1.1 sites  
will be running OpenID 2.0 within a couple months of OpenID 2.0 being  
ratified and libraries available.

If we are successful in creating a simple and powerful specification,  
OpenID 2.0 will be rapidly deployed. The user-centric players have  
converged, awareness is high, and sites are hungry for a solution.

While I empathize with sites running OpenID 1.1 now wanting to  
minimize the effort to move to OpenID 2.0, that needs to be weighed  
against the much larger pain of orders of magnitude more sites needed  
to change later. Additionally, most sites are deploying libraries, so  
the code change is in the library, and the site may be completely  
insulated from the change.

I am NOT suggesting that we change the overall protocol of OpenID. I  
am suggesting that if there are small changes that make OpenID easier  
to understand, develop and deploy, now is the time to do it rather  
then later. Given the discovery mechanism, an RP can easily determine  
if an IdP will support the services desired.

-- Dick

On 20-Sep-06, at 5:11 PM, Drummond Reed wrote:

> 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 "") 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 [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?
> Josh
> _______________________________________________
> specs mailing list
> specs at
> _______________________________________________
> specs mailing list
> specs at

More information about the specs mailing list