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 <[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 > <[email protected] <mailto:[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. >> <[email protected] >> <mailto:[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 >>> <http://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] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
