jiebi/CodeConvo huggingface dataset:
Code change:
Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing. <del> Discard any leading SP characters from input_string. </del> <ins> Discard any leading OWS characters from input_string. </ins> If field_type is "list", let output be the result of running Parsing a List (parse-list) with input_string.

Related discussion:
text: From Magnus's feedback
also NAME PTAL
This does not instill much of a panicked reaction in me, which is probably a good sign. I trust it is intentional to not apply a similar treatment to inner lists (which also has a prose description I had commented on previously) on the grounds of them not resembling existing top-level header field structures? That's certainly defensible, though I have to wonder whether someone will simply assume that it must be the same (not that we have much hope of changing such a person's behavior).
How does this vibe with ? I know we spent a bit of time on it, but it's long enough ago that I can't recall detail.
Ah, right, I think I remember. Doing it this way means inner-list is different: The original motivation to remove tabs was because the above was going to be but there was consternation about RWS. Most of the discussion is in
NAME was where my mind went first too, but that seems to be just about in inner lists (which makes sense). I think this is separate; intermediaries that don't know about the semantics and syntactic limitations of a given field shouldn't be meddling inside it (which inner list delimitation is).
NAME I think so -- that's the only reason to allow this. Existing servers may already legitimately be using TAB when combining multiple field lines. And I suppose it makes sense, given the recent discussion about not breaking up individual list or dictionary members over multiple lines, that we don't need to replace *SP with OWS everywhere. I'm okay with this change -- does it warrant a note in the prose somewhere that this special case only exists to accommodate field concatenation? Let's hope we don't need to add VTAB or FF to this, too :)
NAME I don't know that that's necessary; we already pretty clearly. In SF, I looked at changing "whitespace", but in each case the ABNF and algorithms make it clear what we're talking about, so I don't see a strong need to disambiguate.
I'm ok with the change over here; that said, the Semantics spec could be clearer. Opened URL
NAME and I have been talking about this, and have come to the conclusion that this change went too far.
Code change:
Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing. <del> Discard any leading SP characters from input_string. </del> <ins> Discard any leading OWS characters from input_string. </ins> If field_type is "list", let output be the result of running Parsing a List (parse-list) with input_string.

Related discussion:
text: Specifically, steps 1 and 5 in "Parsing Structured Fields" should just be SP, not OWS, because there isn't any risk of an intermediary inserting TAB before the first field line or after the last field line; it's only between List and Dictionary members that we need to be concerned. Reverting that part of the change also makes writing the test cases considerably simpler. See 6842793e.
This is so that field line combination as per the Semantics spec can happen, right? I note that currently says: Note that it says "comma an optional whitespace", not "OWS". Depending on how you read it, it might include other whitespace characters. I believe this needs to be fixed in the Semantics spec.I dont think I ever saw a TAB in a HTTP header in real life, but I am OK with this.
Code change:
The user agent includes stored cookies in the Cookie HTTP request header field. <del> When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field. </del> A user agent MAY omit the Cookie header field in its entirety.  For example, the user agent might wish to block sending cookies during "third-party" requests from setting cookies (see third-party- cookies). If the user agent does attach a Cookie header field to an HTTP <del> request, the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </del> <ins> request, the user agent MUST generate a single cookie-string and the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </ins> 5.7.2.

Related discussion:
text: The current limbo state isn't helping anyone :) cc NAME
Yes, +1 to documenting reality and no longer blocking the IETF process for 6265bis on this particular item (which I do agree we should treat as a security bug to be eventually solved).
Not an editor, but LGTM (given that it reflects reality).LGTM, given the context.
Code change:
The user agent includes stored cookies in the Cookie HTTP request header field. <del> When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field. </del> A user agent MAY omit the Cookie header field in its entirety.  For example, the user agent might wish to block sending cookies during "third-party" requests from setting cookies (see third-party- cookies). If the user agent does attach a Cookie header field to an HTTP <del> request, the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </del> <ins> request, the user agent MUST generate a single cookie-string and the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </ins> 5.7.2.

Related discussion:
text: Sorry, let me clarify antecedents: >This text [found in RFCs 7540, 9113, and 9114] clearly supposes that anything version-specific which comes after RFC 7540 will know that Cookies may have been split; perhaps [6265bis] should prescribe tolerance of receiving that on the server side. That is, perhaps the Cookie spec should require that servers be able to handle Cookie fragments having been split into multiple Cookie headers, since this document has the opportunity to be aware of HTTP/2+ behavior.
Thanks for clarifying, that makes sense.
LGTM % tiny nits.
Code change:
IANA is requested to deprecate the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry at <del> https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2]. </del> <ins> https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2] and replace the note on this registry with the following text: </ins> 8.  References

Related discussion:
text: Follow up to the IANA review of the digest spec. We asked them to deprectae the old registry, so lets add a note to it to clarify what the new expectations of that registry are.
Code change:
BFF proxy will automatically add tokens to calls to the resource server. <del> 6.3. </del> <ins> 6.4. </ins> In this architecture, the JavaScript code is first loaded from a static web host into the browser (A), and the application then runs

Related discussion:
text: I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.
Code change:
regular validity checks, but might also be abused in cases where this is not intended and unknown to the Holder, e.g. profiling the suspension of a driving license or checking the employment status of <del> an employee credential.  This behaviour could be constrained by adding authorization rules to the Status List, see security- authorization. </del> <ins> an employee credential. This behaviour could be mitigated by: - adding authorization rules to the Status List, see security-authorization.  - regular re-issuance of the Referenced Token, see implementation-lifecycle. </ins> 11.4. <del> Colluding Issuers and Relying Parties have the possibility to identify the usage of credentials of a particular Holder, as the Referenced Token contains unique, trackable data. </del> <ins> Colluding Issuers and a Relying Parties have the possibility to link two transactions, as the tuple of "uri" and "index" inside the Referenced Token are unique and therefore traceable data.  By comparing the status claims of received Referenced Tokens, two colluding Relying Parties could determine that they have interacted with the same user or an Issuer could trace the usage of its issued Referenced Token by colluding with various Relying Parties.  It is therefore recommended to use Status Lists for Referenced Token formats that have similar unlinkability properties. </ins> To avoid privacy risks for colluding Relying Parties, it is <del> recommended that Issuers use batch issuance to issue multiple tokens, such that Holders can use individual tokens for specific Relying Parties.  In this case, every Referenced Token MUST have a dedicated Status List entry.  Revoking batch issued Referenced Tokens might reveal this correlation later on. </del> <ins> RECOMMENDED that Issuers use batch issuance to issue multiple tokens, see implementation-lifecycle. </ins> <del> To avoid information leakage by the values of "uri" and "index", Issuers are RECOMMENDED to: </del> <ins> To avoid further correlatable information by the values of "uri" and "index", Issuers are RECOMMENDED to: </ins> choose non-sequential, pseudo-random or random indices

Related discussion:
text: Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens
Code change:
Since two semantically distinct inputs can create the same output in the signature base, special care has to be taken when handling such <del> values. </del> <ins> values.  Signers can make use of the "bs" parameter to armor such fields, as described in http-header-byte-sequence. </ins> Specifically, the Set-Cookie field COOKIE defines an internal syntax that does not conform to the List syntax in STRUCTURED-FIELDS.  In

Related discussion:
text: This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and
Code change:
encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. <del> The encoding of the public key is determined by the Signature </del> <ins> 3.1.1. Both the "Public Key" field of the TLS key exporter context (see above) and the "a" Parameter (see parameter-a) carry the same public key.  The encoding of the public key is determined by the Signature </ins> Algorithm in use as follows: This document does not define the public key encodings for other

Related discussion:
text: In 4.2, the parameter is "a byte sequence that contains the public key", and the encoding of the public key is taken from Section 3.1. When reading this, I was initially unclear whether was only the key or the entire structure defined in Section 3.1 or another structure, particularly given the use of the word "contains." I might clarify that the parameter is the public key, and perhaps point from both 3.1 and 4.2 to the same place for how to get the bytes which are being base64url-encoded here. (Make a 3.1.1?) (Marking editorial, as I don't think I'm asking for a technical change here, just clarification of how this already works.)
What you're describing is indeed what we intended. I'm write up an editorial PR to clarify this.
Code change:
receives a response, the cache SHOULD update or invalidate each of its stored <del> GET responses that could have been selected for that request (see </del> <ins> GET responses that could have been chosen for that request (see </ins> caching.negotiated.responses). <del> For each of the stored responses that could have been selected, if the stored response and HEAD response have matching values for any </del> <ins> For each of the stored responses that could have been chosen, if the stored response and HEAD response have matching values for any </ins> received validator fields ( and

Related discussion:
text: Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .
Code change:
"inclusion-proof: bstr .cbor CCF-inclusion-proof".  This contains the serialized CCF inclusion proof, as defined above. <del> "leaf" (label TBD_2): "bstr .cbor CCF-leaf".  This contains the CCF-specific serialization of the leaf element The payload of the signature is the CCF ledger Markle root digest, </del> <ins> The payload of the signature is the CCF ledger Merkle root digest, </ins> and MUST be detached in order to force verifiers to recompute the root from the inclusion proof in the unprotected header.  This provides a safeguard against implementation errors that use the

Related discussion:
text: NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call
Code change:
and a final response that were sent from the origin server in response to a revalidation request. <ins> A server MAY emit multiple 103 (Early Hints) responses with additional header fields as new information becomes available while the request is being processed.  It does not need to repeat the fields that were already emitted, though it doesn't have to exclude them either.  The client can consider any combination of header fields received in multiple 103 (Early Hints) responses when anticipating the list of header fields expected in the final response. The following example illustrates a series of responses that a server might emit.  In the example, the server uses two 103 (Early Hints) responses to notify the client that it is likely to send three Link header fields in the final response.  Two of the three expected header fields are found in the final response.  The other header field is replaced by another Link header field that contains a different value. </ins> 3. Some clients might have issues handling 103 (Early Hints), since

Related discussion:
text: Clarify that the disappearance of a header field (that once existed in a 103 response) from the following 103 responses does not indicate the retraction of the expectation that the header field will be included in the final response.
ecb2c7e clarifies the general rule that this PR relies on (i.e. the nonexistence of a header field in the 103 response cannot be used as a signal that the header field will be absent in the final response), at the same time addressing Spencer Dawkins' suggestion to clarify that "the server can add header fields in the 200 that were not present in the 103."
In section 2. "103 Early Hints" the last paragraph describes that 103 can be send multiple time. The given example reads as if a server may correct its previous 103 that is made from a cached resource. So the following 103 are correcting the older ones, they are only adding headers to the previous ones or are they replacing them completely? Maybe sentence clarifying this would be good.
This is an interesting question. I think that we should agree on what the expected behavior is before discussing how (or if) we should update the text. Regarding the question, I think that we should consider two (or more) Early Hints responses as expectations from different sources, rather than considering the following one to update the earlier ones. The reason I think so is because nonexistence of a header field in the 103 response does not imply that the header field will not exist in the final response, since we are not required to include in 103 response all the headers that are expected to be included in the final response. So consider the following example: a caching intermediary might generate an Early Hints response from a stale-cached response. That Early Hints response could contain a header field that will never be included within an Early Hints response sent from the origin. In such case, considering both of the Early Hints responses as genuine makes the most sense.
Code change:
S s-maxage (cache directive) <del> selected response </del> shared cache stale

Related discussion:
text: Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .
Code change:
5.2. <del> TBD </del> <ins> The Status List Token MUST be encoded as a "CBOR Web Token (CWT)" according to RFC8392. Applications MAY use the media type "statuslist+cwt" for a CWT in accordance with the rules outlined in this specification. The following content applies to the CWT protected header: "3" (content type): REQUIRED.  The CWT content type MUST be "statuslist+cbor". The following content applies to the CWT Claims Set: "1" (issuer): REQUIRED.  Same definition as "iss" claim in (#status-list-token-jwt). "2" (subject): REQUIRED.  Same definition as "sub" claim in (#status-list-token-jwt). "6" (issued at): REQUIRED.  Same definition as "iat" claim in (#status-list-token-jwt). "4" (expiration time): OPTIONAL.  Same definition as "exp" claim in (#status-list-token-jwt). "TBD" (status list): REQUIRED.  The status list claim MUST specify the Status List conforming to the rules outlined in status-list- cbor. The following additional rules apply: The CWT MAY contain other claims. The CWT MUST be digitally signed using an asymmetric cryptographic algorithm.  Relying parties MUST reject the JWT if it is using a Message Authentication Code (MAC) algorithm.  Relying parties MUST reject CWTs with an invalid signature. Relying parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" RFC8392. Application of additional restrictions and policy are at the discretion of the verifying party. The following is a non-normative example for a Status List Token in CWT format: The following is the CBOR diagnostic output of the example above: </ins> 6.

Related discussion:
text: In fact COSE is already mentioned at all places, so the question is whether we should align things and say Referenced Token = JOSE/COSE-based
Use reference to RFC9052 instead of RFC8152
As described in the title, detail the CWT representation of the status list which is complementary to the JWT representation.
Maybe a naive question but what's the motivation for this draft having the two representations? When positioned as a companion of the SD-JWT VC draft and aiming for the OAuth WG, it seems like keeping the scope tighter and only having the JWT representation would be sufficient/okay/preferable.
NAME credential formats like mDocs do not have a status/revocation mechanism hence a CWT based representation is beneficial to these applications as they dont typically have JWT support.
I dunno, I'm not convinced that necessitates having multiple status list token representations. Especially in one draft. This draft, which again is being positioned as a companion to the SD-JWT VC. I suspect the work would be more palatable for adoption with a scope that's reflective of that. But maybe that's just me. Thanks for the context.