I’m currently working on a UI redesign for https://colibri.social. As part of this redesign, I need to take the requirements of app stores into consideration. One of these requirements is to allow users to delete their accounts from within the app, or link to a website where they can do so. As Colibri uses fine-grained OAuth scopes, we can’t have users manage their account from within the app, so we want to link to the account management page of the PDS itself. The problem is that said page may not always be at the same location. The reference PDS uses /account, Tranquil redirects from there, but other PDS implementations 404 at that path. Could the com.atproto.server.describeServer endpoint potentially include a link for where to send people to manage their ATproto account? Should it even be the place for this, or should it be advertised some other way?
Absolutely think this is something we should do. Clients redirecting out to the proper place for account management seems the most sensible solution to the “every app is reimplementing account management” issue. Especially as PDSs themselves gain more features that can’t be expressed inside the com.atproto XRPC APIs. I think it’s also a good way to start getting people more comfortable with the fact that their atproto account isn’t tied to a single app.
If I remember correctly @thisismissem.social mentioned somewhere that there is some standard property for this for the OAuth AS metadata document? I think this is a more appropriate place than describeServer as the account management interface is conceptually part of the AS not the PDS itself (even if the PDS is often the AS).
+1, 100% should be a standard route/path on each PDS, have been saying this for years. it should be in the PDS spec/docs, but in the meantime, getting indiedevs who govern/implement their own PDSs to adopt in advance of that would be worth attempting. no idea if the proposed record is the best possible place to hide a pointer in a repo, but my personal preference would be for not needing a pointer at all and having it be deterministically derivable from the PDS value in the DID Doc… maybe a pointer is a good fallback and legacy-support mechanism until that’s realized, tho.
I don’t have particularly strong feelings about the mechanism. We might want something that isn’t OAuth-specific, and then the OAuth auth server could “also” include the URL in that metadata? I do think we probably need something configurable (vs a fixed path).
Some design questions:
can the account page be on any domain/origin? or only on the PDS host or auth service origin? my intuition is usually to lock things down instead of being fully flexible to start, though I don’t have any particular reasoning for that here. I folks could always HTTP redirect if they need to.
does it need to be possible to template in the account identifier (eg DID) in to the URL path? or maybe this could be an optional “hint” query param?
should we define a fallback behavior in the specification? if so, should it be /account or something less generic?
should we allow separate URLs for “manage existing account” versus “sign up for an account”? or keep it simple and assume that the former could link to the later
I would mention for the sake of comparison that the ActivityPub has no such “same origin” requirement, and exactly because it doesn’t, many interesting things (probably not anticipated by many of the spec’s authors at the time) are now possible, such as splitting static content from dynamic content or even hosting static content on other protocols (e.g. ipfs:///{cid}), as outlined in this specification. (Full disclosure, that work was partially supported with a grant from the Filecoin Foundation). I would actually lobby NOT to impose a same-domain rule here, to allow similar distributions of labor and economies of scale (e.g., all accounts hosted by hosting-co.example, even did:web and BYO-handle accounts, using pds.hosting-co.example for the PDS endpoints but byo-handle.example for the account manager, etc etc).
Similarly, the did templating in a URI path gets annoying fast even if you drop the :s (same problem as the URI scheme), particularly if did:web stays supported forever and non-ASCII characters/internationalization are supported (cough, cough, JAPAN). query param seems like a good idea for this. Usually one of the main gotchas with query params is privacy/observability of GET URLs, but probably a non-issue in this usecase.