jiebi/CodeConvo huggingface dataset:
Code change:
4.2. <del> SD-JWT VCs MUST be encoded using the SD-JWT Combined Format for Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. </del> <ins> SD-JWT VCs MUST be encoded using the SD-JWT format defined in Section 5 of I-D.ietf-oauth-selective-disclosure-jwt.  A presentation of an SD-JWT VC MAY contain a Key Binding JWT. </ins> <del> 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. </del> <ins> Note that in some cases, an SD-JWT VC MAY have no selectively disclosable claims, and therefore the encoded SD-JWT will not contain any Disclosures. </ins> 4.2.1.

Related discussion:
text: I removed the subsection numbers where appropriate to be less dependent on changes in the SD-JWT spec. I also removed references to the issuance/presentation format, as this was unified in SD-JWT. This also meant that the section on the data formats for issuance and presentation in our spec can now be just one section, as there are no big differences any longer.
There are a number of references to specific section numbers in SD-JWT that are now out of sync and point to the wrong sections or non-existent sections. And some lingering use of terms like "Combined Format for XXXXX" that are no longer used in SD-JWT.
And there may well be other changes coming to the section layout URL so it might be prudent to avoid specific section number references (for the time being anyway).
lgtm
Code change:
NAT64 prefix(es) MUST be advertised by those stub routers that are able to discover it. <ins> In order for infrastructure-provided NAT64 to work, the stub network must have an OSNR prefix that is known to the infrastructure. Typically this means that the stub router must have acquired this prefix using DHCPv6 Prefix Delegation.  Unless otherwise configured to do so, the stub router MUST NOT advertise infrastructure-provided NAT64 service on the stub network if it has not acquired the OSNR prefix through DHCPv6 Prefix Delegation. </ins> 6.2. Most infrastructure networks at present do not provide NAT64 service. <del> It is therefore necessary for stub routers to be able to provide </del> <ins> Many infrastructure networks do not provide DHCPv6 Prefix Delegation. In these cases it is necessary for stub routers to be able to provide </ins> NAT64 service if IPv4 hosts are to be reachable from the stub <del> network. </del> <ins> network.  Therefore, stub routers MUST be capable of providing NAT64 service to the stub network.  When infrastructure-provided NAT64 service is not present or is not usable, and when no other NAT64 service is already advertised on the stub network, stub routers MUST, by default, enable their own NAT64 service and advertise it on the stub network. </ins> To provide NAT64 service, a stub router must allocate a NAT64 prefix. For convenience, the stub network allocates a single prefix out of

Related discussion:
text: Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.
Code change:
credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant HTTP message content could require the Content-Digest header to be <del> present and covered as well as mandate a value for "context" that is specific to the API being protected. </del> <ins> present and covered as well as mandate a value for "tag" that is specific to the API being protected. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter

Related discussion:
text: Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.
Code change:
new registration procedure and moving HTTP field definitions into a separate registry. <del> Please create a new registry as outlined in fields.registry. </del> <ins> Please create a new registry as outlined in fields.registry, and let that registry link to this specification (e.g., "See section fields.extensibility of [this document] for information on defining and registering new HTTP Header Fields."). </ins> After creating the registry, all entries in the Permanent and Provisional Message Header Registries with the protocol 'http' are to

Related discussion:
text: note in message-headers registry above move of HTTP registry in message-headers registry, remove obsolete note about HTTP field name registry note in new http field registry
Code change:
We would like to thank Alen Horvat, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, <del> Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Tobias Looker, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.
Code change:
The following transfer coding names for compression are defined by the same algorithm as their corresponding content coding: <ins> The compression codings do not define any parameters.  Their presence SHOULD be treated as an error. </ins> 7.3. The "HTTP Transfer Coding Registry" defines the namespace for

Related discussion:
text: This one is almost trivial. Except: previously, the ABNF sort-of ruled out parameters in the ABNF (at least that was the intent) this is now done in prose - we need to say though what to do when parameters are present - is "SHOULD treat as error" correct?
Should not enumerate the actual coding names. Make the ABNF generic and point out that the predefined encodings do not have parameters.
See URL
Instead of saying in each encoding that the presence of an undefined parameter should be treated as an error, it would be better to say that once in the main section for any encoding that does not define its own parameters. But +1 anyway.
Code change:
For each member mem of input: <del> Let name be the result of applying Serialising an Identifier (ser-identifier) to mem's member-name. </del> <ins> Let name be the result of applying Serialising an Key (ser-key) to mem's member-name. </ins> Append name to output. Append "=" to output. <del> Let value be the result of applying Serialising a Key (ser-key) to mem's member-value. </del> <ins> Let value be the result of applying Serialising an Item (ser- item) to mem's member-value. </ins> Append value to output.

Related discussion:
text: Serialisation of dictionary and param-list currently say instead of This fixes that.
Blah, good catch; thanks.
Code change:
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </ins> 3. 3.1.

Related discussion:
text: client-cert: Mention that origin server access control decisions can be conveyed with a 403 or by selecting response content
Do you envision that clients would drop their client cert cache in response to this 403? (They currently do not.) If so, how would that interact with subresources on the page?
I honestly don't envision any change in client behavior. I realize that doesn't address your concern. But I believe doing anything more is firmly beyond the scope of this draft. The sentence added by this PR is only aiming to fulfill Tommy's suggestion at the last virtual interim and in the issue URL
You might want to explain that David's concern is a genuine problem that this doesn't solve, something like:
Thanks Martin. I'll add that note.
From URL, it sounds like the intent with the client certs draft is that the proxy does little to no certificate validation and punts all of it to the origin. In that case, we need to sort out how errors work... Client cert UX is bad in part due to an impedance mismatch. In a user-facing client (like a browser), presenting a client certificate with a user-facing identity, we typically need to prompt the user to select an identity, reprompt on bad selection, etc. However, a single user-facing "session" covers multiple HTTP requests, which may then create or reuse connections depending on many factors. That means we cannot surface auth to the user at the connection- or request-. TLS session resumption and further complicate this. The consequence is clients cache client certificate decisions. (Non user-facing clients tend to have credentials preconfigured, which effectively also remembers the decision.) With a cache, clients need to know when to invalidate it. Otherwise the user can never recover from selecting the wrong identity. As this is TLS-level auth, today this is done by reacting to TLS-level alerts. draft-ietf-httpbis-client-cert-field breaks this correspondence by introducing a way to move half of TLS-level auth to HTTP. That is incompatible with today's client cert deployment assumptions, so we need to define something here. This is further complicated because the draft is shifting connection-level auth to a per-request scheme. I can see two options, but neither is very satisfying. Proxy translates HTTP error to TLS alert The most compatible option would be to define an HTTP error that the proxy must translate to a TLS alert on the client.
Code change:
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </ins> 3. 3.1.

Related discussion:
text: The problem is TLS alerts tear down the connection, so this would be very disruptive in HTTP/2, where we may have other requests multiplexed. (The TLS-level mechanism does not have this problem because it happens in connection setup.) Modify clients to interpret HTTP error as TLS error The other option is to define an HTTP error and pass it through to the client. However, that means this draft is not only a proxy server protocol, but also changes HTTP clients. We would need to discuss the compatibility implications. Additionally, by introducing a brand new way to do client cert errors, we introduce some awkward quirks. Suppose the server sends a resource with subresources on the same origin. Unlike HTTP auth, client cert auth applies to the whole connection. There would be no way to fetch those subresources without re-triggering the auth prompt. Perhaps we include lots of warnings that the server need to keep all its error page resources inline or on a different origin? Perhaps we say the client should ignore the response and map the HTTP error to some network-level error page?
The use of post-handshake authentication is similarly fraught. I assume that you are looking to have a connection torn down if any certificate is not fit for purpose. Isn't that a bit of a blunt instrument? It makes the use of multiple certificates an interesting game: get one wrong and you lose. More so because the TLS-terminating proxy is the one that plays the game with the client the one that pays the price. My assumption was a far more narrowly scope scenario: The proxy asks for a certificate based on some condition it arranges with the origin server (this is proprietary and not our problem). The client provides a certificate with a signature. The proxy validates the signature and passes certificate information to the origin server with any requests (again, deciding which requests to annotate thus is proprietary). The origin server takes this information and authorizes requests, or not. That's it. The scope of the draft starts and ends at step 3 here. The holistic problem is that clients tend to stick to their choice of client certificate in the face of these HTTP errors, only changing their mind if TLS fails (with a specific subset of possible alerts). That seems like a poor design choice; a legacy of how HTTP/1.1 works and not suited to modern uses.
Code change:
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </ins> 3. 3.1.

Related discussion:
text: For starters, the provision of the certificate was successful, it's just that it was not the one that the server wanted. Tearing the connection down is too strong a response when you consider that HTTP/2 and HTTP/3 have multiple concurrent requests, some of which might be affected by a TLS alert that brings the whole session down. I really do think that client changes are the right choice here. Clients can treat 401 (Unauthorized) as a signal that the credentials offered (zero or more certificates) are not adequate. At that point, it's probably safe to treat the cached choice of certificate as not useful for the next certificate request that comes along. Post-handshake authentication allows them to add to the pile of certificates, not jeopardizing credentials that are working. For the proxy, if it decides that it needs to ask for more credentials from a client that doesn't do post-handshake auth'n, then a TLS alert is an option. It's probably the only realistic option as things stand today. I'd prefer GOAWAY with a code that indicates that a new connection with different credentials is appropriate. For NAME benefit, I don't see any of this as affecting the client-cert-field work as long as it makes its scope clear. That work can probably just note that a proxy probably has to tear down the connection to the client after a 401 response so that the client won't fixate on the wrong certificate. Pick an appropriate alert. I don't think we need to go into defining new signaling arrangements. I don't think that it is worth the effort of doing more to improve client certificate-based authentication, unless there is some general trend toward enabling post-handshake auth, at which point we can talk about choosing a better solution.
While acknowledging that and associated issues, the scope of the draft is only about conveying the client cert info and not any new error signaling or attempts at addressing the larger problems.
It might be nice to still have some text to still mention that server can send back 403 status codes, etc, if they don't like the client certs. Don't add any new mechanisms, but explain that errors can happen, and there are ways to express them today.
If the server sends back a 403 mechanism, would you expect clients to act on this? I'm not aware of any client today that uses HTTP error codes to inform client certificate selection.
Code change:
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </ins> 3. 3.1.

Related discussion:
text: If a client without a client cert would see a 403, then I think it makes sense to mention that sending a 403 is what would reasonably happen here. I don't know if clients would do something automatically, but presenting the 403 error at least indicates that authentication was the problem.
PR basically adds this sentence, "Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context."
This is sufficient. A similar experience exists today when a client presents a certificate which is valid, but which does not grant access to the requested resource. While it's not ideal in certain ways -- the client might possess other certificates that would grant access if given an appropriate selector -- the server might also prefer not to share that list. This draft isn't attempting to create new solutions from scratch -- it's attempting to outline what is currently done in assorted custom ways to help coalesce these into a single format. Those custom mechanisms don't provide TLS alert translation either, so far as I'm aware.
Code change:
: "value" <del> And the following signature base lines: </del> <ins> And the following signature base lines, with (SP) indicating a single trailing space character before the empty component value: </ins> <del> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature base lines in the order in which the parameters occur in the target URI.  Note that in some implementations, the order of parsed query parameters is not stable, and this situation could lead to unexpected results.  If multiple parameters are common within an application, it is </del> <ins> This derived component has some limitations.  Specifically, the algorithm in HTMLURL only supports query parameters using percent- escaped UTF-8 encoding.  Other encodings are not supported. Additionally, multiple instances of a named parameter are not reliably supported in the wild.  If a parameter name occurs multiple times in a request, the named query parameter MUST NOT be included. If multiple parameters are common within an application, it is </ins> RECOMMENDED to sign the entire query string using the "@query" component identifier defined in content-request-query. <ins> The encoding process allows query parameters that include newlines or other problematic characters in their values, or with alternative encodings such as using the plus character to represent spaces.  For the query parameters in this message: The resulting values are encoded as follows: If the encoding were not applied, the resultant value would be: This base string violates the constraints on component values, and is therefore invalid. </ins> 2.2.9. The "@status" derived component refers to the three-digit numeric

Related discussion:
text: So we need to deal with it one way or another. I could live with UTF-8, and a note that if the octet sequence does not decode as UTF-8, you can't sign it.
NAME - yes, you can merge and close issues as you wish, you are the editor. But by all means do not submit a new draft until the changes have been reviewed by those who opened the issue. (cc chairs NAME NAME )
As far as I can tell, the changes require percent-encoding only for non-ASCII values. That is, the character U+0080 would get the same encoding as a verbatim "%80" in a field value. I believe this is a problem.
This issue has been addressed. There is no percent encoding needed in this section since the value is taken directly from the bytes of the field in a binary-wrapped representation, and the bytes are encoded using the base64 serialization of a Byte Sequence from Structured Fields:
I'm talking about the simple case, not the one where Byte Sequence encoding is used (yes, the issue title doesn't match anymore).
Ok, opened new issue URL
Code change:
its payload, the target resource, or the connection.  They are called "HTTP fields" or just " <del> ". </del> <ins> ".  Fields occur in groups called " " or just "sections". </ins> Fields that are sent/received before the message body are referred to as "header fields" (or just "headers", colloquially) and are located

Related discussion:
text: The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.