Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Built Explore the source changes : Inspect the deploy log : Browse the preview : 
 Still need to explain better how to do that , will track as part of lifecycle discussion 
 explains how an existing request can be modified by a PATCH request to the continuation endpoint . My question is , what happens if such a PATCH request is sent while the interaction for the associated grant request is not yet finished ? I feel like this should not be allowed , but could not find any information anywhere in Section 5 that this is actually forbidden . Section 5.3 also says that the PATCH request may include post - interaction responses . I assume this means that by specifying an interaction reference in the PATCH request the interaction can be finished by the PATCH request , so the question would be what happens if the interaction is not finished and the PATCH request does not contain an interaction reference ? 
 In Section 3.3.4 it says If the PATCH request is considered a continuation request ( which is reasonable since it is sent to the continuation URI ) , this would prohibit a PATCH request before the interaction finishes . However , if no interaction finish mode is used , this does not apply . 
 I believe the cases are covered ( a PATCH ca n't be done when it is pending ) , even if we could make things clearer probably : using PATCH instead of POST aims to provide better signal / control of when the partial update can be made as part of a continuation request ( and it needs to use the continue access token ) when the client ca n't receive a finish method ( redirect or push ) , then it will need to poll regularly ( cf 5.2 ) 
 Summary from editor 's discussion : The grant process is stateful , a grant goes from ( requested ) -(pending approval ) -(approved ) , at least . The PATCH request only makes sense to an ( approved ) grant , the post - interaction requests only make sense for the ( pending ) grant . We can call out this stateful nature and constrain different requests and inputs to specific states . 
 Proposed solution to make a state diagram and add state description in the overall protocol discussion . 
 Modifying an Existing Request :  's note : The net result of this is that interaction requests are really only meant to be responded to exactly once by the AS . This is n't spelled out explicitly , but could be included in Section 2.5 and/or Section 3.3 . 
 This feeds into the overall discussion of " what can be sent when " and the lifecycle of the grant within the API ; I do think that these artifacts should be one - time - use , especially the nonces .
Paragraph (version A):
The AS SHOULD apply suitable timeouts to any interaction mechanisms
provided, including user codes and redirection URLs.  The client
instance SHOULD apply suitable timeouts to any callback URLs.
Paragraph (version B):
The AS SHOULD handle any interact request as a one-time-use mechanism
and SHOULD apply suitable timeouts to any interaction mechanisms
provided, including user codes and redirection URLs.  The client
instance SHOULD apply suitable timeouts to any callback URLs.