<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I've grouped issues 5 & 7 together as they are related.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Here are links to the issues:<br><br></div><div>notifications</div><div dir="ltr"><a href="https://github.com/openid/openid-provider-commands/issues/7">https://github.com/openid/openid-provider-commands/issues/7</a></div><div dir="ltr"><br><div>202 response for async command processing</div><div><a href="https://github.com/openid/openid-provider-commands/issues/5">https://github.com/openid/openid-provider-commands/issues/5</a></div></div></div></div></div>