Right, so the issue here Warren is that we don't have _any_ first-party clients. The PDS is literally just a data storage server and an authorization server. There's no blessed client application for it.
Hence, we need some way for other third-party clients to discover the URI at which the PDS's authorization management UI lives. — Emelia > On 17 Nov 2025, at 22:36, Warren Parad <[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. > > On Mon, Nov 17, 2025 at 10:26 PM Aaron Parecki <[email protected] > <mailto:[email protected]>> wrote: >> Yes, a page at the AS that lists all the authorized clients. >> >> It is extremely common for an AS to have this page today. It is typically >> linked to from first-party OAuth clients. You can find plenty of examples of >> that in the wild. >> >> The new thing here is that the decentralized model of OAuth used by ATProto >> and others means there is less of a concept of first-party apps now. There's >> typically a primary app a user uses, but different users with accounts at >> the same AS might be using different apps primarily. >> >> It's not about giving a way for a client to manage/revoke its own consent, >> it's about giving the user a way to find this page at the AS. >> >> >> >> On Mon, Nov 17, 2025 at 1:21 PM Warren Parad <[email protected] >> <mailto:[email protected]>> wrote: >>> It feels like the cardinality is off for me. But it's probably because I'm >>> missing something. Are we talking about the page for the AS or for the >>> Service Clients? >>> >>> I think we are talking about an AS page. And then as an AS page, I don't >>> think it makes sense for a client to link to a page that displays all >>> clients. If a client wants to enable easy access for a user to do >>> something, they can provide their own pages in their own app, that is >>> outside of the OAuth as a protocol. I could imagine a client metadata page >>> service_documentation to make it available for user agents to automatically >>> open that, and control configuration. And that's an interesting thought, >>> but feels orthogonal to the issue raised here. >>> >>> That is, I don't think it is the AS responsibility to enable service >>> clients to better display a UX for the user, given that the UX we are >>> concerned with is an AS level concept. >>> >>> And I really like Brian's point: >>>> 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? >>> >>> What is wrong with the authorize endpoint? Maybe the thought could be that >>> the authorize endpoint doesn't make it easy to remove existing permissions >>> because we are missing an oauth mode. But in that circumstance, why would >>> the client need to make it easy to remove a permission it actually needs? >>> But I suppose if it did, this would be again an AS level interaction, and >>> some flavor of the authorize endpoint, and potentially a new parameter >>> would make more sense to me. >>> >>> So maybe back to the question, are we talking about a page that lists all >>> clients and their configuration? I wouldn't expect Clients to link to that, >>> nor for it to ever want to send a user there. A page for the specific >>> client in question and their configuration? I like the authorize endpoint >>> for that, maybe (new idea for me, but I'm willing to go along with it for >>> the moment 😀) >>> >>> On Mon, Nov 17, 2025 at 10:04 PM Emelia S. >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Ah, sure, so I emphasize that service_documentation says "human-readable >>>> information that developers might want to know", i.e., it's not a >>>> user-facing website. >>>> >>>> Instead the idea here is that clients would provide a link in their UI to >>>> the authorization_management_uri that for native apps would open in the >>>> users' default browser (not in a webview or embedded browser) and for web >>>> apps would open in a new tab (target="_blank") and this website would >>>> first authenticate the user before showing them a list of their current >>>> sessions and authorized applications, and possibly allow things like >>>> managing their password or login credentials. >>>> >>>> For example, this is the Bluesky PDS implementation's UI, which is located >>>> at bsky.social/account <http://bsky.social/account> (however, this URL is >>>> dependent on where your PDS is hosted) >>>> >>>> <Screenshot 2025-11-17 at 21-59-26 Your account.png> >>>> >>>> This is the same page in Keycloak: >>>> >>>> <PastedGraphic-1.png> >>>> >>>> Hopefully this helps? >>>> >>>> — Emelia >>>> >>>>> On 17 Nov 2025, at 21:52, Warren Parad <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Emelia, the reason I ask, is because without a clear expectation on how >>>>> anyone would come to find out about the link, or what they would do with >>>>> this link, the service_documentation is already an existing attribute in >>>>> the spec, as Aaron linked. Is there a reason you wouldn't see this as >>>>> sufficient for the end goal: >>>>> service_documentation >>>>> OPTIONAL. URL of a page containing human-readable information >>>>> that developers might want or need to know when using the >>>>> authorization server. In particular, if the authorization server >>>>> does not support Dynamic Client Registration, then information on >>>>> >>>>> how to register clients needs to be provided in this >>>>> documentation. >>>>> >>>>> >>>>> On Mon, Nov 17, 2025 at 9:47 PM Emelia S. <[email protected] >>>>> <mailto:[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 >>>>>>> <[email protected] >>>>>>> <mailto:[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] <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]
