The RFC 7800 [1] presents a concrete approach, which defines how to communicate the confirmation key information in JWTs. This is applicable in any case where the RPT itself is a self-contained access token (which is an JWT).
In other words, as per RFC 7800 the authorization server (or the token issuer) embeds the confirmation key (associated with the client) (or a reference to the confirmation key) in the JWT (which signed by the issuer.
The confirmation key can be either symmetric or asymmetric proof of procession key.
If it's asymmetric, then the public key information is communicated in the JWT issued by the authorization server.
If it's symmetric, then the confirmation key is encrypted by a key known to the resource server.
In either case, the JWT can also communicate the confirmation key by reference, using the kid or the jku.
What is not discussed in the RFC 7800?
1. It does not talk about how the key information is established between the client and the authorization server.
2. It does not talk about how the client proves its procession of the confirmation key.
The draft spec OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution [2] addresses how key distribution happens between the client and the authorization server.
The draft spec A Method for Signing HTTP Requests for OAuth [3] can be used as way for the client to prove the procession of the key.
Overall the architecture to build PoP tokens (or RPT in UMA) is in development - and UMA may need not to do any thing specific to itself - but rather provide recommendations and pointers.
Thoughts please...