Post

@thisismissem.social @divy.zone and I recently went through an exploration of how the browser can help you login to websites with atproto accounts. We recently presented to the FedID CG and here is a sneak peek in case you couldn't join! This is early but we'd love your input before we go too far!

First, the happy case scenario, logging in to a website with your atproto account, say lealeft.pub. This is a good end state prompt: one that shows every atproto account you are logged in to (most users would only have one) and allows the user to select one.

Here, leaflet.pub is able to accept both "listed IdPs" (in this case, bluesky, blacksky) as well as "registered IdPs" (in this case, elisabecket.com). The difference between the two is that while the former is enumerated/anticipated by the relying party, the latter is indicated by the user.

The former is important because it allows the relying party to reuse the existing network effects of established IdPs. The latter is critical because in an open federation such as atproto it is impossible for the relying party to enumerate every atproto PDS that exists. But how?

By clicking on "Add another account" in the first prompt. When that happens, the browsers open an account selector, that allows you to add more accounts for "listed IdPs" but also to type your own (the same way you type an email address in an input box).

The mental model I have of this UX is a "search box": you get 0-state suggestions with "listed IdPs" but as you type the browser starts discoverying new IdPs that conform to a search constrain specified by the relying party. Here, the user is offered to add an account based on what they typed:

These are all RP-initated flows (flows in which you start from the RP) but there are a lot of opportunities for IdP-initiated flows too (where the user goes to the IdP ahead of time). Here, we have a variety of different UXes that have all sorts of trade-offs.

The one that I like most is what we've been calling the "save to autofill UX", which looks like this. This would show up when you are logging in to the IdP, say, bluesky.app. It would register the website as an IdP (with the permission of the user) so that it can be automatically discovered later.

There are other variations of registration UIs, such as toasts, modal dialogs and so on, and it is still too soon to know which one will work well!

I’m curious about mobile, specifically android ( don’t know how iOS works). @scottlanoue.com has been playing with the Account Manager service. Will fedcm interact with this android system directly or indirectly? Unidirectionally or bidirectional? Is this convo on the table right now?

I'm not the most familiar with FedCM yet. is there any endpoint or callback that can trigger to the RP (leaflet.pub in this case) when the user types in their handle, where the RP could return a list of entries that should go in this list of IdPs? because the canonical way in atproto to find your-

-provider (PDS) is to make a request to a certain server (plc.directory). that server returns data about the user's provider, and Leaflet could be in charge of making that request, finding the user's provider, and sending it back to the FedCM dialog. although that's kind of a roundabout way to do it

the thing I'm just seeing with the way it is right now is that I'm not sure how FedCM is identifying what IdP (PDS, in this case) the user is using. and if it's not, what if the user chooses wrong? unless I'm missing something @thisismissem.social