jiebi/CodeConvo huggingface dataset:
Code change:
<del> 6.1. </del> <ins> 7.1. </ins> The choice of cryptographic hash function is the primary primitive impacting the security of authenticating payload inclusion in a merkle root.  Tree algorithm designers should review the latest guidance on selecting a suitable cryptographic hash function. <del> 7. </del> <ins> 8. </ins> <del> 7.1. </del> <ins> 8.1. </ins> <del> 7.1.1. </del> <ins> 8.1.1. </ins> This document requests IANA to add new values to the 'COSE Algorithms' and to the 'COSE Header Algorithm Parameters' registries in the 'Standards Action With Expert Review category. <del> 7.1.1.1. </del> <ins> 8.1.1.1. </ins> <del> Name: tree_alg </del> <ins> Name: verifiable_data_structure </ins> Label: TBD_1 <del> Value type: tree_alg </del> <ins> Value type: verifiable_data_structure </ins> Value registry: See

Related discussion:
text: There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.
Code change:
The "Repr-Digest" HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm <del> applied to the entire "selected representation data" (see SEMANTICS). </del> <ins> applied to the entire selected representation data (see SEMANTICS). </ins> Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests

Related discussion:
text: Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that
Code change:
The following pseudo-header fields are defined for HTTP/2 requests: <del> All HTTP/2 requests MUST include exactly one valid value for the </del> <ins> All HTTP/2 requests MUST include exactly one valid value for the " </ins> <del> , </del> <ins> ", " </ins> <del> , and </del> <ins> ", and " </ins> <del> pseudo-header fields, unless it is a CONNECT.  An HTTP request that </del> <ins> " pseudo-header fields, unless it is a CONNECT.  An HTTP request that </ins> omits mandatory pseudo-header fields is malformed. Individual HTTP/2 requests do not carry an explicit indicator of

Related discussion:
text: I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.
Code change:
4.1. <del> *Senders/Receivers*: Many to Many *Bi-directional*: Yes *Latency*: Ultra-Low Where media is both sent and received; This may include audio from both microphone(s) or other inputs, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation.  This may be done as client/server, or peer to peer with a many to many relationship of both senders and receivers. 4.2. </del> <ins> 4.1.1. </ins> *Senders/Receivers*: One to One *Bi-directional*: Yes *Latency*: <del> Ull100 </del> <ins> Ull-50 </ins> Where media is received, and user inputs are sent by the client. This may also include the client receiving other types of signalling,

Related discussion:
text: It's likely that only NAME and I will care about this, but I think it matters :grin:
Code change:
7.1. <del> To obtain the Status List or Status List Token, the Verifier MUST send a HTTP GET request to the Status List Endpoint.  Communication with the Status List Endpoint MUST utilize TLS.  Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </del> <ins> To obtain the Status List or Status List Token, the Relying Party MUST send a HTTP GET request to the Status List Endpoint. Communication with the Status List Endpoint MUST utilize TLS.  Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. </ins> <del> The Verifier SHOULD send the following Accept-Header to indicate the requested response type: </del> <ins> The Relying Party SHOULD send the following Accept-Header to indicate the requested response type: </ins> "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs <del> If the Verifier does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. </del> <ins> If the Relying Party does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. </ins> 7.2.

Related discussion:
text: Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology
Code change:
corresponding Date header field to the message's header section if it is cached or forwarded downstream. <ins> A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received. </ins> A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP

Related discussion:
text: They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Code change:
corresponding Date header field to the message's header section if it is cached or forwarded downstream. <ins> A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received. </ins> A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP

Related discussion:
text: Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)
Code change:
corresponding Date header field to the message's header section if it is cached or forwarded downstream. <ins> A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received. </ins> A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP

Related discussion:
text: Those changes are editorial.
specifies what to do when it isn't present (use the received time), but not what to do when it doesn't parse. The intuitive thing to do is align, and say that the received time should be used in this situation as well -- but probably not require implementations to replace it if forwarded. I might write some tests...
Okay, I am still waiting on those new glasses. Too much Age. It's fine with me if we interpret an invalid Date as the received time, but that assumes we know the received time when we parse the Date. I think as long as the scope is specific to Caching, we should specify that a cache always record the time received (regardless of Date) and use the received time if the Date field value is invalid.
is used in a number of places in caching, so that modification will be pretty invasive. Why do you think it needs to be restrained to just caching? I suppose it could be specified in semantics as something like 'If the Date field value does not parse, it MAY be replaced with the time the message was received. Caches SHOULD consider the message receipt time as the Date value when it cannot be parsed.'
The "it" in that last sentence has an unclear subject (is it the date, the arrival time, or the cache?), and "consider" -> "use".
The only reason I said it is okay for caching is because we already depend on the cache having a clock and storing time received. It seems reasonable, regardless of role, if the recipient has a clock. But I wasn't suggesting a new requirement.
Code change:
described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. <ins> When there are no selectively disclosable claims, a presentation of SD-JWT VC does not contain any Disclosures. </ins> 6.1.1. If the presentation of the SD-JWT VC includes a Holder Binding JWT,

Related discussion:
text: Merging this since this is an improvement and PR might not be merged as is.
NAME can you pls resolve merge conflicts, then we can merge this PR.
Merging PR since a lot of approvals.
lgtm, since we have merged PR and might not merge PR , we should merge this.
Code change:
described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. <ins> When there are no selectively disclosable claims, a presentation of SD-JWT VC does not contain any Disclosures. </ins> 6.1.1. If the presentation of the SD-JWT VC includes a Holder Binding JWT,

Related discussion:
text: alternative to based on NAME 's comment "I can't help but wonder if it'd make sense to have the spec be only about SD-JWT VCs and treat the plain JWT VC as just a special case of an SD-JWT with no selectively disclosable claims." no changes to the basic structure. simple clarifications what to do when there are no selectively disclosable claims ie no claim and no Disclosures. Might need some more details but this is how it might look like. (cc NAME NAME linked to rendered preview
Generally, I really like this approach! Some examples could be useful for key binding with JWT (no disclosures)
I'd expect the typ for both to have +jwt if that were really the case. There is another draft up for multiple suffixes. URL Is it simple enough to support now?
should this be titled ? I think this should be changed as well as the title before merging to make sure we are calling out that this covering SD-JWTs and JWTs
Yes. Will make a change once we have a decision whether PR or this one is the way to go…
What is the position of this specification? From my understanding it defines a VC with JWT claims it defines a profile for the JWT claims it defines a profile for securing the VC There's an open discussion between the sd-jwt and JWS protection. Relevant discussion has been started URL - sd-jwt introduces an encoding that becomes incompatible with JWS in the limit where selective disclosure is not used. In other words, it introduces a first-order phase transition. Let's see how this topic resolves. IMO, the data model and securing mechanisms should support both sd-jwt and JWS.
I do like this approach, but I am a bit concerned that even in the 'no disclosures' case, we'll have the trailing tilde in the issuance and presentation (when no KB is present). A JWT is not a special case of an SD-JWT for this reason.
I agree with the concern.
IMHO keeping the trailing tilde is preferable as it keeps the model consistent.
from what I am sensing, there seems to be a lot of preference towards the approach in this PR over , partially because it is simpler and gives one credential format and not two (consolidation, yay!), with one major discussion point being a ~ after a JWT VC when it is issued.
Code change:
described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure- jwt. <ins> When there are no selectively disclosable claims, a presentation of SD-JWT VC does not contain any Disclosures. </ins> 6.1.1. If the presentation of the SD-JWT VC includes a Holder Binding JWT,

Related discussion:
text: a bit of the context... this trailing ~ is the result of the decision being taken in SD-JWT spec to better align the issuance and presentation formats, (URL does it, and it has not been merged yet). One option is to keep issuance and presentation formats separate in SD-JWT (as-is) so that there is no ~ when (SD-)JWT VC is issued. but that is not that clean from a pure SD-JWT processing perspective is I think the opinion of its authors (NAME NAME so the question is really what to do with a trailing ~ when there is no SD in SD-JWT based VC.
should be good to merge once NAME takes a look and approves
I'm ok with this direction. I personally don't like the trailing tilde but we can fix that in another PR. I'll open an issue in the repository.
Merging this PR since a lot of approvals and no objections.
approving but will create an issue to address trailing tilde.I approve this approach over as, the specification is much cleaner I expect implementations to be much cleaner I don't see confusion with trailing tilde, because typ is not jwt but sd-jwt most interop profiles will require SD support anywayI prefer URL since I find its description of what we're achieving more natural / less surprising. But I can live with this description as well, provided the distracting "with JSON Claims" language is removed.
Code change:
The retrieval's URI's path path-matches the cookie's path. If the cookie's secure-only-flag is true, then the retrieval's <del> URI's scheme must denote a "secure" protocol (as defined by the user agent). </del> <ins> URI must denote a "secure" connection (as defined by the user agent). </ins> <del> NOTE: The notion of a "secure" protocol is not defined by this document.  Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol. </del> <ins> NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol and "localhost" to be trusted host. </ins> If the cookie's http-only-flag is true, then exclude the cookie if the retrieval's type is "non-HTTP".

Related discussion:
text: The current limbo state isn't helping anyone :) cc NAME
Yes, +1 to documenting reality and no longer blocking the IETF process for 6265bis on this particular item (which I do agree we should treat as a security bug to be eventually solved).
Not an editor, but LGTM (given that it reflects reality).LGTM, given the context.
Code change:
NOTE: This algorithm parses both Integers and Floats float, and returns the corresponding structure. <del> If the first character of input_string is not "-" or a DIGIT, fail parsing. </del> <ins> Let type be "integer". Let sign be 1. Let input_number be an empty string. If the first character of input_string is "-", remove it from input_string and set sign to -1. </ins> <del> Let input_number be the result of consuming input_string up to (but not including) the first character that is not in DIGIT, "-", and ".". </del> <ins> If input_string is empty, fail parsing. </ins> <del> If any character of input_number after the first is "-", fail </del> <ins> If the first character of input_string is not a DIGIT, fail </ins> parsing. <del> If input_number contains ".", parse it as a floating point number and let output_number be the result. </del> <ins> While input_string is not empty: Let char be the result of removing the first character of input_string. If char is a DIGIT, append it to input_number. Else, if type is "integer" and char is ".", append char to input_number and set type to "float". Otherwise, fail parsing. If type is "integer" and input_number contains more than 19 characters, fail parsing. If type is "float" and input_number contains more than 16 characters, fail parsing. If type is "integer", parse input_number as an integer and let output_number be the result. Otherwise: If the final character of input_number is ".", fail parsing. </ins> <del> Otherwise, parse input_number as an integer and let output_number be the result. </del> <ins> Parse input_number as a float and let output_number be the result. </ins> <del> Return output_number. </del> <ins> Return the product of output_number and sign. </ins> 4.6.

Related discussion:
text: This algorithm automatically enforces the ABNF syntax, including length limits. It still punts on the actual strtoi/strtof part. ?
Much better, thanks!
Code change:
reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently <del> providing a prefix on the stub network, it needs to take no action. If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </del> <ins> providing a prefix on the stub network, it does not need to take action.  If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </ins> When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been

Related discussion:
text: The working group didn't actually agree on the use of the term "CPE Router", and there were substantive objections to it. I've used the term Home Gateway here, and included a definition that I think includes both ISP-provided routers with integrated uplink support (cable modem or DSL modem) and also includes routers where the WAN link is an ethernet connector. Not clear that this is correct, but hopefully it's evolving in the right direction.
Code change:
mechanism can be used along with opportunistic or application-driven message signatures by either party. <ins> The mechanisms defined in this document are important tools that can be used to an overall security mechanism for an application.  This toolkit provides some powerful capabilities, but does not sufficient in creating an overall security story.  In particular, the requirements in application and the security considerations in security are of high importance to all implementors of this specification.  For example, this specification does not define a means to directly cover HTTP message content (defined in HTTP), but relies on the DIGEST specification to provide a hash of the message content, as discussed in security-message-content. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Related discussion:
text: message signatures are just one part of an overall system, and this adds language to make that expectation more explicit in the introductory sections.