Draft: draft-ietf-gnap-core-protocol

Commentary: To edit notification comments on pull requests , go to your . 
 It 's a continuation of the discussion started in which I would like to track as a separate issue . If we want to have that then client should be able to wait and handle a delayed response say after 60 - 120 seconds , and client should be able to gracefully handle various timeous ( client and from the network infrastructure ) and make a subsequent call , and client should know what to do with the " wait " field when a timeout occurs in the previous step . I think it could be a great addition to this specification . Furthermore , take a look at and how they leverage the HTTP long polling mechanism . 
 The specification allows using the HTTP long polling mechanism against the  token endpoint in somewhat similar circumstances . I had some spare time to research this topic a bit deeper and do n't have a good answer on how it was possible for me to have the abovementioned specification out of sight . Again , it would be such a great thing to have a bit more instant notification mechanism in the specification core , I mean , not in its extensions or in one or another out of band / vendor - specific solution . 
 I wonder if we can do better than just telling the RC to poll the AS . There are a few options : http long polling , this should " just work " , so long as is defined to allow it ( we had quite extensive discussion over this for CIBA ) webhook , this could be something quite interesting to add in to the spec as it has many other uses . 
 Interesting . We should probably map those technical possibilities to detailed use cases . 
 I believe both of these options are already available . As you say , long polling should just work , and we 'd do well to pull in the lessons learned in CIBA . The " callback " method allows for a " push " notification for post - interaction , which is functionally equivalent to a webhook . The asynchronous authentication example is meant to be just that -- an example of how to accomplish this , not a required combination for that use case . 
 If long polling " just works " , please mention it in the draft as an option . 
 There are still details to check out , like in CIBA long polling , if I remember well , there is a question of delay ( like 30s ) . In practice there might be questions related to how to avoid DDoS. The difference I imagined in webhooks were more related to callbacks not specifically tied to a UI interact , but I 'm not exactly sure which use cases that would cover . Maybe notifications through partner apps , like slack etc . 
 Thanks I 'd missed that . 
 Yep , there are many other uses for webhooks , however I think they may be outside the scope of the core spec . I think the core spec needs to be simplified where possible . Re long polling , I do think it needs to be called out . 
 The example is very useful here
Paragraph (version B):
The ability to continue an already-started request allows the client
instance to perform several important functions, including presenting
additional information from interaction, modifying the initial
request, and revoking a grant request in progress.
Paragraph (version B):
state before returning the response message.
Paragraph (version A):
The ability to continue an already-started request allows the client
instance to perform several important functions, including presenting
additional information from interaction, modifying the initial
request, and getting the current state of the request.