The dynamic client auth spec recommends JWTs be signed using public/private key auth.
When presented to the authorization server as part of a
client registration request, the software statement MUST be digitally
signed or MACed using JSON Web Signature (JWS) [RFC7515] and MUST
contain an "iss" (issuer) claim denoting the party attesting to the
claims in the software statement. It is RECOMMENDED that software
statements be digitally signed using the "RS256" signature algorithm
The spec does not describe how one should determine the public key to verify against. One possible way we could do this would be to inspect the iss header, and ping a .well-known address for a public key based of the iss URL. For instance, $iss/.well-known/wp-api.key. We would then need to verify that the iss, client_uri and redirect_uris are all in the same domain.
We could then show on the connection screen that this is an authorized $client_uri app ( or something to that effect ).
The dynamic client auth spec recommends JWTs be signed using public/private key auth.
The spec does not describe how one should determine the public key to verify against. One possible way we could do this would be to inspect the
issheader, and ping a.well-knownaddress for a public key based of theissURL. For instance,$iss/.well-known/wp-api.key. We would then need to verify that theiss,client_uriandredirect_urisare all in the same domain.We could then show on the connection screen that this is an authorized
$client_uriapp ( or something to that effect ).