Semantic Permissions

[ripienaar]

Proposed change

We should move to a model where the permissions for consuming from a stream in another account isn’t about listing n permissions but rather just expression a permission like stream_consumer(STREAM) in an ACL and the ACL will do the right thing.

This way as JetStream evolves and more subjects are added or changed the implications on ACLs are hidden from the user. It’s also just much easier.

This can take a number of forms:

• @bruth have made a proposal in this space ADR-32: Logical permissions nats-architecture-and-design#145 to expand the server
• We could turns this into an enhance-client behaviour by allowing each ACL to have a tag or metadata, this way user land tooling can add/remove ACLs and know what are the related set.

The server-side approach is preferable as this would make it much safer for us to develop future features. Today we often run into the scenario of adding a new API is hard because many users have locked down permissions and we do not control those. However if users locked their servers down using this kind of permission where the server expands it to ACLs we could expand to additional ACLs over time.

Use case

Enhance the ability for users to secure their systems without having to be experts on the jetstream implementation details

Contribution

No response