[Openid-specs-ab] notifications and async responses

Mon May 12 17:28:05 UTC 2025

There are different values for the tenant claim

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

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