jiebi/CodeConvo huggingface dataset:
Code change:
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line. <del> 8.1.2.3. COMPRESSION does not preserve the order of header fields, because the relative order of header fields with different names is not important.  However, the same header field can be repeated to form a list (see RFC7230), where the relative order of header field values is significant.  This repetition can occur either as a single header field with a comma-separated list of values, or as several header fields with a single value, or any combination thereof.  Therefore, in the latter case, ordering needs to be preserved before compression takes place. To preserve the order of multiple occurrences of a header field with the same name, its ordered values are concatenated into a single value using a zero-valued octet (0x0) to delimit them. After decompression, header fields that have values containing zero octets (0x0) MUST be split into multiple header fields before being processed. For example, the following HTTP/1.x header block: contains three Cache-Control directives; two directives in the first Cache-Control header field, and the third directive in the second Cache-Control field.  Before compression, they would need to be converted to a form similar to this (with 0x0 represented as '\0'): Note here that the ordering between Content-Type and Cache-Control is not preserved, but the relative ordering of the Cache-Control directives - as well as the fact that the first two were comma- separated, while the last was on a different line - is. Header fields containing multiple values MUST be concatenated into a single value unless the ordering of that header field is known to be not significant. The special case of "set-cookie" - which does not form a comma- separated list, but can have multiple values - does not depend on ordering.  The "set-cookie" header field MAY be encoded as multiple header field values, or as a single concatenated value. 8.1.2.4. </del> <ins> 8.1.2.5. </ins> The COOKIE can carry a significant amount of redundant data.

Related discussion:
text: Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).
Code change:
sessions, either within a single connection or on multiple connections can be used. <ins> Implementations that have a default priority SHOULD set it to a value in the middle of the range (eg: 128) to allow non-default priorities to be set either higher or lower. </ins> 5. Relays are leveraged to enable distribution scale in the MoQ

Related discussion:
text: The text we landed for to define priorities (URL) indicates that we should use a 8 bits ( where is ) to convey subscriber priority and similarly a byte to convey publisher priority. ( URL ) ( URL ) The text also indicates that lower values have higher priority which I read as meaning 1 () should be sent before 10 (), (After) is 133 (u8) Edit: We should probably recommend that implementations use a mid-range value like as a default to allow for prioritizing both above and below it. (The MoQT spec doesn't need to define a default since these values are currently always explicit on the wire, but I think it would be helpful to provide guidance here.)
I have a slight preference for treating these priorities as signed values because it makes a good default for implementations to choose. That way it's possible to go above or below the default. The same is possible with unsigned values, too, but if we go that direction we may want to provide some guidance to that effect (recommending something like or as a default mid-range value).
Oh, nevermind, NAME noticed some text I missed in section 4: "with 0 being the highest priority" which would imply these are unsigned int values, . It may still be helpful to make that more explicit and recommend a default mid-range value.
I'm fine with some editorial text here if that's how we want to resolve it? (PRs welcome NAME ) I'm also ok with it being signed, since it it nice for 0 to be a 'default' value, but we don't use signed integers anywhere else in MoQ, so I'm a bit concerned that using them in exactly one spot could be confusing or error prone?
In some cases, things would work better if we allocated some ranges of priorities to specific DSCP like "less than best effort" or "best effort". That would end up making the actually numbers here have absolute meaning too instead of just relative meaning.
Code change:
implementation requirements.  The "jti" method is mandatory and hence acts as a default fallback. <del> 8. 8.1. This section registers the value "client-assertion-type:jwt-client- attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation Common Name: OAuth 2.0 Attested Key-Based Client Authentication Change Controller: IESG Specification Document: TBC </del> <ins> 9. </ins> <del> 8.2. </del> <ins> 9.1. </ins> This section registers the value "attest_jwt_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by

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:
implementation requirements.  The "jti" method is mandatory and hence acts as a default fallback. <del> 8. 8.1. This section registers the value "client-assertion-type:jwt-client- attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation Common Name: OAuth 2.0 Attested Key-Based Client Authentication Change Controller: IESG Specification Document: TBC </del> <ins> 9. </ins> <del> 8.2. </del> <ins> 9.1. </ins> This section registers the value "attest_jwt_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by

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:
implementation requirements.  The "jti" method is mandatory and hence acts as a default fallback. <del> 8. 8.1. This section registers the value "client-assertion-type:jwt-client- attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation Common Name: OAuth 2.0 Attested Key-Based Client Authentication Change Controller: IESG Specification Document: TBC </del> <ins> 9. </ins> <del> 8.2. </del> <ins> 9.1. </ins> This section registers the value "attest_jwt_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by

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:
implementation requirements.  The "jti" method is mandatory and hence acts as a default fallback. <del> 8. 8.1. This section registers the value "client-assertion-type:jwt-client- attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation Common Name: OAuth 2.0 Attested Key-Based Client Authentication Change Controller: IESG Specification Document: TBC </del> <ins> 9. </ins> <del> 8.2. </del> <ins> 9.1. </ins> This section registers the value "attest_jwt_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by

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:
The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT: <del> If any step fails, the SD-JWT is not valid and processing MUST be aborted. </del> <ins> If any step fails, the SD-JWT is not valid, and processing MUST be aborted.  Otherwise, the JSON document resulting from the preceding processing and verification steps, herein referred to as the processed SD-JWT payload, can be made available to the application to be used for its intended purpose. </ins> It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them

Related discussion:
text: Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw.
Code change:
The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT: <del> If any step fails, the SD-JWT is not valid and processing MUST be aborted. </del> <ins> If any step fails, the SD-JWT is not valid, and processing MUST be aborted.  Otherwise, the JSON document resulting from the preceding processing and verification steps, herein referred to as the processed SD-JWT payload, can be made available to the application to be used for its intended purpose. </ins> It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them

Related discussion:
text: if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition
Code change:
Custom policies may use additional information present in the ledger outside of claims.  For instance, issuers may have to register on the TS before claims can be accepted; a custom policy may be used to <del> enforce access control to the transparency service.  Similarly, policies may be used </del> <ins> enforce access control to the transparency service.  Verifying the signature of the issuer is also a form of registration policy, but it is globally enforced in order to separate authentication and authorization, with policy only considering authentic inputs. </ins> tbl-initial-named-policies defines an initial set of named policies that TS may decide to enforce.  This may be evolved in future drafts.

Related discussion:
text: NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!
Code change:
more workloads.  The workloads within an Trust Domain may be invoked only through published interfaces.  A Trust Domain must have an identifier that is used as the "aud" (audience) value in <del> Txn-Tokens.  The format of this identifier is a universal resource identifier.  Each Trust Domain has exactly one Txn-Token Service. </del> <ins> Txn-Tokens.  The format of this identifier is as defined in the JWT specification RFC7519. </ins> A published interface to an Trust Domain that results in the invocation of a workload within the Trust Domain.

Related discussion:
text: In the Terminology section, the Trust Domain value is being defined and referenced in the aud claim as universal resource identifier. It should be spelled Universal Resource Identifier and a reference to RFC3986 should be added. However, later in the document, the aud claim value is specified as defined in RFC7519. This RFC defines the aud claim as "StringOrURI". The different passages should be aligned. Furthermore, the examples for the aud claim values should be aligned accordingly. In section Txn-Token Request the POST request example to the token service uses: If an URI is used, I suggest to use 'https' instead of 'http'. Later the JWT body example of the Txn-Token just uses a string:
Code change:
To evaluate a received If-None-Match header field: <del> An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond with either a) the </del> <ins> An origin server MUST NOT perform the requested method if a received If-None-Match condition evaluates to false; instead, the origin server MUST respond with either a) the </ins> status code if the request method is GET or HEAD or b) the

Related discussion:
text: They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Code change:
To evaluate a received If-None-Match header field: <del> An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond with either a) the </del> <ins> An origin server MUST NOT perform the requested method if a received If-None-Match condition evaluates to false; instead, the origin server MUST respond with either a) the </ins> status code if the request method is GET or HEAD or b) the

Related discussion:
text: Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)