DEV Community

Cover image for H2A2H Verifiable Action Authorization Layer
suissAI
suissAI

Posted on

H2A2H Verifiable Action Authorization Layer

#h2a2h #ai #webdev #allascode

Short name: VAAL
Status: Draft v0.1
Scope: H2A2H Core
Nature: Domain-independent authorization layer

1. Abstract

The H2A2H Verifiable Action Authorization Layer defines how an Entity can cryptographically authorize an Agent to execute a consequential Action on its behalf.

VAAL generalizes the authorization concepts used by AP2 beyond payments by replacing the payment-specific transaction with a generic, semantically identified Action and its corresponding StateTransition.

The core security principle is:

No externally consequential Action may mutate authoritative state unless the executor can verify a cryptographic chain proving who authorized it, what was authorized, under which constraints, against which state or request, and whether that authorization is still valid.

VAAL does not replace identity, authentication, transport, domain protocols or business rules.

It binds them together at the moment where an Action is allowed to become a real-world effect.

2. Position inside H2A2H 

Human / Organization / Entity
            │
            ▼
     OpenIntent Protocol
       "what is wanted"
            │
            ▼
 OpenDelegation Protocol
  "who may act for whom"
            │
            ▼
        ┌───────────┐
        │   VAAL    │
        │           │
        │ may this  │
        │ exact     │
        │ Action    │
        │ happen?   │
        └─────┬─────┘
              │
              ▼
       OpenEntityChannels
              │
      MCP / A2A / REST
      QUIC / NATS / gRPC
      Kafka / RabbitMQ
      ...
              │
              ▼
           Actor
              │
              ▼
           Action
              │
              ▼
      State Transition
              │
              ▼
      Verifiable Receipt
Enter fullscreen mode Exit fullscreen mode

Responsibilities are deliberately separated:

Layer Question
OpenIntent What outcome is desired?
OpenDelegation Who may act for whom?
VAAL Is this exact Action authorized now?
OpenEntityChannels How are participants communicating?
Actor Who coordinates execution?
Action What atomic behavior is executed?
Receipt What actually happened?
Proof-of-Human-Return Must control return to the human?

3. Authorization unit

VAAL MUST NOT authorize generic application access whenever a more precise Action can be identified.

The fundamental authorization unit is:

canonical_label(Entity.Action)
Enter fullscreen mode Exit fullscreen mode

Examples:

government.license.renew
government.address.update

health.records.read
health.records.share
health.appointment.schedule

education.content.consume
education.course.enroll
education.assignment.submit

company.contract.negotiate
company.contract.sign

infrastructure.production.deploy

communication.email.send

home.front_door.unlock
Enter fullscreen mode Exit fullscreen mode

Therefore:

Authorization
≠ Agent has access to Service X
Enter fullscreen mode Exit fullscreen mode

Instead:

Authorization
=
Agent A
may execute
Action X
on Entity/Resource Y
under Constraints C
in Context K
before Time T
against Commitment H
Enter fullscreen mode Exit fullscreen mode

4. Core authorization tuple

The logical authorization tuple is:

A = (
    principal,
    agent,
    canonical_action,
    target,
    constraints,
    purpose,
    context,
    validity,
    delegation,
    commitment
)
Enter fullscreen mode Exit fullscreen mode

An authorization MUST be invalid if any mandatory component differs at execution time.

5. Roles

VAAL defines roles rather than fixed infrastructure components.

Principal

Entity possessing the original authority.

Examples:

Human
Company
Government
Hospital
School
Service
another Agent with delegated authority
Enter fullscreen mode Exit fullscreen mode

Agent

Entity receiving delegated authority.

Trusted Surface

Environment where meaningful authorization or consent is obtained.

Examples:

PersonalAgent UI
wallet
passkey device
mobile application
hardware authenticator
government portal
Enter fullscreen mode Exit fullscreen mode

Mandate Issuer

Entity cryptographically attesting the authorization.

Provider

Entity exposing the Action.

Verifier

Component responsible for deciding whether authorization is valid.

Executor

Component actually capable of producing the side effect.

Verifier and Executor MAY belong to the same service, but VAAL SHOULD permit them to be separated for high-risk operations.

Auditor

Optional entity capable of independently validating authorization and execution evidence.

6. Core artifacts

VAAL v0.1 defines four main artifacts.

DelegationMandate
ActionCommitment
ActionMandate
ActionReceipt
Enter fullscreen mode Exit fullscreen mode

An optional fifth artifact is:

ExecutionChallenge
Enter fullscreen mode Exit fullscreen mode

7. DelegationMandate

A DelegationMandate corresponds conceptually to an open authorization.

It establishes a bounded region of actions in which an Agent can operate autonomously.

Example:

type: org.h2a2h.mandate.delegation.v1

principal:
  id: did:example:human123

delegate:
  id: did:example:personal-agent456

allowed_actions:
  - education.course.search
  - education.course.compare
  - education.course.enroll

constraints:
  institution:
    allowed:
      - university.example

  workload:
    max_hours_per_week: 8

  credits:
    max: 6

  schedule:
    forbidden:
      - monday_morning

validity:
  not_before: 2026-09-01T00:00:00Z
  expires_at: 2027-02-01T00:00:00Z

delegation:
  further_delegation: false
  max_depth: 0

proof:
  ...
Enter fullscreen mode Exit fullscreen mode

This mandate does NOT authorize arbitrary operations.

It defines the authorization envelope.

8. ActionCommitment

Before a consequential Action is executed, VAAL creates a canonical representation of what is about to happen.

type: org.h2a2h.action_commitment.v1

canonical_action: health.records.share

actor:
  id: did:example:personal-agent456

target:
  entity: did:example:hospital789
  resources:
    - MRI:2026-08-10
    - BloodTest:2026-08-22

parameters:
  recipient: did:example:doctor999
  purpose: treatment

context:
  intent_id: intent:8f92...
  session_id: session:91aa...

state:
  before_hash: sha256:...
  version: "283"

commitment:
  canonicalization: jcs
  hash_algorithm: sha-256
  request_hash: sha256:...
Enter fullscreen mode Exit fullscreen mode

request_hash binds the authorization to the canonical semantics of the Action.

For state-mutating Actions, before_hash SHOULD additionally bind execution to the state against which the decision was made.

If the resulting state is deterministically knowable beforehand:

state:
  before_hash: sha256:AAA
  proposed_after_hash: sha256:BBB
Enter fullscreen mode Exit fullscreen mode

MAY be used.

This distinction is important.

Not every Action permits the future state to be known before execution.

Therefore VAAL binds every execution to an exact ActionCommitment, but only requires proposed_after_hash when meaningful.

9. ActionMandate

An ActionMandate is the closed authorization for one concrete Action.

type: org.h2a2h.mandate.action.v1

principal:
  id: did:example:human123

agent:
  id: did:example:personal-agent456

canonical_action: health.records.share

delegation_mandate:
  hash: sha256:DELEGATION...

intent:
  id: intent:8f92...
  hash: sha256:INTENT...

action_commitment:
  hash: sha256:ACTION...

audience:
  - did:example:hospital789

nonce: 80bcd...

validity:
  expires_at: 2026-09-03T15:00:00Z

execution:
  max_uses: 1

proof_of_possession:
  key: ...

proof:
  ...
Enter fullscreen mode Exit fullscreen mode

The ActionMandate MUST NOT grant more authority than its parent DelegationMandate.

Formally:

Authority(ActionMandate)
    ⊆
Authority(DelegationMandate)
Enter fullscreen mode Exit fullscreen mode

This property is called:

Delegation Attenuation
Enter fullscreen mode Exit fullscreen mode

Every child delegation follows the same invariant:

Authority(child)
    ⊆
Authority(parent)
Enter fullscreen mode Exit fullscreen mode

Authority can only remain equal or decrease.

Never increase.

10. Human-present authorization

When a human is present, the human can directly approve the final ActionCommitment.

Provider
   ↓
ActionCommitment
   ↓
Trusted Surface
   ↓
Human
   ↓ approve
ActionMandate
   ↓
Verifier
   ↓
Executor
Enter fullscreen mode Exit fullscreen mode

No autonomous DelegationMandate is required.

11. Human-not-present authorization

For autonomous execution:

Human
   ↓
DelegationMandate
   ↓
PersonalAgent

... time passes ...

PersonalAgent
   ↓
Discovery
   ↓
Negotiation
   ↓
ActionCommitment
   ↓
derive ActionMandate
   ↓
Verifier
   ↓
Executor
Enter fullscreen mode Exit fullscreen mode

The Agent MUST prove possession of the key authorized by the DelegationMandate.

The verifier MUST verify that the concrete Action remains inside every parent constraint.

12. Constraint Model

Constraints are typed semantic objects.

Example:

constraints:

  - type: org.h2a2h.constraint.action
    allowed:
      - health.records.share

  - type: org.h2a2h.constraint.recipient
    organization: hospital-x
    specialty: cardiology

  - type: org.h2a2h.constraint.purpose
    allowed:
      - treatment

  - type: org.h2a2h.constraint.resource
    categories:
      - cardiac

  - type: org.h2a2h.constraint.temporal
    expires_at: 2026-09-05T00:00:00Z

  - type: org.h2a2h.constraint.execution_count
    max: 1
Enter fullscreen mode Exit fullscreen mode

Core constraint families SHOULD include:

ActionConstraint
EntityConstraint
ResourceConstraint
ParameterConstraint
PurposeConstraint
TemporalConstraint
GeographicConstraint
ExecutionCountConstraint
DataClassificationConstraint
RecipientConstraint
ChannelConstraint
RiskConstraint
DelegationDepthConstraint
StateConstraint
CredentialConstraint
PolicyConstraint
Enter fullscreen mode Exit fullscreen mode

Domain profiles MAY define additional constraints.

Unknown mandatory constraints MUST fail closed.

unknown constraint
→ deny / challenge
Enter fullscreen mode Exit fullscreen mode

Never:

unknown constraint
→ ignore
Enter fullscreen mode Exit fullscreen mode

13. Authorization decisions

VAAL defines three outcomes:

ALLOW
DENY
CHALLENGE
Enter fullscreen mode Exit fullscreen mode

CHALLENGE means execution cannot continue with the currently available evidence.

Possible challenges:

human authorization
additional credential
stronger authentication
new ActionCommitment
new state snapshot
additional proof
legal acknowledgement
second approver
Enter fullscreen mode Exit fullscreen mode

14. Proof-of-Human-Return integration

Proof-of-Human-Return becomes a first-class escalation mechanism.

Example:

Agent
 ↓
company.contract.negotiate
 ↓
ALLOW

Agent
 ↓
company.contract.sign
 ↓
CHALLENGE
 ↓
Proof-of-Human-Return
 ↓
Human
 ↓
new ActionMandate
 ↓
ALLOW
Enter fullscreen mode Exit fullscreen mode

Therefore:

autonomy boundary
=
authorization boundary
Enter fullscreen mode Exit fullscreen mode

The Agent itself does not decide when human authorization is necessary.

The policy and Mandate constraints determine it.

15. Risk classes

VAAL SHOULD support semantic risk classification.

R0 — Public / non-consequential 

public information retrieval
catalog discovery
public search
Enter fullscreen mode Exit fullscreen mode

Mandate MAY be unnecessary.

R1 — Private read 

personal records
private documents
internal company data
Enter fullscreen mode Exit fullscreen mode

Requires authenticated authority.

R2 — Reversible mutation 

schedule appointment
modify preference
create draft
Enter fullscreen mode Exit fullscreen mode

Delegated Mandate normally sufficient.

R3 — Consequential mutation 

submit government document
share medical record
deploy production service
enroll student
send binding communication
Enter fullscreen mode Exit fullscreen mode

Requires state/request-bound ActionMandate.

R4 — Critical / irreversible / legally sensitive 

contract signature
medical consent
dangerous device control
high-impact legal declaration
Enter fullscreen mode Exit fullscreen mode

Policy SHOULD normally require Proof-of-Human-Return or multiple independent authorities.

Risk class is a policy input.

It MUST NOT by itself confer authority.

16. Discovery

An Entity SHOULD advertise authorization capabilities through its H2A2H profile.

Example:

entity:
  canonical_label: hospital.example

services:

  health.records:
    version: "1.0"

    capabilities:

      health.records.read:
        schema: https://hospital.example/schemas/records-read.yml

      health.records.share:
        schema: https://hospital.example/schemas/records-share.yml

        authorization:
          required: true

          protocols:
            - org.h2a2h.vaal.v1

          mandate_formats:
            - vc+sd-jwt

          supported_constraints:
            - org.h2a2h.constraint.recipient
            - org.h2a2h.constraint.purpose
            - org.h2a2h.constraint.temporal

          challenge_modes:
            - openid4vp
            - proof-of-human-return
Enter fullscreen mode Exit fullscreen mode

Discovery declares support.

It does NOT confer trust.

capability_supported
≠
action_authorized
Enter fullscreen mode Exit fullscreen mode

17. Negotiation

Before execution:

Agent Requirements
       ∩
Provider Capabilities
       ∩
Mandate Capabilities
       ∩
Policy
       =
Executable Authorization Profile
Enter fullscreen mode Exit fullscreen mode

If the intersection is empty:

CHALLENGE
or
DENY
Enter fullscreen mode Exit fullscreen mode

No transport-specific behavior should alter authorization semantics.

18. Credential layer

VAAL SHOULD reuse existing credential standards.

Default interoperability profile:

W3C Verifiable Credentials
        +
SD-JWT VC
        +
OpenID4VP
Enter fullscreen mode Exit fullscreen mode

Other formats MAY be supported:

ISO mdoc
COSE
JWT
hardware-attested credentials
passkey-bound credentials
Enter fullscreen mode Exit fullscreen mode

VAAL defines authorization semantics.

It does not define a new identity wallet format.

19. Deterministic verification algorithm

Before any consequential Action, the verifier MUST perform the equivalent of:

1. Parse Mandate
2. Validate schema
3. Canonicalize authorization data
4. Verify signatures
5. Verify credential status
6. Verify issuer trust policy
7. Verify agent proof-of-possession
8. Verify delegation lineage
9. Verify attenuation
10. Verify expiration
11. Verify audience
12. Verify nonce
13. Verify replay state
14. Verify canonical_action
15. Verify target
16. Verify parameters
17. Verify purpose
18. Verify every constraint
19. Verify Intent binding
20. Verify ActionCommitment hash
21. Verify resource/state version when applicable
22. Verify local policy
23. Determine ALLOW / DENY / CHALLENGE
Enter fullscreen mode Exit fullscreen mode

Only ALLOW reaches the Executor.

Verifier.ALLOW
   ↓
Execution Boundary
   ↓
Executor
Enter fullscreen mode Exit fullscreen mode

The Executor MUST NOT accept an Agent's assertion that authorization was already verified elsewhere unless the deployment explicitly establishes a trusted authorization boundary.

20. Execution Boundary

The security-critical architectural rule is:

Agent
 │
 │ request
 ▼
Verifier
 │
 │ signed authorization decision
 ▼
──────────── EXECUTION BOUNDARY ────────────
 │
 ▼
Executor
Enter fullscreen mode Exit fullscreen mode

The Agent MUST NOT have another path around this boundary.

Otherwise VAAL becomes audit metadata instead of authorization.

21. ActionReceipt

Every consequential execution SHOULD create a signed receipt.

Example:

type: org.h2a2h.receipt.action.v1

receipt_id: receipt:019...

verifier:
  id: did:example:hospital789

executor:
  id: service:medical-record-service

principal:
  id: did:example:human123

agent:
  id: did:example:personal-agent456

canonical_action: health.records.share

authorization:
  mandate_hash: sha256:...
  action_commitment_hash: sha256:...

execution:
  result: success
  executed_at: 2026-09-03T12:04:19Z

state:
  before_hash: sha256:AAA
  after_hash: sha256:BBB

result:
  hash: sha256:RESULT...

proof:
  ...
Enter fullscreen mode Exit fullscreen mode

The minimum auditable chain becomes:

Intent
 ↓ hash
DelegationMandate
 ↓
ActionCommitment
 ↓ hash
ActionMandate
 ↓
Authorization Decision
 ↓
Execution
 ↓
ActionReceipt
Enter fullscreen mode Exit fullscreen mode

22. Receipt effects on authority

Receipts are not passive logs.

They MAY modify remaining delegated authority.

Examples:

max_uses = 1
Enter fullscreen mode Exit fullscreen mode

After a successful receipt:

remaining_uses = 0
Enter fullscreen mode Exit fullscreen mode

Or:

budget = 10 actions
executed = 3
remaining = 7
Enter fullscreen mode Exit fullscreen mode

Thus the verifier maintains:

AuthorizationState
Enter fullscreen mode Exit fullscreen mode

in addition to application state.

23. Anti-replay

ActionMandates SHOULD support:

nonce
audience
expiration
proof-of-possession
action_commitment_hash
single-use identifiers
state version
receipt consumption
Enter fullscreen mode Exit fullscreen mode

A captured Mandate MUST NOT automatically be reusable against:

another Entity
another Action
another state
another Agent
another request
another time window
Enter fullscreen mode Exit fullscreen mode

24. Transport independence

VAAL is transport-independent.

The same authorization semantics can travel through:

REST
MCP
A2A
gRPC
QUIC
NATS
Kafka
RabbitMQ
RedPanda
BullMQ
WebSocket
embedded execution
Enter fullscreen mode Exit fullscreen mode

OpenEntityChannels decides transport.

VAAL decides authority.

Therefore:

Authorization semantics
MUST NOT depend on transport.
Enter fullscreen mode Exit fullscreen mode

25. Agent chains

VAAL MUST support:

Human
 ↓
PersonalAgent
 ↓
SpecialistAgent
 ↓
ExecutionAgent
 ↓
Service
Enter fullscreen mode Exit fullscreen mode

Every delegation edge must preserve attenuation:

A₀ ⊇ A₁ ⊇ A₂ ⊇ A₃
Enter fullscreen mode Exit fullscreen mode

No downstream Agent may create authority unavailable to its parent.

The complete chain MUST be independently verifiable.

26. H2A2H Entity integration

Every protected Action SHOULD declare:

action:
  canonical_label: health.records.share

authorization:
  consequential: true
  vaal_required: true
  risk: R3

  accepted_mandates:
    - org.h2a2h.mandate.action.v1

  constraints:
    required:
      - recipient
      - purpose

  human_return:
    required_when:
      - recipient.outside_care_team
      - purpose != treatment
Enter fullscreen mode Exit fullscreen mode

This information belongs to the Action definition rather than Agent code.

The Agent therefore contains no hidden authorization rules.

27. Everything as Code

VAAL follows AllasCode principles.

A runtime SHOULD be generated from declarations such as:

schema.yml
manifest.yml
config.yml
policies/
constraints/
authorization.yml
Enter fullscreen mode Exit fullscreen mode

Not:

if user.isDoctor &&
   hospital == "X" &&
   action == "share" ...
Enter fullscreen mode Exit fullscreen mode

hidden inside application code.

Authorization behavior must be inspectable, diffable, testable and reproducible.

28. Example — Education 

canonical_action: education.content.consume

constraints:

  course:
    equals: CS101

  allowed_transformations:
    - summarize
    - translate
    - simplify
    - create_examples
    - create_flashcards
    - create_diagram
    - create_audio

  forbidden_actions:
    - education.assignment.submit
    - education.exam.answer
    - education.grade.modify
Enter fullscreen mode Exit fullscreen mode

The PersonalAgent can adapt learning material extensively.

It cannot impersonate the student academically.

29. Example — Government 

canonical_action: government.license.renew

constraints:
  changes_allowed: false

  holder:
    equals: principal

  human_return_if:
    - new_legal_declaration
    - penalty_detected
    - changed_terms
Enter fullscreen mode Exit fullscreen mode

30. Example — Healthcare 

canonical_action: health.records.share

constraints:

  records:
    categories:
      - cardiology

  recipient:
    organization: hospital-x
    specialty: cardiology

  purpose:
    equals: treatment

  validity:
    max: PT48H

  redistribution:
    allowed: false
Enter fullscreen mode Exit fullscreen mode

31. Example — Infrastructure 

canonical_action: infrastructure.production.deploy

constraints:

  repository:
    equals: billing-api

  commit:
    equals: 7a872...

  tests:
    required: passed

  security_scan:
    required: passed

  destructive_migration:
    allowed: false

  replicas:
    max_delta: 2

  validity:
    max: PT10M
Enter fullscreen mode Exit fullscreen mode

An Agent having Kubernetes credentials is not sufficient.

It must also possess authorization for this deployment.

32. Domain profiles

The core remains generic.

Domains extend it.

VAAL Core
 │
 ├── Commerce Profile
 │      AP2
 │
 ├── Health Profile
 │      FHIR Consent
 │
 ├── Education Profile
 │      VC / Open Badges / CLR
 │
 ├── Government Profile
 │
 ├── Legal Profile
 │
 ├── Enterprise Profile
 │
 ├── DevOps Profile
 │
 ├── IoT Profile
 │
 └── Data Privacy Profile
Enter fullscreen mode Exit fullscreen mode

Domain standards SHOULD be referenced rather than recreated.

33. AP2 compatibility

Commerce remains a specialization.

Conceptual mapping:

VAAL                       AP2

DelegationMandate      → Open Mandate

ActionMandate          → Closed Mandate

ActionCommitment       → checkout-bound commitment

canonical_action       → payment/checkout action

ActionReceipt          → Mandate Receipt

Constraint             → AP2 Constraint

Principal              → User

Agent                  → Shopping Agent

Verifier               → Business /
                          Payment Processor
Enter fullscreen mode Exit fullscreen mode

VAAL does not replace AP2 for payments.

Instead:

AP2
=
Commerce Authorization Profile
compatible with the broader model
Enter fullscreen mode Exit fullscreen mode

34. UCP compatibility

The reusable UCP concepts are:

Discovery
Services
Capabilities
Extensions
Schema composition
Negotiation
Transport bindings
Action contracts
Versioning
Enter fullscreen mode Exit fullscreen mode

VAAL adopts the architectural principles without claiming that non-commerce capabilities are UCP capabilities.

Possible integration:

extensions:
  org.h2a2h.vaal:
    version: "1.0"
    schema: https://h2a2h.space/schemas/vaal/v1
Enter fullscreen mode Exit fullscreen mode

35. Relationship to OAuth authorization

OAuth remains useful for obtaining API access.

VAAL solves a more semantic problem.

OAuth token:
"this client can access this API"

VAAL Mandate:
"this Agent is authorized by this Principal
to execute this precise semantic Action,
against this request/state,
under these constraints"
Enter fullscreen mode Exit fullscreen mode

They SHOULD coexist.

VAAL does not replace OAuth.

36. Core invariants

INV-001 — No authority expansion 

Authority(child) ⊆ Authority(parent)
Enter fullscreen mode Exit fullscreen mode

INV-002 — Action identity

Every protected Action has exactly one stable canonical_label.

INV-003 — Binding

Execution MUST match the authorized ActionCommitment.

INV-004 — State freshness

When authorization depends on authoritative state, stale state invalidates the authorization.

INV-005 — Fail closed

Unknown mandatory constraint → not ALLOW.

INV-006 — Proof of possession

Autonomous delegated authority MUST be cryptographically bound to the authorized Agent.

INV-007 — Replay resistance

Authorization MUST include sufficient context to prevent unintended reuse.

INV-008 — Execution boundary

No consequential execution path may bypass authorization enforcement.

INV-009 — Receipt

Every successfully executed consequential Action produces verifiable execution evidence.

INV-010 — Human escalation

An Agent cannot autonomously expand its Mandate when authorization is insufficient.

It must:

CHALLENGE
→ Proof-of-Human-Return
Enter fullscreen mode Exit fullscreen mode

37. Minimal runtime

The runtime can be reduced to five operations:

discover()
delegate()
commit()
authorize()
execute()
receipt()
Enter fullscreen mode Exit fullscreen mode

More formally:

Discovery
  ↓
Delegation
  ↓
Commitment
  ↓
Verification
  ↓
Execution
  ↓
Receipt
Enter fullscreen mode Exit fullscreen mode

38. Integration with the H2A2H runtime

Current H2A2H runtime:

Intake
→ Resolver
→ Binding
→ Healing
→ Proof
→ Governor
→ Orchestration
→ Acceptance
→ Persistence
Enter fullscreen mode Exit fullscreen mode

VAAL should integrate as:

Intake
→ Resolver
→ Binding
→ Healing
→ Proof
→ Authorization
→ Governor
→ Orchestration
→ Execution Boundary
→ Acceptance
→ Receipt
→ Persistence
Enter fullscreen mode Exit fullscreen mode

Authorization validates authority.

Governor evaluates system/domain policies.

They must remain different concerns.

39. Proposed repository structure 

authorization/
│
├── README.md
├── manifest.yml
├── config.yml
├── schema.yml
│
├── mandates/
│   ├── delegation/
│   └── action/
│
├── commitments/
│   └── action/
│
├── receipts/
│   └── action/
│
├── constraints/
│   ├── action/
│   ├── entity/
│   ├── resource/
│   ├── purpose/
│   ├── temporal/
│   ├── delegation/
│   ├── state/
│   └── execution-count/
│
├── verifier/
│
├── execution-boundary/
│
├── challenges/
│   └── proof-of-human-return/
│
├── profiles/
│   ├── commerce/
│   ├── government/
│   ├── health/
│   ├── education/
│   ├── enterprise/
│   ├── legal/
│   ├── devops/
│   └── iot/
│
├── bridges/
│   ├── ap2/
│   ├── ucp/
│   ├── openid4vp/
│   ├── oauth/
│   └── vc/
│
└── tests/
    ├── authorization/
    ├── attenuation/
    ├── replay/
    ├── state-binding/
    ├── expiration/
    ├── constraints/
    └── human-return/
Enter fullscreen mode Exit fullscreen mode

40. Protocol lifecycle

The complete generic flow is:

Principal
   │
   │ creates Intent
   ▼
OpenIntent
   │
   ▼
PersonalAgent
   │
   │ obtains bounded authority
   ▼
DelegationMandate
   │
   ▼
Entity Discovery
   │
   ▼
Capability Negotiation
   │
   ▼
Action proposal
   │
   ▼
ActionCommitment
   │
   │ derive exact authorization
   ▼
ActionMandate
   │
   ▼
Verifier
   │
   ├── DENY ────────────────X
   │
   ├── CHALLENGE
   │       │
   │       ▼
   │ Proof-of-Human-Return
   │       │
   │       └───────────────┐
   │                       │
   └── ALLOW ◄─────────────┘
           │
           ▼
    Execution Boundary
           │
           ▼
        Executor
           │
           ▼
       New State
           │
           ▼
     ActionReceipt
           │
           ▼
 Authorization State Update
Enter fullscreen mode Exit fullscreen mode

41. Core semantic statement

The H2A2H authorization model can be summarized as:

Authentication proves who an Entity is.

Delegation proves who may act for whom.

Intent expresses what outcome is desired.

Authorization proves whether an exact Action may occur.

Commitment proves what was actually authorized.

Execution changes reality.

Receipt proves what actually happened.
Enter fullscreen mode Exit fullscreen mode

This separation is fundamental.

42. Contribution boundary

VAAL MUST NOT claim invention of:

Verifiable Credentials
delegated authorization
agent authorization
Mandates
selective disclosure
proof-of-possession
authorization receipts
pre-execution permits
capability negotiation
Enter fullscreen mode Exit fullscreen mode

Those mechanisms have substantial prior art.

The prospective H2A2H contribution is their unification around a semantic action model:

Entity
+
canonical Action identity
+
OpenIntent
+
OpenDelegation
+
UCP-like capability discovery
+
cryptographically attenuated authority
+
ActionCommitment
+
state/request-bound authorization
+
transport-independent execution
+
Proof-of-Human-Return
+
verifiable ActionReceipt
Enter fullscreen mode Exit fullscreen mode

The particularly important H2A2H hypothesis is:

A stable semantic canonical_label for an atomic Action can serve simultaneously as the vocabulary for discovery, delegation, authorization, policy, orchestration, proofs, observability and execution receipts.

That hypothesis is broader than payment authorization and should be evaluated independently as part of the H2A2H research program.

43. Canonical rule

The foundational VAAL invariant is therefore:

No externally consequential Intent Action SHALL cross an execution boundary without a verifiable, attenuated and context-bound authorization chain whose semantic target is the Action's canonical identity.

Or formally:

Execute(A)
⇒
ValidIdentity(A)
∧ ValidDelegation(A)
∧ ValidAction(A)
∧ ValidConstraints(A)
∧ ValidCommitment(A)
∧ ValidContext(A)
∧ ValidState(A)
∧ ValidPolicy(A)
Enter fullscreen mode Exit fullscreen mode

And after execution:

Execute(A)
⇒
∃ Receipt(A)
Enter fullscreen mode Exit fullscreen mode

This becomes the authorization foundation for autonomous H2A2H systems.

Top comments (0)