jiebi/CodeConvo huggingface dataset:
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses the date-time, time-offset, and time-secfrac rules from RFC3339. </ins> 2. The HTTP fields listed in compatible-fields can usually have their

Related discussion:
text: I still believe this change should end up in the revision of SF.
That's
Some have pushed back on using integers for dates, see eg URL As I suggested there, one accommodation would be to define a new structured type for them. That could be done in retrofit, or separately.
I see no mention of fractional seconds ? I think we need to ponder that, if the goal is (eventual) convergence for all timestamps in HTTP ? Considering how much effort we spend on speeding up HTTP, I find the "human readable" argument utterly bogus. Only a very tiny fraction of these timestamps are ever read by humans, and most are in a context where software trivially can render the number in 8601 format if so desired. In terms of efficiency, I will concede that, in a HTTP context, it is almost always possible to perform the necessary calculations and comparisons on raw ISO-8601 timestamps, without resorting to the full calendrical conversions, but once all the necessary paranoia is included, I doubt it is an optimization. My preference is seconds since epoch, (and this is largely why has three decimals in the first place), because it gives us fast processing, good compression and millisecond resolution. PS: A Twitter poll with only 40 respondents, carried out on the first monday after new-years ? Really ?!
One argument against any "seconds since epoch" representation is that (at least under the ) it is incapable of representing an instant within a positive leap second (since "each and every day shall be accounted for by exactly 86400 seconds_", any such time would be interpreted as being in the first second of the following UTC day).
For HTTP I think subsecond precision is an overkill due to RTT / intermediaries.
IMHO: I like structured format. There are a lot of diagnostics and other software that would not want to do additional transcoding of header elements but just represent them verbatim as they occur. Those are helped if the verbatim representation is already easier readable. I do not think TZ belongs into a time/date representation. Aka: all date/times in UTC please. TZ can be added somehow as a "location" information, ideally in a different header field. If it is in the same header field, it would be confusing to show the time in UTC but ALSO to indicate the TZ.
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses the date-time, time-offset, and time-secfrac rules from RFC3339. </ins> 2. The HTTP fields listed in compatible-fields can usually have their

Related discussion:
text: Maybe this can be resolved by coming up that would make it as obvious as possible that the date/time is NOT adjusted for the TZ shown. Maybe not call it "TZ" but "LOC" so that the "the date/time it TZ adjusted" recognition is not triggered. And of course waste the three characters on "UTC" in the representation. I do not believe the processing speed argument to be valid. The level of processing speed where just a (sub)second unstructured value would help goes IMHO into the space of CoAP, not HTTP. I'd first try to make HTTP better where it does not just duplicate CoAP efforts. All that binary stuff CoAP needs to do is severely making toolchains more complex IMHO. I do like the leap-second argument. I do think msec accuracy should be an option. RTTs within lan/metro environments can easily be in the single digit msec range and you want to be able to diagnose e.g.: REST based broker/bus-type transaction speeds, relative ordering of request/replies.
Seems reasonable to me. +1 Not sure this is an "interface" that HTTP exposes / should be relied upon.
I suspect the experience of pretty much everybody writing and deploying HTTP intermediaries and servers at scale is different -- at those rates, cycles wasted on parsing do matter, especially when architectures have many layers of intermediaries to go through.
See linked PR for a proposal.
Re leapseconds: as written ("excluding leap-seconds") means that timestamps will be illegal, effectively mandating POSIX leap-second (non-)handling. To make able to handle leap-seconds requires that every HTTP handling entity needs an up to date file, either at system level or application level, and that the upper limit on the "internal data model range" becomes indeterminable, since we cannot predict how many leap seconds will happen in the future, nor what sign they may have. That is a total no-go from a systems engineering and complexity point of view, in particular as the rest of the world converges on either papering over leap-seconds or abolishing them. If the textual format cannot handle leap-seconds (without requiring a boat-load of complexity), then, why take the extra expense in CPU-load and code complexity ? As stated earlier, we should go for the more efficient and less error-prone solution: POSIX time_t (with optional milliseconds) as a .
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses the date-time, time-offset, and time-secfrac rules from RFC3339. </ins> 2. The HTTP fields listed in compatible-fields can usually have their

Related discussion:
text: (If we want to designate the timestamps with a senteniel, 'NAME is a particular bad choice, since the HPACK huffmann assigns it 13 bits.) PS: In context of four digit years: Century scale predictions, based on orbital considerations, expect the current leap-second regieme to break down in approx 2000 years, because we will need leap seconds more often than every month.
Do any current HTTP implementations take leap seconds into account? Regarding HPACK - it's one character. Let's not over-optimise here.
I don't know, but leap seconds are explicitly supported by : And the difference between 23:59:60 and following-day 00:00:00 would certainly be relevant for e.g. Last-Modified.
I have spent a lot of time over the years searching, but I have yet to see a 23:59:60 timestamp in the wild...
Now there's a picture in my mind of PHK walking the wilds, searching for an elusive date stamp.
I don't know what counts as "in the wild", but there is certainly documentation of and .
Discussion at IETF114 wasn't conclusive, but we now seem to be focusing on these options: Do nothing. Dates in SF are Integers (unless folks fall back to Strings), and recipients need to know that they're dates and how to handle them. Create a Date SF type along the lines of the PR. The textual representation is human-friendly, and it's identified as a date in a machine-readable way without special knowledge. Create a Date SF type but use an Integer; e.g., . The textual representation is not human-friendly, but it is identified as a date in a machine-readable way without special knowledge. I'll observe that if we believe that we'll eventually have a binary representation of structured fields widely in use, (2) is preferable in that it has the best properties -- it's both efficient and human-friendly. Of course, that's not at all certain. I'll also observe that in the discussions I've had, the people who want human-friendly representation are generally those who are working with tools and developers, "closer" to the application. The infrastructure folks and "lower layer" folks tend to minimise this aspect.
PR updated to reflect (3) above.
I personally support (2) or because it covers similar use cases than HTTP-date.
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses the date-time, time-offset, and time-secfrac rules from RFC3339. </ins> 2. The HTTP fields listed in compatible-fields can usually have their

Related discussion:
text: In case of (3) I think we can just use an Integer SF, like we do Signatures and other specs. Side note: we sometimes hear that RFC3339 is ambiguous. I think it is, and after ~20 years it probably requires a RFC3339bis that clearly specifies a basic profile ( T, Z uppercase; Always ). I'd be happy to start this work.
Why do the number of decimals need to be specified? Surely we could just say the format is nnnnn[.ddddddd] or similar where an integer-only parser stops at whitespace or a '.' while those who care about sub-second parsing continue on until they are satisfied with the resolution or they run out of digits. The senders decides how many decimals to provide, perhaps with a recommendation of three or upto their clock resolution? So "123456789" and "123456789.1" and "123456789.123456789" are all equally valid.
I like this direction; thanks.
Code change:
authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in <del> the "cnf" claim of the corresponding client attestation JWT. </del> <ins> the "cnf" claim of the corresponding Client Attestation JWT. </ins> The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.

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:
authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in <del> the "cnf" claim of the corresponding client attestation JWT. </del> <ins> the "cnf" claim of the corresponding Client Attestation JWT. </ins> The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.

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:
authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in <del> the "cnf" claim of the corresponding client attestation JWT. </del> <ins> the "cnf" claim of the corresponding Client Attestation JWT. </ins> The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.

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:
authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in <del> the "cnf" claim of the corresponding client attestation JWT. </del> <ins> the "cnf" claim of the corresponding Client Attestation JWT. </ins> The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.

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:
authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in <del> the "cnf" claim of the corresponding client attestation JWT. </del> <ins> the "cnf" claim of the corresponding Client Attestation JWT. </ins> The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.

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:
7.1.  URIs <del> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements </del> <ins> [1] https://github.com/moq-wg/moq-requirements </ins> [2] https://www.ietf.org/mailman/listinfo/moq

Related discussion:
text: NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"?
Code change:
7.1.  URIs <del> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements </del> <ins> [1] https://github.com/moq-wg/moq-requirements </ins> [2] https://www.ietf.org/mailman/listinfo/moq

Related discussion:
text: In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface: