jiebi/TextFlow huggingface dataset:
Original 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.

Reviewer comments:
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

Revised text:
7.3.4.  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.
Original text:
The verifier MUST validate the signature against the expected key of the signer. <del> 7.3.6. </del>  This method is indicated by "oauthpop" in the "proof" field.  The signer creates an HTTP Authorization PoP header as described in I-

Reviewer comments:
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

Revised text:
The verifier MUST validate the signature against the expected key of the signer.  <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-
Original 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>  If this interaction mode is supported for this client instance and request, the AS returns a redirect interaction response response-

Reviewer comments:
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:

Revised 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  <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-
Original 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>  which the client instance determines the application to open with this URL are out of scope of this specification.

Reviewer comments:
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:

Revised 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  <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.
Original 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>  contents, composition, or relationship to the AS grant URL. If this interaction mode is supported for this client instance and

Reviewer comments:
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:

Revised text:
If the client instance is capable of displaying or otherwise communicating a short, human-entered code to the RO, the client  <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
Original 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>  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

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

Revised text:
as far as the overall protocol is concerned. A single role need not be deployed as a monolithic service.  For  <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
Original text:
In some circumstances, the information needed at a given stage is communicated out of band or is preconfigured between the components <del> or entities performing the roles.  For example, one entity can fulfil multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </del>  1.5.1.

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

Revised text:
In some circumstances, the information needed at a given stage is communicated out of band or is preconfigured between the components  <ins> or entities performing the roles.  For example, one entity can fulfill multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </ins> 1.5.1.
Original text:
The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction- <del> redirect given by the AS in (2). </del>  <del> The user's directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </del>  documentation, the AS documentation, or the client software itself.  Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a

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

Revised text:
The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-  <ins> usercode given by the AS in (2). </ins>  <ins> The users directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </ins> documentation, the AS documentation, or the client software itself.  Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a
Original text:
The client instance request.  The client instance does not send any interaction modes to the server. <del> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to the client instance.  Note that response-subject is not generally </del>  applicable in this use case, as there is no user involved. The client instance use-access-token to call the RS.

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

Revised text:
The client instance request.  The client instance does not send any interaction modes to the server.  <ins> The AS determines that the request has been authorized, the AS grants access to the resource in the form of response-token to the client instance.  Note that response-subject is not generally </ins> applicable in this use case, as there is no user involved. The client instance use-access-token to call the RS.
Original text:
the RS again. The RS validates the access token and determines that the access <del> token is expired The RS responds to the client instance with an </del>  error. The client instance calls the token management URI returned in (2)

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

Revised text:
the RS again. The RS validates the access token and determines that the access  <ins> token is expired.  The RS responds to the client instance with an </ins> error. The client instance calls the token management URI returned in (2)
Original text:
2. <del> To start a request, the client instance sends RFC8259 document with </del>  an object as its root.  Each member of the request object represents a different aspect of the client instance's request.  Each field is described in detail in a section below. Additional members of this request object can be defined by <del> extensions to this protocol as described in </del>  A non-normative example of a grant request is below:

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

Revised text:
2.  <ins> To start a request, the client instance sends a RFC8259 document with </ins> an object as its root.  Each member of the request object represents a different aspect of the client instance's request.  Each field is described in detail in a section below. Additional members of this request object can be defined by  <ins> extensions to this protocol as described in request-extending. </ins> A non-normative example of a grant request is below:
Original text:
to determine appropriate key information, the client instance can send this instance identifier as a direct reference value in lieu of the "client" object.  The instance identifier MAY be assigned to a <del> client instance at runtime through the response-dynamic-handles or MAY be obtained in another fashion, such as a static registration process at the AS. </del>  When the AS receives a request with an instance identifier, the AS MUST ensure that the key used to binding-keys is associated with the

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

Revised text:
to determine appropriate key information, the client instance can send this instance identifier as a direct reference value in lieu of the "client" object.  The instance identifier MAY be assigned to a  <ins> client instance at runtime through a grant response (response- dynamic-handles) or MAY be obtained in another fashion, such as a static registration process at the AS. </ins> When the AS receives a request with an instance identifier, the AS MUST ensure that the key used to binding-keys is associated with the
Original text:
In response to a client instance's request, the AS responds with a JSON object as the HTTP entity body.  Each possible field is detailed <del> in the sections below </del>  In this example, the AS is returning an response-interact-redirect, a response-interact-finish, and a response-continue.

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

Revised text:
In response to a client instance's request, the AS responds with a JSON object as the HTTP entity body.  Each possible field is detailed  <ins> in the sections below. </ins> In this example, the AS is returning an response-interact-redirect, a response-interact-finish, and a response-continue.
Original text:
it can request-interact-usercode. The AS determines that interaction is needed and response with a <del> response-interact-usercode.  This could optionally include a URI to direct the user to, but this URI should be static and so could be configured in the client instance's documentation.  The AS also includes information the client instance will need to response- continue in (8) and (10).  The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </del>  The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-

Reviewer comments:
Update all diagrams to use AASVG for rendering in HTML.
To edit notification comments on pull requests, go to your ._

Revised text:
it can request-interact-usercode. The AS determines that interaction is needed and response with a  <ins> response-interact-usercode.  The AS also includes information the client instance will need to response-continue in (8) and (10). The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </ins> The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-
Original text:
any interaction modes to the server, indicating that it does not expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using <del> the request-user. </del>  The AS determines that interaction is needed, but the client instance cannot interact with the RO.  The AS response with the

Reviewer comments:
Update all diagrams to use AASVG for rendering in HTML.
To edit notification comments on pull requests, go to your ._

Revised text:
any interaction modes to the server, indicating that it does not expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using  <ins> the request-user.  It's also possible for the AS to determine which RO needs to be contacted by the nature of what access is being requested. </ins> The AS determines that interaction is needed, but the client instance cannot interact with the RO.  The AS response with the
Original text:
response-token-single, the proof of that key MUST be used when presenting the access token. <del> A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of public keys in security-symmetric. A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key. </del>  Additional key formats are defined in the IANA-key-formats. <del> This non-normative example shows a single key presented in multiple formats.  This example key is intended to be used with the httpsig- binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. </del>  7.1.1.

Reviewer comments:
After discussion with NAME , this PR now makes keys single-format-only as previously suggested.
To edit notification comments on pull requests, go to your ._
Yaron: why are we sending a JWK as well as a cert? Are we checking that the cert contains the same public key as the cert? Justin: I would be OK with the different formats being mutually exclusive somehow. The AS would need to check that they’re the same and throw an error if not. But this would also let the RC send over whatever it’s got for its own keys every time.
The document has been changed to address this issue, copying my text that refers to the latest draft version: In Sec. 7.1 we allow the client to include multiple keys of different formats, provided they are "equivalent". This doesn't make sense, because the only reason to send multiple keys is that the sender suspects that the recipient doesn't understand one of the formats. But if that's the case, the recipient is not able to validate the MUST requirement that the two formats be equivalent. This could also lead to interesting key injection attacks. IMO we should only allow one key value/format for each request.

Revised text:
response-token-single, the proof of that key MUST be used when presenting the access token.  <ins> A key presented by value MUST be a public key and MUST be presented in one and only one supported format, as discussed in security- multiple-key-formats.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of the presentation of public keys in security-symmetric. </ins> Additional key formats are defined in the IANA-key-formats.  <ins> This non-normative example shows a single key presented in two different formats.  This example key is intended to be used with the httpsig-binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. As a JSON Web Key: As a certificate in PEM format: </ins> 7.1.1.