All, Just to recap the discussion.
First thanks all that has provided feedback on this request. I fully understand that there is hesitation to specify a particular key derivation for HMAC signatures. At least at this stage.
It makes sense from the perspective of making SD JWT on pair with mDOC (which does exactly this). I just want to make you aware of current discussions I'm aware of, that places this particular issue pretty high on the choice between mDoc and SD JWT for EUDI wallet. But we haven't seen that last of this yet. I for one would strongly prefer SD JWT, but if I can't get interoperability with regards to key derivation, I fear we will have to go with mDoc.
We have started a discussion with Paul Bastian to advance a version of his draft on this issue. That will be the second best alternative. I like his approach to include header parameters that identifies the key derivation approach. It will provide more generality than our one-way to implement approach. We have provided some suggestions.
I this group would change its mind to include something like this, I'd be all for it, but I guess it is less likely.
Thanks for at least consider this. /Stefan On 2025-05-14 09:26, Neil Madden wrote:
On 13 May 2025, at 12:52, Stefan Santesson <[email protected]> wrote: Hi, We just submitted the following issue on JD JWT GitHub page detailing this request. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/574 Providing the final stage of this document, we would only do this because it is very important, is non breaking and our initial contacts with editors suggests that this could be accepted.I agree with Brian’s points in his other message. I’d also point out that there are some technical issues with the proposal. Most importantly is that it uses the nonce as the salt input to HKDF, but nothing in the spec says where this nonce comes from or how/whether it is authenticated. See section 3.4 of RFC 5869: " In particular, an application needs to make sure that salt values are not chosen or manipulated by an attacker. As an example, consider the case (as in IKE) where the salt is derived from nonces supplied by the parties in a key exchange protocol. Before the protocol can use such salt to derive keys, it needs to make sure that these nonces are authenticated as coming from the legitimate parties rather than selected by the attacker” Generally any kind of challenge value should go in the info not the salt input to HKDF. Secondly, there is no “HKDF” function defined in that RFC, only individual HKDF-Extract and HKDF-Expand functions. — Neil _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
