Mahesh Jethanandani has entered the following ballot position for draft-ietf-oauth-sd-jwt-vc-23: No Objection
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-sd-jwt-vc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors for the work since Last Call. Most of the directorate and LC feedback has visibly landed in -20 through -23. Section 2.2.2.3, note on RFC 7800: 494 > Note that Section 3 of [RFC7800] requires that a JWT containing a cnf 495 > claim also contain either the sub or iss claim. This specification 496 > explicitly overrides that requirement, as there are valid and 497 > legitimate uses of key-bound SD-JWT VCs without either of those 498 > claims. I support Mike's DISCUSS. I checked RFC 7800 Section 3, and the text being overridden is a plain MUST: > At least one of > the "sub" and "iss" claims MUST be present in the JWT. RFC 9901 doesn't make this departure, so this document is the first to do it. "Explicitly overrides" a MUST in another Standards Track RFC needs either an Updates: relationship or a rewording that makes it clear this is a profile-specific exception that leaves RFC 7800 alone for everyone else. --- Section 7.1, URL validation: 1824 > Before making a request to any of these URLs, including every 1825 > redirect target as described in Section 3, the Consumer MUST validate 1826 > the URL to ensure that it is a valid HTTPS URL and that it does not 1827 > point to resources an issuer cannot access (e.g., resources internal 1828 > to the Consumer). Such resources include, in particular, hosts with 1829 > addresses from the IANA Special-Purpose Address Registries [RFC6890] 1830 > that are not globally reachable (such as loopback, link-local, and 1831 > private-use address ranges) as well as hosts that are only reachable 1832 > from within the Consumer's network. Ionuț Mihalcea asked in his SECDIR review whether this requirement assumes SD-JWT VCs are used only on the open Internet. Brian answered that it isn't meant to preclude other deployments, and the fix was to reword the first sentence to "resources an issuer cannot access". That helps, but the very next sentence still names private-use ranges and hosts reachable only from within the Consumer's network as forbidden, unconditionally. Consider an enterprise or closed-ecosystem deployment where the Issuer, its JWT VC Issuer Metadata and its Type Metadata all live on internal addresses and the Verifiers are internal too. As written, a conforming Consumer can't retrieve any of it. Could the text allow destinations that local policy has explicitly configured as permitted (for example, a configured allow-list of Issuers or hosts), while keeping the default prohibition for everything else? That keeps the SSRF protection and makes the intended flexibility real. --- Section 2.5, Inline X.509 Certificates, and Section 7.3: 854 > * Inline X.509 Certificates: A mechanism to retrieve the Issuer's 855 > public key using the X.509 certificate chain in the SD-JWT header. 856 > When the protected header of the Issuer-signed JWT contains the 857 > x5c parameter (Section 4.1.6 of [RFC7515]), the recipient uses the 858 > public key from the end-entity certificate of the certificates 859 > from that x5c header parameter and validates the X.509 certificate 860 > chain accordingly against a trust anchor permitted for the Issuer 861 > according to policy. In this case, the Issuer of the Verifiable 862 > Digital Credential is the subject of the end-entity certificate. 863 > If the iss claim is also present, there is no requirement that its 864 > value directly correspond to a subject name in the end-entity 865 > certificate. 1862 > When defining ecosystem-specific rules for resolution and 1863 > verification of the public key, as outlined in Section 2.5, it is 1864 > critical that those rules maintain the integrity of the relationship 1865 > between the iss value of the SD-JWT, if present, and the public keys 1866 > of the Issuer. Nas Til raised three points on this section during Last Call, from verifying live EUDI reference credentials that carry both an HTTPS iss and x5c. The -20 change (lines 863-865) settles the first. Two loose ends remain. First, the two sections now pull in different directions. Section 2.5 says iss needn't correspond to the certificate when x5c is used, while Section 7.3 says the relationship between iss and the Issuer's keys is critical to maintain. I'm left unsure what relationship a Verifier is meant to preserve in the x5c case. Relatedly, when a credential triggers both mechanisms (HTTPS iss and x5c), nothing says which applies, beyond "permitted ... according to policy". Nas Til reported that implementations have already reached opposite conclusions here. A sentence saying that the mechanism is selected by Verifier policy per Issuer, and not by what the credential happens to carry, would line Section 2.5 up with the MUST in Section 7.3. Second, "validates the X.509 certificate chain accordingly" doesn't say according to what. RFC 7515 Section 4.1.6 already requires validation per RFC 5280, so citing that here (and saying that the certificates in x5c are never themselves trust anchors) would close Nas Til's third point at little cost. --- Section 5.4 and Section 3, bounding extends chains: 1208 > The extended type MAY itself extend another type. This can be used 1209 > to create a chain or hierarchy of types. The security considerations 1210 > described in Section 7.4 apply in order to avoid problems with 1211 > circular dependencies. 912 > Consumers MUST perform each retrieval in a time-bound and size-bound 913 > manner to prevent resource exhaustion and denial-of-service attacks, Section 3 bounds each retrieval and Section 7.4 catches cycles, but nothing bounds how many retrievals a single credential can trigger. A non-circular extends chain of arbitrary length, each document small and fast, together with the logos, background images and SVG templates referenced at each level, passes both checks. I'd suggest that Consumers limit the depth of an extends chain (and perhaps the total number of retrievals per credential) and treat exceeding it as a Type Metadata processing failure. --- Operational considerations: The document introduces discovery endpoints, remote metadata and caching behaviour that operators will have to run, but it has no Operational Considerations section. draft-ietf-opsawg-rfc5706bis (still a WG document) recommends one placed before Security Considerations. Much of the material already exists. Section 3, Section 5.3.4 and Section 7.5 cover retrieval, caching and offline use. The authors may want to gather those there, together with a word on Issuer key rotation as seen through cached JWT VC Issuer Metadata (how a freshness lifetime interacts with rollover, and what a Verifier does when metadata is unreachable). Entirely at the authors' discretion. --- Section 10.1, Status List reference, and the shepherd writeup: 2161 > [I-D.ietf-oauth-status-list] 2162 > Looker, T., Bastian, P., and C. Bormann, "Token Status 2163 > List (TSL)", Work in Progress, Internet-Draft, draft-ietf- 2164 > oauth-status-list-21, 21 June 2026, The shepherd writeup was written for -16 and still answers questions 17 and 18 as if there were no normative references to I-Ds. It also predates the aka_vcts claim registration (-18), the new HTTP retrieval section (-19) and the post-LC changes. A refresh of the shepherd writeup before approval would be desirable. ---------------------------------------------------------------------- NIT ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1.2, paragraph 2: 187 > Selective Disclosure JWT (SD-JWT) [RFC9901] is a specification that Section 1.4 and RFC 9901 itself use "Selectively Disclosable JWT". s/Selective Disclosure JWT (SD-JWT)/Selectively Disclosable JWT (SD-JWT)/ --- Section 1.2, paragraph 5: 206 > key referenced in the cnf claim. What the credential means, that is, 207 > the semantics of its claims, is identified by its type, which is 208 > conveyed in the vct claim Section 2.2.2.1. Type Metadata Section 5 Same missing-parentheses pattern Mike flagged in Section 3. It also appears at line 210 and in Section 2.2.2.2 (line 428). s/vct claim Section 2.2.2.1/vct claim (Section 2.2.2.1)/ s/Type Metadata Section 5/Type Metadata (Section 5)/ --- Section 9.1, vct registration: 2100 > * Claim Description: Verifiable digital Credential Type identifier s/Verifiable digital Credential Type identifier/Verifiable Digital Credential Type identifier/ --- Section 5.1, Figure 17, and Appendix A.2, Figure 30: 1103 > "name":"Betelgeuse Education Credential - Version 42", 2855 > "name": "Betelgeuse Education Credential - First Version", Both are Type Metadata for the same vct (https://betelgeuse.example.com/education_credential/v42), but they differ in name, description and hash. Given that Section 2.2.2.1 says the vct value identifies the version, the examples would read better if they agreed, or if one used a different vct. --- Appendix A.2, note on degrees, item 4: 3056 > 4. The date_awarded property of each degree object is marked as sd: 3057 > always, meaning it can be selectively disclosed. Per Section 5.6.4, always means the Issuer MUST make it selectively disclosable, not merely that it can be. s/meaning it can be selectively disclosed/meaning it is always selectively disclosable/ _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
