jiebi/CodeConvo huggingface dataset:
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: What I am suggesting that you could change the structure to the following. In addition to the hash value, each entry will contain the moment when the entry becomes stale. The moment can be calculated when the entry is added. For example, if the entry represents a HTTP response with a , can be calculated as . If the entry represents an immutable HTTP response, then should be set to a very large value (e.g.. assuming that underlying type of is ). When building a GCS digest, you would do the following: step 1. prepare an empty list that would contain hashes of fresh responses step 2. prepare an empty list that would contain hashes of stale responses step 3. foreach entry in cuckoofilter: step 3-1. check if the entry is fresh or not, by checking the value of step 3-2. if the entry is fresh, append of the entry to the list of the hashes of fresh responses step 3-3. otherwise, append of the entry to the list of the hashes of stale responses step 4. sort the list of hashes of the fresh responses, encode as GCS, and send step 5. sort the list of hashes of the stale responses, encode as GCS, and send You can skip the operations related to stale objects (i.e. step 2, 3-3, 5) if the server is unwilling to receive stale digests. Whether the approach can be implemented depends on if a client can determine the moment a response becomes stale. I anticipate that it is possible to determine that when you register the entry to Cuckoo filters (which is when you receive the response from the server).
NAME NAME I'm planning to attend the IETF 100 hackathon this weekend in Singapore. (First timer here. ) I'm happy to collaborate on a (URL) implementation of this spec if either of you are around and interested. I'm fairly familiar with the current spec, having implemented it and .
NAME Wonderful! I'll be attending the hackathon on both days (i.e. Saturday and Sunday). I do not think that I would have time to work on Cache Digests, but would love to discuss with you (or help, if you need) about your work on Cache Digests.
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: I've got an incomplete initial reference implementation at URL It doesn't yet include removal and querying (that's what I'll be adding next), but I did run it on a list of ~3250 URL (which I got out of my main profile chrome://cache/) and it seems to be creating reasonable sized digests. One more advantage, the digests seem to be highly compressible when sparse. Results so far: Digest with 1021 entries (so room for ~4K URLs): 5621 in-memory, 5233 gzipped (when filled with 3250 URLs). Digest with 2503 entries (so room for ~10K URLs): 13772 in-memory, 6879 gzipped (same 3250 URLs). Digest with 7919 entries (so room for ~31K URLs): 43560 in-memory, 9984 gzipped (same 3250 URLs). In practice, I think ~1000 entries is most probably enough, but it's good to know we can increase the digest size (to avoid having to recreate it), without significant over-the-wire penalty.
OK, I now have a complete reference implementation and it seems to be working fine. It also exposed an issue with the initial algorithm, forcing table allocation to accommodate a power of 2 number of entries. Latest results for 3250 URLs taken from my cache: One note: the 1021 entries table had 35 collisions, so it seems like it's insufficient for that number of URLs, unless we're willing to absorb extra pushes for ~1% of the resources.
NAME Interesting! It's good to know that we have numbers now. What is the value of P (the false positive ratio) that you used?
P=8 (so 1/256 false positive)
Note that the numbers here may be possible to further optimize. One example is semi-sorting of the buckets which the Cuckoo-Filters paper mentions, and which I have not yet implemented. It adds some runtime complexity, but can reduce the fingerprint size per resource by a full bit, so could have resulted in ~9% smaller digests in this case.
NAME Awesome! Me not being familiar with these data structures (despite reading Wikipedia article ), why does the 1/256 probability (~4/1000) result in 35 collisions?
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 35 collisions are on top of the false positive rates, and represents resources that we failed to put into the table to begin with (due to both their buckets being full). That rate of collisions seems high compared to the results in the paper, so I need to dig further to see who's wrong...
The collisions are now fixed. It was an algorithm issue, where the entry to be pushed was always the same one at the end of the bucket. I've change that to be a random fingerprint from the bucket, which significantly improved things. The ref implementation is now collision free almost up to the point where the digest is full.
Code change:
process of being standardized that share these characteristics include: <ins> Cross-device protocols should not be used for same-device scenarios. If the initiating device and authorization device is the same device protocols like OpenID Connect Core OpenID.Core and OAuth 2.0 Authorization Code Grant as defined in RFC6749 are more appropriate. </ins> 5. The unauthenticated channel between the initiating device and the

Related discussion:
text: Added additional text making it clear that cross device flows should not be used for same device scenarios as suggested by Joseph Heenan (see )
From Joseph Heenan: URL I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Hi Pieter / Daniel / Filip It’s great to see this document moving forward. I may have missed it, but it may be worth being move explicit that one solution is to avoid using cross-device flows for same-device scenarios? It’s sort of obvious, but questions like “well CIBA works for both cross-device and same-device, can’t I save myself effort by only implementing CIBA and not bothering with standard redirect-based OAuth flows?” are commonly asked. Also, in this text: "If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel Authentication (CIBA) provides an alternative, provided that the underlying devices can receive push notifications.” It might be best to use a term other than ‘push notifications’ there or otherwise rewording this, as there are alternatives. e.g. I think there’s at least one CIBA implementation out there that can use email to notify the user of an authorization request. Thanks Joseph
Code change:
Serialize the cookie-list into a cookie-string by processing each cookie in the cookie-list in order: <del> Output the cookie's name, the %x3D ("=") character, and the cookie's value. </del> <ins> If the cookies' name is not empty, output the cookie's name followed by the %x3D ("=") character. If the cookies' value is not empty, output the cookie's value. </ins> If there is an unprocessed cookie in the cookie-list, output the characters %x3B and %x20 ("; ").

Related discussion:
text: Nameless cookies serialize as . Valueless cookies serialize as . No, this isn't what we would have chosen if we were designing cookies from scratch, but it's Chromium and Firefox's shipping behavior, and it's reasonable to just accept. This specification change is covered by 0021 and 0022 in the WPT repository (see URL). Closes URL
WDYT, NAME / NAME ?
Step 4 says: However looking at WPT tests (for example [1] / [2]) I can see that when we have (empty name with value ) the expectation is to have back, so perhaps these instructions should include a special case when the cookie name is empty. [1] URL [2] URL
Minor suggestion, OK for me either way.
Code change:
recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. <ins> 9.6.1. Issuer provided integrity protection of the SD-JWT payload and Disclosures is achieved by the signature on the Issuer-signed JWT that covers the SD-JWT payload including the digest values of the Disclosures as described in sec-is-jwt and sec-disclosures, respectively.  The Key Binding JWT, defined in kb-jwt, serves exclusively as a mechanism for the Holder to demonstrate possession of the private key corresponding to the public key in the SD-JWT payload.  As such, the signature on the Key Binding JWT does not cover other parts of the SD-JWT.  In cases where it's desirable for the Holder's signature to convey more than a proof-of-possession, such as signing over the selected Disclosures to prove those were the Disclosures selected, the SD-JWT to be presented can be embedded in another JWT (as described in Enveloping SD-JWTs [3]) or otherwise signed by the Holder via the application protocol delivering it. </ins> 9.7. SD-JWT ensures that names of claims that are selectively disclosable

Related discussion:
text: update: agreed to replace SD-JWT VC example with PID. agreed to have only one sd-jwt vc example, so this will also address and
The and the editor's draft didn't get generated - URL 404s
fixed - thank you, Brian!
NAME Binding design and the usage of biometrics data is based on your original PR 210. Shall we replace 4a example with this one? But if you don’t see the need for this example anymore, I am not going to die on this hill.
Thinking about this just a little more NAME does this warrant a doc history bullet? Something like: Replaced the general SD-JWT VC example with one based on Person Identification Data (PID) from the European Digital Identity Wallet Architecture and Reference Framework The history is nice to have and I often use it as a starting place when making "what's changed from last time" type slides for f2f meetings.
I'm just gonna add the doc history to keep things moving here... and done w/ 08d70d2fbfcb1afce5e2d088cb97934b91ce83a1
relevant section in the editor's copy preview: URL should anyone want to take a look before the coming soon merge NAME NAME @ etc
I think this is ready to merge (for real this time). It's kinda awkward process and numbers wise with Dr. out. And peppelinux is still listed as requesting changes but I think his comments were addressed. But I think it's good to go. Approved with two pendings suggestioni/change request and a general comment that's not relevant for the revision but Just informative
Code change:
recognized Key Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. <ins> 9.6.1. Issuer provided integrity protection of the SD-JWT payload and Disclosures is achieved by the signature on the Issuer-signed JWT that covers the SD-JWT payload including the digest values of the Disclosures as described in sec-is-jwt and sec-disclosures, respectively.  The Key Binding JWT, defined in kb-jwt, serves exclusively as a mechanism for the Holder to demonstrate possession of the private key corresponding to the public key in the SD-JWT payload.  As such, the signature on the Key Binding JWT does not cover other parts of the SD-JWT.  In cases where it's desirable for the Holder's signature to convey more than a proof-of-possession, such as signing over the selected Disclosures to prove those were the Disclosures selected, the SD-JWT to be presented can be embedded in another JWT (as described in Enveloping SD-JWTs [3]) or otherwise signed by the Holder via the application protocol delivering it. </ins> 9.7. SD-JWT ensures that names of claims that are selectively disclosable

Related discussion:
text: as additional explanation in the draft for see it here URL
in this PR might be replaced with depending on how PR goes.
Thanks, LGTM, just one editorial comment.
Code change:
Signed Statements presented for Registration.  Some Transparency Services may publish every Signed Statement in their logs, to facilitate their dissemination and auditing.  Others may just return <del> Receipts to clients that present Singed Statements for Registration, </del> <ins> Receipts to clients that present Signed Statements for Registration, </ins> and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents.

Related discussion:
text: I found another typo, to make review simple and not mix it in with a more substantive editorial PR that is pending, I am fixing this misspelling in a separate PR for review and likely approval. Correct singed->signed in Section 6.2.2.
Code change:
let param_name be the result of running Parsing a Key (parse- key) with input_string. <del> If param_name is already present in parameters, there is a duplicate; fail parsing. </del> Let param_value be Boolean true. If the first character of input_string is "=":

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

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

Related discussion:
text: I agree that NAME that it's a hack, though sadly, I do not think we can get rid of such practice through API design on the server side. People are so used to dealing with each line of header fields than working through a API that deals with a set of header fields as a whole.
There are CDNs that offer JS or Wasm APIs effectively using et al. Once structured header values are more baked and have dedicated on-the-wire support I'd definitely like to add first-class support to objects.
I weakly prefer "first one wins" (2). It's only an aesthetic preference, however: I don't have any principled reason to pick 2 over 3 or vice-versa. I can live with either for the reasons NAME spells out.
If I had pick, I probably agree with NAME reasoning.
PTAL
Thank you for the changes. Looks good to me now. FWIW, I was bit surprised to learn that we do not mention how a duplicate is processed alongside the type definitions in . I checked and now I understand that the formal definition is provided in section 4.
Code change:
textual value makes the prioritization scheme extensible; see the discussion below. <del> 8.2. One of the aims of this specification is to define a mechanism for merging client- and server-provided hints for prioritizing the responses.  For that to work, each urgency level needs to have a well-defined meaning.  As an example, a server can assign the highest precedence among the supplementary responses to an HTTP response carrying an icon, because the meaning of "u=2" is shared among the endpoints. This specification restricts itself to defining a minimum set of urgency levels in order to provide sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. However, that does not mean that the prioritization scheme would forever be stuck to the eight levels.  The design provides extensibility.  If deemed necessary, it would be possible to subdivide any of the eight urgency levels that are currently defined. Or, a graphical user-agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. A server can combine the hints provided in the Priority header field with other information in order to improve the prioritization of responses.  For example, a server that receives requests for a font RFC8081 and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment. </del> 9. This specification registers the following entry in the Permanent

Related discussion:
text: We landed a change to remove the semantic meanings of urgency levels but neglected to remove a considerations section that discussed this. This PR moves some of the still relevant text out of the section and nukes the stuff no longer needed.
oops, this will need a rebase...