Closed bc-pi closed 3 weeks ago
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.
Yep, this sounds good to me.
It seems that using the
cnf
claim exclusively would be more straightforward and much better for interop.
:+1:
maybe leaving the door open to something like cnfs
I'd be fine with having cnf
as the only defined mechanism but leaving the door open for cnfs
or similar.
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
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. Thecnf
claim can be made the way to do holder binding while still leaving that up to verifier policy.