jiebi/CodeConvo huggingface dataset:
Code change:
"delta-seconds" is used as defined in Section 1.2.1 of RFC 7234 RFC7234. <ins> 2.1.4. The following examples demonstrate valid Expect-CT response header fields: </ins> 2.2. This section describes the processing model that Expect-CT Hosts

Related discussion:
text: This changes Expect-CT to be a comma-separated list of directives (which may be name=value pairs), and adds some examples. Also allows the server to send multiple header fields so that they can be combined, as per URL Fixes issue ,
Would it be possible to include an example in the spec? Something like... Expect-CT: enforce; max-age=3600; report-uri="URL" As I believe most developers like to work with examples, rather than just using the spec definition as found under the heading "Response Header Field Syntax". :-)
Code change:
13.3. <del> &#65532; The "contentMD5" digest-algorithm token defined in Section 5 of RFC3230 is removed from the HTTP Digest Algorithm Values Registry. </del> <ins> The "contentMD5" digest-algorithm token defined in Section 5 of RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. </ins> All digest-algorithms defined in RFC3230 are now "deprecated". 13.4. <del> The digest-algorithm values for "MD5", "SHA", "SHA-256", "SHA-512" </del> <ins> The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" </ins> have been updated to lowercase. The status of "MD5" and "SHA" has been updated to "deprecated", and <del> their description states that they MUST NOT be used. </del> <ins> their description has been modified accordingly. </ins> The "id-sha-256" and "id-sha-512" algorithms have been added to the registry.

Related discussion:
text: add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need.
Code change:
13.3. <del> &#65532; The "contentMD5" digest-algorithm token defined in Section 5 of RFC3230 is removed from the HTTP Digest Algorithm Values Registry. </del> <ins> The "contentMD5" digest-algorithm token defined in Section 5 of RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. </ins> All digest-algorithms defined in RFC3230 are now "deprecated". 13.4. <del> The digest-algorithm values for "MD5", "SHA", "SHA-256", "SHA-512" </del> <ins> The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" </ins> have been updated to lowercase. The status of "MD5" and "SHA" has been updated to "deprecated", and <del> their description states that they MUST NOT be used. </del> <ins> their description has been modified accordingly. </ins> The "id-sha-256" and "id-sha-512" algorithms have been added to the registry.

Related discussion:
text: If there's any question from the DEs they can always kick it back out for further review.
NAME Seems that NAME is on the same page URL ;) So let it be Specification Required! Move on :)
Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4.1.2. </del> <ins> 4.3. </ins> <del> The following rules apply to validating the Client Attestation JWT. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating the Client Attestation PoP JWT.  Application of additional restrictions and policy are at the </ins> discretion of the Authorization Server. The JWT MUST contain an "iss" (issuer) claim with a value

Related discussion:
text: Based on the discussions had at IETF 119 in the OAuth WG, this PR attempts to make the following changes to the draft Move away from usage of the assertion framework defined in RFC 7521 and RFC 7523 for conveying the client attestation and client attestation pop. Instead use two newly defined HTTP headers OAuth-Client-Attestation and OAuth-Client-Attestation-PoP for conveyance in an HTTP request, akin to how DPoP works. Explicitly mention this mechanism could be used in a variety of places including with a resource server. Note, there are still many outstanding items I would like to add, however I felt this PR was already big enough as it is, these include Error responses for the token endpoint Optimisation for when this mechanism is used with DPoP to avoid having to send two PoP's Formalising whether this mechanism still constitutes a form of client authentication
For some reason it seems to not create an html version? This is the rendered text: URL
I think there were potential objections mentioned about moving to headers as to whether we'd run into size limits (I think 8 KB was mentioned as a common restriction) and people felt jwts with embedded x5c headers etc may get close to these limits?
NAME indeed. We may have a client attestation with an huge x509 certificate chain or an openid federation trust chain with several metadata, trust marks and jwks. I don't see the benefit of moving from what it is actually more efficient (wa~wa-pop) more over, technically we can have multiple client_assertions that embedes their pop (using ~), while having multiple http headers that divide attestation from pop forces the implementations to loop all the assertions and all the pop to find the matching ones
Added client instance definition and updated to use US based spelling of authorization instead of authorisation.
NAME NAME I can understand the desire to want to use X.509 certificates to validate the client assertion (e.g as an alternative key resolution mechanism to resolving a JWKS document from a domain), however I don't see how the certificate chain would be more then 1 certificate (maybe 2) in length (bearing in mind the root certificate(s) would be communicated to the issuer out of band and pre-trusted for the client).
Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4.1.2. </del> <ins> 4.3. </ins> <del> The following rules apply to validating the Client Attestation JWT. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating the Client Attestation PoP JWT.  Application of additional restrictions and policy are at the </ins> discretion of the Authorization Server. The JWT MUST contain an "iss" (issuer) claim with a value

Related discussion:
text: W.r.t other aspects of the client attestation or client attestation pop being too big for an HTTP header could you elaborate on what you see as the contents of your attestation NAME Because IIUC you perhaps want to use the client attestation to convey all client metadata? If that is the case IMO the client attestation isn't for this purpose, client metadata should continue to be communicated outside of these attestations with the pre-existing mechanisms we already have defined. Finally even if we did begin to encroach on header payload limits with a client attestation, we aren't talking about hard limits here, rather just the default maximums that common web server platforms have configured, which can always be adjusted.
there some point for clarification assertion weight: a client assertion may have a x5c or an openid federation trust chain within its JWT header. This is an issuer's choice, allowed by RFC 7515 that might be not supported by httpd maximum header body size, that's a deployment/configuration choice that might be different within different domains. chain length: it could be assumed that a chain may not exceed 2 or 3 certificate breaks. This depends on the number of intermediates, an aspect that falls outside the technical specification and is determined by the federation's topology and composition. client metadata: we have some required claims in the wallet attestations and the possibility to include any other custom claim or any other claims pertaining the wallet capabilities or anything else related to the trust framework. My comment is not related to assertion payload, but to the previous point 1 and 2. However, the payload also impacts in the assertion weight, as pointed out at point 1. The missing point concerns the processing of multiple DPoP tokens within the same request. Handling multiple DPoP tokens necessitates a loop to identify the one that matches a specific assertion. This introduces additional computational and development efforts not present in the current approach (WA~WA-POP), which directly associates an assertion with its proof of possession (PoP), facilitating a straightforward and efficient identification of matching pairs.
Ok great so do we agree that this isn't an issue because servers are freely able to re-configure the max header size based on their application? Because it isn't a hard limit.
Understood but based on the above point is this actually an issue if the limit on header size isn't a hard limit?
Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4.1.2. </del> <ins> 4.3. </ins> <del> The following rules apply to validating the Client Attestation JWT. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating the Client Attestation PoP JWT.  Application of additional restrictions and policy are at the </ins> discretion of the Authorization Server. The JWT MUST contain an "iss" (issuer) claim with a value

Related discussion:
text: Right but to be clear, the current draft does not handle multiple wallet attestations either though so I think this a new requirement that we should discuss separately, would you mind opening a seperate issue?
The issue extends beyond the realm of multiple wallet attestations, as there could also be multiple DPoP tokens involved. An additional consideration, which we have not yet fully addressed but may emerge as a future requirement, is the scenario where a wallet instance operates under more than one trust framework, necessitating specialized assertions for each. While we have consciously chosen to limit the scope to a single wallet attestation to simplify implementation, it's important to acknowledge that this decision does not preclude the possibility of requiring multiple assertions in the future. Implementers may need to adapt or extend the specification to accommodate such needs. However, to avoid digressing further, let's focus on the matter of handling multiple DPoP headers for now. The approach currently documented, which aims to streamline the process by limiting it to a single attestation, is designed to offer the same benefits while minimizing computational overhead.
While it is possible to reconfigure these options, it is important to keep default values of the wide-spread implementations in mind to allow an easy path for adoption. I took the time to look at some of the frameworks I would say are good indicators: nginx: --> 8KB for 1 header max envoy (used in istio): --> 60 KB for headers URL --> 16KB for headers traefik: --> re-uses go/http: 1MB for headers --> After looking at this, I would say we can go with headers
An OpenID Federation trust chain with two intermediates, the trust anchor entity configuration with a long list of trust mark issuers and the leaf entity configuration with a very verbose configuration, such as an AS + Openid4VCI + OpenID4VP (considering an EAA provider), with policies and a consistent number of trust mark might be 20KB. A serialized X.509 certificate chain, with 4 intermediates, custom extensions and QWACs ... Considering each certificate up to 2.2KB, might it be 8.8KB?
Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4.1.2. </del> <ins> 4.3. </ins> <del> The following rules apply to validating the Client Attestation JWT. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating the Client Attestation PoP JWT.  Application of additional restrictions and policy are at the </ins> discretion of the Authorization Server. The JWT MUST contain an "iss" (issuer) claim with a value

Related discussion:
text: (please, consider that openid federation brings policy languages, trust marks and multiple protocol specific metadata) I'm worried about these aspects: loop required for parse/matching the correct DPoP when multiple DPoP are present, while WIA~WIA-POP doesn't bring this problem. What's the benefit of having this breaking change that reduce the flexibility while increasing the complexity? size limitations: Do we have to imagine to standardize something upon the assumption that a federation topology should not have more than 2 or 4 or 8 intermediates, since this decision is out of scope on this specification.
A bit off-topic for the current discussion: We need to fix the examples - they are way too long which breaks the rendering/conversion and will cause problems with the datatracker. I do believe that this is also the reason why the html file was not created.
Note that rfc9449 does not allow for multiple DPoP headers. It could maybe have been stated more clearly but is kinda implied and was absolutely the intent of the RFC overall and specific text like URL
NAME as I implied with my earlier comment, the current draft text doesn't support multiple attestations so I don't view this proposal to shift to headers as removing functionality, it appears this is a new usecase and I think we should discuss it in a seperate issue. No I dont think we do, what was identified above is that there is no size limit on headers in HTTP rather defaults that servers apply which can be adjusted, in reality web servers also apply limits to the body of an HTTP request (although often much larger then what is allocated for headers).
Discussed with NAME I will add an implementation consideration around the default size limits for HTTP headers.
NAME what about using compressed values? unfortunately this sounds like giving a solution that may bring other problems, at the same time we can consider zlib (RFC 1950) for doing this.
Something broke with linking the html rendered versions properly Rendered html: URL
It just (re)occurred to me that specs defining new HTTP headers (which the cool kids call fields nowadays) are supposed to request their registration in the . I don't want to hold up this PR for this but will create an issue from this comment so as not to lose track of it.
Code change:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4.1.2. </del> <ins> 4.3. </ins> <del> The following rules apply to validating the Client Attestation JWT. Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating the Client Attestation PoP JWT.  Application of additional restrictions and policy are at the </ins> discretion of the Authorization Server. The JWT MUST contain an "iss" (issuer) claim with a value

Related discussion:
text: I do believe there should be a discussion about terminology (attestation vs assertion) as it seems to create quite a bit of confusion, but I do think a different issue/PR is better suited for that. Minor nit: Client Attestation seems to be used in lower and upper case somewhat inconsistently. Should every usage be upper case (e.g., also client attestation mechanism)?
Code change:
4.2. SD-JWT VCs MUST be encoded using the SD-JWT Combined Format for <del> Issuance as defined in I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> Issuance as defined in Section 5.3. of I-D.ietf-oauth-selective- disclosure-jwt. </ins> SD-JWT VCs MUST contain all Disclosures corresponding to their SD-JWT <del> component except for Decoy Digests as per section 5.1.1.3. of I- </del> <ins> component except for Decoy Digests as per Section 5.1.1.3. of I- </ins> D.ietf-oauth-selective-disclosure-jwt. 4.2.1.

Related discussion:
text: Only minor editorial changes such as typos.
Only minor editorial changes such as typos -> no peer-review required at this stage.
Code change:
Field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase <del> when constructing a HTTP/2 message.  A request or response containing an uppercase character ('A' to 'Z', ASCII 0x41 to 0x5a) in a field name MUST be treated as malformed. </del> <ins> when constructing a HTTP/2 message. </ins> HPACK is capable of carrying field names or values that are not valid in HTTP.  Though HPACK can carry any octet, fields are not valid in

Related discussion:
text: The validation for uppercase characters is no longer listed separately, but instead included with the minimal validation.
NAME : factored out non controversial changes from
Code change:
validation requests for the content might only be applicable along the same request path (through the same proxies). <del> The 203 response is similar to the Warning code of 214 Transformation Applied (field.warning), which has the advantage of being applicable to responses with any status code. </del> A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness).

Related discussion:
text: by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.
Code change:
validation requests for the content might only be applicable along the same request path (through the same proxies). <del> The 203 response is similar to the Warning code of 214 Transformation Applied (field.warning), which has the advantage of being applicable to responses with any status code. </del> A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness).

Related discussion:
text: "The 203 response is similar to the Warning code of 214 Transformation Applied (Section 5.5 of [Caching]), which has the advantage of being applicable to responses with any status code." But then we have removed "Warning"...
I think we can just remove this text; if it's important, we can refer to 7234 and mention that it's deprecated.
I say just remove the sentence.
Code change:
source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>. <del> The changes in this draft are summarized in changes.since.04. </del> <ins> The changes in this draft are summarized in changes.since.05. </ins> 1.

Related discussion:
text: NAME yes, as per issue discussion I was reconsidering this. See updated PR.
yeah, I like that. Will update.
It'd be good to say something about how weakly-framed content (e.g., no Content-Length in 1.0; no CL or chunked in 1.1) should be handled differently by caches, especially during reload. From URL
In , add:
currently has: Observations: the reference really should be more specific and go to "6.3. Message Body Length" is this clear enough for protocols other than HTTP/1.1?
Referring to h1-messaging 6.3 would make this specific to H1. Referring to 4.3.1 in caching keeps it protocol-generic. If another version doesn't crisply define what's an incomplete message, we can deal with that separately.
I think the text in 3.1 should change to:
This seems reasonable. It's also related to URL, asking whether servers can wait for end-of-stream to consider a message complete in HTTP/3. (Proposal in URL is "no, you can't.")
No, HTTP/1.0 is consistently optimistic. If the server desires more rigor, it can do the work to supply the framing that would indicate an error occurred. When it fails to do so, it is deliberately choosing to maximize performance over correctness. Hence, the assumption has always been that a close-delimited message is always complete.
I think Mark's suggestion is right. I would characterize HTTP/1.0 as ambiguous and that causes revalidation deadlocks. Its somewhat worse that this pattern needlessly shows up in HTTP/1.1 as well.
Thinking on this for a while, I think MAY might be more appropriate than SHOULD here; I have a strong suspicion that most caches will not consider a close-delimited response as incomplete. I could test it, I suppose.
Also, in the sentence: ...I think s/partial/incomplete/, based on context. Any concerns there?