OpenID status update

[Martin Atkins]

Evan Martin wrote:
> 
> However, one useful thing is to define behavior for when the version
> does change.
> For example, add something to the spec like:
>   If there is a version key in the request, you should just return an
> error like "version not understood".
> This allows you to actually add that new version without worrying
> about how older consumers will handle it.
> 

I think the idea is that the software will downgrade to suit what it's
talking to, rather than failing.

For example, if server is version 2 and consumer is version 1, the
server will see that the consumer's request was version 1 and thus reply
in version 1.

If server is 1 and consumer is 2, the consumer will make a version 2
request, which will ideally be backwards compatible. (If not, we've lost
anyway.) The server will respond with version 1, and the consumer will
still know how to deal with version 1 and act accordingly.

As Paul has been saying, the only thing that is likely to change in
future is that new fields will be added to the request and to the
signature. As long as all of the old request fields stick around, this
above scheme will work without anyone breaking.

However, per this scheme I don't really see the difference between
explicitly stating version=1 and just having it implied by the lack of a
version number. It's more likely that our future versions will be
implied by additional request parameters anyway, and in a more recent
thread a self-describing signature format is being discussed to allow
the signature structure to change in future.