Oauth scopes vs record permissions

Discussion
, , ,
1

i hope this is an alright place to put this, but it was just a thought i had inspired by this tweet

even with oauth scopes, i think that interoperability between applications is a tough problem because i have to fully trust every oauth client that i use with access to record namespaces. so if i have existing bluesky records, and then i want to use a different application which wants to be able to create and delete bluesky records, either i can’t use bluesky features in that application, or i need to trust that it won’t delete all my existing records. i think i read in the proposal for scopes that there are plans for more granular permissions, like the ability to create records but not delete them, but i think that this doesn’t help that much; maybe a bad actor creates a lot of records in an inconvenient manner

so my thought was for oauth to additionally have record permissions, like unix file permissions. each record created by an oauth client would have a top-level field like $type named something like $owner or $creator, inserted by the pds when the record is created, which contains the client_id of the oauth client that made the createRecord request. in order to update or delete records created by a different oauth client, you would need to go through a special oauth flow to give the oauth client temporary sudo privileges. all records created prior to this which don’t have a $owner field would retroactively be considered sudo records. in this way, i could give an application delete privileges to my bluesky records with confidence that they could only mess with records that that application itself created. in the spam example, i think it would just make it a lot easier for someone to write a utility that allows you to bulk delete records created by a given client_id, instead of trying to do an autopsy after the fact to try and figure out which records were spam and which ones were legitimate

also, i think that this is just a neat lil feature which could promote discoverability of alternative clients, which they could try out with a new confidence

if this is already in the works or on the table in a discussion somewhere, well this is my endorsement for that sort of system

5 Likes
2

Yeah, I wish that application client id was encoded as meta-data in records somehow so it could be used as a permission boundary. Being able to express “Smoke Signal can only modify or delete records that it has created” would be pretty handy.

5 Likes
3

It’s a great place to post it!

A lot of people are waiting for OAuth Scopes and then we’re going to have to dig into a lot of this in detail.

1 Like
4

Maybe tie oauth scopes to lexicon NSID’s?

5

This is something we talked about when working on the permissions system. It would indeed be nice to say “this client/session can only update or delete records it created itself”.

Another variation would be “only mutate records newer than the start of the session”.

I don’t think that the metadata about which client/session created a record should be included publicly in records themselves. I know could have some benefits for client developers (it is a form of visibility and promotion of clients, which is fine and good), but the privacy trade-off is too high.

If the metadata is not in the public records, then it needs to be stored in the PDS. That is probably doable, though it makes PDS implementation more complex. One question is whether this is per-session or per-client: per-session would mean the info could be cleared at the end of the session which is nice. In either case, there would need to be a story about account migration between PDS instances: either a mechanism to transfer this metadata (adding complexity to an already very complex system), or it doesn’t (could violate user expectations).

6

I was thinking about it more of an ACL feature. For the sake of argument, consider ACLs to be a PDS-internal data structures that can be managed through XRPC but are effectively off-protocol.

During the record creation process, an additional parameter is provided that says “client-managed”. That would translate to an ACL entry that would limit write and delete operations for that specific AT-URI to OAuth sessions that are associated with the client ID that created the record.