jiebi/CodeConvo huggingface dataset:
Code change:
I strongly think that all 10 EDHOC-KDF should be in the same table The text about maclengthx need to use the defined term hash_length
I made one commit for review.

Related discussion:
text: (method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then <del> mac_length_3 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del> <ins> mac_length_3 is equal to hash_length. </ins> ID_CRED_I - identifier to facilitate the retrieval of CRED_I, see
Code change:
This builds on .
Summary: use a high-entropy PSK with DH, otherwise, with a low-entropy PSK, use a PAKE. Reference appendix with security properties from NAME

Related discussion:
text: 4. <del> Applications MUST use external PSKs that adhere to the following requirements: Each PSK MUST be derived from at least 128 of entropy and MUST be at least 128-bits long unless the TLS handshake is being used with a separate key establishment mechanism such as a Diffie-Hellman exchange.  This recommendation protects against passive attacks using exhaustive search of the PSK. </del> <ins> Applications MUST adhere to the following requirements for external PSKs: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a
Code change:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Related discussion:
text: violated, then the security properties of TLS are severely weakened. As discussed in use-cases, there are use cases where it is desirable <del> for multiple clients or multiple servers share a PSK.  If this is </del> <ins> for multiple clients or multiple servers to share a PSK.  If this is </ins> done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious
Code change:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Related discussion:
text: appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when <del> using external PSKs if these risks. </del> <ins> using external PSKs to mitigate these risks. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can
Code change:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Related discussion:
text: constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. <del> Some devices are provisioned PSKs via an out-of-band, cloud-based </del> <ins> Some devices provision PSKs via an out-of-band, cloud-based </ins> syncing protocol. Some secrets may be baked into or hardware or software device
Code change:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Related discussion:
text: Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH <del> exchange for forward secrecy.  Low entropy PSKs, i.e., those derived from less than 128 bits of entropy, MUST be combined with a Password Authenticated Key Exchange (PAKE) mechanism. </del> <ins> exchange for forward secrecy.  As discussed in sec-properties, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided.  Low entropy keys are only secure against active attack if a Password Authenticated Key Exchange (PAKE) is used with TLS. </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a
Code change:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Related discussion:
text: 6.1. <del> Most major TLS implementations support external PSKs.  And all have a common interface that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </del> <ins> Most major TLS implementations support external PSKs.  Stacks supporting external PSKs provide interfaces that applications may use when supplying them for individual connections.  Details about existing stacks at the time of writing are below. </ins> OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites.  They also then configure callbacks that are invoked for PSK selection during the handshake. <del> These callbacks must provide a PSK identity (as a character string) and key (as a byte string).  (If no identity is provided, a default one is assumed.)  They are typically invoked with a PSK hint, i.e., the hint provided by the server as per RFC4279.  The PSK length is validated to be between [1, 256] bytes upon selection. </del> <ins> These callbacks must provide a PSK identity and key.  The exact format of the callback depends on the negotiated TLS protocol version with new callback functions added specifically to OpenSSL for TLS 1.3 RFC8446 PSK support.  The PSK length is validated to be between [1, 256] bytes.  The PSK identity may be up to 128 bytes long. </ins> mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. <del> Servers must implement callbacks similar to that of OpenSSL.  PSK lengths are validate to be between [1, 16] bytes. </del> <ins> Servers must implement callbacks similar to that of OpenSSL.  Both PSK identity and key lengths may be between [1, 16] bytes long. </ins> gnuTLS: Applications configure PSK values, either as raw byte <del> strings or hexadecimal strings.  The PSK size is not validated. </del> <ins> strings or hexadecimal strings.  The PSK identity and key size are not validated. </ins> wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.
Code change:
FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME

Related discussion:
text: Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. <del> [[OPEN ISSUE: discuss implication of collisions between external and resumption PSKs.]] </del> <ins> 6.1.2. It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK. </ins> 7.
Code change:
Ah, I see now. I think what would help is "in contrast to methods like RTX or flexfec (when retransmissions are used) [I-D.]"

Related discussion:
text: indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used.  This is in contrast to methods <del> like RTX RFC4588 or flexfec I-D.ietf-payload-flexible-fec-scheme retransmissions, which only transmit redundant data when necessary, at the cost of an extra roundtrip. </del> <ins> like RTX RFC4588 or flexfec's retransmission mode ( I-D.ietf-payload- flexible-fec-scheme, Section 1.1.7), which only transmit redundant data when necessary, at the cost of an extra roundtrip. </ins> Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low, and SHOULD
Code change:
It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.

Related discussion:
text: This approach, as described in RFC2198, allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous <del> packet, or for codecs that support variable-bitrate encodings, </del> <ins> payload, or for codecs that support variable-bitrate encodings, </ins> possibly a smaller, lower-quality representation.  In certain cases, <del> the redundant data could include multiple prior packets. </del> <ins> the redundant data could include encodings of multiple prior audio frames. </ins> Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant
Code change:
It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.

Related discussion:
text: Some audio codecs, notably Opus RFC6716 and AMR RFC4867, support their own in-band FEC mechanism, where redundant data is included in <del> the codec payload. </del> <ins> the codec payload.  This is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient. </ins> <del> For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery </del> <ins> For Opus, audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery </ins> of a lost packet.  This scheme is fairly efficient; experiments performed indicate that when Opus FEC is used, the overhead imposed <del> is about 20-30%, depending on the amount of protection needed.  Note that this mechanism can only carry redundancy information for the immediately preceding packet; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </del> <ins> is only about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </ins> For AMR/AMR-WB, packets can contain copies or lower-quality encodings <del> of multiple prior audio frames.  This mechanism is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, Section 3.7.1 for details on this mechanism. </del> <ins> of multiple prior audio frames.  See RFC4867, Section 3.7.1 for details on this mechanism. </ins> In-band FEC mechanisms cannot recover any of the RTP header.
Code change:
It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.

Related discussion:
text: Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described <del> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1, as an </del> <ins> in I-D.ietf-payload-flexible-fec-scheme, Section 5.1.2, as an </ins> additional supported media type for the associated m= section in the SDP offer RFC3264.  As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group,
Code change:
The discovery fields for the interaction methods were still in a single list, even though those have now been split into start and finish sections.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 754d971b07753b2b9580c2c6f0b3c8997c34b260 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Yes, makes sense

Related discussion:
text: result MAY be used by the client instance in the request- capabilities of the request. <del> OPTIONAL.  A list of the AS's interaction methods.  The values of this list correspond to the possible fields in the request- interact of the request. </del> <ins> OPTIONAL.  A list of the AS's interaction start methods.  The values of this list correspond to the possible values for the request-interact-start of the request. OPTIONAL.  A list of the AS's interaction finish methods.  The values of this list correspond to the possible values for the method element of the request-interact-finish of the request. </ins> OPTIONAL.  A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the
Code change:
remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now

Related discussion:
text: Mutual TLS certificate verification <del> OAuth Demonstration of Proof-of-Possession key proof header </del> HTTP Signing signature header OAuth PoP key proof authentication header
Code change:
remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now

Related discussion:
text: 7.3.4. <del> This method is indicated by "dpop" in the "proof" field.  The signer creates a Demonstration of Proof-of-Possession signature header as described in I-D.ietf-oauth-dpop section 2.  In addition, this specification defines the following fields to be added to the DPoP payload: Digest of the request body as the value of the Digest header defined in RFC3230.  When a request contains a message body, such as a POST or PUT request, this field is REQUIRED. In this example, the request body is the following JSON object: ~~~ { "access_token": { "access": [ "dolphin-metadata" ] }, "interact": { "start": ["redirect"], "finish": { "method": "redirect", "uri": "https://client.foo/callback", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }, "client": { "proof": "dpop", "key": { "jwk": { "kid": "gnap-rsa", "kty": "RSA", "e": "AQAB", "alg": "RS256", "n": "hYOJ- XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_ 3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ" } } "display": { "name": "My Client Display Name", "uri": "https://client.foo/" }, } } ~~~ The JOSE header contains the following parameters, including the public key: The JWS Payload contains the following JWT claims, including a hash of the body: This results in the following full HTTP message request: The verifier MUST parse and validate the DPoP proof header as defined in I-D.ietf-oauth-dpop.  If the HTTP message request includes a message body, the verifier MUST calculate the digest of the body and compare it to the "htd" value.  The verifier MUST ensure the key presented in the DPoP proof header is the same as the expected key of the signer. 7.3.5. </del> This method is indicated by "httpsig" in the "proof" field.  The sender creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures.
Code change:
remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now

Related discussion:
text: The verifier MUST validate the signature against the expected key of the signer. <del> 7.3.6. </del> <ins> 7.3.5. </ins> This method is indicated by "oauthpop" in the "proof" field.  The signer creates an HTTP Authorization PoP header as described in I-
Code change:
The boolean value "true" is no longer used to specify supported interaction start modes.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ef948b6b0b53f92352ec617e6074174e0a2eaa3f Inspect the deploy log: Browse the preview:

Related discussion:
text: If the client instance is capable of directing the end-user to a URL defined by the AS at runtime, the client instance indicates this by <del> sending the "redirect" field with the boolean value "true".  The means by which the client instance will activate this URL is out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end-user's device, providing a scannable image encoding, and printing out a URL to an interactive console.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the AS grant URL. </del> <ins> including "redirect" in the array under the "start" key.  The means by which the client instance will activate this URL is out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end-user's device, providing a scannable image encoding, and printing out a URL to an interactive console. While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the AS grant URL. </ins> If this interaction mode is supported for this client instance and request, the AS returns a redirect interaction response response-
Code change:
The boolean value "true" is no longer used to specify supported interaction start modes.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ef948b6b0b53f92352ec617e6074174e0a2eaa3f Inspect the deploy log: Browse the preview:

Related discussion:
text: If the client instance can open a URL associated with an application on the end-user's device, the client instance indicates this by <del> sending the "app" field with boolean value "true".  The means by </del> <ins> including "app" in the array under the "start" key.  The means by </ins> which the client instance determines the application to open with this URL are out of scope of this specification.
Code change:
The boolean value "true" is no longer used to specify supported interaction start modes.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ef948b6b0b53f92352ec617e6074174e0a2eaa3f Inspect the deploy log: Browse the preview:

Related discussion:
text: If the client instance is capable of displaying or otherwise communicating a short, human-entered code to the RO, the client <del> instance indicates this by sending the "user_code" field with the boolean value "true".  This code is to be entered at a static URL that does not change at runtime.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its </del> <ins> instance indicates this by including "user_code" in the array under the "start" key.  This code is to be entered at a static URL that does not change at runtime.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its </ins> contents, composition, or relationship to the AS grant URL. If this interaction mode is supported for this client instance and
Code change:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:

Related discussion:
text: as far as the overall protocol is concerned. A single role need not be deployed as a monolithic service.  For <del> example, A client instance could have components that are installed </del> <ins> example, a client instance could have components that are installed </ins> on the end user's device as well as a back-end system that it communicates with.  If both of these components participate in the delegation protocol, they are both considered part of the client