[Openid-specs-ab] notifications and async responses

Mon May 12 17:15:45 UTC 2025

I think you miss the point.  You cannot serve both man and mammon at the
same time. If you take a user oriented approach you will not be able to
talk about him behind his back. If you take the mammon side you really
don't care about the user. I know exactly the who, what, where, when and
how this decision was made by John Shewchuck.  I hated the choice then and
I hate it now. But I understand why you make it.
Peace ..tom jones

On Mon, May 12, 2025 at 9:44 AM Dick Hardt <dick.hardt at gmail.com> wrote:

> We should definitely be considering the UX in the standards.
>
> last_access may be useful in a consumer scenario where the OP wants to
> help the user know they have an account somewhere they are not using and
> that they (the user) can have their data at an RP deleted.
>
> Your use case of converting an account from personal to managed is a
> different issue. We have yet to discuss how that might happen.
>
>
> On Mon, May 12, 2025 at 9:30 AM Tom Jones <thomasclinganjones at gmail.com>
> wrote:
>
>> I know that these standards generally are created with no consideration
>> of UX, but I can't help but point out that ugly stuff happens when the
>> status of the poor user is manipulated behind the user's back.
>> 1. The user has not consented to this specific exchange of information
>> about the user.
>> 2. These transactions only make sense where the user account w/ the OP is
>> work/school, not personal.
>> 3 When the RP is a SAAS, meaning the RP is billing the OP for its time,
>> this makes economic sense.
>> 4 Where is goes off the rails is when the user's status with the RP
>> changes.
>> 5 I have a specific use case where the user gets screwed by this
>> ability.  I once used a computer as a gig worker and got labeled as a work
>> account. I no longer work for the RP, but the OP doesn't know that. I
>> cannot now download the free version of Visual Studio because I am now
>> labeled as a work account and not a personal account. I have no way to fix
>> the problem other than creating a new persona or flatten the computer or
>> who-know-what to become personal again.
>> 6 As a general rule the user should be able to know when information
>> about them is exchanged and this violates that principle.  The status of
>> the user is not indicated in the protocol. This ambiguity works against the
>> user's interests.
>>
>>
>> Peace ..tom jones
>>
>>
>> On Mon, May 12, 2025 at 9:16 AM Dick Hardt via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> 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
>>>>>
>>>> _______________________________________________
>>> 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/e415fe1d/attachment.htm>