A business challenge appears
A payment approval, onboarding step, account change, or other business action needs trusted identity and user authority.
§ 01 · KNOW YOUR AGENT · CORE IDEA
A user grants an AI agent scoped access to their identity wallet.
That is the core Paphwey model. We help the user approve that access clearly, help the business understand what the agent is allowed to do, and help the resulting action carry trust.
§ 02 · The KYA Flow
Four-step model
The flow
Four steps from user permission to business result.
Each step is a distinct moment of authority — what the business needs, what the user grants, what the agent does, and what the business receives.
The user approves agent access
The user grants the AI agent permission to use their identity wallet for that specific challenge or scope of challenges.
The agent acts within that scope
The agent uses the approved wallet access to perform the task the user allowed it to perform — nothing beyond.
The business receives a trusted outcome
The organization gets a result tied back to approved user authority rather than generic automation.
§ 03 · What Stays True
Invariants
Invariants
The model stays clear even as the challenge changes.
User-controlled wallet
The identity wallet remains under the user's control — not the app's, not the agent's.
Scoped agent access
The user approves what the agent can do, rather than handing over open-ended authority.
Business-specific challenge
The same model can support different business challenges while keeping the trust logic understandable.
For users
Use AI assistance without giving up control of identity.
- Keep the wallet under user authority.
- Approve what the agent can do.
- Use AI help without blind delegation.
For businesses
Accept agent-completed actions with a clearer trust basis.
- Understand what authority the user gave the agent.
- Handle sensitive challenges with stronger approval logic.
- Receive an outcome built for reliance and review.
§ 06 · Policy Contract
Fine-grained caps
Policy contract
Caps evaluate before the wallet is ever invoked — and return a structured reason when they deny.
A delegation carries explicit caps. A relying-party policy layers on top with its own caps. Paphwey checks the delegation first, then the policy, and returns a machine-readable reason whenever either bound rejects the request. No freeform error strings, no silent fall-through.
Policy contract
The JSON that travels with every decision.
{
"spend_cap": {
"amount_minor": 2500,
"currency": "GBP",
"window": "weekly"
},
"per_domain_allowlist": [
"merchant.example.com"
],
"per_api_allowlist": [
"POST /v1/orders"
],
"approval_threshold_minor": 5000,
"reasons": [
"SPEND_CAP_EXCEEDED",
"DOMAIN_NOT_ALLOWED",
"API_NOT_ALLOWED",
"APPROVAL_THRESHOLD_REQUIRED"
]
}
What the RP sees
A signed answer — approved or denied — they can act on.
- Signed attestation on approve; signed denial with reason on deny.
- Delegation credential JWT discoverable via the published JWKS.
- Status and revocation endpoints poll cleanly and are signed too.
- Daily audit anchor lets the RP verify the whole chain after the fact.
§ 07 · Built on Open Standards
Seven anchors
Open standards
Paphwey is legible to the rest of the identity ecosystem — by design, not by translation.
Every layer of the gateway maps onto an open specification: how identifiers are published, how credentials are shaped, how wallets receive them, how verifiers request presentations, and how agents call the API. The stack below is what relying parties, wallets, and governance teams already know how to reason about.
W3C DID Core 1.0
Gateway, wallet, and agent identities are DIDs. The gateway publishes its DID Document at /.well-known/did.json; principals and agents use did:key for offline resolution.
W3C Verifiable Credentials Data Model 2.0
Delegation credentials and attestations both use the VC v2 shape — @context, type, credentialSubject — so VC tooling reads them natively.
IETF SD-JWT VC
The v1 IAT envelope follows draft-ietf-oauth-sd-jwt-vc. Relying parties receive only the claims their policy asked for, backed by SHA-256 disclosure digests.
OpenID for Verifiable Credential Issuance
Wallets pick up Paphwey-issued credentials through OIDC4VCI — credential offer, pre-authorized token, and credential endpoints — advertised at /.well-known/openid-credential-issuer.
OpenID for Verifiable Presentations
Verifier flows use OIDC4VP: a presentation request object pointing at a presentation_definition, a signed response carrying the SD-JWT VC.
OAuth 2.1 + PAR + DPoP
The relying-party API baseline leans on modern OAuth patterns — short-lived tokens, pushed authorization requests, and proof-of-possession where agent binding requires it.
Model Context Protocol (MCP)
The agent-facing interface speaks MCP — paphwey-mcp exposes the agent-action triad as first-class tools for Claude Desktop, ChatGPT Agent Mode, and the OpenAI Agent SDK. See developer docs ↗
§ 08 · Topology
Four actors, four keys
Who holds which key
The wallet-agent-user topology, drawn out.
Paphwey separates four actors on purpose. The user is the human in charge. Their wallet device is the phone they press "approve" on. The AI agent is the software doing the work on their behalf. The relying party is the business that needs a verifiable answer. Each actor holds its own key — so a compromise of any one of them doesn't forge authority for another.
User
Human in charge
Holds the root of authority. Never signs anything directly — always
acts through the wallet device. Can revoke, pause, or re-scope any
delegation from the wallet UI.
Wallet device
Paphwey mobile wallet
Holds a device PEM keypair device_sig.
Signs challenge approvals and, at delegation time, signs the
binding payload that pins a specific agent public key to
the delegation contract.
AI agent
ChatGPT, Claude, internal bot
Holds its own ES256 or Ed25519 keypair agent_pop.
The public half is pinned into the delegation VC's
cnf.jwk. At challenge time the agent signs a
proof-of-possession over
{challenge_id, nonce, audience, timestamp}.
Relying party
Merchant / onboarding host
Holds no signing key of its own for the trust chain — verifies
everything against Paphwey's JWKS gateway_jwks.
Pulls the delegation VC, checks its signature, pins
cnf.jwk, then verifies the agent PoP against that key.
1. Authorise
User approves delegation on the wallet. Agent submits public JWK;
wallet signs the binding payload.
2. Issue VC
Gateway verifies the device signature and packs a VC-JWT with
cnf.jwk = agent public key.
3. Challenge
RP raises a challenge. Agent signs PoP over
challenge_id / nonce / audience / timestamp.
4. Verify
Gateway (and RP, independently) check VC signature, delegation
scope, and PoP against the pinned agent key.
Why four and not three
Collapsing the user and the wallet device into one actor is how phishing wins. Collapsing the agent into the user is how delegation turns into impersonation. Paphwey keeps all four distinguishable on the wire so the business can tell which signature meant which thing.
§ 09 · Where KYA meets KYC/KYB
Regulatory mapping
Regulatory mapping
Every Paphwey artefact maps to a regulatory obligation a relying party already has.
Paphwey is not a KYC vendor. We consume the KYC signal your provider already produces and we emit agent-side artefacts that slot into the frameworks your MLRO, fraud team, and CISO already read against. The table below is the short version — the long form lives in the compliance FAQ.
| Paphwey artefact | Regulatory obligation | Framework reference |
|---|---|---|
| Delegation credential | Non-human identity governance | NIST SP 800-63 (AAL), NYDFS Part 500 (reference) |
| IAT (attestation token) | Strong Customer Authentication / TRA | PSD2 RTS |
| IAT (attestation token) | Identity proofing | UK MLR 2017 reg. 28 |
| Receipt + audit chain | AML record-keeping | UK MLR 2017 reg. 40, FATF R.11 |
| Policy engine | Transaction risk monitoring | DORA (ICT risk), EBA fraud guidelines |
We are not a KYC vendor — we consume the KYC signal your provider already produces.
Next step