Policy
A Policy is a disjunction of Clauses, meaning any satisfied Clause is sufficient to satisfy the Policy. We don't anticipate needing anything sophisticated here, and if we do, this is easily extensible to a complete logical algebra.
Array [
]
clauses
object[]
required
subject
object
required
A Subject is an entity to which access can be granted, such as a dataset.
A dataset which a principal may or may not have access to.
A model definition which a principal may or may not have access to.
A model file which a principal may or may not have access to. In practice, this likely matches the model itself.
A job, in the sense of an async/worker job. Ex: a user may be able to see a fine tune job but not edit/cancel it.
An operation. Ex: a user may be able to see datasets without their full lineage (as operations).
targetPrincipal
object
required
A Principal acting as a Subject to express user management actions and transitive access. See note in Predicate.
organizationRole
object
required
A role specified in the context of a particular organization. Can be used as its own Principal as a convenient way to define groups of permissions.
role
object
required
A role for a principal (likely a user) within an organization. Mostly used for Authorization. Anticipating the need for more roles here, we space out the values to leave unused numbers so that we can add more later while preserving the natural ordering of permissions. We don't prescribe specific authorizations here despite the suggestive names.
"Basic" permissions.
"Editor" permissions.
"Owner" permissions.
When true, this flag dictates that the Subject represents the entire
resource type. The id field must also be a literal "*" or else we should
fail validation, to avoid magic strings or unexpected auth configurations.
A wildcard subject is especially important for creating new resources of a
type (CREATE), and listing (LIST), since in each case there is no existing
ID to base authorization on.