Draft: draft-ietf-gnap-core-protocol

Commentary: for also addresses by requiring that non - continuation access tokens can not be used in continuation requests 
 Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview : 
 Should the access token used for continuation have a more specific label ? From the mailing list : 
 Tangential to terminology discussion in 
 grant token seems like a good name 
 I think it should keep " access " in the name . In OAuth Dynamic Registration we called a similar structure the " Registration Access Token " , maybe this can be the " grant access token " , or " grant API access token " -- with " grant token " for short , even . 
 yes , " grant access token " would be fine too 
 Currently leaning towards " continuation access token " to be used throughout the document . 
 Request Continuation :  's note : Is this a restriction we want to enforce ? 
 Editors suggest moving this text to a security consideration as defining this normatively would define internal behavior to the AS that does not affect interoperability . 
  . we should define security - critical functionality in the body of the protocol , even if it does not affect interoperability . And even if it can not be enforced . 
 Will at least be handled within a dedicated security consideration If we find that we can put normative requirements into the body , we 'll do so . Right now editors feel this specific issue can be closed as it has been referenced in ( need PR to update text ) 
 No , please do n't shovel individual security issues into a " security " uber - issue . is about formal analysis of the protocol , that 's a whole different matter . 
 It seems strange to describe functionality that ca n't be enforced , does it not ? At least for implementers I would see that as an issue more than something that helps . Just to clarify the intent : the suggestion related to 135 is not that we want to put all individual security discussions into a uber - issue , it is that this specific item is fundamentally about the threat model , and so it seems to fit well with a sort of meta requirement . To make the distinction , many security discussions related to keys ( for instance ) have operational consequences in the core of the text , and are managed as specific issues and not in 135 . So we agree with you on " please do n't shovel individual security issues into a " security " uber - issue " , but feel it 's not the case for that specific item . 
 I believe position is to leave the normative requirement as it stands in the text right now , without text changes ( which would mean closing this issue without a PR ) . The editors ' original proposed solution to this issue was to add security considerations about the token but remove the normative requirement because of its lack of enforceability , which would require a PR . The editors ' new comment above is that we will at least add security considerations for this item regardless of what happens with the normative statement . 
 Yes , this is my position . Security - critical statements should be normative , and should be included in the main text where it makes best sense for an implementer . Regardless of enforceability . As a reminder , many cryptographic checks ( the recipient MUST validate this hash / signature / format ) are hard or impossible to enforce . 
 " As a reminder , many cryptographic checks ( the recipient MUST validate this hash / signature / format ) are hard or impossible to enforce . " This is very different as this refers to what the client should / must do . So there 's really an entity that is concerned by the requirement . While in the specific case related to the issue , I really have no idea who 's targeted by the requirement , which seems nothing more than a trust model . I 'm all in favor of making sure security requirements are explicit , but only when it is also clear what to do about them . 
 I do n't understand your point . The AS defines different tokens so that they are trusted for different resources . It can implement this trust different ways : e.g. by marking the tokens differently in its internal database , or by signing different attributes within the JWT that 's the token . This requirement is a constraint on how the AS should manage this authorization . I do n't think it 's a requirement on the Client at all . 
 Maybe I did n't get what you meant by the cryptographic check you 're talking about . But it seems we 're diverging a bit from the original issue . The question is whether we can close this issue as suggested by the editorial team , knowing that we keep in mind your point about making sure security requirements are well defined in the core of the spec . 
 It 's not clear what the team is proposing now . If the proposal is ( 1 ) to make this constraint non - normative and ( 2 ) to move it outside the main text , I disagree with ( 1 ) strongly and with ( 2 ) less strongly ... 
 ( 1 ) MUST here does n't seem directly enforceable . Or we might need to add text to explain what needs to be done about it . ( 2 ) In practice , the proposal would be that it is still be in the main text , but in a dedicated section related to the trust model . 
 See also Let 's rephrase this to the inverse so that it is something that is actually testable . Access tokens other than the continuation access token ( name tbd based on ) MUST NOT be usable for continuation requests . In other words , regular access tokens used for accessing resources MUST NOT be usable for continuation requests .
Mailing list commentary: Hi Fabien , Thanks for the clarification . I think only accepting this kind of token at the continuation is a good idea otherwise the AS would need to be able to parse and understand all sorts of access tokens . Conceptually , I like the idea to treat the continuation as another kind of resource . However , here are some observations I want to share with you : This resource is different as it will issue other access tokens ( of this kind ) to be used in subsequent continuation requests . This requires different handing on the client side . This access token ( if I understand correctly ) is ( or at least feels like ) a handle for the underlying grant . So it is kind of the super access token to obtain other access tokens . I would consider using a different term to refer to this special access token , grant token or grant handle for example , in order to prevent confusion . best regards , Torsten .
Paragraph (version B):
REQUIRED.  A unique access token for continuing the request,
called the "continuation access token".  The value of this
property MUST be in the format specified in response-token-single.
This access token MUST be bound to the client instance's key used
in the request and MUST NOT be a bearer token.  As a consequence,
the "flags" array of this access token MUST NOT contain the string
"bearer" and the "key" field MUST be omitted.  The client instance
MUST present the continuation access token in all requests to the
continuation URI as described in use-access-token.
Paragraph (version A):
To enable this ongoing negotiation, the AS provides a continuation
API to the client software.  The AS returns a "continue" field
response-continue that contains information the client instance needs
to access this API, including a URI to access as well as an access
token to use during the continued requests.
Paragraph (version A):
The access token is initially bound to the same key and method the
client instance used to make the initial request.  As a consequence,
when the client instance makes any calls to the continuation URL, the
client instance MUST present the access token as described in use-
access-token and present proof of the client instance's key (or its
most recent rotation) by signing the request as described in binding-
keys.  The AS MUST validate all keys presented by the client instance
or referenced in an ongoing request for each call within that
request.
Paragraph (version A):
The AS MUST be able to tell from the client instance's request which
specific ongoing request is being accessed, using a combination of
the continuation URL, the provided access token, and the client
instance identified by the key signature.  If the AS cannot determine
a single active grant request to map the continuation request to, the
AS MUST return an error.
Paragraph (version B):
To enable this ongoing negotiation, the AS provides a continuation
API to the client software.  The AS returns a "continue" field
response-continue that contains information the client instance needs
to access this API, including a URI to access as well as a
continuation access token to use during the requests.
Paragraph (version B):
The continuation access token is initially bound to the same key and
method the client instance used to make the initial request.  As a
consequence, when the client instance makes any calls to the
continuation URL, the client instance MUST present the continuation
access token as described in use-access-token and present proof of
the client instance's key (or its most recent rotation) by signing
the request as described in binding-keys.  The AS MUST validate all
keys presented by the client instance or referenced in an ongoing
request for each call within that request.
Paragraph (version B):
Access tokens other than the continuation access tokens MUST NOT be
usable for continuation requests.
Paragraph (version B):
The AS MUST be able to tell from the client instance's request which
specific ongoing request is being accessed, using a combination of
the continuation URL, the provided continuation access token, and the
client instance identified by the key signature.  If the AS cannot
determine a single active grant request to map the continuation
request to, the AS MUST return an error.
Paragraph (version A):
example, if the request is a grant request [42], the AS needs to
compare the TLS client certificate presented at the TLS layer to the
key identified in the request body itself (either by value or through
a referenced identifier).
Paragraph (version B):
example, if the request is a grant request [41], the AS needs to
compare the TLS client certificate presented at the TLS layer to the
key identified in the request body itself (either by value or through
a referenced identifier).