Thanks Hannes, I really appreciate the feedback and work towards moving this one foreword in the process.
I've prepared this pull request https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552 with updates aimed at addressing the review comments. Please take a look and let us know if anything is amiss. I hope to review with my co-authors soon and then integrate the changes and publish a -16 draft that incorporates the updates. Inline below are more specific responses to the comments and links to associated changes in the PR. On Tue, Feb 11, 2025 at 1:59 AM Hannes Tschofenig < hannes.tschofe...@h-brs.de> wrote: > Hi Daniel, Kristina, Brian, > > here are a few review comments that are easy to address: > > 1. Complete the IANA registry section for the media type registrations. > Search for TBD in that section. As you make this change you might also > want to remove the RFC 2119 language from the description fields. I do > not believe it is the right place to put normative language. > Indeed, I "borrowed" that language verbatim from the RFC7515 application/jose+json <https://www.iana.org/assignments/media-types/application/jose+json> registration because, well, the encoding considerations are exactly the same and I figured if it was good enough for the general JWS JSON Serialization of RFC7515 it was good enough for the JWS JSON Serialization of SD-JWT. But I agree with you that it is not really the right place to put normative language. I'll change that and flesh out the TBDs too. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/f8f8a0e6a96ccdceedd30b35900c967c1a8b2a8d > 2. Normative Reference: I think you need to move RFC 8725, RFC5234, and > RFC6838 from the informative reference section to the normative section > since they are needed for the specification. RFC 8725 is probably a > reference we can argue about but the others seem to be pretty clear cases. > The only use of RFC5234 follows the qualification of, "As an alternative illustration of the SD-JWT format," so I can't see how, as an alternative, that could be considered normative. I'll switch the other two though. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/f8f8a0e6a96ccdceedd30b35900c967c1a8b2a8d > > 3. Minor nits: > > In the introduction you write: "instead, a hash digest of the data takes > its place.". Since the digest is computed using a hash, it would be > better to just say "digest" instead of "hash digest". This would also be > consistent with the rest of the document. > Yep. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/7a680be357b221af4aa57e5bb5e447a03b4e4074 > > In Section 4.1, you write: "The payload MUST NOT contain the reserved > claims _sd or ... except for the purpose of transporting digests as > described below.". The term "reserved claim" only appears once in the > document and it is not clear to me whether the "..." refers to the claim > with the name "..." or whether you are referring to the claims that this > document defines. The exception also appears misleading since you > defined the claims for conveying digests. The reference to "below" in > this sentence is not helping since I do not really know where to look at. > Fair point. I've endeavored to improve that sentence with that feedback in consideration. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/51689807ad0cf73cdc54e92aba82cfc7dbd37219 > > In Section 4.2.1, you write: "The claim value, as it would be used in a > regular JWT payload. The value MAY be of any type that is allowed in > JSON, including numbers, strings, booleans, arrays, null, and objects.". > I believe you should write "The value MUST be of a type that is allowed > in JSON....". The sentence appears more than once in the document. > That's an interesting observation. I think avoidance of normative key words there altogether would be better and more appropriate. We are just saying that it's JSON and thus can be any JSON thing. No need to say anything more prescriptive. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/599dc15c188d52bb620ee1f1e166d7deb77512f8 > > In Section 9.1 you write: "The Issuer-signed JWT MUST be signed by the > Issuer to protect integrity of the issued claims.". I would remove the > first "Issuer-signed" qualification to improve the readability of the > sentence. > Readability thusly improved. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/39b2d2ec2b8c3103f3346a39be8466620766468b > > In Section 9.4, you write: "In the terminology of cryptographic > commitment schemes, the hash function MUST be computationally hiding.". > Since you mention the terminology, I expected a reference to the term, > especially given the use of RFC 2119 language. > This was language suggested by Neil, if I recall correctly, who is more fluent with the terminology of cryptographic commitment schemes. I wasn't able to find an easily referenceable definition for the term, even with the 'help' of chatgpt and gemini, and I think the intent of the text is to be explanatory (it expands on prior text in the paragraph) so I think dropping the normative RFC 2119 MUST here is appropriate. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/fbd9026fcad7b34614ba5f481cd6d06ab3dc330f > > Section 9.8 is called "Issuer Signature Key Distribution and Rotation". > It should instead be called "Issuer Signature Verification Key > Distribution" since you are not planning to distribute the signature key > of the issuer itself since it is the private key. > Makes sense. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/cba9307d416b14be726396145e8f8c4aef75bece > > In Section 10.1, you write "The following types of unlinkability are > considered here:". I would change this to "The following types of > unlinkability are discussed below:" > Okay. https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/552/commits/b7f34b62c126a6976e455d2818ec0e9ca6bc8b39 > > I noticed the absence of a mention regarding the use of digital > signatures in Verifier/Verifier unlinkability. If a holder uses SD-JWTs > with different Verifiers, these SD-JWTs are linkable based on the > signature value, unless each SD-JWT is signed by the Issuer > individually. The signature value itself as a correlateable value is kind of implied in the section - especially https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-15#section-10.1-6 with "Issuer's signature is directly presented" and the disscusion around https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-15#section-10.1-9 on batch issuence that say new key binding keys and salts must be used for each directly implies that a distinct signature would be on each. Do you think signatures themselves need to be more explicitly mentioned? If so, do you have any suggestions for text? > Batch issuance is suggested as a solution when the Holder > does not request SD-JWTs individually- either proactively or in > real-time. Proactively requesting SD-JWTs works in cases where the > holder knows in advance what disclosures the Verifier will ask for. > However, if there are many possible combinations, this approach may > become practically challenging. If the holder switches to a real-time > request pattern with the Issuer, the SD-JWT solution may become less > useful since the Holder can just ask the Issuer for a regular JWT that > only contains the claims it wants to disclose to the Verifier. Do the > existing media types support returning multiple SD-JWTs and multiple > SD-JWT+KBs in a batch? > The media types in the draft do not account for batches. While the concept is mentioned in the privacy considerations, the actual details of batch issuance are beyond the scope of this draft, which is defining the format of the single thing. Higher level protocols or applications for credential issuance, such as OpenID for Verifiable Credential Issuance (OpenID4VCI), would be where such things would be defined. And the "application/json" media type will likely be used to return multiple SD-JWTs in one batch (see for example https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-15.html#section-8.3-13). So in a way, yes, existing media types do support it. But regardless it's to be defined elsewhere. And presenting multiple SD-JWT+KBs in a batch would similarly be defined in part of a presentation protocol, such as OpenID for Verifiable Presentations (OpenID4VP). > > In Section 11, you acknowledge Richard Barnes and Martin Thomson. I > suggest removing the "fnord" from Richard "fnord" Barnes and the > paragraph related to Martin Thomson: > > " > Special appreciation is extended to Martin Thomson, who wielded his > considerable intellect and influence to change a single occurrence of > the word "to" to "with" in the midst of a significant proposal that > would be integrated into this document six months later. > " > It has always been my understanding, from https://www.rfc-editor.org/rfc/rfc7322.html#section-4.10 and over 15 years of experience writing and being listed in acknowledgements sections, that the acknowledgements section is an area for the document authors to thank people and things which they felt were helpful in producing the document. And that whom to thank and how to thank them were largely at the discretion of the authors. The unique treatment for Richard Barnes and Martin Thomson (both of whom I highly respect) in the Acknowledgements section of this draft is absolutely intentional and factually grounded in the actual contributions they made. > > I would also acknowledge Denis, even though his feedback was not > incorporated into the document. He certainly reviewed the document. > He certainly did. Based on my prior comment above about the content of the acknowledgements section being largely at the discretion of the authors, I trust you understand why Denis is not listed. > In the body of the document, you mention "credential" several times. It > might be helpful to clarify in the terminology section that this term is > a synonym for SD-JWT and SD-JWT+KB. I went looking to add something along those lines but noticed that the word "credential" doesn't appear in the document until section 9 and its use thereafter seems sufficiently understandable without any qualification or introduction of terminology. > In the appendix the term Verifiable > Credential is used a few times but in the body of the document you just > use the term "credential". I believe that "credential" and "Verifiable > Credential" are used interchangeably. > The places where the capital V and C are used are more specific and about the W3C Verifiable Credentials Data Model v2.0 and IETF's SD-JWT-based Verifiable Credentials. They are accompanied by references to the respective work. > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > -- _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 -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
