Hi Warren, There shouldn't be a redirect URI, as the "next" action is simply to close the page. We don't need to take the user back anywhere because we're opening it in a new page.
For Client ID, I agree that this could be useful to have, and have added an issue to track as client_id_hint. I would be inclined to avoid a page hint / action hint, since this will vary between authorization servers, and I don't really want to be standardizing all the different actions one could possibly take with their authorization server. Instead this would just be a "Manage Account" link (where I'm using "Account" as a more user-friendly word for "Authorization Grant"). We would likely be bikeshedding for a very long time if we were to try to standardize all the actions one can take at an authorization server, and I'd like to avoid that. Yours, Emelia Smith > On 18 Nov 2025, at 20:28, Warren Parad <[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 > <[email protected] <mailto:[email protected]>> > wrote: >> Warren, >> >> > On Nov 17, 2025, at 6:22 PM, Warren Parad >> > <[email protected] <mailto:[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]
