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]
