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

Related discussion:
text: signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in signature-multiple. <ins> Applications that make use of content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header field in the request, the server is unable to include a signature that covers the request's content. </ins> 7.3. 7.3.1.
Code change:
[ ] to obsolete the IANA Digest Algorithms Registry or define another registry [ ] it can stay as historical ~identify whether and how it should stay~ [x] if it should stay, the note below should be fixed.
I think it's easiest to just add a request to update the note in the IANA considerations of digest spec. E.g. current: something like
cc: NAME guidance welcome
Note: this has been fixed. the IANA Digest Algorithm Registry Note not to mention "message body" since it's not even mentioned in RFC3230.
NAME NAME what is expected to happen to URL after Digest's deprecation? Can it be marked as "historical" to avoid issues with current Digest implementers?
Yes, IANA can be instructed to do that in IANA Considerations.

Related discussion:
text: algorithm-table.  The procedure for new registrations is provided in algorithms. <ins> 7.3. IANA is requested to deprecate the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry at https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2]. </ins> 8.  References 8.1.  URIs [1] https://www.iana.org/assignments/http-digest-hash-alg/ <ins> [2] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml </ins>
Code change:
Add requirement for unprompted auth to use TLS 1.2 with extended master secret or later. Fixes httpwg/http-extensions
Please mark this PR as fixing the corresponding issue
From Ilari Liusvaara on the :

Related discussion:
text: exporter is used to generate a 32-byte key which is then used as a nonce. <ins> Because the TLS keying material exporter is only secure for authentication when it is uniquely bound to the TLS session RFC7627, the Signature and HMAC authentication schemes require either one of the following properties: The TLS version in use is greater or equal to 1.3 TLS. The TLS version in use is greater or equal to 1.2 and the Extended Master Secret extension RFC7627 has been negotiated. Clients MUST NOT use the Signature and HMAC authentication schemes on connections that do not meet one of the two properties above.  If a server receives a request that uses these authentication schemes on a connection that meets neither of the above properties, the server MUST treat the request as malformed. </ins> 3. The "Unprompted-Authentication" header field allows a user agent to
Code change:
Fixes httpwg/http-extensions.
Please mark this PR as fixing the corresponding issue
From NAME on the :
The conservative thing to do here would be to insist that the key be unique to the protocol. We have domain separation in our outputs, so we don't need to worry about unprompted auth messages being used in cross-protocol attacks, but a different protocol (that doesn't use context strings) could possibly be induced to generate unprompted auth messages. We also need to worry about key compromise. Imagine a protocol that leaks the private / secret key, that shares a key with unprompted auth. This doesn't even need to be a bug, it could be a commit-before-reveal style protocol. (Obviously that's a pathological example, but it shows we can't assume composability with all protocols) If we want to do a formal analysis (which I do) I think we need to be conservative here.
SGTM

Related discussion:
text: the corresponding key, so binding authentication to requests would not provide much benefit in practice. <ins> Key material used for authentication in unprompted authentication, whether symmetric or asymmetric MUST NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. </ins> 8. 8.1.
Code change:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Related discussion:
text: mechanism QUIC-TLS. The user agent leverages a TLS keying material exporter KEY-EXPORT to <del> generate a nonce which can be signed using the user's key.  The </del> <ins> generate a nonce which can be signed using the chosen key.  The </ins> keying material exporter uses a label that starts with the characters "EXPORTER-HTTP-Unprompted-Authentication-" (see schemes for the labels and contexts used by each scheme).  The TLS keying material
Code change:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Related discussion:
text: 4.1. <del> The OPTIONAL "u" (user ID) parameter is a byte sequence that specifies the user ID that the user agent wishes to authenticate. </del> <ins> The OPTIONAL "k" (key ID) parameter is a byte sequence that identifies which key the user agent wishes to use to authenticate. This can for example be used to point to an entry into a server-side database of known keys. </ins> 4.2. The OPTIONAL "p" (proof) parameter is a byte sequence that specifies the proof that the user agent provides to attest to possessing the <del> credential that matches its user ID. </del> <ins> credential that matches its key ID. </ins> 4.3.
Code change:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Related discussion:
text: 5.1. The "Signature" HTTP Authentication Scheme uses asymmetric <del> cryptography.  User agents possess a user ID and a public/private key pair, and origin servers maintain a mapping of authorized user IDs to their associated public keys.  When using this scheme, the "u", "p", </del> <ins> cryptography.  User agents possess a key ID and a public/private key pair, and origin servers maintain a mapping of authorized key IDs to their associated public keys.  When using this scheme, the "k", "p", </ins> and "s" parameters are REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication- Signature" and the associated context is empty.  The nonce is then signed using the selected asymmetric signature algorithm and transmitted as the proof directive. <del> For example, the user ID "john.doe" authenticating using Ed25519 </del> <ins> For example, the key ID "basement" authenticating using Ed25519 </ins> ED25519 could produce the following header field (lines are folded to fit): 5.2. The "HMAC" HTTP Authentication Scheme uses symmetric cryptography. <del> User agents possess a user ID and a secret key, and origin servers maintain a mapping of authorized user IDs to their associated secret key.  When using this scheme, the "u", "p", and "h" parameters are </del> <ins> User agents possess a key ID and a secret key, and origin servers maintain a mapping of authorized key IDs to their associated secret key.  When using this scheme, the "k", "p", and "h" parameters are </ins> REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication-HMAC" and the associated context is empty.  The nonce is then HMACed using the selected HMAC algorithm and transmitted as the proof directive. <del> For example, the user ID "john.doe" authenticating using HMAC-SHA-512 </del> <ins> For example, the key ID "basement" authenticating using HMAC-SHA-512 </ins> SHA could produce the following header field (lines are folded to fit):
Code change:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Related discussion:
text: 7. <del> Unprompted Authentication allows a user-agent to authenticate to an </del> <ins> Unprompted Authentication allows a user agent to authenticate to an </ins> origin server while guaranteeing freshness and without the need for the server to transmit a nonce to the user agent.  This allows the server to accept authenticated clients without revealing that it
Code change:
The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.

Related discussion:
text: extensions. The authentication proofs described in this document are not bound to <del> individual HTTP requests; if the same user sends an authentication proof on multiple requests they will all be identical.  This allows </del> <ins> individual HTTP requests; if the key is used for authentication proofs on multiple requests they will all be identical.  This allows </ins> for better compression when sending over the wire, but implies that client implementations that multiplex different security contexts over a single HTTP connection need to ensure that those contexts
Code change:
OK with me.
doesn't return . Without that, the number itself isn't necessarily enough to determine what the type is (necessary for parsing Date).
So what we need to prevent here is that: parses as date.
I don't think this is necessary; the result of Parsing a... already has a type, and that's already checked in Date parsing. Nevertheless, see PR...
The PR isn't correct; it fails to account for the different return signature everywhere it's called. Fixing that is much more invasive, so I'm going to push back on this more strongly; it isn't necessary. What Parsing an Integer or Decimal returns is typed; it's either an integer or a decimal. This can be seen in other places as well -- e.g., in Serializing a Bare Item ("If input_item is an Integer, return..."). No change is necessary here.
NAME NAME can I close this with no action, or should we take it to the list, or...?
So your assertion is that a value inherently carries a type? That's not obvious to me.
Yes. defines those types; the serialisation algorithms take them as parameters, and the parsing algorithms return them. That's reflected in the introduction text for each individual algorithm.

Related discussion:
text: If type is "integer": <del> Parse input_number as an integer and let output_number be the product of the result and sign. </del> <ins> Let output_number be an Integer that is the result of parsing input_number as an integer. </ins> Otherwise:
Code change:
OK with me.
doesn't return . Without that, the number itself isn't necessarily enough to determine what the type is (necessary for parsing Date).
So what we need to prevent here is that: parses as date.
I don't think this is necessary; the result of Parsing a... already has a type, and that's already checked in Date parsing. Nevertheless, see PR...
The PR isn't correct; it fails to account for the different return signature everywhere it's called. Fixing that is much more invasive, so I'm going to push back on this more strongly; it isn't necessary. What Parsing an Integer or Decimal returns is typed; it's either an integer or a decimal. This can be seen in other places as well -- e.g., in Serializing a Bare Item ("If input_item is an Integer, return..."). No change is necessary here.
NAME NAME can I close this with no action, or should we take it to the list, or...?
So your assertion is that a value inherently carries a type? That's not obvious to me.
Yes. defines those types; the serialisation algorithms take them as parameters, and the parsing algorithms return them. That's reflected in the introduction text for each individual algorithm.

Related discussion:
text: If the number of characters after "." in input_number is greater than three, fail parsing. <del> Parse input_number as a decimal number and let output_number be the product of the result and sign. </del> <ins> Let output_number be a Decimal that is the result of parsing input_number as a decimal number. Let output_number be the product of output_number and sign. </ins> Return output_number.
Code change:
Based on
Right now the document contains the (user ID) parameter. Thinking about it some more, this is more about describing the key than the user, see httpwg/http-extensions. In addition to that change, we should add text warning about the tracking risks or this and how to avoid these issues.
It seems to me that there's room for both user-ID type uses for the "u" (in the employee remote access model, e.g.) as well as the more indirect key-indicator type uses (in the Internet Freedom model of distributed communities). I'm especially interested in the latter - use cases where users can prove they are in possession of a valid secret without requiring a hard user identifier (one that attaches them to a permanent/billable/irrevocable external identifier). The draft does not currently provide an Authentication Scheme that directly offers this latter capability, however (though it's possible to overload on the "u"/"k" parameter if the server and client agree on the scheme for doing that). I'm unable to steelman the case for "u" (or "k") being a "super-cookie". The imagined use cases in my head have this scheme tied to a single service provider and employed on the first hop. I don't understand the language being used in the list commentary on this topic (e.g., "Each site (*) could get a different key pair and key identifier."). My assumption has been sites issue credentials as they see fit without reference to any other site. The commentary implies to me that there is some overriding entity distributing credentials to many sites (a la Privacy Pass). I did not think Unprompted Authentication addresses that space. Further, if indeed we need to address that space, it seems to me the "super-cookie" burden of proof is then with THAT scheme, not Unprompted Authentication. The "document it" point might be the salient one: "This is probably another case where documenting a little more detail about the usage context could help.". Here's a start: Sites offering Unprompted Authentication are able to link requests from individuals clients via the Authentication Schemes provided. However, requests as not linkable across other sites if the credentials used are private to individual sites.

Related discussion:
text: protocols.  Doing so can undermine the security guarantees of the authentication. <ins> Sites offering Unprompted Authentication are able to link requests that use the same key for the Authentication Schemes provided. However, requests are not linkable across other sites if the keys used are private to the individual sites using Unprompted Authentication. </ins> 9. 9.1.
Code change:
Ilari suggests on the :
to this. It's been implemented for exported authenticators and isn't too challenging.

Related discussion:
text: Since the Signature and HMAC HTTP Authentication Schemes leverage TLS keying material exporters, their output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support <del> this specification will validate the authentication received from the client themselves, then inform the upstream HTTP server of the presence of valid authentication using some other mechanism. </del> <ins> this specification have two options: The intermediary can validate the authentication received from the client, then inform the upstream HTTP server of the presence of valid authentication. The intermediary can export the nonce (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. </ins> 8.
Code change:
s/ise-case/use case e.g. -> e.g., nit pass

Related discussion:
text: However, transport-oriented integrity provides a limited utility because it is opaque to the application layer and only covers the extent of a single connection.  HTTP messages often travel over a <del> chain of separate connections, in between connections there is a </del> <ins> chain of separate connections.  In between connections there is a </ins> possibility for unintended or malicious data corruption.  An HTTP integrity mechanism can provide the means for endpoints, or applications using HTTP, to detect data corruption and make a choice
Code change:
s/ise-case/use case e.g. -> e.g., nit pass

Related discussion:
text: The HTTP fields defined in this document can be used for HTTP integrity.  Senders choose a hashing algorithm and calculate a digest <del> from an input related to the HTTP message, the algorithm identifier </del> <ins> from an input related to the HTTP message.  The algorithm identifier </ins> and digest are transmitted in an HTTP field.  Receivers can validate the digest for integrity purposes.  Hashing algorithms are registered <del> in the "Hash Algorithms for HTTP Digest Fields" (see algorithms). </del> <ins> in the "Hash Algorithms for HTTP Digest Fields" registry (see establish-hash-algorithm-registry). </ins> Selecting the data on which digests are calculated depends on the use <del> case of HTTP messages.  This document provides different fields for HTTP representation data and HTTP content. </del> <ins> case of the HTTP messages.  This document provides different fields for HTTP representation data and HTTP content. </ins> <del> There are use-cases where a simple digest of the HTTP content bytes </del> <ins> There are use cases where a simple digest of the HTTP content bytes </ins> is required.  The "Content-Digest" request and response header and trailer field is defined to support digests of content (RFC9110); see content-digest. <del> For more advanced use-cases, the "Repr-Digest" request and response </del> <ins> For more advanced use cases, the "Repr-Digest" request and response </ins> header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to selected representation data (RFC9110).  Basing "Repr-Digest" on the <del> selected representation makes it straightforward to apply it to use- </del> <ins> selected representation makes it straightforward to apply it to use </ins> cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see
Code change:
s/ise-case/use case e.g. -> e.g., nit pass

Related discussion:
text: Integer, and List. The definitions "representation", "selected representation", <del> "representation data", "representation metadata", "user agent" and </del> <ins> "representation data", "representation metadata", "user agent", and </ins> "content" in this document are to be interpreted as described in RFC9110. This document uses the line folding strategies described in FOLDING. Hashing algorithm names respect the casing used in their definition <del> document (e.g.  SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g. "sha", "crc32c"). </del> <ins> document (e.g., SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g., "sha", "crc32c"). </ins> The term "checksum" describes the output of the application of an algorithm to a sequence of bytes, whereas "digest" is only used in
Code change:
s/ise-case/use case e.g. -> e.g., nit pass

Related discussion:
text: Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests or methods such as HEAD, while the way the content is transferred "on <del> the wire" is dependent on other transformations (e.g. transfer </del> <ins> the wire" is dependent on other transformations (e.g., transfer </ins> codings for HTTP/1.1 - see RFC9112).  To help illustrate HTTP representation concepts, several examples are provided in resource- representation.
Code change:
s/ise-case/use case e.g. -> e.g., nit pass

Related discussion:
text: reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The "standard" status is not suitable for an algorithm that is known to <del> be weak, broken or experimental.  If a registration request attempts </del> <ins> be weak, broken, or experimental.  If a registration request attempts </ins> to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional".
Code change:
s/ise-case/use case e.g. -> e.g., nit pass

Related discussion:
text: multiple hops or system boundaries.  Even a simple mechanism for end- to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to <del> a HTML parser, video player etc. for parsing. </del> <ins> an HTML parser, video player, etc. for parsing. </ins> Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could
Code change:
s/ise-case/use case e.g. -> e.g., nit pass

Related discussion:
text: additional considerations when Integrity fields are included in this set. <del> There are no restrictions placed on the type or format of digitial </del> <ins> There are no restrictions placed on the type or format of digital </ins> signature that Integrity fields can be used with.  One possible approach is to combine them with HTTP Message Signatures SIGNATURES. <del> Digests explicitly depend on the "representation metadata" (e.g. the </del> <ins> Digests explicitly depend on the "representation metadata" (e.g., the </ins> values of "Content-Type", "Content-Encoding" etc).  A signature that protects Integrity fields but not other "representation metadata" can expose the communication to tampering.  For example, an actor could