Initial design ideas: #1852 (comment)

Token design concept:

{
    "t": {
        "a": ["ir", "ur", "dr"],
        "d": {
            "fixtures": ["ir", "ur", "dr"]
        },
        "t": {
            "fixtures": {
                "searchable": ["ir"]
            }
        }
    }
}

That JSON would be minified and signed.

Minified version of the above looks like this (101 characters):

{"t":{"a":["ir","ur","dr"],"d":{"fixtures":["ir","ur","dr"]},"t":{"fixtures":{"searchable":["ir"]}}}}

The "t" key shows this is a token that as a default API key.

"a" means "all" - these are permissions that have been granted on all tables and databases.

"d" means "databases" - this is a way to set permissions for all tables in a specific database.

"t" means "tables" - this lets you set permissions at a finely grained table level.

Then the permissions themselves are two character codes which are shortened versions - so:

• ir = insert-row
• ur = update-row
• dr = delete-row

Remaining tasks

• Add these options to the datasette create-token command
• Tests for datasette create-token options
• Documentation for those options at https://docs.datasette.io/en/latest/authentication.html#datasette-create-token
• A way to handle permissions that don't have known abbreviations (permissions added by plugins). Probably need to solve the plugin permission registration problem as part of that
• Stop hard-coding names of actions in the permission_allowed_actor_restrictions function