jiebi/CodeConvo huggingface dataset:
Code change:
information leakage to recover any meaningful amount of information (see PETAL). <del> 8.2. </del> <ins> 8.3. </ins> An attacker can try to cause an endpoint to exhaust its memory. HPACK is designed to limit both the peak and state amounts of memory

Related discussion:
text: I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.
Code change:
1.2. <del> TODO If the service provides multiple applications, then it creates an additional burden to build and maintain native login flows within each application.  Instead, the redirect-based authorization code flow removes the burden of implementing login flows from each application by centralizing all aspects of logging in at the authorization server. See phishing section below. </del> <ins> It's important to remember that the scope of this specification is limited to 1st party native applications.  Please review the entirety of security-considerations and when more than one 1st party native application is supported, multiple-applications. </ins> 2.

Related discussion:
text: I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.
Code change:
unordered set of references to entries in the header table.  This is used for the differential encoding of a new header set. <del> A header set is a potentially ordered group of header fields that are encoded jointly.  A complete set of key-value pairs contained in a HTTP request or response is a header set. </del> <ins> A header set is an unordered group of header fields that are encoded jointly.  A complete set of key-value pairs contained in a HTTP request or response is a header set. </ins> A header field can be represented in encoded form either as a literal or as an index (see header.representation).

Related discussion:
text: Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.
Code change:
priority.  Expressing priority is therefore only a suggestion. A server can use priority signals along with other inputs to make <del> scheduling decisions.  No guidance is provided about how this can or should be done.  Factors such as implementation choices or deployment environment also play a role.  Any given connection is likely to have many dynamic permutations.  For these reasons, there is no unilateral perfect scheduler and this document only provides some basic recommendations for implementations. </del> <ins> scheduling decisions.  Factors such as implementation choices or deployment environment also play a role.  Any given connection is likely to have many dynamic permutations.  For these reasons, there is no unilateral perfect scheduler.  This document provides some basic, non-exhaustive, recommendations for how servers might act on priority parameters.  It does not describe in detail how servers might combine priority signals with other factors. </ins> Clients cannot depend on particular treatment based on priority signals.  Servers can use other information to prioritize responses.

Related discussion:
text: Addresses Ea of Bob comments that the "no guidance is provided" sounds like it is in conflict with the rest of the section that includes some normative recommendations. The intent of this text was to highlight there is no (or at least very little) about how servers are supposed to combine priority parameters with the million other things that they have to worry about. This change shuffles the sentences around to try and make the original intent clearer.
This is much better than the original. Thank you for the PR.
Code change:
that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma <del> and </del> <ins> (",") and optional whitespace ( </ins> <del> (optional whitespace).  For consistency, use comma SP. </del> <ins> , defined in whitespace).  For consistency, use comma SP. </ins> The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a

Related discussion:
text: Used in 5.6.1, defined in 5.6.3. Minimally make the forward reference explicit.
And 5.3.
Code change:
If the authorization grant is in the form of a JWT bearer token, the client SHOULD use the "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" as defined in <del> RFC7521.  Otherwise, the client SHOULD request an access token using </del> <ins> RFC7523.  Otherwise, the client SHOULD request an access token using </ins> the "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" as defined in RFC7521 (Section 4.1).  For the purpose of this specification the following descriptions apply:

Related discussion:
text: Fixes RFC7523 reference (was RFC7521)
Feedback from Brian Campbell The reference in the first sentence of [URL] would be 7523 rather than 7521 (I got rather confused reading that paragraph :-) ).
Code change:
commitment interval starts when the commitment is received and authenticated and runs for a number of seconds equal to value of the "tls-commit" member, less the current age of the http-opportunistic <del> response (as defined in Section 4.2.3 of RFC7234).  A client SHOULD avoid sending requests via cleartext protocols or to unauthenticated alternative services for the duration of the commitment interval, except to discover new potential alternatives. </del> <ins> response (as defined in Section 4.2.3 of RFC7234).  Note that the commitment interval MAY exceed the freshness lifetime of the "http- opportunistic" resource. A client SHOULD avoid sending requests via cleartext protocols or to unauthenticated alternative services for the duration of the commitment interval, except to discover new potential alternatives. </ins> A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware

Related discussion:
text: We make this decision explicitly, and we don't want to imply that just because you don't have a fresh "http-opportunistic" resource, any commitment is shortened as a result (which is a reasonable interpretation based on the current text).
Code change:
Let this_key be the result of running Parsing a Key (parse-key) with input_string. <del> If dictionary already contains the name this_key, there is a duplicate; fail parsing. </del> If the first character of input_string is "=": Consume the first character of input_string.

Related discussion:
text: NAME thanks for the review, see latest commit. is talking about the abstract model for dictionaries, so they are required to be unique. I've removed "required to be" so that people don't misread this.
allows a sender to generate multiple header fields with the same name, if the field is defined as a comma-separated list [i.e., #(values)], and that such duplicates are semantically equivalent to them concatenated into a single header field. I think that this property has been useful for us, when annotating header fields. Can we allow such duplicates for Structured Headers too, when a list or a dictionary is being used? Note that we have merged based on the assumption that it is okay to require the consumer of SH header fields to have the knowledge on what the top type is.
That's always been the intent; are you saying that we should have text specifically enabling this for serialisation of dictionaries and lists?
Good to know that that has been the intent. Yes, I think we should clarify that explicitly for dictionaries and lists, because RFC 7230 can be interpreted to allow duplicates only for those using notation (which we do not use in SH). Also, it might be a good idea to revisit the rule for duplicate dictionary values, as I'd assume that people would try to append a header field without checking the values that already exist. IMO, the rule should be that the dictionary element that appears later overwrites the one that precedes.
PTAL
NAME Thank you! cb76bf1 looks good to me. Is your intention to retain the forbidding of duplicate dictionary values, even when the dictionary members are split into different header fields? For example, in the hypothetical world where cache-control is sent using SH, all the cache-control directives in the following example would be considered invalid and ignored. I am not strongly opposed to that, though my weak preference goes to requiring decoders to use the dictionary member that appears later when there is a collision.
NAME the problem is that ignoring duplicates can cause security issues for some headers (the headers that WebAppSec in the W3C are particularly sensitive about this). The only way to address it would be to add a flag to the API to control what to do with dups -- but that adds complexity (more to specifications than to implementations, but still). I'm not crazy about that; what do others think?
Code change:
Let this_key be the result of running Parsing a Key (parse-key) with input_string. <del> If dictionary already contains the name this_key, there is a duplicate; fail parsing. </del> If the first character of input_string is "=": Consume the first character of input_string.

Related discussion:
text: NAME Thank you for the explanation. But I wonder if it is actually the case that what those specifications forbid is having duplicate header fields, rather than forbidding duplicate dictionary members (or maybe both). By quickly searching on URL, I was able to find the prohibition on having duplicate header fields, but could not find a rule that forbids having duplicate policy tokens. Assuming that at least such specifications forbid having duplicate header fields, and based on the fact that SH draft does not forbid that (when a list or dictionary is used), I think there is no reason for the SH draft to forbid having duplicate dictionary members.
NAME NAME any comments re: the above? Specifically, if SH swallowed duplicate dictionary values rather than raising an error, would that be a concern from a security standpoint?
Given a header like , it seems like we have a few options: Fail parsing. Return . Return . Return . I think I can come up with arguments for any of these options, though I'd find 4 a bit surprising as a spec author, insofar as I'd have to deal with unexpected lists for all my dictionary values. of URL skips duplicate CSP directives. That is, it picks 2 out of the list above, choosing to retain only the first value for a given name. I do wonder whether that was the right decision, but it is consistent across browsers and provides developers with predictable behavior. We throw a warning into the console in Chrome for this case, and that's probably Good Enough.
This sounds like a bad API for working with structured header values. I'd hope that eventually we offer better APIs for operating on (what Fetch calls) header lists. I think historically there were some arguments for always using first or last based on likelihood of where header injection would happen. But I'm not sure how sound any of that rationale was. I don't think a client can reasonably protect against it. Therefore, what's most important is that the result is unambiguous and that it doesn't matter how you "spell" multiple values (commas or multiple fields or a combination) in the traditional header syntax.
Anyone have preferences between Mike's options 2 and 3?
NAME I think option 3 is preferable, because that would allow server administrators to override parameters by appending header fields.
Code change:
Let this_key be the result of running Parsing a Key (parse-key) with input_string. <del> If dictionary already contains the name this_key, there is a duplicate; fail parsing. </del> If the first character of input_string is "=": Consume the first character of input_string.

Related discussion:
text: I agree that NAME that it's a hack, though sadly, I do not think we can get rid of such practice through API design on the server side. People are so used to dealing with each line of header fields than working through a API that deals with a set of header fields as a whole.
There are CDNs that offer JS or Wasm APIs effectively using et al. Once structured header values are more baked and have dedicated on-the-wire support I'd definitely like to add first-class support to objects.
I weakly prefer "first one wins" (2). It's only an aesthetic preference, however: I don't have any principled reason to pick 2 over 3 or vice-versa. I can live with either for the reasons NAME spells out.
If I had pick, I probably agree with NAME reasoning.
PTAL
Thank you for the changes. Looks good to me now. FWIW, I was bit surprised to learn that we do not mention how a duplicate is processed alongside the type definitions in . I checked and now I understand that the formal definition is provided in section 4.
Code change:
or <del> parameter as defined in OIDC. </del> <ins> authorization request parameters as defined in OIDC. </ins> Those extensions will make it possible to implement interoperable step up authentication with minimal work from resource servers,

Related discussion:
text: changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
PushResources contains a thorough description of the use of PUSH_PROMISE frames. <del> The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This </del> <ins> The payload of a PUSH_PROMISE includes a "Promised-Stream-ID".  This </ins> unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see

Related discussion:
text: Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL:
Code change:
allowed to combine values of HTTP fields with any amount of whitespace between the commas, and if this behavior is not accounted for by the verifier, the signature can fail since the signer and <del> verifier will be see a different component value in their respective </del> <ins> verifier will see a different component value in their respective </ins> signature bases.  For robustness, it is RECOMMENDED that signed messages include only a single instance of any field covered under the signature, particularly with the value for any list-based fields

Related discussion:
text: A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?
Code change:
Note that the media type has been changed to "application/octet- stream" to avoid exposing information about the content. <ins> Alternatively (and equivalently), the Content-Type header field can be omitted. </ins> 5.2.

Related discussion:
text: This moves the values that were in the Encryption header field to the start of the payload. This provides a meagre efficiency gain as well as removing the need to have two correlated header fields. This should go most of the way to address WGLC comments.
Looks good to me in general. That said; this removes the parsing weirdness for "Encryption" (good), but not for "Crypto-Key", right?
NAME happy to correct any parsing weirdness, but need to know precisely what it is first.
Code change:
Requirements on cache handling of a received If-None-Match header field are defined in validation.received. <ins> Note that an If-None-Match header field with a list value containing "*" and other values (including other instances of "*") is unlikely to be interoperable. </ins> 8.2.5. The "If-Modified-Since" header field makes a GET or HEAD request

Related discussion:
text: ... for If-Match and If-None-Match.
URL to special-case "*" as top-level construct.
Also need to fix things like to something like
Discussed; intent is to add a note at the end of each section pointing out that the behaviour of multiple/mixed stars is undefined, and that this is a lame way to specify a field.
Code change:
If the cookie-attribute-list contains an attribute with an attribute-name of "Path", set the cookie's path to attribute-value <del> of the last attribute in the cookie-attribute-list with an attribute-name of "Path".  Otherwise, set the cookie's path to the </del> <ins> of the last attribute in the cookie-attribute-list with both an attribute-name of "Path" and an attribute-value whose length is no more than 1024 octets.  Otherwise, set the cookie's path to the </ins> default-path of the request-uri. If the cookie-attribute-list contains an attribute with an

Related discussion:
text: Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.