oauth-selective-disclosure-jwt icon indicating copy to clipboard operation
oauth-selective-disclosure-jwt copied to clipboard

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

Open bc-pi opened this issue 1 year ago • 4 comments

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.

bc-pi avatar Mar 20 '24 21:03 bc-pi

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.

selfissued avatar Mar 21 '24 00:03 selfissued

Yep, this sounds good to me.

bifurcation avatar Mar 21 '24 04:03 bifurcation

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

:+1:

babisRoutis avatar Apr 08 '24 08:04 babisRoutis

maybe leaving the door open to something like cnfs

bc-pi avatar May 15 '24 15:05 bc-pi

I'd be fine with having cnf as the only defined mechanism but leaving the door open for cnfs or similar.

danielfett avatar Jun 04 '24 15:06 danielfett

PR https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/435 aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key

bc-pi avatar Jun 12 '24 15:06 bc-pi