@intyga/verify 0.0.0-bootstrap.0 → 1.0.0

package/dist/index.d.ts

@@ -0,0 +1,803 @@
+/**
+ * A DIV Proof Envelope — a verifiable proof of what the human approved, returned once a challenge is
+ * APPROVED. `canonicalPayload` is the exact signed bytes (the DIV Intent Payload); the remaining
+ * fields are the signature metadata needed to verify it, extended beyond DIV §4.4's raw-ES256 shape
+ * with the WebAuthn assertion components so a passkey approval — the primary approver path — is
+ * representable.
+ */
+export interface ApprovalReceipt {
+    canonicalPayload: string;
+    target?: string | null;
+    actionType?: string | null;
+    actionDescription: string;
+    params: Record<string, unknown>;
+    /**
+     * EVERY witness signature over `canonicalPayload`. A quorum receipt carries one entry per approver;
+     * a single-signer receipt carries one. Emitting only the first approval made an M-of-N approval
+     * indistinguishable from a 1-of-1 one, so the quorum could not be verified offline at all.
+     */
+    signatures?: ApprovalWitness[] | null;
+    signerDid?: string | null;
+    signerPublicKey?: string | null;
+    signature?: string | null;
+    sigAlg?: string | null;
+    authenticatorData?: string | null;
+    clientDataJSON?: string | null;
+    requester?: RequesterIdentity | null;
+    verificationCode: string;
+}
+/** One approver's signature over the canonical payload. */
+export interface ApprovalWitness {
+    signerDid: string;
+    signerPublicKey: string;
+    signature: string;
+    sigAlg?: string | null;
+    authenticatorData?: string | null;
+    clientDataJSON?: string | null;
+}
+/** Thrown when a value outside the JSON data model is handed to the canonicalizer. */
+export declare class NonCanonicalValue extends Error {
+}
+/**
+ * Deterministic JSON with recursively sorted keys — identical to mcp-schemas.stableStringify.
+ *
+ * STRICT: RFC 8785 defines a mapping over JSON data, so anything outside that domain is REJECTED
+ * rather than coerced. The permissive version silently collapsed distinct runtime values onto one
+ * canonical string — `new Date(0)`, `{}`, `new Map()` and any class instance all serialized to `{}`,
+ * and a `toJSON` method was emitted as a `null`-valued key instead of being honoured. For a function
+ * whose entire job is "these bytes are exactly what was signed", quietly mapping several inputs onto
+ * one output is the wrong failure mode: the relying party's `expected.params` come from its own live
+ * runtime objects, so it is the caller most likely to hand us a Date.
+ *
+ * Exported so the shared golden vectors can pin THIS copy directly (vectors.test.ts) — every other
+ * port pins its canonicalizer against the committed file; the shipped relying-party verifier must
+ * not be the one implementation pinned only transitively.
+ */
+export declare function stableStringify(value: unknown): string;
+/** The requesting workload's identity, as bound into a DIV Intent Payload. Mirrors mcp-schemas. */
+export interface RequesterIdentity {
+    did: string;
+    attestation: {
+        method: string;
+        issuer: string;
+        subject: string;
+    } | null;
+}
+/** Agent-only DIV v1 claims. Configuration and execution truth are checked by the RP's PEP. */
+export interface AgentIntentContext {
+    action: {
+        reversibility: "reversible" | "irreversible";
+        amount: {
+            amount: string;
+            currency: string;
+        } | null;
+    };
+    agent: {
+        label: string;
+        configDigest: string;
+        delegatedBy: string | null;
+    };
+    session: {
+        id: string;
+        seq: string;
+        prev: string | null;
+        aggregate: {
+            amount: string;
+            currency: string;
+        } | null;
+    };
+    nbf: string;
+}
+export declare function validateAgentIntentContext(context: AgentIntentContext, expiresAt: string): void;
+/** DIV protocol version and type discriminator — identical to mcp-schemas. */
+export declare const DIV_VERSION = 1;
+export declare const DIV_INTENT_TYPE = "div-intent-verification";
+/**
+ * OFFLINE APPROVAL (docs/DIV.md §5a.2): a normal approval, signed by real humans through the normal
+ * quorum, but collected OUT OF BAND at incident time because the gateway is unreachable. The relying
+ * party builds the challenge itself, the humans review and sign it on a disconnected device, and the
+ * result is verified by the ordinary §5 procedure.
+ *
+ * This deliberately replaces the older pre-signed "sealed break-glass" token. Pre-signing puts a
+ * bearer capability on disk and captures a human judgment about a HYPOTHETICAL; moving the ceremony
+ * off the network instead keeps the human in the loop for the ACTUAL incident and leaves nothing at
+ * rest to steal. See DIV §5a.1.
+ *
+ * The distinct `type` is the single most important guardrail in the whole mechanism. It sits inside
+ * the signed bytes, so:
+ *   - an offline proof can NEVER verify as a normal approval, and
+ *   - a normal approval can NEVER be replayed as an offline one.
+ * Neither direction is possible even with a byte-identical action, because the reconstructed payload
+ * differs and the signature comparison fails. Do not "simplify" this into a flag outside the payload.
+ */
+export declare const DIV_OFFLINE_INTENT_TYPE = "div-offline-intent";
+/**
+ * DELEGATION (docs/DIV.md §5a.5): signed in advance by the ordinary quorum, it transfers the
+ * AUTHORITY TO APPROVE one pre-declared action to a named set of local operators.
+ *
+ * A delegation authorizes NOTHING by itself. `verifyApprovalReceipt` refuses this type outright and
+ * there is deliberately no opt-in flag that would let it through — see `verifyDelegation`, which is a
+ * separate operation for exactly that reason. A delegation that could authorize its own action would
+ * be the pre-signed bearer capability DIV §5a.1 rejects.
+ */
+export declare const DIV_DELEGATION_TYPE = "div-delegation";
+/**
+ * Agent authority (DIV §5b): a quorum-signed statement of STANDING SCOPE for one agent. Authorizes
+ * no action on its own; `verifyApprovalReceipt` refuses it outright, and `verifyAgentAuthority` is
+ * the only door. Mirrors mcp-schemas.
+ */
+export declare const DIV_AGENT_AUTHORITY_TYPE = "div-agent-authority";
+/**
+ * Platform hash-only intent (DIV §5c): an integrating platform's subject signs the DIGEST of the
+ * platform's own canonical payload. `verifyApprovalReceipt` refuses it outright;
+ * `verifyPlatformReceipt` is the only door. Mirrors mcp-schemas.
+ */
+export declare const DIV_PLATFORM_INTENT_TYPE = "div-platform-intent";
+/**
+ * Hard ceiling on an offline proof's validity window, enforced at verification and not only at mint.
+ * An offline proof is created and redeemed within one incident, so the window is minutes — it exists
+ * to bound a proof whose `expiresAt` was minted over-long, which is otherwise indistinguishable at
+ * verification time from a correct one (DIV §5a.3).
+ */
+export declare const MAX_OFFLINE_WINDOW_MINUTES = 60;
+/**
+ * Ceiling on the witness list this verifier will process. A DIV quorum is single digits — this is a
+ * denial-of-service bound, not a policy limit, because verification runs in the relying party's own
+ * process on an attacker-supplied receipt immediately before an irreversible action.
+ */
+export declare const MAX_WITNESSES = 64;
+/**
+ * Hard ceiling on a delegation's validity window. Hours, not the 30 days the old sealed token
+ * allowed: a delegation cannot be revoked at an offline relying party, so the short window IS the
+ * revocation story (DIV §5a.6).
+ */
+export declare const MAX_DELEGATION_WINDOW_HOURS = 72;
+/**
+ * The approval policy in force for a challenge, frozen at creation and SIGNED as part of the payload.
+ *
+ * This exists because the gateway enforces a rich requirement (quorum, four-eyes, hardware class) that
+ * used to appear nowhere in the signed bytes. A receipt from a 3-of-3, hardware-key-pinned challenge
+ * was byte-for-byte indistinguishable from a 1-of-1, no-hardware one — so a relying party doing
+ * "offline verification" still had to take the gateway's word for the entire policy, which is the
+ * exact class of trust the offline verifier exists to remove. Binding it into the payload also means
+ * the APPROVER sees and attests to the policy their signature is being counted toward.
+ *
+ * What a verifier can check offline, and what it cannot:
+ *  - `requiredApprovals` — fully checkable. Counts distinct trusted approver signatures.
+ *  - `requesterCannotApprove` — fully checkable. The requester DID is in the same signed payload.
+ *  - `requireHardwareKey` — PARTIALLY checkable. A verifier can confirm the witness is a WebAuthn
+ *    assertion rather than a bare P-256 key, and it refuses one whose signed authenticatorData says
+ *    Backup Eligible or Backup State (a synced passkey announcing itself). An assertion carries no
+ *    attestation, though, so BE=0 is the authenticator's claim, not proof of a discrete security key.
+ *  - `allowedAaguids` — NOT checkable offline. The AAGUID lives in attestedCredentialData, which is
+ *    present at REGISTRATION, not in an assertion. Only the gateway (which stored it at enrollment)
+ *    can enforce the model. What a verifier CAN do is refuse what obviously cannot satisfy it: a
+ *    non-empty allowlist is treated exactly like `requireHardwareKey` — a bare-key witness is refused
+ *    and an offline proof is refused outright (`requiresHardwareCredential`).
+ *  - `signerClass` — PARTIALLY checkable, and differently per witness kind. For a WEBAUTHN witness
+ *    the UV flag (already required by `verifyWebAuthnSignature`) is cryptographic evidence a
+ *    user-verification ceremony — a human gesture — happened at signing. An ES256 witness carries no
+ *    signer-class evidence at all: there the class rests on the issuing deployment's signing-time
+ *    enforcement, or, for an offline proof, on the delegation ceremony that named the operators.
+ *    The verifier's own obligation is narrower and absolute: REFUSE any value it does not
+ *    recognize (only "human" is defined today), so a future signer class can never verify as
+ *    human-approved by default. It deliberately does NOT reject ES256 witnesses under
+ *    `signerClass: "human"` — humans legitimately sign with raw P-256 keys (offline break-glass);
+ *    a deployment wanting cryptographic proof of the ceremony pins `requireHardwareKey`.
+ */
+/**
+ * Whether a signed requirement can only be met by a hardware-backed WebAuthn credential: an explicit
+ * `requireHardwareKey`, OR a non-empty `allowedAaguids` model allowlist. The two are the same class of
+ * policy for every check a verifier can make — a bare key satisfies neither, and neither can be met
+ * offline — so they are refused together. Treating the allowlist as "not checkable, so not checked"
+ * let a bare software key satisfy a YubiKey-only rule on every offline path.
+ */
+export declare function requiresHardwareCredential(requirement: {
+    requireHardwareKey?: unknown;
+    allowedAaguids?: unknown;
+}): boolean;
+export interface ApprovalRequirementAttestation {
+    requiredApprovals: number;
+    requireHardwareKey: boolean;
+    allowedAaguids: string[];
+    requesterCannotApprove: boolean;
+    /** Required signer class — `"human"` is the only value defined today. Unrecognized values are refused. */
+    signerClass: string;
+}
+/**
+ * The one signer class defined by DIV today (docs/DIV.md §4.3.2). Mirrors mcp-schemas, like
+ * DIV_VERSION — this package deliberately imports nothing from it.
+ */
+export declare const SIGNER_CLASS_HUMAN = "human";
+/**
+ * Canonical DIV Intent Payload (docs/DIV.md v1) — byte-identical to
+ * mcp-schemas.canonicalIntentPayload. Strict RFC 8785 JCS: the whole object is serialized with every
+ * key sorted recursively by UTF-16 code unit via `stableStringify`. Do NOT hand-order keys.
+ */
+export declare function canonicalIntentPayload(input: {
+    target: string;
+    actionType: string;
+    display: string;
+    params: Record<string, unknown>;
+    requester: RequesterIdentity;
+    requirement: ApprovalRequirementAttestation;
+    nonce: string;
+    expiresAt: string;
+    agentContext?: AgentIntentContext;
+}): string;
+/**
+ * Canonical OFFLINE INTENT payload (DIV §5a.2). Deliberately a separate function rather than a `type`
+ * parameter on `canonicalIntentPayload`.
+ *
+ * A parameter would mean every existing call site could silently produce the wrong kind by passing
+ * the wrong argument, and the normal approval path — which is the overwhelmingly common one — would
+ * carry a footgun for the sake of a rare one. Two functions cannot be confused: you either called the
+ * offline builder or you did not.
+ *
+ * `challengedAt` is the only extra field, and it exists so the verifier can bound the validity
+ * WINDOW. Without it, a payload minted with a 10-year `expiresAt` would be indistinguishable from a
+ * correctly minted one at verification time.
+ */
+export declare function canonicalOfflineIntentPayload(input: {
+    target: string;
+    actionType: string;
+    display: string;
+    params: Record<string, unknown>;
+    requester: RequesterIdentity;
+    requirement: ApprovalRequirementAttestation;
+    nonce: string;
+    challengedAt: string;
+    expiresAt: string;
+}): string;
+/**
+ * Canonical DELEGATION payload (DIV §5a.5) — a signed statement about WHO MAY APPROVE, not about
+ * what may run.
+ *
+ * `delegatedTo` is sorted because it is a SET: the same three operators in a different order must
+ * produce the same bytes, exactly as for `allowedAaguids`. `requirement` here describes the quorum
+ * that signed this delegation, while `delegatedQuorum` is how many of `delegatedTo` must sign at
+ * incident time — two different quorums, which is why both are in the signed bytes.
+ */
+export declare function canonicalDelegationPayload(input: {
+    target: string;
+    actionType: string;
+    display: string;
+    params: Record<string, unknown>;
+    requester: RequesterIdentity;
+    requirement: ApprovalRequirementAttestation;
+    delegatedTo: string[];
+    delegatedQuorum: number;
+    nonce: string;
+    sealedAt: string;
+    expiresAt: string;
+}): string;
+/**
+ * Canonical AGENT AUTHORITY payload (DIV §5b) — byte-identical to
+ * mcp-schemas.canonicalAgentAuthorityPayload; parity is enforced by `canonical-parity.test.ts`.
+ *
+ * Not a delegation: `div-delegation` deliberately covers exactly one action, forbids wildcards and
+ * caps its window at 72 hours, because it pre-authorizes WHO MAY APPROVE at incident time. An
+ * authority is governance enforced online — it may carry a scope (patterns) and a long validity
+ * precisely because it authorizes nothing offline. `actionPatterns` is sorted because it is a SET,
+ * exactly as `allowedAaguids` is.
+ */
+export declare function canonicalAgentAuthorityPayload(input: {
+    target: string;
+    actionPatterns: string[];
+    display: string;
+    agent: {
+        did: string;
+    };
+    parentReceiptHash?: string | null;
+    requester: RequesterIdentity;
+    requirement: ApprovalRequirementAttestation;
+    nonce: string;
+    sealedAt: string;
+    expiresAt: string;
+}): string;
+/**
+ * Canonical PLATFORM HASH-ONLY INTENT payload (DIV §5c.2) — byte-parity with mcp-schemas' copy is
+ * enforced by canonical-parity.test.ts. This mirror REPRODUCES bytes and does not validate the
+ * digest grammar (producers normalize, verifiers reproduce); `verifyPlatformReceipt` enforces the
+ * lowercase-hex rule on the RELYING PARTY's expected value instead.
+ */
+export declare function canonicalPlatformIntentPayload(input: {
+    payloadHash: string;
+    rpId: string;
+    subjectExternalId: string;
+    signedAt: string;
+    expiresAt: string;
+    nonce: string;
+}): string;
+/** Short verification code (first 8 hex of SHA-256 of the canonical payload), grouped XXXX-XXXX. */
+export declare function verificationCode(canonical: string): string;
+/** Verify a raw ECDSA P-256 signature (base64, DER or IEEE-P1363) over `payload` against an SPKI key. */
+export declare function verifyEcdsaP256(publicKeyB64: string, payload: string, signatureB64: string): boolean;
+/** Default clock-skew tolerance for expiry validation (DIV §6.2 RECOMMENDED ±30s). */
+export declare const DEFAULT_CLOCK_SKEW_SECONDS = 30;
+/**
+ * The MINIMUM approval requirement YOUR policy demands for this action (DIV §5 step 3d).
+ *
+ * The signed `requirement` is authored by whoever composed the bytes the approvers signed — the
+ * issuing gateway, or any one approver composing their own payload. Its signature protects it
+ * against third parties, NOT against the signers the quorum constrains: an approver who is also
+ * the requester can sign `{ requiredApprovals: 1, requesterCannotApprove: false }` alone and, without
+ * a floor, that receipt verifies. Supplying the floor makes the verifier refuse any signed
+ * requirement weaker than it, before a single signature is counted.
+ *
+ * Without a floor the verifier proves only the signers' OWN stated quorum. Supply one whenever you
+ * hold the approval rule (a trust bundle, a pinned policy, your own configuration).
+ *
+ * Only strictly weaker values are refused: a signed requirement at least as strict passes, and the
+ * signed value is what is then enforced. `allowedAaguids` is not floored — express a model
+ * restriction as `requireHardwareKey`, which a verifier can at least partially check.
+ */
+export interface RequirementFloor {
+    /** Integer ≥ 1. The signed `requiredApprovals` must be at least this. */
+    requiredApprovals: number;
+    /** When true, the signed requirement must also forbid the requester approving. Defaults to false. */
+    requesterCannotApprove?: boolean;
+    /** When true, the signed requirement must also demand a hardware key. Defaults to false. */
+    requireHardwareKey?: boolean;
+}
+/** The reason stem every port uses when a signed requirement is below the caller's floor. */
+export declare const WEAKER_REQUIREMENT_REASON = "signed requirement is weaker than the relying party's policy";
+/**
+ * The approver identities/keys YOU trust, resolved from your own key-management policy.
+ *
+ * This is the single most important input to verification. Without it, `verifyApprovalReceipt` would
+ * verify a signature using the public key carried INSIDE the receipt — which proves only that the
+ * receipt is internally consistent, i.e. nothing. Anyone able to hand you a receipt (per the DIV
+ * threat model, that includes the untrusted agent itself) could mint a keypair, sign a payload over
+ * the nonce you issued and the params you are about to run, put any string in `signerDid`, and be
+ * told the action was approved by a human. DIV §3 Invariant 3 and §5 step 3 require the Approver key
+ * to be resolved from deployment key-management policy; this type is that step.
+ *
+ *  - `{ publicKeys }`  — a direct allowlist of base64 SPKI / COSE keys.
+ *  - `{ dids, resolveKey }` — a DID allowlist plus your own resolver (directory lookup, pinned
+ *    enrollment record, etc). Return `null` for an unknown DID to reject it.
+ *
+ * PREFER DID MODE where you can. In `publicKeys` mode the receipt's `signerDid` is an unverified
+ * string, so quorum has to count distinct KEYS instead of distinct approvers — and a delegation
+ * (DIV §5a.6), which names identities, cannot be enforced at all.
+ *
+ * `resolveKey` may return SEVERAL keys for one DID. An approver commonly holds a software key plus
+ * one or more registered authenticators, and any of them is legitimately theirs; returning them all
+ * keeps the identity intact instead of forcing callers to flatten everything into `publicKeys` mode
+ * and lose the DID binding. Every key returned for a DID counts as that ONE approver.
+ *
+ * SELF-CERTIFYING DIDs need no resolver. A pinned DID of the form `did:intyga:key:<fingerprint>`
+ * (see {@link SELF_CERTIFYING_DID_PREFIX}) is itself a commitment to the enrolled public key, so the
+ * witness-carried key can be validated against the DID by hashing — no key distribution at all.
+ * `resolveKey` is therefore optional: it is required only for pinned DIDs that are NOT
+ * self-certifying, and verification fails closed with an explicit reason when such a DID is
+ * encountered without one.
+ *
+ * PRECEDENCE: when `resolveKey` DOES return keys for a self-certifying DID, those keys are the
+ * anchor and the hash commitment is not consulted. That is what lets a deployment widen the DID to
+ * the person's later-enrolled credentials, and — the security-relevant direction — NARROW it: a
+ * compromised credential is dropped by mapping the DID to the remaining keys, which a
+ * commitment-always-wins rule would silently keep trusting.
+ */
+export type ApproverTrustAnchor = {
+    publicKeys: string[];
+    dids?: undefined;
+    resolveKey?: undefined;
+} | {
+    dids: string[];
+    resolveKey?: (did: string) => string | string[] | null;
+    publicKeys?: undefined;
+};
+/**
+ * Prefix of a self-certifying Intyga DID: `did:intyga:key:<base64url(sha256(publicKey bytes))>`.
+ * The identifier IS a commitment to the enrolled public key (the issuing gateway's derivation), so a
+ * DID of this form can serve as a complete trust anchor entry on its own. The commitment is to the
+ * EXACT enrolled key bytes — an approver signing with a different credential (say, a browser passkey
+ * registered later) does not match it, and needs a `resolveKey` mapping under a stable DID instead.
+ */
+export declare const SELF_CERTIFYING_DID_PREFIX = "did:intyga:key:";
+/**
+ * Derive the self-certifying DID for a public key (base64; the DECODED bytes are hashed, so padded
+ * and unpadded encodings of the same key derive the same DID). Mirrors the gateway's derivation.
+ */
+export declare function selfCertifyingDid(publicKeyB64: string): string;
+/** What you assert the receipt must say. `target`, `nonce` and `approvers` are required. */
+export interface ReceiptExpectation {
+    /**
+     * REQUIRED. The approvers you trust — see ApproverTrustAnchor. There is deliberately no default:
+     * a receipt cannot be permitted to vouch for its own signer.
+     */
+    approvers: ApproverTrustAnchor;
+    /**
+     * YOUR target identifier — the Relying Party / execution environment this approval must be bound to
+     * (DIV Target Isolation). Required and asserted from your own identity, never read from the
+     * receipt: this is what rejects an approval minted for a different service (cross-service replay).
+     */
+    target: string;
+    actionType: string;
+    params: Record<string, unknown>;
+    /**
+     * The challenge nonce YOU issued and are redeeming. Required: it is what ties this receipt to one
+     * specific request you are tracking. See the replay note on verifyApprovalReceipt.
+     */
+    nonce: string;
+    /** Optionally assert WHICH workload the approval was granted to. */
+    requesterDid?: string;
+    /** Independent PEP state for an AI_AGENT receipt. Never copy this from the receipt. */
+    agentContext?: AgentIntentContext;
+    /**
+     * STRONGLY RECOMMENDED. The minimum requirement YOUR approval rule demands for this action — see
+     * RequirementFloor. Without it this verifier enforces only the quorum the signers themselves
+     * stated, which one approver (possibly the requester) can set to 1-of-1. Under a delegation, pass
+     * the ORDINARY rule: the delegated quorum must already be at least as strict (DIV §5a.5).
+     */
+    requirement?: RequirementFloor;
+}
+/** Verification options. The WebAuthn expectations are mandatory for a WEBAUTHN receipt. */
+export interface VerifyReceiptOptions {
+    allowAutoApproved?: boolean;
+    /** A complete root-to-leaf, independently trusted chain is mandatory for delegated agent receipts. */
+    agentAuthorityChain?: Array<{
+        receipt: ApprovalReceipt;
+        expected: {
+            approvers: ApproverTrustAnchor;
+            target: string;
+            agentDid: string;
+            requirement?: RequirementFloor;
+        };
+    }>;
+    /**
+     * Accept an OFFLINE APPROVAL (`type: "div-offline-intent"`). Defaults to FALSE — an offline proof is
+     * refused on every ordinary call site, exactly like `allowAutoApproved`.
+     *
+     * Pass this at the SPECIFIC call that is allowed to run under an offline approval, never globally. A
+     * process-wide default would mean every gated action in the service silently accepts an
+     * out-of-band approval, which is the difference between an emergency mechanism and a hole.
+     *
+     * Setting it does not weaken any other check: the quorum, four-eyes and target binding signed into
+     * the payload are still enforced, the window is capped at MAX_OFFLINE_WINDOW_MINUTES, and a proof
+     * whose signed policy demands a hardware key is REFUSED (DIV §5a.3 step 4) because that requirement
+     * cannot be satisfied offline.
+     */
+    allowOffline?: boolean;
+    /**
+     * A delegation that has ALREADY been verified by `verifyDelegation`, substituting the eligible
+     * approver set and the quorum for this one verification (DIV §5a.6).
+     *
+     * Only meaningful together with `allowOffline`. This narrows rather than widens: the delegation's
+     * target/actionType/params must equal what you are executing, and the offline payload's signed
+     * `requiredApprovals` must equal the delegation's `delegatedQuorum`, so the operators still sign the
+     * policy their signatures are counted toward. Its expiry is rechecked at this verification's
+     * evaluation time even if the successful seal verification was cached.
+     */
+    delegation?: VerifiedDelegation;
+    /** Exact `origin` the assertion must carry, e.g. "https://app.example.com". Required for WEBAUTHN. */
+    expectedOrigin?: string;
+    /** RP ID the authenticatorData must hash to, e.g. "app.example.com". Required for WEBAUTHN. */
+    expectedRpId?: string;
+    /** Demand the User-Verified flag (biometric/PIN, not mere possession). Defaults to true. */
+    requireUserVerification?: boolean;
+    /**
+     * Accept an assertion produced inside a cross-origin frame. Defaults to FALSE (refuse).
+     *
+     * `origin` alone cannot detect this: inside a cross-origin iframe the browser reports the FRAME's
+     * origin — which for an embedded RP page is the RP's own origin — and rpIdHash matches too. So with
+     * `publickey-credentials-get` delegated, a third-party embedder can drive a high-risk approval
+     * ceremony while every other check here passes. `crossOrigin` is the only signal that distinguishes
+     * the two (W3C WebAuthn L3 §7.2 step 9).
+     */
+    allowCrossOrigin?: boolean;
+    /**
+     * Expiry handling (DIV §5 step 8 / §6.2). By DEFAULT this verifier is fail-closed on `expiresAt`: a proof
+     * whose expiry is in the past (beyond the skew tolerance) is rejected — the correct behaviour for a
+     * pre-execution check. Set `allowExpired: true` ONLY for post-hoc audit/forensic re-verification,
+     * where you deliberately want to confirm a signature that was valid at the time even though it has
+     * since expired. `asOf` overrides "now" for deterministic/replayed checks.
+     */
+    allowExpired?: boolean;
+    /**
+     * Wall-clock instant to evaluate time against. Defaults to `new Date()`.
+     *
+     * Also the reference point for the forward-dating rule (DIV §5a.3 rule 3), which — unlike expiry —
+     * `allowExpired` does NOT waive: that option re-examines a proof that was valid and has lapsed,
+     * which says nothing about accepting one dated in the future.
+     */
+    asOf?: Date;
+    /** Clock-skew tolerance in seconds for expiry and forward-dating. Defaults to DEFAULT_CLOCK_SKEW_SECONDS. */
+    clockSkewSeconds?: number;
+}
+/** One WebAuthn assertion and the exact payload it claims to sign — a single stored witness row. */
+export interface WebAuthnWitness {
+    /** The string whose UTF-8 bytes were the assertion challenge (the canonical payload), as signed. */
+    signedPayload: string;
+    /**
+     * The credential's P-256 public key, base64 or base64url: a COSE_Key (as recorded at registration)
+     * or DER SubjectPublicKeyInfo. Supply it from YOUR record of the credential — never from the thing
+     * being verified — or any key the presenter chose will do.
+     */
+    publicKey: string;
+    /** base64 or base64url, as the browser returned them. */
+    authenticatorData: string;
+    clientDataJSON: string;
+    /** The DER ECDSA assertion signature. */
+    signature: string;
+}
+export interface WebAuthnWitnessExpectation {
+    /** The origin(s) the assertion may carry, e.g. "https://app.example.com". Required. */
+    expectedOrigin: string | readonly string[];
+    /** The RP ID the authenticatorData must hash to, e.g. "app.example.com". Required. */
+    expectedRpId: string;
+    /** Demand the User-Verified flag. Defaults to TRUE; User-Present is always required. */
+    requireUserVerification?: boolean;
+    /** Accept `clientDataJSON.crossOrigin: true`. Defaults to FALSE (DIV §4.4.5 rule 5). */
+    allowCrossOrigin?: boolean;
+}
+/**
+ * Verify ONE WebAuthn assertion on its own — the §4.4.5 checks every receipt verifier here applies
+ * to each WEBAUTHN witness, without a receipt around it: one approver of a quorum, a console step-up,
+ * a login approval, a row read back out of an audit ledger. Same implementation, not a copy.
+ *
+ * It answers only "did the holder of THIS key sign THIS payload, at THIS relying party, with the
+ * user present". It knows nothing of quorum, validity windows, payload type, the signed requirement
+ * or who the key belongs to: a caller verifying an approval must use verifyApprovalReceipt (or the
+ * delegation/agent-authority/platform verifiers), which also enforce those. Never throws.
+ */
+export declare function verifyWebAuthnWitness(witness: WebAuthnWitness, expectation: WebAuthnWitnessExpectation): {
+    ok: true;
+} | {
+    ok: false;
+    reason: string;
+};
+/**
+ * Independently verify an approval receipt against the instruction you are ABOUT to execute. Recomputes
+ * the canonical payload from your params, confirms it byte-matches what was signed, and verifies the
+ * human's P-256 or WebAuthn signature — with no Intyga secret.
+ *
+ * WHAT THIS PROVES: that enough APPROVERS YOU ALREADY TRUST (`expected.approvers`) signed exactly this
+ * action, with exactly these params, for exactly the target and nonce you pass in `expected`; that the
+ * number of distinct valid signatures meets the quorum recorded in the signed payload; that the
+ * requester did not self-approve when the signed policy forbids it; and that the proof has not expired.
+ *
+ * THE SIGNED QUORUM IS THE SIGNERS' OWN STATEMENT. The signed `requirement` is authored by whoever
+ * composed the bytes — so one approver (possibly the requester) can sign a 1-of-1 payload alone. Pass
+ * `expected.requirement` (your own rule, see RequirementFloor) and a weaker signed requirement is
+ * refused (DIV §5 step 3d). Without it, "quorum met" means only "the quorum the signers stated".
+ *
+ * THE TRUST ANCHOR IS NOT OPTIONAL. Verification uses the key you resolve for an approver, never the
+ * `signerPublicKey` carried in the receipt. A receipt verified against its own embedded key proves
+ * only internal consistency — anyone who can hand you a receipt could have minted the keypair.
+ *
+ * EXPIRY: the signed `expiresAt` is enforced fail-closed by default (±30s skew) — a lapsed proof is
+ * rejected. Pass `{ allowExpired: true }` ONLY for post-hoc audit/forensic re-verification, where
+ * confirming a signature that was valid AT THE TIME is the point.
+ *
+ * WHAT THIS DOES NOT PROVE: that the approval has not ALREADY BEEN USED within its validity window.
+ * Expiry bounds how long a proof is valid, but single-use enforcement is separate and lives in the
+ * gateway's /authorize/verify (which atomically marks the challenge CONSUMED) — this function is a
+ * defense-in-depth companion to that call, not a replacement for it. If you verify offline and skip
+ * the consume step, YOU must record redeemed nonces yourself; requiring `expected.nonce` here is what
+ * makes that possible, since you cannot call this without having tracked the nonce you issued.
+ *
+ * Returns `{ ok: false, reason }` on any mismatch.
+ */
+export declare function verifyApprovalReceipt(receipt: ApprovalReceipt, expected: ReceiptExpectation, opts?: VerifyReceiptOptions): {
+    ok: boolean;
+    reason?: string;
+    autoApproved?: boolean;
+    signers?: string[];
+};
+/** A platform hash-only receipt (DIV §5c) as issued by the gateway's platform plane. */
+export interface PlatformReceipt {
+    /** The exact bytes the subject's passkey signed (the §5c.2 payload). */
+    canonicalPayload: string;
+    /** Display copies only — verification reconstructs from the RELYING PARTY's own values. */
+    payloadHash?: string | null;
+    rpId?: string | null;
+    subject?: {
+        externalId?: string | null;
+    } | null;
+    signedAt?: string | null;
+    expiresAt?: string | null;
+    nonce?: string | null;
+    signatures?: ApprovalWitness[] | null;
+    signerDid?: string | null;
+    signerPublicKey?: string | null;
+    signature?: string | null;
+    sigAlg?: string | null;
+    authenticatorData?: string | null;
+    clientDataJSON?: string | null;
+    verificationCode?: string;
+}
+export interface PlatformReceiptExpectation {
+    /** REQUIRED. The subject keys you trust — same modes as ReceiptExpectation.approvers. */
+    approvers: ApproverTrustAnchor;
+    /**
+     * REQUIRED. The SHA-256 (lowercase hex) YOU recompute from your own copy of the canonical
+     * payload — never read from the receipt. This is the §5c data-minimization anchor: the payload
+     * itself never traveled, so this digest is the entire content binding.
+     */
+    payloadHash: string;
+    /** REQUIRED. YOUR registered WebAuthn RP ID — used for the signed-bytes binding AND as the
+     *  assertion's expected rpIdHash. Asserted from your own configuration, never the receipt. */
+    rpId: string;
+    /** REQUIRED. The signing challenge nonce you are redeeming. */
+    nonce: string;
+    /** Optionally assert WHICH of your subjects signed. */
+    subjectExternalId?: string;
+}
+/**
+ * Verify a PLATFORM HASH-ONLY receipt (DIV §5c.3). Deliberately a separate function:
+ * `verifyApprovalReceipt` refuses the `div-platform-intent` type outright, and this function
+ * refuses every other type, so neither proof kind can ever pass through the other's door.
+ *
+ * Every witness must be a WebAuthn assertion (this plane's subjects only ever sign with enrolled
+ * passkeys on the platform's registered origin), so `opts.expectedOrigin` is REQUIRED and the RP ID
+ * expectation comes from `expected.rpId`. `AUTO_APPROVED` is refused with no override — policy
+ * pre-approval does not exist on this plane.
+ */
+export declare function verifyPlatformReceipt(receipt: PlatformReceipt, expected: PlatformReceiptExpectation, opts?: VerifyReceiptOptions): {
+    ok: boolean;
+    reason?: string;
+    signers?: string[];
+};
+/** A delegation whose own signature, quorum and window have been verified by `verifyDelegation`. */
+export interface VerifiedDelegation {
+    /** Identities permitted to approve at incident time. Enforced against the witness DIDs. */
+    delegatedTo: string[];
+    /** How many distinct members of `delegatedTo` must sign. */
+    delegatedQuorum: number;
+    /** The single action this delegation covers. All three must equal what is being executed. */
+    target: string;
+    actionType: string;
+    params: Record<string, unknown>;
+    /** The delegation's OWN nonce — for the audit trail, never for authorization. */
+    nonce: string;
+    /** Who signed the delegation itself. */
+    signers: string[];
+    expiresAt: string;
+}
+/**
+ * Verify a DELEGATION (DIV §5a.6 step 1) — a statement, signed in advance by the ordinary quorum, that
+ * names local operators who may approve one pre-declared action while the gateway is unreachable.
+ *
+ * Deliberately a SEPARATE function from `verifyApprovalReceipt`, which refuses this payload type
+ * outright. A delegation authorizes nothing, and the only way to keep that true structurally is to
+ * make it impossible to hand one to the approval verifier and get an `ok: true` back. What you get here
+ * is a `VerifiedDelegation` — an input to a later approval check, never a substitute for one.
+ *
+ * `approvers` MUST be the ORDINARY approver set (from your trust bundle), not the delegated operators:
+ * the point of the check is that the people entitled to approve this action are the ones who signed
+ * away that entitlement.
+ */
+export declare function verifyDelegation(receipt: ApprovalReceipt, expected: {
+    /** The ORDINARY approvers entitled to delegate. Resolved from your own trust policy. */
+    approvers: ApproverTrustAnchor;
+    /** YOUR target identifier, asserted independently of the delegation (DIV Target Isolation). */
+    target: string;
+    actionType: string;
+    params: Record<string, unknown>;
+    /**
+     * STRONGLY RECOMMENDED. The ORDINARY approval rule for the delegated action: the delegation's
+     * sealing requirement must be at least this strict (DIV §5a.5, §5 step 3d). Without it only the
+     * sealers' own stated quorum is enforced.
+     */
+    requirement?: RequirementFloor;
+}, opts?: VerifyReceiptOptions): {
+    ok: boolean;
+    reason?: string;
+    delegation?: VerifiedDelegation;
+};
+/** An agent authority whose sealing signatures, quorum and window verified (`verifyAgentAuthority`). */
+export interface VerifiedAgentAuthority {
+    /** The agent the authority is ABOUT — from the signed bytes, asserted by the caller. */
+    agentDid: string;
+    target: string;
+    /**
+     * The signed scope, deduplicated. Case-insensitive substring patterns over the machine
+     * `actionType` ONLY — deliberately NOT the human-readable description, which is authored by the
+     * agent being bounded and would let an out-of-scope request cover itself by quoting a pattern
+     * (DIV §5b.2). "*" = all.
+     */
+    actionPatterns: string[];
+    parentReceiptHash: string | null;
+    /** The authority's OWN nonce — for the audit trail, never for authorization. */
+    nonce: string;
+    /** Who sealed it. */
+    signers: string[];
+    sealedAt: string;
+    expiresAt: string;
+}
+/**
+ * Verify an AGENT AUTHORITY (DIV §5b) — a statement, sealed by a human quorum, of the standing scope
+ * one agent may operate under.
+ *
+ * Deliberately a SEPARATE function from `verifyApprovalReceipt`, which refuses this payload type
+ * outright — the same structural rule as delegations. What you get back is governance EVIDENCE:
+ * "these named humans granted this agent this scope, and the grant was live at `asOf`". It is never
+ * an approval; executing an action still requires an ordinary receipt.
+ *
+ * Two things the caller asserts and never reads from the artifact (DIV Invariant 3):
+ * `expected.approvers` (the sealing quorum's keys, from your own trust policy) and
+ * `expected.target` / `expected.agentDid` (what YOU are checking authority over). Revocation is
+ * authoritative online only — an offline verifier sees validity, not revocation; treat a seal like
+ * a certificate, not a bearer token.
+ */
+export declare function verifyAgentAuthority(receipt: ApprovalReceipt, expected: {
+    /** The sealing approvers entitled to grant. Resolved from your own trust policy. */
+    approvers: ApproverTrustAnchor;
+    /** YOUR target identifier, asserted independently of the artifact (DIV Target Isolation). */
+    target: string;
+    /** The agent whose authority you are checking, asserted independently of the artifact. */
+    agentDid: string;
+    /**
+     * STRONGLY RECOMMENDED. YOUR sealing policy for agent authority: the signed sealing requirement
+     * must be at least this strict (DIV §5b.3, §5 step 3d). Without it only the sealers' own stated
+     * quorum is enforced.
+     */
+    requirement?: RequirementFloor;
+}, opts?: VerifyReceiptOptions): {
+    ok: boolean;
+    reason?: string;
+    authority?: VerifiedAgentAuthority;
+};
+/** Hash the COMPLETE proof, including every witness. Hashing only the intent would permit a
+ * never-approved pending intent to be used as a parent receipt. */
+export declare function agentReceiptDigest(receipt: ApprovalReceipt): string;
+/** Verify a root-to-leaf chain of human-sealed agent scopes. Each child commits the COMPLETE
+ * parent receipt. A child's substring pattern denotes a subset only when it contains one of the
+ * parent's patterns; this deliberately rejects scopes whose inclusion cannot be proved. */
+export declare function verifyAgentDelegationChain(chain: Array<{
+    receipt: ApprovalReceipt;
+    expected: {
+        approvers: ApproverTrustAnchor;
+        target: string;
+        agentDid: string;
+        requirement?: RequirementFloor;
+    };
+}>, action: {
+    target: string;
+    actionType: string;
+    agentDid: string;
+    delegatedBy: string;
+}, opts?: VerifyReceiptOptions): {
+    ok: boolean;
+    reason?: string;
+};
+/** RP-side commitment to the exact model/tool/prompt configuration handed to the agent runtime.
+ * This is an RP assertion, not an integrity attestation. The PEP must recalculate it immediately
+ * before execution and refuse any mismatch with the signed intent. Raw prompt text is never logged. */
+export declare function agentConfigDigest(config: {
+    model: {
+        provider: string;
+        version: string;
+    };
+    tools: Array<{
+        id: string;
+        version: string;
+        schemaDigest: string;
+    }>;
+    systemPrompt: string;
+}): string;
+/** Verify a complete ordered session bundle against a head pinned OUTSIDE the bundle. An
+ * unanchored single branch cannot prove another branch was not withheld. */
+export declare function verifyAgentSessionChain(entries: Array<{
+    receipt: ApprovalReceipt;
+    expected: ReceiptExpectation;
+}>, trustedHead: string, opts?: VerifyReceiptOptions): {
+    ok: boolean;
+    reason?: string;
+    aggregate?: {
+        amount: string;
+        currency: string;
+    } | null;
+};
+export { ALGORITHM_REGISTRY, type AlgorithmRegistry, AUDIT_PROFILE, BUNDLE_KIND, type BundleVerification, type CheckResult, DEWP_PROTOCOL, DEWP_VERSION, deriveVerificationLevel, leafCountMismatch, type ProofBundle, type TrustedCheckpoint, type VerificationLevel, type VerificationProperties, verifyBundle, verifyEmbeddedSignature, type VerifyOptions, } from "./ledger-bundle.js";
+export { EVIDENCE_BUNDLE_KIND, type EvidenceAnchorSet, type EvidenceBundle, type EvidenceEntry, type EvidenceVerification, type EvidenceVerifyOptions, type RedactionRecord, verifyEvidenceBundle, } from "./ledger-evidence.js";
+export { ANCHOR_ALGORITHMS, ANCHOR_CLOCK_SKEW_SECONDS, type AnchorInput, type AnchorKeyResolver, type AnchorPolicy, type AnchorQuorumResult, DEFAULT_MAX_ANCHOR_LAG_SECONDS, type ExpectedCheckpoint, type ExternalAnchorKeys, anchorDigest, anchorDigestHex, anchorPreimage, isWellFormedAnchor, parseAnchorTimestampMs, signAnchor, type SignedAnchor, verifyAnchorQuorum, verifyAnchorSignature, } from "./ledger-anchor.js";
+export { type ChainInput, type ChainVerification, chainHash, chainPreimage, GENESIS_PREV_CHAIN_HASH, type RootsChainEntry, verifyRootsChain, } from "./ledger-chain.js";
+export { parseRekorEvidence, type RekorEvidence, type RekorVerification, rekorPayloadHashFor, verifyRekorAnchor, } from "./ledger-rekor.js";
+export { type AuditLeaf, canonicalPreimage, leafHash } from "./ledger-leaf.js";
+export { hashLeaf, hashPair, merkleProof, merkleRoot, type ProofStep, sha256Hex, verifyMerkleProof, } from "./ledger-merkle.js";
+export { type InclusionProof, verifyInclusionProof } from "./ledger-proof.js";
+export { verifyRfc3161Anchor, verifyRfc3161Timestamp, verifyRfc3161TimestampAsync, type Rfc3161Trust, type Rfc3161Verification, } from "./ledger-rfc3161.js";
+export { verifyAuditSignature, type AuditSignaturePolicy, type AuditSignatureCheck, } from "./ledger-signature.js";