[Openid-specs-ab] notifications and async responses

Mon May 12 17:20:47 UTC 2025

We are off the topic of async responses.

OP Commands has a tenant concept in an OP, and the concept that a tenant
can be for "personal" accounts, so the same OP can serve both users that
personally manage their account, and users where the account is managed by
an organization. Either way, I do care about the user experience. There is
a difference in which entity controls the account.

On Mon, May 12, 2025 at 10:15 AM Tom Jones <thomasclinganjones at gmail.com>
wrote:

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