[siopv2] `cnf` instead of `sub_jwk`?

[Kristina Yasuda]

I was pointed out it would be a good idea to converge around cnf claim defined in RFC 7800 - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) (ietf.org) instead of sub_jwk.

[David Waite]

Since the subject is also the issuer, and since there is no separate proof of possession, wouldn’t it make sense to use the jwk protected header field?

[Giuseppe De Marco]

cnf Is correct but is not immediate to the human comprehension. sub_jwk Is a speaking word, It has a very good sematic.

[Vladimir Dzhuvinov]

David made a good point.

https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.3

"jwk" (JSON Web Key) Header Parameter

The "jwk" (JSON Web Key) Header Parameter is the public key that
corresponds to the key used to digitally sign the JWS. This key is
represented as a JSON Web Key [JWK]. Use of this Header Parameter is
OPTIONAL.

The signing key is not technically a JWT claim, like the other claims that go into the ID token, so let’s place it in the JWT header where we can use a standard parameter for it.

DPoP uses the jwk header in exactly the same way:

https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-08.html#section-4.2

‌

[Michael Jones]

I agree with DW’s points. As much as I love RFC 7800 , this key isn’t a PoP confirmation key - it’s just the signing key. I’d be fine leaving it as the sub_jwk claim or using the jwk header parameter. Unless it’s for a confirmation key, let’s not use cnf.