jiebi/TextFlow huggingface dataset:
Original text:
those privileges to an end-user.  This process is refered to as privilege delegation. <del> protected API (Application Programming Interface) served by a RS </del>  and that can be accessed by a client, if and only if a valid access token is provided.  Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource. ability given to a subject to perform a given operation on a <del> resource under the control of a RS. </del>  person, organization or device. parameters for the incoming request match those that it is expecting from the session created in (1).  The client instance also needs to be prepared for the end-user never being returned to <del> the client instance and handle time outs appropriately. </del>  The client instance loads the continuation information from (3) and sends the interaction reference from (7) in a request to Claims about the RO as known and declared by the AS. <del> An identifier this client instance instance can use to identify itself when making future requests. </del>  <del> An identifier this client instance instance can use to identify its current end-user when making future requests. </del>  An error code indicating that something has gone wrong.

Reviewer comments:
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fd1d0f88ac7d2a9ad6f43bb6d959a2aa84558f2b https://deploy-preview-179--gnap-core-protocol-editors-URL
One small change needed (marked) but otherwise good!

Revised text:
those privileges to an end-user.  This process is refered to as privilege delegation.  <ins> protected API (Application Programming Interface) served by an RS </ins> and that can be accessed by a client, if and only if a valid access token is provided.  Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource. ability given to a subject to perform a given operation on a  <ins> resource under the control of an RS. </ins> person, organization or device. parameters for the incoming request match those that it is expecting from the session created in (1).  The client instance also needs to be prepared for the end-user never being returned to  <ins> the client instance and handle timeouts appropriately. </ins> The client instance loads the continuation information from (3) and sends the interaction reference from (7) in a request to Claims about the RO as known and declared by the AS.  <ins> An identifier this client instance can use to identify itself when making future requests. </ins>  <ins> An identifier this client instance can use to identify its current end-user when making future requests. </ins> An error code indicating that something has gone wrong.
Original text:
endpoint to retrieve the server's discovery information.  The AS MUST respond with a JSON document containing the following information: <del> REQUIRED.  The full URL of the AS's grant request endpoint.  This MUST match the URL the client instance used to make the discovery request. </del>  OPTIONAL.  A list of the AS's capabilities.  The values of this result MAY be used by the client instance in the request-

Reviewer comments:
Suggested changes for URL They could be also simplified to something like
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 0569eb3db265511e06d7fb19b2320081d4626430 https://deploy-preview-183--gnap-core-protocol-editors-URL
Sections "9 Discovery" states that It makes sense to specify that this URL should be using HTTPS. I also don't think you want to allow using the fragment component in it, as well as query parameters. The query parameters could be arguable though...
This definition should be beyond just the discovery portion -- this endpoint is fundamental to the protocol and it does need to be protected. We can at least mention that it starts with HTTPS here. Prohibiting fragments makes sense, but prohibiting query parameters or any other URL portion does not make sense, though, as that could be important to an AS's deployment. However, the client instance always takes this string as-is and doesn't add or modify anything, and it always makes a POST to it.
URL
I've reused the definition of . That is a very precise one IMO.

Revised text:
endpoint to retrieve the server's discovery information.  The AS MUST respond with a JSON document containing the following information:  <ins> REQUIRED.  The location of the AS's grant request endpoint.  The location MUST be a URL RFC3986 with a scheme component that MUST be https, a host component, and optionally, port, path and query components and no fragment components.  This URL MUST match the URL the client instance used to make the discovery request. </ins> OPTIONAL.  A list of the AS's capabilities.  The values of this result MAY be used by the client instance in the request-
Original text:
A timestamp of the request in integer seconds <del> When to bind a request to an access token, the access token hash </del>  value.  Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the "access_token" value, where the hash algorithm used is the hash This method is indicated by "dpop" in the "proof" field.  The client instance creates a Demonstration of Proof-of-Possession signature <del> header as described in I-D.ietf-oauth-dpop section 2.  In addition to the required fields, the DPoP body MUST also contain a digest of the request body: </del>  Digest of the request body as the value of the Digest header <del> defined in RFC3230. </del>  7.3.5.

Reviewer comments:
Changes field to , adds to DPoP definition for parity with other JOSE signature methods.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fc15fc873432dae90bce38706aa85313d831d419 https://deploy-preview-195--gnap-core-protocol-editors-URL
The signature methods all need to cover the access token, but the DPoP method currently does not. We can add the method used in the and methods.
The FAPI WG is proposing a similar DPoP profile: URL This uses the field instead of , and we could align with that.
Convergence would be helpful, do we know the status of the document?
Is this something that can be standardized in , even as a best practice or recommendation? Trying to align with all documents out there is not a long time strategy...
I've reached out to the OAuth WG on the topic of defining the field in DPoP itself. If that happens we can remove this field from our spec, but until that happens then it makes sense to keep FAPI and GNAP aligned, for now.
Regarding alignment between FAPI and GNAP... DPoP describes "htu" as while GNAP as which obviously isn't the same.

Revised text:
A timestamp of the request in integer seconds  <ins> When a request is bound to an access token, the access token hash </ins> value.  Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the "access_token" value, where the hash algorithm used is the hash This method is indicated by "dpop" in the "proof" field.  The client instance creates a Demonstration of Proof-of-Possession signature  <ins> 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: </ins> Digest of the request body as the value of the Digest header  <ins> defined in RFC3230.  When a request contains a message body, such as a POST or PUT request, this field is REQUIRED. When a request is bound to an access token, the access token hash value.  Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the "access_token" value, where the hash algorithm used is the hash algorithm used in the "alg" header parameter of the JWS's JOSE Header.  For instance, if the "alg" is "RS256", hash the "access_token" value with SHA-256, then take the left-most 128 bits and base64url encode them. </ins> 7.3.5.
Original text:
described in response-token-single. When neither an access token nor key proof are used, this is an <del> unsecured request.  This type of used only for calls to the RS during a discovery phase as described in rs-request-without-token. </del>  7.1. general-purpose APIs use a URI for this field to avoid collisions between multiple API types protected by a single AS. <del> While it is expected that many APIs will have its own properties, a </del>  set of common properties are defined here.  Specific API implementations SHOULD NOT re-use these fields with different semantics or syntax.  The available values for these properties are The access requested for a given object when using these fields is the cross-product of all fields of the object.  That is to say, the object represents a request for all "action" values listed within the <del> object to be used at all "locations" values listed within the object </del>  for all "datatype" values listed within the object.  Assuming the request above was granted, the client instance could assume that it would be able to do a "read" action against the "images" on the first

Reviewer comments:
Minor typos
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit b2ce64bfa924bc30b24ea9301223156ec0eb8520 https://deploy-preview-204--gnap-core-protocol-editors-URL
within (and likely other sections), the property names are plural, but the text sometimes refers to the singular property names. This should be cleaned up to be consistent one way or another.

Revised text:
described in response-token-single. When neither an access token nor key proof are used, this is an  <ins> unsecured request.  This type of request is used only for calls to the RS during a discovery phase as described in rs-request- without-token. </ins> 7.1. general-purpose APIs use a URI for this field to avoid collisions between multiple API types protected by a single AS.  <ins> While it is expected that many APIs will have their own properties, a </ins> set of common properties are defined here.  Specific API implementations SHOULD NOT re-use these fields with different semantics or syntax.  The available values for these properties are The access requested for a given object when using these fields is the cross-product of all fields of the object.  That is to say, the object represents a request for all "action" values listed within the  <ins> object to be used at all "location" values listed within the object </ins> for all "datatype" values listed within the object.  Assuming the request above was granted, the client instance could assume that it would be able to do a "read" action against the "images" on the first
Original text:
7.3.1. This method is indicated by "jwsd" in the "proof" field.  A JWS <del> RFC7515 signature object is created as follows: </del>  <del> The header of the JWS MUST contain the "kid" field of the key bound to this client instance for this request.  The JWS header MUST contain an "alg" field appropriate for the key identified by kid and MUST NOT be "none".  The "b64" field MUST be set to "false" and the "crit" field MUST contain at least "b64" as specified in </del>  <del> To protect the request, the JWS header MUST contain the following additional fields. </del>  The HTTP Method used to make this request, as an uppercase ASCII string. 7.3.2. This method is indicated by "jws" in the "proof" field.  A JWS <del> RFC7515 signature object is created as follows: </del>  <del> The header of the JWS MUST contain the "kid" field of the key bound to this client instance for this request.  The JWS header MUST contain an "alg" field appropriate for the key identified by "kid" and MUST NOT be "none". </del>  To protect the request, the JWS header MUST contain the following <del> additional fields. </del>  The HTTP Method used to make this request, as an uppercase ASCII string.

Reviewer comments:
These changes replace with replace with replace with in Detached JWS and Attached JWS sections.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit df67d81f6aadce526a2eecb1d9185d684f17242c https://deploy-preview-207--gnap-core-protocol-editors-URL
I think the proposal in could have some impact on this language, as well as making sure both attached and detached JWS methods are fully aligned.
could definitely have some impact. Although, these changes touch only the used terminology.
Accept to align with JOSE terminology, will probably be updated again when crypto methods get updated.

Revised text:
7.3.1. This method is indicated by "jwsd" in the "proof" field.  A JWS  <ins> RFC7515 object is created as follows: </ins>  <ins> The JOSE (JSON Object Signing and Encryption) header MUST contain the "kid" parameter of the key bound to this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none".  The "b64" parameter MUST be set to "false" and the "crit" parameter MUST contain at least "b64" as specified in RFC7797. </ins>  <ins> To protect the request, the JOSE header MUST contain the following additional parameters. </ins> The HTTP Method used to make this request, as an uppercase ASCII string. 7.3.2. This method is indicated by "jws" in the "proof" field.  A JWS  <ins> RFC7515 object is created as follows: </ins>  <ins> The JOSE header MUST contain the "kid" parameter of the key bound to this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none". </ins> To protect the request, the JWS header MUST contain the following  <ins> additional parameters. </ins> The HTTP Method used to make this request, as an uppercase ASCII string.
Original text:
corresponding to the token labels chosen by the client instance in the request-token-multiple. <del> In this non-normative example, two bearer tokens are issued under the names "token1" and "token2", and only the first token has a management URL associated with it. </del>  Each access token corresponds to one of the objects in the "access_token" array of the client instance's request-token-multiple.

Reviewer comments:
…alue should be the boolean false. Please, correct me if I wrong.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 23bd329e9c764cedfe6a8dd1e26b557aa8fda9a6 https://deploy-preview-209--gnap-core-protocol-editors-URL
Ok, I will take care of it a bit later. I also suggest omitting from other examples as it's a default value.
Done.
We'll need to add an example of in at least one location, but otherwise these changes are good.
Done in URL
The intent was to make the examples bound tokens by default, so instead of changing the examples, any text surrounding these examples referring them as bearer needs to be adjusted appropriately.

Revised text:
corresponding to the token labels chosen by the client instance in the request-token-multiple.  <ins> In this non-normative example, two tokens are issued under the names "token1" and "token2", and only the first token has a management URL associated with it. </ins> Each access token corresponds to one of the objects in the "access_token" array of the client instance's request-token-multiple.
Original text:
To protect the request, the JOSE header MUST contain the following additional parameters.  The HTTP Method used to make this request, as an uppercase ASCII string. To protect the request, the JWS header MUST contain the following additional parameters.  The HTTP Method used to make this request, as an uppercase ASCII string.

Reviewer comments:
Suggested changes for URL
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 5602b657d1be7c2b17685269030092799ccb120f https://deploy-preview-226--gnap-core-protocol-editors-URL
This PR is now pending merge, linking with a new issue for verification (to check the value based on typ).
Key proof sections do not currently detail how to verify each method, including requirements for verifying fields, this needs to be added.
The idea is to minimize ways to reuse JWS objects . These attacks are sometimes referred as Swapping JWTs and Cross-JWT Confusion). See also discussion in URL

Revised text:
To protect the request, the JOSE header MUST contain the following additional parameters. <ins> The type header, value "gnap-binding+jwsd". </ins> The HTTP Method used to make this request, as an uppercase ASCII string. To protect the request, the JWS header MUST contain the following additional parameters. <ins> The type header, value "gnap-binding+jws". </ins> The HTTP Method used to make this request, as an uppercase ASCII string.
Original text:
the RO that the request has been completed. Meanwhile, the client instance loads the continuation information <del> stored at (3) and continue-request.  The AS determines which </del>  ongoing access request is referenced here and checks its state. If the access request has not yet been authorized by the RO in

Reviewer comments:
Typo for section 1.4.3 Asynchronous Authorization, step 6: The continuation information was stored on step (2) not (3) as specified in the latest draft.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit befdba8ad92320248c4d011b13cca4f1dcb51f83 https://deploy-preview-245--gnap-core-protocol-editors-URL
Well spotted.

Revised text:
the RO that the request has been completed. Meanwhile, the client instance loads the continuation information  <ins> stored at (2) and continue-request.  The AS determines which </ins> ongoing access request is referenced here and checks its state. If the access request has not yet been authorized by the RO in
Original text:
around that ecosystem.  However, GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. GNAP seeks to provide functionality and solve use cases that OAuth <del> 2.0 cannot easily or cleanly address.  Even so, GNAP and OAuth 2.0 will exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example- oauth2. </del>  1.1.

Reviewer comments:
Fixes issue Note : in the appendix, I used "OAuth 2", elsewhere we talk about "OAuth 2.0". Maybe needs some adjustements.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit 40ad74b8eeec1229a14c83324dbcce73533365d9 https://deploy-preview-247--gnap-core-protocol-editors-URL
For the RFC to be self-contained, please add a section to the Introduction (or an appendix) summarizing the main changes from OAuth2/OIDC, and the rationale for each delta. (Originally raised by NAME
Suggest to put this area in the wiki to have a deeper explanation
I've started a wiki page with some content I had written up for another publication: URL
This information is important to the draft's readership, and people are not seeing it (e.g., Denis's mail from March 26). Can we include it as-is in an appendix to the draft?
I will submit a PR as an appendix. Note also that the editors prepared a short paper "Managing authorization grants beyond OAuth 2" that has been accepted at . It was a nice way to get some external reviews. Will be published in
Looks good, just one typo to fix before inclusion.

Revised text:
around that ecosystem.  However, GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. GNAP seeks to provide functionality and solve use cases that OAuth  <ins> 2.0 cannot easily or cleanly address. vs-oauth2 further details the protocol rationale compared to OAuth 2.0.  GNAP and OAuth 2.0 will exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP.  Some examples of these can be found in example-oauth2. </ins> 1.1.
Original text:
this hash, and the client instance MUST validate the hash when received. <del> To calculate the "hash" value, the party doing the calculation first takes the "nonce" value sent by the client instance in the request- interact-finish, the AS's nonce value from response-interact-finish, and the "interact_ref" sent to the client instance's callback URL. These three values are concatenated to each other in this order using a single newline character as a separator between the fields.  There is no padding or whitespace before or after any of the lines, and no trailing newline character. </del>  The party then hashes this string with the appropriate algorithm based on the "hash_method" parameter of the "callback".  If the

Reviewer comments:
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 4080bf7a507929bd0ad4286d8ef72c0a70506c31 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Please ask the guy who submitted the vuln if there's any publication we can reference, maybe even the master's thesis as a WIP. They've earned it!
NAME I've reached out to them if there's a good URL to reference, and added them to the ack section (I should have done that before!).

Revised text:
this hash, and the client instance MUST validate the hash when received.  <ins> To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the following order using a single newline ("n") character to separate them: the "nonce" value sent by the client instance in the the AS's nonce value from the "interact_ref" returned from the AS as part of the the grant endpoint URL the client instance used to make its There is no padding or whitespace before or after any of the lines, and no trailing newline character. </ins> The party then hashes this string with the appropriate algorithm based on the "hash_method" parameter of the "callback".  If the
Original text:
with a management URL and a response-subject in the form of an opaque identifier. <del> In this example, the AS is returning only a pair of response-subject as both an email address and an opaque identifier. </del>  3.1.

Reviewer comments:
To align with secevent draft 8 which added DIDs
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! :hammer: Explore the source changes: 6ded21ad57eed6fd25df2ca4fb77dcf186c93209 :mag: Inspect the deploy log: :sunglasses: Browse the preview:

Revised text:
with a management URL and a response-subject in the form of an opaque identifier.  <ins> In this example, the AS is returning set of response-subject, simultaneously as an opaque identifier, an email address, and a decentralized identifier (DID). </ins> 3.1.