Roman Danyliw has entered the following ballot position for draft-ietf-oauth-selective-disclosure-jwt-19: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ ---------------------------------------------------------------------- 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? ** 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”. ** 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? ** 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. ** 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? ** 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. -- Would “none” from [IANA.JWS.Algorithms] be acceptable? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Thomas Fossati for the GENART review. ** Section 1. Editorial. This specification defines such a mechanism for JSON payloads of JSON Web Signatures, with a primary use case being JWTs. ... SD-JWT is based on an approach called "salted hashes": There was an abrupt transition where the text should introduce that this is specification is SD-JWT, and SD should be expanded. NEW (proposed) This specification, Selective Disclosure for JSON Web Tokens (SD-JWT), defines such a mechanism for JSON payloads of JSON Web Signatures, with a primary use case being JWTs. ** Section 4. As an alternative illustration of the SD-JWT format, ABNF [RFC5234] for the SD-JWT, SD-JWT+KB, and various constituent parts is provided here (for those who celebrate): What does the phrase “(for those who celebrate)” mean? Is that humor about the formal syntax of ABNF? If so, please remove it. ** Section 7.3 2. Ensure that a signing algorithm was used that was deemed secure for the application Is this a local policy decision? If so, say so. ** Section 9.4 Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed fundamental weaknesses and MUST NOT be used. Good advice, but why? These hashes are not registered in [IANA.Hash.Algorithms]. ** Section 9.7 The exact list of such content will depend on the application and SHOULD be listed by any application-specific profiles of SD-JWT. What is the use case for a SD-JWT profile to omit which claims would be needed to verify authenticity or validating? ** Section 10.5 For example, if the National Cancer Institute only issued SD-JWTs with cancer registry information, it is possible to deduce that the Holder owning its SD-JWT is a cancer patient. Don’t call out the “National Cancer Institute” (or any proper noun) specifically in an example. Please make this example more generic. _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
