jiebi/TextFlow huggingface dataset:
Original text:
content type of "application/jose".  The AS MUST extract the payload of the JWS and treat it as the request body for further processing.  If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload and passed in the "Detached-JWS" header as

Reviewer comments:
(thanks NAME
The example given for "attached JWS" in incorrect: missing JWS headers, incorrect value. Here's a better one for your base64 pleasure: eyJhbGciOiJSUzI1NiIsImtpZCI6IktBZ05wV2JSeXk5TWYycmlrbDQ5OExUaE1ydmtiWldIVlNRT0JDNFZIVTQiLCJodG0iOiJwb3N0IiwiaHR1IjoiL3R4IiwidHMiOjE2MDM4MDA3ODN9.eyJjYXBhYmlsaXRpZXMiOltdLCJjbGllbnQiOnsia2V5Ijp7Imp3ayI6eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsImtpZCI6IktBZ05wV2JSeXk5TWYycmlrbDQ5OExUaE1ydmtiWldIVlNRT0JDNFZIVTQiLCJuIjoibGxXbUhGOFhBMktOTGRteE9QM2t4RDlPWTc2cDBTcjM3amZoejk0YTkzeG0yRk5xb1NQY1JaQVBkMGxxRFM4TjNVaWE1M2RCMjNaNTlPd1k0YnBNX1ZmOEdKdnZwdExXbnhvMVB5aG1Qci1lY2RTQ1JRZFRjX1pjTUY0aFJWNDhxcWx2dUQwbXF0Y0RiSWtTQkR2Y2NKbVpId2ZUcERIaW5UOHR0dmNWUDhWa0FNQXE0a1ZhenhPcE1vSVJzb3lFcF9lQ2U1cFN3cUhvMGRhQ1dOS1ItRXBLbTZOaU90ZWRGNE91bXQ4TkxLVFZqZllnRkhlQkRkQ2JyckVUZDR2Qk13RHRBbmpQcjNDVkN3d3gyYkFRVDZTbHhGSjNmajJoaHlJcHE3cGM4clppYjVqTnlYS3dmQnVrVFZZWm96a3NodC1Mb2h5QVNhS3BZVHA4THROWi13In0sInByb29mIjoiandzIn0sIm5hbWUiOiJNeSBGaXN0IENsaWVudCIsInVyaSI6Imh0dHA6Ly9sb2NhbGhvc3QvY2xpZW50L2NsaWVudElEIn0sImludGVyYWN0Ijp7ImNhbGxiYWNrIjp7Im1ldGhvZCI6InJlZGlyZWN0Iiwibm9uY2UiOiJkOTAyMTM4ODRiODQwOTIwNTM4YjVjNTEiLCJ1cmkiOiJodHRwOi8vbG9jYWxob3N0L2NsaWVudC9yZXF1ZXN0LWRvbmUifSwicmVkaXJlY3QiOnRydWV9LCJyZXNvdXJjZXMiOnsiYWN0aW9ucyI6WyJyZWFkIiwicHJpbnQiXSwibG9jYXRpb25zIjpbImh0dHA6Ly9sb2NhbGhvc3QvcGhvdG9zIl0sInR5cGUiOiJwaG90by1hcGkifSwic3ViamVjdCI6eyJzdWJfaWRzIjpbImlzcy1zdWIiLCJlbWFpbCJdfX0.LUyZ8fERmxbYARq8kBYMwzcd8GnCAKAlo2ZSYLRRNAYWPrp2XGLJOvg97WK1idfLB08OJmLVsCXxCvn9mgaAkYNLZjHcusBvY1mNo0E1sdTEr31CVKfC-6WrZCscb8YqE4Ayhh0Te8kzSng3OkLdy7xN4xeKuHzpF7yGsM52JZ0cBcTo6WrYEfGdr08AWQJ59ht72n3jTsmYNy9A6I4Wrvfgj3TNxmwYojpBAicfjnzA1UVcNm9FxiSz1y2tdH7j5rVqBMQife-k9Ewk95vr3lurthenliYSNiUinVfoW1ybnaIBcTtP1YCxg_h1y-B5uZEvYNGCuoCqa6IQ
At this stage, most of the examples need to be reworked and/or re-generated, especially including things with signatures. They were all originally pulled from a running system based on an older version of the I-D, and so edits to them have been by hand so far. This is a helpful start, so thanks!

Revised text:
content type of "application/jose".  The AS MUST extract the payload of the JWS and treat it as the request body for further processing. <ins> This example's JWS header decodes to: And the JWS body decodes to: </ins> If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload and passed in the "Detached-JWS" header as
Original text:
and MAY be more powerful.  The means for the RS to determine the resource reference are out of scope of this specification, but some dynamic methods are discussed in I-D.draft-ietf-gnap-resource- <del> servers.  The content of the resource handle is opaque to the client instance. </del>  The client instance then makes a request to the "as_uri" as described in request, with the value of "access" as one of the members of the

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: b88d66c00c5d10b7eacc0beb4dd928bbb94470a9 Inspect the deploy log: Browse the preview:
Good catch, thanks!

Revised text:
and MAY be more powerful.  The means for the RS to determine the resource reference are out of scope of this specification, but some dynamic methods are discussed in I-D.draft-ietf-gnap-resource-  <ins> servers.  The content of the resource reference is opaque to the client instance. </ins> The client instance then makes a request to the "as_uri" as described in request, with the value of "access" as one of the members of the
Original text:
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and <del> other elements.  Some examples use a single trailing backslash '' to </del>  indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.

Reviewer comments:
Apostrophes were accidentally used instead of backticks to render the backslash as code.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ffdb4ee91464d098f38e69f9bd5e6936a5a009a8 Inspect the deploy log: Browse the preview:

Revised text:
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and  <ins> other elements.  Some examples use a single trailing backslash "" to </ins> indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.
Original text:
To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the <del> following order using a single newline ("n") character to separate </del>  them: the "nonce" value sent by the client instance in the

Reviewer comments:
The backslash does not need to be escaped
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 1a3c389510f95bfaaf245f40e2552e735e30826b Inspect the deploy log: Browse the preview:

Revised text:
To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the  <ins> following order using a single newline ("n") character to separate </ins> them: the "nonce" value sent by the client instance in the
Original text:
token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been split by the AS, the value of the "label" field is chosen by the <del> AS and the "split" field is included and set to "true". </del>  OPTIONAL.  The management URI for this access token.  If provided, the client instance MAY manage its access token as described in

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: bf6004c8584efbaf8dc30f3637ba0c61bc000d84 Inspect the deploy log: Browse the preview:
NAME The editors would like to give you credit for all these contributions, can you please give us your name as you'd like it to appear in the acknowledgements section? Thank you!

Revised text:
token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been split by the AS, the value of the "label" field is chosen by the  <ins> AS and the "split" flag is used. </ins> OPTIONAL.  The management URI for this access token.  If provided, the client instance MAY manage its access token as described in
Original text:
(2) The client instance request. (3) The AS processes the request and determines what is needed to <del> fulfill the request.  The AS sends its response. </del>  (B) If interaction is required, the AS authorization to gather authorization.  The interactive component of the AS can function

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 88c9fdd493cc1d969e1405501ff6b7d071b218e9 Inspect the deploy log: Browse the preview:
In section 1.4, the text states: How can the AS "determine what is needed to fulfill the request" ? Shall the AS have established some prior relationship ? If yes, what such relationships consist of ? If no, can "other means" be used ?

Revised text:
(2) The client instance request. (3) The AS processes the request and determines what is needed to  <ins> fulfill the request.  (See authorization.)  The AS sends its response. </ins> (B) If interaction is required, the AS authorization to gather authorization.  The interactive component of the AS can function
Original text:
In GNAP, the client instance secures its requests to the AS and RS by presenting an access token, presenting proof of a key that it <del> possesses, or both an access token and key proof together. </del>  When an access token is used with a key proof, this is a bound token request.  This type of request is used for calls to the RS

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 3ba5ef509380bf20fa220808c57fd1ced5797c5d Inspect the deploy log: Browse the preview:
This term is specific to the protocol, so should probably be defined
Background of picking a new term: The intended goal for the term as currently used is to generically talk about all the different methods of presenting proof of key possession by a client instance. Current methods include signature-based schemes that work on the HTTP message and a TLS-based scheme that relies on the key being the same between layers. These can all be optionally bound to an access token as well, and each "proof method" needs to have a way to include the access token in its coverage.
Renamed the issue for clarity. Please undo if I got it wrong.

Revised text:
In GNAP, the client instance secures its requests to the AS and RS by presenting an access token, presenting proof of a key that it  <ins> possesses (aka, a "key proof"), or both an access token and key proof together. </ins> When an access token is used with a key proof, this is a bound token request.  This type of request is used for calls to the RS
Original text:
4.2.2. <del> When using the response-interact-finish with the "push" method, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URL sent in request-interact-callback- push. </del>  The entity message body is a JSON object consisting of the following two fields: and no trailing newline character. The party then hashes this string with the appropriate algorithm <del> based on the "hash_method" parameter of the "callback".  If the </del>  "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3".

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 681a99c7e9be294002d224d914dbb452a5d278bf Inspect the deploy log: Browse the preview:

Revised text:
4.2.2.  <ins> When using the response-interact-finish, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URL sent in request-interact-callback-push. </ins> The entity message body is a JSON object consisting of the following two fields: and no trailing newline character. The party then hashes this string with the appropriate algorithm  <ins> based on the "hash_method" parameter under the "finish" key.  If the </ins> "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3".
Original text:
The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing <del> method is associated with the key.  This information is conveyed in the "bound" and "key" parameters in response-token-single and response-token-multiple responses. </del>  If the "flags" field does not contain the "bearer" flag and the "key" is absent, the access token MUST be sent using the same key and

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 906ec0b0bbf3cdcb59850a43e4e9221456aa5eb8 Inspect the deploy log: Browse the preview:

Revised text:
The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing  <ins> method is associated with the key.  This information is conveyed by the "key" parameter and the "bearer" flag in response-token-single and response-token-multiple responses. </ins> If the "flags" field does not contain the "bearer" flag and the "key" is absent, the access token MUST be sent using the same key and
Original text:
client software can include these values in their code for a more efficient and compact request. <del> If desired, the AS MAY also generate and return some of these references dynamically to the client instance in its response to facilitate multiple interactions with the same software.  The client instance SHOULD use these references in future requests in lieu of sending the associated data value.  These handles are intended to be used on future requests. Dynamically generated handles are string values that MUST be protected by the client instance as secrets.  Handle values MUST be unguessable and MUST NOT contain any sensitive information.  Handle values are opaque to the client instance. All dynamically generated handles are returned as fields in the root JSON object of the response.  This specification defines the following dynamic handle return, additional handles can be defined in IANA. </del>  A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance. <del> This non-normative example shows one handle along side an issued access token. </del>  [[ See issue #77 [18] ]]

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 8641b302c594f5e2fd15576ceed1134a210465bd Inspect the deploy log: Browse the preview:

Revised text:
client software can include these values in their code for a more efficient and compact request.  <ins> If desired, the AS MAY also generate and return an instance identifier dynamically to the client instance in the response to facilitate multiple interactions with the same client instance over time.  The client instance SHOULD use this instance identifier in future requests in lieu of sending the associated data values in the "client" field. Dynamically generated client instance identifiers are string values that MUST be protected by the client instance as secrets.  Instance identifier values MUST be unguessable and MUST NOT contain any sensitive information.  Instance identifier values are opaque to the client instance. </ins> A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance.  <ins> This non-normative example shows an instance identifier along side an issued access token. </ins> [[ See issue #77 [18] ]]
Original text:
software.  However, end-users might also be facing some attacker's client software, without even realizing it.  client/AS: An honest AS may be facing an attacker's client (as discussed just above), or the reverse, and GNAP aims at making common attacks impractical.  The core specification makes access

Reviewer comments:
May later make a link to security considerations related to phishing attacks but currently the section has not been merged in trunk, so it would create an error
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 0dd7278bfa3604409da8bb8ea4ddc6983824cdb2 Inspect the deploy log: Browse the preview:
To be described (interactions)

Revised text:
software.  However, end-users might also be facing some attacker's client software, without even realizing it. <ins> end-user / AS: when the client supports it (see response- interact), the end-user gets to interact with front-channel URLs provided by the AS. </ins> client/AS: An honest AS may be facing an attacker's client (as discussed just above), or the reverse, and GNAP aims at making common attacks impractical.  The core specification makes access
Original text:
validates the hash.  If the client instance does not use an interaction finish method or does not check the interaction finish hash value, the compromised AS can be granted a valid access token on <del> behalf of the resource owner.  See attack-surfaces for details of one </del>  such attack, which has been since addressed in this document by including the grant endpoint in the interaction hash calculation. The client instance still needs to validate the hash for the attack

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 8fe956adfc5cb03ad39042fa3e3497c42d7fbce1 Inspect the deploy log: Browse the preview:
Some unicode characters within the document break the build tools, specifically we see being changed to in the rendered document.

Revised text:
validates the hash.  If the client instance does not use an interaction finish method or does not check the interaction finish hash value, the compromised AS can be granted a valid access token on  <ins> behalf of the resource owner.  See AXELAND2021 for details of one </ins> such attack, which has been since addressed in this document by including the grant endpoint in the interaction hash calculation. The client instance still needs to validate the hash for the attack
Original text:
mechanism. The means of dereferencing this value are out of scope for this <del> specification. </del>  7.2.

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ca9e3193f78b420b40659157f6d18545ddc97e80 Inspect the deploy log: Browse the preview:
Originally posted by NAME in URL
In general I would tend to think this doesn't need to be specified by us, supporting the current text "The means of dereferencing this value are out of scope for this specification." But before we can conclude, I'd like to ask a few questions: related the lifecycle of the referenced key (cf ) : is it something ephemeral (linked to a specific request) or not ? (but knowing that continuation could last for some time, what do we do then?) could it have an impact on error management? (for instance collision of references?)
In draft 7, says that dereferencing key references are out of scope. Add to 7.1.1 to clarify: The common case is such that key references are created by the AS and are not necessarily deferenceable by the client, they are just an internal AS reference If an implementation (or ecosystem of implementations) wants to use references that are resolvable by both clients and ASs (i.e. the client publishes its key at a URL), that could be described as an extension
I think the text looks good, left one note on formatting/structure but it's not a showstopper.

Revised text:
mechanism. The means of dereferencing this value are out of scope for this  <ins> specification.  Commonly, key references are created by the AS and are not necessarily needed to be dereferencable by the client.  These types of key references are an internal reference to the AS, such as an identifier of a record in a database.  In other applications, it can be useful to use key references that are resolvable by both clients and ASs, which could be accomplished by e.g. a client publishing a public key at a URL.  For interoperability, this method could later be described as an extension. </ins> 7.2.
Original text:
The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL <del> Safe Base64 with no padding.  The resulting string is the hash value. </del>  4.2.3.2. The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL <del> Safe Base64 with no padding.  The resulting string is the hash value. </del>  5.

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 00127788e68e6777c3e674eb44e3a821cb54516e Inspect the deploy log: Browse the preview:
in 4.2.3.1 and 4.2.3.2, for base64 encoded URLs with no padding (+ by the way, we should explain what we mean by no padding and URL safe)
Base64 URL-safe encoding, with and without padding, is defined in RFC4648. URLsafe: URL Optional padding: URL
thanks exactly the links i needed

Revised text:
The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL  <ins> Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> 4.2.3.2. The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL  <ins> Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> 5.
Original text:
If an access token response includes the "manage" parameter as described in response-token-single, the client instance MAY call this URL to manage the access token with any of the actions defined in the <del> following sections.  Other actions are undefined by this specification. </del>  The access token being managed acts as the access element for its own management API.  The client instance MUST present proof of an

Reviewer comments:
Actually a very minor editorial change to specify the actions.
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: b874cebd8f241746631e4c73c3c9056b190bfb1e Inspect the deploy log: Browse the preview:
So I was starting to have a look at rotation/revocation issues (keys or tokens), as we have many open issues that relate to that Interesting insight from DIF KERI (Universal Identifier Theory paper) "The term revocation has two completely different meanings in the identity space. In key management one may speak of revoking keys. With statement issuance, authorization issuance, or credential issuance, one may speak of revoking an authorization statement, a token, or a credential. This becomes confusing when the act of revoking keys also implicitly revokes the authorization of statements signed with those keys." and "KERI terminology usually avoids that confusion between rotation and revocation because a key rotation operation is the equivalent of a key revocation operation followed by a key replacement operation. So one operation, rotate, is implemented instead of two operations (revoke and replace)."
Related question: what is persistent (drawback, need to store that info somewhere, safely) ? what is ephemeral ? what's the lifecycle of related objects? And more specifically: every new request needs to provide a key -> don't need long term persistance for that, we simply need to handle key rotations during a single request (as described in issue ) objets derived from some underlying key however (including bound tokens) might be more tricky ( ex ). Do we need some kind of registry to keep track of the changes over time, to keep them alive even if the key changes? Or do we just consider that they get revoked? (and what happens if you fall into that case at some point, what's your next action?)
This is already managed by section 7.2 "If the flags field does not contain the bearer flag and the key is absent, the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation)"

Revised text:
If an access token response includes the "manage" parameter as described in response-token-single, the client instance MAY call this URL to manage the access token with any of the actions defined in the  <ins> following sections: rotate and revoke.  Other actions are undefined by this specification. </ins> The access token being managed acts as the access element for its own management API.  The client instance MUST present proof of an