Can registrations be updated using fields returned on the public Register APIs?

[CDR-Register-Stream]

The following was raised in our Wednesday forum

V1.3.0 of the CDR Register design introduces the fields legal entity ID and legal entity name as optional to the SSA. If those haven't been specified by the client but are obtained through the API, and then the client does a GET on the DCR endpoint, is it appropriate to return the values already obtained from the Register via the APIs?

[CDR-Register-Stream]

The Dynamic Client Registration design intends for the data recipient to control their registrations with data holders.

We can imagine a scenario where a company goes through re-branding and changes fields within their legal entity definition. This data recipient may choose to update the Registration on a small data holder to have a controlled change and ensure there are no unintended consequences. These changes would then be propagated through to all the other data holders once the quality gate has been met.

If data holders are able to make these changes post registration, the data recipient loses control of their registration and what is presented to their consumers.

Therefore, our current thinking is that data holders should not be making updates to the publicly exposed registration fields outside of the currently defined registration flows.

[anzbankau]

Thanks for the clarification on this topic. Could you also please clarify - when a data recipient performs a PUT operation on the DCR end point - will the SSA supplied include all the fields (including optional fields) that were originally supplied in the POST?

[CDR-Register-Stream]

@anzbankau Thank you for your query. The SSA provided for a PUT operation is intended to be the same or a newer version of the SSA payload used during the POST operation. There won't be a subset of fields provided.

That said, I will need to provide some clarity on what happens if a previous version of an SSA is used during a PUT operation. This wouldn't be an appropriate operation but may be technically valid.

I'll work this through and update this thread and the documentation.

[CDR-Register-Stream]

Using a previous version of an SSA to update a current registration would be a technically valid operation.

SSAs don't have version numbers so data holders need to treat the SSA as normal, i.e. data holders must process fields they support and ignore those they don't. Responses will still need to comply with the DCR API specification

Data recipients are responsible for maintaining their own registrations and registration mismanagement (e.g. using an older version of an SSA) will be up to the data recipient to rectify.

[spikejump]

@CDR-Register-Stream technically it is possible for DRs to use "old" SSAs. However, that SSA would have an exp that would most likely have expired. So if DHs validate the SSA's signature then DHs would have picked up the SSA is an old SSA and reject the PUT.

[CDR-Register-Stream]

@spikejump thanks for your comments. It is correct that the exp claim would invalidate any old SSA previously retrieved.

This issue raises the question on whether an ADR can retrieve an old version of an SSA. Currently this is valid as the x-v header allows for previously versions of SSAs to be retrieved. We don't want the deprecation of endpoints on the CDR Register to be the only control here.

[CDR-Register-Stream]

V1.4.0 of the CDR Register Design introduces a new section on DCR PUT operations with the following documentation:

---

Registrations must only be updated via Registration PUT operations

PUT operations are to be used for one of two scenarios:

1. The client has updated their registration details on the CDR Register and updates this information to the data holder brands
2. A new version of the SSA has been released and the client updates this information to the data holder brands

• POST and PUT operations MUST accept the SSA payload.

• Any fields the data holder brand does not support are not persisted. However, registration responses must conform to the DCR API specification