AclEntry class

One access-control entry: who the grant is for (subject), the ceiling it is held under (role), where the subject may act (act) and approve (approve), and which capabilities it may exercise (capabilities) and approve (approveCapabilities). The act axis and the approve axis are independent and a consumer MUST resolve them separately: act + capabilities (+ keys) answer "may this subject do X"; approve + approveCapabilities answer "may this subject ratify someone else doing X". Neither implies the other. An entry with act: {scope: none} and an approve scope other than none is a least-privilege approver — able to satisfy an approval and unable to initiate any change.

Constructors

AclEntry({required String subject, required String role, required AuthorityScope? act, AuthorityScope? approve, required CapabilityScope? capabilities, ApproveCapabilityScope? approveCapabilities, String? delegatedBy, required KeyScope? keys, String? label, String? createdAt, String? createdBy, String? updatedAt, String? updatedBy, String? expiresAt, AclEntryStepUp? stepUp, Ext? ext})
const
AclEntry.fromJson(Map<String, dynamic> json)
Read this payload from a decoded JSON object.
factory

Properties

act → Object?
REQUIRED explicit act scope: where this subject may make a change itself. Exactly one of {"scope": "all"} (unrestricted — every context the maintainer has), {"scope": "none"} (may act nowhere), or {"scope": "contexts", "contexts": \[...\]} with at least one context path (the named contexts and, where the maintainer's contexts are hierarchical, their descendants). There is no default and no implicit form: an entry without act, or with an empty contexts list, is malformed and MUST be refused, never read as all and never read as none. A maintainer that has no contexts (for example a community node that narrows authority with resource qualifiers instead) states all or none only. Replaces 0.1's scopes.
final
approve → Object?
OPTIONAL approve scope: where this subject may ratify a change made by someone else (a step-up ratification, a consent decision, an N-of-M approval). Same three shapes as act, resolved independently of it. ABSENT MEANS NONE — the subject may ratify nothing — so a consumer that has not implemented the member confers less than the producer intended, never more. A producer SHOULD state {"scope": "none"} explicitly rather than rely on omission. A subject MUST NOT confer approve authority wider than the approve authority it holds itself (see acl/grant approveWiderThanGranter). Replaces 0.1's approve {all, scopes}.
final
approveCapabilities → Object?
OPTIONAL explicit approvable-capability scope: which capabilities this subject may APPROVE an action needing — independent of what it may do itself, so an approver can ratify a capability it does not hold (the least-privilege approver). One of {"scope": "ceiling"} (the role's full approve ceiling; at a maintainer whose roles define no capability-level approve ceiling, any action within approve), {"scope": "none"}, or {"scope": "listed", "grants": \[...\]} with at least one CapabilityRef (intersected with the role's approve ceiling where one is defined). ABSENT MEANS NONE: the subject may approve no capability, because absence derives no authority. Bounded by approve: where approve is absent or {"scope": "none"} this member confers nothing whatever it states. A subject MUST NOT confer approvable capabilities it cannot itself approve.
final
capabilities → Object?
REQUIRED explicit capability scope: which capabilities this entry holds. Exactly one of {"scope": "ceiling"} (the role's full ceiling, unnarrowed), {"scope": "none"} (no capabilities), or {"scope": "listed", "grants": \[...\]} with at least one CapabilityGrant. For listed, the EFFECTIVE set is (the role's ceiling ∩ the non-additive grants) ∪ the additive grants; it can only narrow the ceiling, except through an explicit additive grant, which only an unrestricted granter may make. There is no implicit form: an entry without capabilities, or with an empty grants list, is malformed and MUST be refused. A non-additive grant outside the role's ceiling is refused when written, never accepted with the capability silently dropped; a capability the consumer does not recognise is never treated as granted. Producers SHOULD NOT list the same (capability, resource) pair twice; a consumer MAY refuse a list that does.
final
createdAt → ResourceQualifier?
final
createdBy → ResourceQualifier?
VID of the party that originally wrote this entry.
final
delegatedBy → ResourceQualifier?
VID of the granter whose authority this entry was delegated from and is bounded by. The entry MUST NOT hold authority the granter did not hold when it was written, and MUST NOT retain authority the granter has since lost, so a maintainer re-evaluates it when the granter's own entry narrows or is removed. Distinct from createdBy, which records who wrote the entry: the two differ where an entry is written on a granter's behalf (for example after an N-of-M approval, or by an offline operator). Set by the maintainer from the granter it authorized; absent on an entry that derives from no granter's authority (the first administrator, an operator-written recovery entry).
final
expiresAt → ResourceQualifier?
Optional time after which the entry confers no authority. Evaluated at every authorization decision, not only when a session is established.
final
ext → Ext?
Ecosystem-defined extension members per SPEC.md §4.5.1. Reverse-DNS-namespaced; consumers MUST ignore unrecognized namespaces. An extension member MUST NOT be interpreted as conferring authority.
final
hashCode → int
The hash code for this object.
no setterinherited
keys → Object?
REQUIRED explicit key scope: which keys this subject may invoke the maintainer's signing oracle on. Exactly one of {"scope": "all"} (every key the entry's act scope reaches), {"scope": "none"} (no keys), or {"scope": "listed", "keys": \[...\]} with at least one key identifier. INTERSECTS WITH act — it can only narrow, never widen: a listed key that lies outside the entry's act scope remains unreachable, exactly as if it were not listed. There is no implicit form: an entry without keys, or with an empty keys list, is malformed and MUST be refused. A maintainer that operates no signing oracle states {"scope": "none"}. Replaces 0.1's allowedKeys, whose absence meant every key.
final
label → ResourceQualifier?
Optional human-readable label. Confers nothing.
final
role → String
Opaque role identifier interpreted by the ACL maintainer. A role is a CEILING, never a grant: it bounds the capabilities the entry may hold and never adds to them. A consumer that does not recognise the role MUST treat the entry as conferring no authority and MUST NOT fall back to a default role. Act scope and role are independent members; a consumer MUST NOT compute either from the other.
final
runtimeType → Type
A representation of the runtime type of the object.
no setterinherited
stepUp → AclEntryStepUp?
Per-entry authentication step-up configuration, consumed by the ACL maintainer when it gates an operation behind a step-up (see auth/step-up/policy). ADDITIVE-ONLY: a per-entry setting MAY raise the assurance required of this subject above the maintainer's system-wide floor, but MUST NOT lower it. The maintainer resolves the effective requirement as the strictest of (system floor, this entry). Carried forward from 0.1 unchanged.
final
subject → String
VID of the party in the ACL. Compared by exact string equality (SPEC.md §4.8); producers SHOULD emit canonical form.
final
updatedAt → ResourceQualifier?
final
updatedBy → ResourceQualifier?
VID of the party that last modified this entry.
final

Methods

noSuchMethod(Invocation invocation) → dynamic
Invoked when a nonexistent method or property is accessed.
inherited
toJson() → Map<String, dynamic>
Serialize to a JSON-encodable map, omitting absent members.
toString() → String
A string representation of this object.
inherited

Operators

operator ==(Object other) → bool
The equality operator.
inherited