JEP Action Mandate Profile (JEP-AMP)
draft-wang-jep-action-mandate-profile-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | yuqiang wang | ||
| Last updated | 2026-09-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-jep-action-mandate-profile-02
Network Working Group Y. Wang
Internet-Draft 26 September 2026
Intended status: Experimental
Expires: 30 March 2027
JEP Action Mandate Profile (JEP-AMP)
draft-wang-jep-action-mandate-profile-02
Abstract
This document defines JEP Action Mandate Profile 2 (JEP-AMP-2), a
profile of the Judgment Event Protocol (JEP) [JEP].
JEP-AMP-2 specifies how a JEP Delegation event can express a bounded,
verifiable, terminable, and auditable mandate for an agent, human,
organization, workflow, or system to attempt an action on behalf of a
principal.
JEP-AMP-2 does not redefine JEP-Core event verbs, Event Identity,
Event Hash, signature semantics, validation checks, identity systems,
credential systems, legal liability, payment clearing, or global
authorization validity. It defines a signed Action Mandate
Descriptor and profile-level rules for evaluating mandate validity
under an explicit trust, policy, domain, and relying-party context.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang Expires 30 March 2027 [Page 1]
Internet-Draft JEP-AMP September 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Action Mandate . . . . . . . . . . . . . . . . . . . . . 4
3.2. Mandate Identity . . . . . . . . . . . . . . . . . . . . 4
3.3. Mandate Artifact Hash . . . . . . . . . . . . . . . . . . 4
3.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Principal . . . . . . . . . . . . . . . . . . . . . . . . 4
3.6. Delegatee . . . . . . . . . . . . . . . . . . . . . . . . 5
3.7. Mandate Status . . . . . . . . . . . . . . . . . . . . . 5
3.8. Action Decision . . . . . . . . . . . . . . . . . . . . . 5
4. Profile Identifier and Versioning . . . . . . . . . . . . . . 5
5. Relationship to JEP-Core . . . . . . . . . . . . . . . . . . 5
6. Action Mandate Descriptor . . . . . . . . . . . . . . . . . . 6
6.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Required Members . . . . . . . . . . . . . . . . . . . . 7
6.3. Optional Members . . . . . . . . . . . . . . . . . . . . 8
6.4. Action . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.5. Target . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.7. Constraints . . . . . . . . . . . . . . . . . . . . . . . 10
6.8. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.9. Authority Evidence . . . . . . . . . . . . . . . . . . . 10
6.10. Delegation Controls . . . . . . . . . . . . . . . . . . . 11
6.11. Termination Controls . . . . . . . . . . . . . . . . . . 12
6.12. Minimal Descriptor Example . . . . . . . . . . . . . . . 12
7. Mandate Issuance . . . . . . . . . . . . . . . . . . . . . . 13
8. Mandate References . . . . . . . . . . . . . . . . . . . . . 14
8.1. Logical Reference . . . . . . . . . . . . . . . . . . . . 14
8.2. Exact Artifact Pin . . . . . . . . . . . . . . . . . . . 14
8.3. Application Alias . . . . . . . . . . . . . . . . . . . . 15
9. Mandate Termination . . . . . . . . . . . . . . . . . . . . . 15
9.1. Termination Event . . . . . . . . . . . . . . . . . . . . 15
9.2. Profile-Level Effect . . . . . . . . . . . . . . . . . . 15
9.3. Expiry . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Reservation, Usage, and Consumption . . . . . . . . . . . . . 16
10.1. Separation from Core Acceptance . . . . . . . . . . . . 16
Wang Expires 30 March 2027 [Page 2]
Internet-Draft JEP-AMP September 2026
10.2. Single-Use and Bounded-Use Mandates . . . . . . . . . . 16
10.3. Reservation . . . . . . . . . . . . . . . . . . . . . . 16
10.4. Consumption . . . . . . . . . . . . . . . . . . . . . . 16
11. AMP Validation Model . . . . . . . . . . . . . . . . . . . . 17
11.1. Layer Separation . . . . . . . . . . . . . . . . . . . . 17
11.2. Profile-Specific Checks . . . . . . . . . . . . . . . . 17
11.3. Mandate Status . . . . . . . . . . . . . . . . . . . . . 18
11.4. Baseline Validation Flow . . . . . . . . . . . . . . . . 18
12. Verification Events . . . . . . . . . . . . . . . . . . . . . 19
13. Subdelegation and Chains . . . . . . . . . . . . . . . . . . 20
14. Receipts and Evidence . . . . . . . . . . . . . . . . . . . . 20
15. Domain Protocols and Local Action Decisions . . . . . . . . . 21
16. Capability Declaration . . . . . . . . . . . . . . . . . . . 21
17. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 22
17.1. AMP-2 Mandate Producer . . . . . . . . . . . . . . . . . 22
17.2. AMP-2 Mandate Verifier . . . . . . . . . . . . . . . . . 23
17.3. Gateway Evaluator . . . . . . . . . . . . . . . . . . . 23
18. Failure Codes and Test Guidance . . . . . . . . . . . . . . . 23
19. Security Considerations . . . . . . . . . . . . . . . . . . . 25
20. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
22. Changes from -01 . . . . . . . . . . . . . . . . . . . . . . 26
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
23.1. Normative References . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
1. 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:
Does this signed delegation satisfy the declared AMP mandate rules,
and does the requested action remain within that mandate?
The local decision to permit an external action remains a relying-
party or domain-policy decision.
JEP Profiles [JEP-PROFILES] defines the general profile-selection,
composition, trust, acceptance, and profile-specific-check model.
Wang Expires 30 March 2027 [Page 3]
Internet-Draft JEP-AMP September 2026
JEP Conformance [JEP-CONFORMANCE] defines validation-result and test-
harness conventions used by this profile.
Where this document conflicts with JEP-Core, JEP-Core controls.
2. 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 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals.
3. Terminology
3.1. Action Mandate
A signed JEP Delegation event whose what value conforms to the Action
Mandate Descriptor defined by this profile.
3.2. 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.
3.3. 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.
3.4. Issuer
The actor identified by the issuance event's who member.
The issuer is not automatically authorized to act for the principal.
3.5. Principal
The person, organization, account, tenant, legal entity, or other
subject on whose behalf the delegated action is to be attempted.
Wang Expires 30 March 2027 [Page 4]
Internet-Draft JEP-AMP September 2026
3.6. Delegatee
The actor identified by what.delegatee.
3.7. 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.
3.8. 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.
4. Profile Identifier and Versioning
The profile identifier for this version is:
https://humanjudgment.org/jep/profiles/amp/2
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.
5. Relationship to JEP-Core
JEP-AMP-2 relies on JEP-Core for:
* the D event object;
Wang Expires 30 March 2027 [Page 5]
Internet-Draft JEP-AMP September 2026
* 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".
6. Action Mandate Descriptor
6.1. 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.
Wang Expires 30 March 2027 [Page 6]
Internet-Draft JEP-AMP September 2026
A future extension MAY define a detached representation, but it MUST
preserve the Core-required signed D semantics and define conflict
resolution.
6.2. 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.
Wang Expires 30 March 2027 [Page 7]
Internet-Draft JEP-AMP September 2026
* validity MUST be an object containing expires_at.
validity.expires_at MUST be an RFC 3339 date-time [RFC3339].
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.
6.3. 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.
Wang Expires 30 March 2027 [Page 8]
Internet-Draft JEP-AMP September 2026
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.
6.4. 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.
6.5. 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.
6.6. 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.
Wang Expires 30 March 2027 [Page 9]
Internet-Draft JEP-AMP September 2026
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.
6.7. 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.
6.8. 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.
6.9. 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.
Wang Expires 30 March 2027 [Page 10]
Internet-Draft JEP-AMP September 2026
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.
6.10. 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.
Wang Expires 30 March 2027 [Page 11]
Internet-Draft JEP-AMP September 2026
6.11. 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.
6.12. Minimal Descriptor Example
Wang Expires 30 March 2027 [Page 12]
Internet-Draft JEP-AMP September 2026
{
"profile": "https://humanjudgment.org/jep/profiles/amp/2",
"principal": {
"id": "did:example:acme",
"type": "organization"
},
"delegatee": "did:example:agent:procure-7",
"action": {
"type": "urn:example:procurement:action:purchase"
},
"target": {
"type": "procurement_request",
"id": "req-123"
},
"scope": {
"purpose": "purchase-approved-materials",
"work_unit_ref": "req-123"
},
"validity": {
"not_before": "2026-09-26T00:00:00Z",
"expires_at": "2026-09-28T00:00:00Z"
},
"constraints": {
"amount": {
"currency": "USD",
"max": 5000
}
},
"usage": {
"max_uses": 1,
"reservation_required": true
},
"policy_ref": [
{
"uri": "urn:policy:acme:procurement:v3"
}
],
"delegation": {
"subdelegation_allowed": false
}
}
The DID identifiers are illustrative only.
7. Mandate Issuance
An AMP-2 mandate is issued by one JEP D event.
Wang Expires 30 March 2027 [Page 13]
Internet-Draft JEP-AMP September 2026
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.
8. Mandate References
8.1. Logical Reference
A JEP event referring to an AMP-2 mandate SHOULD reference the
issuance Event Identity.
Conceptually:
{
"type": "jep:event",
"value": {
"who": "did:example:issuer",
"id": "urn:uuid:..."
}
}
8.2. Exact Artifact Pin
When the exact signed issuance artifact matters, the reference MAY
additionally pin the issuance Event Hash.
Wang Expires 30 March 2027 [Page 14]
Internet-Draft JEP-AMP September 2026
A validator MUST verify an exact-artifact pin when the active
validation context requires reference_integrity.
8.3. 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.
9. Mandate Termination
9.1. 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.
9.2. 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.
9.3. Expiry
After validity.expires_at, the mandate is invalid for new AMP
reliance even if no T event exists.
Wang Expires 30 March 2027 [Page 15]
Internet-Draft JEP-AMP September 2026
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.
10. Reservation, Usage, and Consumption
10.1. 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.
10.2. 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.
10.3. 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.
10.4. Consumption
A consumption record SHOULD bind:
Wang Expires 30 March 2027 [Page 16]
Internet-Draft JEP-AMP September 2026
* 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.
11. AMP Validation Model
11.1. 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.
11.2. 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
Wang Expires 30 March 2027 [Page 17]
Internet-Draft JEP-AMP September 2026
* 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.
11.3. 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.
11.4. Baseline Validation Flow
A Mandate Verifier SHOULD:
* validate the issuance event under JEP-Core;
Wang Expires 30 March 2027 [Page 18]
Internet-Draft JEP-AMP September 2026
* 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.
12. 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
Wang Expires 30 March 2027 [Page 19]
Internet-Draft JEP-AMP September 2026
* 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.
13. 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.
14. 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;
Wang Expires 30 March 2027 [Page 20]
Internet-Draft JEP-AMP September 2026
* 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.
15. 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.
16. Capability Declaration
A system MAY publish an AMP capability declaration.
Wang Expires 30 March 2027 [Page 21]
Internet-Draft JEP-AMP September 2026
Example:
{
"jep_core": "0.7",
"amp_profiles": ["https://humanjudgment.org/jep/profiles/amp/2"],
"roles": [
"mandate_producer",
"mandate_verifier",
"gateway_evaluator"
],
"validation_modes": [
"archival",
"acceptance",
"policy"
],
"amp_checks": [
"https://humanjudgment.org/jep/profiles/amp/2#descriptor",
"https://humanjudgment.org/jep/profiles/amp/2#issuer-authority",
"https://humanjudgment.org/jep/profiles/amp/2#termination-status",
"https://humanjudgment.org/jep/profiles/amp/2#request-scope"
],
"reservation_supported": true
}
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.
17. Conformance
17.1. 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.
Wang Expires 30 March 2027 [Page 22]
Internet-Draft JEP-AMP September 2026
17.2. 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.
17.3. 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.
18. 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
Wang Expires 30 March 2027 [Page 23]
Internet-Draft JEP-AMP September 2026
* 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;
Wang Expires 30 March 2027 [Page 24]
Internet-Draft JEP-AMP September 2026
* 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.
19. 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.
Wang Expires 30 March 2027 [Page 25]
Internet-Draft JEP-AMP September 2026
A failed or unavailable required trust, policy, evidence,
reservation, or termination check MUST NOT be converted into
successful Mandate Status.
20. 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.
21. 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.
22. 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;
Wang Expires 30 March 2027 [Page 26]
Internet-Draft JEP-AMP September 2026
* 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;
Wang Expires 30 March 2027 [Page 27]
Internet-Draft JEP-AMP September 2026
* 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.
23. References
23.1. Normative References
[JEP] Wang, Y., "Judgment Event Protocol (JEP)", Work in
Progress, Internet-Draft, draft-wang-jep-judgment-event-
protocol-07, 26 September 2026,
<https://datatracker.ietf.org/doc/html/draft-wang-jep-
judgment-event-protocol-07>.
[JEP-CONFORMANCE]
Wang, Y., "JEP Conformance and Test Suite", Work in
Progress, Internet-Draft, draft-wang-jep-conformance-01,
26 September 2026, <https://datatracker.ietf.org/doc/html/
draft-wang-jep-conformance-01>.
[JEP-PROFILES]
Wang, Y., "JEP Profiles and Interoperability", Work in
Progress, Internet-Draft, draft-wang-jep-profiles-01, 26
September 2026, <https://datatracker.ietf.org/doc/html/
draft-wang-jep-profiles-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
Author's Address
Yuqiang Wang
Email: signal@humanjudgment.org
URI: https://github.com/hjs-spec
Wang Expires 30 March 2027 [Page 28]