[Openid-specs-ab] notifications and async responses

[Jeff LOMBARDO]

 > 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.

As shared in the conversation last Thursday, here another scenario for RP
notifications.

Having a user account being active for no reason can be the source of large
costs billed by a RP. Having the ability for the RP to notify the OP that
it wants details about an account can help the Owner of the RP to apply a
better logic for cost optimization by determining if the account is active
at the OP. Active here is not  in relation tor Account Lifecycle State but
more about if the Account is Idle or was subject to a valid Authorization
decision recently. "Recently" being a notion evaluated by the RP.

On Fri, May 9, 2025 at 5:49 PM Dick Hardt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> https://github.com/openid/openid-provider-commands/pull/20
>
> On Thu, May 8, 2025 at 9:17 PM Dick Hardt <dick.hardt at gmail.com> wrote:
>
>> I cornered a few people tonight at events and queried preference for
>> opaque URL vs opaque token and fixed endpoint. Opaque tokens were
>> overwhelmingly preferred. I'll be doing PR for that.
>>
>> On Mon, Apr 28, 2025 at 9:05 PM Dick Hardt <dick.hardt at gmail.com> wrote:
>>
>>> 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
>>>>
>>> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250512/fe6d9bd6/attachment.htm>