jiebi/CodeConvo huggingface dataset:
Code change:
the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". <del> Support for "x5t" is mandatory to implement. </del> <ins> When using x509, Support for "x5t" is mandatory to implement. </ins> Support for "kid" and "x5chain" is optional.

Related discussion:
text: Hi all, This PR comes from a place that agrees: If using an identity scheme, then yes, it must be used in maner consistent with that scheme, But aslo that There is no identity scheme we could all agree on as universally applicable or agreable, further, the space continues to evolve. And, The trustworthiness or otherwise of issuers identity, in the context of a transparency ledger, is temporal and subjective in nature. It's just a question of time frame. This means that regardless of registration time checks, relying parties, auditors and general consumers will have to re evaluate regardless. And will do so according to their own subjective context. Remembering that "It can never be assumed that some Issuers and some Transparency Services will not be corrupt.". And also "A Verifier SHOULD validate a Transparent Statement originating from a given Issuer" ... "and would not depend on any other Issuer or Transparency Services." It does seem obvious that, Syntactic validation of the issuer identity claims makes good sense and supports interoperability. But, Specifying a single identity scheme in the core architecture as "minimally required" does not meaningfully help interoperability when there is no single agreeable scheme, and especially when a TS may be used to underpin identity schemes themselves. Regarding the burden on Relying Parties and Auditors, The definition for "Relying Party" states "a Relying Parties consumes Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain". IOW: Relying parties are already expected to deeply consider statements. Assessing the identity asserted by the issuer, at the time the artifact is being considered, seems to be a natural and useful part of that process. Registration Auditability: Requiring that Transparency Services "enough information is made available to Auditors" ... "to authenticate and retrieve the Transparent Statements" is essentially impossible to specify at this level, imposes un-bounded maintenance and storage issues on implementations, and represents a significant layering violation in the architecture.
Editors meeting: will wait 24hours for reviews, with merger if no objections.
Per the editors meeting, I've merged the discussed changes and resolved the discussed topics. I've opened to track the MUST/Should discussion, which wasn't part of this PR.
Code change:
the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". <del> Support for "x5t" is mandatory to implement. </del> <ins> When using x509, Support for "x5t" is mandatory to implement. </ins> Support for "kid" and "x5chain" is optional.

Related discussion:
text: Please review and we'll merge Wednesday morning US Pacific time if there are no objections. I'll incorporate agreed suggestions as well.
Merging with no other feedback.
good enough By and large the document is at a point where it can be called on for final reading. There are some nits or issues that we would like to see done to tighten it up. The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect. This word should be deleted. Removal of the Feeds definition. This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation. We have decided collectively to park that and thus the use of feeds is gone. In a future overarching product or charter it could come back. There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported. The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time. This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important. We need to clear up these two points. What goes into the append only log can vary from implementation to implementation. It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups). Another implementation may simply store the signed statement. This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always. In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. Based on the last statement this has two problems. The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement. If it could this would be equivalent to the original in intent but not binary equal. The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger.
Code change:
the protected header of the COSE envelope, as one of "x5t", "x5chain" or "kid". <del> Support for "x5t" is mandatory to implement. </del> <ins> When using x509, Support for "x5t" is mandatory to implement. </ins> Support for "kid" and "x5chain" is optional.

Related discussion:
text: Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".
Code change:
tree alg (label: TBD): REQUIRED.  Merkle tree algorithm.  Value type: int / tstr. <del> tree size (label: TBD): OPTIONAL.  Merkle tree size as the number of leaves.  Value type: uint. </del> A COSE profile of this specification may add further header <del> parameters, for example to identify the signer. </del> <ins> parameters, for example to identify the signer or add a timestamp. Envelope Payload: A Merkle tree root according to the tree alg. </ins> <del> Payload: Merkle tree root hash bytes according to tree alg (i.e., header params tell you what the alg id is here) </del> <ins> The envelope payload can be detached, since it can be recomputed by the verifier. </ins> <del> Note: The payload is just a byte string representing the Merkle tree root hash (and not some wrapper structure) so that it can be detached (see defintion of payload in https://www.rfc-editor.org/rfc/ rfc9052#section-4.1) and easily re-computed from an inclusion path and leaf bytes.  This allows to design other structures that force re-computation and prevent faulty implementations (forgetting to match a computed root with one embedded in a signature). </del> <ins> Forcing a verifier to perform re-computation can prevent faulty implementations. </ins> <del> One example of a Signed Merkle Tree Proof is a "transparent signed statement" or "claim" as defined in I-D.ietf-scitt-architecture. </del> <ins> One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture. </ins> 3.2.

Related discussion:
text: Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.
Code change:
additional frames to the server immediately after sending the client connection preface, without waiting to receive the server connection preface.  It is important to note, however, that the server <del> connection preface SETTINGS frame might include parameters that </del> <ins> connection preface SETTINGS frame might include settings that </ins> necessarily alter how a client is expected to communicate with the server.  Upon receiving the SETTINGS frame, the client is expected to <del> honor any parameters established.  In some configurations, it is </del> <ins> honor any settings established.  In some configurations, it is </ins> possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.

Related discussion:
text: In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.
Code change:
7.1.1. <del> IANA will be requested to register the new COSE Header parameters defined below in the "COSE Header Parameters" registry at some point. </del> <ins> This document requests IANA to add new values to the 'COSE Algorithms' and to the 'COSE Header Algorithm Parameters' registries in the 'Standards Action With Expert Review category. 7.1.1.1. </ins> Name: tree_alg <del> Label: TBD </del> <ins> Label: TBD_1 </ins> Value type: tree_alg

Related discussion:
text: These changes focus this draft on the minimal definitions required to secure the data structures defined in RFC9162 using CBOR and COSE. Extraneous information has been removed. There is a wip implementation available here: URL There is a demo here: URL
LGTM!sry 4 the l8 approvalI recommend merging now
Code change:
be safely processed MUST be rejected using the 425 (Too Early) status code. <ins> The "Early-Data" header field carries a single bit of information and clients MUST include at most one instance.  Multiple instances MUST be treated as equivalent to a single instance by a server. A "Early-Data" header field MUST NOT be included in responses or request trailers. </ins> 5.2. A 425 (Too Early) status code indicates that the server is unwilling

Related discussion:
text: According to RFC 7231, Section 8.3.1. I didn't include anything here about Vary because I wanted to discuss that first and these seemed uncontroversial. It seems OK to say that Vary is permitted here because we expressly talk about varied reactions based on the presence of Early-Data. If that's right, I will amend this with a second commit. (I'm jetlagged, so being a little cautious.)
Your proposal looks very clear to me, despite your jetlag :-) I agree with you that Vary should be OK. I don't even think we need to say anything about it then.
Code change:
5.2.2. <ins> In the case where the authorization server wishes to interact with the user directly, it can return the "redirect" response.  The authorization server may choose to interact directly with the user based on a risk assesment, the introduction of a new authentication method not supported in the application, or to handle an exception flow like account recovery.  In this case the client is expected to initiate a traditional OAuth Authorization Code flow with PKCE according to RFC6749 and RFC7636. 5.2.3. </ins> If the request contains invalid parameters or incorrect data, the authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following

Related discussion:
text: Added option for redirecting to the web. Notes: Re-using the PAR response - feels strange to have the "request_uri" parameter as the redirect URI - is that OK? Added and example of redirecting to the web. Not entirely sure how control gets passed back to the "native" app/client or how much detail we should provide.
I see the problem with the current text. In PAR, the response is a which represents the PAR request itself: The client is expected to then start an authorization request and put the value in the query string parameter: So the text in this section should instead be:
Code change:
The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response. <ins> Note that an If-Match header field with a list value containing "*" and other values (including other instances of "*") is unlikely to be interoperable. </ins> 8.2.4. The "If-None-Match" header field makes the request method conditional

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:
Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in "privacy mode." <del> 6.  References </del> <ins> 7.  References </ins> <del> 6.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Related discussion:
text: Resolves URL
cc NAME NAME
Hey Yoav, Thanks; will take a look. Two immediate things: You're getting a error in the markdown; . I see you've added yourself as an author. That's generally the decision of the chair - NAME in this case.
Hopefully fixed. Is there a way to test it locally? Apologies for the noobness. Removed myself.
See URL for build info.
NAME Thank you for working on the proposal. Am I correct in assuming that changes other than the switch to Cuckoo filters and the introduction are unintentional? For example, I see flag of the frame being removed. Do you have a working code that implements Cuckoo filters? I am curious to see it working. The concept of makes sense to me. Maybe we might want to adjust the codepoints and the naming in relation to .
Oh, I now understand the intent of removing the flag. The motive of the proposal is to build a digest without referring to every response object stored in cache. The fact means that it is not be easy for the client to determine the freshness of the entries that is going to be included in the digest. I am sympathetic to the idea, but I am afraid if the approach works well with the current mechanism of HTTP/2 caching. My understanding is that browsers that exist today only consume a pushed response when it fails to find a freshly cached response in its cache. Otherwise, the pushed response never lands in the browser cache. Unless we change the behavior of the browsers to respect the pushed response even if a freshly cached object already exists in its cache, there's a chance that servers would continually push responses that gets ignored by the client (due to the existence of a freshly cached response in the browser cache with the same URL). NAME Assuming that I correctly understand the motive of removing the distinction between a fresh digest and a stale digest, I would appreciate it if you could clarify your ideas on the problem.
Thanks for reviewing, NAME :) My intent was to include all stored resources in the digest, regardless of them being stale or fresh. Entries are added to the digest when a resource is added to the cache and removed from the digest when a resource is removed.
Code change:
Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in "privacy mode." <del> 6.  References </del> <ins> 7.  References </ins> <del> 6.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Related discussion:
text: The reason is that I think the distinction doesn't make much sense, and maintaining it adds a lot of complexity, basically forcing browsers to recreate the digest for every connection at O(N) cost. Under this premise what servers should do is: Push all the resources that are known not to be in the cache digest Push 304 responses for resources that are in the cache digest, but are likely to be stale (short freshness lifetime, etc) Don't push resources that are in the cache digest and have a long term freshness lifetime or are immutable. Does that make sense? I'm not sure I understand your reference to the push cache vs. the HTTP cache in your comment. In light of my explanation, is there still an issue there in your view?
URL is the reference implementation. Happy to change it. Do you have any specific changes in mind?
NAME Thank you for the explanation. I now understand the intent better. I think that we need to consider two issues regarding the approach. First is the fact that a browser cache may contain more stale responses than fresh resources. Below are the numbers of cached objects found in my Firefox's cache (to be honest the date is from 2016, I haven't been using Firefox in recent weeks and therefore cannot provide up-to-date data). total ---: 2,273 1,003 As you can see, large scale websites tend to have more stale objects than fresh objects. In other words, including information of stale-cached objects increases the size of the digest roughly three times in this case. Since performance-sensitive resources (that we need to push) are likely to be stored fresh (since they are the most likely ones marked as immutable, or near-immutable), transmitting only the digest of freshly-cached responses makes sense. Second is a configuration issue on the server side. One strategy that can be employed by an H2 server (under the current draft) is to receive a digest of freshly cached resources only, compare the digest against the list of resources the browser should preload by only using the URL, and push the missing resources to the client. It is possible for a H2 server to perform the comparison without actually fetching the resource (from origin or from cache) since only the URL would be required for calculating the digest.
Code change:
Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in "privacy mode." <del> 6.  References </del> <ins> 7.  References </ins> <del> 6.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Related discussion:
text: The proposal prevents such strategy from being deployed since it requires the ETag values to be always taken into consideration (should they be associated to the HTTP responses). In other words, servers would be required to load response headers of the resources to determine if it needs to be pushed, which could be a huge performance degradation on some deployments. Fortunately, servers could avoid the issue by not including ETags for resources that it may push. I think such change on the server-side configuration would be possible, but we need to make sure if we are to take the path (of removing the fresh vs. stale distinction). Let me explain using an example. Consider the following case: client has with and on server-side, the resource has been updated to When receiving a new request from the client, the server cannot determine if the client has URL in its cache. Therefore, would be pushed. The client, when observing (or equivalent tag), tries to load the resource. Since the fresh resource exists within the browser cache, that would be used. The pushed version is ignored and gets discarded (). This would be repeated every time until the cached object either becomes stale or gets removed from the cache. My understanding is that the browser behavior (explained in ) is true for Firefox and also for Chrome. Am I wrong, or missing something? Thank you for the link. I will try to use it. OTOH, do you have some working code that can actually calculate the cache-digest value taking a list of URLs as an input (something like URL)? I ask this because it would give us a better sense in how the actual size of the digest would be. One way to proceed would be to split the discussion of from Cuckoo filters into a separate issue or a PR. I do not have a strong opinion on the naming or the codepoints. What do you think? NAME
NAME Have you considered the approach using Cuckoo filter to generate GCS? I can understand the fact that you do not want to iterate through the browser cache when sending a cache digest. Per-host Cuckoo hash seems like a good solution to the issue. OTOH, as I described in my previous comment, it seems that sending the hash directly has several issues.
Code change:
Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in "privacy mode." <del> 6.  References </del> <ins> 7.  References </ins> <del> 6.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Related discussion:
text: That is why I am wondering if it would be viable to generate GCS from the per-host Cuckoo filter that would be maintained within the browser. I can see three benefits in the approach, compared to sending the values of Cuckoo filter directly: the size of the digest will be smaller we can keep the distinction between fresh vs. cache. Sending digest of fresh resources only would end up in even smaller digests. Retaining the distinction lowers the bar to deploy cache-digests on the server side. note: you can store the time when the cached object becomes stale in the data associated to the Cuckoo filter entry (assuming that you would have associated data to handle resize, as we discussed in URL). That information can be used when builiding the GCS to determine if a particular object should go into a GCS of fresh resources or that of stale ones less change to the browser push handling (no need to handle pushes of 304 or replace a freshly cached object when an object with the same URL is being pushed) In case of or in the comment above, sending fresh-only digests using GCS would be about 1/3 the size of sending fresh & stale digests using Cuckoo filter. The biggest cost of calculating GCS from Cuckoo hash would be the sort operation. But I think that the cost could be negligible compared to the ECDH operation that we would be doing for every connection, considering the fact that the number of entries that we would need to sort would be small (e.g., up to 1,000 entries of uint32_t), and the fact that sort algorithms faster than O(n log n) radix sort can be deployed (e.g. radix sort). WDYT?
So have a cuckoo filter digest and then put its fingerprints in a GCS? I have not considered that. Need to give it some thought... At the same time, it's not clear to me how that would enable a "stale" vs. "fresh" digests, or handling of improperly cached resources (fresh resources that were replaced on the server).
I would appreciate it if you could consider. To me it seems it's worth giving a thought. Under the approach proposed in this PR, structure that stores the per-host digest would look like below. is required for resizing the filter (e.g., when doubling or halving ).