jiebi/CodeConvo huggingface dataset:
Code change:
current connection, but MAY use the ORIGIN frame RFC8336 to indicate that not all covered origins will be served. <ins> Certificates supplied by clients MUST NOT be considered by servers when processing a request unless the client explicitly authorizes their use.  Clients MAY send "USE_CERTIFICATE" frame with the "UNSOLICITED" flag set to indicate that an available certificate should be considered on a new request. </ins> Likewise, a party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a

Related discussion:
text: Automatic use of client-proffered certificates was removed a while back; clients can indicate which certificate (if any) they want the server to consider by sending a frame with the flag set. There was text talking about automatic use of the server-proffered certificates, but there wasn't corresponding text disallowing that behavior for client certificates, simply the absence of permission. This PR forbids considering "available" certificates until the client indicates which certificate to use.
The secondary certificates draft leaves the authentication state of exchanges like the following unclear: In stream 1, the client is unambiguously using certificate A in the request to . Is it also using it for ? If the client believes the answer is no, while the server believes the answer is yes, secondary certificates introduces a . Some examples to consider: HTTP/2 cross-name pooling means one connection may service multiple origins. The client may choose to use a client certificate with some origins but not others. The web platform makes both anonymous and credentialed requests (see CORS). Keeping those straight is critical to avoid CSRF attacks. For now, browsers do not pool them due to various problematic connection-level auth mechanisms in HTTP/1.1, but there is discussion on relaxing this for the vast majority of connections that don't use these. This puts a heavier dependency on protocols getting these kinds of details right. This is especially important to make unambiguous because the original renegotiation-based hack for reactive client auth did rely on ambient authority. Once you renegotiated with a certificate, the unwritten interpretation was that all subsequent requests on this connection pick up the certificate. A server implementation may then be tempted to apply a similar logic to client certificates. The spec needs a MUST-level requirement not to do this, and make it clear that this is a server security vulnerability. Instead, client wishing to approximate the original renegotiation-based hack would send proactive frames on subsequent credentialed requests. This is especially important for HTTP/2, where there is both larger scope of pooling from cross-name bits and where multiplexing means we requests overlap temporally.
Code change:
this behavior is specific to HTTP1 and does not apply to other versions of the HTTP specification. <del> Encode the bytes of the resulting field value's ASCII representation as a Byte Sequence. </del> <ins> Encode the bytes of the resulting field value as a Byte Sequence.  Note that most fields are restricted to ASCII characters, but other octets could be included in the value in some implementations. </ins> Add the Byte Sequence to the List accumulator.

Related discussion:
text: Addresses encodings of signature component values for query parameters and field values.
: This seems to be inconsistent with Section 2.2.8 ("Query Parameters"), which could create non-ASCII component values.
FWIW, a query parameter (after application of URL) could contain CR, LF and other control characters.
So we likely need to serialize information extracted from query parameters using some kind of encoding; maybe an SF Byte Sequence.
This is tricky -- originally the query parameters were kept in percent-encoded form but from WG discussion we changed that to just use the unencoded value instead since several percent-encoded forms could be used. However it does look like the unencoded form could end up with problematic values here, so maybe we need to go back to that. I'd rather us use an encoding native to the value rather than inventing something to put on top of it, even trying to re-use the flag we've already got defined for headers.
And we did that because to extract query parameter values, we need a query parser, and that is defined the way it is. I believe that decision was good, we now just need to figure out out to transform the extracted values so that they can be used in the signature base. (And, FWIW, at the end we also should have an example for a case like that in the spec).
In 2.2.8, it might be good to mention that the referenced algorithm only supports query parameters using (percent-escaped) UTF-8 encoding (this came as a surprise to me because I assumed it works the same as the algorithm used for forms decoding).
in 2.1.3: What if the field value contains non-ASCII characters (from obs-text)? Of course that could be considered an error, but I believe the intention is to be able to represent anything here. So the text should refer to the field value as byte sequence, in which case the encoding step would not be needed.
This text was added in response to a comment about needing to know which encoding to put into the byte sequence input, and the commenter suggested ASCII as the base for it. If field values have a well-defined byte sequence that isn't ASCII characters only, then we should refer to whatever that is from the HTTP docs.
Well, field values in HTTP can be anything. It's obsolete, it's deprecated, but that's what it is.
Code change:
this behavior is specific to HTTP1 and does not apply to other versions of the HTTP specification. <del> Encode the bytes of the resulting field value's ASCII representation as a Byte Sequence. </del> <ins> Encode the bytes of the resulting field value as a Byte Sequence.  Note that most fields are restricted to ASCII characters, but other octets could be included in the value in some implementations. </ins> Add the Byte Sequence to the List accumulator.

Related discussion:
text: So we need to deal with it one way or another. I could live with UTF-8, and a note that if the octet sequence does not decode as UTF-8, you can't sign it.
NAME - yes, you can merge and close issues as you wish, you are the editor. But by all means do not submit a new draft until the changes have been reviewed by those who opened the issue. (cc chairs NAME NAME )
As far as I can tell, the changes require percent-encoding only for non-ASCII values. That is, the character U+0080 would get the same encoding as a verbatim "%80" in a field value. I believe this is a problem.
This issue has been addressed. There is no percent encoding needed in this section since the value is taken directly from the bytes of the field in a binary-wrapped representation, and the bytes are encoded using the base64 serialization of a Byte Sequence from Structured Fields:
I'm talking about the simple case, not the one where Byte Sequence encoding is used (yes, the issue title doesn't match anymore).
Ok, opened new issue URL
Code change:
use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement. <del> Each of these functions MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service. </del> For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE).

Related discussion:
text: Closes URL
external attacks and internal misbehavior by some or all of the operators of the Transparency Service. What does the term "each of these functions" refer to?
LGTM to Danny
Code change:
HTTP Client Hints <del> draft-ietf-httpbis-client-hints-08 </del> <ins> draft-ietf-httpbis-client-hints-10 </ins> Abstract

Related discussion:
text: When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).
Code change:
6.4. When a Signed Statement is registered by a Transparency Service a <del> Transparent Statement is created.  This Transparent Statement consists of the Signed Statement and a Receipt.  Receipts are based on COSE Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree- proofs) with an additional wrapper structure that adds the following information: </del> <ins> Receipt becomes available.  When a Receipt is included in a Signed Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree-proofs). Receipts protected headers have additional mandatory fields: : The "crit" header (id: 2) MUST be included and all SCITT- specific headers (version, DID of Transparency Service and Registration Policy) MUST be marked critical </ins>

Related discussion:
text: This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:
Code change:
that received it. Consequently, SNAC routers SHOULD be configurable to not advertise <del> themselves as default routers on the stub network.  Stub routers </del> <ins> themselves as default routers on the stub network.  SNAC routers </ins> SHOULD be configurable to explicitly advertise AIL prefixes on the stub network even if they are advertising as a default router.  The mechanisms by which such configuration can be accomplished are out of

Related discussion:
text: Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)
Code change:
request routing is likely to be safe from side-effects, but other actions might not be. <del> Intermediary servers do not have sufficient information to make this determination, so status describes a way for the origin to signal to them that a particular request isn't appropriate for early data. Intermediaries that accept early data MUST implement that mechanism. </del> <ins> Intermediary servers do not have sufficient information to decide whether early data can be processed, so status describes a way for the origin to signal to them that a particular request isn't appropriate for early data.  Intermediaries that accept early data MUST implement that mechanism. </ins> Note that a server cannot choose to selectively reject early data at the TLS layer.  TLS only permits a server to accept all early data,

Related discussion:
text: NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!
Code change:
2.1. <del> The headers in this document encode certificates as Structured Field Byte Sequences (RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280.  In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </del> <ins> The headers in this document encode certificates as Byte Sequences (RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280.  In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </ins> Note that certificates are often stored encoded in a textual format, such as the one described in RFC7468, which is already nearly <del> compatible with a Structured Field Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </del> <ins> compatible with a Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </ins> 2.2.

Related discussion:
text: try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM
Code change:
less than a previously sent Object ID within a given group in that stream. <del> 7.5. </del> <ins> 7.4. </ins> Sending a track on one stream: <del> Sending a group on one stream, with a unordered object in the group appearing on its own stream. </del> <ins> Sending a peep on one stream: </ins> 8.

Related discussion:
text: I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments
Code change:
The CWT MAY contain other claims. <del> The CWT MUST be digitally signed using an asymmetric cryptographic algorithm.  Relying parties MUST reject the CWT if it is using a Message Authentication Code (MAC) algorithm.  Relying parties MUST reject CWTs with an invalid signature. </del> <ins> The CWT MUST be secured using a cryptographic signature or MAC algorithm.  Relying Parties MUST reject CWTs with an invalid signature. </ins> Relying parties MUST reject CWTs that are not valid in all other respects per "CBOR Web Token (CWT)" RFC8392. Application of additional restrictions and policy are at the <del> discretion of the verifying party. </del> <ins> discretion of the Relying Party. </ins> The following is a non-normative example for a Status List Token in CWT format in Hex:

Related discussion:
text: As the similar requirement was relaxed on SD-JWT, I think we should consider the same.
Code change:
Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, <del> Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Pieter Kasselman, Richard Barnes, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: In OpenID Connect, we decided that our "meta-claims" would start with underscore to visually distinguish them from normal claims. For instance, see the claims and in the registry at URL I support SD-JWT continuing to follow this convention and so would prefer that the leading underscore be kept for its meta-claims.
NAME What is the difference between "normal claims" and "meta-claims" here? And why did OpenID Connect go that way?
"Meta-claims" are claims about the structure of where actual claim values can be found - claim values that are not simply top-level members in the JWT Claims Set. They're road-signs saying where to go to get them - not the destinations themselves.
Thanks, that distinction makes sense. Applying that to SD-JWT, it seems directly applicable to , and sort of fits as well, since it tells you how to read the road-signs (to continue NAME metaphor). I'm OK with these keeping ``. But is not a road-sign, it's the main event. If you ignore or , you miss out on some claims, but nothing fundamental breaks. If you ignore , you're not enforcing the key security properties of the system. So I think the original issue here is still valid.
PR URL would remove the leading underscore on (and only there). Which is the original issue here.
Code change:
item reflects that a CCF ledger records both signed envelopes and auxiliary entries.) <del> For each signed envelope, compute the "Countersign_structure" as described in cose_sign1_countersign. </del> <ins> For each signed envelope, create the countersigner protected header and compute the "Countersign_structure" as described in cose_sign1_countersign. </ins> For each item in the list, compute "LeafBytes" as the bytestring concatenation of the internal hash, the hash of internal data and,

Related discussion:
text: Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.
Code change:
knowledge of server support. The request MUST NOT include the "Upload-Offset" header or the <del> "Upload-Incomplete" header.  The server MUST reject the request with the "Upload-Offset" header or the "Upload-Incomplete" header by sending a "400 (Bad Request)" response. </del> <ins> "Upload-Complete" header.  The server MUST reject the request with the "Upload-Offset" header or the "Upload-Complete" header by sending a "400 (Bad Request)" response. </ins> If the server considers the upload associated with this upload URL active, it MUST send back a "204 (No Content)" response.  The response MUST include the "Upload-Offset" header set to the current resumption offset for the client.  The response MUST include the <del> "Upload-Incomplete" header which is set to true if and only if the upload is incomplete.  An upload is considered complete if and only if the server completely and successfully received a corresponding </del> <ins> "Upload-Complete" header which is set to true if and only if the upload is complete.  An upload is considered complete if and only if the server completely and successfully received a corresponding </ins> Upload Creation Procedure (upload-creation) or Upload Appending <del> Procedure (upload-appending) request with the "Upload-Incomplete" header being omitted or set to false. </del> <ins> Procedure (upload-appending) request with the "Upload-Complete" header being set to true. </ins> The client MUST NOT perform the Offset Retrieving Procedure (offset- retrieving) while the Upload Creation Procedure (upload-creation) or

Related discussion:
text: The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.