Change:
negotiating the parameters of the request through modification of the request. <ins> 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. The AS MAY make use of long polling mechanisms such as discussed in RFC6202.  Instead of returning the current status immediately, the long polling technique allows the AS additional time to process and fulfill the request before returning the HTTP response to the client instance.  For example, when the AS receives a continuation request but the grant request is in the state, the AS could wait until the grant request has moved to the or state before returning the response message. </ins> 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

Discussion:
To edit notification comments on pull requests, go to your .
It's a continuation of the discussion started in URL which I would like to track as a separate issue. If we want to have that then the client should be able to wait and handle a delayed response say after 60 - 120 seconds, and the client should be able to gracefully handle various timeous (client and from the network infrastructure) and make a subsequent call, and the 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 OAuth2 token endpoint in somewhat similar circumstances. I had some spare time to research this topic a bit deeper and don'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 NAME 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