Draft: draft-ietf-gnap-core-protocol

Commentary: adds a paragraph to the introduction adds specific examples under roles 
 Deploy preview for gnap - core - protocol - editors - draft ready ! Built with commit https://deploy - preview-254 - -gnap - core - protocol - editors-
Paragraph (version B):
The focus of this protocol is to provide interopability between the
different parties acting in each role, and is not to specify
implementation details of each.  Where appropriate, GNAP may make
recommendations about internal implementation details, but these
recommendations are to ensure the security of the overall deployment
rather than to be prescriptive in the implementation.
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
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.
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
likely 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 A):
For another example, an AS could likewise be built out of many
constituent components in a distributed architecture.  The component
that the client instance calls directly could be different from the
component that the the RO interacts with to drive consent, since API
calls and user interaction have different security considerations in
many environments.  Furthermore, the AS could need to collect
identity claims about the RO from one system that deals with user
attributes while generating access tokens at another system that
deals with security rights.  From the perspective of GNAP, all of
these are pieces of the AS and together fulfill the role of the AS as
defined by the protocol.
Paragraph (version B):
In these cases, the distinct components of what is considered a GNAP
client instance may use any number of different communication
mechanisms between them, all of which would be considered an
implementation detail of the client instances and out of scope of
GNAP.
Paragraph (version B):
For another example, an AS could likewise be built out of many
constituent components in a distributed architecture.  The component
that the client instance calls directly could be different from the
component that the RO interacts with to drive consent, since API
calls and user interaction have different security considerations in
many environments.  Furthermore, the AS could need to collect
identity claims about the RO from one system that deals with user
attributes while generating access tokens at another system that
deals with security rights.  From the perspective of GNAP, all of
these are pieces of the AS and together fulfill the role of the AS as
defined by the protocol.  These pieces may have their own internal
communications mechanisms which are considered out of scope of GNAP.