Isn't it somewhat analogous to the authorization endpoint itself? As in it's a URL that the end user would somehow navigate to using a web browser and the UI for the whole interaction would be provided there? Which would probably be user authentication of some sort (maybe an existing session) and some UI showing all the grants (access a user granted to an app/client) and options to revoke/cancel or maybe modify that access for each. Or am I misunderstanding?
On Mon, Nov 17, 2025 at 1:47 PM Emelia S. <emelia= [email protected]> wrote: > Yeah, service_documentation or homepage_uri, it's not intended for > automating management, but just providing a link to the website at > which the user can manage their account's authorizations. I think > service_documentation is typically the API documentation for the service? > > The property could also be called like service_management_uri or > something, if that makes more sense? > > On 17 Nov 2025, at 21:43, Aaron Parecki <aaron= > [email protected]> wrote: > > I think it's more like the "service_documentation" URL in AS metadata > where it provides a page the user can visit in a browser: > https://datatracker.ietf.org/doc/html/rfc8414#section-2 > > It's not an API endpoint like the FAPI Grant Management API. > > The app would just provide a link to it and open the browser to that URL > so the user can log in and manage their authorizations there. > > > On Mon, Nov 17, 2025 at 12:39 PM Warren Parad <wparad= > [email protected]> wrote: > >> Can I just say, I really hate this is a problem, and I love the idea of >> trying to standardize something here. Because, as a user of many different >> services, where I have in the past given out access to, it's near >> impossible to know where and how to revoke access to some of those things. >> >> One question I have here is, how do you envision connecting from the >> publishing of the *authorization_management_uri*, to it actually being >> used practically? >> >> On Mon, Nov 17, 2025 at 9:11 PM Emelia S. <emelia= >> [email protected]> wrote: >> >>> Hi all, >>> >>> I've recently encountered an issue with OAuth for decentralized social >>> web applications (e.g., those built on AT Protocol), >>> where the user may not be directly familiar with their Authorization >>> Servers' UI because they normally use apps to access >>> their accounts. >>> >>> For instance, many Bluesky users don't know how to access their >>> Authorization Server's management UI for managing >>> which clients have access to their account, as documented in >>> https://github.com/bluesky-social/social-app/issues/9403 >>> >>> This has lead many users on Bluesky to think that App Passwords >>> (effectively additional passwords for their account) >>> are more secure than OAuth, because the Bluesky client application >>> cannot provide a management UI for OAuth clients, >>> since it is not the authorization server. The authorization server is >>> instead bsky.social <http://bsky.social/> when people use bsky.app as >>> the client. >>> >>> I noticed that in the Authorization Server Metadata (RFC8414) there >>> wasn't particularly a relevant property besides maybe >>> homepage_uri (from OpenID Federation) through which to expose the >>> management UI. >>> >>> So I'd like to propose a `authorization_management_uri` property, and >>> have submitted an internet draft to enable discovery >>> of the management UI: >>> https://www.ietf.org/archive/id/draft-emelia-oauth-authorization-management-uri-00.html >>> >>> n.b., I know there's a typo in the security considerations section, I >>> caught it after publishing -00 and didn't want to publish a >>> new version just for changing one word. >>> >>> Yours, >>> Emelia Smith >>> _______________________________________________ >>> 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] >> > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
