jiebi/CodeConvo huggingface dataset:
Code change:
"type" and "title", and another one for the "Basic" scheme with a realm value of "simple". <ins> Some user agents do not recognise this form, however.  As a result, sending a WWW-Authenticate field value with more than one member on the same field line might not be interoperable. </ins> 11.3.2. The "Proxy-Authenticate" header field consists of at least one

Related discussion:
text: These are probably just implementation bugs, but it's somewhat curious that no browser handles from the standard correctly. They all do handle correctly on the other hand. I'll create some manual tests for web-platform-tests, unless someone has a good idea on how to automate this...
At it's defined by and by with But in the it is: :confused:
What exactly do you mean by "but"?
You're right. My fault. I didn't read the correctly. Where is the alternative defined? Thank you for your assistance.
See URL and the links from there.
Thank you and sorry for the noise.
Basic manual test at URL including links to browser bugs (all browsers fail).
When I wrote tests around seven years ago, Konqueror was fixed to pass most of them. That seems to indicate that it's possible to implement the spec.
Oooh, can we convert those to web-platform-tests somehow, even if only manual for now? (I got some pushback from at least one Firefox developer on fixing this and given it's HTTP authentication I suspect most people won't be too enthused, but it also seems worth fixing as having separate parser requirements for any header between a single comma-separated and two headers is just bad and not really compatible with how HTTP is defined.)
Feel free to steal from URL ...
While it's possible to implement the spec, given that none of the browsers implement it and doing so won't really make anything possible that isn't possible now, could we limit to one challenge per header?
In HTTP, intermediaries are allowed to coalesce multiple field instances into a single one, no matter what the field name is. So if you have two header instances, it's legal to combine them into a single one. RFC 7230 made one exception for cookies, because they break otherwise. We looked at WWW-Authenticate and verified that no exception is needed here. So my position remains: implement the spec, or otherwise prove that it's impossible/would break existing use cases.
I'm the one Anne talked to. He's right, I'm not particularly excited about the idea of making this change - none of the browsers handle it right now, and with the ambiguity around commas in the grammar, making this change is on the higher side of the "likely to introduce terrible bugs" scale. Not to mention there may be intermediaries somewhere that depend on the current behaviour.
Code change:
"type" and "title", and another one for the "Basic" scheme with a realm value of "simple". <ins> Some user agents do not recognise this form, however.  As a result, sending a WWW-Authenticate field value with more than one member on the same field line might not be interoperable. </ins> 11.3.2. The "Proxy-Authenticate" header field consists of at least one

Related discussion:
text: Changing this could also result in interop issues there, which will be much more difficult to fix than upgrading clients. Given all that, this seems like a case where changing the spec would be more appropriate.
How exactly would those be affected?
Even if you change the standard, some browsers might still have to change their code as URL indicates that, e.g., parses differently across browsers. That doesn't really seem like an acceptable outcome whatever we do.
FWIW, that's a parse error according to the ABNF. EDIT: in the meantime I realized that the syntax is ok.
NAME : Currently one can embed a comma somewhere in the auth challenge. These will break if browsers change behavior. Given how long this bug has been around, it's difficult to estimate the effect of such a change. Both FF and Chrome have telemetry, but at least from the perspective of Chrome, we don't have much insight into many corporate or closed networks where middle boxes tend to be much more prevalent. The change itself is fairly trivial from a code perspective. And I understand that either option isn't great. However IMHO the reward doesn't seem to justify the risk of changing browser behavior here.
No, it doesn't, if the parsing is done correctly. Please give an example if you think otherwise.
I don't know, and that's what scares me. Intermediaries have all kinds of busted behaviour already, and changing the way the WWW-Authenticate header is parsed in practice (spec notwithstanding) could have unintended consequences (dropped as a malformed header is the first possibility that comes to mind).
It would be helpful if you gave at least one concrete example.
HTTP is not defined by browser behavior after receipt of a valid message. Even if five major browsers caught fire and imploded upon receipt of multiple challenges, that would only increase the need for those parsers to be fixed (somehow). We can't control the bits received. The easiest fix is to simply parse the field as specified, since that's what the non-browser UAs have been doing for ages.
NAME unfortunately I can't, as I have neither the time nor the resources to test even the most common intermediaries. I've just been around long enough to not trust them to not be doing something horrible. NAME your hyperbole is not at all useful here, thanks.
Code change:
"type" and "title", and another one for the "Basic" scheme with a realm value of "simple". <ins> Some user agents do not recognise this form, however.  As a result, sending a WWW-Authenticate field value with more than one member on the same field line might not be interoperable. </ins> 11.3.2. The "Proxy-Authenticate" header field consists of at least one

Related discussion:
text: I'm glad you're confident in all the major browser vendors being so perfect as to not accidentally introduce some corner-case parsing bug that is potentially catastrophic for the security of WWW-Authenticate. I would prefer to be conservative, and recognize the fact that this is the way the internet has operated for years (decades?) and we're probably better off taking the safe course of changing the spec over changing every single browser on the planet's handling of a security-sensitive header.
NAME What hyperbole? Changing the spec is not a "safe course", no matter how you look at it. There exist cases where multiple schemes are in use today. There exist many intermediaries that will, without question, merge those multiple field names into a single field value regardless of sender's choice to send multiple fields. There exist many clients (e.g., API clients) that currently support multiple auth schemes and choose one, which is the primary audience for this bit of the protocol. The only question here is what should a browser do given the same bits received. Regardless of that answer, the spec will not be changed.
OK, if the answer I give doesn't matter, and the spec won't be changed, then no point engaging.
We cannot change HTTP (for which there exist thousands of independent implementations) just because a few browser implementations choose to ignore a valid header field value. We can only make a change when all deployed implementations do the same thing, or when failing to implement it correctly is either impossible or known to be insecure. Servers compensate by not delivering the same options to bug-present user agents that they do for API clients, or rely on a TLS connection being sufficient to prevent most intermediaries from joining field values (which can lead to gateway/CDN issues, etc.). This has never been good for the security of browsers. They get stuck with Basic while the rest of the HTTP universe is using better auth schemes. Nevertheless, we can't change the spec to prevent header field joining, which deployed implementations have always done, nor can we disallow multiple auth schemes that current APIs depend upon. Hence, an implementation can choose to magically ignore some parts of the field and occasionally fail to support certain (usually more secure) auth schemes when an intermediary is present, or we can get past the FUD and just implement the field as specified. That is an implementation choice, not a spec choice.
Code change:
"type" and "title", and another one for the "Basic" scheme with a realm value of "simple". <ins> Some user agents do not recognise this form, however.  As a result, sending a WWW-Authenticate field value with more than one member on the same field line might not be interoperable. </ins> 11.3.2. The "Proxy-Authenticate" header field consists of at least one

Related discussion:
text: FWIW, I believe there is some confusion about what a conforming client is supposed to do. Hint: it's not "splitting where a comma is". That's why I'm asking for examples.
NAME if I'm not totally wrong a is not allowed within a only in a (double) quoted string So parsing is not straight forward "splitting where a comma is".
NAME - that is true, but it is allowed in a parameter value (when using quoted-string syntax). FWIW, this syntax is common across many many HTTP header fields. A common parser library should do the trick.
NAME definitely, do parsing not by yourself. But I've no idea how many libraries/frameworks does it correctly beside of browsers.
Let me just gently remind the audience here that authentication if anything is possibly even more widely implemented and used in and by non-browser HTTP user-agents. Then, I could add that curl also doesn't parse these headers "correctly" and assumes multi-line. And I don't think we've ever had a bug report about it...
I believe this issue should be closed with no action.
NAME does "assumes multi-line" mean "only supports multiple challenges if they're on different lines"?
ah yes, exactly.
I think the options available to us are: Do nothing (i.e., close this issue without action) Include text advising that putting more than one on a header field line may not be interoperable Create a formal exception for (like Cookies)
I don't see why a formal exception is needed; the situation is different from Cookies (cookies do not work without the exception, but WWW-A does). My preference is (1), but I could be persuaded to do (2).
Does anyone object to (2)? If so, why?
Code change:
The status code indicates that the server did not receive a complete <del> request message within the time that it was prepared to wait.  If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. </del> <ins> request message within the time that it was prepared to wait. If the client has an outstanding request in transit, it MAY repeat that request.  If the current connection is not usable (e.g., as it would be in HTTP/1.1, because request delimitation is lost), a new connection will be used. </ins> 15.5.10.

Related discussion:
text: "If the client has an outstanding request in transit, the client MAY repeat that request on a new connection."
I don't think this needs to be changed (connection is a defined term), but if you can think of some other way to say that the 408 implies partial receipt of the last request (which means the connection gone broke) then go ahead.
Suggestion:
+1
Code change:
The status code indicates that the server did not receive a complete <del> request message within the time that it was prepared to wait.  If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. </del> <ins> request message within the time that it was prepared to wait. If the client has an outstanding request in transit, it MAY repeat that request.  If the current connection is not usable (e.g., as it would be in HTTP/1.1, because request delimitation is lost), a new connection will be used. </ins> 15.5.10.

Related discussion:
text: : "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.
Code change:
support selective disclosure for JWTs: For an SD-JWT document, a Holder can decide which claims to release (within bounds defined by the Issuer).  This format is therefore perfectly suited for <del> Verifiable Credentials and Verifiable Presentations. </del> <ins> Verifiable Credentials. </ins> SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how Verifiable Credentials can be expressed using SD-JWT. <del> JWTs (and SD-JWTs) can contain claims that are registered in the IANA JWT Claim Registry, as well as public and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </del> <ins> JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </ins> 1.3.

Related discussion:
text: Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?
Code change:
For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream.  Clients MUST NOT accept a malformed <del> response.  Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </del> <ins> response. Endpoints that progressively process messages might have performed some processing before identifying a request or response as malformed.  For instance, it might be possible to generate an informational or 404 status code without having received a complete request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend on the remainder of the request being correct.  A server or intermediary MAY use RST_STREAM -- with a code other than REFUSED_STREAM -- to abort a stream if a malformed request or response is received. These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </ins> 8.1.3.

Related discussion:
text: The language doesn't properly acknowledge the possibility that some processing might have been performed before an error is detected. This could use some tweaking.
Proposal here: URL
Seems like a reasonable change.
Seems like a nice clear improvement
Code change:
and "Secure" cookie to authenticate the session between the browser and Application Server. <ins> Additionally, cookies MUST be protected from leakage by other means, such as logs. This architecture protects against tokens leakage from the browser, but creates a CSRF attack vector: once the user is authenticated, the BFF proxy will automatically add tokens to calls to the resource server. </ins> 6.3. In this architecture, the JavaScript code is first loaded from a

Related discussion:
text: Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy
Code change:
field-components defines some generic syntactic components for field values. <del> The rule below is defined in Messaging; </del> This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in RFC6365.

Related discussion:
text: : "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.
Code change:
4. Please register the following entry in the Hypertext Transfer <del> Protocol (HTTP) Field Name Registry defined by I-D.ietf-httpbis- semantics: </del> <ins> Protocol (HTTP) Field Name Registry defined by HTTP: </ins> Field Name: CDN-Cache-Control

Related discussion:
text: This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.
Code change:
Padding size low bits.  This field is only present if the PAD_LOW flag is set. <del> A single reserved bit.  This field is optional and is only present if the PRIORITY_GROUP flag is set. A 31-bit identifier for a priority group, see StreamPriority. This field is optional and is only present if the PRIORITY_GROUP flag is set. An 8-bit weight for the identified priority group, see StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the PRIORITY_GROUP flag is set. </del> A single bit flag indicates that the stream dependency is exclusive, see StreamPriority.  This field is optional and is only <del> present if the PRIORITY_DEPENDENCY flag is set. </del> <ins> present if the PRIORITY flag is set. </ins> A 31-bit stream identifier for the stream that this stream depends on, see StreamPriority.  This field is optional and is only <del> present if the PRIORITY_DEPENDENCY flag is set. </del> <ins> present if the PRIORITY flag is set. An 8-bit weight for the identified stream dependency, see StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the PRIORITY flag is set. </ins> A HeaderBlock.

Related discussion:
text: NAME I would add an explicit hint to implementers that having more than 8 bits of internal precision is a good thing. NAME I think we should leave open the possibility to insert a new stream between the connexion and all its children, even if it's probably a large re-prioritization.
I think large re-prioritization is not a problem. If proxy gets such requests and it aggregates several frontend connections to single backend connection, inserting under stream 0x0 with exclusive flag set seems to be impossible in backend.
If it aggregates to a different backend connection it is not impossible to proxy. Consider streams A and B depend on stream 0x0 and are proxied to some backend connection as streams X and Y. If we get a new streams, C, that exclusively depends on 0x0, we can proxy it as stream Z by dropping the exclusive dependency and then re-prioritizing streams X and Y to depend on stream Z.
Yes, it works like that. But if we just don't allow 0x0 with exclusive dependency, we can do all priority stuff via proxy without doing any extra handling except for stream ID mappings.
Yep, true -- I don't have much of a preference -- if clients feel like it is not an important use case than I am perfectly happy to disallow it.
Is it possible to move this discussion to the mailing list? If you need comments from a client, I'm happy to take a look later. On Tue Apr 15 2014 at 9:39:56 AM, Jeff Pinner EMAIL wrote:
Code change:
The PING frame defines the following flags: <del> Bit 1 being set indicates that this PING frame is a PING response. </del> <ins> Bit 0 being set indicates that this PING frame is a PING response. </ins> An endpoint MUST set this flag in PING responses.  An endpoint MUST NOT respond to PING frames containing this flag.

Related discussion:
text: Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.