jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-gnap-resource-servers

Commentary: Deploy Preview for gnap - resource - servers - 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-resource-servers

Commentary: : heavycheckmark : Deploy Preview for gnap - resource - servers - editors - draft ready ! Built : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview : 
 A couple of other minor things it sounds to me like an optional step for the RS to validate the signature if the key object is presented in the introspection response . That should be MUST , right ? The third step in section " Token Introspection " states that I think that the AS should validate the RS 's request and only after that the AT 's value . 
 The RS always has to validate the signature , but sometimes it ca n't fully validate it until after it looks up the token 's data using introspection . We should look at what OAuth MTLS and  say in terms of RS validation steps . The intent of the language for the AS validation was not to imply an order in either direction , so we can look to tweak this to make that more clear .
Paragraph (version A):
This specification defines several means for a RS and AS to
communicate these aspects with each other, including structured
access tokens and RS-facing APIs.  This specification also discusses
methods for an RS to derive a downstream token for calling another
chained RS.
Paragraph (version B):
This specification defines several means for an RS and AS to
communicate these aspects with each other, including structured
access tokens and RS-facing APIs.  This specification also discusses
methods for an RS to derive a downstream token for calling another
chained RS.
Paragraph (version A):
When the AS issues an access token for use at an RS, the RS needs to
have some means of understanding what the access token is for in
order to determine how to respond to the request.  The core GNAP
protocol makes no assumptions or demands on the format or contents of
the access token, and in fact the token format and contents are
opaque to the client instance.  However, such token formats can be
the topic of agreements between the AS and RS.
Paragraph (version B):
When the AS issues an access token for use at an RS, the RS needs to
have some means of understanding what the access token is for in
order to determine how to respond to the request.  The core GNAP
protocol makes neither assumptions nor demands on the format or
contents of the access token, and in fact, the token format and
contents are opaque to the client instance.  However, such token
formats can be the topic of agreements between the AS and RS.
Draft: draft-ietf-gnap-resource-servers

Commentary: Expands discussion of RS authentication , with examples . Re - uses structures from client instance auth used in core . Addresses 
 : heavycheckmark : Deploy Preview for gnap - resource - servers - editors - draft ready ! : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview :
Paragraph (version A):
Unless otherwise specified, the RS protects its calls to the AS using
any of the signature methods defined by GNAP.  This signing method
MUST cover all of the appropriate portions of the HTTP request
message, including any body elements, tokens, or headers required for
functionality.
Paragraph (version A):
The AS MAY require an RS to pre-register its keys or could
alternatively allow calls from arbitrary keys, in a trust-on-first-
use model.  The RS MAY present its keys by reference or by value in
the same fashion as a client instance calling the AS in the core
protocol of GNAP I-D.ietf-gnap-core-protocol.
Paragraph (version B):
Unless otherwise specified, the RS MUST protect its calls to the AS
using any of the signature methods defined by GNAP.  This signing
method MUST cover all of the appropriate portions of the HTTP request
message, including any body elements, tokens, or headers required for
functionality.
Paragraph (version B):
The RS MAY present its keys by reference or by value in a similar
fashion to a client instance calling the AS in the core protocol of
GNAP, described in I-D.ietf-gnap-core-protocol.  In the protocols
defined here, this takes the form of the resource server identifying
itself using a "key" field or by passing an instance identifier
directly.
Paragraph (version B):
The AS MAY require an RS to pre-register its keys or could allow
calls from arbitrary keys in a trust-on-first-use model.
Paragraph (version A):
Since the RS is acting as a client instance, the RS MUST identify
itself with its own key in the "client" field and sign the request
just as any client instance would.
Paragraph (version B):
Since the RS is acting as a client instance, the RS MUST identify
itself with its own key in the "client" field and sign the request
just as any client instance would, as described in authentication.
Draft: draft-ietf-gnap-resource-servers

Commentary: Adds registry and discussion for access token formats and where they could be used in the protocol , particularly as part of discovery from the AS . Addresses 
 : heavycheckmark : Deploy Preview for gnap - resource - servers - editors - draft ready ! : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview : 
 Section 3.1 mentions : A sub - section describing the structure of this list of token formats is currently missing . 
 In section 2 . Access Token Formats , the text states : Token formats can be the topic of agreements between the AS and RS , if the AS has prior relationships with every RS . However , it should be mentioned that the access token format can also be negotiated . Add : 
 The negotiation is between the AS and RS , not the client . This spec is about negotiation between the AS and RS .
Paragraph (version A):
When the AS issues an access token for use at an RS, the RS needs to
have some means of understanding what the access token is for in
order to determine how to respond to the request.  The core GNAP
protocol makes no assumptions or demands on the format or contents of
the access token, but such token formats can be the topic of
agreements between the AS and RS.
Paragraph (version A):
Self-contained structured token formats allow for the conveyance of
information between the AS and RS without requiring the RS to call
the AS at runtime as described in introspection.
Paragraph (version B):
When the AS issues an access token for use at an RS, the RS needs to
have some means of understanding what the access token is for in
order to determine how to respond to the request.  The core GNAP
protocol makes no assumptions or demands on the format or contents of
the access token, and in fact the token format and contents are
opaque to the client instance.  However, such token formats can be
the topic of agreements between the AS and RS.
Paragraph (version B):
Self-contained structured token formats allow for the conveyance of
information between the AS and RS without requiring the RS to call
the AS at runtime as described in introspection.  Structured tokens
can also be used in combination with introspection, allowing the
token itself to carry one class of information and the introspection
response to carry another.
Paragraph (version B):
The supported token formats can be communicated dynamically at
runtime between the AS and RS in several places.
Paragraph (version B):
In all places where the token format is listed explicitly, it MUST be
one of the registered values in the GNAP Token Formats Registry iana-
token-format.
Paragraph (version A):
A list of token formats supported by this AS.
Paragraph (version B):
A list of token formats supported by this AS.  The values in this
list MUST be registered in the GNAP Token Format Registry.
Paragraph (version B):
This specification establishes the GNAP Token Format Registry to
define token formats.
Paragraph (version B):
The table below contains the initial contents of the GNAP Token
Format Registry.
Draft: draft-ietf-gnap-resource-servers

Commentary: Expands the discovery document and aligns it with changes made to the discovery process in core . Addresses 
 : heavycheckmark : Deploy Preview for gnap - resource - servers - editors - draft ready ! : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview :
Paragraph (version A):
A GNAP AS offering RS-facing services can publish its features on a
well-known discovery document using the URL ".well-known/gnap-as-rs".
Paragraph (version A):
The URL of the endpoint offering introspection.
Paragraph (version A):
The URL of the endpoint offering resource registration.
Paragraph (version A):
The grant endpoint of the GNAP AS.
Paragraph (version B):
A GNAP AS offering RS-facing services can publish its features on a
well-known discovery document using the URL ".well-known/gnap-as-rs"
appended to the grant request endpoint URL.
Paragraph (version B):
OPTIONAL.  The URL of the endpoint offering introspection.  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.
Paragraph (version B):
The URL of the endpoint offering resource registration.  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.
Paragraph (version B):
REQUIRED.  The location of the AS's grant request endpoint, used
by the RS to derive downstream access tokens.  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 be the same URL used by
client instances in support of GNAP requests.
Paragraph (version B):
OPTIONAL.  A list of the AS's supported key proofing mechanisms.
The values of this list correspond to possible values of the
"proof" field of the key section of the request.
Draft: draft-ietf-gnap-resource-servers

Commentary: closing 
 : heavycheckmark : Deploy Preview for gnap - resource - servers - editors - draft ready ! Built : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview : 
 Added the list of terms 
 Include a reference to the Terminology section of the Core doc . 
 I think we should list out the terminology in question here as well as the general reference .
Paragraph (version B):
Terminology specific to GNAP is defined in the terminology section of
the core specification I-D.ietf-gnap-core-protocol, and provides
definitions for the protocol roles: Authorization Server (AS),
Client, Resource Server (RS), Resource Owner (RO), End-user; as well
as the protocol elements: Attribute, Access Token, Grant, Privilege,
Protected Resource, Right, Subject, Subject Information.  The same
definitions are used in this document.
Draft: draft-ietf-gnap-resource-servers

Commentary: See also related PR at ietf - wg - gnap / gnap - core - protocol 
 Deploy preview for gnap - resource - servers - editors - draft ready ! Built with commit https://deploy - preview-26 - -gnap - resource - servers - editors- 
 Following the review I checked this PR too , seems fine
Paragraph (version A):
This specification defines several means for a RS and AS to
communicate these aspects with each other, including structured
access tokens and RS-facing APIs.  This specification also discusses
methods for an RS to derive a downstream token for calling another
chained RS as well as a client-facing discovery mechanism that can be
used to bootstrap the GNAP process when the client instance does not
know which AS protects a given RS.
Paragraph (version B):
This specification defines several means for a RS and AS to
communicate these aspects with each other, including structured
access tokens and RS-facing APIs.  This specification also discusses
methods for an RS to derive a downstream token for calling another
chained RS.
Paragraph (version A):
The RS MAY make this handle available as part of a rs-request-
without-token or as documentation to developers.
Paragraph (version B):
The RS MAY make this handle available as part of a discovery response
as described in I-D.ietf-gnap-core-protocol or as documentation to
developers.
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 handle SHOULD be sufficient
for at least the action the client instance was attempting to take at
the RS.  The RS MAY use the rs-register-resource-handle to register a
new resource handle, or use a handle that has been pre-configured to
represent what the RS is protecting.  The content of this handle is
opaque to the RS and the client instance in both cases.
Paragraph (version A):
The client instance then makes a call to the "as_uri" as described in
I-D.ietf-gnap-core-protocol, with the value of "access" as one of the
members of the "access" array in the "access_token" portion of the
request.  The client instance MAY request additional resources and
other information, and MAY request multiple access tokens.
Draft: draft-ietf-gnap-resource-servers

Commentary: Deploy preview for gnap - resource - servers - editors - draft ready ! Built with commit https://deploy - preview-1 - -gnap - resource - servers - editors-
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.