jiebi/CodeConvo huggingface dataset:
Code change:
Name: CCF_LEDGER_SHA256 <del> Value: TBD_1 (requested assignment 2) </del> <ins> Value: 2 (requested assignment) </ins> <del> Description: Historical transaction ledgers produced by Trusted Execution Environments, such as the CCF ledger </del> <ins> Description: Append-only logs that are integrity-protected by a Merkle Tree and signatures produced via Trusted Execution Environments containing a mix of public and confidential information, as specified by the Confidential Consortium Framework. </ins> Reference: This document

Related discussion:
text: In alignment with draft-bryce-cose-merkle-mountain-range-proofs (i.e. this I-D will request VDS reg entry "2" and mmrp will request vds reg entry "3").
2 is a good number. Thanks for cleaning out the attic
Code change:
6.2.2.1. <del> The ROLE parameter (key 0x00) allows each endpoint to independently specify what functionality they support for the session.  It has three possible values, which are of type varint: Both endpoints MUST send a ROLE parameter with one of the three values specified above.  Both endpoints MUST close the session if the ROLE parameter is missing or is not one of the three above-specified values. 6.2.2.2. </del> The PATH parameter (key 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by the server, or when WebTransport is used.  If the peer receives a

Related discussion:
text: The role somewhat limited what actions were valid, but it's not clear that was important. Also, some things can be limited by MAXSUBSCRIBEID now.
I understand that a ClientSetup is sent that includes the role of if the client only wants to send objects, the role of if it only wants to receive objects, and the role of if it wants to both send and receive objects. And I believe that basically only the following relationships can be established: Client: vs Server: Client: vs Server: Client: vs Server: My questions are as follows: If a ClientSetup with or role parameters were to arrive at an ingestion-only server, how would the server handle it? Is it required that the server returns that the client does not expect and the client understands the server's intention? If a client that has already sent or receives a ServerSetup containing , is it acceptable to use that connection as is? There may be some security risks in this case. Thank you!
As a side note, if the conclusion in will be that Role Parameter is unnecessary or no consideration are required as endpoint behavior, then this issue would be unnecessary.
Not clear what the use case is. Seems like a foot gun in that it can be set wrong for how the connection is used.
I don't care if we leave it or keep it. Just adding this as I got questions about why have it.
Having the client voluntarily declare itself to abide by a certain role is not preventing the relay form having to do any work. A malicious client will declare one role but then act differently. Any relay open to the public has to protect itself against unauthorized ANNOUNCE and SUBSCRIBE control messages, irrespective of what role was declared. Therefore the upfront role declaration is superfluous.
I tend to agree it's not doing anything helpful here, and sent out to remove it.
Only suggestion to adjust other setup parameter keys now that you have removed 0x00. Given we don't have a strong need for this, glad to see it go for now and we can add back later if we find a strong need for it.
Code change:
sender's preferred digest-algorithm is the one (or ones) with the highest "qvalue". <del> Two examples of its use are </del> <ins> Two examples of its use are: </ins> 5. Digest-algorithm values are used to indicate a specific digest computation. <del> All digest-algorithm values are case-insensitive but the lower case is preferred. </del> <ins> All digest-algorithm values are case-insensitive but lower case is preferred. </ins> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed

Related discussion:
text: This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!
Code change:
A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order: <del> Any extension to HTTP/1.1 that defines additional conditional request </del> <ins> Any extension to HTTP that defines additional conditional request </ins> header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.

Related discussion:
text: header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice. This should just be "HTTP", no?
Code change:
Extra Parameters: <del> details: a sh-string containing the checksum or SPKI of the certificate received from the next hop. Recommended HTTP status code: 502 3.26. Name: tls_unexpected_peer_identity Description: The intermediary received peer certificate with unexpected identity (e.g., Subject Alternative Name doesn't match) during TLS handshake with the next hop. </del> <ins> identity: a sh-string containing a comma-separated list of Subject Alternative Names from the certificate received from the next hop. </ins> <del> Extra Parameters: </del> <ins> sha256: a sh-string containing the hex-encoded SHA-256 of the certificate received from the next hop. </ins> <del> details: a sh-string containing the identity of the next hop. </del> <ins> spki: a sh-string containing the base64-encoded SHA-256 of the Subject Public Key Info (SPKI) from the certificate received from the next hop. </ins> Recommended HTTP status code: 502 <del> 3.27. </del> <ins> 3.26. </ins> Name: tls_missing_proxy_certificate

Related discussion:
text: Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
Code change:
The signer creates an ordered list of content identifiers representing the message content and signature metadata to be covered by the signature, and assigns this list as the signature's <del> Covered Content.  Each identifier MUST be one of those defined in Section 2.  This list MUST NOT be empty, as this would result in creating a signature over the empty string.  If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include (created) and (request-target) in the list.  If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include date and (request-target) in the list.  Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list order is significant and once established for a given signature it MUST be preserved for that signature. </del> <ins> Covered Content. Each identifier MUST be one of those defined in Section 2. This list MUST NOT be empty, as this would result in creating a signature over the empty string. If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include (created) and (request- target) in the list. If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include date and (request-target) in the list. Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list order is significant and once established for a given signature it MUST be preserved for that signature. </ins> For example, given the following HTTP message:

Related discussion:
text: Strengthened requirement for content identifiers for header fields to be lower-case (changed from SHOULD to MUST). Relaxed guidance on processing Creation Time and Expiration Time to only require verifiers to examine them and test against the verifier’s requirements. Minor editorial corrections and readability improvements.
The current text allows mixed-case header field names when they are being used as content identifiers. This is unnecessary – header field names are case-insensitive – and creates opportunity for incompatibility. Instead, content identifiers should always be lowercase.
The processing instructions for Creation Time and Expiration Time imply that verifiers are not permitted to account for clock skew during signature verification.
This can safely be fixed adding a -like claim, so that the signer remains in control of the signature validity. This is especially important if the signature is created with the signer's private key. imho this kind of document should not define a clock-skew tolerance threshold, and implementors shoud be suggested to fix their clocks. There may be corner cases (eg. IoT/disconnected devices ) that we should address properly
I'd split the clock-skew part in a separate PR. The rest LGTM.
Code change:
The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters <del> applicable to the proxy for this target URI (target.resource).  A proxy MUST send at least one Proxy-Authenticate header field in each </del> <ins> applicable to the proxy for this request.  A proxy MUST send at least one Proxy-Authenticate header field in each </ins> response that it generates.

Related discussion:
text: P-A is as: This seems really odd -- P-A is not generally used in a way that's specific to a single target URI.
I think it's scoped to the request; i.e., if the client retries the same request with appropriate credentials, it's likely to succeed; we can't say much more than that.
FTR, the text we have is inherited from .
Code change:
8.1. <del> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that </del> <ins> Upon receiving an SD-JWT, a Holder or a Verifier needs to ensure that </ins> The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT:

Related discussion:
text: which can be found at
I think the following change might be cleaner per in Jefferey's review. "9. Check that the Key Binding JWT is valid in all other respects, per [NAME and [NAME -> "9. Check that the Key Binding JWT is a valid JWT in all other respects, per [NAME and [NAME
Sure, that's done in 4442c3a06767498ee24154024d8dff987325b08f
While reviewing URL, I had to understand some of the SD-JWT verification algorithms. I noticed some issues, which I've listed here. I haven't filed individual issues yet because I'm not sure how you'll want to group them. Thanks to NAME for doing a first pass; any remaining mistakes are probably because I didn't take his advice. [x] This should follow URL by specifying "what serialization and serialization features are used". I see that 1.1. Feature Summary mentions the compact serialization, but that doesn't clearly say that this embedded JWT uses it.[x] "The claim name, or key, as it would be used in a regular JWT payload. The value MUST be a string." <- I assume the "value" is the key, and not the key's value in the JSON object? [x] Why is 128 bits only recommended and not required for the salt?[x] This should follow URL by specifying "what serialization and serialization features are used". I see that 1.1. Feature Summary mentions the compact serialization, but that doesn't clearly say that this embedded JWT uses it.[x] This mentions "bytes preceding the KB-JWT in the Presentation", but several other places mention "Key Binding is provided by means not defined in this specification", in which case the relevant bytes don't precede the KB-JWT. These should be consistent.[x] Are "Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that" and "The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT" accomplishing the same thing? [x] "Separate the SD-JWT" should cite an algorithm for doing that. I think it's "5. SD-JWT Data Formats" which implies it's just "split on '~'"?
Code change:
8.1. <del> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that </del> <ins> Upon receiving an SD-JWT, a Holder or a Verifier needs to ensure that </ins> The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT:

Related discussion:
text: [x] "Ensure that a signing algorithm was used that was deemed secure" disclosure and then call a recursive element-processing-and-replacing function, but this isn't too bad. [x] "Remove all array elements for which the digest was not found" probably won't confuse anyone for long, but my first reading said that an array in the payload like [1, 2, 3] would wind up empty since no digests were found for the elements. [x] "Check that the SD-JWT is valid using claims such as nbf, iat, and exp" should say where those claims are defined and what part of which object they appear on. (URL, and the top level of the payload, not the header, right?) [x] The "required validity-controlling claim"s should probably be an input parameter to this algorithm. Possibly all the IANA-registered JWT claim handling should be passed in, or this algorithm should return all the claims for the caller to deal with.[x] "create a Key Binding JWT" <- refer to the section that says how to do this. [x] "Assemble the SD-JWT for Presentation" <- This should at least refer to "5. SD-JWT Data Formats" and possibly just write out the algorithm of "make an array of the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT, and join the array with '~'."[x] This is clearer that "Verifiers MUST ensure that" is accomplished by the steps in the following algorithm, but I don't like the redundant MUST. You can just say "Verifiers need to ensure that" and then leave the normative requirements to the algorithm. [x] "according to the Verifier's policy" should be an input parameter to this algorithm, that the verifier provides along with the bytes of the presentation. [x] "verify the Key Binding according to the method used" <- how? This might be URL, but you should cite the details. [x] "Determine the public key for the Holder" <- how? This might be the 'cnf' claim, but you should say so. [x] "Ensure that a signing algorithm was used that was deemed secure" <- as above, this should be an input parameter to this algorithm or computed from the public key.
Code change:
8.1. <del> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that </del> <ins> Upon receiving an SD-JWT, a Holder or a Verifier needs to ensure that </ins> The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT:

Related discussion:
text: [x] "Validate the signature" <- again, cite how to do this. [x] "the typ of the Key Binding JWT" <- is that in the header or payload? (cite 5.3. Key Binding JWT and possibly URL) [x] "within an acceptable window." <- should be an input parameter [x] "validating nonce and aud claims" <- The instructions for doing this should be an input parameter to this algorithm. [x] "Check that the Key Binding JWT is valid in all other respects" should call a particular algorithm from the other specs that it cites.[x] Many of these should be normative. For example, base64url is used all over the normative parts of this specification, and it comes from [RFC7515] in this section.
Thanks for the review Jeffrey! I'm acknowledging it with this comment but also noting that there's a lot here so response/action will take some time.
1c1f165ab821dea5350f62225f103bdceff31532 one was an oversight and one was a tooling issue and oversight. I think that covers them tho.
Those other specs don't have algorithms that can be called nor do they have suitable sections to reference directly.
Some contributors want to leave open the option of a more computationally expensive hash with smaller salt values.
Yes and I've tried to remove any ambiguity there by just not using the word "value" with d015a3de2ae50623b4a294590fb2d0249e7d33b5
Per , "JWTs are always represented using the JWS Compact Serialization" the compact serialization is already specified.
That is for the claim in Key Binding JWT so isn't relevant elsewhere.
& Yeah, with 2a0e270f2e1dbfa9664bb5ce4989a2f6a1765217 I basically applied your suggestion to both places.
Yup 7d68d4ed9b91e49a0aa00254475bf7c116669dd6
Yes but I believe it's sufficiently clear in the context of the draft.
This draft is not structured such that it has input parameters to algorithms so suggestions to make something an input parameter to an algorithm are not actionable or practical.
Code change:
8.1. <del> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that </del> <ins> Upon receiving an SD-JWT, a Holder or a Verifier needs to ensure that </ins> The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT:

Related discussion:
text: e9acd5ed665b107776b6b41355680470cde89f2c
is a JOSE header. Will cite sec 5.3. where that's more explicit 64a4c4519668c7a63f1a0be215176657895fa0c8
That sentence starts with "If Key Binding is provided by means not defined in this specification," so there are not specific details to cite. mentions that other ways of proving Key Binding are possible. DPoP/rfc9449 is one possibility but not the only one. Nor a particularly likely one. At least not likely enough to warrant mention here.
The very next part of that sentence says "in the processed payload" and that's a non-exhaustive list of JWT claims for which a citation/reference isn't really needed.
I feel like it's sufficiently clear from context and shouldn't confuse anyone for too long.
Noted.
This draft intentionally doesn't prescribe how keys are distributed, identified, selected, trusted, etc. any more than JWT/JWS do (e.g. URL, URL, etc). A map from (issuer ID, key ID) pairs to public keys is one application but certainly not the only one.
referencing that 072a0605bcb62937e343aaa7812aa8ef86d8379f
That's a somewhat existential and loaded question but common usage of the word doesn't preclude it describing nested items and array elements. And this draft is not alone in that. In the intro it also says, '"Claims" here refers to both object properties (name-value pairs) as well as array elements.'

"create a Key Binding JWT" <- refer to the section that says how to do this. cbee5f8457f447574400377dc6f7c9fe7f1c3c18
a474e2b0b0ff7635af38c2ac95e70b40b2f82798 makes things a little more a bit more prescriptive about suggesting RFC7800 cnf/jwk be used to convey the Key Binding key and references that section from the "Verification by the Verifier" section.
Thank you so much, Brian! overall, agree with all the responses.
Code change:
8.1. <del> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that </del> <ins> Upon receiving an SD-JWT, a Holder or a Verifier needs to ensure that </ins> The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT:

Related discussion:
text: I made few comments on the PR, but one thing to note here too: I think recommending claim per comment is inconsistent with a comment that says that "this draft intentionally doesn't prescribe how keys are distributed, identified, selected, trusted, etc. any more than JWT/JWS do. so I think recommending is redundant and using in examples is sufficient.
That latter comment was about (and in reply to a suggestion about) validating the signature on the Issuer-signed JWT and checking that the signing key belongs to this Issuer. While the former comment is about the holder's public key inside the Issuer-signed JWT itself. Different things so I don't believe there's really an inconsistency in my statements. Nor do I think that being a little more a bit more prescriptive and more clear about using RFC7800 cnf/jwk to convey the Key Binding key is redundant. Rather this review of a review seemed like a good opportunity to provide a little more clarity and guidance in an area the draft that could benefit from such.
one nit, otherwise looks good - thank you, Brian!
Code change:
8. <del> HTTP/2 defines a framing of the HTTP message abstraction (HTTP). </del> 8.1. <ins> HTTP/2 defines a framing of the HTTP message abstraction (HTTP). </ins> A client sends an HTTP request on a new stream, using a previously unused StreamIdentifiers.  A server sends an HTTP response on the same stream as the request.

Related discussion:
text: This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.
Code change:
connections becoming unusable due to limits on the number of messages the underlying cipher suite can encipher. <del> A client MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any </del> <ins> An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any </ins> renegotiation MUST occur prior to sending the connection preface.  A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection.

Related discussion:
text: Two changes here, one editorial and one probably-editorial: The endpoint might send a connection or a stream error of HTTP11_REQUIRED, depending on the scope of the requirement. Note that this was non-normative language, so removing the implication that it would always be a connection error simply makes clearer what was already permitted. The server might know as soon as the connection is established that it will want the cert, but want it protected by the handshake. Either endpoint, not just the client, may choose to renegotiate before sending their preface.