DPoP to prevent sharing tokens between devices

[GwenSynamedia]

Token sharing is used at industry scale by professional pirates to provide access to licensed content. It is somewhat the equivalent for CDNs to ECM sharing for Conditional Access Systems or password sharing for subscription-based services. This use case seems to be addressed in Section §3.5 of the current CAT spec and seems to be covered by the claim cattpk of the document §4.5.xx.

While this claim supports mTLS, it does not accommodate for the emerging DPoP mechanism whereas the latter has been designed to address an number of the shortcomings of mTLS

1. mTLS cannot be supported by browser based applications, (e.g. as used in popular SmartTV clients)
2. Being at the application-layer, the DPoP mechanism also benefits native applications running on general purpose devices – reducing dependency on TLS stack implementation in devices, and alleviating any privacy issues that might arise (of which application can access what client certificate)
3. On the CDN/Server side, DPoP decouples L4/L5 processing from HTTP/L7 processing, allowing for distributed architectures where client-facing TLS termination is done by a component other than the one handling L7 processing.
4. DPoP provides the receiver with the power to decide which anti-replay mechanism to enforce – e.g., one-use-only (jti based), time-window based (where the receiver can decide on the time window to use).

Looking at the discussion history of the group, I can see that DPoP has been presented/examined by Akamai in November 2021. At the time, DPoP seems to have been put aside due to a lack of maturity of the spec. DPoP draft is now at version 10 and has passed the working group review, as well as document shepherd’s review. It is therefore likely to be relatively stable and to become soon an official RFC.

Based on these updated elements, would it be possible to reconsider the inclusion of DPoP in the common access token specification?

Reference documents
mTLS: https://datatracker.ietf.org/doc/html/rfc8705
DPoP: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-10

[GwenSynamedia]

Proposal wording for the CAT claims

Claim to add

catdpop
This claim shall include DPoP validation information & configuration subclaims, which the receiver MUST use to validate the token against a DPoP JWT in the DPoP request header as defined in draft-ietf-oauth-dpop-10.
If the Receiver generates a Session token which the sender is to use for subsequent access, then that session token MUST include the catdpop claim copied from the Access token.

The catdpop claim shall include the following nested claims:

Mandatory Sub claim:

jkt: JWK SHA-256 Thumbprint Confirmation Method. The value of the jkt member MUST be the base64url encoding (as defined in RFC7515 of the DPoP public key (in JWK format) to which the access token is bound.

The Receiver shall reject requests for which the jkt claim does not match the jkt computed from the DPoP token’s public key, as defined in draft-ietf-oauth-dpop-10/section4.3.

Optional Sub Claims

These claims control the Receiver validation logic, providing the access token issuer with control over DPoP validation logic.

vjti: A numeric value controlling Receiver validation of the jti claim in the DPoP token per draft-ietf-oauth-dpop-10/section4.3:
0: jti claim in the DPoP token shall be ignored by the receiver. This shall be the default Receiver behaviour if vjti is not provided.
1: jti claim in the DPoP token shall be compared by the Receiver against previously received jti values (within a receiver controlled time window & URL space). If the same DPoP jti has been received, the Receiver shall reject the request.

vtd: The maximum allowed time difference, in seconds, difference between the DPoP token’s iat and the Receiver’s notion of current time.
If not provided, the Receiver shall use its pre-configured value for vtd.
The Receiver shall reject a request if abs(now – DPoP.iat) > vtd

vath: A numeric value controlling Receiver validation of the ath claim in the DPoP token, as defined in draft-ietf-oauth-dpop-10/section4.3. In the following, the hash of the access or session token shall be computed by the receiver as defined in draft-ietf-oauth-dpop-10/section 4.2/ath.
0: ath claim in the DPoP token shall be ignored by the receiver. This shall be the default Receiver behavior if vath claim is not provided.
1: ath claim in the DPoP token shall be validated against the hash of the access token, but shall be ignored in requests that include a subsequent session token.
2: ath claim in the DPoP token shall be validated against the hash of the access token if exists, and against the hash of a session token if an access token does not exist.
Failed validation of the vath claim shall cause the Receiver to reject the request.

[GwenSynamedia]

Example
The following is an example of the catdpop claim. For clarity, the example is presented in JSON format.

"catdpop": {
            "jkt":"boxkEfrVy4Z3wg48dLE6HtdOVAEUxyrvGv4BIddLwwc"
            "vjti":0
            "vtd":10
            "vath":1
}

The Receiver in this example shall reject the request if any of the following conditions occur:

• The access token is invalid (for any reason not pertaining to the catdpop claim
• The DPoP header is missing or malformed
• The DPoP JWT htu claim does not match the URI of the request as defined in draft-ietf-oauth-dpop-10/section4.3.
• The DPoP JWT htm claim does not match the request method as defined in draft-ietf-oauth-dpop-10/section4.3.
• JKT of the DPoP Public Key in the DPoP token sent with the request is not equal to boxkEfrVy4Z3wg48dLE6HtdOVAEUxyrvGv4BIddLwwc
• The time difference between the Receiver’s time and the iat value of the DPoP token is greater than 10 seconds
• If the request includes an Access token – the hash of the access token computed as defined in draft-ietf-oauth-dpop-10/section 4.2/ath, matches the value of the DPoP ath claim. If the request includes only a session token, then the ath claim shall be ignored.
• The DPoP JWT signature is invalid, as defined in draft-ietf-oauth-dpop-10/section4.3.

[GwenSynamedia]

Previous DPoP discussion in CTA WAVE CAT
Nov.1st meeting minutes: https://standards.cta.tech/apps/org/workgroup/cat/download.php?document_id=34102
Presentation mTLS vs. DPoP: https://standards.cta.tech/apps/org/workgroup/cat/download.php/34039/DPoP%20vs%20mTLS.pdf