Hi Max, Just to follow up on this point, the proposal here is specifically *not* an API, as we do actually want users to become familiar with their authorization server which they would otherwise be unfamiliar with outside of OAuth flows. It is specifically a URI you open a browser page to, which after authentication allows the user to manage their authorization grants (revoke them) and potentially manage their account (delete, change password, etc).
So FAPI Grant Management is orthogonal to the problem I'm trying to solve here. It does solve a similar thing, but the idea here is to not be granting the client application management permissions, and instead taking them to a trusted page on the AS to perform management. – Emelia > On 18 Nov 2025, at 20:01, Max Gerber <[email protected]> wrote: > > Check out the FAPI Grant Management for OAuth draft - > https://openid.net/specs/oauth-v2-grant-management-ID1.html, which describes > exactly that - API based approaches for management of authorization grants. > My understanding is that the draft isn't under active development anymore, > though someone please correct me if I'm wrong. > > > > On Tue, Nov 18, 2025 at 5:03 AM emelia > <[email protected] > <mailto:[email protected]>> wrote: >> Hi Warren, >> >> The goal isn't to allow clients to completely manage all the users' >> authorization grants via API, but instead to provide a discovery mechanism >> to existing AS user interfaces for this. >> >> If a client wants to manage its own access token & authorization grant, >> there's already the Token Revocation endpoint (RFC 7009) and the Dynamic >> Client Registration Management API (RFC 7592) >> >> If you want an API based approach for MCPs or agentic management of >> authorization grants, I'd suggest you write an internet draft for it, but my >> experience working in trust & safety says that isn't a good idea, as it >> reduces the user's' familiarity with their Authorization Server further. >> >> Yours, >> Emelia >> >>> On 18. Nov 2025, at 09:23, Warren Parad <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> I think we should definitely support ATProto as long as the constructs are >>> consistent with OAuth. In this case, in this case, I believe they are. If I >>> could summarize my understanding it would be: >>> The user owns the AS or has a close association with it >>> The user owns the client RS >>> The user agent is running a generic client that has low control or >>> affiliation with AS other than understanding OAuth >>> The user would like to configure their AS to revoke permissions they have >>> given out >>> In this case the generic client would need so much more than just a url. I >>> would expect something along the lines of: >>> A new AS endpoint url that returns a list of clients and their allowed >>> scopes, GET "Connections" >>> A new AS endpoint url that allows user agents to DELETE Connection >>> A blessed AS scope that can be requested by clients to GET/DELETE >>> Connections oauth:connections:manage >>> This for me feels much more appropriate for the situation. AS providing the >>> mechanism for connection management and then letting the client deal with >>> the configuration and UX, seems aligned with the need and extensible. If we >>> just have the URL for the AS management, that means that the clients would >>> need to direct the user to different connection management pages and have >>> the user deal with the problem manually. When in the browser this isn't so >>> bad, but if you are using a mobile app, or want to delegate this control to >>> another client, you no longer have the ability to do so. A mobile app would >>> need to launch an in app browser or jump out to the system browser to >>> control the flow, and we would be at the mercy of AS that have chosen the >>> appropriate mechanisms for control here. Since the expectation is that >>> generic clients want a way to control the management, this in itself is >>> more aligned to the end goal. Additionally, if we think about the "MCP >>> Agent world" for a moment, this would also enable generic clients to expose >>> the list of permissions that have been granted to LLM like agents through >>> generic clients that interact with LLMs. >>> >>> On Tue, Nov 18, 2025 at 3:42 AM Max Gerber <[email protected] >>> <mailto:[email protected]>> wrote: >>>> I'm sympathetic towards the problem - going back to my Zapier + Gmail >>>> example, having a one-click button from the RS (zapier) to manage the >>>> grant within the AS (google) seems like a very useful thing to have. That >>>> is to say - I do believe there would be adoption outside of the ATProto >>>> ecosystem. >>>> >>>> Some questions: >>>> - Would we want to pass some standardized grant metadata (e.g. >>>> client_id_hint as a query param) back to the AS management UI so that the >>>> AS knows where the user is coming from and what grant they are interested >>>> in? >>>> - How would this field work with something like Cross App Access - where >>>> the grant isn't managed within the AS but within the workforce IDP used to >>>> log in to the AS? Out of scope? RP AS links back to Workforce IDP AS? >>>> >>>> >>>> On Mon, Nov 17, 2025 at 3:47 PM Nick Watson >>>> <[email protected] <mailto:[email protected]>> >>>> wrote: >>>>> I strongly support making authz server management pages more easily >>>>> discoverable by users, as it is a persistent problem. (How many of you >>>>> have visited https://myaccount.google.com/connections before? How did you >>>>> find it?) Putting it in authz server metadata seems like a good start for >>>>> things that can be easily specced out, but it will still be up to the >>>>> client or RS to expose it to users. >>>>> >>>>> I think it would be useful to have some non-normative recommendations for >>>>> how AS, RS, or clients should expose this URL to the users, e.g. on the >>>>> consent page for the AS. ("You're granting these permissions; here's how >>>>> to manage/remove them.") >>>>> >>>>> On Tue, Nov 18, 2025 at 8:36 AM Aaron Parecki >>>>> <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> > 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. >>>>>> >>>>>> "Log in with Google" isn't the right way to look at it, that's why you >>>>>> can't think of a reason you want to do it. A better example would be an >>>>>> app that accesses Google resources, but Google doesn't necessarily have >>>>>> to be the way the user logged in to the app. >>>>>> >>>>>> But the scenario described in this thread is closer to a first-party app >>>>>> anyway because the app _is_ the primary way the user accesses their >>>>>> resources at the API. >>>>>> >>>>>> The only real argument against adding this parameter would be that it >>>>>> isn't actually a generic OAuth problem, like trying to argue that it's >>>>>> actually an ATProto-specific concept. Another example of that would be a >>>>>> Wordpress app that you can point at an arbitrary Wordpress server >>>>>> already needs to know the Wordpress-specific API endpoints to manage >>>>>> content, so this could be treated as another Wordpress-specific endpoint. >>>>>> >>>>>> But clearly both of these scenarios would benefit from the same >>>>>> mechanism, and the OAuth grants _are_ part of OAuth, so it makes sense >>>>>> for it to be an authorization server metadata property. >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 17, 2025 at 3:23 PM Warren Parad <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>>> I think it makes sense for us to fully understand a use case before >>>>>>> just diving in. If we can envision the problem holistically, then we >>>>>>> can ensure that we are designing a forward compatible protocol. It's >>>>>>> always a mistake to "throw one line in the metadata registry", if in >>>>>>> the end it doesn't actually solve the complete problem space. >>>>>>> >>>>>>> That being said, if we are confident that we understand the whole >>>>>>> problem, and most paths it could take in the future, then it does make >>>>>>> sense. But at least, I don't have the confidence to say personally, "I >>>>>>> understand the whole problem". And from what little of the problem I do >>>>>>> understand, it doesn't make sense to me. This just tells me that I >>>>>>> don't understand it well enough like you do. >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> On Tue, Nov 18, 2025 at 12:04 AM Michael Sweet >>>>>>> <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> Warren, >>>>>>>> >>>>>>>> > On Nov 17, 2025, at 4:36 PM, Warren Parad >>>>>>>> > <[email protected] >>>>>>>> > <mailto:[email protected]>> wrote: >>>>>>>> > >>>>>>>> > For sure, it's just the connection from the client to the AS page, >>>>>>>> > that is at least weird for me. >>>>>>>> > >>>>>>>> > Users absolutely want to find this page. I just don't think >>>>>>>> > non-first party clients should be providing that way to make it >>>>>>>> > happen though. Which brings me back to the problem of when would it >>>>>>>> > ever get usage. If we think about all the clients of ATProto being >>>>>>>> > first party apps though, then this makes a lot more sense. >>>>>>>> >>>>>>>> So as a "generic OAuth client" implementor (specifically for CUPS, but >>>>>>>> anyone can use the C API), I am 100% in favor of providing metadata >>>>>>>> that allows my client software to provide "first party" security >>>>>>>> capabilities/functionality for whatever OAuth provider they choose. I >>>>>>>> also don't think adding one line to the IANA metadata registry is a >>>>>>>> big deal, with or without people lining up to support it, but for the >>>>>>>> record I'd support it in CUPS. >>>>>>>> >>>>>>>> ________________________ >>>>>>>> Michael Sweet >>>>>>>> >>>>>> _______________________________________________ >>>>>> 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] <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]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
