Code change:
<del> Selective Disclosure JWS (SD-JWS) </del> <ins> Selective Disclosure JWT (SD-JWT) </ins> draft-fett-selective-disclosure-jwt-00 Abstract <del> This document specifies conventions for creating JSON Web Signature (JWS) documents that support selective disclosure of claim values. </del> <ins> This document specifies conventions for creating JSON Web Token (JWT) documents that support selective disclosure of JWT claim values. </ins> 1. <del> The JSON-based content of JSON Web Signatures (JWS) as defined in RFC7515 is secured against modification using digital signatures.  A consumer of a JWS document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving a JWS document can read all contents of the document. For example, a common use case is that the signed document represents a user's identity credential, created by an issuer.  The issuer includes the user's public key or a reference thereto.  To proof their identity to a verifier, the user can then send the issuer- signed credential plus a signature over some transaction-specific values, the so-called proof.  It is signed using the user's private key.  This demonstrates possession of the private key, and by extension, the identity of the user. The problem is, that using this approach, the user has to release the full issuer-signed credential to the verifier.  The credential is often created once and can then be used for many transactions.  Thus, it is in the user's interest that the credential creates many user attributes which can be disclosed selectively to verifiers. This document describes a format for JWS documents that support selective disclosure (SD-JWS) including a format for proofs. It is important to note that while user identity credentials of natural persons are common use cases, the mechanisms defined in this document can be used for any other use case as well. </del> <ins> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. This document describes a format for JWT that supports selective disclosure (SD-JWT) which would enable sharing only subset of the claims included in the original JWT instead of releasing all the claims to every Verifeir.  This document also defines an optional format for signatures called releases (SD-JWT-R). One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such use case, there has been no privacy-related concerns with existing JOSE signature schemes, because when a signed JWT is one-time use, it contains only JWT claims that the user has consented in real time to release to the Verifier.  However, when a signed JWT is intended to be multi-use, the ability to selectively disclose a subset of the claims depending on the verifier becomes crucial to ensure minimum disclosure and prevent Verifier from obtaining claims irrelevant for the use case at hand. One example of such multi-use JWT is a verifiable credential, or a tamper-evident credential with a cryptographically verifiable authorship that contains claims about a subject. SD-JWT defined in this document enables such selective disclosure of claims. In a common use case, such JWT includes claims describing natural persons, the mechanisms defined in this document can be used for any other use cases as well. It is also important to note that this format enables selective disclosure of claims, but in itself it does not achieve unlinkability of the subject of a JWS document. Note: so far agreed to define holder binding (user's public key contained inside an SD-JWS) as an option.  It is not mandatory since holder binding is use case specific and orthogonal to the general mechanism of selective disclosure we are trying to define here. </ins> 1.1.

Related discussion:
text: first pass, will cover other sections later
I approve of the content in this PR. (I would use the GitHub "Approve" function, but it appears that I may need write or contributor access to the repository to be able to do so. Could that be added for me?)
These changes are all worthwhile improvements.