This is sort of why I asked about the full user story, because it isn't clear to me what a user's expectation would be after they "did a thing" in the AS. Sitting and waiting in the AS as a terminal location doesn't make sense to me. In a mobile app, this doesn't really matter, since a user could always just hit the device "back" button, assuming this is an in-app browser. But for system browsers and non-mobile apps, returning the user back to somewhere useful is almost a requirement of a good user experience and not possible with context being passed to the AS. Unless the argument is, "return the user to the referer header value", but I don't think it is.
It's like this annoying and almost useless screen from Google Docs: [image: image.png] I never want to do either of those actions, I want the tab to just close - the end. But chrome doesn't support a tab self close, without the site doing quite some magic, but we won't get into that. There are a lot of better UX options compared to what is provided. The rest of the message is just cognitive overhead. I'm just hoping we won't see the same problem show up for every AS user management screen (or whatever we want to call this). On Tue, Nov 18, 2025 at 8:56 PM Aaron Parecki <aaron= [email protected]> wrote: > I disagree with the need for redirect URI. This is _not_ intended to be a > protocol level thing that somehow ends up with something issued to the > client. It really is as simple as providing the client a way to link out to > a web browser to a specific page on the AS. I could maybe see the argument > for including client ID and some action hint, but I worry that going that > route quickly makes this way more complicated than necessary to be useful. > > On Tue, Nov 18, 2025 at 11:29 AM Warren Parad <wparad= > [email protected]> wrote: > >> That's a fair point, there might be too many things in this list to >> create a handler for each one of them. >> >> From my experience, we would need a lot more than a registry key for the >> AS though, this would need to be a full endpoint that works similar to >> /authorize, and take: >> * Redirect URI - For knowing where to send the user back to "when they >> are done" >> * Client ID - For knowing which client is engaging or requesting this >> * Page Hint / Action - For the action the user wants to do, Password >> Reset, Permission changes, add passkey, etc... Should this list be >> exhaustive? based on the conversation so far, I think it would need to be, >> in order to be the most useful. >> >> I support the draft with the stipulation that these properties like this >> are able to make their way in. >> >> - Warren >> >> On Tue, Nov 18, 2025 at 8:18 PM Michael Sweet <msweet= >> [email protected]> wrote: >> >>> Warren, >>> >>> > On Nov 17, 2025, at 6:22 PM, Warren Parad <wparad= >>> [email protected]> wrote: >>> > ... >>> > Since you have a generic oauth client, would you be able to share more >>> about how that client works, and under which situations you might expect a >>> user to want to navigate to AS that you don't control? Naïvely I look at >>> this as similar to me putting a "Configure all your Google Allowed >>> Applications" button in my app that lets users log in with Google, and I >>> can't think of a reason why I would want to do that. That is "what's the >>> user story?" Would you be able to share the user story you are providing >>> support for, for the users of the implementers of your client? That would >>> be really helpful for me. >>> >>> Some common things a first-party client provides: >>> >>> - Change profile/password/passkey/2FA/etc. info >>> >>> - Monitor/revoke active logins/credentials for things like "I'm in >>> Ontario but somebody in Australia is logged into my account?!?", "I'm still >>> logged in from my old iPhone?", etc. >>> >>> - Delete account >>> >>> Assuming the AS provides a web page for such things, it would be nice >>> for a generic client to be able to provide access to it to perform the >>> above tasks. >>> >>> ________________________ >>> Michael Sweet >>> >>> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
