<div dir="ltr">We are off the topic of async responses. <br><br>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.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 10:15 AM Tom Jones <<a href="mailto:thomasclinganjones@gmail.com">thomasclinganjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><font face="-apple-system, system-ui, system-ui, Segoe UI, Roboto, Helvetica Neue, Fira Sans, Ubuntu, Oxygen, Oxygen Sans, Cantarell, Droid Sans, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol, Lucida Grande, Helvetica, Arial, sans-serif" color="#38761d"><span style="font-size:14px;background-color:rgb(242,242,242)">Peace ..tom jones</span></font></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 9:44 AM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We should definitely be considering the UX in the standards.<br><br>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.<br><br>Your use case of converting an account from personal to managed is a different issue. We have yet to discuss how that might happen.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 9:30 AM Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank">thomasclinganjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div>1. The user has not consented to this specific exchange of information about the user.</div><div>2. These transactions only make sense where the user account w/ the OP is work/school, not personal.</div><div>3 When the RP is a SAAS, meaning the RP is billing the OP for its time, this makes economic sense.</div><div>4 Where is goes off the rails is when the user's status with the RP changes.</div><div>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.</div><div>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.</div><div><br></div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><font face="-apple-system, system-ui, system-ui, Segoe UI, Roboto, Helvetica Neue, Fira Sans, Ubuntu, Oxygen, Oxygen Sans, Cantarell, Droid Sans, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol, Lucida Grande, Helvetica, Arial, sans-serif" color="#38761d"><span style="font-size:14px;background-color:rgb(242,242,242)">Peace ..tom jones</span></font></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 9:16 AM Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hey Jeff, the discussion inspired this issue <a href="https://github.com/openid/openid-provider-commands/issues/18" target="_blank">https://github.com/openid/openid-provider-commands/issues/18</a><br><br>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. <br><br></div><div>Perhaps there may be another or different claim the RP could return to the OP that is cost related vs access time related.<br><br>I believe discussion of this topic will be on the agenda for today's call. I hope you can join!</div><div><br></div><div>/Dick<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 12, 2025 at 8:36 AM Jeff LOMBARDO <<a href="mailto:jeff.lombardo@gmail.com" target="_blank">jeff.lombardo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
> 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.
<br><br></div>As shared in the conversation last Thursday, here another scenario for RP notifications.<br><br>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.
</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 9, 2025 at 5:49 PM Dick Hardt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><a href="https://github.com/openid/openid-provider-commands/pull/20" target="_blank">https://github.com/openid/openid-provider-commands/pull/20</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 8, 2025 at 9:17 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 28, 2025 at 9:05 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 27, 2025 at 12:14 PM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I've grouped issues 5 & 7 together as they are related.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Here are links to the issues:<br><br></div><div>notifications</div><div dir="ltr"><a href="https://github.com/openid/openid-provider-commands/issues/7" target="_blank">https://github.com/openid/openid-provider-commands/issues/7</a></div><div dir="ltr"><br><div>202 response for async command processing</div><div><a href="https://github.com/openid/openid-provider-commands/issues/5" target="_blank">https://github.com/openid/openid-provider-commands/issues/5</a></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>