jiebi/CodeConvo huggingface dataset:
Code change:
fields (e.g., "Alt-Svc" RFC7838, "Strict-Transport-Security" RFC6797). <del> Classic HTTP CONNECT proxies can be used to reach a target host that is specified as a domain name or an IP address.  However, because only a single target host can be specified, proxy-driven Happy Eyeballs and cross-IP fallback can only be used when the host is a domain name.  For IP-targeted requests to succeed, the client must know which address families are supported by the proxy via some out- of-band mechanism, or open multiple independent CONNECT requests and abandon any that prove unnecessary. </del> 1.3. This specification describes an alternative mechanism for proxying

Related discussion:
text: It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).
In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.
Thanks for the updates based on the discussion at 119
Code change:
verify that requested scopes are not higher priveleged than the scopes of presented subject_token. <del> 2.3.6. </del> <ins> 2.3.5. </ins> All of section 2.2 of RFC8693 applies.  In context of this specification the following applies in addtion:

Related discussion:
text: parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details
Code change:
idle connection is still functional.  PING frames can be sent from any endpoint. <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer. </ins> In addition to the frame header, PING frames MUST contain 8 octets of opaque data in the frame payload.  A sender can include any value it chooses and use those octets in any fashion.

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
As part of the signature verification, the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of <del> use.. </del> <ins> use. </ins> <del> Guidance is illustrated in RFC3161 via an example that shows how timestamp tokens can be used during signature verification of a timestamped message when using X.509 certificates. </del> <ins> RFC3161 provides an example that illustrates how timestamp tokens can be used to verify signatures of a timestamped message when utilizing X.509 certificates. </ins> <del> 4. </del> <ins> 5. </ins> The security considerations made in RFC3161 as well as those of RFC9338 apply. <del> 5. </del> <ins> 6. </ins> <del> IANA is requested to add the COSE Header parameter described in sec- tst-hdr to the "COSE Header Parameters" of the IANA.cose registry. </del> <ins> IANA is requested to add the two COSE Header parameters described in sec-tst-hdr to the "COSE Header Parameters" of the IANA.cose registry. </ins>

Related discussion:
text: See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat
Code change:
In all of the attack scenarios listed above, a user is tricked or exploited.  For other attacks, where the user is willingly colluding <del> with the attacker, the security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on their device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to trick proximity checks. </del> <ins> with the attacker, the threat model, security implications and potential mitigations are very different.  For example, a cooperating user can bypass software mitigations on their device, share access to hardware tokens with the attacker, and install additional devices to forward radio signals to circumvent proximity checks. </ins> This document only considers scenarios where a user does not collude with an attacker.

Related discussion:
text: Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!
Code change:
6.3. <del> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI. </del> <ins> An endpoint sends a "GOAWAY" message to inform the peer it intends to close the session soon.  Servers can use GOAWAY to initiate session migration (session-migration) with an optional URI. </ins> <del> The server MUST terminate the session with a Protocol Violation (session-termination) if it receives a GOAWAY message.  The client MUST terminate the session with a Protocol Violation (session- termination) if it receives multiple GOAWAY messages. </del> <ins> The GOAWAY message does not impact subscription state.  A subscriber SHOULD individually UNSUBSCRIBE for each existing subscription, while a publisher MAY reject new requests while in the draining state. </ins> <del> New Session URI: The client MUST use this URI for the new session if provided.  If the URI is zero bytes long, the current URI is reused instead.  The new session URI SHOULD use the same scheme as the current URL to ensure compatibility. </del> <ins> Upon receiving a GOAWAY, an endpoint SHOULD NOT initiate new requests to the peer including SUBSCRIBE, FETCH, ANNOUNCE and SUBSCRIBE_ANNOUNCE. The endpoint MUST terminate the session with a Protocol Violation (session-termination) if it receives multiple GOAWAY messages. New Session URI: When received by a client, indicates where the client can connect to continue this session.  The client MUST use this URI for the new session if provided.  If the URI is zero bytes long, the client can reuse the current URI is reused instead.  The new session URI SHOULD use the same scheme as the current URL to ensure compatibility. If a server receives a GOAWAY with a non-zero New Session URI Length it MUST terminate the session with a Protocol Violation. </ins> 6.4.

Related discussion:
text: My current thinking is that GOAWAY is useful for all publishers, even if they're 'clients' (ie: an original publisher). It also seems useful if an original publisher is publishing to an ingestion server that is about to restart and the server wants to cause them to connect to a different ingestion server. I don't have a clear use for the end subscriber sending a GOAWAY, but it also doesn't seem particularly harmful.
I think you missed a few spots to update (suggestions made), but maybe you intentionally left those as is?
Code change:
described in RFC4861. Support for adjacent infrastructure links on networks where Neighbor <del> Discovery is not supported are out of scope for this document.  Stub routers do not provide routing between adjacent infrastructure links when connected to more than one such link. </del> <ins> Discovery is not supported and is out of scope for this document. Stub routers do not provide routing between adjacent infrastructure links when connected to more than one such link. </ins> 5.1.

Related discussion:
text: AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?
Code change:
The "@status" identifier MUST NOT be used in a request message. <ins> 2.3.11. When a signed request message results in a signed response message, the "@request-response" identifier can be used to cryptographically link the request and the response to each other by including the identified request signature value in the response.  This identifier has a single REQUIRED parameter: Identifies which signature from the response to sign. The value is the "sf-binary" representation of the signature value of the referenced request identified by the "key" parameter. For example, when serving this signed request: This would result in the following unsigned response message: The server signs the response with its own key and includes the signature of "sig1" from the request in the signed content of the response.  The signature input string for this example is: The signed response message is: 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. The "@request-response" identifier MUST NOT be used in a request message. </ins> 2.4. The signature input is a US-ASCII string containing the content that

Related discussion:
text: This creates a mechanism to cryptographically bind a response to its associated request by letting the responder sign the signature value of the request, and the requester validate the signature based on their original request's signature.
Code change:
The "type" value is optional and defaults to "raw". <del> 2.1.6. </del> <ins> 2.1.7. </ins> <del> 2.1.6.1. </del> <ins> 2.1.7.1. </ins> A response that contained a response header:

Related discussion:
text: This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!
Code change:
3.3. <del> RUSH uses its own frame types on top of QUIC as it pre-dates the datagram specification; in addition individual media frames are given their own stream identifiers to remove HoL blocking from processing out-of-order. </del> <ins> Whilst RUSH predates the datagram specification, it uses its own frame types on top of QUIC to take advantage of QUIC implementations reassembling messages greater than MTU.  In addition individual media frames are given their own stream identifiers to remove HoL blocking from processing out-of-order. </ins> It defines its own registry for signalling codec information with room for future expansion but presently is limited to a subset of

Related discussion:
text: Although it's true that RUSH predates DATAGRAM, streams were an intentional choice as RUSH implementations can leverage standard QUIC library reassembly of messages longer than one MTU.
Absolutely. It's disingenuous to say that RUSH is using QUIC streams because QUIC datagrams didn't exist yet. QUIC streams provide fragmentation, reliability, flow control, and cancellation (error codes). In fact, you could (but shouldn't) use QUIC streams to deliver individual RTP packets without much downside.
The above commits should fix this, please let me know if I got it wrong.
Code change:
is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% markdown in quality". <del> A request without any Accept header field implies that the user agent will accept any media type in response.  If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a response or disregard the header field by treating the response as if it is not subject to content negotiation. </del> A more elaborate example is Verbally, this would be interpreted as "text/html and text/x-c are

Related discussion:
text: (alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.
Code change:
11.3. <del> When Relying Parties fetch the Status List, they need to be aware of its up-to-date status.  The 'ttl' (time-to-live) claim in the Status List Token provides one mechanism for setting a maximum cache time for the fetched data.  This property permits distribution of a Status List to a CDN or other distribution mechanism while giving guidance to consumers of the Status List on how often they need to fetch a fresh copy of the Status List even if that Status List is not expired. </del> <ins> When fetching a Status List Token, Relying Parties must carefully evaluate how long a Status List is cached for.  Collectively the "iat", "exp" and "ttl" claims when present in a Status List Token communicate how long a Status List should be cached and should be considered valid for.  The following diagram illustrates the relationship between these claims and how they are designed to influence caching. It is essential to understand the distinct purposes of the "ttl" and "exp" claims.  The "ttl" claim represents a duration to be interpreted relative to the time the Status List is fetched, indicating when a new version of the Status List may be available. In contrast, the "exp" claim specifies an absolute timestamp, marking the point in time when the Status List expires and MUST NOT be relied upon any longer.  Together, these claims provide guidance on when to check for updates ("ttl" claim) and when the Status List must be refreshed or replaced ("exp" claim). </ins> 12.

Related discussion:
text: We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL
Code change:
be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc. <del> Issuers and Transparency Services MUST rotate verification keys for signature checking in well-defined cryptoperiods (see KEY- MANAGEMENT). </del> <ins> Issuers and Transparency Services MUST rotate their keys in well- defined cryptoperiods, see KEY-MANAGEMENT. </ins> A Transparency Service MAY provide additional authenticity assurances about its secure implementation and operation, enabling remote

Related discussion:
text: I generalized the description. You need to rotate all keys.
I don't have strong opinions about the MUST vs. SHOULD requirement here. The group will have to sort this out
Was wondering whether the cases where keys are never rotated are actually valid. The implication is the following: if an end-entity certificate has an indefinite lifetime then the certificates of the subordinate and CA certificates also need to have an indefinite lifetime. Is this a realistic deployment? If so, can you describe this deployment?
Sitting in the SUITS meeting, the same question of MUST came up. Someone made the comment that the MIST could be required in the doc, but the doesn’t mean a service that doesn’t follow the MIST guidance, can’t physically operate or even interop with other services. It would mean it’s not conformant to informative guidance, and a security review could seem it not as secure. Which might be fine for a locked down, IoT scenario. After the SUITS discussion, I’m fine with a MUST for operational info, that enables a service to function as they deem fit
Keeping with MUST as it doesn't change the compatibility, and a service that doesn't rotate would still be interoperable, and be operationally not compliant.
LGTM!removed the hyphen from cryptoperiodsApproving the MUST text.
Code change:
Several characteristics of HTTP/2 provide an observer an opportunity to correlate actions of a single client or server over time.  These <del> include the value of settings, the manner in which flow-control </del> <ins> include the values of settings, the manner in which flow-control </ins> windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings.

Related discussion:
text: Values is correct in the first case, but the second should be "a value" by which it means "any value".
and 10.9: Please confirm that these instances of "value" should not be "values". Original: These include the value of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. Possibly: These include the values of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on secret values is the best defense against any form of timing attack.
These should both be "values".
Values is correct in the first case, but the second should be "a value" by which it means "any value".
Code change:
<del> : organizations, stakeholders, and users involved in creating or </del> <ins> : organizations, consumers, and users involved in creating or </ins> attesting to supply chain artifacts, releasing authentic Statements to a definable set of peers

Related discussion:
text: LGTM, Thanks, NAME the stakeholders to consumers looks like a great change. I don't know if we'd keep both, or replace. I'll merge this to keep moving forward. Also, thanks for the catch on CBOR
Code change:
features, but that is not a requirement for it to be a Txn-Token Service. <del> Each Trust Domain MUST have exactly one logical Txn-Token Service. </del> <ins> Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. </ins> 7.

Related discussion:
text: Changed MUST to MAY. Cardinality of the txn-token service is 0..1, not exactly one. MAY not be the appropriate framing, I'm open to alternative text here to describe this more correctly.
I've updated the PR with the language provided by NAME in two places where the previous language was found in the draft.