jiebi/CodeConvo huggingface dataset:
Change:
GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles. <ins> This specification focuses on the portions of the delegation process facing the client instance.  In particular, this specification defines interoperable methods for a client instance to request, negotiate, and receive access to information facilitated by the authorization server.  This specification also discusses discovery mechanisms for the client instance to configure itself dynamically. The means for an authorization server and resource server to interoperate are discussed in the companion document, I-D.draft-ietf- gnap-resource-servers. </ins> The focus of this protocol is to provide interoperability between the different parties acting in each role, and is not to specify implementation details of each.  Where appropriate, GNAP may make

Discussion:
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 3259334e2eec3bc29ead34a917ce3a579ca3cfe5 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
client requests to RS w/o access token should be covered in core (client-facing protocol) See also
Requesting a Resource With Insufficient Access: Editor's note: This borrows heavily from UMA 2's "distributed authorization" model and, like UMA, might be better suited to an extension than the core protocol.
I'm in favour of this being in the core protocol. I don't think it adds that much complexity and it opens up a whole world of different deployment options.
First, the sentence at the top of this section is broken: . Second, I think this is a complicated decision: The RC is more likely to assume it will receive a useful response if this is in the core document rather than an extension. There may be privacy issues with the RS reporting the AS URI for a particular resource. Which would argue against including it in the core protocol.
It is definitely something that would be hard to make "mandatory to implement". I would like to see it included but not mandated for all deployments.
Yaron: 3.4: "updated_at": Unix time is nice, but for absolute time it's common to use ISO 8601 format. Justin: I stole this field from OIDC, but I’m fine with any format here, so if there’s no outcry we should change it in the next revision.
This has been changed to ISO 8601 format in 7d6c4580a11f2cd352d67121c8eeb68326b3d009
Change:
either party of a TLS connection.  It can be transmitted to the other party of the TLS connection at the application layer.  The application layer protocol used to send the authenticator SHOULD use <del> TLS as its underlying transport to keep the certificate confidential. The application MAY use the existing TLS connection to transport the </del> <ins> TLS or a protocol with comparable security properties as its underlying transport to keep the certificate confidential.  The application MAY use the existing TLS connection to transport the </ins> authenticator. An authenticator message can be constructed by either the client or

Discussion:
A reference QUIC would also need to be added to the references section If it's an informative draft maybe not a thing, but if it's a normative reference then this draft will sit in the queue until QUIC transport gets published. Maybe that's okay, but just an FYI.
I may be missing some follow-on discussions, but: Ben suggested that we mention that QUIC is also an option, even if informatively, in addition to the “SHOULD use TLS” statement. I think we left my question re: back-fitting this protocol into the IANA TLS registry open. Quoting: YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Request! I think it's a really bad idea. Better to hack special support to existing libraries, allowing this specific extension for this special case, than to change the base protocol. Otherwise, this document should UPDATE 8446. NS: This is a good point and one that we struggled a bit with during design. We needed to allow SNI in the CertificateRequest message because it can be client-generated in this context. I'd be ok with creating a different extension for this, but it's rather elegant to re-use it in this context. I'd like to hear some opinions from the working group on this point BK: Or, since extension codepoints are cheap, just use a new codepoint.
Addressed by .
Change:
This document <del> 11.2. </del> <ins> 9.2. </ins> The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM:

Discussion:
Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.
Change:
JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer API.  The <del> application then uses that offer to set up its local config via the setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </del> <ins> application then uses that offer to set up its local configuration via the setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </ins> To complete the offer/answer exchange, the remote party uses the createAnswer API to generate an appropriate answer, applies it using

Discussion:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.
Change:
An ACME account resource represents a set of metadata associated with an account.  Account resources have the following structure: <del> The public key of the account's key pair, encoded as a JSON Web Key object RFC7517.  The client may not directly update this field, but must use the key-change resource instead. </del> The status of this account.  Possible values are: "valid", "deactivated", and "revoked".  The value "deactivated" should be used to indicate user initiated deactivation whereas "revoked"

Discussion:
The client knows what its public key is, because it has to have access to the private key in order to sign new-account requests or updates to the account resource. So this field serves no purpose.
Has this been discussed on list? I'm concerned that we're removing information that could be valuable for debugging client issues. There's no harm in keeping this; the server has to store this information anyway.
Yep, this was discussed on-list. I can say that as a client developer, I've never found this field useful. Clients need to be able to successfully serialize a jwk in order to speak the protocol. Also, I have no objection to servers including this as an extra field, but it seems wrong to normatively require it when it serves no purpose.
For the record where it was available for discussion. For me, the observation that you need the private key to get an account object is dispositive. There's not even debugging utility here. So I'm OK to merge. Right now, account objects echo back the public key associated with the account, in the "key" field. However, this is redundant since the only request types that can return an account object are signed by the corresponding private key, so the client necessarily knows what its public key is. Removing this simplifies the spec somewhat. URL Thoughts?
Change:
The protocol must ensure interoperability by specifying a single format for requests and responses that is mandatory to implement. That format must be able to support future modifications to the <del> DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </del> <ins> DNS protocol including the inclusion of one or more EDNS options (including those not yet defined). </ins> The protocol must use a secure transport that meets the requirements for HTTPS.

Discussion:
NAME my previous (deleted now) comment was in error in case you get a copy of that in email. sorry - git skillz failure on my part.
Change:
order. Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, and the header. </del> <ins> bhttp request", a zero byte, and the header.  Note: repurposing discusses how alternative message formats might use a different "info" value. </ins> Create a sending HPKE context by invoking "SetupBaseS()" (HPKE) with the public key of the receiver "pkR" and "info".  This yields

Discussion:
This adds a little structure to the section on encapsulation and tries to make the relationship between different media types more distinct. This builds on top of (which we are going to merge soon) because that hits all the same text and we have already effectively agreed to those changes. You can review to see what the substance of these changes are. Alternatively, just look at the top of the "HPKE Encapsulation" section (the other changes are unrelated).
I spent some time being confused because (content type) and (the hpke info tag) are so similar. Is it possible to align these two? Section 9, Repurposing the Encapsulation Format, mentions changing the hpke info for other protocols, so I suppose is re-using the content-type from the binary http draft at this layer, while the outer Content-Type is specific to this draft's application? I can see the logic there, but some clarifying text about the two being different would have been helpful.
We kept them separate because they refer to different things. The "message/ohttp-req" content type refers to the type of HTTP request sent from client to gateway, whereas the "message/bhttp request" content type refers to the type of content that's encapsulated to the gateway. We can probably improve this distinction in the text. Thanks for flagging this.
I did a little rewriting of some of the key framing text for another issue, does the following help at all? URL
The new references to the repurposing section in that commit are helpful. The extra wording you linked doesn't help much I think. It's confusing that the both encapsulates a and is called an 'encapsulated request/response'. So when you say, the word 'contains' is ambiguous: is it that the directly contains the binary HTTP message, or is that the HPKE AEAD contains the binary HTTP message? I understand it's the second one, but on first reading this kind of layer confusion was hard to keep track of. Maybe something about the media type containing the encrypted message along with the necessary parameters to convey the encapsulation would help?
I took a swing at this in . Am I getting closer?
Change:
request with the original, and by now already validated, Registrar voucher-request so as to avoid an extra crypto validation. <ins> Rather than returning the audit log as a response to the POST (with a return code 200), the MASA MAY instead return a 201 ("Created") RESTful response (RFC7231 section 7.1) containing a URL to the prepared (and easily cachable) audit response. MASA servers that return URLs SHOULD take care to make the returned URL unguessable.  URLs containing a database number such as https://example.com/auditlog/1234 or the EUI of the device such https://example.com/auditlog/10-00-00-11-22-33, would be easily enumerable by an attacker.  It is recommended put to put some meaningless randomly generated slug that indexes a database instead. A MASA that returns a code 200 MAY also include a Location: header for future reference by the Registrar. </ins> The request media type is: The request is a "YANG-defined JSON document that has been signed

Discussion:
Proposes 201/Location: operation optional for /requestauditlog end-point.
Think we should discuss.
Change:
The payload of a packet that contains frames MUST contain at least one frame, and MAY contain multiple frames and multiple frame types. <del> Frames always fit within a single QUIC packet and cannot span multiple packets. </del> <ins> An endpoint MUST treat receipt of a packet containing no frames as a connection error of type PROTOCOL_VIOLATION.  Frames always fit within a single QUIC packet and cannot span multiple packets. </ins> Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields:

Discussion:
Sec 12.4 says: There is no specification of error handling in the case of zero frame. I would like to know what kind of error MUST be sent. Also, the packet formats contains the following field: Should we change this to the following?
Change:
The string "dns-01" A random value that uniquely identifies the challenge.  This value <del> MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </del> <ins> MUST have at least 128 bits of entropy.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and

Discussion:
Per feedback from Zach Shepherd[0] on the mailing list the justification for the 128 bits of required token entropy from section 8.2 is at odds with the actual rationale (as I understand it). This commit updates the justification for the entropy requirement to not mention being secret from an attacker, but instead not predictable by a naive challenge response server that would complete challenges without having been a party to the authz/chal creation.
It seems like whatever change is made should be applied to sections 8.2, 8.3, and 8.4.
Based on zjs' feedback, I think it makes more sense for the individual token fields to just say "MUST have 128 bits", and explain why in one place in the Security Considerations section.
NAME NAME Updated. Thanks for the feedback!
Change:
11. <ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, or Endorsements, or Appraisal Policy, needs to support end- to-end integrity protection and replay attack prevention, and often also needs to support additional security protections.  For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust, e.g., whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM. It is also important that the Appraisal Policy was itself obtained securely.  As such, if Appraisal Policy in a Relying Party or Verifier can be configured via a network protocol, the ability to attest to the health of the client providing the Appraisal Policy needs to be considered. </ins> 12. This document does not require any actions by IANA.

Discussion:
Incorporates both text from birkholz arch draft and thaler arch draft. Avoids using normative language per IETF 106 discussion. Signed-off-by: Dave Thaler
The Birkholz draft had the idea of roles to describe higher level concepts (independent of transport layer security considerations). It also defined "Actors" that focused on trust model relationships (and their fungibility). Also a higher-layer concept from transport layer security considerations. Each section in the arch spec addresses security considerations appropriate for the level of abstraction. Maybe this security considerations is aimed at transport level security considerations?
Change:
ACP domain certificates MUST be RFC5280 compliant X.509 certificates. ACP nodes MUST support RSA and Elliptic Curve (ECC) public keys in <del> ACP certificates.  ACP certificates wth ECC keys MUST indicate to be </del> <ins> ACP certificates.  ACP certificates with ECC keys MUST indicate to be </ins> Elliptic Curve Diffie-Hellman capable (ECDH) if X.509 v3 keyUsage and extendedKeyUsage are included in the certificate.

Discussion:
I've done some slight editing of your text for readability. I have removed text that is repeating RFC8247 and RFC8221 poorly, leveraging those documents better. I have made a change to say that trust anchor certificates should be sent. (Believe me, without that, it makes debugging really difficult)
Change:
Proxies MUST NOT introspect the contents of UDP payloads as that would lead to ossification of UDP-based protocols by proxies. <del> 7. </del> <ins> 8. </ins> <del> 7.1. </del> <ins> 8.1. </ins> This document will request IANA to register "connect-udp" in the HTTP Upgrade Token Registry maintained at

Discussion:
This is one potential design for the identifier at the start of the CONNECT-UDP datagram payload. Note that this PR is against the design team consensus branch, not main. . .
During the HTTP Datagrams Design Team meeting on 2022-01-20, we reached consensus to move forward with the dynamic approach, so I'm merging this PR.
Change:
Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to <del> indicate no set upper limit; values in this format always end on an byte boundary </del> <ins> indicate no set upper limit; values in this format always end on a byte boundary </ins> Indicates that x, with a length described by L, has a fixed value of C

Discussion:
Draft 34 changed notation from "octet" to "byte" in a few places, but forgot to change the article in two places.
Thanks, NAME
Change:
bytes in length.  Connection IDs are described in connection-id. The next byte contains the length in bytes of the Source Connection <del> ID field that follows it.  This length is encoded as a 8-bit unsigned integer.  The Source Connection ID field follows the Source </del> <ins> ID field that follows it.  This length is encoded as an 8-bit unsigned integer.  The Source Connection ID field follows the Source </ins> Connection ID Length field and is between 0 and 255 bytes in length. The remainder of the packet contains version-specific content.

Discussion:
My WGLC feedback for -invariants is mostly nits, so I figured I'd go straight to a PR. There's one piece of this that might be non-editorial; feel free to kick to an issue if you prefer. In one section, we say that different versions "might" define authentication for VN packets. Later, we say that QUIC versions MUST define such a mechanism. Resolving in favor of the MUST, I've changed the other occurrence to a more definitive statement that QUIC versions do so.
Thanks Mike.
Change:
Source Address Validation: The handshake protocol may delegate validation of the remote peer that has sent data to the transport protocol or application.  This involves sending a cookie exchange <del> to avoid DoS attacks.  Protocols: QUIC + TLS, DTLS, WireGuard </del> <ins> to avoid DoS attacks. </ins> DTLS QUIC <ins> IKEv2 </ins> WireGuard 5.3.

Discussion:
Addresses
Comment from Ekr's review of -10: S 5.2. IKE has source address validation, no?
Right! I'll change that in my summary table in .
Change:
5.4. <ins> Side-channel attacks, such as those based on timing correlation, could be used to link attestation and redemption contexts together. In particular, for interactive tokens that are bound to a Client- specific redemption context, the anonymity set of Clients during the issuance protocol consists of those Clients that started issuance between the time of the Origin's challenge and the corresponding token redemption.  Depending on the number of Clients using a particular Issuer during that time window, the set can be small. Appliations should take such side channels into consideration before choosing a particular deployment model and type of token challenge and redemption context. 6. </ins> A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization amongst those participants.{

Discussion:
cc NAME NAME
The privacy considerations section should probably include a discussion on timing correlation. The timing issues are non-trivial here; in particular, in the scenarios where the token is issued online in response to a token challenge (which is suggested in all of the diagrams, and which is required if the origin requires session-bound tokens). In that case, the anonymity set of issuance flows that could match a redemption flow is limited to those that started after the challenge was sent and ended before the token was redeemed. Even if process takes a second (which seems slow to me), you need a fairly popular issuer service to get a non-trivial anonymity set, and any (obviously desirable) improvements in the latency of this process put further pressure on the anonymity set. I think there should be a caution against deploying PrivacyPass in a setting where the issuance rate can be low, at least in combination with session-bound context.
This is a good suggestion! I proposed text that adds this under the privacy considerations section.
Change:
An HTTP message (request or response) consists of: <del> the header field section, sent as a single HEADERS frame (see frame-headers), </del> <ins> the header section, sent as a single HEADERS frame (see frame- headers), </ins> optionally, the content, if present, sent as a series of DATA frames (see frame-data), and <del> optionally, the trailer field section, if present, sent as a single HEADERS frame. </del> <ins> optionally, the trailer section, if present, sent as a single HEADERS frame. </ins> <del> Header and trailer field sections are described in Sections 6.3 and 6.5 of SEMANTICS; the content is described in Section 6.4 of SEMANTICS. </del> <ins> Header and trailer sections are described in Sections 6.3 and 6.5 of SEMANTICS; the content is described in Section 6.4 of SEMANTICS. </ins> Receipt of an invalid sequence of frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED; see errors.  In

Discussion:
HTTP Semantics refers to the field sections used at particular locations using terms "header section" and "trailer section." However, the HTTP/3 draft sometimes calls them "header field section" and "trailer field section." This PR addresses the inconsistency. It also fixes one instance "fields section."
NAME Of course I did (not). Done in 18c0242.
Have you checked to make sure QPACK matches as well?