jiebi/CodeConvo huggingface dataset:
Code change:
3.7. <ins> 3.8. </ins> In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding with the attacker, the security implications and potential

Related discussion:
text: fixes URL
Merging new mitigation proposal
I want to use my E-ID on a verifier website to prove my identity. If I authenticated on the correct website using a phishing resistant authentication and only after this, can I scan the QR Code to present my verifiable credentials presentation. This works good, as a lot of the website where I require a digital identity check, I already have an account and can use a phishing resistant authentication first. I could add a text for this, if you think this is a good idea. Greetings Damien
NAME I think of this as a type of "authenticated flow" where the user authenticated the channel before engaging in an additional cross device flow. I think it is a reasonable mitigation, would you like to take a stab at writing up a more detailed description of the attack?
NAME Thanks for the feedback. I created a PR for this: URL Greetings Damien
Code change:
delivery of Client Hints on subsequent requests to the server's origin (RFC6454). <ins> Accept-CH-Lifetime is a Structured Header I-D.ietf-httpbis-header- structure.  Its value MUST be sh-integer (Section 3.4 of I-D.ietf- httpbis-header-structure).  Its ABNF is: </ins> When a client receives an HTTP response that contains Accept-CH- Lifetime header field, the field-value indicates that the Accept-CH preference SHOULD be persisted and bound to the origin, and be

Related discussion:
text: NAME - can you take a look?
Migrating .. Julian:
NAME NAME per URL, how about... Does that make sense? Would appreciate your guidance on this one :)
I'm starting to wonder if Client Hints should adopt Structured Headers to avoid having to deal with these sorts of questions. Ilya, WDYT?
NAME that would hit a major reset on all existing CH implementations and set us back another couple years, I don't think this is the right call for CH. /cc NAME Surely CH is not the first instance where we had to spell out behavior for selecting one out of N header values? That said, if we don't have established verbiage for this, I'm happy to just make up some language ourselves to clarify how it should behave.. what we're aiming for ain't rocket science. :)
I wouldn't want to set CH back that much (although it is lingering on :). I only mention it because all of the defined syntax seems like it would easily fit into SH, and Chrome already has a good start on a SH parser, thanks to NAME work on signed exchanges, etc.
As an aside, the same clarification should also apply to response headers. Currently Chrome treats multiple responses headers as an error and ignores both.
NAME my preference is to get this over the finish line without introducing dependency on SH. For one, we're also relying on Feature-Policy for delegation and we decided against SH there. WDYT of suggested text in URL — warmer? NAME ack.
NAME I hear you. My thinking is: We've already waited a good while for CH, and it's not clear that it's really really done yet (I suspect we have at least one more round of doc review). People are already using CH as a framework for new hints, so getting SH in would be best now if it's going to get in. If CH are going to be commonly sent, having well-defined parsing behaviour and the possibility of better serialisations (which SH gives us) is very attractive. To be clear -- this is me as me, not me as chair.
NAME - could you clarify what you mean by CH adopting SH? Do you mean that the / headers would be defined as /? Or that they'd be define as with extended processing model (which guarantees that the last item in the list "wins")? Or something else altogether?
Code change:
delivery of Client Hints on subsequent requests to the server's origin (RFC6454). <ins> Accept-CH-Lifetime is a Structured Header I-D.ietf-httpbis-header- structure.  Its value MUST be sh-integer (Section 3.4 of I-D.ietf- httpbis-header-structure).  Its ABNF is: </ins> When a client receives an HTTP response that contains Accept-CH- Lifetime header field, the field-value indicates that the Accept-CH preference SHOULD be persisted and bound to the origin, and be

Related discussion:
text: Both and could be s. would be a of s. Both and would be s. would be a . I'm not really sure why its current ABNF is a list. NAME Considering that parsing and serialisation algorithms for these haven't been defined yet at all, I don't think it would take a lot of work (and would be happy to do a PR).
Good catch, I think that's an oversight and we can fix that. Stepping back, my preference is (still) to proceed at this stage without introducing dependency on SH. First off, introducing SH does not address the issue we're actually trying to solve in this bug. Second, it adds another significant dependency to CH adoption that I would like to avoid at this stage, as it's yet another reason for a browser vendor to drag their feet and delay integrating support for SH. To get CH over the last call barrier, I believe we have two outstanding tasks: Clarify Accept-CH-Lifetime definition, per above. Provide some minimum guidance on how to deal with aggregated values — see URL I don't think we'll land on perfect text for (2), but this is not a unique or new gap vs other and existing specs, and I don't think we should block on this. NAME does this sound reasonable?
friendly bump :-) NAME NAME PTAL, any thoughts or guidance on the above text?
The issue is that it's defined to only have one value. I think you'd need to say something like: Or, to really define it, define an algorithm.
This was discussed at the HTTPWG meeting today and it was decided to go ahead with Structured Headers!
Based on group discussion at IETF, everyone is on board.
Code change:
client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. <del> The token is a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on. </del> <ins> This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on.  New token and extension token values can only be defined by revisions of this specification. </ins> 8.

Related discussion:
text: only one "on" value is recognized today allow parameters on token Discussion: URL NAME NAME can you please do a quick sanity check?
NAME thanks, updated! getting warmer?
Think so. NAME is the Keeper of the ABNF, though.
NAME NAME thanks. Updated, do you want to do a last sanity check before I merge?
Looks good to me.
I understand that the current method has the save-data aspect of client hints as a simple on/off switch. I wonder, though, about the willingness to consider allowing for some extensibility. Right now, someone saying "save-data=on" is signing up for pretty much anything. Separating acceptance of data saving for different elements, e.g. agreeing to smaller video resources but not lower fidelity audio, seems like it may be useful. I suggest that the working group consider making this an extensible field with "save-date=all" as the default, with semantics matching the current "save-data=on". Then later extensions can be specified for more granular statements.
I think we can already achieve this with current definition: We can define other tokens We can define parameters - e.g. "on;video-only", etc. Changing from "on" to "all" doesn't really change anything. Also, we already have both client and server implementations that are relying on "on". p.s. some background: URL
NAME - any further comment?
I think the parameter method would be quite useful, and if the doc describes that it would be useful. I'm less sanguine about introducing parameters later, but I certainly wouldn't fall on any sharp objects if that were the decision of the WG.
I guess we should clarify that it is extensible and define "on" as one of its recognized values... Does that make sense? I'm sure my ABNF is off.. :)
, Ilya Grigorik EMAIL wrote: regards, Ted
Resolved via .
Is there a reason to use semicolon here instead of the more typical comma? Also, the grammar does seem off: it does not allow whitespace (because the “implied ” rule of RFC 2616 no longer applies), and it uses instead of .
Code change:
client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. <del> The token is a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on. </del> <ins> This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on.  New token and extension token values can only be defined by revisions of this specification. </ins> 8.

Related discussion:
text: Assuming you really want semicolons, I think it should be: (I can file a separate issue if you want)
I wouldn't say comma is "typical" -- it depends a bit on the use case. For instance, alt-svc uses a list of comma-delimited directives, each of which can have semicolon delimited parameters. In any case, if this does not use commas, the spec ought to state what happens when commas turn up in a field value, or if a field occurs multiple times in a messages (this is stated for the other client hints).
That, indeed, was the intent - e.g. "on;video-only". Re, OWS: good catch. Addressed in URL
Code change:
vary. The authorization server MAY define additional parameters in the <del> response depending on the implmentation. </del> <ins> response depending on the implmentation.  The authorization server MAY also define more specific content types for the error responses as long as the response is JSON and conforms to "application/<as- defined>+json". </ins> 5.3.

Related discussion:
text: Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types
Code change:
accept the upload from the client, and the client begins transferring the entire file in the request content. <del> An informational response can be sent to the client to signal the support of resumable upload on the server and transmit the upload resource URL in the Location header. </del> <ins> An informational response can be sent to the client, which signals the server's support of resumable upload as well as the upload resource URL via the Location header field (HTTP). </ins> <del> 2) If the connection to the server gets interrupted, the client may want to resume the upload.  Before this is possible, the client must know the amount of data that the server was able to receive before the connection got interrupted.  To achieve this, the client retrieves the offset (offset-retrieving) from the upload resource. </del> <ins> 2) If the connection to the server is interrupted, the client might want to resume the upload.  However, before this is possible the client needs to know the amount of data that the server received before the interruption.  It does so by retrieving the offset (offset-retrieving) from the upload resource. </ins> <del> 3) Afterwards, the client can resume the upload by sending the remaining file content to the upload resource (upload-appending), appending to the already stored data in the upload.  The "Upload- Offset" value is included to ensure that the client and server agree on the offset that the upload resumes from. </del> <ins> 3) The client can resume the upload by sending the remaining file content to the upload resource (upload-appending), appending to the already stored data in the upload.  The "Upload-Offset" value is included to ensure that the client and server agree on the offset that the upload resumes from. </ins> <del> 4) If the client is not interested in completing the upload anymore, it can instruct the upload resource to delete the upload and free all </del> <ins> 4) If the client is not interested in completing the upload, it can instruct the upload resource to delete the upload and free all </ins> related resources (upload-cancellation). 3.2.

Related discussion:
text: See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.
Code change:
that use different grammatical notations than this document (which uses ABNF from RFC5234). <del> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </del> <ins> Per the grammar above, servers SHOULD NOT produce nameless cookies (i.e.: an empty cookie-name) as such cookies may be unpredictably serialized by UAs when sent back to the server. </ins> The semantics of the cookie-value are not defined by this document.

Related discussion:
text: While already discouraged by the grammar, this warning further discourages servers from sending nameless cookies which have a history of causing compatibility problems. It also reorders the notes in the syntax section to group similar notes together.
Ideally we'd define server-side parsing of cookie-string (or at least recommend behaviour here for things that don't match cookie-string!), given this does cause problems for some servers (e.g. URL). Until then we should at least make it clear that the "the algorithm to compute the cookie-string from a cookie store and a request-uri" can create things that don't match cookie-string (e.g., nameless cookies after ). There's a number of WPT expected results that don't match cookie-string.
Can you clarify what a fix would look like? Bonus points for a PR. (I mean, I can also attempt a PR, just not clear on what the recommended fix would be)
You attempting would probably be as good as me attempting!
I'm skeptical, however willing to try! And now I think I actually understand the bug report (and didn't when I commented). NAME is saying that the ABNF in URL has a bug, since is defined as: But nameless and valueless cookies exist. cf. URL URL
I think maybe this can be solved by making the following changes: This is pretty simple to grok: This is supposed to convey "a nameless cookie, OR a valueless cookie (but not both)" That should work for the following valid cookie-pairs: (nameless) (nameless2) (named cookie with empty , i.e., valueless) (name + value) If that's the route we go, then in URL cookie-string = cookie-pair *( ";" SP cookie-pair ) That should work. However... unless we tweak , I think you can end up with the following invalid cookie: . Will need to formalize "if no name, there must be a value". Maybe we can just add an and then do something like:
Actually that won't fix the bug I described.
Code change:
that use different grammatical notations than this document (which uses ABNF from RFC5234). <del> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </del> <ins> Per the grammar above, servers SHOULD NOT produce nameless cookies (i.e.: an empty cookie-name) as such cookies may be unpredictably serialized by UAs when sent back to the server. </ins> The semantics of the cookie-value are not defined by this document.

Related discussion:
text: Maybe this super elegant solution (but the above ABNF would have to be tweaked):
FWIW nameless and valueless cookies are no longer RFC compliant after URL Up until then only Set-Cookie strings with empty names and empty values weren't accepted, but there were ways around this to get empty-name-empty-value cookies into user agents' cookie jar using the CookieStore API.
There are nameless cookies and there are valueless cookies (and, as you said, there are no nameless-and-valueless cookies). FWIW, the syntax in section 4.1.1 where is defined is a SHOULD, not a MUST, on the server's part. I think one issue is that reusing it to define makes that also implicitly a SHOULD, if I'm reading this correctly: Edit: To clarify, I'm thinking there's no accuracy issue with the spec as written, since if the server does things as recommended (and sends a cookie with name=value), then the user agent will respond as given by . But that is still totally confusing, at least to me, so I think we should still define this better.
(love the ambiguities of english -- thanks for the explicit callout and pointer to NAME
In the nameless cookie case, it seems that an unhandled edge case arises because of the following, from the section: To illustrate the problem with some examples: if is empty and is , the algorithm above works - the resulting cookie line would be if is empty and is , though, the resulting cookie line would be , which would be interpreted as a cookie with name and value . One solution for this, which is currently specified by the , is to forbid cookies with an empty name and a value containing '=' from being set. Limiting from containing a '=' is not mentioned in the section or the section of RFC6265bis, though. It seems like using the following in the section would be a better approach: This would fix the issue in the example above (the resulting cookie lines would be and respectively, both of which would be interpreted correctly). If we want to allow to be produced in the first case, we could replace step 2 above with something like: I'll submit a PR for this change.
The empty-name-but-nonempty-value case is serialized as and not for historical/compat reasons. There's some earlier discussion in .
Code change:
that use different grammatical notations than this document (which uses ABNF from RFC5234). <del> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </del> <ins> Per the grammar above, servers SHOULD NOT produce nameless cookies (i.e.: an empty cookie-name) as such cookies may be unpredictably serialized by UAs when sent back to the server. </ins> The semantics of the cookie-value are not defined by this document.

Related discussion:
text: The case where the value contains an '=' is interesting though, and not tested by WPTs I believe. The Set-Cookie header can't produce a nameless cookie with value so this is only a concern for non-HTTP APIs that don't parse a set-cookie-string. Could we instead just add to the Storage Model section the restriction that the cookie-name and cookie-value cannot contain '=' or ';' characters? (Side note, more generally, this is getting out of hand and we should try to factor out common logic in the Storage Model and set-cookie-string parsing sections.)
hmm, looks like there is a WPT for this case, but the expected output for it would be interpreted incorrectly :( URL;l=22-26 Wouldn't be allowed in a Set-Cookie header? Also, '=' is a valid base64 character, so not allowing it in might cause a lot of headaches
Oh, my mistake, you're right that creates a nameless cookie with value . Chrome/Edge/Firefox agree on how to serialize these, but Safari ignores nameless cookies altogether. I would be a bit concerned about breaking stuff if this serialization changed. :-/ Theoretically there's a use case for this behavior... since and are the same cookie (the nameless cookie) but with different values, and they overwrite each other, a site could be relying on getting the output or (but never both) as a way of (sort of) setting two mutually exclusive cookies named and .
Maybe we just fix this with a note cautioning against using nameless cookies, and point to this issue as a warning.