[Openid-specs-ab] notifications and async responses

[Dick Hardt]

Hey Jeff, the discussion inspired this issue
https://github.com/openid/openid-provider-commands/issues/18

I think it is the OP that should be doing the cost management, not the RP.
The RP can signal to the OP to do an audit_tenant -- and in the response
can include last_access.

Perhaps there may be another or different claim the RP could return to the
OP that is cost related vs access time related.

I believe discussion of this topic will be on the agenda for today's call.
I hope you can join!

/Dick


On Mon, May 12, 2025 at 8:36 AM Jeff LOMBARDO <jeff.lombardo at gmail.com>
wrote:

> > 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/ad37328f/attachment-0001.htm>