PoP attestation binding

[peppelinux]

Even if remote, there is the possibility that an implementation re-uses the same cryptographic keys for different scopes.

the PoP JWT could be used with the same cryptograhic key attested in more than a single attestation and therefore be replicated for different endpoints/audience

What do you think about getting the ath claim inside the DPoP token as requested?

In this way, a DPoP token cannot be replicated when the key that proves possession is the same within different attestations.

Even if DPoP specs defines ath in relation to an access token, may we consider that any kind of JWT could represent an access token, in relation of its scope, the flow where it is used and its usage in general?

Then, could we provide a binding of the PoP to a specific attestation where the possession aims to be proved?

[peppelinux]

For better clarity

an aud is not enough where a pop is used on a different attestation that has in common the same key used for the signature of another attestation

it's an implementation risk where an implementer would use the same key for different attestations

once you have one, you can replay the same PoP for another/different attestation that has in common the same key
hash of the attestation is then required, WDYT?

[Sh-Amir]

Even if remote, there is the possibility that an implementation re-uses the same cryptographic keys for different scopes.

the PoP JWT could be used with the same cryptograhic key attested in more than a single attestation and therefore be replicated for different endpoints/audience

What do you think about getting the ath claim inside the DPoP token as requested?

In this way, a DPoP token cannot be replicated when the key that proves possession is the same within different attestations.

Even if DPoP specs defines ath in relation to an access token, may we consider that any kind of JWT could represent an access token, in relation of its scope, the flow where it is used and its usage in general?

Then, could we provide a binding of the PoP to a specific attestation where the possession aims to be proved?

I can see the benefits of binding the wallet instance attestations to the specific proof to avoid the possibility that it could be swapped in the case that the same cryptography keys are used by the implementers. I agree that the usage of a similar countermeasure like ath that is defined in the DPoP specification can work here as a mitigation. However, it would be better to introduce a new claim for this to be included in PoP as ath meant for the Access Token, and here as we deal with Wallet Instance Attestation maybe we can use the following claim wiah?

[paulbastian]

Do you propose a new claim in the Client Attestation PoP JWT thats value is the hash of the corresponding Client Attestation JWT?

[Sh-Amir]

Do you propose a new claim in the Client Attestation PoP JWT thats value is the hash of the corresponding Client Attestation JWT?

Yes Paul. That is the idea.

[paulbastian]

We will explore this, but initially it does not seem like a bad idea

[tplooker]

Noting the direction of #146 which is trying to align the Client Attestation PoP to the DPoP proof, this would re-introduce some inconsistency in the PoP's which may not be worthwhile. While I understand the proposal I'm unsure whether this protection actually provides any material security benefit.