Selective Disclosure for JWTs (SD-JWT)
draft-ietf-oauth-selective-disclosure-jwt-22

I have read this from a transport protocol perspective and have no objection to publication.

Thank you for your work on this document. It looks solid; my comments below are intended to improve the document and can be incorporated at the discretion of the authors and the responsible AD.

As others have noted, introduce the term SD-JWT in the Introduction and fully expand it in the title of the document. It also feels slightly strange that the title of the document is only one of the two primary formats defined within it. Is there a title that would encompass both?

SD-JWT and KB-JWT probably don't need definitions in the Terminology section, as they've already been introduced in 1.1 and the entire document is their definition.

Section 3:
- "For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send Disclosures or reveal the salt values in any other way." This isn't a normative requirement, it's a statement of what this specification enabled. For data that the Holder does not want to reveal to the Verifier, it can withhold the associated Disclosure and the Verifier will not be able to recover the content from the JWT.
- Remove "(for those who celebrate)"

Section 4.1: The payload here is specifically a JWT, not just a "JSON structure" or "JSON object", no? Use that more specific term, if so.

Hi Daniel, Kristina, and Brian, 

Thank you for the effort put into this specification. The theory of operation is well-explained with clear role and adequate cross references to link the various actions. 

Thanks to Tiru Reddy for the OPSDIR review. I'm echoing below two main points, but I trust the authors will follow-up with Tiru for all the points he raised.

# Error reporting and troubleshooting 

In environments with multiple parties involved (e.g., issuer, holder, verifier), failures may be hard to identify. It would be useful to describe how error reporting and troubleshooting can be handled in a privacy-preserving way.

# Computation overhead

Consider including discussion on the computational and network overhead associated with SD-JWT. 

# Nits

Please find below some very minor nits: 

# Please expand “JWTs” in the title.

# get rid of “often” in the introduction

s/is often secured/can be secured
s/is often used/is used

# The discussion about RPs was confusing to me as I didn’t find any such mention in RFC7515/7519, but finally find it in OpenID.Core. Also, it wasn’t clear to me at that point how this relates the Issuer/Holder/Verifier roles defined in the specification.

Cheers,
Med

Thanks for addressing my discuss and comments in -20.

Thank you to Thomas Fossati for the GENART review.

Thanks for addressing my DISCUSS and COMMENT feedback with -20.  Below is additional recommendations based on the DISCUSS feedback: 

** Section 7.1
   1.  Decide which Disclosures to release to the Verifier, obtaining
       consent if necessary.

Thanks for revising this text in -20.  I would recommend making it clear that the means to get this “consent” is out of scope for this 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.

[on -19] -- This text from RFC7515 appears to be saying that the application decides and
there aren’t any new security requirements.

[response] 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. 

[on -20] No comment on the phrase “… including post-quantum algorithms, when they are ready”.  I’m reacting to the reference to RFC7515, as it seems misleading to me.  Practically, it doesn’t impost any requirements, so why mention it?  Would this be clearer:

NEW (roughly)
Per the last paragraph of Section 5.2 of [RFC7515], it is an application-specific decision to choose the appropriate JWS digital signature algorithm from [IANA.JWS.Algorithms].