specs/acl/update/v0_1/payload
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).
-
Payload
-
Amend the non-role attributes of an existing ACL entry: its label, scopes, allowed
keys, expiry, step-up requirement, or approve-authority. Role changes are NOT
expressible here — they go through acl/change-role, which requires the current role
as a compare-and-swap.
-
PayloadApprove
-
Replacement approve-authority — what the subject may CONFER on others, as distinct
from what it may exercise. Granting or widening this is an escalation vector (a
subject able to confer can manufacture an approver for an operation it could not
authorize), so a consumer SHOULD gate it more strictly than the other members here.
-
PayloadStepUp
-
Replacement per-entry step-up configuration. Same additive-only rule as on the
entry itself: it MAY raise the assurance required of this subject above the system
floor but MUST NOT lower it.
-
Response
-
ACL Update — response payload
Extension Types
-
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).
Typedefs
-
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.
