Human authority stays visible
Critical actions do not disappear into automation. The user's role remains deliberate and understandable.
§ 03 · TRUST · RELIANCE MODEL
Trust only matters when the outcome can be relied on.
Paphwey is designed around the conditions enterprises look for in high-assurance environments: explicit user authority, identity-backed approval, scoped action control, and outcomes that hold up to review.
§ 04 · What Makes It Credible
Four guarantees
Guarantees
What trust means, concretely.
Approval carries identity weight
The signal is stronger than interface consent because it is tied to trusted identity context.
Scope remains legible
Organizations can define what kind of action is being approved and where stronger trust should apply.
Outcomes can be defended
Confidence is shaped for downstream governance, partner reliance, and enterprise accountability.
§ 05 · Enterprise Readiness
Cross-function
Enterprise readiness
Built for teams that need trust decisions to make sense across product, risk, and governance.
The same outcome has to satisfy different readers — each with their own standard of proof.
Product teams
Create AI-powered experiences without making sensitive approval moments feel reckless or opaque.
Risk and compliance
Understand how approval was obtained and why the resulting trust signal should be accepted.
Operations and partners
Receive a result that is usable in decisioning, review workflows, and customer support pathways.
What trust looks like
Confidence that a real person knowingly authorized a meaningful action.
- The request is clear enough to evaluate.
- The approval moment is meaningful enough to matter.
- The identity context is strong enough to rely on.
What it avoids
Ambiguous handoffs between automation, user intent, and enterprise accountability.
- Hidden approvals supported by weak evidence.
- Over-broad delegation with unclear boundaries.
- Outcomes that become difficult to defend after the fact.
§ 06 · Delegation Credential Format
Signed authority
Credential shape
Every delegation is a signed Verifiable Credential — not a lookup row.
When a principal grants authority, Paphwey packs the grant into a JWS envelope carrying the W3C Verifiable Credential v2 payload. The same credential is the anchor point for every downstream decision: caps, audience, scope, and lifecycle are all derivable from it.
Signed at write time
The credential is issued by Paphwey with the active key and published via JWKS so relying parties can verify offline.
Verifiable Credential v2 shape
The payload carries a standard vc claim — @context, type, and credentialSubject — so it reads cleanly into VC tooling.
Carries the policy contract
Scopes, challenge types, spend caps, and validity windows live inside the credential, not alongside it. What was signed is exactly what is enforced.
Key rotation aware
Every credential carries a kid header. A rotation publishes a new key on JWKS with a grace window; old credentials remain verifiable until expiry.
§ 07 · Mid-Lifecycle Controls
Pause · Revoke · Status
Lifecycle
Authority can be paused, resumed, or revoked after the fact — and everyone can check.
A grant is not a one-way door. Principals can pause a delegation from the wallet (soft halt, reversible) or revoke it outright (hard stop). Relying parties poll a signed status endpoint and a signed revocation snapshot so their own systems stay in sync without private integrations.
Pause
Temporary halt without reissue.
- Principal taps Pause in the Paphwey wallet.
- Status flips to
paused; new challenges are rejected. - Resume at any time — the same credential keeps its validity window.
Revoke
Hard stop with verifiable proof.
- Status endpoint returns
revokedwithrevoked_at. - The revocations snapshot lists the credential and is signed.
- Downstream systems see the same outcome — no private side-channels.
§ 08 · Tamper-Evident Audit
Hash chain · Merkle anchor
Audit
Every decision is hash-chained; every day is Merkle-rooted and signed.
Audit events include the hash of the previous event, so any edit breaks the chain. Once a day, Paphwey publishes a signed Merkle root over the day's events to a well-known endpoint. Auditors, regulators, and partner RPs can independently verify that the story was not rewritten.
Hash chain on write
Each audit event stores the previous event's hash. Tampering with an older row breaks every row after it.
Daily Merkle anchor
A single signed root covers the whole day. Verifiers compare the published root against a root they compute themselves.
Served at a well-known URL
Polling /.well-known/paphwey-audit-anchor with a date returns the signed envelope — cached, auditable, low-friction.
Signed by the active key
Signatures use the same key set that signs attestations, so verifiers only need one discovery endpoint.
§ 09 · Trust Framework Anchor
ToIP layer model
Framework
Paphwey anchors agent and wallet identities as DIDs within the Trust over IP layer model.
Governance teams and auditors should not have to read a bespoke architecture diagram. Paphwey operates as a ToIP Layer 3 credential issuer and Layer 4 application, so every interop question maps onto a layer the framework already defines.
Verification keys published at /.well-known/did.json
The gateway's did:web document lists JsonWebKey2020 verification methods drawn from the active JWKS — one discovery endpoint for DID-aware verifiers.
Same JWKS still lives at /.well-known/jwks.json
Existing JWT verifiers do not have to learn DID resolution. The Plan 3 JWKS endpoint continues to serve the same keys with a 60-second cache.
Layer 3 — credential issuer
Delegation credentials and attestations are W3C Verifiable Credentials signed by the gateway's DID, suitable for governance frameworks like EUDI ARF and NIST SP 800-63 (planned conformance statements).
Layer 4 — application
The orchestration APIs (challenge, approval, attestation, revocation) are the application-layer surface that sits on top of the credential and identifier layers.
§ 10 · Who holds which key
Four actors, four keys
Key custody
Every signature on the wire is attributable to exactly one actor.
Paphwey's trust story is simple to audit because the cryptographic chain maps one-to-one onto the human story: the user authorises on their phone, the phone signs the delegation binding, the agent signs every challenge, and the gateway signs the credentials the business consumes. No shared signing key, no ambiguous envelope.
User — no signing key
The user is the authority but never signs anything themselves. Their consent travels exclusively through the wallet device, which means a stolen password can't forge delegation.
Wallet device — device_pem
Holds a per-enrolment PEM keypair. Signs challenge approvals
and the delegation binding payload that pins a
specific agent public key to a delegation. Registered at
POST /api/v1/mobile/auth/device/key/register.
AI agent — agent_jwk
Holds an ES256 or Ed25519 keypair it generated for this
delegation. The public half is pinned into
cnf.jwk of the delegation VC. The agent proves
possession at every challenge by signing
{challenge_id, nonce, audience, timestamp}.
Gateway — gateway_jwks
Signs the delegation VC and the attestation. The active
JWKS is published at /.well-known/jwks.json
and mirrored through the gateway's did:web
document. RPs verify everything off this one endpoint.
Relying party — no custodial key
The business holds an RP API key for rate-limiting and billing, but no signing key enters the trust chain. That's deliberate: it keeps RPs stateless verifiers rather than trusted issuers.
What revocation looks like
Rotating any one key invalidates only that actor's future signatures — a leaked agent key doesn't re-issue the VC, and a revoked delegation doesn't invalidate the gateway's JWKS. Blast radius is bounded by key custody.
§ 11 · Regulatory alignment
PSD2 · MLR · NIST
For the CISO, MLRO, and audit committee
Paphwey's trust chain lines up against the three frameworks our regulated customers already have to defend.
We do not ask a risk function to accept a new regulatory story. We emit the artefacts — a delegation credential, an attestation token, a hash-chained receipt — that slot into frameworks already being read against. Detail and jurisdictional coverage live in the compliance FAQ.
PSD2 SCA
The attestation token captures the strong-customer-authentication moment and the transaction-risk signal in a form the relying party's PSP can verify under the PSD2 regulatory technical standards. A delegated agent action still traces back to a user-approved SCA event on the wallet device.
UK MLR 2017
Identity-proofing obligations under regulation 28 are carried by the IAT; record-keeping obligations under regulation 40 are carried by the hash-chained receipt and daily Merkle anchor. Paphwey itself is not a regulated entity under MLR 2017 — the obligations remain with the relying party.
NIST SP 800-63
Assurance-level semantics follow NIST's identity framework: IAL, AAL, and FAL signals ride inside the credential the agent presents. The same credentials cover the emerging Non-Human Identity (NHI) guidance for software acting on a user's behalf.
Company