jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : 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 .
Paragraph (version A):
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
possesses, or both an access token and key proof together.
Paragraph (version B):
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
possesses (aka, a "key proof"), or both an access token and key proof
together.
Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Built Explore the source changes : Inspect the deploy log : Browse the preview : 
 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 !
Paragraph (version A):
REQUIRED for multiple access tokens, OPTIONAL for single access
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
AS and the "split" field is included and set to "true".
Paragraph (version B):
REQUIRED for multiple access tokens, OPTIONAL for single access
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
AS and the "split" flag is used.
Draft: draft-ietf-gnap-core-protocol

Commentary: 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 : Inspect the deploy log : Browse the preview :
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-ietf-gnap-core-protocol

Commentary: Expands on discussion in 
 Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview :
Paragraph (version A):
User reference identifiers can be dynamically response-dynamic-
handles to allow the client instance to represent the same end-user
to the AS over subsequent requests.
Paragraph (version A):
If the client instance has a reference for the end-user at this AS,
the client instance MAY pass that reference as a string.  The format
of this string is opaque to the client instance.
Paragraph (version B):
The AS can identify the current end-user to the client instance with
a reference which can be used by the client instance to refer to the
end-user across multiple requests.  If the client instance has a
reference for the end-user at this AS, the client instance MAY pass
that reference as a string.  The format of this string is opaque to
the client instance.
Paragraph (version B):
One means of dynamically obtaining such a user reference is from the
AS returning an "opaque" subject identifier as described in response-
subject.  Other means of configuring a client instance with a user
identifier are out of scope of this specification.
Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Built Explore the source changes : Inspect the deploy log : Browse the preview : 
 Good catch , thanks !
Paragraph (version A):
servers.  The content of the resource handle is opaque to the client
instance.
Paragraph (version B):
servers.  The content of the resource reference is opaque to the
client instance.
Draft: draft-ietf-gnap-core-protocol

Commentary: missing changelog entries reordered key proofing methods , changed notional example signature methods to use httpsig throughout release -06 [ release ] prepare for next release 
 : heavycheckmark : Deploy Preview for gnap - core - protocol - editors - draft ready ! : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview :
Paragraph (version A):
This non-normative example shows a single key presented in multiple
formats.  This key is intended to be used with the detached-jws
proofing mechanism, as indicated by the "proof" field.
Paragraph (version B):
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.
Paragraph (version A):
If the "bound" value is the boolean "true" 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).
Paragraph (version A):
If the "bound" value is the boolean "true" and the "key" value is an
object as described in key-format, the access token MUST be sent
using the key and proofing mechanism defined by the value of the
"proof" field within the key object.
Paragraph (version A):
If the "bound" value is the boolean "false", the access token is a
bearer token that MUST be sent using the "Authorization Request
Header Field" method defined in RFC6750.
Paragraph (version B):
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).
Paragraph (version B):
If the "flags" field does not contain the "bearer" flag and the "key"
value is an object as described in key-format, the access token MUST
be sent using the key and proofing mechanism defined by the value of
the "proof" field within the key object.
Paragraph (version B):
If the "flags" field contains the "bearer" flag, the access token is
a bearer token that MUST be sent using the "Authorization Request
Header Field" method defined in RFC6750.
Paragraph (version A):
The client software MUST reject as an error a situation where the
"bound" value is the boolean "false" and the "key" is present.
Paragraph (version B):
The client software MUST reject as an error a situation where the
"flags" field contains the "bearer" flag and the "key" field is
present with any value.
Draft: draft-ietf-gnap-core-protocol

Commentary: To align with secevent draft 8 which DIDs 
 : heavycheckmark : Deploy Preview for gnap - core - protocol - editors - draft ready ! : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview :
Paragraph (version A):
In this example, the AS is returning only a pair of response-subject
as both an email address and an opaque identifier.
Paragraph (version B):
In this example, the AS is returning set of response-subject,
simultaneously as an opaque identifier, an email address, and a
decentralized identifier (DID).
Draft: draft-ietf-gnap-core-protocol

Commentary: remove OAuth DPoP binding . Described why on IETF mailing list : OAuth PoP : expired draft , due to be replaced with new draft based on HTTP Message Signatures . Also closing and 
 : heavycheckmark : Deploy Preview for gnap - core - protocol - editors - draft ready ! : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview : 
 Removed autoindent in my editor to fix the issue 
 OAuth Proof of Possession ( PoP ):  's note : This is a stale draft from the OAuth working group , but it does at least provide some basic functionality for protecting HTTP messages with a signature . This work is likely to be subsumed by the general - purpose HTTP message signature mechanism in Section 8.5 . 
 OAuth Proof of Possession ( PoP ):  's note : This is in contradiction to the referenced spec which makes this field mandatory .
Paragraph (version A):
The "b" (body hash) field MUST be calculated and included, if the
message includes an entity body (such as a PUT or PATCH request).
Paragraph (version A):
All components of the URL MUST be calculated and included,
including query parameters "q", path "p", and host "u".
Paragraph (version A):
The verifier MUST parse the JWS object of the PoP header.  The
verifier MUST validate the signature of the header against the
expected key of the signer.  The verifier MUST ensure that all
required parts of the message are covered by the signature.  The
verifier MUST ensure that all components of the signature contain
correct values.
Draft: draft-ietf-gnap-core-protocol

Commentary: 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 : : 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
Paragraph (version A):
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.
Paragraph (version A):
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.
Draft: draft-ietf-gnap-core-protocol

Commentary: 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 : : mag : Inspect the deploy log : : sunglasses : Browse the preview : 
 Yes , makes sense
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Draft: draft-ietf-gnap-core-protocol

Commentary: : heavycheckmark : Deploy Preview for gnap - core - protocol - editors - draft ready ! : hammer : Explore the source changes : : 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 ! 
 I 've reached out to them if there 's a good URL to reference , and them to the ack section ( I should have done that before ! ) .
Paragraph (version A):
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.
Paragraph (version B):
There is no padding or whitespace before or after any of the lines,
and no trailing newline character.
Draft: draft-ietf-gnap-core-protocol

Commentary: 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 https://deploy - preview-247 - -gnap - core - protocol - editors- 
 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 
 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 : 
 This information is important to the draft 's readership , and people are not seeing it ( e.g. ,  '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 .
Paragraph (version A):
This protocol solves many of the same use cases as OAuth 2.0 RFC6749,
OpenID Connect OIDC, and the family of protocols that have grown up
around that ecosystem.  However, GNAP is not an extension of OAuth
GNAP seeks to provide functionality and solve use cases that OAuth
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.
Paragraph (version B):
This protocol solves many of the same use cases as OAuth 2.0 RFC6749,
OpenID Connect OIDC, and the family of protocols that have grown up
around that ecosystem.  However, GNAP is not an extension of OAuth
GNAP seeks to provide functionality and solve use cases that OAuth
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.
Draft: draft-ietf-gnap-core-protocol

Commentary: 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 https://deploy - preview-245 - -gnap - core - protocol - editors- 
 Well spotted .
Paragraph (version A):
Meanwhile, the client instance loads the continuation information
stored at (3) and continue-request.  The AS determines which
ongoing access request is referenced here and checks its state.
Paragraph (version B):
Meanwhile, the client instance loads the continuation information
stored at (2) and continue-request.  The AS determines which
ongoing access request is referenced here and checks its state.
Draft: draft-ietf-gnap-core-protocol

Commentary: Suggested changes for 
 Deploy preview for gnap - core - protocol - editors - draft ready ! Built with commit https://deploy - preview-226 - -gnap - core - protocol - editors- 
 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 . 
 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
Paragraph (version B):
The type header, value "gnap-binding+jwsd".
Paragraph (version B):
The type header, value "gnap-binding+jws".
Draft: draft-ietf-gnap-core-protocol

Commentary: … alue should be the boolean false . Please , correct me if I wrong . 
 Deploy preview for gnap - core - protocol - editors - draft ready ! Built with commit https://deploy - preview-209 - -gnap - core - protocol - editors- 
 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 
 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 .
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy preview for gnap - core - protocol - editors - draft ready ! Built with commit https://deploy - preview-208 - -gnap - core - protocol - editors- 
 It may make sense to change the order to something like = = & & is present = = & & is absent = = = = & & is present 
 I did changes for There are lots of other things that , I believe , could be improved & changed for the " Presenting Access Tokens " section and they will be addressed in separate PRs in the future . 
 Thank you , this is great !  with the language in
Paragraph (version A):
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
method is associated with the key.  This information is conveyed in
the "key" and "proof" parameters in response-token-single.
Paragraph (version A):
If the "key" value is the boolean "false", the access token is a
bearer token sent using the HTTP Header method defined in RFC6750.
Paragraph (version A):
The form parameter and query parameter methods of RFC6750 MUST NOT be
used.
Paragraph (version A):
If the "key" value is the boolean "true", 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).
Paragraph (version B):
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
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.
Paragraph (version B):
If the "bound" value is the boolean "true" 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).
Paragraph (version B):
If the "bound" value is the boolean "true" and the "key" value is an
object as described in key-format, the access token MUST be sent
using the key and proofing mechanism defined by the value of the
"proof" field within the key object.
Paragraph (version B):
If the "bound" value is the boolean "false", the access token is a
bearer token that MUST be sent using the "Authorization Request
Header Field" method defined in RFC6750.
Paragraph (version B):
The "Form-Encoded Body Parameter" and "URI Query Parameter" methods
of RFC6750 MUST NOT be used.
Paragraph (version B):
The client software MUST reject as an error a situation where the
"bound" value is the boolean "false" and the "key" is present.
Draft: draft-ietf-gnap-core-protocol

Commentary: These changes with with with in Detached JWS and Attached JWS sections . 
 Deploy preview for gnap - core - protocol - editors - draft ready ! Built with commit https://deploy - preview-207 - -gnap - core - protocol - editors- 
 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 .
Paragraph (version B):
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.
Paragraph (version B):
To protect the request, the JOSE header MUST contain the following
additional parameters.
Paragraph (version A):
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".
Paragraph (version B):
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".
Paragraph (version B):
To protect the request, the JWS header MUST contain the following
additional parameters.