Does the ID Token itself constitute a Proof of Possession (PoP)?

[EthanHeilman]

1. the `dpop_jkt` parameter in the OpenID Connect Authentication Request
2. the `DPoP` header in the Token Request to the `token_endpoint`
3. the `cnf` claim containing the public key in the returned ID Token

In step 3 is the Token_Endpoint checking that the DPoP header verifies under public key specified by dpop_jkt? This seems like it would prevent rogue key attacks because the very fact that the user has an ID Token with the cnf value proves it has DPoP of the signing key. Am I reading this correctly?

What does the RP sign? In OpenPubkey we have the RP sign the ID Token itself after issuance, but that adds a second signature to the ID Token.

Is there any value in having the RP sign the claims of the ID Token so that it can ensure that the ID Token it is binding the JWK to contains the identity it expects?

Is there a missing step here?

+------+                              +------+
|      |-- Authentication Request --->|      |
|  RP  |   (1) dpop_jkt parameter     |  OP  | 
|      |                              |      | 
|      |<- (2) nonce -----------------|      |
|      |                              |      | 
|      |-- Token Request ------------>|      |
|      |   (3) DPoP header            |      |
|      |                              |      |
|      |<-- Token Response -----------|      |
|      |   (4) cnf claim containing   |      |
|      |   the public key in ID Token |      | 
+------+                              +------+

[EthanHeilman]

Use the auth code as the value (nonce) which is signed in DPoP header?

[dickhardt]

let's keep this open for now so we remember to check with DPoP people about use of code in DPoP token

[dickhardt]

Use of the ID Token and what is signed is out of scope I think. Each protocol where it might be used will have its own mechanisms.

I do think in Security Considerations we should call out the cnf claim should only be used to bind a signed object with the other claims in the id_token. The cnf claim should not be used as proof the user controls the key identified by cnf

[EthanHeilman]

I do think in Security Considerations we should call out the cnf claim should only be used to bind a signed object with the other claims in the id_token. The cnf claim should not be used as proof the user controls the key identified by cnf.

Not opposed to this change, I think it makes sense to not make that assumption.

What are the circumstances were it would it not be the user? Are you saying that the cnf claim is a proof that someone the user delegated control of the token to could control the key identified by the cnf?

[dickhardt]

What are the circumstances were it would it not be the user? Are you saying that the cnf claim is a proof that someone the user delegated control of the token to could control the key identified by the cnf?

I don't understand.

I was building on a comment you made a long time ago that the ID Token should not be used as a bearer token, or proof that the user has that key.

[EthanHeilman]

@dickhardt I completely misunderstood you. I thought you were saying doing a Proof of Possession with the public key in the cnf is not proof the user holds the key, but rather proof that whoever holds the key is either the user or someone the user has delegated the responsibility of signing to.

I do think in Security Considerations we should call out the cnf claim should only be used to bind a signed object with the other claims in the id_token. The cnf claim should not be used as proof the user controls the key identified by cnf

I can add this

[EthanHeilman]

Added as #4