This is an excellent question. I'm going to suggest that it is answered at a meta-level by the UMA business model (and in its specifics by any concrete set of legal devices put in place, used in some specific jurisdiction that has operative laws like the ones you're referring to). So this is a good test for the business model, and perhaps a FAQ if the model passes the test.
OAuth has an incomplete "BLT" model when it comes to answering questions about "responsibility". Any one interpretation has to come down to specific profiles and, potentially, some guessing. I'm thinking, for example, of Open Banking, where there has been a lot of work -- outside of actual specifications -- around client registries, mappings of flows to regulatory meanings of "consent", and so on, and I'm willing to bet that these profiles' coverage doesn't exactly match the coverage given by SMART on FHIR, HEART, etc. in their sector, and so on.
UMA's business model provides this additional "BLT" layer. The legal party role that is responsible for client registration is called a Client Operator. The CO has to engage in a client registration flow prior to the involvement of the user. (Though, in the case of dynamic registration, it might be only just slightly prior.)
Another way OAuth's model is incomplete is that it doesn't contemplate Alice sharing data with Bob. The OAuth singular "user" is always the resource owner, and this entity just grants access to the client. In UMA technical language, a resource owner grants access to a requesting party (the latter is the one using the client). In the UMA business model -- deep breath -- an Authorization Server Operator licenses access on a Resource Rights Administrator's behalf to both the Client Operator and the Requesting Agent. (That's a good enough rendering for now, given a simple use case!)
So "the user" of the client (meaning the party engaging with the Client Operator) might be:
- In the case of most OAuth grants, and trying to back-fit the UMA business model to it as best we can: "Alice who is always the sole user/resource owner, and therefore both the Resource Rights Administrator and the Requesting Agent"
- In the case of the UMA grant of OAuth: "Whoever is the Requesting Agent -- could be Alice again, could be Bob"
This "user" presumably has some opportunity to make an agreement with the client, e.g., if they're a human, agree to a ToS/privacy notice. But it's always after client registration, which is done in a one-to-one fashion by the Client Operator with the Authorization Server Operator. So the Client Operator pretty much has to be responsible for client registration.
The same sort of analysis applies when we talk about UMA's resource server component, which is loosely coupled with the authorization server component and has an OAuth client relationship with it. So the Resource Server Operator is responsible for client registration (and the Resource Rights Administrator may have an opportunity to make an agreement with the Resource Server Operator, such as agreeing to a ToS/privacy notice).
You can see all of these relationships unfold in the
Legal Role Definitions slide deck, particularly some of our older "railroad track" diagrams on slide 33 ("How RSO and CO become known to ASO").