Thank you for the review and ballot position, Charles. We are working through Mike's DISCUSS at https://mailarchive.ietf .org/arch/msg/oauth/hSDZBQ75YQ4MiQdZcYXAxauEQOs/ and nearing resolution. I just did this PR https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/453 on the overeager BCP 14 keyword use. I do think alphanumeric is probably specific enough in the given context.
On Wed, Nov 4, 2026 at 2:28 PM Charles Eckel via Datatracker < [email protected]> wrote: > Charles Eckel 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: > ---------------------------------------------------------------------- > > # Charles Eckel, ART AD, IESG ballot: draft-ietf-oauth-sd-jwt-vc-23 > CC @eckelcu > > * line numbers: > - > > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-23.txt&submitcheck=True > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > * "Handling Ballot Positions": > - > https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > Thanks to Hannes Tschofenig for the Shepherd writeup, and to Christian > Amsüss > for the ARTART review. Thanks also to the authors for addressing his > comments. > > I support Mike Bishop's DISCUSS on the RFC 7800 sub/iss override. > > ## Comments > > ### BCP 14 keyword in Sections 2.2 and 2.2.2.5 > > ``` > 278 Note that in some cases, an SD-JWT VC MAY have no selectively > 279 disclosable claims, and therefore the encoded SD-JWT will not > contain > 280 any Disclosures. > ``` > > It does not seem like normative language was intended here. Consider using > lowercase instead: > > s/an SD-JWT VC MAY have/an SD-JWT VC can have > > ``` > 518 An SD-JWT VC MAY have no selectively disclosable claims. In > that > 519 case, the SD-JWT VC MUST NOT contain the _sd claim in the JWT > body. > 520 It also MUST NOT have any Disclosures. > ``` > > The same applies to the first sentence of Section 2.2.2.5, and the MUST > NOTs > that follow state the actual requirement. > > s/An SD-JWT VC MAY have/An SD-JWT VC can have > > ### BCP 14 keywords in Section 5.3.3 > > ``` > 1185 Ecosystems MAY define additional methods for retrieving Type > 1186 Metadata. For example, a standardization body or a community > MAY > 1187 define a service which has to be used to retrieve Type Metadata > based > 1188 on a URN in the vct claim. > ``` > > These MAYs apply to parties writing specifications rather than to protocol > participants. Consider using lowercase instead: > > s/Ecosystems MAY define/Ecosystems can define/ > s/a community MAY define/a community can define/ > > ### Character set for svg_id > > ``` > 1436 * svg_id: A string defining the ID of the claim for reference > in the > 1437 SVG template, as described in Section 5.5.1.2.2. The ID > MUST be > 1438 unique within the type metadata. It MUST consist of only > 1439 alphanumeric characters and underscores and MUST NOT start > with a > 1440 digit. It MUST NOT be used in a claim metadata object whose > path > 1441 contains a null component, since such a path can select more > than > 1442 one value. This property is OPTIONAL. > ``` > > Is alphanumeric specific enough? Perhaps better to replace with something > like > the following: > > "It MUST consist only of the ASCII characters A-Z, a-z, 0-9, and underscore > ("_"), and MUST NOT start with a digit." > > It might also be helpful to state whether it is compared case-sensitively > or > not. > > > > -- _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]
