JEP Action Mandate Profile (JEP-AMP)

Introduction JEP-Core defines signed J/D/T/V events and the minimum protocol semantics of Delegation. A Core-valid D event records a delegation statement, but does not by itself establish that the delegator possessed authority, that the delegatee may execute an action, or that a relying party should permit the action. JEP-AMP-2 defines a profile for one narrower use of D: a bounded action mandate. The central profile question is: The local decision to permit an external action remains a relying-party or domain-policy decision. JEP Profiles defines the general profile-selection, composition, trust, acceptance, and profile-specific-check model. JEP Conformance defines validation-result and test-harness conventions used by this profile. Where this document conflicts with JEP-Core, JEP-Core controls.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Terminology

Action Mandate A signed JEP Delegation event whose what value conforms to the Action Mandate Descriptor defined by this profile.

Mandate Identity The Event Identity (who,id) of the JEP Delegation event that issues the mandate. Mandate Identity is the canonical logical identifier of an AMP-2 mandate.

Mandate Artifact Hash The JEP Event Hash of one exact signed representation of the issuance event. The Mandate Artifact Hash is not the Mandate Identity.

Issuer The actor identified by the issuance event's who member. The issuer is not automatically authorized to act for the principal.

Principal The person, organization, account, tenant, legal entity, or other subject on whose behalf the delegated action is to be attempted.

Delegatee The actor identified by what.delegatee.

Mandate Status A profile-level result indicating whether the mandate satisfies the AMP-2 requirements for the requested evaluation context. The initial values are valid, invalid, and indeterminate.

Action Decision A local relying-party decision about whether an external action should be allowed, denied, reviewed, or deferred. Action Decision is not a global JEP-AMP conclusion.

Profile Identifier and Versioning The profile identifier for this version is: The short name JEP-AMP-2 MAY be used in user interfaces and documentation. The identifier is an HTTPS URI under a publisher-controlled namespace. It is not an IANA-registered URN namespace value. Implementations MUST compare the profile identifier as the exact URI string defined above. Dereferencing the URI is not required for validation, although publishers SHOULD keep the URI stable and SHOULD make profile documentation available there when practical. JEP-AMP-1 used urn:jep:profile:amp:1. AMP-2 changes mandate identity, reference, validation, and Core-alignment semantics in non-compatible ways. Therefore AMP-2 uses a new profile identifier rather than silently changing the meaning of AMP-1. An AMP-2 producer binds profile selection by including the exact profile identifier in the signed Action Mandate Descriptor.

Relationship to JEP-Core JEP-AMP-2 relies on JEP-Core for:

the D event object;
required id, who, when, what, and sig members;
Event Identity (who,id);
Event Hash;
signing-payload and signature semantics;
aud;
ref;
extension processing;
independent validation checks;
validation modes;
idempotent acceptance.

JEP-AMP-2 MUST NOT redefine any of those semantics. JEP-Core idempotent acceptance prevents one Event Identity from applying the same acceptance effect more than once within one acceptance domain. AMP mandate usage or consumption is a different concept. A single mandate may authorize zero, one, or multiple external action attempts according to this profile and local policy. Implementations MUST NOT treat Core already_accepted as equivalent to "mandate consumed".

Action Mandate Descriptor

Encoding For the AMP-2 baseline profile, the Action Mandate Descriptor is the JEP D event's what object. The descriptor MUST therefore include the Core-required D members delegatee and scope. AMP-2 does not define a detached descriptor encoding. External policy, credential, evidence, receipt, or domain objects MAY be referenced from the descriptor or from JEP references, but the authoritative AMP-2 descriptor itself is signed inline as what. A future extension MAY define a detached representation, but it MUST preserve the Core-required signed D semantics and define conflict resolution.

Required Members An AMP-2 Action Mandate Descriptor MUST contain:

profile
principal
delegatee
action
target
scope
validity

The required members have the following baseline shapes:

profile MUST be a string equal to https://humanjudgment.org/jep/profiles/amp/2.
principal MUST be an object containing a non-empty string id. principal.type MAY be present as a non-empty string.
delegatee MUST be a non-empty string actor identifier.
action MUST be an object containing a non-empty string type. action.type MUST be an absolute URI identifying the action or action family. A domain profile MAY define additional members of action.
target MUST be an object containing non-empty string members type and id. A domain profile MUST define the identifier and matching semantics for the target type it uses.
scope MUST be a non-empty JSON object. A domain profile MUST define the meaning and comparison rules for any scope members that affect an Action Decision.
validity MUST be an object containing expires_at. validity.expires_at MUST be an RFC 3339 date-time . validity.not_before MAY also be present and, if present, MUST be an RFC 3339 date-time.

If validity.not_before is absent, AMP-2 imposes no profile-level lower time bound. A relying party MAY impose a local or domain-specific lower bound, but MUST NOT derive trusted start time solely from the JEP when value. A mandate whose expires_at precedes not_before is invalid. The descriptor MUST NOT add new top-level members beyond those defined by this document or a later compatible AMP revision. Additional extensibility MUST use JEP ext / ext_crit or referenced profile-defined objects rather than a second descriptor-level extension namespace.

Optional Members The descriptor MAY contain:

mandate_id
constraints
usage
policy_ref
authority_evidence
delegation
termination

mandate_id, when present, MUST be a non-empty string application-level alias. It MUST NOT replace Mandate Identity for cross-system logical references. constraints, when present, MUST be a JSON object. If absent, AMP-2 imposes no additional constraint set beyond the required action, target, scope, validity, and applicable policy rules. policy_ref, when present, MUST be a non-empty array of objects. Each object MUST contain a non-empty uri string identifying the applicable policy or policy document. Absence of policy_ref means that the mandate itself declares no external policy reference; local policy MAY still apply. authority_evidence, when present, MUST be a non-empty array of references. Each reference MUST use JEP reference semantics or a reference form explicitly defined by the active authority profile. No descriptor-level extensions member is defined by AMP-2. Extension data belongs in JEP ext / ext_crit or in referenced profile-defined objects.

Action action MUST be an object and MUST contain the required type member defined in Section 6.2. action.type identifies the action or action class. AMP-2 does not define a global action taxonomy. A domain profile MUST define the semantics and request-matching rules for each action type it uses. Additional members of action MAY be defined by the active domain profile.

Target target MUST be an object and MUST contain the required type and id members defined in Section 6.2. The target identifies the object, resource, record, account, workflow, case, transaction, or other domain object to which the mandate applies. A domain profile MUST define the target identifier, normalization, comparison, and matching rules used for Action Decision.

Scope scope MUST be a non-empty JSON object and MUST be machine-processable under the applicable domain profile. It MAY include purpose, work-unit, resource, tenant, geography, data-boundary, or other domain limits. A relying party MUST NOT infer a broader scope merely because a requested action uses the same action type or target family. A domain profile MUST define comparison rules for every scope member that can change an Action Decision.

Constraints constraints MAY define amount limits, data limits, resource sets, vendor sets, customer sets, risk limits, approval thresholds, or other boundaries. A domain profile MUST define comparison rules for any constraint that affects Action Decision.

Usage If usage is absent, AMP-2 imposes no profile-level use-count limit. Local or domain policy MAY still impose a limit. If usage is present, it MUST be an object containing max_uses. usage.max_uses MUST be a positive integer. usage.reservation_required MAY be present as a boolean. If absent, its value is false. A max_uses value of 1 defines a single-use mandate at the AMP layer. Usage counting and consumption state MUST NOT be inferred from Core idempotent acceptance. A relying party MUST still enforce max_uses safely. Deployments requiring concurrent or distributed use control MUST provide an atomic or equivalent reservation/consumption mechanism, regardless of the value of reservation_required.

Authority Evidence authority_evidence MAY reference evidence that the issuer is authorized to issue or convey the mandate on behalf of the principal. If the principal is distinct from the issuer, a Mandate Verifier MUST NOT report issuer authority as pass without applicable authority evidence or a selected policy/profile rule that establishes that authority. If the principal and issuer identifiers are the same, actor binding may be sufficient for a self-principal deployment only when the active profile or local policy explicitly permits that interpretation.

Delegation Controls If delegation is absent, subdelegation is not allowed. If delegation is present, it MUST be an object containing the boolean member subdelegation_allowed. If subdelegation_allowed is false, no child mandate is permitted under AMP-2. If subdelegation_allowed is true:

max_depth MUST be present and MUST be a positive integer;
scope_expansion_allowed MAY be present as a boolean and defaults to false;
constraint_relaxation_allowed MAY be present as a boolean and defaults to false;
the parent-reference rule defined by this document applies;
any parent-termination effect on child eligibility MUST be explicitly defined by the parent descriptor or active domain profile.

AMP-2 has no implicit parent-termination cascade rule. If a child mandate is permitted, its issuance event MUST reference the parent Mandate Identity using a typed JEP event reference. An exact parent artifact MAY additionally be pinned by Event Hash. Unless scope_expansion_allowed is explicitly true, child scope MUST be equal to or narrower than parent scope. Unless constraint_relaxation_allowed is explicitly true, child constraints MUST be equal to or stricter than parent constraints. Even when expansion or relaxation is permitted by the descriptor, the active domain policy MAY still reject it.

Termination Controls If termination is absent, the issuance actor is the default authorized terminator. If termination is present, it MUST be an object. It MAY contain authorized_terminators. authorized_terminators, when present, MUST be a non-empty array of non-empty string actor identifiers. Only actors permitted by this list and any stricter active policy may satisfy the AMP termination-status check as an authorized terminator. Expiry under validity.expires_at does not require a T event.

Minimal Descriptor Example The DID identifiers are illustrative only.

Mandate Issuance An AMP-2 mandate is issued by one JEP D event. The issuance event:

MUST conform to JEP-Core 0.7 or a later compatible Core revision;
MUST have verb equal to D;
MUST carry an AMP-2 descriptor in what;
MUST have what.profile equal to https://humanjudgment.org/jep/profiles/amp/2;
MUST have what.delegatee and what.scope;
SHOULD use aud when the mandate is intended for a bounded audience;
MAY use ref to identify a parent mandate or another context whose relationship is explicitly defined;
MUST NOT claim that AMP-2 alone establishes global legal authorization.

The issuance Event Identity is the canonical Mandate Identity. The issuance Event Hash identifies only the exact signed issuance artifact.

Mandate References

Logical Reference A JEP event referring to an AMP-2 mandate SHOULD reference the issuance Event Identity. Conceptually:

Exact Artifact Pin When the exact signed issuance artifact matters, the reference MAY additionally pin the issuance Event Hash. A validator MUST verify an exact-artifact pin when the active validation context requires reference_integrity.

Application Alias A mandate_id alias MAY be indexed or displayed by applications. A relying party MUST NOT substitute mandate_id for Mandate Identity unless a domain mapping explicitly defines that mapping and collision behavior.

Mandate Termination

Termination Event An AMP-2 termination declaration is a JEP T event that:

has verb equal to T;
uses a typed JEP event reference in ref whose value equals the Mandate Identity;
has what.termination_scope equal to https://humanjudgment.org/jep/profiles/amp/2#mandate-reliance;
is signed and Core-validated;
is issued by an actor authorized by the mandate or applicable profile.

The T event MAY include a profile-defined reason such as revoked, consumed, superseded, completed, policy_change, or constraint_violation.

Profile-Level Effect A conforming Mandate Verifier that observes an authorized AMP-2 termination event in the applicable evaluation context MUST treat the referenced mandate as ineligible for future reliance in that context. This is an AMP profile rule. The JEP T event itself does not delete history, retroactively invalidate prior events, or prove that every downstream system has observed or enforced the termination.

Expiry After validity.expires_at, the mandate is invalid for new AMP reliance even if no T event exists. Expiry is evaluated from the mandate validity rule and the time source chosen by the active profile or relying party. The issuance event's JEP when value alone is not trusted wall-clock evidence.

Reservation, Usage, and Consumption

Separation from Core Acceptance Core acceptance answers whether the same JEP Event Identity has already applied the same acceptance effect in one acceptance domain. AMP usage answers whether a mandate has remaining authorized uses. These are independent state machines and MUST NOT be conflated.

Single-Use and Bounded-Use Mandates When usage.max_uses limits use, the relying party MUST maintain sufficient usage state to avoid permitting more uses than allowed. For concurrent or distributed relying parties, a domain profile SHOULD define an atomic reservation or consumption mechanism.

Reservation A reservation record SHOULD bind:

Mandate Identity;
requested action and target;
request digest when available;
reserving actor;
reservation time;
optional reservation expiry;
reservation outcome.

A reservation MAY be recorded by a profile-defined V event or by an external domain record referenced from a JEP event.

Consumption A consumption record SHOULD bind:

Mandate Identity;
receipt or evidence reference;
consuming actor or relying party;
consumed use count;
consumption time;
terminal reason when applicable.

A T event with reason consumed MAY record a declaration that no future reliance is intended. It does not by itself provide the concurrency guarantee required to prevent double consumption.

AMP Validation Model

Layer Separation AMP-2 distinguishes:

JEP-Core validation status;
AMP Mandate Status;
local Action Decision.

A valid JEP signature is not sufficient for Mandate Status valid. Mandate Status valid is not a global authorization decision.

Profile-Specific Checks The following provisional AMP-2 check identifiers are defined:

https://humanjudgment.org/jep/profiles/amp/2#profile-binding
https://humanjudgment.org/jep/profiles/amp/2#descriptor
https://humanjudgment.org/jep/profiles/amp/2#issuer-authority
https://humanjudgment.org/jep/profiles/amp/2#delegatee
https://humanjudgment.org/jep/profiles/amp/2#time-validity
https://humanjudgment.org/jep/profiles/amp/2#audience
https://humanjudgment.org/jep/profiles/amp/2#termination-status
https://humanjudgment.org/jep/profiles/amp/2#usage-status
https://humanjudgment.org/jep/profiles/amp/2#request-scope
https://humanjudgment.org/jep/profiles/amp/2#subdelegation
https://humanjudgment.org/jep/profiles/amp/2#evidence
https://humanjudgment.org/jep/profiles/amp/2#policy

Check statuses use the JEP conformance values:

pass
fail
not_checked
not_applicable
unsupported
indeterminate

AMP-2 does not define a cumulative validation level.

Mandate Status For the requested AMP validation context:

valid means every required AMP check passed or was not applicable;
invalid means at least one required AMP check failed;
indeterminate means no required check failed but at least one required check is unsupported, not checked, or indeterminate.

A validator MUST report which checks were required and which statuses were obtained.

Baseline Validation Flow A Mandate Verifier SHOULD:

validate the issuance event under JEP-Core;
confirm that the event is D and what.profile is the AMP-2 identifier;
validate the descriptor structure;
confirm what.delegatee and what.scope;
evaluate issuer/principal authority under the active trust or policy profile;
evaluate validity time using the applicable time source;
evaluate aud when required;
resolve relevant authorized termination declarations;
evaluate usage or reservation state when applicable;
evaluate requested actor, action, target, scope, and constraints;
evaluate subdelegation rules when applicable;
evaluate required evidence, approvals, and policy;
return Core status, AMP check results, and Mandate Status separately.

A validator MUST NOT report Action Decision allow solely because Mandate Status is valid.

Verification Events A JEP V event MAY record an AMP evaluation. The V event MUST satisfy JEP-Core V requirements, including ref, verification_scope, and result. A profile-defined AMP verification scope SHOULD use a collision-resistant identifier derived from the AMP-2 profile identifier. Examples include:

https://humanjudgment.org/jep/profiles/amp/2#mandate-validation
https://humanjudgment.org/jep/profiles/amp/2#reservation-status
https://humanjudgment.org/jep/profiles/amp/2#consumption-status
https://humanjudgment.org/jep/profiles/amp/2#receipt-binding

A V event MUST NOT imply evaluation beyond its declared scope. A V result value is the semantic result of that declared verification scope. It MUST NOT be confused with the independent validator check-status vocabulary used in Section 11.

Subdelegation and Chains Subdelegation is not allowed unless the parent descriptor explicitly permits it. A child mandate MUST identify the parent Mandate Identity. A child mandate MUST NOT expand scope or relax constraints unless the parent descriptor and applicable domain profile explicitly permit that change. Chain reconstruction, cycle analysis, complete-log assumptions, and causal or responsibility interpretation belong to a chain profile or external system. AMP-2 defines only the mandate-level comparison rules required to decide whether a child remains within the parent mandate. When parent termination is intended to affect child eligibility, the parent descriptor or domain profile MUST define that rule explicitly. No cascade is implied by JEP-Core or by AMP-2 merely because a parent reference exists.

Receipts and Evidence AMP-2 is primarily a pre-action mandate profile. A receipt or post-action evidence record SHOULD identify Mandate Identity. When the exact issuance artifact matters, the receipt MAY additionally bind the Mandate Artifact Hash. A receipt MAY also reference:

the action request;
relevant V events;
relevant J events;
reservation or consumption state;
termination declarations;
the external action or result;
evidence objects or evidence digests.

A receipt MUST NOT claim that legal, policy, factual, or external-result requirements were satisfied unless the receipt or referenced evidence supports that claim under an identified verification or policy scope.

Domain Protocols and Local Action Decisions JEP-AMP-2 is cross-domain and does not replace domain protocols. A payment, procurement, healthcare, identity, data-access, or other domain profile MAY define a mapping between AMP and its native mandate or authorization object. Such a mapping SHOULD state:

which object controls domain execution;
which fields are authoritative in that domain;
how AMP action, target, scope, and constraints map to domain semantics;
which trust and policy profiles apply;
which receipt or evidence system is authoritative;
how failures map between the systems.

JEP-AMP-2 MUST NOT define payment clearing, settlement, funds movement, medical authorization, legal effect, or another domain's native execution semantics. A local gateway MAY return decisions such as allow, deny, review, or indeterminate, but such values are relying-party decisions and are not global AMP validity values.

Capability Declaration A system MAY publish an AMP capability declaration. Example: A capability declaration is descriptive. It does not prove conformance, authority, certification, or legal competence. Unsupported required capabilities MUST NOT be silently downgraded to a successful AMP result.

Conformance

AMP-2 Mandate Producer A conforming AMP-2 Mandate Producer MUST:

produce a JEP D event conforming to the applicable Core Producer class;
use https://humanjudgment.org/jep/profiles/amp/2;
include the Action Mandate Descriptor inline in what;
satisfy all required descriptor members;
use Mandate Identity consistently;
preserve profile and Core boundaries.

AMP-2 Mandate Verifier A conforming AMP-2 Mandate Verifier MUST:

perform or consume a JEP-Core validation result;
support the baseline AMP checks required by the evaluation context;
preserve independent check statuses;
distinguish Core status, Mandate Status, and Action Decision;
resolve authorized T events when termination status is required;
evaluate usage state when the mandate declares a usage limit;
reject or return indeterminate when required evidence or capabilities are unavailable;
avoid treating Event Hash as Mandate Identity.

Gateway Evaluator A gateway that claims AMP-2 Gateway Evaluator capability MUST perform Mandate Verification before making a local Action Decision. If the local Action Decision relies on the AMP mandate as authorization evidence, the gateway MUST NOT return allow when Mandate Status is invalid or indeterminate. A gateway MAY allow an action on an independent non-AMP basis, but it MUST report that AMP was not the authorization basis for that decision and MUST NOT present the result as AMP-authorized. Its local Action Decision MUST be labeled as local or domain-specific and MUST NOT be presented as a universal AMP authorization result.

Failure Codes and Test Guidance AMP failures SHOULD identify both the profile check and stable error code. Initial recommended error codes include:

AMP_ERR_PROFILE_BINDING
AMP_ERR_DESCRIPTOR
AMP_ERR_ISSUER_AUTHORITY
AMP_ERR_DELEGATEE
AMP_ERR_TIME
AMP_ERR_AUDIENCE
AMP_ERR_TERMINATED
AMP_ERR_USAGE_EXHAUSTED
AMP_ERR_REQUEST_SCOPE
AMP_ERR_SUBDELEGATION
AMP_ERR_EVIDENCE
AMP_ERR_POLICY
AMP_ERR_REFERENCE
AMP_ERR_UNSUPPORTED_CAPABILITY

AMP test vectors SHOULD include:

valid minimal issuance;
invalid profile identifier;
missing Core-required delegatee;
missing Core-required scope;
expired mandate;
issuer-authority failure;
delegatee mismatch;
action or target outside scope;
authorized termination by Mandate Identity;
termination reference with wrong Event Identity;
exact-artifact hash mismatch;
safe Core retry without mandate consumption;
single-use mandate first consumption;
single-use mandate exhausted;
concurrent reservation race with exactly one successful consumption;
child mandate narrowing parent scope;
child mandate illegally expanding parent scope;
receipt bound to Mandate Identity;
receipt additionally pinning exact Mandate Artifact Hash;
unsupported required profile capability;
indeterminate issuer authority;
V event that overclaims beyond its declared verification scope.

Stateful consumption, termination, and reservation vectors SHOULD use the stateful test-harness conventions defined by JEP Conformance.

Security Considerations A valid signature does not establish issuer authority, Mandate Status, or Action Decision. Implementations MUST validate Core status, AMP descriptor structure, issuer/principal authority, validity time, relevant audience requirements, termination status, usage state where applicable, subdelegation controls, and required policy or evidence before relying on a mandate. Event Identity and Event Hash confusion can cause incorrect revocation, consumption, or receipt binding. Logical mandate references MUST use Mandate Identity. Exact artifact checks MAY additionally use Event Hash. Single-use mandates require concurrency-safe reservation or consumption. Core idempotent acceptance alone is insufficient. Relying parties MUST NOT silently broaden action, target, scope, constraints, or subdelegation rights. A failed or unavailable required trust, policy, evidence, reservation, or termination check MUST NOT be converted into successful Mandate Status.

Privacy Considerations Action mandates can expose business intent, organizational relationships, authority structures, customer or supplier references, resource identifiers, transaction context, and risk policy. Implementations SHOULD minimize sensitive data in the descriptor and SHOULD reference external evidence when embedding it is unnecessary. Stable Mandate Identity, actor identifiers, policy references, and receipt bindings can enable cross-context correlation. Domain profiles SHOULD define retention, disclosure, encryption, selective disclosure, and redaction rules appropriate to their context.

IANA Considerations This document requests no IANA actions. https://humanjudgment.org/jep/profiles/amp/2 and the profile-specific identifiers derived from it are publisher-controlled HTTPS URI identifiers. They are not IANA-registered URN namespace values. A future registry specification may register JEP profile identifiers, profile checks, verification scopes, and error codes.

Changes from -01 Major changes from draft-wang-jep-action-mandate-profile-01:

aligned AMP with JEP-Core 0.7, JEP Profiles-01, and JEP Conformance-01;
replaced the historical urn:jep:profile:amp:1 identifier with the publisher-controlled HTTPS profile identifier https://humanjudgment.org/jep/profiles/amp/2;
defined canonical Mandate Identity as the issuance Event Identity (who,id);
limited Event Hash to exact signed-artifact identity;
removed Event-Hash-derived mandate identity;
changed mandate, termination, reservation, consumption, receipt, and chain logical references to use Mandate Identity;
made the AMP descriptor the signed inline D what object;
removed baseline detached-descriptor semantics;
made scope REQUIRED to match JEP-Core D requirements;
defined baseline JSON shapes for all required descriptor members;
reduced the baseline optional-member set and removed the second descriptor-level extension namespace;
defined omission/default semantics for validity.not_before, usage, constraints, policy_ref, delegation, and termination;
required validity.expires_at for bounded AMP-2 mandates;
removed the redundant baseline descriptor issuer field; issuer is Core who;
removed nonce and Validation Level dependencies;
replaced cumulative validation levels with independent AMP checks;
removed conditional from validator check statuses;
separated Core idempotent acceptance from mandate usage and consumption;
made single-use reservation and consumption explicitly stateful and concurrency-sensitive;
made termination a profile-level future-reliance rule rather than a claim of global external revocation;
required a typed JEP Event Identity reference for AMP termination;
removed implicit parent-termination cascade semantics;
defined explicit subdelegation defaults and expansion/relaxation controls;
aligned V events with Core ref, verification_scope, and result;
distinguished V semantic result values from validator check statuses;
required AMP-based gateways to fail closed for invalid or indeterminate Mandate Status while allowing separately labeled non-AMP authorization;
changed IANA language to request no action and use publisher-controlled HTTPS identifiers.