Thanks for the review Roman. In hopes of expediting discussion towards a resolution to the blocking comments, similar to how I responded to Orie, I'm going to reply separately to the DISCUSS here first. That's inline below.
On Tue, May 20, 2025 at 11:50 AM Roman Danyliw via Datatracker < [email protected]> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-oauth-selective-disclosure-jwt-19: Discuss > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 4.2.1 > 1. A salt value. MUST be a string. See Section 9.3 for security > considerations. It is RECOMMENDED to base64url-encode a > minimum of 128 bits of cryptographically secure random data, > producing a string. > > How will a consumer of the SD-JWT know/recognized that a salt value is > base64url encoded as opposed to consuming the salt string value without > preprocessing? > The consumer doesn't need to do any processing or preprocessing of the salt value. That recommendation is for the issuer and just a relatively straightforward way to get a string with sufficient entropy. We've tried to articulate what the salt does and its minimum entropy in that sec 9.3: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-19#name-entropy-of-the-salt. Perhaps changing the language in 4.2.1 that you quoted to something like this would be better? "1. A salt value. MUST be a string. See Section 9.3 for security considerations. One way to produce a value with sufficient entropy is to base64url-encode 128 bits of cryptographically secure random data, producing a string." > ** Section 7.1 > * the Issuer-signed JWT is valid, i.e., it is signed by the Issuer, > the signature is valid, it is not expired, it is not suspended or > revoked, etc., and > > Where are the validation procedures specified? Is that Section 7.2 of > RFC7519? > I’m concerned by the “etc”. > It's a fair concern! The two bullets at the beginning of 7.1 aren't meant to be comprehensive, however, rather just giving a general idea of what needs to happen. The full set of verification steps follows in the numbered list. > ** Section 7.1 > The Holder or the Verifier MUST perform the following (or equivalent) > steps when receiving an SD-JWT to validate the SD-JWT and extract the > payload: > > What does it mean for there to be an “equivalent” step? This list contains > normative behavior? > The intent was that the normative behavior must be followed but to reasonably allow for implementation choices like order of some steps or use of different intermediate data structures than what's implied. Is there a better way to say that? > ** Section 7.1 > Issuer. > 4. Check that the _sd_alg claim value is understood and the hash > algorithm is deemed secure (see Section 4.1.1). > > How is a hash algorithm deemed to be “secure”? Is this a local policy > decision? If so, say so. > Yeah, I think so. We can say as much. > > ** Section 7.1 > 1. Decide which Disclosures to release to the Verifier, obtaining > proper consent if necessary. > > How is “proper consent” obtained? Is this in scope for the document? > It's not really in scope for the document because it's likely some UI of the holder application. But it'll likely/maybe be a common part of deciding which Disclosures to release to the Verifier. I dunno, I'm having a hard time defending/explaining the language being there. But also don't know that it hurts anything. Do you think a change is needed here? ** Section 9.1 > Any of the JWS asymmetric digital signature > algorithms registered in [IANA.JWS.Algorithms] that meet the security > requirements described in the last paragraph of Section 5.2 of > [RFC7515] can be used, including post-quantum algorithms, when they > are ready. > > The last paragraph of Section 5.2 of RFC7515 says: > > Finally, note that it is an application decision which algorithms may > be used in a given context. Even if a JWS can be successfully > validated, unless the algorithm(s) used in the JWS are acceptable to > the application, it SHOULD consider the JWS to be invalid. > > -- This text from RFC7515 appears to be saying that the application > decides and > there aren’t any new security requirements. > Hard to disagree with that observation. Do you think some change is needed as a result? That bit in Section 9.1 was mostly (I think) intended to reassure readers that post-quantum algorithms showing up in the alg registry will be usable. > > -- Would “none” from [IANA.JWS.Algorithms] be acceptable? Nope! https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-19#section-4.1-1 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-19#section-7.1-4.2.2.1 forbid "none" explicitly for the Issuer-signed JWT (and there are similar for the KB-JWT). -- _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]
