HMAC Issuer-signed JWT and/or KB-JWT

[Sakurann]

[filing on behalf, not my issue] A request has been received via work in ISO to enable an option to HMAC KB JWT to enable non-repudiation.

[bc-pi]

My understanding is that it's not about non-repudiation but rather that it enables some degree of repudiation b/c the HMAC key is known to both parties (likely resulting from an ECDH exchange at the "protocol" layer requesting/presenting the credential). There have been some other claims of privacy benefits too but I'd be lying if I said I understood them.

[bc-pi]

A potential variation on this issue (and maybe common point of misunderstanding/confusion in general) would instead be to allow for the Issuer-signed JWT to be HMAC'd. It's been discussed a few times I think but came up again with Neil Madden being supportive of the idea in this ML thread https://mailarchive.ietf.org/arch/msg/oauth/rPitG7FvJcVEyIcAwn0bXzGToGM/ that I've copied relevant parts from:

[Neil] The draft repeatedly says that a symmetric signature algorithm (MAC) must not be used. Perhaps I’m missing something here, but why not? It doesn’t seem like it compromises any of the intended security properties. Use of a symmetric MAC may also limit the privacy impacts on users as it provides some measure of deniability (similar to that mentioned in section 12.1), as any Verifier in possession of the secret key could also have produced any claims that are subsequently leaked, allowing the user to deny that they were produced by the supposed Issuer. (This deniability property holds even without subsequent leaking of old signing keys).

[Brian] The thinking behind that was basically that this Issuer-Holder-Verifier model implies/assumes that an Issuer issues a token with no idea of where it’ll be presented and having a shared symmetric key seemed really weird in that situation. Also hard to explain why or how a shared symmetric key would work in that situation too. That said, there’s been some talk about loosening that restriction - largely around the same reasoning on deniability that you cite - I guess your comment here should be taken as supportive of that prospective change?

[Neil] Yes.

[Sakurann]

closing this because confirmed that what is potentially needed is HMACing issuer-signed credential and not KB JWT.

[bc-pi]

reopening to have some tracking of the potential variation on this issue of having the Issuer-signed JWT to be HMAC'd

[bc-pi]

Closing this as it is effectively a duplicate of #369