Draft: draft-ietf-gnap-resource-servers

Commentary: Deploy preview for gnap - resource - servers - editors - draft ready ! Built with commit https://deploy - preview-11 - -gnap - resource - servers - editors-
Paragraph (version A):
The core GNAP protocol does not define any one specific mechanism for
the resource server (RS) to communicate with the authorization server
(AS), allowing the connection between these components to be solved
orthogonally to the core protocol's concerns.  For example, the RS
and AS roles could be fulfilled by the same piece of software with
common storage, obviating the need for any connecting protocol.
However, it is often desirable to have the RS and AS communicate at
runtime for a variety of purposes, including allowing the RS to
validate and understand the rights and privileges associated with a
grant of access represented by an access token issued by (AS), or
negotiating the capabilities of either party.  These types of
connections are particularly useful for connecting an AS and RS from
different vendors, allowing interoperable distributed deployments of
GNAP-protected systems.
Paragraph (version B):
The core GNAP protocol does not define any one specific mechanism for
the resource server (RS) to communicate with the authorization server
(AS), allowing the connection between these components to be solved
orthogonally to the core protocol's concerns.  For example, the RS
and AS roles could be fulfilled by the same piece of software with
common storage, obviating the need for any connecting protocol.
However, it is often desirable to have the RS and AS communicate at
runtime for a variety of purposes, including allowing the RS to
validate and understand the rights and privileges associated with a
grant of access represented by an access token issued by the AS, or
negotiating the capabilities of either party.  These types of
connections are particularly useful for connecting an AS and RS from
different vendors, allowing interoperable distributed deployments of
GNAP-protected systems.
Paragraph (version A):
The AS validates the access token value and the client instance's
request and returns the introspection response for the token.
Paragraph (version B):
The AS validates the access token value and the Resource Server's
request and returns the introspection response for the token.
Paragraph (version A):
While it is possible to use a [token format]{#structure} that allows
for the RS to generate its own secondary token, the AS can allow the
RS to request this secondary access token using the same process used
by the original client instance to request the primary access token.
Since the RS is acting as its own client instance from the
perspective of GNAP, this process uses the same grant endpoint,
request structure, and response structure as a client instance's
request.
Paragraph (version B):
While it is possible to use a structure that allows for the RS to
generate its own secondary token, the AS can allow the RS to request
this secondary access token using the same process used by the
original client instance to request the primary access token.  Since
the RS is acting as its own client instance from the perspective of
GNAP, this process uses the same grant endpoint, request structure,
and response structure as a client instance's request.