!!! Overview
[{$pagename}] ([DPoP]), an [Internet Draft], defines a relatively simple [application]-level mechanism for sender-constraining [OAuth] [access|Access_token] and [refreshtokens.|Refresh_token] 


It enables a client to demonstrate proof-of-possession of a [public|Public Key]/[Private Key] pair by including the "[DPoP]" [header|HTTP Request Header] in an [HTTP Request].
Using that header, an [Authorization Server] is able to [bind|Binding] issued tokens to the [public|Public Key] part of the client's key pair.  Recipients of such tokens are then able to verify the [binding] of the [token] to the key pair that the client has demonstrated that it holds via the "[DPoP]" header, thereby providing some [assurance|Assurance Level] that the client presenting the token also possesses the [Private Key].  In other words, the legitimate presenter of the token is constrained to be the sender that holds and can prove possession of the private part of the key pair.

[{$pagename}] achieves [Proof-of-Possession] ([PoP]) by [Binding] the [tokens] to a [Public Key]-[Private Key] pair.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer|https://tools.ietf.org/html/draft-fett-oauth-dpop-04|target='_blank'] (Expired)- based on information obtained 2019-05-02
* [#2] - [OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)|https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop|target='_blank'] - based on information obtained 2020-05-02