jiebi/CodeConvo huggingface dataset:
Code change:
third-party code, development practices and tools, deployment methods and infrastructure, and interfaces and protocols.  The software supply chain comprises all elements associated with an application's <del> design, development, deployment, and maintenance throughout its entire lifecycle.  The complexity of software coupled with a lack of lifecycle visibility increases the risks associated with system attack surface and the number of cyber threats capable of harmful impacts, such as exfiltration of data, disruption of operations, and loss of reputation, intellectual property, and financial assets. There is a need for a platform architecture that will allow consumers to know that suppliers maintained appropriate security practices without requiring access to proprietary intellectual property. SCITT-enabled products and analytics solutions will assist in managing compliance and assessing risk to help prevent and detect supply chain attacks across the entire software lifecycle while prioritizing data privacy. </del> <ins> design, development, build, integration, deployment, and maintenance throughout its entire lifecycle.  The complexity of software coupled with a lack of lifecycle visibility increases the risks associated with system attack surface and the number of cyber threats capable of harmful impacts, such as exfiltration of data, disruption of operations, and loss of reputation, intellectual property, and financial assets.  There is a need for a platform architecture that will allow consumers to know that suppliers maintained appropriate security practices without requiring access to proprietary intellectual property.  SCITT-enabled products and analytics solutions will assist in managing compliance and assessing risk to help prevent and detect supply chain attacks across the entire software lifecycle while prioritizing data privacy. </ins> 1.1.

Related discussion:
text: Please note the template is based on: https://rfc-URL We would like to stick to this template and progress this document!
Code change:
This would result in the following unsigned response message: <ins> The server signs the response with its own key, including the "@status" code and several header fields in the covered components. </ins> To cryptographically link the response to the request, the server <del> signs the response with its own key and includes the method, authority, and the signature value "sig1" from the request in the covered components of the response.  The signature base for this example is: </del> <ins> includes the method, authority, and the signature and signature input labeled "sig1" from the request in the covered components of the response.  The signature base for this example is: </ins> The signed response message is: <del> Since the request's signature value itself is not repeated in the response, the requester MUST keep the original signature value around long enough to validate the signature of the response that uses this component identifier. </del> Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. <ins> Since the signature component values from the request are not repeated in the response, the requester MUST keep the original message component values around long enough to validate the signature of the response that uses this component identifier.  In most cases, this means the requester needs to keep the original request message around, since the signer could choose to include any portions of the request in its response, according to the needs of the application. Since it is possible for an intermediary to alter a request message before it is processed by the server, applications need to take care not to sign such altered values as the client would not be able to validate the resulting signature. Applications needing this type of binding have to sign sufficient portion the request to ensure that it is uniquely tied to the response.  Signing the signature value of a signed request alone does not provide sufficient coverage in most cases, as discussed in security-sign-signature. The response signature can only cover what is included in the request.  Therefore, if an application needs to bind the message content of the request in its response, the client needs to include a means for covering that content, such as a Content-Digest field.  See the discussion in security-message-content for more information. </ins> The "req" parameter MUST NOT be used in a signature that targets a request message.

Related discussion:
text: A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?
Code change:
the request to the origin server.  A proxy MUST NOT generate a Vary field with a "*" value. <del> A Vary field value consisting of a comma-separated list of names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation.  The potential selecting header fields are not limited to those defined by this specification. </del> <ins> A Vary field value consisting of a list of field names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation.  The potential selecting header fields are not limited to those defined by this specification. </ins> For example, a response that contains

Related discussion:
text: Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:
Code change:
<del> Security Considerations for Optimistic Use of HTTP Upgrade </del> <ins> Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 </ins> draft-ietf-httpbis-optimistic-upgrade-latest Abstract <del> The HTTP/1.1 Upgrade mechanism allows the client to request a change to a new protocol.  This document discusses the security </del> <ins> In HTTP/1.1, the client can request a change to a new protocol on the existing connection.  This document discusses the security </ins> considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues.

Related discussion:
text: This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME
Code change:
status code values summarized in the table of overview.of.status.codes. <ins> Additionally, please update the following entry in the Hypertext Transfer Protocol (HTTP) Status Code Registry: </ins> 13.4. Please update the "Message Headers" registry of "Permanent Message

Related discussion:
text: Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok
Code change:
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  The <del> SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. </del> <ins> SHA algorithm MUST NOT be used as it's now vulnerable to collision attacks IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document. <del> Status: obsoleted </del> <ins> Status: deprecated </ins>

Related discussion:
text: Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm
Code change:
The "@method" derived component refers to the HTTP method of a request message.  The component value is canonicalized by taking the value of the method as a string.  Note that the method name is case- <del> sensitive as per HTTP, and conventionally standardized method names are uppercase US-ASCII. </del> <ins> sensitive as per HTTP.  While conventionally standardized method names are uppercase US-ASCII, no transformation to the input method value's case is performed. </ins> For example, the following request message:

Related discussion:
text: Clarify method case requirements. Add justification for use of empty query string.
Comment by NAME : >If the query string is absent from the request message, the value is the leading ? character alone: When would it make sense to sign this component although empty? Might be good to add some clarification for the reader.
URL I would drop the "and conventionally standardized method names are uppercase US-ASCII". Method names are case-sensitive, that's what is relevant. The second part somewhat weakens that statement.
This is a note to implementors and doesn't change the normative requirements or behaviors -- I think we should leave it in. Note that the text in question appears in section 9.1 as referenced:
Good catch, and I should have objected to that. Anyway; I don't think it makes sense to note it here. It doesn't help at all - the method name is what appears in the request message. The note doesn't add anything useful, but might cause confusion. Take this ticket as proof.
Having seen people try to normalize things by lowercasing because "it made sense", I disagree that the note doesn't add anything useful. I'd like to leave it in.
Just to clarify: my concern is that implementers will take that as a suggestion to uppercase.
Code change:
HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in <del> association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </del> <ins> association with a previous client-initiated request. Server push was designed to allow a server to improve client- perceived performance by predicting what requests will follow those that it receives, thereby removing a round trip for them.  For example, a request for HTML is often followed by requests for stylesheets and scripts referenced by that page.  When these requests are pushed, the client does not need to wait to receive the references to them in the HTML and issue separate requests. In practice, server push is difficult to use effectively, because it requires the server to correctly anticipate the additional requests the client will make, taking into account factors such as caching, content negotiation, and user behavior.  Errors in prediction can lead to performance degradation, due to the opportunity cost that the additional data on the wire represents.  In particular, pushing any significant amount of data can cause contention issues with more- important responses. </ins> A client can request that server push be disabled, though this is negotiated for each hop independently.  The SETTINGS_ENABLE_PUSH

Related discussion:
text: could have been a solution, but the work on it looks stopped.
URL
NAME suggested calling out the current status: lack of support in browser APIs for push, pointy edges in the usage, and the limitations in the spread of its usage. I think this is a reasonable editorial change.
NAME to draft a document to encourage users to set the value to 0 by default and move on.
Discussed at Feb 2021 interim; intent to document concerns / caveats, recommend sending setting = 0. NAME to PR.
LGTMVery nice. Thanks Mark.
Code change:
according to the calculations in expiration.model. A cache MUST NOT generate a stale response if it is prohibited by an <del> explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an </del> <ins> explicit in-protocol directive (e.g., by a "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an </ins> applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see cache-response-directive).

Related discussion:
text: : I think that MAY should be prose, and should also list retrying the request as an option.
Code change:
Abstract <del> This specification describes three CBOR data structures for primary use in COSE envelopes.  A CBOR encoding of Merkle Roots for use in COSE payloads.  A CBOR encoding of Inclusions Proofs for use in COSE unprotected headers.  A CBOR encoding of Consistency Proofs for use in COSE unprotected headers. </del> <ins> This specification describes verifiable data structures and associated proof types for use with COSE.  The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. </ins> 1. <del> Merkle trees are verifiable data structures that support secure data storage, through their ability to protect the integrity of batches of documents or collections of statements. </del> <ins> Merkle trees are one of many verifiable data structures that enable tamper evident secure information storage, through their ability to protect the integrity of batches of documents or collections of statements. </ins> <del> A merkle proof is a path from a leaf to a root in a merkle tree. </del> <ins> Merkle trees can be constructed from simple operations such as concatenation and digest via a cryptographic hash function, however, more advanced constructions enable proofs of different properties of the underlying verifiable data structure. </ins> <del> Merkle proofs can be used to prove a document is in a database (proof of inclusion), or that a smaller set of statements are contained in a large set of statements (selective disclosure proofs). </del> <ins> Verifiable data structure proofs can be used to prove a document is in a database (proof of inclusion), that a database is append only (proof of consistency), that a smaller set of statements are contained in a large set of statements (proof of disclosure, a special case of proof of inclusion), or proof that certain data is not yet present in a database (proofs of non inclusion). </ins> <del> Typically, merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. </del> <ins> Differences in the representation of verifiable data structures, and verifiable data structure proof types, can increase the burden for implementers, and create interoperability challenges for transparency services. </ins> <del> The simple design and valuable cryptographic properties of merkle trees have been leveraged in many network and database applications. Differences in the representation of a merkle tree, merkle leaf and merkle inclusion proof can increase the burden for implementers, and create interoperability challenges. This document describes the three data structures necessary to use merkle proofs with COSE envelopes. </del> <ins> This document describes how to convey verifiable data structures, and associated proof types in COSE envelopes. </ins> 1.1.

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
Code change:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, <del> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

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:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, <del> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

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!