jiebi/CodeConvo huggingface dataset:
Change:
To edit notification comments on pull requests, go to your .
NAME and NAME -- please check these additions to the implementation section.

Discussion:
12. implementation by David Skyberg.  https://github.com/dskyberg/gnap <del> [2].  Prototype implementation of AS and Client in Rust.  MIT license. </del> <ins> [2] Prototype implementation of AS and client in Rust.  MIT license. from Interop Alliance, implementation by Dmitri Zagidulin. https://github.com/interop-alliance/gnap-client-js [3] Prototype implementation of client in JavaScript.  MIT License. </ins> from Interledger Foundation. https://github.com/interledger/rafiki <del> [3] Production implementation of AS in JavaScript.  Apache 2.0 </del> <ins> [4] Production implementation of AS in JavaScript.  Apache 2.0 </ins> license. implementation by Aaron Parecki. https://github.com/aaronpk/gnap- <del> client-php [4] Prototype implementation of web application client and </del> <ins> client-php [5] Prototype implementation of web application client and </ins> CLI client in PHP, with common support library.  CC0 license. <del> from SUNET. https://github.com/SUNET/sunet-auth-server [5] Production </del> <ins> from SUNET. https://github.com/SUNET/sunet-auth-server [6] Production </ins> implementation of AS in Python.  BSD license. <ins> from SecureKey. https://verified.me/ [7] Production implementation of AS, client and RS.  Proprietary license. </ins> from Bespoke Engineering, implementation by Justin Richer. <del> https://github.com/bspk/oauth.xyz-java [6].  Advanced prototype implementation of AS, Client, and RS in Java, with common support library.  Prototype implementation of SPA Client in pure JavaScript. </del> <ins> https://github.com/bspk/oauth.xyz-java [8] Advanced prototype implementation of AS, client, and RS in Java, with common support library.  Prototype implementation of SPA client in JavaScript. </ins> Apache 2.0 license. 13.

[2] https://github.com/dskyberg/gnap <del> [3] https://github.com/interledger/rafiki </del> <ins> [3] https://github.com/interop-alliance/gnap-client-js [4] https://github.com/interledger/rafiki [5] https://github.com/aaronpk/gnap-client-php </ins> <del> [4] https://github.com/aaronpk/gnap-client-php </del> <ins> [6] https://github.com/SUNET/sunet-auth-server </ins> <del> [5] https://github.com/SUNET/sunet-auth-server </del> <ins> [7] https://verified.me/ </ins> <del> [6] https://github.com/bspk/oauth.xyz-java </del> <ins> [8] https://github.com/bspk/oauth.xyz-java </ins>
Change:
To edit notification comments on pull requests, go to your .
From the HTTP message sig spec : "tag: An application-specific tag for the signature as a String value. This value is used by applications to help identify signatures relevant for specific applications or protocols." Fair enough, but does a MUST requirement improve the security of the protocol ?
Yes, because it prevents cross-protocol confusion attacks. Where an attacker tries to use a signed HTTP message from another protocol in GNAP, or vice versa.
This was recently added to HTTP Signatures. Please add a standard value for GNAP messages.
LGTM

Discussion:
Other message components MAY also be included. <ins> The signer MUST include the "tag" signature parameter with the value "gnap", and the verifier MUST verify that the parameter exists with this value.  The signer MUST include the "created" signature parameter with a timestamp of when the signature was created, and the verifier MUST ensure that the creation timestamp is sufficiently close to the current time given expected network delay and clock skew.  The signer SHOULD include the "nonce" parameter with a unique and unguessable value.  When included, the verifier MUST determine that the nonce value is unique within a reasonably short time period such as several minutes. </ins> If the signer's key presented is a JWK, the "keyid" parameter of the signature MUST be set to the "kid" value of the JWK, the signing algorithm used MUST be the JWS algorithm denoted by the key's "alg"
Change:
To edit notification comments on pull requests, go to your .
Nothing more than yaron's feedback
From IETF115 comments: Change the default hash for interaction_hash to sha256, and change the MTI profile to use the same.
Please search for some remaining occurrences of "sha-512".

Discussion:
in the IANA Named Information Hash Algorithm Registry [1]. If the "hash_method" value is not present in the client instance's <del> request, the algorithm defaults to "sha3-512". </del> <ins> request, the algorithm defaults to "sha-256". </ins> <del> For example, the "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then </del> <ins> For example, the "sha-256" hash method consists of hashing the input string with the 256-bit SHA2 algorithm.  The byte array is then </ins> encoded using URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value. <del> The "sha2-512" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using </del> <ins> The "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using </ins> URL-Safe Base64 with no padding RFC4648.  The resulting string is the hash value.

This is explicitly defined as the signature algorithm specified by the associated key material and the content digest is calculated <del> using sha-512. </del> <ins> using sha-256. </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would

parameters are defined: This example uses the ECDSA signing algorithm over the P384 curve and <del> the SHA-256 hashing algorithm for the content digest. </del> <ins> the SHA-512 hashing algorithm for the content digest. </ins> When the proof method is specified in string form, the signing algorithm MUST be derived from the key material (such as using the JWS algorithm in a JWK formatted key), and the content digest <del> algorithm MUST be "sha-512". </del> <ins> algorithm MUST be "sha-256". </ins> When using this method, the signer creates an HTTP Message Signature as described in I-D.ietf-httpbis-message-signatures.  The covered
Change:
The current formulation regarding the client instance's validation of a pushed interaction completion notification can be misunderstood as "client instance must either parse JSON & verify hash or return an error", whereas I think the intended meaning is "client instance must parse JSON and verify hash. If either fails, return an error."
Built To edit notification comments on pull requests, go to your .

Discussion:
attacks as discussed in security-ssrf. When receiving the request, the client instance MUST parse the JSON <del> object and validate the hash value as described in interaction-hash, or else return an "unknown_interaction" error (response-error).  If the hash validates, the client instance sends a continuation request to the AS as described in continue-after-interaction using the interaction reference value received here. </del> <ins> object and validate the hash value as described in interaction-hash. If either fails, the client instance MUST return an "unknown_interaction" error (response-error).  If the hash validates, the client instance sends a continuation request to the AS as described in continue-after-interaction using the interaction reference value received here. </ins> 4.2.3.
Change:
type, - beit -> be it,
To edit notification comments on pull requests, go to your .
"beit" isn't a word, it should be "be it".
As I was reading through the latest version of the draft, I spotted a typo within section 2.1.1. It should says accesstoken object, not acccess_token object.

Discussion:
2.1.1. To request a single access token, the client instance sends an <del> "acccess_token" object composed of the following fields. </del> <ins> "access_token" object composed of the following fields. </ins> The values of the "flags" field defined by this specification are as follows:

13.22. During the interaction process, the client instance usually hands <del> control of the user experience over to another component, beit the </del> <ins> control of the user experience over to another component, be it the </ins> system browser, another application, or some action the resource owner is instructed to take on another device.  By using an interaction finish method, the client instance can be securely

a number of protocol elements that it needs to manage, including nonces, references, keys, access tokens, and other elements.  During the interaction process, the client instance usually hands control of <del> the user experience over to another component, beit the system </del> <ins> the user experience over to another component, be it the system </ins> browser, another application, or some action the resource owner is instructed to take on another device.  In order for the client instance to make its continuation call, it will need to recall all of
Change:
Built To edit notification comments on pull requests, go to your .
[I-D.ietf-uta-6125bis] " BROKEN REFERENCE ".

Discussion:
each time a new TLS connection is established, both the client and the server (or the server only when using mtls) have to validate the other party's identity.  Such a verification can be achieved via <del> methods described in I-D.ietf-uta-6125bis), but these are not enough to establish the identity of the client instance in many cases. </del> <ins> methods described in I-D.ietf-uta-rfc6125bis, but these are not enough to establish the identity of the client instance in many cases. </ins> To counter this, GNAP defines a set of key binding methods in binding-keys that allow authentication and proof of possession by the
Change:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 24fa4dc27f079697512f5eb15ca85b15f1c7ec62 https://deploy-preview-1--gnap-resource-servers-editors-URL

Discussion:
Grant Negotiation and Authorization Protocol Resource Server Connections <del> draft-ietf-gnap-resource-servers-latest </del> <ins> draft-ietf-gnap-resource-servers-00 </ins> Abstract

BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and other elements.  Some examples use a single trailing backslash '' to indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value. </ins> 2. When the AS issues an access token for use at an RS, the RS needs to

A GNAP AS offering RS-facing services can publish its features on a well-known discovery document using the URL ".well-known/gnap-as-rs". <del> This endpoint contains a JSON document consisting of a single JSON object with any combination of the following optional fields: </del> <ins> This endpoint contains a JSON document RFC8259 consisting of a single JSON object with any combination of the following optional fields: </ins> The URL of the endpoint offering introspection.
Change:
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit 122ea374f78cfa417b0d1d80101e64990c448665 https://deploy-preview-11--gnap-resource-servers-editors-URL

Discussion:
However, it is often desirable to have the RS and AS communicate at runtime for a variety of purposes, including allowing the RS to validate and understand the rights and privileges associated with a <del> grant of access represented by an access token issued by (AS), or </del> <ins> grant of access represented by an access token issued by the AS, or </ins> negotiating the capabilities of either party.  These types of connections are particularly useful for connecting an AS and RS from different vendors, allowing interoperable distributed deployments of

the request with its own key (not the client instance's key or the token's key). <del> The AS validates the access token value and the client instance's </del> <ins> The AS validates the access token value and the Resource Server's </ins> request and returns the introspection response for the token. The RS fulfills the request from the client instance.

at the secondary RS.  This internal secondary token is issued in the context of the incoming access token. <del> While it is possible to use a [token format]{#structure} that allows for the RS to generate its own secondary token, the AS can allow the RS to request this secondary access token using the same process used by the original client instance to request the primary access token. Since the RS is acting as its own client instance from the perspective of GNAP, this process uses the same grant endpoint, request structure, and response structure as a client instance's request. </del> <ins> While it is possible to use a structure that allows for the RS to generate its own secondary token, the AS can allow the RS to request this secondary access token using the same process used by the original client instance to request the primary access token.  Since the RS is acting as its own client instance from the perspective of GNAP, this process uses the same grant endpoint, request structure, and response structure as a client instance's request. </ins> The client instance calls RS1 with an access token.
Change:
closing
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! Built :hammer: Explore the source changes: 35665c3208b87850c24d51a1083919c030a1978d :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Added the list of terms
Include a reference to the Terminology section of the Core doc.
I think we should list out the terminology in question here as well as the general reference.

Discussion:
character and leading spaces on wrapped lines are not part of the value. <ins> Terminology specific to GNAP is defined in the terminology section of the core specification I-D.ietf-gnap-core-protocol, and provides definitions for the protocol roles: Authorization Server (AS), Client, Resource Server (RS), Resource Owner (RO), End-user; as well as the protocol elements: Attribute, Access Token, Grant, Privilege, Protected Resource, Right, Subject, Subject Information.  The same definitions are used in this document. </ins> 2. When the AS issues an access token for use at an RS, the RS needs to
Change:
Expands discussion of RS authentication, with examples. Re-uses structures from client instance auth used in core. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 71b0e6f2bdaa5a34903865e3130160be29eefc4b :mag: Inspect the deploy log: :sunglasses: Browse the preview:

Discussion:
3.2. <del> Unless otherwise specified, the RS protects its calls to the AS using any of the signature methods defined by GNAP.  This signing method MUST cover all of the appropriate portions of the HTTP request </del> <ins> Unless otherwise specified, the RS MUST protect its calls to the AS using any of the signature methods defined by GNAP.  This signing method MUST cover all of the appropriate portions of the HTTP request </ins> message, including any body elements, tokens, or headers required for functionality. <del> The AS MAY require an RS to pre-register its keys or could alternatively allow calls from arbitrary keys, in a trust-on-first- use model.  The RS MAY present its keys by reference or by value in the same fashion as a client instance calling the AS in the core protocol of GNAP I-D.ietf-gnap-core-protocol. </del> <ins> The RS MAY present its keys by reference or by value in a similar fashion to a client instance calling the AS in the core protocol of GNAP, described in I-D.ietf-gnap-core-protocol.  In the protocols defined here, this takes the form of the resource server identifying itself using a "key" field or by passing an instance identifier directly. or by reference: The AS MAY require an RS to pre-register its keys or could allow calls from arbitrary keys in a trust-on-first-use model. </ins> 3.3.

Since the RS is acting as a client instance, the RS MUST identify itself with its own key in the "client" field and sign the request <del> just as any client instance would. [[ See issue #116 [2] ]] </del> <ins> just as any client instance would, as described in authentication. </ins> The AS responds with a token for the downstream RS2 as described in I-D.ietf-gnap-core-protocol.  The downstream RS2 could repeat this

8.1.  URIs [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 <del> [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 </del>
Change:
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! Built :hammer: Explore the source changes: ee6b3fc9832467191449ff86c6651ebf548d33ea :mag: Inspect the deploy log: :sunglasses: Browse the preview:
A couple of other minor things it sounds to me like an optional step for the RS to validate the signature if the key object is presented in the introspection response. That should be MUST, right? The third step in section "Token Introspection" states that I think that the AS should validate the RS's request and only after that the AT's value.
The RS always has to validate the signature, but sometimes it can't fully validate it until after it looks up the token's data using introspection. We should look at what OAuth MTLS and DPoP say in terms of RS validation steps. The intent of the language for the AS validation was not to imply an order in either direction, so we can look to tweak this to make that more clear.

Discussion:
different vendors, allowing interoperable distributed deployments of GNAP-protected systems. <del> This specification defines several means for a RS and AS to </del> <ins> This specification defines several means for an RS and AS to </ins> communicate these aspects with each other, including structured access tokens and RS-facing APIs.  This specification also discusses methods for an RS to derive a downstream token for calling another

When the AS issues an access token for use at an RS, the RS needs to have some means of understanding what the access token is for in order to determine how to respond to the request.  The core GNAP <del> protocol makes no assumptions or demands on the format or contents of the access token, and in fact the token format and contents are opaque to the client instance.  However, such token formats can be the topic of agreements between the AS and RS. </del> <ins> protocol makes neither assumptions nor demands on the format or contents of the access token, and in fact, the token format and contents are opaque to the client instance.  However, such token formats can be the topic of agreements between the AS and RS. </ins> Self-contained structured token formats allow for the conveyance of information between the AS and RS without requiring the RS to call
Change:
Updates based on reviewing comments from Martin and Jan.
I was expecting more changes. What about the Title?
good enough but, FYI, there's no need to set the "abbrev" attribute if it's the same value as the title...
Looks like the "abbrev" text is too long. How about "HTTPS YANG Notifications"?
Or maybe "HTTPS Notif Transport" ??? Either way is fine by me.

Discussion:
<del> An HTTPS-based Transport for Configured Subscriptions </del> <ins> An HTTPS-based Transport for YANG Notifications </ins> draft-ietf-netconf-https-notif-latest Abstract
Change:
NAME pls review
While not a mandatory requirement for new fields, using SF has a number of benefits: Well-defined parsing and serialisation algorithms Corresponding reduction of interop and security issues Existing implementation support Possibility of more efficient serialisation support (i.e., binary HTTP headers) URL
Closing this, PR is merged after NAME comment is addressed.

Discussion:
2.1. <del> The "Idempotency-Key" request header field describes </del> <ins> "Idempotency-Key" is an Item Structured Header RFC8941.  Its value MUST be a String.  Refer to Section 3.3.3 of RFC8941 for ABNF of "sf- string": </ins> Clients MUST NOT include more than one "Idempotency-Key" header field in the same request.
Change:
This: Gets the editors' draft generated by the template using GitHub actions (was never set up) Fixes up some document metadata Updates the IANA considerations section to fit current practice
looks like this one didn't work as expected, NAME URL
Fixed.

Discussion:
The Idempotency-Key HTTP Header Field <del> draft-ietf-httpapi-idempotency-key-header-01 </del> <ins> draft-ietf-httpapi-idempotency-key-header-latest </ins> Abstract

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here, and without quotes. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule

idempotency related requirements as published by the server and use appropriate algorithm to generate idempotency keys. <del> For each request, client SHOULD </del> <ins> For each request, client </ins> Send a unique idempotency key in the HTTP "Idempotency-Key" request header field.

Server is responsible for managing the lifecycle of the idempotency key. <del> For each request, server SHOULD </del> <ins> For each request, server </ins> Identify idempotency key from the HTTP "Idempotency-Key" request header field.

3.1. <del> The "Idempotency-Key" request header should be added to the permanent registry of message header fields (see RFC3864), taking into account the guidelines given by HTTP/1.1 RFC7231. </del> <ins> The Idempotency-Key field name should be added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry". </ins> 4.