Let's expand on this and describe how an app developer can run a backend service that validates the DeviceCheck/Play Integrity signatures and returns a JWT the app can use with the private_key_jwt client authentication method. This would actually be a pretty reasonable level of assurance of the app's identity. This doesn't need to be specified normatively in this proposal, since the actual underlying OAuth mechanism used is only the private_key_jwt auth method.

Perhaps the normative text can be left in the IETF draft, and we can just normatively reference that instead and outline the concept of using "private_key_jwt" here. Alternatively we can add a section to talk about client authentication as a core part of the spec, and not just as a mitigation in this section.

Proposing some expanded text below.

is there some kind of validation we could use? could jus t people impersonate any client there?

someone running software bound on localhost can impersonate another client running on localhost. Solving that requires more work, but is not different from DCR today. there's a longer write up in the blog about this topic: https://blog.modelcontextprotocol.io/posts/client_registration/#challenge-2-client-identity-and-impersonation

how are clients choosing the approach to use? is there any concept of priority?

Generally the way I see clients doing this is:

1. If they have a pre-registered credential available, use that
2. If not, use CIMD if supported
3. If not, use DCR if supported
4. If not, prompt user that they can't connect / they need to go pre-register a client

This would probably be good to explicitly spell out

what kind of validation are we talking about? block some ip ranges?

yea good question, I wonder if we want to just link to the CIMD RFC rather than spelling this all out here as well.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00#section-6.5

Authorization servers fetching the client metadata document and resolving URLs located in the metadata document should be aware of possible SSRF attacks. Authorization servers SHOULD avoid fetching any URLs using private or loopback addresses and consider network policies or other measures to prevent making requests to these addresses. Authorization servers SHOULD also be aware of the possibility that URLs might be non-http-based URI schemes which can lead to other possible SSRF attack vectors.

what about private_key_jwt? can you show an example?

I'd rather leave that to the CIMD RFC