search

ietf-wg-gnap / gnap-core-protocol

141 stars 26 forks source link

delayed responses from the AS and the HTTP long polling mechanism #404

Closed adeinega closed 1 year ago

adeinega commented 2 years ago

It's a continuation of the discussion started in https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/388#issuecomment-1049243339 which I would like to track as a separate issue.

I always wondered if it's allowed for the AS to provide a "delayed" response, or in other words, leverage the HTTP long polling mechanism just like for this response with the continue field.

Of course, there will be definitely upsides and downsides to it.

See https://datatracker.ietf.org/doc/html/rfc6202 for more info.

If we want to have that then

  1. the client should be able to wait and handle a delayed response say after 60 - 120 seconds, and
  2. the client should be able to gracefully handle various timeous (client and from the network infrastructure) and make a subsequent call, and
  3. 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 Poll-Based Security Event Token (SET) Delivery Using HTTP (RFC 8936) and how they leverage the HTTP long polling mechanism.

adeinega commented 2 years ago

The OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 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.