jiebi/CodeConvo huggingface dataset:
Code change:
The Issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places <del> in the structure of the SD-JWT.  This can be seen in Example 3 in the Appendix, where multiple claims with the name </del> <ins> in the structure of the SD-JWT.  This can be seen in the example in example-complex-structured-sd-jwt, where multiple claims with the name </ins> appear, but each of them has a different salt.

Related discussion:
text: for issue URL
The layout of these section delineations seems off. There's an "Example 1" section header, but no other numbers. Some examples are top-level, some are subordinate. Is this intended?
Kinda. has additional examples with some of those other numbers. ! And a few places refer back to "Example 1" by name. This all could probably be tidied up though.
like it
Code change:
The client MAY cancel the upload (upload-cancellation) after rejecting the offset. <ins> The following example shows an offset retrieval request.  The server indicates the new offset and that the upload is not complete yet: </ins> The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received.

Related discussion:
text: This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!
Code change:
The client MAY cancel the upload (upload-cancellation) after rejecting the offset. <ins> The following example shows an offset retrieval request.  The server indicates the new offset and that the upload is not complete yet: </ins> The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received.

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:
workload specific identity with a generalized one for a given administrative domain. <del> 3.8.2. </del> <ins> 3.10.2. </ins> Inbound security gateway is a common design pattern for service protection.  This functionality is often found in CDN services, API

Related discussion:
text: added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.
Code change:
autonomous configuration. A prefix is not considered a usable on-link prefix if it is <del> advertised on the link as on-link, but the 'm' bit is set in the Router Advertisement message header (RFC4861) that contains the Prefix option.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "usable"&#151;not all hosts can actually use it. </del> <ins> advertised on the link as on-link, but the 'a' bit is not set in the Prefix Information option header (RFC4861) that contains the Prefix option.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "usable"&#151;not all hosts can actually use it. </ins> A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is

Related discussion:
text: see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.
Code change:
different single value: Both of these versions are treated differently by the application. <del> however, if included in the signature base without parameters, the </del> <ins> However, if included in the signature base without parameters, the </ins> component value would be the same in both cases: However, if the "bs" parameter is added, the two separate instances

Related discussion:
text: Addresses encodings of signature component values for query parameters and field values.
: This seems to be inconsistent with Section 2.2.8 ("Query Parameters"), which could create non-ASCII component values.
FWIW, a query parameter (after application of URL) could contain CR, LF and other control characters.
So we likely need to serialize information extracted from query parameters using some kind of encoding; maybe an SF Byte Sequence.
This is tricky -- originally the query parameters were kept in percent-encoded form but from WG discussion we changed that to just use the unencoded value instead since several percent-encoded forms could be used. However it does look like the unencoded form could end up with problematic values here, so maybe we need to go back to that. I'd rather us use an encoding native to the value rather than inventing something to put on top of it, even trying to re-use the flag we've already got defined for headers.
And we did that because to extract query parameter values, we need a query parser, and that is defined the way it is. I believe that decision was good, we now just need to figure out out to transform the extracted values so that they can be used in the signature base. (And, FWIW, at the end we also should have an example for a case like that in the spec).
In 2.2.8, it might be good to mention that the referenced algorithm only supports query parameters using (percent-escaped) UTF-8 encoding (this came as a surprise to me because I assumed it works the same as the algorithm used for forms decoding).
in 2.1.3: What if the field value contains non-ASCII characters (from obs-text)? Of course that could be considered an error, but I believe the intention is to be able to represent anything here. So the text should refer to the field value as byte sequence, in which case the encoding step would not be needed.
This text was added in response to a comment about needing to know which encoding to put into the byte sequence input, and the commenter suggested ASCII as the base for it. If field values have a well-defined byte sequence that isn't ASCII characters only, then we should refer to whatever that is from the HTTP docs.
Well, field values in HTTP can be anything. It's obsolete, it's deprecated, but that's what it is.
Code change:
different single value: Both of these versions are treated differently by the application. <del> however, if included in the signature base without parameters, the </del> <ins> However, if included in the signature base without parameters, the </ins> component value would be the same in both cases: However, if the "bs" parameter is added, the two separate instances

Related discussion:
text: So we need to deal with it one way or another. I could live with UTF-8, and a note that if the octet sequence does not decode as UTF-8, you can't sign it.
NAME - yes, you can merge and close issues as you wish, you are the editor. But by all means do not submit a new draft until the changes have been reviewed by those who opened the issue. (cc chairs NAME NAME )
As far as I can tell, the changes require percent-encoding only for non-ASCII values. That is, the character U+0080 would get the same encoding as a verbatim "%80" in a field value. I believe this is a problem.
This issue has been addressed. There is no percent encoding needed in this section since the value is taken directly from the bytes of the field in a binary-wrapped representation, and the bytes are encoded using the base64 serialization of a Byte Sequence from Structured Fields:
I'm talking about the simple case, not the one where Byte Sequence encoding is used (yes, the issue title doesn't match anymore).
Ok, opened new issue URL
Code change:
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority <del> Field Value MUST be treated as a connection error.  In HTTP/2 the </del> <ins> Field Value MAY be treated as a connection error.  In HTTP/2 the </ins> error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type <del> H3_FRAME_ERROR. </del> <ins> H3_GENERAL_PROTOCOL_ERROR. </ins> A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open (except for HTTP/2 push streams; see h2-update-

Related discussion:
text: This lets servers be more permissive if they want to treat it like the Header but allows them to be strict if they want. Since this is not an error in the frame itself, change the code to a general error; reason phrase is available if people feel it important to share.
In . NAME highlighted our treatment of structured fields parsing failures for the Priority header was a bit naff. We should just defer to structured fields, and that's what PR does. It struck me that our requirement for similar failures while processing PRIORITYUPDATE frames seems a bit overzealous in light of . From URL We introduced the current text as part of addressing . I think perhaps I misread the comment at URL There's a difference between a badly formed HTTP/2 or HTTP/3 frame (imagine one that is shorter than it claims to be, that's already described by those documents), and a frame that contains contents some other specification deems invalid. It now seems to me like it would be ok to defer to structured fields rules here. This would manifest as the receiver having processed the frame, but ignoring the value altogether (and treating it like an omission, which we explain how to deal with elsewhere). Thoughts?
While I do not have a strong opinion, I'm not sure if we need to revisit our previous decision. FWIW, IIUC, this is choosing between two principles: Frames are hop-by-hop signal, therefore the connection should be closed when receiving a malformed signal. Syntax of the value of the PRIORITY_UPDATE frame is the same as that of the header field and therefore malformed values should be ignored.
In the quiche library H3 layer, we handle all of the frame handling recommendations inside the library. When we process received HEADERS frames, we enure frame and QPACK requirements are satisfied and that we can construct a field section but defer all processing of the field section to applications. We don't process PRIORITY_UPDATE frames yet but if we did, we would likely pass the Structured Field Dictionary up to the application to deal with. With the current text we would either need to embed structured fields parsing into the h3 library code, or make the application responsible for adhering to the requirements. Both of hose deviate from our general implementation design (that's not an excuse, we'll have to do what the WG consensus tells us to do).
Code change:
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority <del> Field Value MUST be treated as a connection error.  In HTTP/2 the </del> <ins> Field Value MAY be treated as a connection error.  In HTTP/2 the </ins> error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type <del> H3_FRAME_ERROR. </del> <ins> H3_GENERAL_PROTOCOL_ERROR. </ins> A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open (except for HTTP/2 push streams; see h2-update-

Related discussion:
text: My thinking is that the contents of a frame's Priority Field Value is not a property of an HTTP/2 or HTTP/3 connection. If the Dictionary cannot be parsed, it does not indicate a problem with the connection. It indicates a malformed Dictionary and there are procedures defined on how to handle that in Structured Fields. Since we allow for omission of parameters in this frame, it doesn't seem that different for receivers to parse a Dictionary, fail it and treat it like omission.
Thank you for elaborating. Reading your argument, I'd be supportive to relaxing the current requirement (MUST). Maybe changing MUST to MAY or SHOULD would be the most desirable outcome, as I believe there's no reason to prohibit endpoints from employing a validity check against hop-by-hop signals.
I see you point, thanks. I think this is a case for , I can make a PR for that. I don't think that is the correct code though. URL says: requirements or with an invalid size was received. And IIUC what you want is to communicate that a problem occured at a different layer of abstraction. I think is ok unless you think we need to define a new error code just for this.
From purely editorial perspective, I'm not sure if we need to say "if it can detect" when the keyword is "MAY." I think the choice here might be between SHOULD/MAY or MUST-if-detected. Regarding the choice of the error code, I think my mental model was that the use Structured Field is a layout requirement. But I agree that it's border line, I'm perfectly fine with using H3GENEALPROTOCOL_ERROR. We do not need a new error code for this - HTTP/3 stacks can always use the Reason Phrase field to communicate fine-grained information.
Code change:
Trailer section.  This contains zero or more trailer fields. <ins> Optional padding.  Any amount of zero-valued bytes. </ins> All lengths and numeric values are encoded using the variable-length integer encoding from QUIC.

Related discussion:
text: This adds the ability to pad messages to the binary HTTP format. The design is pretty simple: add zero-valued bytes to the end.
What if someone adds a non-zero byte in the padding block?
Code change:
only via the initialization track field of the track which they initialize. <del> 3.2.16. </del> <ins> 3.2.17. </ins> An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription.  If present, the selection

Related discussion:
text: by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.
Code change:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del> <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.

Related discussion:
text: There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.
Code change:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del> <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.
Code change:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del> <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.

Related discussion:
text: It occurs to me that if we specify to always be used in conjunction with , and that its semantics are that caches that understand the semantics of the status code can ignore the , all current implementations should already be conferment (if not optimal). Currently, I'm not aware of any cache that implements (because it's new).
Code change:
3.5. The application will be able to retrieve topology layer and any <del> network/node/tp/link instances from the controller via Digital Map API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. </del> <ins> network/node/tp/link instances from the controller via the SIMAP API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. </ins> 3.6. The application will be able to retieve the topology at any layer <del> from the controller via Digital Map API and from the response it will </del> <ins> from the controller via the SIMAP API and from the response it will </ins> be able to navigate any retrieve any KPIs for selected topology entity.

Related discussion:
text: Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters
Code change:
signature on the SD-JWT cannot be verified, the SD-JWT MUST be rejected. <del> 7.2. </del> <ins> 7.3. </ins> The security model relies on the fact that the salt is not learned or guessed by the attacker.  It is vitally important to adhere to this

Related discussion:
text: Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.
Code change:
[4] #Example B1: Illicit access to a video streaming service (User Transferred Pattern) <del> [5] #Example B4: Illicit Transaction Authorization (Client Transferred Pattern) </del> <ins> [5] #Example B4: Illicit Transaction Authorization (Backchannel Transferred Session Pattern) </ins> [6] #Example B5: Illicit Network Join (User Transferred Authorization Data Pattern)

Related discussion:
text: Changes made in response to issue
User Transfer Pattern -> User Transferred Session Data Pattern Client Transfer Pattern -> Backchannel Transferred Session Patterns Hybrid Pattern -> User Transferred Authorization Data Pattern
Attack naming conventions updated as reflected in merge 0988577895daf3878e3d3de59add470c35c4cc4a
Code change:
3.3. The nonce input to AEAD_AES_128_GCM is constructed for each record. <del> The nonce for each record is a 12 octet (96 bit) value is produced from the record sequence number and a value derived from the input keying material. </del> <ins> The nonce for each record is a 12 octet (96 bit) value that is produced from the record sequence number and a value derived from the input keying material. </ins> The input keying material and salt values are input to HKDF with different info and length parameters. The length (L) parameter is 12 octets.  The info parameter for the nonce is the ASCII-encoded string "Content-Encoding: nonce", a single <del> zero octet and an context: </del> <ins> zero octet and a context: </ins> The context for nonce derivation is the same as is used for content encryption key derivation.

Related discussion:
text: This moves the values that were in the Encryption header field to the start of the payload. This provides a meagre efficiency gain as well as removing the need to have two correlated header fields. This should go most of the way to address WGLC comments.
Looks good to me in general. That said; this removes the parsing weirdness for "Encryption" (good), but not for "Crypto-Key", right?
NAME happy to correct any parsing weirdness, but need to know precisely what it is first.