specs/acl/shared/v0_1/acl_entry library

Classes

AclEntry: AclEntry
AclEntryApprove: Approve-authority: what this subject may confer on others by ratifying an approval, as distinct from scopes, which is what it may exercise itself. The two axes are independent, and that independence is the point — it is what lets a maintainer configure a least-privilege approver who can authorize an operation in a scope it has no authority to perform. OMISSION MEANS NOTHING IS CONFERRED. An absent approve, an absent all, and an empty scopes are all equivalent to "this subject may ratify nothing". A consumer that does not implement this member therefore confers less than the producer intended rather than more, which is the direction a missed member has to fail in. A subject with approve-authority is NOT thereby authorized to act. Consumers MUST resolve the two axes separately: reading approve to answer "may this party ratify X" and scopes to answer "may this party do X". Collapsing them grants an approver the ability to perform what it was only meant to sign off on.
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/0.1). 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).

AclEntryStepUpRequire: Minimum step-up mode this subject MUST satisfy for gated operations, raising the system floor. self = the subject re-authenticates its own session; delegated = a separate approver MUST ratify. Omitted → the system floor applies unchanged. A value weaker than the resolved floor is ignored (additive-only).

Ext = Map<String, dynamic>: Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.