jiebi/CodeConvo huggingface dataset:
Code change:
(COSE) STD96 header parameters that carry the TimestampToken (TST) output of RFC 3161, thus allowing existing and widely deployed trust infrastructure to be used with COSE structures used for signing <del> (COSE_Sign and COSE_Sign1). </del> <ins> ("COSE_Sign" and "COSE_Sign1"). </ins> 1.1. <ins> This section discusses two use cases, each representing one of the two modes of use defined in modes. A first use case is a digital document signed alongside a trustworthy timestamp.  This is a common case in legal contracts.  In such scenario, the document signer wants to reinforce the claim that the document existed on a specific date.  To achieve this, the document signer acquires a fresh TST for the document from a TSA, combines it with the document, and then signs the bundle.  Later on, a relying party consuming the signed bundle can be certain that the document existed at the time specified by the TSA.  The relying party does not have to trust the signer's clock, which may have been maliciously altered or simply inaccurate. This usage scenario motivates the "Timestamp then COSE" mode defined in sec-timestamp-then-cose. A second use case is the notarization of a signed document by registering it at a Transparency Service.  This is common for accountability and auditability of issued documents.  Once a document is registered at a Transparency Service's append-only log, it cannot be changed.  In certain cases, the registration policy of a Transparency Service may require adding a trustworthy timestamp to the document at the time of registration.  This is done to enhance confidence in the timing of the registration, ensuring that the registration could not have occurred before a certain point in time. To achieve this, the Transparency Service acquires a TST from a TSA, bundles it alongside the signed document, and then registers it.  A relying party that wants to ascertain the time of registration of a given document does not have to trust the Transparency Service's clock, which may have been maliciously altered or can simply be inaccurate. This usage scenario motivates the "COSE then Timestamp" mode described in sec-cose-then-timestamp. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in

Related discussion:
text: In , Orie commented that: "Some use cases for the 2 modes might improve the document."_ E.g., C2PA, SCITT, PDF timestamping.
Add a paragraph to the Introduction to explain the use cases.
given enough guidance you can pass as an artist ;) Authors might consider providing some guidance regarding validation of CTT where the COSE claims appear (iat, nbf) to have happened after the timestamp ( time travel ). IIRC cose counter signatures apply to the protected header, payload and signature, whereas CTT only applies to the signatures. This means that the TSA does not countersign any protected information in the header? Some use cases for the 2 modes might improve the document. Security considerations seem light. OS >
Code change:
5.3.2. <del> All dependent streams are allocated an integer weight between 1 to </del> <ins> All dependent streams are allocated an integer weight between 1 and </ins> 256 (inclusive). Streams with the same parent SHOULD be allocated resources

Related discussion:
text: A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.
Code change:
to notify Transparency Services of credential revocation to stop Verifiers from accepting Signed Statements signed with compromised credentials.  Issuers SHOULD register new Signed Statements <del> indicating the revocation, using the same "13" CWT "iss" and "sub" </del> <ins> indicating the revocation, using the same "15" CWT "iss" and "sub" </ins> claims. The confidentiality of any identity lookup during Signed Statement

Related discussion:
text: Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences
Code change:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). <del> 5.7.1. </del> <ins> 5.8.1. </ins> An IETF transport is not tied to a specific Internet path or type of path.  The set of routers that form a path can and do change with

Related discussion:
text: Added first-cut of minimum delay text. Intended to
Delay based congestion control protocols are making an assumption that the observed RTT is the sum of a constant "min delay" and a variable queuing delay. This assumption may not be valid on wireless links, as delays vary when the distance between mobile endpoint and base station increases, or when changing transmission condition cause the radios to adopt different modulation and coding strategies. I suspect we also have these "variable delays" in satellite services, especially when using constellations of low orbit satellites. The state of the art is not very good. BBR for example recognizes its dependency on accurate estimate of the min RTT, but has to resort to some kind of periodic reset if measurements of RTT kept over RTT min for 10 seconds -- which is both quite long for some apps, and quite annoying for real time apps suffering a transmission issue every ten seconds. LEDBAT++ does something similar. I think these "variable delays" link are good candidates for "special case" links, to be mentioned in a separate section.
The variable delay part applies to most satellite broadband access using GEO also - not because of propagation usually, but more a result of radio resource sharing. It might well apply to some other technologies that use a shared capacity pool.
Min delay variation strikes me as a bit of a corner case -- perhaps it can be an optional case to evaluate. The other piece is delay variation is not always congestion -- this is IIUC very common in wireless and is part of that mandatory case.
In think this is something like: An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering. In this case, a congestion controller could reduce the sending rate to the point of minimum buffering while still preserving the maximum throughput. An internet Path can also include complex subnetworks where the minimum delay changes over various time scales. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc. It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity. Variation also results when a higher priority diffserv traffic classic prompts the transmission by a lower class.
Code change:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). <del> 5.7.1. </del> <ins> 5.8.1. </ins> An IETF transport is not tied to a specific Internet path or type of path.  The set of routers that form a path can and do change with

Related discussion:
text: In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.
The delay will also change when the wireless path between two wireless nodes becomes longer, or slower, or shorter, or faster. Or when a wireless router changes the schedule of transmission and starts polling a wireless station more often. or less often. To give an extreme example, suppose a spacecraft flying away from earth at 12,000 km/h. Every hour, the delay will increase by 40 ms.
Sure, however that requirement is very specific to certain systems - my point is that even for fixed cabled and broadband wireless systems, the base delay changes.
I suggest the language "non stationary minimum delay" to encompass all causes that resemble some form of route or path change, explicitly including LEO and mobile motion. It doesn't really cover link layer re transmissions or delays caused by link scheduling algorithms, but these are short term variations that are more likely to be statistically similar to IP queuing delay. I would use the term "hidden queues" to refer to unmanaged queues that (almost) never incur significant backlog but do occasionally cause jitter and generally can not be observed at the IP queuing layer.
NAME will add something in Sec 5 ("Special Cases")
Code change:
Reference: This document <ins> Label: TBD_3 Value type: "bstr" Reference: This document </ins> 6.1.2. This document requests IANA to add the following new value to the <del> 'Tree Algorithms' registry: </del> <ins> ''COSE Verifiable Data Structures' registry: Name: CCF_LEDGER_SHA256 </ins> <del> Identifier: TBD_1 (requested assignment 2) </del> <ins> Value: TBD_1 (requested assignment 2) </ins> <del> Tree Algorithm: ccf-ledger </del> <ins> Description: Historical transaction ledgers, such as the CCF ledger </ins> Reference: This document

Related discussion:
text: NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call
Code change:
mechanism QUIC-TLS. The user agent leverages a TLS keying material exporter KEY-EXPORT to <del> generate a nonce which can be signed using the user's key.  The </del> <ins> generate a nonce which can be signed using the chosen key.  The </ins> keying material exporter uses a label that starts with the characters "EXPORTER-HTTP-Unprompted-Authentication-" (see schemes for the labels and contexts used by each scheme).  The TLS keying material

Related discussion:
text: The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.
Code change:
not the "representation metadata". Besides, it allows to protect "representation data" from buggy <del> manipulation, buggy compression, etc. </del> <ins> manipulation, undesired "transforming proxies" (see Section 6.5 of SEMANTICS), etc. </ins> Moreover, identity digest-algorithms (eg. "id-sha-256" and "id-sha- 512") allow piecing together a resource from different sources (e.g.

Related discussion:
text: [x] avoid ambiguous statement on digest protecting from compressed content-coding URL i[x] t can protect from intermediaries altering representation metadata (content-type, content-coding)
Code change:
6. The "Downlink" request header field is a number that indicates the <del> client's maximum downlink speed in megabits per second (Mbps), as defined by the "downlinkMax" attribute in the W3C Network Information API (NETINFO). </del> <ins> client's maximum downlink speed in megabits per second (Mbps). </ins> If Downlink occurs in a message more than once, the minimum value should be used to override other occurrences.

Related discussion:
text: Related discussions: URL URL
NAME thanks for the review, updated.. ptal.
Thanks!
LGTM
Code change:
all implementation details behind the resource interface are intentionally hidden by the server. <ins> This extends to how header and trailer fields are stored; while common header fields like will typically be stored and returned upon subsequent GET requests, header and trailer field handling is specific to the resource that received the request.  As a result, an origin server SHOULD ignore unrecognized header and trailer fields received in a PUT request (i.e., do not save them as part of the resource state). </ins> An origin server MUST NOT send a validator field (response.validator), such as an

Related discussion:
text: As discussed on call, we need to say that PUT requests can contain response headers, and what that means.
Code change:
6.4. In protocols that deliver data out of order (such as QUIC HQ) early <del> data can arrive after the handshake completes.  This leads to potential ambiguity about the status of requests and could lead to inconsistent treatment (see be-consistent).  Implementations MUST either ensure that any early data that is delivered late is either discarded or consistently identified and processed. </del> <ins> data can arrive after the handshake completes.  A server MAY process requests received in early data after handshake completion if it can rely on other instances correctly handling replays of the same requests. </ins> 7.

Related discussion:
text: Thanks NAME and NAME for pushing on this.
I think this is good and can even emphasize how to consistently disable 0-RTT across a cluster for any reason then consistently re-enable it.
Code change:
including either header compression (HPACK, QPACK) or a generic framing layer. <del> This format provides an alternative to the "message/http" content type defined in MESSAGING.  A binary format permits more efficient encoding and processing of messages.  A binary format also reduces exposure to security problems related to processing of HTTP messages. </del> <ins> This format defines "message/bhttp", a binary alternative to the "message/http" content type defined in MESSAGING.  A binary format permits more efficient encoding and processing of messages.  A binary format also reduces exposure to security problems related to processing of HTTP messages. </ins> Two modes for encoding are described:

Related discussion:
text: Sounds like a good idea to me.
from the editor's copy >7. "message/bhttp" Media Type The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. is this a typo and it should be >The message/bhttp media type ? Also defining this type at section 7 seems quite late. The first instance of is in examples in section 5, easily missed due to the similarity and prevalence of that is mentioned as a contrasting type. I think it would help a bit to talk about the bhttp type earlier. Probably in the introduction, just after you talk about the old type.
LGTM thank you
Code change:
digest values as defined in representation-digest.  It can be used in both requests and responses. <ins> For example: </ins> The relationship between "Content-Location" (see Section 8.8 of SEMANTICS) and "Digest" is demonstrated in post-not-request-uri.  A comprehensive set of examples showing the impacts of representation

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:
This specification uses the terms "Holder", "Issuer", "Verifier", defined by I-D.ietf-oauth-selective-disclosure-jwt, Verifiable <del> Credential and Verifiable Presentation defined by VC-DATA. </del> <ins> Credential defined by VC-DATA. </ins> 2.

Related discussion:
text: Removes VP terms; changes language around VPs and presentation of VCs; -
NAME gave verbal approval.
Discuss better term than VP-SD-JWTs. VP-SD-JWTs could be an acronym for the above.
I think the term VP-SD-JWT and especially the media type vp+sd-jwt are not appropriate there is no distinct element in SD-JWT that is "THE" VP. I suggest to change the wording to "presentation of a vc-sd-jwt" and drop the media type.
The OpenID4VP spec refers to Verifiable Presentations in the vp_token. Wouldn't it make sense to stick to that terminology? This will allow us to use VP-SD-JWTs more seamlessly with other specs. Would you agree?
That's a good question. I just checked and we don't use the term Verifiable Presentation in conjunction with mdoc. So I think we don't need to use it here either.
Perhaps we should create an issue in OpenID4VP to make it more clear what can be included in the vp_token?
So, this means we will not focus on verifiable presentations at all. We would only speak about presentations of VCs. Is this correct?
Code change:
5.1. This specification introduces a new parameter in the "WWW- <del> Authenticate" response to indicate the resource identifier of the protected resource: </del> <ins> Authenticate" response to indicate the protected resource metadata URL: </ins> <del> The resource identifier of the protected resource. </del> <ins> The URL of the protected resource metadata. </ins> The HTTP status code and error string in the response are defined by RFC6750. <del> The issuer parameter MAY be combined with other parameters defined in other extensions, such as the "max_age" parameter defined by RFC9470. </del> <ins> The "resource_metadata" parameter MAY be combined with other parameters defined in other extensions, such as the "max_age" parameter defined by RFC9470. </ins> 5.2. At any point, for any reason determined by the protected resource, the protected resource MAY respond with a new "WWW-Authenticate" <del> challenge that includes a value for the resource identifier to indicate that its metadata MAY have changed.  If the client receives such a "WWW-Authenticate" response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </del> <ins> challenge that includes a value for the protected resource metadata URL to indicate that its metadata MAY have changed.  If the client receives such a "WWW-Authenticate" response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained.  Among other things, this enables a resource server to change which authorization servers it uses without any other coordination with clients. </ins> 5.3.

Related discussion:
text: Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.