[Openid-specs-ab] notifications and async responses

Mon May 12 20:57:35 UTC 2025

not sure if you saw this on linked it - i know that are other "claims" but
i insist that agency be bound to the ID

...
As Bobby Burns said “A man's a man for a' that:”
But things change and now any human can be a part of an Enterprise.
As at work or school a human is a part of that Enterprise.
At times the human has full agency, at others a part of something bigger.
That is not the way that human Identifiers on the web ever did work.
Any entity on the internet is simply entity1 at entity2.dns
This confusion of agency must stop.
When you have an Identifier it must be clear on-behalf-of who?
Now OAuth is adding tools to control an identifier.
But if I am my own agent, that is not acceptable.
Here is the proposal - all identifiers must indicate agency.
Then the correspondent can know if the entity is sovereign.
I strongly insist that all digital identifiers include agency labels.
Otherwise the humans on the web will never have agency.
Then we can write laws that apply to human identifiers.
Then we can make data brokers ipso facto illegal.

Peace ..tom jones

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

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