Predicate
A Predicate is either a statement or a query of authorization - when a Principal, Subject, and Scope are specified, it has a positive or negative answer. For example, "can user 4 access resource 9 to write?" or something like "user_4:resource_9:write". When the Principal is omitted, it is a Clause, and can be used to specify an authorization constraint on a resource. For example, simply "resource_9:write", tagging a concrete action with its authorization requirements. When the Subject is itself a Principal, the Predicate expresses a relation between the Principals. For example, an owner user 11 might have write access to a basic user 3, or write access to a whole org. Importantly, the target (subject, scope) must have authorization not greater than the principal, since the predicate enables "impersonation". So, an organization should typically not be authorized to act as an individual user this way, since it would confer the same authorization to every member.
principal
object
required
A Principal is an entity in an authorization context, such as a user requesting read access to a resource or an organization who owns it.
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.
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.