Post

Sam Goto
@sgo.to

@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!

Sam Goto
@sgo.to

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.

Sam Goto
@sgo.to

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.

Sam Goto
@sgo.to

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?

Sam Goto
@sgo.to

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).

1 repost31 likes

Sam Goto
@sgo.to

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:

Sam Goto
@sgo.to

The "worse case scenario" is when a user is (a) not logged in to any of the "listed idps" and (b) has never "registered" any idp. In which case, they get the following, which I, personally, think is reasonable.

Sam Goto
@sgo.to

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.

Sam Goto
@sgo.to

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.

Ezra🦋
@ezraboeth.com

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-

Ezra🦋
@ezraboeth.com

-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

Ezra🦋
@ezraboeth.com

what would clicking on Bluesky or Blacksky in the list here do? I'm imagining it would show the user the same search bar but filter the search to only users on Bluesky's PDS or Blacksky's PDS, but idk, that feels superfluous maybe