jiebi/CodeConvo huggingface dataset:
Code change:
Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. <del> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I- D.ietf-oauth-selective-disclosure-jwt. </del> <ins> When there are selectively disclosable claims, SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I-D.ietf-oauth- selective-disclosure-jwt. </ins> 4.2.1.

Related discussion:
text: Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.
Code change:
Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. <del> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I- D.ietf-oauth-selective-disclosure-jwt. </del> <ins> When there are selectively disclosable claims, SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I-D.ietf-oauth- selective-disclosure-jwt. </ins> 4.2.1.

Related discussion:
text: alternative to based on NAME 's comment "I can't help but wonder if it'd make sense to have the spec be only about SD-JWT VCs and treat the plain JWT VC as just a special case of an SD-JWT with no selectively disclosable claims." no changes to the basic structure. simple clarifications what to do when there are no selectively disclosable claims ie no claim and no Disclosures. Might need some more details but this is how it might look like. (cc NAME NAME linked to rendered preview
Generally, I really like this approach! Some examples could be useful for key binding with JWT (no disclosures)
I'd expect the typ for both to have +jwt if that were really the case. There is another draft up for multiple suffixes. URL Is it simple enough to support now?
should this be titled ? I think this should be changed as well as the title before merging to make sure we are calling out that this covering SD-JWTs and JWTs
Yes. Will make a change once we have a decision whether PR or this one is the way to go…
What is the position of this specification? From my understanding it defines a VC with JWT claims it defines a profile for the JWT claims it defines a profile for securing the VC There's an open discussion between the sd-jwt and JWS protection. Relevant discussion has been started URL - sd-jwt introduces an encoding that becomes incompatible with JWS in the limit where selective disclosure is not used. In other words, it introduces a first-order phase transition. Let's see how this topic resolves. IMO, the data model and securing mechanisms should support both sd-jwt and JWS.
I do like this approach, but I am a bit concerned that even in the 'no disclosures' case, we'll have the trailing tilde in the issuance and presentation (when no KB is present). A JWT is not a special case of an SD-JWT for this reason.
I agree with the concern.
IMHO keeping the trailing tilde is preferable as it keeps the model consistent.
from what I am sensing, there seems to be a lot of preference towards the approach in this PR over , partially because it is simpler and gives one credential format and not two (consolidation, yay!), with one major discussion point being a ~ after a JWT VC when it is issued.
Code change:
Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. <del> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I- D.ietf-oauth-selective-disclosure-jwt. </del> <ins> When there are selectively disclosable claims, SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per Section 5.1.1.3. of I-D.ietf-oauth- selective-disclosure-jwt. </ins> 4.2.1.

Related discussion:
text: a bit of the context... this trailing ~ is the result of the decision being taken in SD-JWT spec to better align the issuance and presentation formats, (URL does it, and it has not been merged yet). One option is to keep issuance and presentation formats separate in SD-JWT (as-is) so that there is no ~ when (SD-)JWT VC is issued. but that is not that clean from a pure SD-JWT processing perspective is I think the opinion of its authors (NAME NAME so the question is really what to do with a trailing ~ when there is no SD in SD-JWT based VC.
should be good to merge once NAME takes a look and approves
I'm ok with this direction. I personally don't like the trailing tilde but we can fix that in another PR. I'll open an issue in the repository.
Merging this PR since a lot of approvals and no objections.
approving but will create an issue to address trailing tilde.I approve this approach over as, the specification is much cleaner I expect implementations to be much cleaner I don't see confusion with trailing tilde, because typ is not jwt but sd-jwt most interop profiles will require SD support anywayI prefer URL since I find its description of what we're achieving more natural / less surprising. But I can live with this description as well, provided the distracting "with JSON Claims" language is removed.
Code change:
allowed to have, and restricting the length of time an upload resource can exist. <del> 13. </del> <ins> 15. </ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Related discussion:
text: defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!
Code change:
9.8. <del> TLS provides a facility for secure connection closure through an exchange of closure alerts prior to closing a connection TLS13.  When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. </del> <ins> TLS uses an exchange of closure alerts prior to (non-error) connection closure to provide secure connection closure; see TLS13. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. </ins> When an implementation knows that it has sent or received all the message data that it cares about, typically by detecting HTTP message

Related discussion:
text: Inspired by my ballot comments ( ) I started trying to write something about how it's required to send "close_notify" in normal connection shutdown, but didn't like how that worked, and ended up here. I am not sure if I regressed in some other axes while improving on this one, though.
Code change:
Authentication Authentication o Change Controller: IESG o Specification Document: TBC <del> 6.2. </del> <ins> 7.2. </ins> This section registers the value "attest_key_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by

Related discussion:
text: As highlighted in the title this PR adds a privacy consideration around potential client instance tracking along with a recommendation for client deployments to mitigate such risk.
Code change:
request.  The "actor_token" MUST authenticate the identity of the requesting workload. <ins> 9.4. Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation sequence.  Only Txn-Tokens issued by a trusted Transaction Token Service may be trusted, so verification of the Txn-Token signature is required.  For replacement transaction tokens, not only must the JWT signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. 9.5. The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes) used with client external to the trust domain.  This makes managing unintentional scope increase a critical aspect of the Transaction Token Service.  The TTS MUST ensure that the requested purpose ("scope") of the Txn-Token is equal or less than the scope(s) identified in the "subject_token".  This is also true of requesting a replacement Txn-Token.  The TTS MUST ensure there is not unintentional increase in authorization scope. </ins> 10. 10.1.

Related discussion:
text: Added text to address issue
The following text in 2.2.2 is too open ended and should be refactored. First, the text should include specific guidance on replacement tokens to require scopes to remain the same or be down-scoped on replacement. Second, the draft should include a mechanism to ensure that scopes cannot be increased, or an increase in scope can be detected by downstream services. Finally, add text to the security considerations section regarding the risks of replacement tokens and/or a malicious txn-token-sts.
As far as I understand it, replacement txn-tokens is just a profile to Token Exchange. The Token Exchange RFC defines that an issued token can only have the same or a smaller scope than the presented token. I would assume this applies to replacement tokens as well. If the replacement token mechanism is intended to deviate from Token Exchange in this regard, this should probably be mentioned specifically.
NAME please review PR and see if I addressed your comments.
Completed. Looks good to me.
LGTM.
Code change:
2. <del> Context </del> <ins> Recall the definition of CoMeTre inclusion proofs, which are parametrized by 3 CBOR data types that are specific to the Tree Algorithm: This document defines the "CCF-leaf" and "CCF-inclusion-proof" CBOR types.  The signed Merkle Root data type "smtr" is the same as in I- D.steele-cose-merkle-tree-proofs but MUST set the protected header parameter carrying the identifier of the tree algorithm, "tree_alg", to the value TBD_1. 2.1. The input of the Merkle Tree Hash (MTH) function is a list of n bytestrings, written D_n = {d[0], d[1], ..., d[n-1]}. The output is a single HASH_SIZE bytestring, also called the tree root hash. This function is defined as follows: The hash of an empty list is the hash of an empty string: The hash of a list with one entry (also known as a leaf hash) is: For n > 1, let k be the largest power of two smaller than n (i.e., k < n <= 2k).  The Merkle Tree Hash of an n-element list D_n is then defined recursively as: where: || denotes concatenation : denotes concatenation of lists D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] = d[k1+1], ..., d'[k2-k1-1] = d[k2-1]} of length (k2 - k1). 2.2. Each leaf in a CCF Merkle Tree carries the following components: The "internal_hash" and "internal_data" bytestrings are internal to the CCF implementation.  Similarly, the auxiliary tree entries are internal to CCF.  They are opaque to receipt Verifiers, but they commit the TS to the whole tree contents and may be used for additional, CCF-specific auditing. 2.3. CCF inclusion proofs are one of the tree-specific fields of a "signed-inclusion-proof".  They consist of a list of digests tagged with a single left-or-right bit. Unlike some other tree algorithms, the index of the element in the tree is not explicit in the inclusion proof, but the list of left-or- right bits can be treated as the binary decomposition of the index, from the least significant (leaf) to the most significant (root). 2.4. When a client has received an inclusion proof and wishes to verify inclusion of a signed inclusion proof: 2.5. TBD </ins> 3.

Related discussion:
text: Thanks for the reviews, I have addressed all the comments.
NAME I don't see any reason not to merge.
okay to merge after all suggestions are accepted and remaining comments are acknowledged
Code change:
<del> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </del> <ins> Selective Disclosure for JWTs (SD-JWT) </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract

Related discussion:
text: This solves Issue by moving away from an example that wasn't ideal anyway (it encoded a different bytestring for the value Möbius). The Disclosure JSON should be:
"it shows as is there any way to change that..? (this is not the change introduced in this PR)" on the text in the doc at URL "A different way to encode the umlaut (two dots &; placed over the letter):" Originally posted by NAME in URL
Not sure why this broke now. I created a PR because the example wasn't ideal anyway: URL
I just noticed that the PR does not fully solve the problem. We have the same problem somewhere else as well: !
it's seems to have been an issue at least back to -01 URL and/or -02 URL (so basically since inception). I'm sure we could fight with the tool chain to fix it. But at what cost? I'm inclined to just reword that "The two representations... " part to make the issue go away. Which I did with this 48efde35a81ca3520eb30ceea6c43d62e8cd96f8 update to URL
PR merged
Code change:
<del> SD-JWT: Selective Disclosure for JWT and JWS with JSON Payloads </del> <ins> Selective Disclosure for JWTs (SD-JWT) </ins> draft-ietf-oauth-selective-disclosure-jwt-latest Abstract

Related discussion:
text: I've seen the "new" title from 332ded8faf20d528c5c05e04cebed28aab1a0d33 a few times in context now and it is really awkward.
yup, that updated intro and abstract text stays
as long as the intro text itself stays as we updated it, this makes sense to me.
Code change:
RFC8414, which enables a client to obtain metadata about an OAuth 2.0 authorization server. <ins> The means by which the client obtains the location of the protected resource is out of scope of this document.  In some cases, the location may be manually configured into the client; for example, an email client could provide an interface for a user to enter the URL of their RFC8620 server.  In other cases, it may be dynamically discovered; for example, a user could enter their email address into an email client, the client could perform RFC7033 discovery (in a manner related to the description in Section 2 of OpenID.Discovery) to find the resource server, then fetch the resource server metadata to find the authorization server to use to obtain authorization to access the user's email. </ins> The metadata for a protected resource is retrieved from a well-known location as a JSON RFC8259 document, which declares information about its capabilities and optionally, its relationships to other services.

Related discussion:
text: for
Per my reply to Bo Wu's OpsDir review: NAME can you add your motivating example to the introduction? Thanks!
I didn't mean to merge that PR without your review, so let me know if it looks good before I close this issue!
Looks good! The only change I made was to make the WebFinger reference informative. Please close.
Good catch, not sure why that wasn't informative before.
It was previously incorrectly normative. I just happened to notice when reviewing your addition. Thanks again!
Code change:
field value with parameters Produce an error if the output string contains any non-ASCII <del> (STD80) characters. </del> <ins> (ASCII) characters. </ins> Return the output string.

Related discussion:
text: Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.
Code change:
Specification document(s): content-dpr of this document Related information: for Client Hints <del> 6.3. </del> <ins> 6.4. </ins> Header field name: Downlink Applicable protocol: HTTP

Related discussion:
text: and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.
Code change:
If header_type is "item", let output be the result of running Parsing an Item (parse-item) with input_string. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If input_string is not empty, fail parsing.

Related discussion:
text: An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.
Code change:
HTTP/2 RFC7540 multiplexes multiple HTTP requests over a single connection, which is incompatible with the mechanism above.  Clients cannot correlate the certificate request with the HTTP request which <del> triggered it.  Thus, section 9.2.1 of RFC7540 forbids renegotiation. </del> <ins> triggered it.  Thus, Section 9.2.1 of RFC7540 forbids renegotiation. </ins> TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms.

Related discussion:
text: (Should I go ahead and stamp a -02 now, or wait a bit? Not sure how one usually handles such things.)
WGLC ends on Thursday, so let's wait until then to see if there's any other feedback.
It is Friday, so I've now pushed -02. It just contains this PR. URL
Code change:
are capitalized.  To ensure readability, only a core set of terms is included in this section. <del> : </del> The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052.

Related discussion:
text: Assuming URL is merged, that document will register everything that is needed for SCITT Receipts (a profile of COSE Receipts). There is clean up work to do in the architecture. Remove the editorial notes regarding 394. Review IANA considerations (AFAIK, 394 was never requested for registration in the document, despite the editor notes).
I've merged the PR, but we need to publish a new version to the data tracker. Ideally other authors (of COSE Receipts / COMETRE) will do an editorial pass, and then push a new version to the data tracker.
I'd personally prefer to separate the mediatype exclusion (which I agree with removing) to a different PR, but would approve both anyway. LGTM
Code change:
5. <del> TBD </del> <ins> This specification defines the media type which describes a VC-SD-JWT with the following components: 1.  An SD- JWT to protect the integrity of the claims, to enable selective disclosure and to ensure authorship of the VC-SD-JWT.  The SD-JWT header parameters and the payload is further defined by this specification.  1.  The full set of SD-JWT Disclosures that contain the claims in plain text. This specification defines the media type which describes the VP-SD-JWT with the following components: 1.  The SD-JWT from the VC-SD-JWT.  1.  A subset of the SD-JWT Disclosures that are selectively disclosed by the Holder.  1.  An optional holder binding JWT that proves the Holder is the intended Holder of the Verifiable Credential.  Note, it is the responsibility for the Issuer to include a confirmation method in the Verifiable Credential.  This process is referred to as holder binding.  This enables the Holder to prove they are the intended Holder of the Verifiable Credential. Further note, it is up to the Verifier to require or to not require the Holder to prove posessions of the confirmation method. </ins> 5.1. The <del> header parameter of the SD-JWT-VC MUST be present.  The </del> <ins> header parameter of the SD-JWT MUST be present.  The </ins> <del> value MUST use the media type </del> <ins> value MUST use </ins> <del> that is registered by this specification.  This indicates that the payload of the SD-JWT-VC contains plain JSON and follows the rules as defined in this specification. </del> <ins> . This indicates that the payload of the SD-JWT contains plain JSON and follows the rules as defined in this specification.  It further indicates that the SD-JWT is a SD-JWT component of a VC-SD-JWT. </ins> The following is a non-normative example of a decoded SD-JWT-VC header:

Related discussion:
text: And what would be a format identifier? I know that this doesn't have to be answered in this spec but it helps with answering the terminology question.
Suggest we not overcomplicate things and say: what is returned in a VP Token in OID4VP is a combined Format for presentation with HB-JWT. what is returned in Credential Response in Credential Response in VCI is combined format for issuance. credential format identifier is 'vc+sd-jwt' for both. Terminology-wise, SD-JWT in the IETF spec is defined as an issuer signed JWS without disclosures. For this profile, the payload of SD-JWT, can be mapped back to a VCDM2.0
This is potentially fixed by PR