jiebi/CodeConvo huggingface dataset:
Code change:
content, or poison a cache.  See security.considerations for security considerations regarding message routing. <ins> Unless the caveat above applies, an origin server MUST reject a request if any scheme-specific requirements are not met.  In particular, a request for an "https" resource MUST be rejected unless it has been received over a connection that has been secured via a certificate valid for that target URI's origin, as defined by https.uri. </ins> The status code in a response indicates that the origin server has

Related discussion:
text: Note that if we go in this directions, there are some editorial improvements in that we should pull in separately.
I find Roy's proposal more precise. The overall text does slightly help me find how to figure a scheme in H1.
From NAME - Let's discuss whether the currently specified procedures for reconstructing the target URI from a request-target in absolute-form provide adequate security properties, at the origin server. I'm specifically concerned about taking the scheme directly from the request target, i.e., making the distinction between the "http" and "https" schemes. The simple procedure of "take the scheme from the request-target" would seem to allow for the client to cause the server to engage processing for the "https" origin without receiving the protection that https is supposed to provide. (The converse case does not immediately seem to present much risk but is probably worth preventing as well on general principles of retaining consistency.) I don't remember seeing any text that would require the server to validate the scheme from the request-target against the actual properties of the transport (or the configured fixed URI scheme as might be provisioned with a trusted outbound gateway, etc.) While we do reference §7.4 of [Semantics] with a note that reconstructing the target URI is only part of the process of identifying a target resource, that part of [Semantics] does not mention scheme validation as part of rejecting misdirected requests. Does the origin server need to validate the scheme from an absolute-form request-target? What is the scope of consequences if it fails to do so?
I said: In 3.3 of 1.1 I was skimming by the initial text: The target URI is the request-target when the request-target is in absolute-form. ... whereas you obviously picked up on it. I agree that there's an issue here. The decisions about absolute-form requests were made way back when. My reading of the archive (circa September and October 1995 -- I'm sure those that were there will correct me) is that Host headers were added to address the multiple-hosts-on-an-IP problem in a way that was backwards-compatible with HTTP/1.0, but because some folks wanted to enable the use of URNs, proxies were required to support and use the absolute form, so that URNs could be (theoretically) resolvable through them.
Code change:
content, or poison a cache.  See security.considerations for security considerations regarding message routing. <ins> Unless the caveat above applies, an origin server MUST reject a request if any scheme-specific requirements are not met.  In particular, a request for an "https" resource MUST be rejected unless it has been received over a connection that has been secured via a certificate valid for that target URI's origin, as defined by https.uri. </ins> The status code in a response indicates that the origin server has

Related discussion:
text: That didn't happen, but it is possible to use e.g., FTP through a HTTP proxy as a result (last I looked). I think the solution here is to restrict the statement above so that it only applies to proxies, and to add a requirement for origin servers (including gateways) to specifically check absolute-form URIs for alignment regarding the scheme.
It seems to me that the ability to do cross-protocol requests is a deliberate feature of HTTP, and not one we should interfere with now, even if it's rarely used. In fact, RFC 8164 explicitly relies on the ability to request "http" resources over an "https" connection. I agree that servers should not respond to requests that assume a secure channel over an insecure one. While Sections 4.2.2 and 4.3.3 seem to put most of the burden on the client not to make such requests, the server should probably consider such a request misdirected even if it is authoritative. Perhaps the least disruptive solution would be text in 7.4 adding https:// URIs received over insecure connections as another instance of a potentially misdirected request?
Before I get into the text, I need to clarify that this question is misplaced. The procedure for reconstructing the target URI is about reconstructing what the client sent. It is not about security (yet). It has nothing to do with ensuring the connection is secure. It is about understanding the request as received. AFTER the request is understood, the server needs to determine whether it can answer the request in that context. How it determines that is an internal configuration issue, not a protocol standard (because HTTP requests can arrive via any underlying transport), but there are things we can add to make the process clearer without assuming that all HTTP requests are made by general-purpose browsers.
Code change:
user authentication using asymmetric cryptography that can be invoked from a web browser or native client.  Version 2.2 of the FIDO Client to Authenticator Protocol (CTAP) supports a new cross-device <del> authentication protocol, called "hybrid", which enables an external device, such as a phone or tablet, to be used as a roaming </del> <ins> authentication protocol, called "hybrid transports", which enables an external device, such as a phone or tablet, to be used as a roaming </ins> authenticator for signing into the primary device, such as a personal computer.  This is commonly called FIDO Cross-Device Authentication <del> (CDA). </del> <ins> (CDA).  CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms. </ins> When a user wants to authenticate using their mobile device (authenticator) for the first time, they need to link their authenticator to their main device.  This is done using a scan of a QR code.  When the authenticator scans the QR code, the device sends an encrypted BLE advertisement containing keying material and a <del> tunnel ID.  The main device and authenticator both establish connections to the web service, and the normal CTAP protocol exchange occurs. </del> <ins> tunnel ID.  The main device (CTAP client) and authenticator both establish connections to the web service, and the normal CTAP protocol exchange occurs. </ins> If the user chooses to keep their authenticator linked with the main device, the QR code link step is not necessary for subsequent use.

Related discussion:
text: Addresses issue NAME
From WGLC Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." see: URL NAME
Code change:
application requirements.  In order for these types of application deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application <del> server.  A common way this information is conveyed in practice today is by using non-standard fields to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but </del> <ins> server.  At the time of writing, a common way this information is conveyed is by using non-standard fields to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but </ins> interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices respectively made (like what field names are used or are

Related discussion:
text: Intro para 3 has a chunk of text about fields not defined in this doc This could be condensed to say that the header fields in this document provide a standardized replacement for custom or proprietary fields that were known to be used prior to this document.
It is perhaps a bit long winded and admittedly not award winning literature. But I think it's useful context for the reader and prefer to keep it.
Right but in 20 years if the RFC says "a common practice today is using non-standard fields" it could read odd. Its clearer if this spec focuses on what it provides not what people came up with as custom solutions beforehand.
Thanks, looks good!
Code change:
authentication of one workload to another, such as in the case where one service is making a request to another service as part of a larger, more complex application.  Following authentication, the <del> request to the service offered by the workload it needs to be </del> <ins> request to the service offered by the workload needs to be </ins> authorized.  Even in this simple case the identity of a workload is often composed of many attributes such as:

Related discussion:
text: Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.
Code change:
The HTTP response SHOULD use gzip Content-Encoding as defined in RFC9110. <ins> If caching-related HTTP headers are present in the HTTP response, Relying Parties SHOULD prioritize the exp and ttl claims within the Status List Token over the HTTP headers for determining caching behavior. </ins> 8.3. Upon receiving a Referenced Token, a Relying Party MUST first perform

Related discussion:
text: We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL
Code change:
8859-1, supporting other charsets only through use of RFC2047 encoding.  Specifications for newly defined fields SHOULD limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB.  A recipient <del> SHOULD treat other octets in field content (obs-text) as opaque data. </del> <ins> SHOULD treat other allowed octets in field content (i.e., </ins> <del> Field values containing CR or NUL characters are invalid and </del> <ins> ) as opaque data. Field values containing CR, LF, or NUL characters are invalid and </ins> dangerous, due to the varying ways that implementations might parse <del> and interpret those characters; a recipient of CR or NUL within a field value MUST either reject the message or replace each of those </del> <ins> and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those </ins> characters with SP before further processing or forwarding of that message.  Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake <del> of robustness if they only appear within safe field value contexts (e.g., opaque data). </del> <ins> of robustness when they appear within a safe context (e.g., an application-specific quoted string that will not be processed by any downstream HTTP parser). </ins> Fields that only anticipate a single member as the field value are referred to as

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.
Code change:
Use the "validate" API to confirm the validity of the authenticator with regard to the generated request (if any). <ins> If the authenticator cannot be validated, this SHOULD be treated as a connection error of type "CERTIFICATE_UNREADABLE". </ins> Once the authenticator is accepted, the endpoint can perform any other checks for the acceptability of the certificate itself. Clients MUST NOT accept any end-entity certificate from an exported

Related discussion:
text: though I'm not sure it's yet precise enough. There are three general classes of errors: The peer did something wrong. There are relatively few of these possible -- indicating more certificates to use than were requested, or more than one unsolicited certificate; sending CERTIFICATE_NEEDED to a peer that didn't indicate support for this extension. The authenticator is corrupt. This might indicate a problem with the TLS connection. The certificate isn't acceptable. There are lots of reasons this might happen. The first two should be at least stream and possibly connection errors. The latter should be handled at the HTTP layer, but previously had error codes defined for them. This PR removes several error codes and recommends handling at the HTTP layer if the certificate isn't accepted.
It is very unclear from the draft how exactly the client should handle a secondary server certificate it rejects. Presumably a bad secondary certificate should not be fatal to streams which don't use it. The draft seems to handwaive at this (though not very clearly, which means uncertainty for the server) in section 4. At the same time, the draft says: This is inconsistent with that idea. Suppose the server pushes some CERTIFICATE frame along with some resources it thinks the client would want. If the client rejects that certificate, this text implies the client must tear down the entire connection, interrupting unrelated requests. A useful heuristic for reasoning through all this would be to consider a client which blindly rejects every secondary certificate. This is especially relevant if the draft does not act on .
The restriction on the server is that it not push unless it has first sent the certificate. If the client rejects the certificate, clearly it will discard the push; the question is whether the client will be able to differentiate failure-to-send from cert-not-accepted. That depends on whether you assume that clients will look at the certificates, even if they aren't accepted; otherwise, I suspect that it can't. However, I think you're right that this is an overreaction. RFC7540 requires that a PUSH_PROMISE for an unproven origin be treated as a stream error, but doesn't specify on which stream. The parent stream still seems excessive, since the server can't know for which origins the client considers it authoritative.
Code change:
contained in the JWT, which is a requirement to implement the three- party-model efficiently. <del> Selective Disclosure JWT (SD-JWT) [SD-JWT] is a specification that introduces conventions to 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 Verifiable Credentials and Verifiable Presentations. </del> <ins> Selective Disclosure JWT (SD-JWT) I-D.ietf-oauth-selective- disclosure-jwt is a specification that introduces conventions to 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 Verifiable Credentials and Verifiable Presentations. </ins> SD-JWT itself does not define the claims that must be used within the payload or their semantics.  This specification therefore defines how

Related discussion:
text: This just fixes typos and references.
This just fixes typos and references. No review required at this stage.
Code change:
at the index corresponding to the number of entries in the header table. <del> The header table is initially empty. </del> <ins> The header table is initially empty.  Entries are added as each header block is decompressed. </ins> The header table can contain duplicate entries.  Therefore, duplicate entries MUST NOT be treated as an error by a decoder.

Related discussion:
text: Looks like I caught some trailing whitespace at the same time.
The trailing whitespace came from an automatically generated part of the spec and will reappear if I ever re-generate the examples. In addition, it really should be here ;-).
Code change:
The request method is understood by the cache and defined as being cacheable, and <ins> the response status code is final (see associating.response.to.request), and </ins> the response status code is understood by the cache, and the "no-store" cache directive (see header.cache-control) does not

Related discussion:
text: seems like it should be in messaging.
Part of it needs to be in messaging (how to do it per version), while a shorter description needs to be here just to point out that it is version dependent. The semantics don't make any sense otherwise.
Ack. Will take a stab at it.
The caching document should clarify that only final responses are cached.
Works for me.
Code change:
with the types defined in params and error-types respectively; see register-param and register-error for its associated procedures. <ins> Additionally, please register the following entry in the Hypertext Transfer Protocol (HTTP) Field Name Registry: Field name: Proxy-Status Status: permanent Specification document(s): [this document] Comments: </ins> 4. One of the primary security concerns when using Proxy-Status is

Related discussion:
text: wouldn't the "Proxy-Status" header field require an action in the IANA considerations section to register the header field itself? currently, the only things in this section are the creation of new registries required for the header field.
a la rewriting, invalidation controls, etc. See
Code change:
The retrieved Receipt may be embedded in the corresponding COSE_Sign1 document in the unprotected header. <del> 3. </del> <ins> 4. </ins> Privacy Considerations <del> 4. </del> <ins> 5. </ins> Security Considerations <del> 5. </del> <ins> 6. </ins> Maybe <ins> 6.1. This section requests registration of the "application/receipt+cose" media type RFC2046 in the "Media Types" registry in the manner described in RFC6838. TODO: Consider negotiation for receipt as "JSON" or "YAML".  TODO: Consider impact of media type on "Data URIs" and QR Codes. To indicate that the content is a SCITT Receipt: Type name: application Subtype name: receipt+cose Required parameters: n/a Optional parameters: n/a Encoding considerations: TODO Security considerations: TODO Interoperability considerations: n/a Published specification: this specification Applications that use this media type: TBD Fragment identifier considerations: n/a Additional information: Magic number(s): n/a File extension(s): n/ a Macintosh file type code(s): n/a Person & email address to contact for further information: TODO Intended usage: COMMON Restrictions on usage: none Author: TODO Change Controller: IESG Provisional registration?  No </ins>

Related discussion:
text: A few thoughts after IETF 117. Goals: Address identity up front (by not addressing it directly). Frame feeds in the context of the API Relate media types to feeds This PR is mostly placeholders for future work, but hopefully highlights some areas for follow up based on our in person discussions.
NAME I can't merge this, but we should unless there are changes requested.
fixed collaborator list
LGTM
Code change:
IANA will be requested to register the new COSE Header parameters defined below in the "COSE Header Parameters" registry at some point. <ins> Name: tree_alg Label: TBD Value type: tree_alg Value registry: See Description: Merkle tree algorithm used to produce a COSE Sign1 payload. </ins> 7.2. IANA will be asked to add a new registry "TBD" to the list that <del> appears at https://www.iana.org/assignments/. </del> <ins> appears at IANA Assignments [1]. </ins> The rest of this section defines the subregistries that are to be created within the new "TBD" registry.

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.