Membership roles carry permissions that nothing checks #29

New Issue

2026-09-21T07:18:10Z

cgalo5758 commented

2026-09-21 07:18:10 +00:00

The question

The database seeds roles that carry detailed permission lists, and signing up writes memberships and assignments against them. No server code reads a permission to decide anything: every authorization in the console comes from the session and the one application role carried in the identity provider's token. Are the seeded permissions a contract the console is meant to grow into, or a shape it inherited and should drop?

What depends on the answer

Whether membership roles become the place where access inside an organization is decided, or whether the columns go and the rule stays "one role in the token, one audience behind the operator pages". Until it is settled a reviewer can read a permission list and believe a route is guarded when nothing guards it.

Options known so far

Enforce them: a permission check at the handlers that act inside an organization, with the seeded lists as the vocabulary.
Remove them: keep roles as a label on a membership and delete the permission arrays, so nothing suggests a gate that does not exist.

The identity model upstream describes the richer scheme, so the answer is taken with it rather than against it.

Decided when

The identity model says what a membership role decides, and the console either checks the permissions or no longer stores them.

Migrated from status/issues.md at b7a0e15

## The question The database seeds roles that carry detailed permission lists, and signing up writes memberships and assignments against them. No server code reads a permission to decide anything: every authorization in the console comes from the session and the one application role carried in the identity provider's token. Are the seeded permissions a contract the console is meant to grow into, or a shape it inherited and should drop? ## What depends on the answer Whether membership roles become the place where access inside an organization is decided, or whether the columns go and the rule stays "one role in the token, one audience behind the operator pages". Until it is settled a reviewer can read a permission list and believe a route is guarded when nothing guards it. ## Options known so far - Enforce them: a permission check at the handlers that act inside an organization, with the seeded lists as the vocabulary. - Remove them: keep roles as a label on a membership and delete the permission arrays, so nothing suggests a gate that does not exist. The identity model upstream describes the richer scheme, so the answer is taken with it rather than against it. ## Decided when The identity model says what a membership role decides, and the console either checks the permissions or no longer stores them. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

design

area/identity security labels 2026-09-21 07:18:10 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#29