why isn't cnf the only way to bind to a holder public key?

[bc-pi]

Right after the IETF 119 OAuth session yesterday in a talk with @selfissued and @ve7jtb that started with discussion of PR #394, the question again came up (with some surprise on their part) as to why the cnf claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here.

It seems that using the cnf claim exclusively would be more straightforward and much better for interop.

@bifurcation has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say cnf? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop."

Using the cnf claim exclusively could also help with some clarity in the security considerations where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.".

Note this is related to but separate from the question of if the presence of a cnf claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The cnf claim can be made the way to do holder binding while still leaving that up to verifier policy.

[selfissued]

I support defining cnf as the way to do holder binding.

I'll note that cnf is extensible via a registry, so should the existing cnf parameters not work for a use case, a new one can be defined and used.

[bifurcation]

Yep, this sounds good to me.

[babisRoutis]

It seems that using the cnf claim exclusively would be more straightforward and much better for interop.

👍

[bc-pi]

maybe leaving the door open to something like cnfs