Ensure that an issued access_token is used by the client (wallet) that requested it, and
Constraint the usage of the access_token
This DPoP (demonstration of Proof of Possession) must not be confused with Proof Of Possession that may be used within the credential request.
The basic requirement is:
Token Request
Lib can place a request against the Token Endpoint (to obtain access_token) adding as an HTTP header a specially prepared DPoP JWT. htm and htu should point to token endpoint method and URL (no fragment, no query)
In case OAUTH2 server supports DPoP, it will reply with
token_type equal to DPoP, otherwise
bearer
Library should store this information (whether DPoP was supported)
Placing a call to Issuer Endpoints
For accessing one of the endpoints of the issuer (that require access_token: issuance, batch, deferred, notification) , library must
generate a new DPoP JWT . htm and htu point to the method and endpoint used
add the DPoP as an HTTP header
Change the way access token is placed as a header. Instead of Authorization bearer <access_token> to `Authorization DPoP '
RFC9449 defines
DPoP JWTas a way to:access_tokenis used by the client (wallet) that requested it, andaccess_tokenThis DPoP (demonstration of Proof of Possession) must not be confused with Proof Of Possession that may be used within the credential request.
The basic requirement is:
Token Request
htmandhtushould point to token endpoint method and URL (no fragment, no query)token_typeequal toDPoP, otherwisebearerPlacing a call to Issuer Endpoints For accessing one of the endpoints of the issuer (that require
access_token: issuance, batch, deferred, notification) , library musthtmandhtupoint to the method and endpoint usedAuthorization bearer <access_token>to `Authorization DPoP