[Openid-specs-ab] notifications and async responses

[Dick Hardt]

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/20250327/5295cb3e/attachment.htm>