I'd certainly accept some language along these lines, I tried to keep the language focused only on providing a discovery mechanism for this page, as to not prescribe anything to Authorization Servers.
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.") The only SHOULD is around native apps & not opening this URI in a webview, since that could allow the client application to exfiltrate the user's actual credentials.
But yeah, I think the AS should probably provide UI telling people how they can manage authorization grants during the OAuth flow, but I suspect that might be an orthogonal concern? – Emelia 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.") > 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.
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!
Warren,
> On Nov 17, 2025, at 4:36 PM, Warren Parad <wparad=[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]
To unsubscribe send an email to [email protected]
|
