Draft: draft-ietf-gnap-resource-servers

Commentary: Updates token introspection definitions into a more full protocol offered by the AS . 
 : heavycheckmark : Deploy Preview for gnap - resource - servers - editors - draft ready ! : hammer : Explore the source changes : : mag : Inspect the deploy log : : sunglasses : Browse the preview : 
 Introspecting a Token :  's note : This is n't super different from the token management URIs , but the RS has no way to get that URI , and it 's bound to the RS 's keys instead of the RC 's or token 's keys . 
 From a privacy point of view , token introspection allows an AS to know exactly when operation(s ) are being performed by an end - user on a RS . This provides useful information for ASs that may be tempted to act as " Big Brother " . For that reason , the risks related to token introspection should be advertised in the Privacy Considerations section . Its usage should be deprecated in the general case . If there exists specific cases where there is no such a risk , these cases should be advertised . 
 The section does n't provide any information on what happens when a client wants to introspect an inactive / invalid / revoked token . 
 Yes , this is pretty thin right now . It 's the RS that introspects the token , and this section will be pulled out into a separate spec to make that more clear ( ) . The response for both positive and negative situations is likely to be based on the OAuth introspection spec ,  
 We should add : the AS MUST validate that the token is appropriate for the RS that presented it , and return an error otherwise . 
 In OAuth token introspection , the AS does n't return an error in this stated case -- it simply says the token presented is not active , in order to prevent information leakage to a nosy RS . 
 I do n't understand your argument about a " nosy RS " . The text states : As a consequence , if the AS does not recognize the signature , it can return a error stating " bad signature " . If the signature is correct , the AS can provide all details to the recognized RS , as yaronf mentioned . 
 s / error / inactive status/. 
 Token Introspection : it is not clear to what depth we are defining the API : is it only the existence of the " introspect " endpoint ? Or do we define a minimal set of standard attributes that need to be returned ? The API would not be useful for interoperability unless we define some of the returned attributes . At the very least : " active " . 
 The idea would be to define a core attribute set with extension points like  . This same attribute set could be used for the token model ( but maybe not format ? ) described in
Paragraph (version A):
The AS responds with a data structure describing the token's current
state and any information the RS would need to validate the token's
presentation, such as its intended proofing mechanism and key
material.  The response MAY include any fields defined in an access
token response.
Paragraph (version B):
REQUIRED.  The access token value presented to the RS by the
client instance.
Paragraph (version B):
RECOMMENDED.  The proofing method used by the client instance to
bind the token to the RS request.
Paragraph (version B):
REQUIRED.  The identification used to authenticate the resource
server making this call, either by value or by reference as
described in authentication.
Paragraph (version B):
OPTIONAL.  The minimum access rights required to fulfill the
request.  This MUST be in the format described in the Resource
Access Rights section of I-D.ietf-gnap-core-protocol.
Paragraph (version B):
was issued by the processing AS,
Paragraph (version B):
has not been revoked,
Paragraph (version B):
is appropriate for presentation at the identified RS.
Paragraph (version B):
The AS responds with a data structure describing the token's current
state and any information the RS would need to validate the token's
presentation, such as its intended proofing mechanism and key
material.
Paragraph (version B):
REQUIRED.  If "true", the access token presented is active, as
defined above.  If any of the criteria for an active token are not
true, or if the AS is unable to make a determination (such as the
token is not found), the value is set to "false" and other fields
are omitted.
Paragraph (version B):
REQUIRED.  The access rights associated with this access token.
This MUST be in the format described in the Resource Access Rights
section of I-D.ietf-gnap-core-protocol.  This array MAY be
filtered or otherwise limited for consumption by the identified
RS, including being an empty array.
Paragraph (version B):
REQUIRED if the token is bound.  The key bound to the access
token, to allow the RS to validate the signature of the request
from the client instance.  If the access token is a bearer token,
this MUST NOT be included.
Paragraph (version B):
OPTIONAL.  The set of flags associated with the access token.
Paragraph (version B):
The response MAY include any additional fields defined in an access
token response and MUST NOT include the access token "value" itself.