jiebi/CodeConvo huggingface dataset:
Code change:
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?

Related discussion:
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> <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> <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> <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.
Code change:
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?

Related discussion:
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> <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.
Code change:
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?

Related discussion:
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> <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. <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> <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.
Code change:
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?

Related discussion:
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> <ins> Credential defined by VC-DATA. </ins> 2.
Code change:
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?

Related discussion:
text: 6. This section defines encoding, validation and processing rules for <del> SD-JWT VPs. </del> <ins> presentations of SD-JWT VCs. </ins> 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> <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> <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> <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. <del> If the SD-JWT VP includes a Holder Binding JWT, the following claims are used within the Holder Binding JWT: </del> <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.
Code change:
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.

Related discussion:
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> <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. <del> In the following, the concept of SD-JWSs and matching proofs is described on a conceptual level. </del> <ins> In the following section, the concepts of SD-JWTs and releases are described at a conceptual level. </ins> 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> <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> <del> is usually a simple object with claim names mapped to salted and hashed claim values: </del> <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. <del> For a proof, a holder releases a document such as the following to the verifier: </del> <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:
Code change:
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.

Related discussion:
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
Code change:
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.

Related discussion:
text: signature on the SD-JWT cannot be verified, the SD-JWT MUST be rejected. <del> 7.2. </del> <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
Code change:
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.

Related discussion:
text: it is not practical for the attacker to guess.  Each salt value MUST be unique. <del> 7.3. </del> <ins> 7.4. </ins> The length of the randomly-generated portion of the salt MUST be at least 128 bits. <del> 7.4. </del> <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
Code change:
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.

Related discussion:
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> <ins> 7.6. </ins> TBD
Code change:
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!

Related discussion:
text: 9. <del> We would like to thank ... </del> <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.
Code change:
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 :)

Related discussion:
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> <ins> this document.  It can be passed by value or by reference. </ins> With holder binding, the
Code change:
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 :)

Related discussion:
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> <ins> Note: Examples in this document use </ins> <del> I think. </del> <ins> Claim defined in RFC7800 to include raw public key by value in SD- JWT. </ins> 5.2.
Code change:
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

Related discussion:
text: Selective Disclosure JWT (SD-JWT) <del> draft-fett-oauth-selective-disclosure-jwt-01 </del> <ins> draft-fett-oauth-selective-disclosure-jwt-02 </ins> Abstract
Code change:
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

Related discussion:
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.
Code change:
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

Related discussion:
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> <ins> this document.  It can be passed by value or by reference. </ins> With holder binding, the
Code change:
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

Related discussion:
text: 4.4. <ins> If claim name blinding is used, is created as follows: is a placeholder used instead of the original claim name, chosen such that it does not leak information about the claim name (e.g., randomly). The contents of are modified as follows: Note that blinded and unblinded claim names can be mixed in and accordingly in . 4.5. </ins> A verifier checks that The detailed algorithm is described below.
Code change:
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

Related discussion:
text: guess.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value. <del> The issuer MUST build the digests by hashing over a string that is formed by JSON-encoding an ordered array containing the salt and the claim value, e.g.: </del> <ins> The issuer MUST build the digests by hashing over a JSON literal according to RFC8259 that is formed by JSON-encoding an object with the following contents: The following is an example for a JSON literal without claim name blinding: </ins> <del> . The digest value is then base64url-encoded.  Note that the precise JSON encoding can vary, and therefore, the JSON encodings MUST be sent to the holder along with the SD-JWT, as described below. </del> <ins> The following is an example for a JSON literal with claim name blinding: IMPORTANT: JSON encoding according to RFC8259 allows for white space characters and other variations in the encoded representation.  To ensure that issuer and verifier produce the same hash digest, the issuer therefore sends the JSON literal to the holder along with the SD-JWT, as described below. The claim contains an object where claim names are mapped to the respective digests.  If a claim name is to be blinded, the digests MUST contain the key as described above and the claim name in MUST be replaced by a placeholder value that does not leak information about the claim's original name.  The same placeholder value is to be used in the SVC and SD-JWT-R described below. </ins> 5.1.1.1.