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 : 
 client requests to RS w/o access token should be covered in core ( client - facing protocol ) See also 
 Requesting a Resource With Insufficient Access :  's note : This borrows heavily from UMA 2 's " distributed authorization " model and , like UMA , might be better suited to an extension than the core protocol . 
 I 'm in favour of this being in the core protocol . I do n't think it adds that much complexity and it opens up a whole world of different deployment options . 
 First , the sentence at the top of this section is broken : . Second , I think this is a complicated decision : The RC is more likely to assume it will receive a useful response if this is in the core document rather than an extension . There may be privacy issues with the RS reporting the AS URI for a particular resource . Which would argue against including it in the core protocol . 
 It is definitely something that would be hard to make " mandatory to implement " . I would like to see it included but not mandated for all deployments . 
 Yaron : 3.4 : " updated_at " : Unix time is nice , but for absolute time it 's common to use ISO 8601 format .  : I stole this field from OIDC , but I ’m fine with any format here , so if there ’s no outcry we should change it in the next revision . 
 This has been changed to ISO 8601 format in
Paragraph (version B):
This specification focuses on the portions of the delegation process
facing the client instance.  In particular, this specification
defines interoperable methods for a client instance to request,
negotiate, and receive access to information facilitated by the
authorization server.  This specification also discusses discovery
mechanisms for the client instance to configure itself dynamically.
The means for an authorization server and resource server to
interoperate are discussed in the companion document, I-D.draft-ietf-
gnap-resource-servers.
Paragraph (version A):
When neither an access token nor key proof are used, this is an
unsecured request.  This type of request is not used in the core
protocol of GNAP.
Paragraph (version B):
When neither an access token nor key proof are used, this is an
unsecured request.  This type of request is used optionally for
calls to the RS as part of an RS-first discovery process as
described in rs-request-without-token.
Paragraph (version B):
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.draft-ietf-gnap-resource-
servers.  The content of the resource handle is opaque to the client
instance.
Paragraph (version B):
The client instance then makes a request to the "as_uri" as described
in request, 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.  The client instance MAY request multiple access tokens.
Paragraph (version B):
In this non-normative example, the client instance is requesting a
single access token using the resource reference "FWWIKYBQ6U56NL1"
received from the RS in addition to the "dolphin-metadata" resource
reference that the client instance has been configured with out of
band.
Paragraph (version B):
If issued, the resulting access token would contain sufficient access
to be used at both referenced resources.