Sketching com.atproto.server.createActorAuth

[zicklag.dev]

@dholms.xyz

I’d also be interested in how com.atproto.server.createActorAuth shows up as an OAuth scope.

Here’s a mock-up of the kind of design I’m thinking of. Any scope that can be requested for your own account can also be requested for accounts that you manage. Hypothetically this could also be optionally restricted further to only include a specific list of accounts that you manage.

When displaying the scopes, if there are any delegated scope requests, then we can show them almost identically to how we would show them normally, but under a heading that indicates that they are being requested not from your account, but from accounts that you have been delegated access to.^[1]

This is not a dramatic increase in complexity. It is a relatively small change that adds nothing else other than an explanatory heading and description and it only shows up when an app requests access to delegated accounts.

I’m not totally sure what the delgated scopes would look like, but maybe they are just a delegated: prefix to an existing scope, for example: delegated:repo:app.bsky.feed.post?action=create.

@dholms.xyz

Could have a group admin go through that OAuth flow per-app and then the application could juggle OAuth credentials and allow non-admin users to use that group credential if they’re authorized to do so.

I think this is a huge downgrade from the experience we have today in the Atmosphere for public data: anybody can login to any app and use their authority in that app just like they could in any other app, if they grant the required OAuth scopes at login time, once.

@dholms.xyz

I assumed that the group host is also a repo host! Like the thing managing group permissions also just hosts & signs all the repos for the group DID. That’s what I mean by the authorizing & target services being the same service.

Yeah, I don’t think that this is excluded by this proposal!

But if you need to make an generic XRPC request under the managed group account, then it may not be hosted on the same server. For example, it might be an AppView. This mechanism allows us to generically represent “another user acting under the authority of the group” irregardless of whether the XRPC destination is hosted on the same server that is authorizing the request.

@ngerakines.me

2. As a community moderator of @dayton-pokemon.club, I want to do things as myself that may have side-effect actions that must be done as the community.

This scenario would benefit from individual calls that are in addition to the active session.

Example: I’m creating a forum post as my identity, but then pinning the post as the community and creating a feed post to circulate it as the community.

I think this is the main use-case we have for general “community” / “org” account features. We want to allow admins, moderators, etc. to create records on the community’s PDS, change group settings, make API calls to other apps’ AppViews under the community’s authority, all without having to log in as the community, or login to every community that they are an admin of.

This is especially important if you have have features impacting the community account that might be granted automatically based on trust levels for instance. It would be nontrivial UX impact if a user that was just promoted up a trust level had to now login to the specific space because they have access to new features.

They really just need to be able to get a token, similar to a space credential, from the DID host, that proves that they are allowed to make a certain XRPC call on behalf of the community’s DID. This is a permission that should be able to be granted directly from the OAuth consent screen on the PDS.

By having com.atproto.server.createActorAuth, we give the PDS a clean way to restrict what an app is allowed to request to be delegated, very similar to service auth. Without a delegated: scope you wouldn’t be allowed to call createActorAuth at all.

Otherwise we’ll just have to keep using our town.muni.arbiter.proxy endpoint which will be one big, dangerous OAuth scope that we must request, granting full access to any of the delegated accounts that you control with no restrictions.

---

In summary, without a protocol change we end up with 3 non-optimal options:

1. Require users exercising delegated authority to login with a new OAuth consent screen for every community they manage, for every app they use to manage it and re-doing that if sessions expire.
2. Require apps to take on the responsibility of authorization for the community, and white-list the apps that are allowed to act on behalf of the community.
3. Request access to delegated accounts at login time, but without being able to restrict the scope of that delegation at all. This is like going back to the transition:generic days when it comes to delegated accounts.

Private data is already requiring protocol changes, and one of the very first things we need immediately after having it is the ability for people to cleanly act on behalf of the community’s account, so I think this should be under consideration.

---

1. Note that this is completely compatible with permission sets. On the call we talked about not wanting to allow people to mislead on the OAuth screen with permissions sets, since in the current design they are properly checked based on NSID. This preserves that. ↩︎