jiebi/CodeConvo huggingface dataset:
Code change:
Recommended HTTP status code: 400 <del> 2.3.30. </del> <ins> 2.3.26. </ins> Name: http_upgrade_failed

Related discussion:
text: While I can understand the appeal for providing 'informational' statuses, any suggestion beyond a level of is probably too normative, and unsupported by the underlying specifications and best practices.
NAME the context here is a CDN or other reverse proxy reporting back errors in HTTP response headers, for debugging. There are no requirements around sending them (and senders are cautioned against leaking information that could aid an attacker). So, at one end a Boolean doesn't really help, and at the other end, the full list of errors by any one library (or all of them) is impractical. The list of alerts from NAME seems promising, and I note that we already have , whose value can be any TLS Alert string. However, That's intended to convey alerts received (and perhaps we should communicate that more clearly). The desired semantics here are that the problem indicated by the alert is generated in the client itself, not received by it. That leads me to believe that there are two viable paths forward: Rearrange the errors so that they mirror the alerts above (leaving 's semantic as stated above); e.g., we'd have , , and so forth Reduce everything into two errors, and or similar. Both would carry the TLS Alert value as an additional payload item. I think the difference is mostly stylistic, so NAME and I can figure that out. The bigger question is whether this is the right set of errors to focus upon.
But I think this is missing an important detail: from the perspective of a client, the only stable output is the boolean. For example, OpenSSL's reporting of errors is symptomatic of deeper flaws within its certificate verification; fixing those errors necessarily means some existing errors can't effectively be reported. This is covered at some length in . Ultimately, the set of errors that are relevant are, to an extent, subject to local policy: it's rare for certificate validators to think of errors in the ontology laid out by the TLS layer. Typically, a client just does a "best guess" (or just maps straight to ) when trying to map to the TLS layer, in part so it doesn't disclose extra information. This is certainly true when you think about local policy, such as limits on validity or the requirement of associated metadata, potentially delivered over TLS, such as Certificate Transparency or OCSP Must-Staple.
Code change:
Recommended HTTP status code: 400 <del> 2.3.30. </del> <ins> 2.3.26. </ins> Name: http_upgrade_failed

Related discussion:
text: I think the core question is whether you expect the client and the proxy to be in the same management domain. If they aren't, and the ED seems to be oriented around this scenario (where server and proxy are likely same administrative domain, but proxy and client aren't), then it seems better served as an opaque diagnostic string. As RFC 4158 calls out, beyond the 'boolean' is really just an administrative/diagnostic capability, not something meant to be semantically rich, meaningful, or stable, and certainly not to allow next-hop policy decision making.
Just to be clear - the user agent isn't involved in this at all, beyond receiving the header so as to make it available to someone diagnosing a problem (Likely someone from the origin, from the CDN/reverse proxy operator, and/or a help desk talking to an end user). What I think I hear you saying is that we should define a generic error and allow implementations to convey textual detail in it. Does that make sense? I also still see some value in distinguishing a TLS alert received from the origin by the proxy (in its role as TLS client) from this case (a problem it encounters as a TLS client).
Yes. This matches with Criterion 2 of URL and the dual mode trade-off in URL , which perhaps more clearly highlights the local policy aspect ("Ultimately, the developer determines how to handle the trade-off between efficiency and provision of information"). 100% agreed here. I was only commenting to the extent at which the proxy validates the peer certificate independent of the TLS layer framing. Perhaps poorly stated, but my comment in URL was trying to capture that Option 2 from URL () would likely just reduce to a boolean anyways, in a well-behaved TLS client.
Code change:
only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an offline, universally-verifiable proof that an entry is recorded in <del> the Append-only Log.  Receipts do not expire, but it is possible to append new entries (more recent Signed Statements) that subsume older entries (less recent Signed Statements). </del> <ins> the Append-only Log.  Requesting a receipt can result in the production of a new receipt for the same signed statement.  A Receipt's verification key, signing algorithm, validity period, header parameters or other claims MAY change each time a Receipt is produced. </ins> Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent

Related discussion:
text: To facilitate this forward for submission on Monday, I'm going to merge a few changes for additional discussion/review.
Fair, could you provide a suggested change? [edit] let me elaborate: not making iat mandatory! But about the fact that extension points in Receipts can render them with an expiration date and that only in the architecture's base definition they do not expire.
After reviewing comments and the paragraph this change sits within, the merged suggestions make a minor improvement, and I don't believe rewinds any problems. While we can/should make additional improvements, can we adopt this change? NAME NAME you have blocking requests. If the merged suggestions don't resolve your concerns, can you either make an additional suggestion or comment on why this shouldn't be merged?
NAME here you go: URL
The changes that have been made to the pull request has lost somethings. The logical receipt itself does not expire. The evidence captured in the ledger is more than just the hash of the signed statement as it has to capture the tests done to the signature and the results. That evidence and where it sits in the ledger establishes a time basis for the decision. A new signature on top of that linkage to the evidence in the ledger is being equated as a whole as the receipt. The "thing" signed is the same (location into the ledger) and the only thing that has changed is possibly the identity key material and algorithm. It is this concept of "never" expiring that is important to key.
from :
Tagging NAME
NAME we'll close this in a week and can reconsider with a PR.
Referring to , the latest changes provide the flexibility for Transparency Services to maintain previous receipts and re-issue them or generate new receipts which may not be persisted. As such, I'm approving this PR as incremental progress.
Code change:
"insecure" - for insecure algorithms, <del> "reserved" - for algorithms that use a reserved token value that cannot be expressed in Structured Fields </del> Description: a short description of the algorithm Reference(s): pointer(s) to the primary document(s) defining the <del> technical details of the algorithm, and optionally the key </del> <ins> Algorithm Key and technical details of the algorithm </ins> When reviewing registration requests, the designated expert(s) should pay attention to the requested status.  The status value should

Related discussion:
text: SGTM. Feel free to merge if you are sure we won't need this. Kind regards, R
John Scudder raised during IESG review: algorithms that use a reserved token value that cannot be expressed in Structured Fields". This is a well-formed sentence but I have no idea what it means. I made a desultory attempt to suss it out by searching the document for "token" and this was the only occurrence. If people who will actually be making use of the registry can be expected to make sense of it, then feel free to disregard my comment, of course. This reminded me at some point, I'd sketched out a design for the "Hash Algorithms for HTTP Digest Fields" registry that worked differently with what we ended up with now. In that design, it would have been possible to register an algorithm in the table under some friendly name and then separately register some Structured-Fields identifier that it related to. This would have made it possible to register an algorithm but reserve it from being used, in order to (for example) try and maintain some parity with old digest. Needless to say, the original sketch design had flaws and we didn't go that way. Instead, the registry requires entries to be identified using a Structured Fields key, which makes the idea of a reserved status due to a key that can't be used rather strange. TL;DR lets remove the "reserved" status because it isn't used by anything already and doesn't have much logic behind how it would be used in future.
We need to evaluate and possibly pare down / adjust the flags in the frame, based upon real-world use cases. See Kazuho's evaluation: URL
I agree the need for evaluation. OTOH, I do not think we should pare down / adjust flags, since real-world use cases could change as time evolves. The way it is defined now represents the cache state as-is and I believe that it would be most resilient in the long term.
OK.
Code change:
Interactive client-server applications.  For example, a "click here to speak to a representative" button on a website that starts an <del> interactive WebRTC call.  Such applications avoid the NAT traversal issues that complicate peer-to-peer use of QUIC, and can benefit from stream demultiplexing and (if appropriate algorithms are provided) </del> <ins> interactive WebRTC call.  Because a connection is being established to a known server, such applications avoid the NAT traversal issues that complicate peer-to-peer use of QUIC, and can benefit from stream demultiplexing and (if appropriate algorithms are provided) </ins> congestion control.  They would benefit from unreliable delivery modes to reduce latency.

Related discussion:
text: One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!
Code change:
the firewall by an appropriate pseudonym for that host. An intermediary MAY combine an ordered subsequence of Via header <del> field entries into a single such entry if the entries have identical </del> <ins> field list members into a single member if the entries have identical </ins> received-protocol values.  For example, could be collapsed to <del> A sender SHOULD NOT combine multiple entries unless they are all </del> <ins> A sender SHOULD NOT combine multiple list members unless they are all </ins> under the same organizational control and the hosts have already been <del> replaced by pseudonyms.  A sender MUST NOT combine entries that have </del> <ins> replaced by pseudonyms.  A sender MUST NOT combine members that have </ins> different received-protocol values. 5.6.2.

Related discussion:
text: Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:
Code change:
The underlying transport has properties that do not meet minimum security requirements (see TLSUsage). <ins> The endpoint requires that HTTP/1.1 be used instead of HTTP/2. </ins> Unknown or unsupported error codes MUST NOT trigger any special behavior.  These MAY be treated by an implementation as being equivalent to

Related discussion:
text: This is an update of :
There have been a number of discussions about scenarios where we may want the client to fall back to 1.1 (a server forcing gzip, APIs incompatible with HPACK, etc.). HTTP/1.1 defines status code 505 as indicating that the server "refuses to support the major version of HTTP that was used in the request message [and] is unable or unwilling to complete the request using the same major version as the client [...] other than with this error message." However, that doesn't define a programmatic way to tell the user agent what version to retry with, simply a representation to be shown to the user. We should define a way to inform the client what HTTP version to retry with (presumably 1.1).
Discussed in NYC; task force-ish to come up with a proposal either using 505 or a new status code + header to point to the version(s) to bounce to.
Mark to write draft. use 505 extra header what version to down/upgrade to what the scope of applicability is (server vs resource) cache-control applies
Discussed in person, but capturing here: Scope could also be a path prefix, not just a single resource.
Marking this one as non-blocking. We need to discuss adoption of a mechanism for this; and that's not going to happen in the sorts of time frames we're talking about.
Can this be closed -- i.e., do we need to actually reference the new draft in HTTP/2?
Yep.
Reopening (preliminary) based upon feedback from Mike.
Code change:
1.3.3. The client credentials or other forms of client authentication (e.g. <del> a "client_secret" or a private key used to sign a JWT) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.  Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. </del> <ins> a private key used to sign a JWT, as described in RFC7523) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.  Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. </ins> 1.4.

Related discussion:
text: OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.
Code change:
8.3.2. <del> For HTTP/2 responses, a single </del> <ins> For HTTP/2 responses, a single " </ins> <del> pseudo-header field is defined that carries the HTTP status code </del> <ins> " pseudo-header field is defined that carries the HTTP status code </ins> field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed.

Related discussion:
text: I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.
Code change:
instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client- assertion-type:jwt-client-attestation" authentication method.  The <del> client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued. </del> <ins> client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used for client authentication when the refresh token was issued. </ins> 6.

Related discussion:
text: The "Refresh token binding" section requires "The client MUST also use the same Client Attestation." What is the intention of the requirement from the following options? The exactly same client attestation JWT. The refresh token becomes invalid after the client attestation JWT expires. Even if the attester issues a new client attestation JWT for the same client key, the new client attestation JWT would not work with the refresh token. If the requirement expects this behavior, AS implementations would simply use the hash of the client attestation JWT to judge whether the client attestation JWT presented in the refresh token flow is identical to the previous one. Any client attestation JWT for the same client key issued by the same attester. If this is the actual intention of the requirement, even after the original client attestation JWT expires, the refresh token can be used with a new client attestation JWT issued by the same attester. In this case, AS implementations would check the combination of the attester's identifier and the client key during the refresh token flow. Any client attestation JWT for the same client key issued by any attester the AS trusts. If this is the actual intention of the requirement, even after the original client attestation JWT expires and/or even after the attester ceases its service, the refresh token can be used with a new client attestation issued by any attester the AS trusts. In this case, AS implementations would check the JWK thumbprint of the client key only during the refresh token flow and would not check whether the attester is identical to the one of the previous client attestation JWT. FYI: defines a mechanism to bind an X.509 certificate to an access token. The specification states that a JWT access token should include (which represents the SHA-256 thumprint of an X.509 certificate) in its payload if the access token is bound to a certain X.509 certificate. It results in that certificate-bound access tokens and refresh tokens expire when their X.509 certificates expire and that renewing X.509 certificates for the same subject does NOT revive the access tokens and refresh tokens. Therefore, client applications have to go through an authorization flow again to get a new access token once the X.509 certificate bound to the previous access token expires. There are pros and cons.
Code change:
instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client- assertion-type:jwt-client-attestation" authentication method.  The <del> client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued. </del> <ins> client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used for client authentication when the refresh token was issued. </ins> 6.

Related discussion:
text: The requirement will need to be rephrased depending on what the "refresh token binding" wants to achieve.
Yeah, the statement "The client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued." is problematic and needs to be removed or rephrased. The intent, as I understand it from previously discussing/pushing the issue of RT binding for this draft, is that the RT needs to be bound to the client instance. And that means binding the RT to the client instance's key. I think Tobias didn't want to go so far as saying that b/c he thought it was too inflexible. But the client instance's key is currently the only thing here that uniquely identifies the client instance.
NAME is correct around the intent here, I agree the wording makes it unclear so it should be clarified that the binding is to the client instance key used when the RT was issued.
Why not just use the same client attestation JWT? That would not require any client instance identification and is also not a privacy issue. urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation -> urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation Originally posted by NAME in URL
Related to . The problem with this model is that the refresh token if bound to the client attestation JWT then limits the RT lifetime.
Code change:
Any number of HEADERS frames can may be sent on an existing stream at any time. <del> The HEADERS frame does not define any type-specific flags. </del> <ins> Additional type-specific flags for the HEADERS frame are: </ins> <del> The body of a HEADERS frame contains a HeaderBlock. </del> <ins> Bit 2 being set indicates that this frame does not contain the entire payload necessary to interpret the HEADERS data.  The payload in any series of headers frames is only interpretable when HDR_CONTINUES has NOT been set, and then only when concatenated with the payload from the unbroken series of HEADERS frames where HDR_CONTINUES was set.  When this bit is set for a HEADERS frame on a particular stream (A), HEADERS frames MUST NOT be sent on other streams until a HEADERS frame has been sent on the same stream (A) where the HDR_CONTINUES bit is unset. The payload of a HEADERS frame contains a HeaderBlock. </ins> The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the

Related discussion:
text: Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL: