[Openid-specs-ab] notifications and async responses

Mon May 12 17:25:05 UTC 2025

Yes you are correct. But the procol does not recognize that difference.

thx ..Tom (mobile)

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

> 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/6f87d0fc/attachment.htm>