OAUTH: how does a client manage multiple version of its metadata at the same time?

[sandhose]

A client may want to change its client metadata, for example, to add or remove a scope, or change its redirect_uris.

Because you don't always control the rollout of new versions of your application, how does one manage to maintain two versions of the same application with potentially different client metadata?

You could set different client_ids, e.g. v1.example.com and v2.example.com, which would resolve to different client metadata, but then I presume that would break existing sessions whenever you upgrade the app, as the client_id is different?

Having faced the same problem for the Matrix protocol, an alternative would be to use dynamic client registration, with a software_statement, self-signed using RFC 7800 cnf method. Then the server can use the (cnf, software_id, software_version) tuple to dedupe clients and track client version updates. I still need to write up the real proposal in a public document somewhere

By the way, this client registration problem in a decentralised web is not new, and IndieAuth tried to solve that some time ago, but we dismissed this for Matrix because it was too different from the rest of the OAuth & OIDC specs, was too opinionated also for the auth server part, and was quite lacking in terms of what metadata you could define.

[matthieusieben]

Hi ! Thank you for your message & interest.

Our current position about the rollout of different versions is as follows: Before the rollout of a new version starts, the client metadata can be updated to include additional required scopes and/or redirect_uris. This broader client metadata can then be updated again to a stricter version once the rollout is over.

We also looked into IndieAuth and dismissed it for the same reason. We realized after writing our proposal that there already exists a Draft that does something very similar as we did. We are actively looking into bringing this draft back up and we will try to match whatever spec comes out of it.

[matthieusieben]

I don't really see how software_statements could help with this. software_id is used to identify client instances, and the key used to sign the software_statement can indeed be used as means for clients to prove they are indeed the owner of that software_id. Our implementation does not need any of that. The reason is that our trust model works differently and relies on DNS to verify ownership.

In our implementation, the client_id (= +/- client_uri) acts as a software_id. And the fact that the metadata can be obtained, on the internet, form an endpoint derived from the client_id, serves as "proof" that the owner of the software_id is indeed who he claims to be.

Domain name owners can change, of course, but then so will the private key of the client, which will result in all credentials being invalidated for that client.

[matthieusieben]

Clients who do not wish to allow a broader client metadata to exist should handle authentication failures as being possibly cause by an outdated version of the client (requesting scopes/redirect_uris no longer valid) and prompt the user to update the client.