jiebi/CodeConvo huggingface dataset:
Code change:
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The request content MAY be empty.  If the "Upload-Complete" field is then set to true, the client wants to complete the upload without appending additional data. The following example shows an upload append.  The client transfers the next 100 bytes at an offset of 100 and does not indicate that the upload is then completed.  The server acknowledges the new offset: </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD

Related discussion:
text: This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?
Code change:
2.1. <del> The ORIGIN frame type is 0xb (decimal 11). </del> <ins> The ORIGIN frame type is 0xc (decimal 12). </ins> The ORIGIN frame's payload contains the following fields, sets of which may be repeated within the frame to indicate multiple origins:

Related discussion:
text: While testing firefox's implementation of this draft Vlad determined that some versions of Chrome throw PROTOCOL_ERROR and close the connection if it receives a type 0xB frame with a non zero length on stream 0. Other frame type numbers, such as 0xC do not seem to have that problem. testing indicates this is fixed in version 59 and is a problem previous to that. (57 is in release as I write this). presumably this is related to historical code around BLOCKED which was proposed to use 0xB. Prudence says to just use a different code point for the moment.
Question for NAME and NAME should we somehow reserve 0xb to avoid this problem?
If this is fixed in Chrome 59, why bother? Actually, I'd also revert this change.
Neither. There are still old Chrome versions deployed (some people lag, for various reasons), so it's not safe to use now, but it should be in the not-to-distant future; we just need to wait a while to use it (presumably for another extension). Reserving it for all time would be a bad precedent.
Code change:
set to the resumption offset. If the end of the request body is not the end of the upload, the <del> "Upload-Incomplete" header field (upload-incomplete) MUST be set to true. </del> <ins> "Upload-Complete" header field (upload-complete) MUST be set to false. </ins> The server SHOULD respect representation metadata received in the Upload Creation Procedure (upload-creation) and ignore any

Related discussion:
text: Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it."
Code change:
set to the resumption offset. If the end of the request body is not the end of the upload, the <del> "Upload-Incomplete" header field (upload-incomplete) MUST be set to true. </del> <ins> "Upload-Complete" header field (upload-complete) MUST be set to false. </ins> The server SHOULD respect representation metadata received in the Upload Creation Procedure (upload-creation) and ignore any

Related discussion:
text: The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> Frame diagrams in this document use the format defined in QUIC- </del> <ins> The frame diagram in this document uses the format defined in QUIC- </ins> TRANSPORT to illustrate the order and size of fields. 2. <del> The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of the Origin Set (ORIGIN) for the connection within which it occurs. </del> <ins> The ORIGIN HTTP/3 frame allows a server to indicate what origin or origins RFC6454 the server would like the client to consider as one or more members of the Origin Set (ORIGIN) for the connection within which it occurs. </ins> The semantics of the frame payload are identical to those of the <del> HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for </del> <ins> HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves stream 0 for </ins> frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. <del> Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. </del> <ins> Where ORIGIN indicates that the ORIGIN frame is sent on stream 0, this should be interpreted to mean the HTTP/3 control stream: that is, the ORIGIN frame is sent from servers to clients on the server's control stream. </ins> HTTP/3 does not define a Flags field in the generic frame layout.  As no flags have been defined for the ORIGIN frame, this specification

Related discussion:
text: This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.
Code change:
protocol within a protocol element that requires sending a minor version. <del> 5.2. Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. </del> 5.3. HTTP messages use key/value pairs to convey data about the message,

Related discussion:
text: I think this should be something like "Message Framing and Incomplete Messages", and should be after the headers / payload / trailers sections.
Code change:
A "Digest" header field using NOT RECOMMENDED digest-algorithms SHOULD NOT be used in signatures. <del> 8.5. </del> <ins> 8.6. </ins> ... <del> 8.6. </del> <ins> 8.7. </ins> ...

Related discussion:
text: Obsolete ADLER-32 but don't forbid it.
NAME will this work for you?
I think the pull request is OK as-is, but might be improved slightly. In particularly, I'm wondering if SHOULD NOT is too strong for the server. A server could support ADLER32 without that support impacting on cryptographic data integrity provided that server also supports a cryptographically secure hash; e.g., SHA-512. Clients that wish to protect against malicious actor changes would use the SHA-512 hash and not request (or ignore) the ADLER32 value. Therefore, I would suggest that, for the server, the document says a server MAY implement ADLER32. I think it is perfectly reasonable for the document to say the client SHOULD NOT use ADLER32, for the reasons stated. That said, I can't decide if this distinction is really helpful, so I defer to your judgement, here.
I'm not so sure we want to make a distinction between client and server as you write it. Both client and server can attach Digest header to request or response. It is the receiver of Digest that is exposed to the risk of using a weak digest. The current language avoids mentioning either endpoint so we leave it to implementers. I'm not opposed to spelling things out more clearly but we'd really need to nail down what we mean by "using Digest algorithms" because that relates to requesting them, generating them, regenerating them (proxy), validating them (endpoint or proxy) etc.
That's a good point about client/server. Sorry, I had that wrong. As you say, it's the recipient of a Digest that must decide whether the algorithm is sufficient. This recipient may be either the client or the server. I think the document is right to point out the dangers of accepting a weak digest. Perhaps there is a useful distinction between generating a digest and accepting a digest; e.g., an agent MAY support generating a weak digest but SHOULD NOT accept a weak digest.
Not wrong, just partially true. That could work for me. I'll leave it to NAME to decide what he things makes sense to do.
NAME NAME as this issue is for ADLER, I moved the discussion to As it's in the listed algorithms, the server MAY already implement ADLER32, though it SHOULD NOT be used by both sides of the communication. I think sender and receiver should behave consistently (see again).
Merging as for the positive feedback from NAME and NAME comment URL
Code change:
10.6. <del> HTTP/2 enables greater use of compression for both header fields (HeaderBlock) and entity bodies.  Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. </del> <ins> Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/2 enables compression of header fields (HeaderBlock); the following concerns also apply to the use of HTTP compressed content- codings (RFC7231). </ins> There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., BREACH).  The attacker induces

Related discussion:
text: The latter part is vestigal, from the time when gzip C-E was mandated. Remove it. Here, I'm less concerned.
Code change:
The resource server responds with the protected resource metadata according to PRConfigurationResponse. <del> The client validates the protected resource metadata. </del> <ins> The client validates the protected resource metadata, as described in PRConfigurationValidation. </ins> The client builds the authorization server metadata URL from an issuer identifier in the resource metadata according to RFC8414

Related discussion:
text: cc NAME
[ ] Step 5, add reference to how to validate: "...according to the validation steps described in Section 2.1 (validation of signed resource metadata if it applies) and Section 3.3" [ ] Step 5.2: rephrase to "If the client receives such a WWW-Authenticate response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained."
Looks good to me.
Code change:
3. <ins> Client Attestation JWT A JSON Web Token (JWT) generated by the client backend that authenticates the client instance. Client Attestation Proof of Possession (PoP) A Proof of Possession generated by the client instance for the key that is used in the Client Attestation JWT. Client Instance Key A cryptographic, asymmetric key generated by the client instance and proven to the client backend.  The public key is contained in the Client Attestation JWT and is used to sign the Client Attestation Proof of Possession 4. </ins> To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. The value of the "client_assertion_type" is <del> "urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation". </del> <ins> "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation". </ins> The value of the "client_assertion" parameter contains two JWTs, separated by a '~' character.  It MUST NOT contain more or less than <del> precisely two JWTs seperated by the '~` character.  The first JWT MUST be the client key attestation JWT defined in client-key- attestation-jwt, the second JWT MUST the client key attestation PoP defined in client-key-attestation-pop-jwt. </del> <ins> precisely two JWTs seperated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST the client attestation PoP defined in client- attestation-pop-jwt. </ins> The following example demonstrates client authentication using this scheme during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only): <del> 3.1. </del> <ins> 4.1. </ins> In order to authenticate the client using this scheme, the authorization server MUST validate BOTH the JWTs present in the "client_assertion" parameter according to the criteria below. It is RECOMMENDED that the authorization server validate the Client <del> Key Attestation prior to validating the Client Key Attestation PoP. </del> <ins> Attestation JWT prior to validating the Client Attestation PoP. </ins> <del> 3.1.1. </del> <ins> 4.1.1. </ins> <del> The following rules apply to validating the client key attestation JWT.  Application of additional restrictions and policy are at the </del> <ins> The following rules apply to validating the client attestation JWT. Application of additional restrictions and policy are at the </ins> discretion of the authorization server. The JWT MUST contain an "iss" (issuer) claim that contains a

Related discussion:
text: Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.
Code change:
The handshake methods described in starting are believed sufficient to negotiate the use of alternative protocols. <del> 8.1.2.1. </del> <ins> 8.1.2.3. </ins> HTTP/2 defines a number of pseudo header fields starting with a colon ':' character that carry information about the request target:

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:
3. <ins> In order to include the "next-hop-aliases" parameter, a proxy needs to have access to the chain of alias names and canonical names received in CNAME records. Implementations ought to note that the full chain of names might not available in common DNS resolution APIs, such as "getaddrinfo". "getaddrinfo" does have an option for "AI_CANONNAME", but this will only return the last name in the chain (the canonical name), not the alias names. An implementation MAY include incomplete information in the "next- hop-aliases" parameter to accommodate cases where it is unable to include the full chain, such as only including the canonical name if the implementation can only use "getaddrinfo" as described above. 4. </ins> The "next-hop-aliases" parameter does not include any DNSSEC information or imply that DNSSEC was used.  The information included in the parameter can only be trusted to be valid insofar as the

Related discussion:
text: I think the alias draft should probably have a (non-normative) reference to , in particular noting that: can be populated from the output of . can be used to emulate or substitute for .
I think the flag to only gives you the "canonical name" which is the final CNAME target at the end of the CNAME chain. If you want the full set of interior names across a chain of multiple CNAME records I don't believe you can retrieve that with .
Yeah, I'm hesitant to add references to system APIs like , and particularly for the reason given above. NAME what do you think?
I think AI_CANONNAME is important historical context here. You can't understand where the draft is coming from without it. I also think that this extension will often be implemented by wrapping getaddrinfo, and some guidance about whether that is compliant would be appropriate. I think Robert's comment raises a good example of why this is not trivial, and hence is worth mentioning.
I'm not sure is really required to understand the context of the draft. We don't use it at all on iOS/macOS implementations for current CNAME cloaking detection. I do see that it may be good to warn that it is not sufficient to just wrap up .
Thanks LGTM
Code change:
4.2. <del> TBD </del> <ins> This section defines the "StatusList" structure for a CBOR-encoded Status List. The "StatusList" structure is a map (Major Type 5) and defines the following entries: * "bits": REQUIRED.  Unsigned int (Major Type 0) that contains the number of bits in the per Referenced Token in the Status List.  The allowed values for "bits" are 1, 2, 4 and 8.  * "lst": REQUIRED.  Byte string (Major Type 2) that contains the Status List as specified in status-list-json. The following example illustrates the CBOR representation of the Status List: The following is the CBOR diagnostic output of the example above: </ins> 5.

Related discussion:
text: This PR adds: CBOR/CWT encoding for status list and status list info Example implementation for CBOR/CWT Not included yet: examples for referenced tokens (COSE, CWT) but that should be trivial to add. URL
The decoded cbor is: The list does not seem to be valid zlib.
I've tried with cyberchef and it seems to work for me: -> zlib inflate =
You are right, I probably tried on the hexstring :D
I assume there will be a lot of comments. I had some troubles with the claim language for non-CWTs btw. Please review and give feedback. NAME NAME NAME
I was wondering whether it would be better to define a CDDL for Status, StatusList and StatusListInfo. Basically, having a high-level CDDl description of all objects and then having some specific sections for JWT, COSE, CWT that define how they are used in the corresponding objects.
Also keep in mind that claim for CWT will require IANA to assign us an integer number, so we can use it in the CWT.
There is a problem with the width of the CBOR diagnostic notation examples. The datatracker only allows a width of 72, but cborg defaults to 100 and apparently can't be configured in CLI mode.
I can write a small JS script that uses the cborg library and configures the width to 72. Would this be even possible? I didn't check by myself.
Yes that would be possible and is the only option I have found so far. I was searching for a pure python solution (which would be cleaner imho) but that seems to be not possible right now.
The abstract, intro, diagrams wrt referenced tokens description should refer to COSE and JOSE instead of CWT/JWT. Otherwise, non-CWT COSE objects such as ISO 18013-5 MSO cannot use this spec. Same applies to SD-JWT VC encoded secured using JWS.
We adjusted the terminology already, but the text in the introduction is not matching yet.