[Openid-specs-ab] notifications and async responses

[Dick Hardt]

I was going to do a PR of this -- anyone have any pros / cons for a fixed
OP endpoint and an opaque access token vs an opaque URL?

On Thu, Mar 27, 2025 at 12:14 PM Dick Hardt <dick.hardt at gmail.com> wrote:

> I've grouped issues 5 & 7 together as they are related.
>
> The idea behind notifications is for the RP to be able to send the OP a
> notification. One reason for notifications is if the RP wants to request
> the OP to send a command. This can happen if the RP changes its
> configuration, or wants the OP to perform an audit because it is not sure
> it is in sync.
>
> The other motivation came out of exploring the RP processing a command
> async. This came up in a discussion with a Drupal implementor. Deleting a
> user in Drupal is an async process as they don't want to block the PHP
> response as deletion can be time consuming. The deletion is put into a
> queue that is processed asynchronously. If supported, we would like a way
> for the RP to signal to the OP the result of the processing of the Command
> -- another notification.
>
> If the Command is processed asynchronous, then the RP provides a 202
> response. I'm lending towards normative text that an RP SHOULD respond
> asynchronously if it can. I think async responses only make sense for
> Account Commands. The implication is that an RP that is not able to do
> synchronous deletes like Drupal, would not support `delete_tenant` -- an OP
> would need to delete each account individually.
>
> Here are links to the issues:
>
> notifications
> https://github.com/openid/openid-provider-commands/issues/7
>
> 202 response for async command processing
> https://github.com/openid/openid-provider-commands/issues/5
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250428/07afd896/attachment.htm>