[Openid-specs-ab] notifications and async responses

[Tom Jones]

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/546f8746/attachment.htm>