jiebi/CodeConvo huggingface dataset:
Code change:
9. <del> This section outlines attributes of the HTTP protocol that improve </del> <ins> This section outlines attributes of HTTP that improve </ins> interoperability, reduce exposure to known security vulnerabilities, or reduce the potential for implementation variation.

Related discussion:
text: Not "of the HTTP protocol".
and 9: To avoid the appearance of "of the Hypertext Transfer Protocol protocol", should these two instances of "of the HTTP protocol" be "of HTTP" (or perhaps, in the case of , "HTTP attributes" instead of "attributes of the HTTP protocol")? Original: The frame and stream layers are tailored to the needs of the HTTP protocol. ... This section outlines attributes of the HTTP protocol that improve interoperability, reduce exposure to known security vulnerabilities, or reduce the potential for implementation variation.
Yeah, "of HTTP" is probably best here.
Code change:
6.1. <del> The client adds the content encodings that it supports to the "Accept-Encoding" request header. e.g.: </del> <ins> When a dictionary is available for use on a given request, and the client chooses to make dictionary-based content-encoding available, the client adds the dictionary-aware content encodings that it supports to the "Accept-Encoding" request header. e.g.: When a client does not have a stored dictionary that matches the request, or chooses not to use one for the request, the client MUST NOT send its dictionary-aware content-encodings in the "Accept- Encoding" request header. </ins> 6.2.

Related discussion:
text: Adds language to the to not send the dictionary-aware encodings when a dictionary is not available (or when one is available but not being used). The dictionary-based encodings don't work without a dictionary (they contain a header that has the dictionary hash) and should not be advertised when they are not really available.
Thanks
Code change:
claim of the SD-JWT MUST be used. <del> Furthermore, the recipient of the SD-JWT VC MUST validate that the public verification key for the Issuer-signed JWT as defined in issuer-signed-jwt-verification-key-validation. </del> <ins> Furthermore, the recipient of the SD-JWT VC MUST validate the public verification key for the Issuer-signed JWT as defined in issuer- signed-jwt-verification-key-validation. </ins> If there are no selectively disclosable claims, there is no need to process the

Related discussion:
text: Updated terminology and other sections to clarify VCs and presentations can be repudiable or non-repudiable Minor typo fixed See preview here: URL
3 approvals, merging
The specification currently uses terms like public key validation and potentially other things when it comes to the verification of the KB-JWT. We should make sure there is no language that would prohibit the use of MAC authentication for KB-JWT and Issuer-signed JWT.
Currently blocked by SD-JWT: URL URL
NAME A few options we discussed on the editor's call today (cc NAME NAME ): not do anything in SD-JWT to enable this since SD-JWT just prohibits "symmetric algorithms". We could wait for an JOSE value specification to appear and to be registered in the IANA registry which states that the algorithm is not symmetric. One downside of this approach is that standard JOSE libs won't work today since the value is not supported. Note that technically one could implement this using standard if the key was agreed/derived using an ECDH/ConcatKDF schema. remove the normative statement completely from SD-JWT that prohibits "symmetric algorithms". change the normative statement to a SHOULD NOT use "symmetric algorithms" and explain in the SD-JWT security - considerations section where symmetric values are acceptable and when not. keep the MUST NOT statement in SD-JWT but add an "... unless" clause that explains where this could be useful, e.g., for hybrid schemes but this needs to be confirmed if this process is indeed hybrid and therefore the use case is covered.
I think is the cleanest approach, but may take more time for implementations, we will try to get some experience there. also doesn't sound bad to me.
I think I still lean towards preferring something like # 2 - just remove the explicit prohibition of symmetric algorithms from SD-JWT and not say much, if anything else about it in that spec. Let the layer above SD-JWT/JOSE (probably the presentation protocol) define how an HMAC key is agreed upon and use existing JWS HMAC algs and implementations. I.e., the verifier sends a public key in it's presentation request, which the generator uses in a key agreement with their private key to get a key that is then KDFd to produce an appropriate key for existing/established JWS HS256[384|512] algs.
Code change:
claim of the SD-JWT MUST be used. <del> Furthermore, the recipient of the SD-JWT VC MUST validate that the public verification key for the Issuer-signed JWT as defined in issuer-signed-jwt-verification-key-validation. </del> <ins> Furthermore, the recipient of the SD-JWT VC MUST validate the public verification key for the Issuer-signed JWT as defined in issuer- signed-jwt-verification-key-validation. </ins> If there are no selectively disclosable claims, there is no need to process the

Related discussion:
text: That layer is going to have to define much of that anyway so there's not much gain from pushing an ECDH-based MAC alg into JOSE/JWS (also note that defining and registering a new JOSE alg is far from a trivial exercise). And the prohibition of symmetric algorithms in SD-JWT makes sense from a particular perspective but is arguably just unnecessarily restrictive at the building block layer.
I would agree that removing the restriction is okay, as SD-JWT is an improvement of JWT and JWTs don't have this restriction. Do you think that ECDH-ES is an anti-pattern? It has been in JWA from the beginning and you could have the same arguments there?
I wouldn't take it that far. My comments/arguments here are really just in the context of the current state of JWS specs and existing library support.
NAME NAME if option 2 is our favorite options. Should the SD-JWT VC spec then say something about that? IMO, it would be good to say something in the security considerations at least.
I agree in general that since SD-JWT is a building block, being too restrictive there regarding symmetric algorithms is probably not necessary.
I don't object removing the restriction, I checked RFC7519 and there is no similar statement.
Definitely not opposed to saying something. But it might be challenging to say something that's actually meaningful/helpful.
URL removes the explicit prohibition on MAC from SD-JWT (which will be in the -08 draft-ietf-oauth-selective-disclosure-jwt)
Then, we need a PR that cleans up the language in this specification, so MAC is not going to be prohibited.
Code change:
possible values, which are of type varint: The client MUST send a ROLE parameter with one of the three values <del> specified above.  The server MUST close the connection if the ROLE </del> <ins> specified above.  The server MUST close the session if the ROLE </ins> parameter is missing, is not one of the three above-specified values, or it is different from what the server expects based on the application.

Related discussion:
text: I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:
Code change:
RFC8126) and MUST conform to the purpose of content coding defined in content.codings. <ins> New content codings ought to be self-descriptive whenever possible, with optional parameters discoverable within the coding format itself, rather than rely on external metadata that might be lost during transit. </ins> 7.1.3. A language tag, as defined in RFC5646, identifies a natural language

Related discussion:
text: As part of the discussion about the Encryption specification we discussed how Content-Encodings can or should take parameters from HTTP headers. The consensus was that they shouldn't. Whatever information a C-E may need should be inside the body of the object, just like the GZIP header etc. We should document this as a rule, if we ever do a HTTP[1].ter
+1, except for the constraint: "when possible". In the case of the encryption coding, it's clearly necessary to have the actual key information needed for description outside the payload.
we can add something to URL
I'm fine with this, but I'm also fine with closing with no action. I'm not sure what value it's really adding, since it's so vague, but I'm not sure what else can be said.
Code change:
TLS authentication of the server and HTTP request signing using a secret key. <del> 3.5. </del> <ins> 3.7. </ins> In a typical system of workloads additional information is needed in order for the workload to perform its function.  For example, it is

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:
This specification does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., <del> Cache-Control: no-store).  In particular, when an application caches data and does not make this apparent to or easily controllable by the user, it is strongly encouraged to honour basic control mechanisms like Cache-Control: no-store, as they indicate the resource's intent regarding caching. </del> <ins> Cache-Control: no-store). However, when an application caches data and does not make this apparent to or easily controllable by the user, it is strongly encouraged to define its operation with respect to HTTP cache directives, so as not to surprise authors who expect caching semantics to be honoured.  For example, while it might be reasonable to define an application cache "above" HTTP that allows a response containing Cache-Control: no-store to be reused for requests that are directly related to the request that fetched it (such as those created during the same page load), it would likely be surprising and confusing to users and authors if it were allowed to be reused for requests unrelated in any way to the one from which it was obtained. </ins> 7.

Related discussion:
text: It seems to me that cross-page loads are exactly the type of thing that a sender of no-store is trying to avoid. It is the type of flag sent on highly sensitive or volatile data. Images, stylesheets, etc which have cross-page relevance should not be using it.
Code change:
5.3.1. <del> A proposed congestion control algorithm SHOULD include a clear explanation of any deviations from RFC2914 and RFC7141. </del> <ins> A proposed congestion control algorithm MUST clearly explain any deviations from RFC2914 and RFC7141. </ins> 5.3.2.

Related discussion:
text: A few clarifying nits, as resolving the tension between a global "MUST evaluate" and some local "SHOULD evaluate"s.
Merge!
Code change:
4.4.2. Applications that use HTTP will typically employ the "http" and/or <del> "https" URL schemes. "https" is RECOMMENDED to provide </del> <ins> "https" URI schemes. "https" is RECOMMENDED to provide </ins> authentication, integrity and confidentiality, as well as mitigate pervasive monitoring attacks RFC7258. However, application-specific schemes can also be defined.  When <del> defining an URL scheme for an application using HTTP, there are a </del> <ins> defining an URI scheme for an application using HTTP, there are a </ins> number of tradeoffs and caveats to keep in mind: Unmodified Web browsers will not support the new scheme.  While it <del> is possible to register new URL schemes with Web browsers (e.g. </del> <ins> is possible to register new URI schemes with Web browsers (e.g. </ins> registerProtocolHandler() in HTML5, as well as several proprietary approaches), support for these mechanisms is not shared by all browsers, and their capabilities vary.

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
6.2.2.1. <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 PATH parameter from the server, or when WebTransport is used, it MUST close the connection.  It follows the URI formatting rules RFC3986. </del> <ins> The PATH parameter (Parameter Type 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 PATH parameter from the server, or when WebTransport is used, it MUST close the connection.  It follows the URI formatting rules RFC3986. </ins> When connecting to a server using a URI with the "moqt" scheme, the client MUST set the PATH parameter to the "path-abempty" portion of

Related discussion:
text: Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good
Code change:
the Transparency Service Registration Policy and that has been persisted in the Registry.  Unless advertised in the Transparency Service Registration Policy, the Verifier should not assume that the <del> ordering of Transparent Statements in the Registry matches the ordering of their issuance. </del> <ins> ordering of Signed Statements in the Registry matches the ordering of their issuance. </ins> Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later
Code change:
<del> (label: "15" pending CWT_CLAIM_COSE): A CWT representing the </del> <ins> (label: "15" pending CWT_CLAIMS_COSE): A CWT representing the </ins> Issuer ("iss") making the statement, and the Subject ("sub") to correlate a collection of statements about an Artifact. Additional CWT_CLAIMS MAY be used, while "iss" and "sub" MUST be

Related discussion:
text: simplified a few references & added a WG, some reordering
Thanks, NAME
A small fix and then it will be ready to it.LGTM!LGTM
Code change:
4.2.4. Given an ASCII string input_string, return a list of parameterized <del> identifiers. input_string is modified to remove the parsed value. </del> <ins> items. input_string is modified to remove the parsed value. </ins> Let items be an empty array. While input_string is not empty: <del> Let item be the result of running Parse Parameterized Identifier from Text (parse-param-id) with input_string. </del> <ins> Let item be the result of running Parse Parameterized Item from Text (parse-param-item) with input_string. </ins> Append item to items.

Related discussion:
text: in , NAME asks about having Parameterised Lists whose parameterised identifiers are things other than Tokens. Because of the way SH is put together, I think this would be a fairly easy change, in terms of the spec and implementations; it would require a few more tests. The only downside I can think of immediately is that specs would need to constrain the type of the parameterised identifier themselves, and specify error handling (if it weren't the default "blow up"). Thoughts? I also wonder if we should come up with a better name than "parameterised identifier", especially since we've ditched "identifier" elsewhere. member name? member id? primary identifier?
That works, since splitting lists from parameterised lists. Are you thinking , or just adding a few types? It also changes my thinking a tiny bit on , although not much. I like "parameterised element" but that introduces a new word. "parameterised item" is a nice shade, if any item is allowed there, but "primary identifier" works too. :art: :paintbrush:
The downside here is that it would be very hard to represent in JSON -- e.g., in the . At least some programming languages support hashes/dictionaries/objects with arbitrary key types (e.g., Python, JavaScript, Ruby), but I'm not sure how widespread that is -- especially if folks represent the different between and with an object for . NAME is this a nice-to-have or something that's a blocker?
(Fwiw I do think we should call this a Parameterised Token)
At this point do we just have to accept that the SH data model is essentially a subset of the JavaScript model? Numbers are bounded by JavaScript's limitations, object keys have to be stringy, nobody likes 'token' because it isn't a native JS type... I don't mind if that's the case, but it would be good to just say it outright somewhere. It would also give us a solid position to start from when considering other proposals. Hmm, C++ and Go could be have issues mixing key types within a single map, and Perl is definitely not going to like non-string keys.
It doesn't have to be -- it's just easier for me to write tests this way :)
This was a nice-to-have for me. I’d worked around it by putting an unused string as the identifier. It looks like that workaround is no longer necessary?
Code change:
The following parameters MUST be included in the protected header of the countersigner (sign_protected in cose_sign1_countersign): <ins> Service ID (label: TBD): The Service identifier, as defined in the Transparency Service parameters. </ins> Issued At (label: TBD): The time at which the countersignature was issued as the number of seconds from 1970-01-01T00:00:00Z UTC, ignoring leap seconds.

Related discussion:
text: Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.
Code change:
If a Verifier has decided that Holder Binding is required for a particular use case and the Holder Binding is not present, does not fulfill the requirements (e.g., on the signing algorithm), or no <del> recognized key reference is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. </del> <ins> recognized Holder Binding data is present in the SD-JWT, the Verifier will reject the presentation, as described in verifier_verification. </ins> 8.8.

Related discussion:
text: As discussed on our last call, I added a section saying that there is a potential privacy risk in storing signed End-User data inclusing a discussion and recommendations on potential mitigations. This does include a potentially controversial bit on burning private keys. My final stance on that is subject to the outcome of the that I have launched on Twitter.
Besides what we discussed in our last call, I also made some other tweaks to the wording in the , please review.
should probably add something to the document history too just for posterity
Code change:
6.2.2.2. <del> The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </del> <ins> The MAX_SUBSCRIBE_ID parameter (Parameter Type 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </ins> 6.3.

Related discussion:
text: Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good
Code change:
replayed.  A retried or replayed request can produce different side effects on the server.  In addition to those side effects, replays and retries might be used for traffic analysis to recover information <del> about requests or the resources those requests target. </del> <ins> about requests or the resources those requests target.  In particular, a request that is replayed might result in a different response, which might be observable from the length of protected data even if the content remains confidential. </ins> 6.1.

Related discussion:
text: NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!
Code change:
8.1.1.1. <del> Name: verifiable_data_structure </del> <ins> Name: verifiable-data-structure </ins> <del> Label: TBD_1 </del> <ins> Label: TBD_1 (requested assignment 12) </ins> <del> Value type: verifiable_data_structure </del> <ins> Value type: int / tstr </ins> Value registry: See <del> Description: Merkle tree algorithm used to produce a COSE Sign1 payload. </del> <ins> Description: Tag indicating the Verifiable Data Structure, see sec-generic-verifiable-data-structures. </ins> <del> Name: inclusion_proof </del> <ins> Editors note: Authors are discussing how to avoid flooding the cose header parameters registry with new proof types. </ins> <del> Label: TBD_2 </del> <ins> Name: inclusion-proof </ins> <del> Value type: inclusion_proof </del> <ins> Label: TBD_2 (requested assignment 13) Value type: bstr </ins> Value registry: See <del> Description: Merkle tree inclusion proof for the given verifiable_data_structure. </del> <ins> Description: Tag indicating the "inclusion" Proof Type, see sec- generic-inclusion-proof. </ins> <del> Name: consistency_proof </del> <ins> Name: consistency-proof </ins> <del> Label: TBD_2 </del> <ins> Label: TBD_2 (requested assignment 14) </ins> <del> Value type: consistency_proof </del> <ins> Value type: bstr </ins> Value registry: See <del> Description: Merkle tree consistency proof for the given verifiable_data_structure. </del> <ins> Description: Tag indicating the "consistency" Proof Type, see sec- generic-consistency-proof. </ins> 8.1.2.

Related discussion:
text: This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions