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

Commentary: To edit notification comments on pull requests , go to your . _
Paragraph (version A):
from SecureKey. https://verified.me/ [7] Production implementation of
AS, client and RS.  Proprietary license.
Paragraph (version A):
from Bespoke Engineering, implementation by Justin Richer.
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.
Apache 2.0 license.
Paragraph (version B):
from SecureKey. https://verified.me/ [8] Production implementation of
AS, client and RS.  Proprietary license.
Paragraph (version B):
from Bespoke Engineering, implementation by Justin Richer.
https://github.com/bspk/oauth.xyz-java [9] Advanced prototype
implementation of AS, client, and RS in Java, with common support
library.  Prototype implementation of SPA client in JavaScript.
Apache 2.0 license.
Draft: draft-ietf-gnap-core-protocol

Commentary: Built To edit notification comments on pull requests , go to your . 
 [ I - D.ietf - uta-6125bis ] " BROKEN REFERENCE " .
Paragraph (version A):
methods described in I-D.ietf-uta-6125bis), but these are not enough
to establish the identity of the client instance in many cases.
Paragraph (version B):
methods described in I-D.ietf-uta-rfc6125bis, but these are not
enough to establish the identity of the client instance in many
cases.
Draft: draft-ietf-gnap-core-protocol

Commentary: Just two minor typos I stumbled across . 
 Built To edit notification comments on pull requests , go to your .
Paragraph (version A):
If an interaction response-interact-finish method is associated with
the current request, the AS MUST follow the appropriate method at
upon completion of interaction in order to signal the client instance
to continue, except for some limited error cases discussed below.  If
a finish method is not available, the AS SHOULD instruct the RO to
return to the client instance upon completion.
Paragraph (version B):
If an interaction response-interact-finish method is associated with
the current request, the AS MUST follow the appropriate method upon
completion of interaction in order to signal the client instance to
continue, except for some limited error cases discussed below.  If a
finish method is not available, the AS SHOULD instruct the RO to
return to the client instance upon completion.
Draft: draft-ietf-gnap-core-protocol

Commentary: 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  and verify hash . If either fails , return an error . " 
 Built To edit notification comments on pull requests , go to your .
Paragraph (version A):
When receiving the request, the client instance MUST parse the JSON
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.
Paragraph (version B):
When receiving the request, the client instance MUST parse the JSON
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.
Draft: draft-ietf-gnap-core-protocol

Commentary: 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 " .
Paragraph (version A):
If the "hash_method" value is not present in the client instance's
request, the algorithm defaults to "sha3-512".
Paragraph (version A):
For example, the "sha3-512" hash method consists of hashing the input
string with the 512-bit SHA3 algorithm.  The byte array is then
encoded using URL-Safe Base64 with no padding RFC4648.  The resulting
string is the hash value.
Paragraph (version A):
The "sha2-512" hash method consists of hashing the input string with
the 512-bit SHA2 algorithm.  The byte array is then encoded using
URL-Safe Base64 with no padding RFC4648.  The resulting string is the
hash value.
Paragraph (version B):
If the "hash_method" value is not present in the client instance's
request, the algorithm defaults to "sha-256".
Paragraph (version B):
For example, the "sha-256" hash method consists of hashing the input
string with the 256-bit SHA2 algorithm.  The byte array is then
encoded using URL-Safe Base64 with no padding RFC4648.  The resulting
string is the hash value.
Paragraph (version B):
The "sha3-512" hash method consists of hashing the input string with
the 512-bit SHA3 algorithm.  The byte array is then encoded using
URL-Safe Base64 with no padding RFC4648.  The resulting string is the
hash value.
Paragraph (version A):
This is explicitly defined as the signature algorithm specified by
the associated key material and the content digest is calculated
using sha-512.
Paragraph (version B):
This is explicitly defined as the signature algorithm specified by
the associated key material and the content digest is calculated
using sha-256.
Paragraph (version A):
This example uses the ECDSA signing algorithm over the P384 curve and
the SHA-256 hashing algorithm for the content digest.
Paragraph (version A):
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
algorithm MUST be "sha-512".
Paragraph (version B):
This example uses the ECDSA signing algorithm over the P384 curve and
the SHA-512 hashing algorithm for the content digest.
Paragraph (version B):
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
algorithm MUST be "sha-256".
Draft: draft-ietf-gnap-core-protocol

Commentary: 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  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 to HTTP Signatures . Please add a standard value for GNAP messages . 
 LGTM
Paragraph (version B):
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.
Draft: draft-ietf-gnap-core-protocol

Commentary: To edit notification comments on pull requests , go to your . 
 and -- please check these additions to the implementation section .
Paragraph (version A):
implementation by David Skyberg.  https://github.com/dskyberg/gnap
[2].  Prototype implementation of AS and Client in Rust.  MIT
license.
Paragraph (version A):
from Interledger Foundation. https://github.com/interledger/rafiki
[3] Production implementation of AS in JavaScript.  Apache 2.0
license.
Paragraph (version A):
implementation by Aaron Parecki. https://github.com/aaronpk/gnap-
client-php [4] Prototype implementation of web application client and
CLI client in PHP, with common support library.  CC0 license.
Paragraph (version A):
from SUNET. https://github.com/SUNET/sunet-auth-server [5] Production
implementation of AS in Python.  BSD license.
Paragraph (version A):
from Bespoke Engineering, implementation by Justin Richer.
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.
Apache 2.0 license.
Paragraph (version B):
implementation by David Skyberg.  https://github.com/dskyberg/gnap
[2] Prototype implementation of AS and client in Rust.  MIT license.
Paragraph (version B):
from Interop Alliance, implementation by Dmitri Zagidulin.
https://github.com/interop-alliance/gnap-client-js [3] Prototype
implementation of client in JavaScript.  MIT License.
Paragraph (version B):
from Interledger Foundation. https://github.com/interledger/rafiki
[4] Production implementation of AS in JavaScript.  Apache 2.0
license.
Paragraph (version B):
implementation by Aaron Parecki. https://github.com/aaronpk/gnap-
client-php [5] Prototype implementation of web application client and
CLI client in PHP, with common support library.  CC0 license.
Paragraph (version B):
from SUNET. https://github.com/SUNET/sunet-auth-server [6] Production
implementation of AS in Python.  BSD license.
Paragraph (version B):
from SecureKey. https://verified.me/ [7] Production implementation of
AS, client and RS.  Proprietary license.
Paragraph (version B):
from Bespoke Engineering, implementation by Justin Richer.
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.
Apache 2.0 license.
Draft: draft-ietf-gnap-core-protocol

Commentary: To edit notification comments on pull requests , go to your .
Paragraph (version A):
implementation by Aaron Pareckit. https://github.com/aaronpk/gnap-
client-php [4] Prototype implementation of web application client and
CLI client in PHP, with common support library.  CC0 license.
Paragraph (version B):
implementation by Aaron Parecki. https://github.com/aaronpk/gnap-
client-php [4] Prototype implementation of web application client and
CLI client in PHP, with common support library.  CC0 license.
Draft: draft-ietf-gnap-core-protocol

Commentary: To edit notification comments on pull requests , go to your . 
 from " am I right that previous_key becomes immediately invalid ? If it 's true , would n't be nice to have here some way to rotate them more or less gracefully ? It could be useful when there are multiple running instances of the client and it 's tough , or even impossible , to update the keys on all these instances immediately ( just as an example , the client instance could be deployed as a service in  ) . " We 'll handle this via a ( non normative ) security consideration 
 looks good , thank both of you . There was one thing more , an AS may not always allow its client instances to rotate the keys , correct ? Therefore , client instances might " learn " whether it 's possible in advance , during ongoing negotiation with the AS specification may define a dedicated error that will basically tell the client instances , this operation is n't allowed 
 Great addition , needs a bit of tweaking in the wording and one cross link , which I 've here . Will apply and merge .
Paragraph (version B):
Additional security considerations apply when [rotating
keys]{#security-key-rotation}.
Paragraph (version B):
When keys are rotated, there could be a delay in the propagation of
that rotation to various components in the AS's ecosystem.  The AS
can define its own policy regarding the timeout of the
"previous_key", either making it immediately obsolete or allowing for
a limited grace period during which both the "previous_key" and the
current key can be used for signing requests.  Such a grace period
can be useful when there are multiple running copies of the client
that are coordinated with each other.  For example, the client
software could be deployed as a cloud service with multiple
orchestrated nodes.  Each of these copies is deployed using the same
key and therefore all the nodes represent the same client instance to
the AS.  In such cases, it can be difficult, or even impossible, to
update the keys on all these copies in the same instant.
Paragraph (version B):
The need for accommodating such known delays in the system needs to
be balanced with the risk of allowing an old key to still be used.
Narrowly restricting the exposure opportunities for exploit at the AS
in terms of time, place, and method makes exploit significantly more
difficult, especially if the exception happens only once.  For
example, the AS can reject requests from the "previous_key" (or any
previous one before it) to cause rotation to a new key, or at least
ensure that the rotation happens to the same known key.
Paragraph (version B):
See also the related considerations for token values in security-
network-management.
Draft: draft-ietf-gnap-core-protocol

Commentary: This reformats the object - type key proofs to be defined in terms of types , in parallel with interaction start methods . Now instead of default field values , you can have either an object with parameters or a string with strictly specified behavior . This should be less susceptible to confusion than the previous definition which allowed partial objects and implied a large set of possible combinations that the receiver would have to deal with . 
 To edit notification comments on pull requests , go to your . 
 Makes sense , it 's aligned with the behaviour of the rest of the doc
Paragraph (version A):
Individual modes MAY define additional parameters to be required in
the object.
Paragraph (version B):
Interaction start modes are specified by a string, which consists of
the start mode name on its own, or by a JSON object with one required
field and any number of parameters defined by the mode.
Paragraph (version B):
Individual modes defined as objects MAY define additional parameters
to be required in the object.
Paragraph (version A):
Individual methods MAY define additional parameters as members in
this object.
Paragraph (version B):
Individual methods defined as objects MAY define additional
parameters as members in this object.
Paragraph (version B):
This is explicitly defined as the signature algorithm specified by
the associated key material and the content digest is calculated
using sha-512.
Paragraph (version B):
This method is indicated by the method value "httpsig" and can be
declared in either object form or string form.
Paragraph (version B):
This example uses the ECDSA signing algorithm over the P384 curve and
the SHA-256 hashing algorithm for the content digest.
Paragraph (version B):
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
algorithm MUST be "sha-512".
Paragraph (version A):
This method is indicated by the method value "mtls".  This method
defines no additional parameters.  The signer presents its TLS client
certificate during TLS negotiation with the verifier.
Paragraph (version B):
This method is indicated by the method value "mtls" in string form.
Paragraph (version B):
The signer presents its TLS client certificate during TLS negotiation
with the verifier.
Paragraph (version B):
This method is indicated by the method value "jwsd" in string form.
Paragraph (version B):
This method is indicated by the method value "jws" in string form.
Draft: draft-ietf-gnap-core-protocol

Commentary: Built To edit notification comments on pull requests , go to your . _ 
 The discovery process defined in GNAP details how to get information about the AS once you know the grant endpoint and can talk directly to it . We do not cover how to get the grant endpoint , except in the one case of it being provided by the RS at runtime in a response . The core document should at least discuss this gap as intentional , and an extension specification ( or several ) could be written to fill this gap in different circumstances .
Paragraph (version B):
Additional methods of discovering the appropriate grant endpoint for
a given application are outside the scope of this specification.
This limitation is intentional, as many applications rely on static
configuration between the client instance and AS, as is common in
OAuth 2.0.  However, the dynamic nature of GNAP makes it a prime
candidate for other extensions defining methods for discovery of the
appropriate AS grant endpoint at runtime.  Advanced use cases could
define contextual methods for contextually providing this endpoint to
the client instance securely.  Furthermore, GNAP's design
intentionally requires the client instance to only know the grant
endpoint and not additional parameters, since other functions and
values can be disclosed and negotiated during the grant process.
Draft: draft-ietf-gnap-core-protocol

Commentary: Built To edit notification comments on pull requests , go to your . 
 Please take a look a BCP 107 ( a.k.a . RFC 4107 ) . You may need a reference here . Originally posted by in 
 Ok but should this text be updated ? In 2005 , potential quantum threats were not even anticipated ( with impacts on key size for instance ) 
 I think the overall message remains accurate , but you are right that quantum computing was not a concern when RFC 4107 was written . Any updates to RFC 4107 are not part of your task in the GNAP WG . 
 Sure , thanks for the feedback .
Paragraph (version A):
The cryptographic methods used by GNAP for key-proofing can support
both asymmetric and symmetric cryptography, and can be extended to
use a wide variety of mechanisms.  While symmetric cryptographic
systems have some benefits in speed and simplicity, they have a
distinct drawback that both parties need access to the same key in
order to do both signing and verification of the message.  This means
that when the client instance calls the AS to request a token, the AS
needs to know the exact value of the client instance's key (or be
able to derive it) in order to validate the key proof signature.
With asymmetric keys, the client needs only to send its public key to
the AS to allow for verification that the client holds the associated
private key, regardless of whether that key was pre-registered or not
with the AS.
Paragraph (version B):
The cryptographic methods used by GNAP for key-proofing can support
both asymmetric and symmetric cryptography, and can be extended to
use a wide variety of mechanisms.  Implementers will find useful the
available guidelines on cryptographic key management provided in
RFC4107.  While symmetric cryptographic systems have some benefits in
speed and simplicity, they have a distinct drawback that both parties
need access to the same key in order to do both signing and
verification of the message.  This means that when the client
instance calls the AS to request a token, the AS needs to know the
exact value of the client instance's key (or be able to derive it) in
order to validate the key proof signature.  With asymmetric keys, the
client needs only to send its public key to the AS to allow for
verification that the client holds the associated private key,
regardless of whether that key was pre-registered or not with the AS.
Draft: draft-ietf-gnap-core-protocol

Commentary: To edit notification comments on pull requests , go to your . 
 Yaron : " Speculative " access ( " Requesting a Resources With Insufficient Access " ) is not useful if the response is only a MAY . Why would the RC try it if it is unlikely to provide useful information ?  : I think the MAY is not quite the right normative application here . It ’s a MUST if you ’re doing it to do it in this way , but it ’s not a MUST for all RS ’s everywhere to respond in this fashion . If the RC tries calling an RS that does n’t respond with this , the RC simply does n’t know , from any programmatic or automated way , what to do to make the request actually work . Yaron : Sounds like a SHOULD to me - then an RC can assume with reasonable confidence that a random RS will implement it .
Paragraph (version A):
If the client instance calls an RS without an access token, or with
an invalid access token, the RS MAY respond to the client instance
with an authentication header indicating that GNAP needs to be used
to access the resource.  The address of the GNAP endpoint MUST be
sent in the "as_uri" parameter.  The RS MAY additionally return a
resource reference that the client instance MAY use in its access
token request.  This resource reference MUST be sufficient for at
least the action the client instance was attempting to take at the RS
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.ietf-gnap-resource-servers.  The
content of the resource reference is opaque to the client instance.
Paragraph (version B):
If the client instance calls an RS without an access token, or with
an invalid access token, the RS SHOULD respond to the client instance
with a WWW-Authenticate header field indicating that GNAP needs to be
used to access the resource.  The address of the GNAP endpoint MUST
be sent in the "as_uri" parameter.  The RS MAY additionally return a
resource reference that the client instance SHOULD use in its access
token request.  This resource reference MUST be sufficient for at
least the action the client instance was attempting to take at the RS
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.ietf-gnap-resource-servers.  The
content of the resource reference is opaque to the client instance.