Note that Paul's draft for something like this at the JWS algorithm layer is likely to be discussed at the JOSE session of the upcoming meeting https://mailarchive.ietf.org/arch/msg/jose/nBxAALrHMYE7Lgyq1dHoGx7RaHw/
On Sun, May 25, 2025 at 3:15 PM Stefan Santesson <[email protected]> wrote: > 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] > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
