jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: parameters in specific circumstances, each described in detail in their own sections: <ins> Multiple parameters MAY be specified together, though some combinations are redundant or incompatible.  For example, the "sf" parameter's functionality is already covered when the "key" parameter is used on a dictionary item.  The "bs" parameter, which requires the raw field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </ins> Additional parameters MAY be defined in a registry established in param-registry. 2.1.1. If the value of the the HTTP field in question is known by the <del> application to be a structured field (STRUCTURED-FIELDS), the component identifier MAY include the "sf" parameter to indicate it is a known structured field.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED-FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. </del> <ins> application to be a structured field (STRUCTURED-FIELDS), and the expected type of the structured field is known, the signer MAY include the "sf" parameter in the component identifier.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED- FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. Processing of this parameter MUST occur after multiple field values have been combined into a single List or Dictionary structure. </ins> For example, the following dictionary field is a valid serialization:
Code change:
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

Related discussion:
text: Dictionary is identified by using the parameter "key" and the Dictionary member key as a String value. <ins> Processing of this parameter MUST occur after multiple field values have been combined into a single List or Dictionary structure. </ins> An individual member value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in STRUCTURED-FIELDS on the "member_value" and its parameters, without
Code change:
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

Related discussion:
text: base by adding the "req" parameter to the component identifier. This parameter can be applied to both HTTP fields and derived <del> components with the same semantics.  The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message. </del> <ins> components that target the request, with the same semantics.  The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message instead of the target response message to which the signature is applied. </ins> Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same
Code change:
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

Related discussion:
text: 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
Code change:
Section 1.1 is currently a bit confusing, because it leaves out sections, and does not present them in order (likely the cause of a recent re-org).
NAME do we need it?
it should either make sense, or should be removed.
NAME if it's not required, I think that the document is fine without.
mnot asked us to add one a while back, which I think helped at that point. Editorial changes in the meantime have had an effect though, so I tried to add some colour to the structure in URL Preview at URL The intention is that people can launch of from here to focus on bits they might need, like the field definitions or example. Since security and IANA sections are standard, mentioning them seems superfluous. If the opinion is that the proposal doesn't help, let's just remove the section.

Related discussion:
text: This document is structured as follows: <del> content-digest defines the Content-Digest request and response header and trailer field, </del> <ins> New request and response header and trailer field definitions. </ins> <del> representation-digest defines the Repr-Digest request and response header and trailer field, </del> <ins> content-digest (Content-Digest), </ins> <del> want-fields defines the Want-Repr-Digest and Want-Content-Digest request and response header and trailer field, </del> <ins> representation-digest (Repr-Digest), and </ins> <del> algorithms describes algorithms and their relation to the fields defined in this document, </del> <ins> want-fields (Want-Content-Digest and Want-Repr-Digest). </ins> <del> state-changing-requests details computing representation digests, </del> <ins> Considerations specific to representation data integrity. </ins> <del> examples-unsolicited and examples-solicited provide examples of using Repr-Digest and Want-Repr-Digest. </del> <ins> state-changing-requests (State-changing requests), digest-and-content-location (Content-Location), resource-representation contains worked examples of Representation data in message exchanges, and examples-unsolicited and examples-solicited contain worked examples of Repr-Digest and Want-Repr-Digest fields in message exchanges. algorithms bootstraps a new IANA registry hash algorithms and defines registration procedures for future entries. </ins> 1.2.
Code change:
Contains the following changes: Skip parsing the attribute on empty value. Skip parsing the attribute when given Max-Age=- Add mention of "base 10" as guidance for implementers parsing integers from Max-Age. Regarding browser interop: Skip parsing aligns on Safari behavior and against Chrome and Firefox, which will default to session lifetime when any invalid Max-Age attribute is found (based on manual testing, it's difficult to test this with WPT at the moment, see ).

Related discussion:
text: If the attribute-name case-insensitively matches the string "Max- Age", the user agent MUST process the cookie-av as follows. <del> If the first character of the attribute-value is not a DIGIT or a "-" character, ignore the cookie-av. </del> <ins> If the attribute-value is empty, ignore the cookie-av. If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av. </ins> If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av. <del> Let delta-seconds be the attribute-value converted to an integer. </del> <ins> Let delta-seconds be the attribute-value converted to a base 10 integer. </ins> Let cookie-age-limit be the maximum age of the cookie (which SHOULD be 400 days or less, see attribute-max-age).
Code change:
Editorial, since this is merely restating locally what was previously incorporated by reference.
In draft 00 it says: >The layout and semantics of the frame payload are identical to those of the HTTP/2 frame defined in ]. The ORIGIN frame type is 0xc (decimal 12), as in HTTP/2. I think this is the text as it was, before we ran HTTP/3 and HTTP/2 through the process. I think there's some room for editorial improvements to avoid the guesswork. Not least because HTTP/2 Origin has an errata on the payload definition (URL). My suggestion is to just admit defeat and define the whole frame like we do in HTTP/3 or ext priorities, something like Then we can say something like the semantics of the HTTP/3 ORIGIN frame payload are the same as those of the HTTP/2 ORIGIN frame, modulo the differences already described (control streams and whatnot).

Related discussion:
text: the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs. <del> Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose.  Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. The layout and semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  The ORIGIN frame type is 0xc (decimal 12), as in HTTP/2. </del> <ins> The semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. 2.1. The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity.  The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. An Origin-Entry is a length-delimited string.  Specifically, it contains two fields: An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field. An OPTIONAL sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender asserts this connection is or could be authoritative for. </ins> 3.
Code change:
Define a signature algorithm named that indicates the use of ECDSA using curve P-384 DSS and SHA-384. The algorithm description is probably just 3.3.4 with "256" replaced with "384", but should validate that assumption with actual crypto folks.
What's the push for this specific curve to be included here? The reason I ask is that we shouldn't necessarily try to define ALL known algorithms in here, when it's extensible.
I agree with not defining every possible algorithm; however we should include those with known use cases, and AWS intends to use -384. Since the spec isn't finalized and the addition is trivial, it seems reasonable to add it here rather than punting it to an extension spec.

Related discussion:
text: 3.3.5. <ins> To sign using this algorithm, the signer applies the "ECDSA" algorithm defined in FIPS186-4 using curve P-384 with the signer's private signing key and the signature base (create-sig-input).  The hash SHA-384 RFC6234 is applied to the signature base to create the digest content to which the digital signature is applied, ("M").  The signature algorithm returns two integer values, "r" and "s".  These are both encoded as big-endian unsigned integers, zero-padded to 48-octets each.  These encoded values are concatenated into a single 96-octet array consisting of the encoded value of "r" followed by the encoded value of "s".  The resulting concatenation of "(r, s)" is byte array of the HTTP message signature output used in sign. To verify using this algorithm, the verifier applies the "ECDSA" algorithm defined in FIPS186-4 using the public key portion of the verification key material and the signature base re-created as described in verify.  The hash function SHA-384 RFC6234 is applied to the signature base to create the digest content to which the signature verification function is applied, ("M").  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  This value is a 96-octet array consisting of the encoded values of "r" and "s" concatenated in order.  These are both encoded in big-endian unsigned integers, zero-padded to 48-octets each.  The resulting signature value "(r, s)" is used as input to the signature verification function.  The results of the verification function indicate if the signature presented is valid. Note that the output of ECDSA algorithms are non-deterministic, and therefore it is not correct to re-calculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See security-nondeterministic. Use of this algorithm can be indicated at runtime using the "ecdsa- p384-sha384" value for the "alg" signature parameter. 3.3.6. </ins> To sign using this algorithm, the signer applies the "Ed25519" algorithm defined in RFC8032 with the signer's private signing key and the signature base (create-sig-input).  The signature base is
Code change:
Define a signature algorithm named that indicates the use of ECDSA using curve P-384 DSS and SHA-384. The algorithm description is probably just 3.3.4 with "256" replaced with "384", but should validate that assumption with actual crypto folks.
What's the push for this specific curve to be included here? The reason I ask is that we shouldn't necessarily try to define ALL known algorithms in here, when it's extensible.
I agree with not defining every possible algorithm; however we should include those with known use cases, and AWS intends to use -384. Since the spec isn't finalized and the addition is trivial, it seems reasonable to add it here rather than punting it to an extension spec.

Related discussion:
text: Use of this algorithm can be indicated at runtime using the "ed25519" value for the "alg" signature parameter. <del> 3.3.6. </del> <ins> 3.3.7. </ins> If the signing algorithm is a JOSE signing algorithm from the JSON Web Signature and Encryption Algorithms Registry established by
Code change:
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.

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: "keyid": The identifier for the key material as a String value. <del> "context": An application-specific context for the signature as a String value.  This value is used by applications to help identify </del> <ins> "tag": An application-specific tag for the signature as a String value.  This value is used by applications to help identify </ins> signatures relevant for specific applications or protocols. Additional parameters can be defined in the iana-param-contents.
Code change:
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.

Related discussion:
text: Enforcing uniqueness of the "nonce" parameter. <del> Requiring an application-specific value for the "context" parameter. </del> <ins> Requiring an application-specific value for the "tag" parameter. </ins> Application-specific requirements are expected and encouraged.  When an application defines additional requirements, it MUST enforce them
Code change:
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.

Related discussion:
text: present, and applications should not put semantic meaning on the labels themselves.  Instead, additional signature parameters can be used to convey whatever additional meaning is required to be attached <del> to and covered by the signature.  In particular, the "context" parameter can be used to define an application-specific value as described in security-signature-context. </del> <ins> to and covered by the signature.  In particular, the "tag" parameter can be used to define an application-specific value as described in security-signature-tag. </ins> 7.2.6.