Change:
determine a single active grant request to map the continuation request to, the AS MUST return an error. <del> 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. </del> All requests to the continuation API are protected by this bound continuation access token.  For example, here the client instance makes a POST request to a stable continuation endpoint URI with the

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