jiebi/TextFlow huggingface dataset:
Original text:
referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt. <del> To support revocation of credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </del>  <del> The three-party-model, i.e., actors, Verifiable Credentials and Verifiable Presentations, is also described in VC-DATA.  This specification defines Verifiable Credentials based on the SD-JWT format and JSON payloads.  A translation algorithm between the two approaches is provided in this specification. </del>  1.2.

Reviewer comments:
Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?

Revised text:
referenced in the credential.  This process is further described in I-D.ietf-oauth-selective-disclosure-jwt.  <ins> To support revocation of Verifiable Credentials, an optional fourth party can be involved, a Status Provider, who delivers revocation information to Verifiers.  (The Verifier can also serve as the Status Provider.) </ins>  <ins> The three-party-model, i.e., actors, Verifiable Credentials, is also described in VC-DATA.  This specification defines Verifiable Credentials based on the SD-JWT format and JWT Claim Sets with JSON payloads.  A translation algorithm between the two approaches is provided in this specification. </ins> 1.2.
Original text:
Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWT- based credentials do not support selective disclosure, i.e., the <del> ability for a holder to disclose only a subset of the claims </del>  contained in the JWT, which is a requirement to implement the three- party-model efficiently.

Reviewer comments:
Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?

Revised text:
Verifiable Credentials in a way that is easy to understand and process as it builds upon established web primitives.  However, JWT- based credentials do not support selective disclosure, i.e., the  <ins> ability for a Holder to disclose only a subset of the claims </ins> contained in the JWT, which is a requirement to implement the three- party-model efficiently.
Original text:
support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).  This format is therefore perfectly suited for <del> Verifiable Credentials and Verifiable Presentations. </del>  SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT. <del> JWTs (and SD-JWTs) can contain claims that are registered in the IANA JWT Claim Registry, as well as public and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </del>  1.3.

Reviewer comments:
Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?

Revised text:
support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).  This format is therefore perfectly suited for  <ins> Verifiable Credentials. </ins> SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT.  <ins> JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </ins> 1.3.
Original text:
This specification uses the terms "Holder", "Issuer", "Verifier", defined by I-D.ietf-oauth-selective-disclosure-jwt, Verifiable <del> Credential and Verifiable Presentation defined by VC-DATA. </del>  2.

Reviewer comments:
Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?

Revised text:
This specification uses the terms "Holder", "Issuer", "Verifier", defined by I-D.ietf-oauth-selective-disclosure-jwt, Verifiable  <ins> Credential defined by VC-DATA. </ins> 2.
Original text:
6. This section defines encoding, validation and processing rules for <del> SD-JWT VPs. </del>  6.1. <del> SD-JWT VPs MUST be encoded using the SD-JWT Combined Format for Presentation as defined in Section 5.4. of I-D.ietf-oauth-selective- disclosure-jwt. </del>  <del> SD-JWT VPs MAY contain a Holder Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure-jwt. </del>  6.1.1. <del> If the SD-JWT VP includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: </del>  The Holder Binding JWT MAY include addtional claims which when not understood MUST be ignored.

Reviewer comments:
Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?

Revised text:
6. This section defines encoding, validation and processing rules for  <ins> presentations of SD-JWT VCs. </ins> 6.1.  <ins> A presentation of an SD-JWT VC MUST be encoded using the SD-JWT Combined Format for Presentation as defined in Section 5.4. of I- D.ietf-oauth-selective-disclosure-jwt. </ins>  <ins> A presentation of an SD-JWT VC MAY contain a Holder Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. </ins> 6.1.1.  <ins> If the presentation of the SD-JWT VC includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: </ins> The Holder Binding JWT MAY include addtional claims which when not understood MUST be ignored.
Original text:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This specification uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client" defined by The OAuth 2.0 Authorization Framework RFC6749. </del>  2.  3. <del> In the following, the concept of SD-JWSs and matching proofs is described on a conceptual level. </del>  3.1. <del> An SD-JWS, at its core, is a signed document containing some metadata, the holder's public key, and hashed and salted claims.  It is signed using the issuer's private key. </del>  <del> is usually a simple object with claim names mapped to salted and hashed claim values: </del>  can also be nested deeper to capture more complex objects, as will be shown later.  3.2. <del> For a proof, a holder releases a document such as the following to the verifier: </del>  is usually a simple object with claim names mapped to values and salts:

Reviewer comments:
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.

Revised text:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  <ins> denotes the URL-safe base64 encoding without padding defined in Section 2 of RFC7515. </ins> 2. <ins> Note: discuss if we want to include Client, Authorization Server for the purpose of ensuring continuity and separating the entity from the actor. Note: noneed to define anymore? </ins> 3.  <ins> In the following section, the concepts of SD-JWTs and releases are described at a conceptual level. </ins> 3.1.  <ins> An SD-JWS, at its core, is a digitally signed document containing hashes over the claim values with unique salts, optionally the holder's public key and other metadata.  It is digitally signed using the issuer's private key. </ins>  <ins> is usually a simple object with claim names mapped to hashes over the claim values with unique salts: </ins> can also be nested deeper to capture more complex objects, as will be shown later. <ins> The SD-JWT is sent from the issuer to the holder, together with the mapping of the plain-text claim values, the salt values, and potentially some other information. </ins> 3.2.  <ins> To release to a verifier a subset of SD-JWT claim values, a holder creates a JWS such as the following: Note that the signature over is optional and required if, and only if, holder binding is desired. </ins> is usually a simple object with claim names mapped to values and salts:
Original text:
7.1.  The SD-JWT MUST be signed by the issuer to protect integrity of the issued claims.  An attacker can modify or add claims if an SD-JWT is not signed (e.g., change the "email" attribute to take over the

Reviewer comments:
Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.

Revised text:
7.1. <ins> ToDo: add text explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT: - create a test suite that forces hash computation by the Verifiers, and includes negative test cases in test vectors - use only implementations/libraries that are compliant to the test suite - etc. 7.2. </ins> The SD-JWT MUST be signed by the issuer to protect integrity of the issued claims.  An attacker can modify or add claims if an SD-JWT is not signed (e.g., change the "email" attribute to take over the
Original text:
signature on the SD-JWT cannot be verified, the SD-JWT MUST be rejected. <del> 7.2. </del>  The security model relies on the fact that the salt is not learned or guessed by the attacker.  It is vitally important to adhere to this

Reviewer comments:
Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.

Revised text:
signature on the SD-JWT cannot be verified, the SD-JWT MUST be rejected.  <ins> 7.3. </ins> The security model relies on the fact that the salt is not learned or guessed by the attacker.  It is vitally important to adhere to this
Original text:
it is not practical for the attacker to guess.  Each salt value MUST be unique. <del> 7.3. </del>  The length of the randomly-generated portion of the salt MUST be at least 128 bits. <del> 7.4. </del>  For the security of this scheme, the hash function is required to be preimage and collision resistant, i.e., it is infeasible to calculate

Reviewer comments:
Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.

Revised text:
it is not practical for the attacker to guess.  Each salt value MUST be unique.  <ins> 7.4. </ins> The length of the randomly-generated portion of the salt MUST be at least 128 bits.  <ins> 7.5. </ins> For the security of this scheme, the hash function is required to be preimage and collision resistant, i.e., it is infeasible to calculate
Original text:
Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used. <del> 7.5. </del>  TBD

Reviewer comments:
Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.

Revised text:
Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 revealed fundamental weaknesses and they MUST NOT be used.  <ins> 7.6. </ins> TBD
Original text:
9. <del> We would like to thank ... </del>  10.

Reviewer comments:
In this PR, I generalized the examples: Right now, there is a lot of repetition in the code for each of the three examples. With more examples (W3C VC) and more example code (claims merging) to come, things will get more complicated. I therefore moved the examples into a separate directory as YAML files. I used YAML, because this means that we can store all data required for each example as separate JSON documents in one YAML file (JSON is a subset of YAML). The code can now be called with a YAML file as the input and will run the demo for the example defined in the file. This will make it easier for us to add more examples in the future. Also in this pull request: Cleaned up the code to produce just one example each time - there is no need to calculate all examples when only one is used in each run Cleaned up the code to produce both the CLI output and the spec examples from the same set of data to avoid repetitions This means that placeholders in URL are now strictly named as follows: , where refers to the identifier of the data produced in the example run (see file). Fix for example output: serialized SVC was not shown, but serialized SD-JWT twice Renamed to (not sure what was meant to say) Fix for norandomness: RNG was seeded to static value even when no_randomness was not used
Yes, it was in my backlog, thanx. This first proposal was to get all the examples in a single shot, we can add a CLI parameter, I'll have a look for that This means that placeholders in URL are now strictly named as follows: example-{exampleid}-{artifactid}, where artifactid refers to the identifier of the data produced in the example run (see sdjwt file). Thank you, I wanted to make a proposal for this, you did it My bad it was "selected example" but artifacts is better anyway OK!

Revised text:
9.  <ins> We would like to thank Alen Horvat, Brian Campbell, Christian Paquin, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, and Torsten Lodderstedt for their contributions (some of which substantial) to this draft and to the initial set of implementations. The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway. </ins> 10.
Original text:
must contain information about key material controlled by the holder: Note: How the public key is included in SD-JWT is out of scope of <del> this document.  It can be passed by value or by reference.  Examples in this document use Claim to include raw public key by value in SD-JWT. </del>  With holder binding, the

Reviewer comments:
addresses Issue
NAME considering the last OOP refactor on the python code and the revision of Brian probably it would be easier to close this PR and starting a new one on top of the current master branch, the changes in the code and in the text are very trivial
NAME ok, please do a PR directly to this branch :)

Revised text:
must contain information about key material controlled by the holder: Note: How the public key is included in SD-JWT is out of scope of  <ins> this document.  It can be passed by value or by reference. </ins> With holder binding, the
Original text:
pair to the issuer, the issuer MAY create the key pair for the holder, or holder and issuer MAY use pre-established key material. <del> Note: need to define how holder public key is included, right now examples are using </del>  <del> I think. </del>  5.2.

Reviewer comments:
addresses Issue
NAME considering the last OOP refactor on the python code and the revision of Brian probably it would be easier to close this PR and starting a new one on top of the current master branch, the changes in the code and in the text are very trivial
NAME ok, please do a PR directly to this branch :)

Revised text:
pair to the issuer, the issuer MAY create the key pair for the holder, or holder and issuer MAY use pre-established key material.  <ins> Note: Examples in this document use </ins>  <ins> Claim defined in RFC7800 to include raw public key by value in SD- JWT. </ins> 5.2.
Original text:
Selective Disclosure JWT (SD-JWT) <del> draft-fett-oauth-selective-disclosure-jwt-01 </del>  Abstract

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
Selective Disclosure JWT (SD-JWT)  <ins> draft-fett-oauth-selective-disclosure-jwt-02 </ins> Abstract
Original text:
can be a simple object with claim names mapped to hash digests over the claim values with unique random salts:  can also be nested deeper to capture more complex objects, as will be shown later.

Reviewer comments:
Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT

Revised text:
can be a simple object with claim names mapped to hash digests over the claim values with unique random salts: <ins> The claim name ( ) is an optional </ins> can also be nested deeper to capture more complex objects, as will be shown later.