jiebi/CodeConvo huggingface dataset:
Code change:
Such features SHOULD take into account the following aspects of the information exposed: <del> Exposing highly granular data can be used to help identify users across multiple requests to different origins.  Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. The feature SHOULD NOT expose user sensitive information.  To that end, information available to the application, but gated behind specific user actions (e.g. a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g. through JavaScript callbacks). </del> <ins> Entropy - Exposing highly granular data can be used to help identify users across multiple requests to different origins. Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. Sensitivity - The feature SHOULD NOT expose user sensitive information.  To that end, information available to the application, but gated behind specific user actions (e.g. a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. Change over time - The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g. through JavaScript callbacks). </ins> Different features will be positioned in different points in the space between low-entropy, non-sensitive and static information (e.g.

Related discussion:
text: Non substantive change to improve the list's style, after feedback on URL
Landing, as this is non-substantive
Code change:
Given a token as input_token, return an ASCII string suitable for use in a HTTP header value. <del> If input_token is not a sequence of characters, or contains a </del> <ins> If input_token is not a sequence of characters, the first character is not ALPHA or "*", or the remaining contain a </ins> character not in tchar, ":" or "/", fail serialisation. Let output be an empty string.

Related discussion:
text: ... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
Code change:
A verifier MUST validate an SD-JWT-VC as follows: <del> Additional validation rules MAY apply but their use is out-of-scope of this specification. </del> <ins> Additional validation rules MAY apply, but their use is out of the scope of this specification. </ins> 6.1. <del> Verifiers processing SD-JWT-VCs MUST verify the signature of the SD- JWT with the public key of the SD-JWT-VC issuer.  This makes sure that the SD-JWT-VC was issued by the SD-JWT-VC issuer and that it has not been tampered with since issuance. The claim in the SD-JWT-VC MAY be used to retrieve the public key from the JWT Issuer Metadata configuration (as defined in {#jwt-issuer- metadata}) of the SD-JWT-VC issuer.  A verifier MAY use alternative methods to obtain the public key to verify the signature of the SD- JWT. 6.2. </del> This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.  The JWT Issuer is identified by the

Related discussion:
text: NAME do you know how to fix the build errors?
let's fix references later and create a new issue for that
Code change:
If an endpoint detects multiple different errors, it MAY choose to report any one of those errors.  If a frame causes a connection <del> error, that error MUST be reported. </del> <ins> error, that error MUST be reported.  Additionally, an endpoint MAY use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_ERROR or INTERNAL_ERROR) can always be used in place of more specific error codes. </ins> 5.4.1.

Related discussion:
text: QUIC includes the following statement: I like this. (No accident. I wrote it.) Should HTTP/2 include a similar statement? We have PROTOCOL_ERROR, which has a definition compatible with this statement, so I guess we're already there on as far as allowing a generic code goes. Any sense in saying it explicitly?
Yeah, I think this is sensible text to include.
Reads clearly, captures the intent.
Code change:
Let URL be the URL of the dictionary request. Let PATTERN be an instance of the URLPattern class constructed by <del> setting input=MATCH, and baseURL=URL (see URLPATTERN-CLASS). </del> <ins> setting input=MATCH, and baseURL=URL (see URLPATTERN). </ins> If the hasRegExpGroups attribute of PATTERN is TRUE then return <del> FALSE (see URLPATTERN-REGEXP). </del> <ins> FALSE (see URLPATTERN). </ins> Return TRUE.

Related discussion:
text: This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.
Code change:
A <del> header field-value of "*" always fails to match. </del> <ins> header field value containing a member "*" always fails to match. </ins> The stored response with matching selecting header fields is known as the selected response.

Related discussion:
text: That's
says: I think this should be:
Discussed in Basel. The current ABNF defines as a special value which only invokes the semantics when it's the entire field value; otherwise, it becomes a field name (since it's valid according to the field-name ABNF) and effectively gets ignored (since it's not going to be in normal requests). An alternative way of looking at it is to say that it's a special field name that, when it occurs anywhere in the Vary field value, it effectively turns off caching, no matter what the rest of the field value contains. Waiting for data to see what implementations do. Either way, this needs some examples in the spec, since it's so special.
See some results . It looks like all browser engines will turn off caching if `.
Duplicate of ? See also .
NAME shhh, we're trying to inflate our issue stats.
Code change:
Abstract <del> Generalized Software Supply Chain Use Case Descriptions </del> <ins> This document includes a collection of representative Software Supply Chain Use Case Descriptions.  These use cases aim at identifying software supply chain problems that the industry faces today and acts as a guideline for developing a comprehensive solution for these class of scnenarios. </ins> 1.

Related discussion:
text: Please note the template is based on: https://rfc-URL We would like to stick to this template and progress this document!
Code change:
The "hashes" value is optional and defaults to (sha-256). <del> 2.1.5. </del> <ins> 2.1.7. </ins> <del> 2.1.5.1. </del> <ins> 2.1.7.1. </ins> A response that contained a response header: <del> Would specify matching any URL with a path prefix of /product/ on the same Origin as the original request, expiring as a dictionary in 7 days independent of the cache lifetime of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </del> <ins> Would specify matching any document request for a URL with a path prefix of /product/ on the same Origin as the original request, expiring as a dictionary in 7 days independent of the cache lifetime of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </ins> <del> 2.1.5.2. </del> <ins> 2.1.7.2. </ins> A response that contained a response header:

Related discussion:
text: This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,
Code change:
a verifiable credential for authentication.  The attacker creates a phishing website which will in real time capture log-in QR Codes from the original website and present these to the user.  The attacker <del> tries to get the user to use the phishing website using an e-mail campaign etc.  The user scans the QR code on the phishing website, invokes their digital wallet and presents their credentials.  Once the credentials are presented, the original session from the attackers device is authorized with the user's credentials. </del> <ins> tries to get the user to use the phishing website by sending messages by e-mail or other messaging technologies.  The user scans the QR code on the phishing website, invokes their digital wallet and presents their credentials.  Once the credentials are presented, the original session from the attackers device is authorized with the user's credentials. </ins> 4.3.10.

Related discussion:
text: Adressing feedback in issue
NAME
Feedback from Dean Saxe on WGLC Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? URL
Fixed in Rifaat, I have a few minor nits in the doc, nothing of significant concern for WGLC. When describing the visuals documenting the flows, there is a step that includes “The user authenticates to the authorization server”. In each case this should include verbiage to indicate that this is only necessary if the user is unauthenticated, e.g. “If unauthenticated, the user authenticates to the authorization server…”. Specific sections include 3.1.1, 3.1.2, 4.1.1, 4.1.2 Section 3.1.3 the final sentence notes the authorization data may be delivered as a text message or via a mobile app. This is inconsistent with the methods mentioned in the first paragraph, which includes email and text messages. I suggest being clear that these are example mechanisms and not a full list of mechanisms by which codes can be delivered. Section 3.3.1 the first sentence should note that the QR code is associated with the particular service (Netflix, AppleTV, Disney+). Readers could assume that the QR codes originate from the TV manufacturer’s service alone as written. Section 4.3.9 reads, “… using an e-mail campaign etc.” Should this be rewritten, “using an e-mail campaign, for example.”? Section 6.2.3 discusses FIDO CTAP 2.2. This document is still in review draft 01. We should note that the document is not final as of today. Section 6.2.3.5 could be softened a bit. The first sentence should include, “… and a suitable FIDO credential is not available on the consumption device.” In most patterns, this mechanism is used to bootstrap a new credential on the device, rather than using this mechanism for authN every time. Authors, if you have any questions please let me know.
Code change:
a verifiable credential for authentication.  The attacker creates a phishing website which will in real time capture log-in QR Codes from the original website and present these to the user.  The attacker <del> tries to get the user to use the phishing website using an e-mail campaign etc.  The user scans the QR code on the phishing website, invokes their digital wallet and presents their credentials.  Once the credentials are presented, the original session from the attackers device is authorized with the user's credentials. </del> <ins> tries to get the user to use the phishing website by sending messages by e-mail or other messaging technologies.  The user scans the QR code on the phishing website, invokes their digital wallet and presents their credentials.  Once the credentials are presented, the original session from the attackers device is authorized with the user's credentials. </ins> 4.3.10.

Related discussion:
text: Thanks, -dhs Dean H. Saxe, CIDPRO (he/him) Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS) E: EMAIL | M: 206-659-7293 From: OAuth on behalf of Rifaat Shekh-Yusef Date: Monday, April 22, 2024 at 7:57 AM To: oauth Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. We have not received any feedback on this document so far. This is a reminder to review and provide feedback on this document. If you reviewed the document, and you do not have any comments or concerns, it would be great if you can send an email to the list indicating that. Regards, Rifaat All, This is a WG Last Call for the Cross-Device Flows BCP document. URL Please, review this document and reply on the mailing list if you have any comments or concerns, by April 29th. Regards, Rifaat & Hannes
Code change:
2.2. <ins> An individual member in the value of a Dictionary Structured Field is identified by the lowercased field name, followed by a semicolon "":"", followed by the member name.  An individual member in the value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in Section 4.1.2 of StructuredFields on a Dictionary containing only that member. 2.2.1. This section contains non-normative examples of canonicalized values for Dictionary Structured Field Members given the following example header field, whose value is assumed to be a Dictionary: The following table shows example canonicalized values for different content identifiers, given that field: 2.3. A prefix of a List Structured Field consisting of the first N members in the field's value (where N is an integer greater than 0 and less than or equal to the number of members in the List) is identified by the lowercased field name, followed by a semicolon "":"", followed by N expressed as an Integer String.  A list prefix is canonicalized by applying the serialization algorithm described in Section 4.1.1 of StructuredFields on a List containing only the first N members as specified in the list prefix, in the order they appear in the original List. 2.3.1. This section contains non-normative examples of canonicalized values for list prefixes given the following example header fields, whose values are assumed to be Dictionaries: The following table shows example canonicalized values for different content identifiers, given those fields: 2.4. </ins> The signature's Creation Time (signature-metadata) is identified by <del> the "(created)" identifier. </del> <ins> the "*created" identifier. </ins> Its canonicalized value is an Integer String containing the signature's Creation Time expressed as the number of seconds since

Related discussion:
text: Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)
Code change:
idle connection is still functional.  PING frames can be sent from any endpoint. <del> PING frames consist of an arbitrary, variable-length sequence of octets.  Receivers of a PING send a response PING frame with the PONG </del> <ins> In addition to the frame header, PING frames MUST contain 8 additional octets of opaque data.  A sender can utilize this payload in any manner it wishes but MUST include the octets even if they are unused.  Receivers of a PING send a response PING frame with the PONG </ins> flag set and precisely the same sequence of octets back to the sender as soon as possible.

Related discussion:
text: As discussed in the interim, 8-byte PING frame, opaque octets that MUST be included regardless of whether they are used.
Code change:
client, then inform the upstream HTTP server of the presence of valid authentication. <del> The intermediary can export the nonce (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. </del> <ins> The intermediary can export the nonce and verification (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. </ins> The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document.

Related discussion:
text: In the current draft, the header is composed as: The server computes the nonce from the TLS key material exporter and verifies the signature. This doesn't actually guarantee freshness, because its possible for parties to construct signatures which are valid for any message/nonce. This means that a party which does not have access to the TLS Export material can still inject a valid Auth header. I don't think that's a major problem, but it is a bit unintuitive and its hard to predict how drafts like this will eventually get deployed. A simple fix would be in to add an additional parameter, say which is or similar and have servers check its been correctly computed. This ensures that only parties that can access TLS key material can inject valid headers. Behind the scenes, this attack / fix works because hash functions have to be collision resistant for all inputs, whereas signatures don't have to satisfy any properties if the associated public key was generated maliciously. has a longer discussion.
Thanks! This sounds like an easy fix. Instead of a hash, we could also generate more bytes from the key exporter and use some for the nonce and some for the parameter
Wrote up to fix this
Code change:
2.1.3. <del> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present and has a string length longer than zero then it MUST be sent to the server in a "Dictionary-ID" request header when the dictionary is advertised as being available. </del> <ins> The "id" value of the Use-As-Dictionary header is a String value that specifies a server identifier for the dictionary.  If an "id" value is present and has a string length longer than zero then it MUST be sent to the server in a "Dictionary-ID" request header when the dictionary is advertised as being available. </ins> The server identifier MUST be treated as an opaque string by the client.

Related discussion:
text: Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."
Code change:
or by replacing an existing one.  Before doing such a modification, it has to be ensured that the header table size will stay lower than or equal to the SETTINGS_HEADER_TABLE_SIZE limit (see <del> parameter.negotiation).  To achieve this, repeatedly, the first entry </del> <ins> parameter.negotiation).  To achieve this, repeatedly, the last entry </ins> of the header table is removed, until enough space is available for the modification.

Related discussion:
text: We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .