HTTP translation
Zod-validated input and non-leaking response envelopes
The authority plane
Connect organisational identity to transaction-specific authority.
WhoActs models the appointment, governance, signed evidence, presentation and relying-party decision as one auditable lifecycle.
PRINCIPALappointsREPRESENTATIVEto performACTIONwithinPOLICY
Not another identity layer
Identity authenticates the actor. Authority evaluates the act.
Workforce IAM, signatures, wallets and company registers all answer important questions. None of them alone proves that the named organisation appointed this representative to perform this exact action under these limits.
WhoActs sits between identity and acceptance. It gives the relying party structured evidence and a deterministic policy decision without presenting that output as legal advice.
From appointment to expiry
One lifecycle. No hidden hand-offs.
- 01
Define
Describe the representative, permitted act, resource, limits, channels and expiry.
- 02
Approve
Apply maker–checker governance before authority can move forward.
- 03
Accept
Record that the human, provider or software agent accepts the mandate.
- 04
Issue
Create a signed credential through the configured issuer boundary.
- 05
Present
Disclose the minimum claims a relying party needs for its decision.
- 06
Verify
Check signature, issuer, time, status, binding and requested action.
- 07
Revoke or renew
End, suspend, supersede or renew authority as circumstances change.
Current product surfaces
Built around the evidence chain.
These surfaces exist in the Mandate Rail repository; live readiness varies by mode and provider.
- 01
Organisation records with source provenance
- 02
Mandate creation and lifecycle management
- 03
Evidence upload, bounded input and hashing
- 04
Maker–checker approval and representative acceptance
- 05
Signed sandbox credential issuance
- 06
Wallet and selective-presentation flows
- 07
Public verification and reasoned policy decisions
- 08
Suspension, revocation, renewal and supersession
- 09
Hash-linked audit chain and verification receipts
- 10
Operations cases, webhooks and API keys
- 11
Tenant, role and connected-data boundaries
- 12
Live GLEIF entity corroboration in connected mode
Four independent boundaries
Keep policy, storage, providers and transport separable.
Authority domain
State machine, policy evaluation and credential binding
Repository ports
Deterministic sandbox memory or tenant-scoped connected data
Provider ports
Authentic sources, issuers, extraction, storage and email
Product principles
Authority evidence should be useful and bounded.
Precise authority
Express actions, limits, resources, jurisdictions, channels, approval conditions and exclusions.
Live verification
Evaluate current status and exact scope at the point where an action is requested.
Minimum disclosure
Present only the authority evidence the verifier needs for the transaction in front of it.
Revocable by design
Suspend, revoke, supersede or renew authority without retrieving paper documents.
Auditable evidence
Retain receipts that show the inputs, checks, decision and reason codes at that moment.
Issuer-neutral boundaries
Integrate qualified or non-qualified providers according to the actual assurance requirement.
Design-partner programme
Bring one real authority problem.
We will map the principal, representative, action, resource, policy and relying-party decision with your legal, security and operational stakeholders.