Deterministic Intent Verification (DIV) Protocol Specification

1.1 Scope

DIV specifies exclusively:¶

1. The canonical data schema for an explicit intent payload and its proof envelope.¶

2. The deterministic serialization rules adhering to JSON Canonicalization Scheme (JCS) [RFC8785].¶

3. The local, in-process algorithm executed by a Relying Party to verify an intent proof against runtime parameters.¶

1.2 Out-of-Scope (Explicit Non-Goals)

DIV explicitly does NOT define:¶

• Authentication or Identity Management: DIV assumes identity attestation (e.g., OIDC, SPIFFE [SPIFFE], DIDs) is established independently.¶

• Key Distribution or PKI: Public key discovery, trust anchors, and key rotation mechanisms are deferred to external key-management infrastructure.¶

• Transport Protocols: DIV envelopes MAY be carried over HTTP, gRPC, WebSockets, or file-based IPC.¶

• Approval Workflow Orchestration: Step-up prompting, notification routing, and quorum scheduling are operational concerns outside this specification.¶

4.1 Serialization Format

Intent Payloads MUST be serialized into a deterministic byte sequence using JSON Canonicalization Scheme (JCS) [RFC8785].¶

Implementations MUST NOT rely on arbitrary JSON serialization behavior.¶

Canonicalization accepts JSON data only. Runtime arrays with missing elements (for example a sparse JavaScript array) MUST be refused, rather than collapsed into an empty array or converted to null elements. A present JSON null element is preserved: [] and [null] have different signed bytes.¶

Strings MUST be valid Unicode, as RFC 8785 inherits from I-JSON [RFC7493] §2.1. A string — a value or a member name — containing an unpaired UTF-16 surrogate (a high surrogate not followed by a low one, or a low surrogate not preceded by a high one) MUST be refused by producers and verifiers alike. It MUST NOT be serialized as a \udXXX escape, replaced with U+FFFD, or passed through: each of those was the behaviour of some implementation, and a signature over such a string then verified in some languages and not in others. A verifier that parses signed JSON text MUST likewise refuse a \u escape naming an unpaired surrogate, and text that is not valid UTF-8, rather than decode a replacement character. Valid text, including characters outside the Basic Multilingual Plane, is unaffected: this rule changes no canonical bytes for any valid input.¶

The cryptographic signature MUST cover only the canonical serialized Intent Payload.¶

Proof Envelope metadata, transport metadata, and external execution context MUST NOT be included in signature computation.¶

4.2 Intent Payload Schema

{
  "v": 1,
  "type": "div-intent-verification",
  "target": "prod-db-cluster-01",
  "actionType": "db:dropTable",
  "display": "Delete production users table",
  "params": {
    "environment": "production",
    "table": "users"
  },
  "evidence": null,
  "requester": {
    "did": "did:example:service:deploy-pipeline",
    "attestation": null
  },
  "requirement": {
    "requiredApprovals": 2,
    "requireHardwareKey": true,
    "allowedAaguids": ["adce0002-35bc-c60a-2b7b-40b2ede212b7"],
    "requesterCannotApprove": true,
    "signerClass": "human"
  },
  "nonce": "c_8f91a2b4c6e8",
  "expiresAt": "2026-07-24T12:05:00Z"
}

4.3 Intent Payload Field Definitions

For an AI_AGENT requester, the unpublished v1 format uses the agent extension in §4.3.6. exp replaces expiresAt; action, agent, session and nbf are REQUIRED. The ordinary human/service payload above retains expiresAt. A verifier MUST reject an agent payload unless its RP independently supplies the agent context expected for the action it is about to execute.¶

NOTE: '\' line wrapping per RFC 8792

{
  "action": { "reversibility": "irreversible", "amount": { "amount"\
  : "4200", "currency": "USD" } },
  "agent": { "label": "payments-agent", "configDigest": "sha256:<64 \
  lowercase hex>", "delegatedBy": null },
  "session": { "id": "sha256:<64 lowercase hex>", "seq": "1", "prev"\
  : null,
    "aggregate": { "amount": "4200", "currency": "USD" } },
  "nbf": "2026-09-20T12:00:00.000Z",
  "exp": "2026-09-20T12:05:00.000Z"
}

4.4 Proof Envelope Schema

A DIV Proof Envelope contains:¶

1. The canonical Intent Payload, as a string — the exact bytes that were signed.¶

2. One or more witness signatures over those bytes.¶

3. The metadata a Relying Party needs to resolve keys and recompute the payload.¶

The payload MUST be carried as the serialized canonical string, not as a nested object. A nested object would have to be re-serialized before verification, reintroducing exactly the serialization ambiguity §4.1 exists to eliminate.¶

NOTE: '\' line wrapping per RFC 8792

{
  "canonicalPayload": "{\"actionType\":\"db:dropTable\",\"display\":\
  \"Delete production users table\",…}",
  "signerDid": "did:example:human:alice",
  "signerPublicKey": "base64-spki-p256",
  "signature": "base64-signature",
  "sigAlg": "ES256",
  "verificationCode": "AB12-CD34",
  "actionDescription": "Delete production users table",
  "params": { "environment": "production", "table": "users" }
}

{
  "canonicalPayload": "{\"actionType\":\"db:dropTable\",…}",
  "signatures": [
    {
      "signerDid": "did:example:human:alice",
      "signerPublicKey": "base64-cose-key",
      "signature": "base64-assertion-signature",
      "sigAlg": "WEBAUTHN",
      "authenticatorData": "base64url-authenticator-data",
      "clientDataJSON": "base64url-client-data-json"
    },
    {
      "signerDid": "did:example:human:bob",
      "signerPublicKey": "base64-cose-key",
      "signature": "base64-assertion-signature",
      "sigAlg": "WEBAUTHN",
      "authenticatorData": "base64url-authenticator-data",
      "clientDataJSON": "base64url-client-data-json"
    }
  ],
  "verificationCode": "AB12-CD34",
  "actionDescription": "Delete production users table",
  "params": { "environment": "production", "table": "users" }
}

5a.1 Motivation

A DIV deployment is fail-closed (Invariant 4): when the approval service is unreachable, no proof can be obtained and the Irreversible Action does not execute. That is correct, and it places the approval service in the critical path of every governed action.¶

An operator therefore needs a mechanism that survives the outage. The naive answer — pre-signing approvals for anticipated actions and holding them until needed — is NOT RECOMMENDED by this specification. Such a proof is a bearer capability at rest: possessing the file is sufficient to act, it cannot be revoked at an offline Relying Party, and the human signature attests to a judgment made about a hypothetical rather than about the incident in progress. Narrowing the action and its parameters does not repair this, because the defect is in when the human decided, not in how much they authorized.¶

This section specifies the alternative. Offline Approval moves the signing ceremony off the network rather than earlier in time. The Relying Party constructs the challenge locally at incident time, Approvers review and sign it on a device with no connectivity, and the Relying Party verifies the result with the same stateless procedure of §5. No capability exists at rest, the humans see the actual incident, and the validity window is minutes rather than weeks.¶

Two mechanisms are defined. §5a.2–§5a.4 specify Offline Approval, which applies when the approval service is unreachable but the Approvers are not. §5a.5–§5a.6 specify Delegation, a narrow pre-signed artifact for the residual case where the Approvers themselves cannot be reached; a Delegation authorizes no action by itself and transfers only the authority to approve.¶

5a.2 Offline Intent Payload

An Offline Intent Payload is identical to the Intent Payload of §4.2 except that:¶

The type discriminator is inside the signed bytes. An Offline Intent Proof therefore MUST NOT verify as an Intent Proof, and an Intent Proof MUST NOT verify as an Offline Intent Proof, even for a byte-identical action. Implementations MUST provide the two canonicalizations as distinct operations; a single operation parameterized by type is NOT RECOMMENDED, because it permits the ordinary path to emit an offline payload by mistake.¶

The nonce MUST be generated by the Relying Party (§6.1), which is the party that will redeem it. Because the approval service never sees the challenge, no other party can enforce its single use.¶

challengedAt exists so a verifier can bound the validity window, not merely the expiry. Without it, a payload minted with an over-long expiresAt is indistinguishable at verification time from a correctly minted one.¶

5a.3 Offline Verification

A Relying Party verifying an Offline Intent Proof MUST perform the §5 procedure, reconstructing the payload with the offline canonicalization, and MUST additionally:¶

1. Refuse by default. An Offline Intent Proof MUST be rejected unless the caller has explicitly opted in at that call site. A process-wide or default-on opt-in is NOT RECOMMENDED. An Offline Intent Proof with no human signature (sigAlg: AUTO_APPROVED) MUST be rejected regardless of any auto-approval opt-in.¶

2. Bound the window. expiresAt - challengedAt has a fixed ceiling of 60 minutes. A deployment MAY enforce a shorter window and MUST NOT accept a longer one; a proof whose window exceeds the deployment's cap MUST be rejected even when its signature is valid.¶

3. Reject inverted and forward-dated windows. expiresAt earlier than challengedAt MUST be rejected. A challengedAt later than the verification time plus the §6.2 clock-skew tolerance MUST also be rejected: capping the window's width without bounding its position leaves the window free to slide, so a proof dated years ahead with a compliant 60-minute window would verify today and keep verifying until that date — exactly the pre-signed bearer capability §5a.1 rejects. This rejection is unconditional and is NOT waived by the audit override of §6.2, which exists to re-examine a proof that was valid and has since lapsed and says nothing about one dated in the future.¶

4. Refuse a hardware-key requirement. If the signed approval requirement sets requireHardwareKey, or carries a non-empty allowedAaguids authenticator-model allowlist, the proof MUST be rejected. See §5a.8; this constraint is normative because the requirement cannot be satisfied offline — an offline witness is a bare key, which has no authenticator model at all — and accepting the proof anyway would silently downgrade the policy the Approver attested to. A producer SHOULD refuse to create an offline challenge, or declare an offline runbook, under such a rule.¶

5. Enforce every other invariant unchanged — Target Isolation (§3 Invariant 5), parameter binding (§3 Invariant 1), local payload reconstruction (§3 Invariant 2), the signed approval requirement including requesterCannotApprove (§4.3.2), the §5-step-3d comparison against the Relying Party's policy — normally the Trust Bundle rule for the action (§5a.4) — and expiry (§6.2).¶

The approval requirement bound into an Offline Intent Payload MUST be obtained from an authority outside the Relying Party — normally a Trust Bundle (§5a.4). A Relying Party that composes the requirement itself is setting its own quorum, and the resulting proof attests to nothing beyond that Relying Party's own configuration.¶

5a.4 Trust Bundle

Offline verification requires the Approver keys to be resolvable locally: Invariant 3 forbids taking them from the proof under verification, and the directory that would ordinarily answer the lookup is by definition unreachable. A Trust Bundle is the offline projection of the approval policy, exported while connectivity exists and verified locally thereafter.¶

A Trust Bundle MUST carry, at minimum:¶

A Trust Bundle MUST be integrity-protected by a signature the Relying Party can verify without network access, using key material pinned at export time. A Relying Party MUST refuse an expired bundle, and MUST NOT fall back to an unverified or unbounded Approver set when no valid bundle is available.¶

Reference format (informative). The reference implementation (packages/sdk/src/trust-bundle.ts, exported with intyga trust-bundle export) carries the Trust Bundle as a compact JWS (RS256) whose payload is the bundle JSON above, verified against the issuing gateway's public key stored alongside it at export time — the pinned-at-export key material this section requires. The exact policy profile carries complete quorum, hardware, four-eyes, requester-attestation, allowlist, eligibility, escalation and automatic-window metadata. Group membership is expanded at export; escalation signers remain separate from initial eligibility. The selected rule MUST preserve every constraint of the * baseline or resolution MUST refuse the action. Unknown actions use the baseline only when the signed unmatchedActionPolicy says BASELINE; unsupported offline controls MUST be refused. Signed selectionRank/selectionKey fields are informational, not a substitute for validating the complete constraints. Legacy bundles MUST NOT be used to create new approvals under this profile; ordinary historical receipt verification is unchanged. See the implementation's rollout and compatibility guidance for disconnected consumers. On top of the bundle's own expiresAt it enforces a 30-day maximum age from issuedAt, so an operator who sets a distant expiry still cannot keep a stale approver set in service indefinitely. Other formats satisfying the normative requirements above are equally conformant.¶

Because an Approver identity may be bound to more than one public key (for example a software key and several registered authenticators), a conformant trust anchor MUST be able to associate multiple keys with one identity, and quorum MUST count distinct identities rather than distinct keys. Counting keys would let a single Approver holding several credentials satisfy an M-of-N quorum alone.¶

5a.5 Delegation of Approval Authority

Offline Approval requires the Approvers to be reachable out of band. Where that cannot be assumed, a deployment MAY pre-authorize a Delegation: a proof, signed in advance by the ordinary quorum, that transfers the authority to approve one pre-declared action to a named set of local operators.¶

A Delegation Payload is identical to the Intent Payload of §4.2 except that:¶

A Delegation authorizes no action. It is not an approval and MUST NOT be accepted as one: an implementation MUST reject a Delegation Payload presented to the approval verification procedure of §5, and MUST expose Delegation verification as a distinct operation. There is deliberately no opt-in flag that would permit the substitution, because a Delegation that could authorize its own action would be exactly the pre-signed bearer capability §5a.1 rejects.¶

The requirement in a Delegation Payload describes the quorum that signed the Delegation and MUST be at least as strict as the ordinary requirement for the delegated action. Delegating authority is never the cheaper path.¶

5a.6 Delegation Verification

A Relying Party using a Delegation MUST:¶

1. Verify the Delegation itself against the Trust Bundle's ordinary Approver set, enforcing its signed requirement — including the §5-step-3a signerClass registry check — and its expiry. expiresAt - sealedAt has a fixed ceiling of 72 hours: a deployment MAY enforce a shorter window and MUST NOT accept a longer one. A sealedAt later than the verification time plus the §6.2 clock-skew tolerance MUST be rejected, for the reason §5a.3 rule 3 gives — a ceiling on the window's width bounds nothing about where that window sits — and, as there, unconditionally. A Delegation with no human signature (sigAlg: AUTO_APPROVED) MUST be rejected regardless of any auto-approval opt-in. The ordinary Approver set and minimum sealing requirement are those of the action being executed, resolved from the Trust Bundle's policy, and the signed sealing requirement MUST be compared against that minimum under §5 step 3d. When the Offline Intent Proof is then verified under the Delegation, the same ordinary rule is the step-3d policy for it: delegatedQuorum is already at least as strict (§5a.5). A cached successful verification does not extend the Delegation's life: its expiry MUST be checked again at approval use time under §6.2. Trust Bundle freshness MUST also still hold after collecting incident signatures.¶

2. Require agreement on the action. The Delegation's target, actionType and params MUST equal those of the Offline Intent Proof being verified. A Delegation MUST NOT widen the action it was issued for.¶

3. Substitute, not widen. delegatedTo replaces the eligible Approver set and delegatedQuorum replaces requiredApprovals for that verification, and only for it. The Offline Intent Payload's signed requiredApprovals MUST equal delegatedQuorum, so the operators still sign the policy their signatures are counted toward.¶

4. Resolve delegate keys from the Trust Bundle, never from the Delegation or the Offline Intent Proof. A Delegation names identities; it does not carry key material.¶

5. Enforce every constraint of §5a.3 on the Offline Intent Proof unchanged.¶

A Delegation therefore narrows two things and widens none: who may approve, and for which single action.¶

5a.7 Reconciliation

An approval obtained offline is invisible to the approval service at the time it is granted. A deployment MUST record every offline approval locally and MUST report it to the approval service when connectivity returns, retaining the local record until the report is definitely acknowledged. An unreported approval is indistinguishable from an unauthorized action.¶

A reported offline approval SHOULD be re-verified by the receiving service against its own record of the action and its own Approver key material, rather than accepted on the reporter's assertion. The Approver signatures make the report independently checkable; a report that cannot be checked establishes little.¶

An offline approval MUST be surfaced to the caller under a status distinct from an ordinary approval. The prevailing caller guard is a test for the ordinary approved status, so a distinct status ensures that enabling offline approval in an existing service cannot silently begin permitting actions.¶

5a.8 Security Considerations

No capability at rest. The mechanism of §5a.2–§5a.4 leaves nothing on disk that authorizes an action. This is its principal advantage over pre-signing and the reason the remaining considerations are comparatively narrow.¶

Hardware-backed authenticators. A WebAuthn assertion cannot in general be produced offline: the ceremony requires a secure context and binds to a Relying Party identifier that an offline signing surface will not satisfy. Consequently requireHardwareKey cannot be honoured offline, and §5a.3 requires such a proof to be rejected rather than accepted under a weaker signature class. A deployment that must retain offline capability for hardware-pinned actions has to provision an attested offline authenticator, which is out of scope here. A non-empty allowedAaguids is the same class of requirement: it is uncheckable offline for the reasons given in §4.3.2, and §5a.3 rejects it exactly as it rejects requireHardwareKey — an allowlist that a key with no model could satisfy would not be an allowlist.¶

Out-of-band channel integrity. The payload travels to the Approver, and the signature back, across a channel this specification does not define. That channel need not be confidential — the payload carries no secret and the signature is verified cryptographically — but the Approver MUST be able to read the action they are authorizing in full, and SHOULD confirm the verification code (§4.4.4) against the operator's display. An Approver who signs an opaque blob has not approved anything.¶

Local single use. Nonce redemption is stateful and local (§5, steps 10–11). Because the Relying Party generates its own nonce, single use within that Relying Party is enforceable exactly as in the online case. Two Relying Parties cannot observe each other's redemptions, so a deployment sharing one Approver set across several Relying Parties MUST scope nonces per Relying Party (§6.1).¶

Delegation is a standing capability. Everything §5a.1 says about pre-signing applies to a Delegation, with one mitigation: it authorizes no action alone, so possessing the file is not sufficient to act. The residual risk is collusion between a Delegation holder and delegatedQuorum of the named operators. Deployments using Delegation SHOULD keep the window short, cap the number of live Delegations, and monitor the ratio of delegated to ordinary approvals.¶

Revocation. Neither mechanism can be revoked at a Relying Party that is offline. For Offline Approval the exposure is bounded by the window cap of §5a.3 and by the fact that a human decides at incident time. For Delegation the window cap of §5a.6 is the only mitigation, which is why it is short. Both caps bound the window's width and, through the forward-dating rule of §5a.3 rule 3, its position — without that second half a cap bounds nothing durable, since an artifact minted today for a window opening years from now would satisfy the width ceiling and still be a capability at rest for its whole wait.¶

Unforeseen incidents. Offline Approval imposes no pre-declaration: any action the Relying Party can describe can be approved offline, because the humans are in the loop when it happens. Delegation does fix the action and its parameters in advance and is therefore limited to anticipated incidents.¶

Relying Party compromise. Out of scope, as in §7. Note that a Relying Party constructs its own offline challenge, so a compromised one can choose the action it asks to have approved — but it cannot obtain a signature over an action the Approvers decline, and it could equally have declined to ask at all.¶

5b.1 Motivation

As agents take on delegated work, deployments need a governed, verifiable answer to "who authorized this agent to operate in this scope" — an answer that survives offline verification with no issuer secret, exactly as approvals do. An Agent Authority is that artifact: a statement of standing scope for one named agent, sealed by a human quorum through the same signing ceremony as an ordinary approval.¶

An Agent Authority is deliberately declarative: a target, a set of action patterns, a validity window. It defines no evaluation semantics beyond substring matching and carries no expression language. It is also not a Delegation (§5a.5): a Delegation pre-authorizes WHO MAY APPROVE at incident time — hence its one-action, no-wildcard, ≤72-hour constraints — while an Authority authorizes nothing at all. Execution always still requires an ordinary Intent Proof (§5). Loosening Delegation to carry scope would have weakened the break-glass invariants; the distinct type keeps both sets of constraints intact.¶

5b.2 Agent Authority Payload

The canonical payload has type div-agent-authority and serializes under the same JCS rules as §4.1:¶

There is no 72-hour window cap: that cap exists because a Delegation pre-authorizes offline approval and cannot be revoked at an offline Relying Party. An Authority is enforced — and revoked — online by the issuing deployment; its window is deployment policy. A verifier MUST still reject a payload whose expiresAt precedes its sealedAt, and one whose sealedAt is later than the verification time plus the §6.2 clock-skew tolerance — an Authority sealed in the future was not live at that time, and §5b.3's evidence claim is precisely about liveness then (§5a.3 rule 3).¶

The issuing deployment SHOULD floor the sealing quorum at the strictest approval rule covering any action the patterns reach, so that sealing standing scope over an action is never cheaper than approving that action once. This is a SHOULD on the issuing deployment, not a verifier check: the artifact does not carry the deployment's approval rules, so a verifier cannot re-derive the floor.¶

5b.3 Agent Authority Verification

A verifier MUST expose Agent Authority verification as a function separate from Intent Proof verification, and Intent Proof verification MUST reject a div-agent-authority payload outright. The result of verifying an Authority is governance evidence — "these named humans granted this agent this scope, and the grant was live at the evaluation time" — never an authorization to execute.¶

For a delegated subagent, the verifier MUST receive the complete root-to-leaf authority receipt chain and independently trusted approver keys for every link. Each child parentReceiptHash MUST equal the digest of its verified parent receipt; the root MUST carry null. Targets MUST match, the child's validity interval MUST fit inside the parent's, and every child substring pattern MUST contain at least one parent pattern (or the parent has "*"). This is a conservative, provable subset test: ambiguous patterns are refused. The leaf's agent DID MUST equal the executing agent DID, the action type MUST match a leaf pattern, and the action intent's agent.delegatedBy MUST equal the leaf receipt digest. A scope seal still never substitutes for an action approval. An offline verifier cannot learn later revocations; the gateway's online path rejects a child if any ancestor has been revoked or expired.¶

Verification proceeds as §5a.6 does for Delegations, with the §5-step-3a signerClass registry check and the §5-step-3d comparison against the Relying Party's own sealing policy (how many humans, with what separation of duties, must grant agent scope) applied to the sealing requirement. Without that comparison a seal proves only the quorum its sealers stated. Validate the payload type and version; validate actionPatterns, sealedAt, expiresAt; reconstruct the canonical bytes from the verifier's OWN target and agent.did (Local Payload Reconstruction — both come from the caller's policy, never from the artifact); verify each witness signature against a trust anchor resolved from local policy; count distinct approver identities against requirement.requiredApprovals; reject AUTO_APPROVED. Expiry is checked against the evaluation time; an expired Authority MAY be re-verified for audit with an explicit override (§6.2).¶

Revocation is authoritative online only. An offline verifier sees validity, not revocation state. Treat a sealed Authority like a certificate, not a bearer token: the issuing deployment records seals in its witness ledger (the sealing event commits the payload digest, the agent, and the scope), revokes them there, and answers for liveness.¶

Request-time enforcement (non-normative). The issuing deployment MAY use live seals as a request boundary. The reference gateway does, with a deliberately simple rule: sealing is the switch — an agent with no live seal is unbounded (every request escalates to a human, unchanged), and an agent with one or more live seals is confined to the union of its sealed scopes, with out-of-scope requests refused before a challenge exists and the refusal witnessed. Coverage is decided from the scope's target and the request's actionType alone — a bounded agent that omits actionType matches nothing but "*". A subagent's seal counts as scope only while every ancestor seal is live; one whose ancestry was revoked or expired still bounds the agent but covers nothing, so a parent's revocation never widens a child. An in-scope request is not thereby approved; it takes the ordinary §5 path. This keeps the Authority's normative claim intact — it authorizes nothing — while making "no agent acts outside human-granted scope" an enforceable, auditable property.¶

5c.1 Motivation

An integrating platform — a service with its own end customers and its own UI — needs the non-repudiation primitive without handing its payloads to the issuer. Its requests carry financial, personal, or payroll data; transmitting them in plaintext would make the issuer a data processor for the platform's entire customer base while adding no verification value, since the Relying Party (the platform itself, or its auditor) already holds the payload.¶

The Platform Hash-Only Intent inverts §4.2's display model: the platform canonicalizes its own payload (under the §4.1 rules), renders its approval UI from that one serialization, and submits only the payload's digest. The issuer binds a WebAuthn ceremony to the digest, verifies the assertion against the subject's enrolled credential and the platform's own registered Relying Party (rpId/origins), and witnesses the result. The signed bytes never contain the payload.¶

What shifts, stated plainly. In §4.2 the display string inside the signed bytes is the What-You-See-Is-What-You-Sign anchor, and the issuer's approval surface renders it. Here the platform's UI is the display authority: the issuer attests that this enrolled key signed this digest at this time on this RP, and cannot attest what the person was shown. A platform that renders one thing and hashes another defeats WYSIWYS for its own users — which is why an integration MUST derive displayed, signed and executed bytes from the single canonical serialization, and MUST NOT rebuild the payload between approval and execution. This is an integration requirement on the platform, verifiable by the platform's auditor against its own codebase, not a property the receipt can carry.¶

5c.2 Platform Intent Payload

The canonical payload has type div-platform-intent and serializes under the same JCS rules as §4.1:¶

The WebAuthn assertion challenge is the canonical payload's bytes in base64url, exactly as §4.4.5 defines for other payload kinds.¶

5c.3 Verification

A verifier MUST expose Platform Intent verification as a function separate from Intent Proof verification (verifyPlatformReceipt in the reference implementation), and Intent Proof verification MUST reject a div-platform-intent payload outright — the two attest different things, and neither may ever be mistaken for the other.¶

The Relying Party supplies, from its own state and never from the receipt: the payloadHash it recomputes from its own copy of the canonical payload, its rpId, the ceremony nonce it is redeeming, its WebAuthn origin expectation, and the subject's trusted keys (§4.4.6 trust-anchor modes; the self-certifying DID mode applies unchanged). Verification reconstructs the canonical bytes from those values plus the receipt's signedAt/expiresAt/subject, byte-compares against the signed payload, then verifies each WebAuthn witness under §4.4.5 with the PLATFORM's origin/rpId as the expected values. Every witness MUST be a WebAuthn assertion (sigAlg WEBAUTHN) with user verification asserted — unconditionally: a verifier option that waives the User-Verified flag for ordinary receipts (§4.4.5 rule 2) MUST NOT apply here; AUTO_APPROVED MUST be rejected with no override — this plane has no policy pre-approval. At least one distinct verified witness is REQUIRED. Expiry follows §6.2, fail closed.¶

Credential revocation is evaluated at signing time. The issuer refuses a revoked credential in every ceremony from the moment of revocation, and witnesses both the revocation (CREDENTIAL_REVOKED) and each refusal. Receipts signed before revocation remain valid; an offline verifier sees validity, not revocation state (the same bound as §5b.3's revocation note).¶

5c.4 Security Considerations

The origin binding is the trust boundary for a browser-mediated ceremony. A standards-compliant browser is what refuses to let a page assert an origin other than its own when it constructs clientDataJSON, so an assertion produced through a browser on one of the platform's registered origins is the only kind whose clientDataJSON.origin can be trusted, and §4.4.5 verification rejects anything else the browser could have produced. This binding is a property of the browser as client, not of the authenticator or of WebAuthn as a wire format: a native CTAP2 client that talks to a security key directly (bypassing a browser — e.g. a custom app built on libfido2 or an equivalent) constructs its own clientDataJSON and can put any origin string in it; the key itself does not know or enforce origin, so it signs whatever it is asked to. No offline verifier can distinguish that from a genuine browser assertion after the fact — the guarantee holds only for the class of client that cannot lie about where the interaction happened, and general-purpose end-user devices are not restricted to that class. Enrollment MUST therefore verify the attestation against the registered RP configuration, and registration of that configuration is a privileged, witnessed act; neither closes this residual.¶

Because credentials are scoped to the platform's RP ID, one person enrolled by two platforms holds two unrelated keypairs and two subject identities; nothing in this profile links them — deliberate data minimization, and the §1.2 non-goal (DIV is not an identity system) applies with extra force.¶

Implementation status. TypeScript, Go, Rust, Python and Java implement div-platform-intent through dedicated platform-receipt verifiers. Their ordinary approval verifiers continue to refuse this type: a platform signature is never an ordinary action approval. Shared verifier parity fixtures pin successful verification and digest/RP/origin/subject/nonce refusals.¶

6.1 Nonce Requirements

The nonce MUST be unique within the replay-protection scope of the Relying Party.¶

The Relying Party SHOULD generate the nonce whenever approval requests originate from untrusted requesters.¶

A redeemed nonce MUST remain unavailable for reuse until the associated proof expiration time has elapsed. Recording and enforcing redemption is a stateful Relying Party responsibility (see the note on §5 steps 10–11) and is distinct from the stateless cryptographic verification of the Proof Envelope.¶

6.2 Expiration Validation

The Relying Party MUST reject proofs where the current time exceeds expiresAt.¶

Timestamp syntax. Every signed timestamp (expiresAt, challengedAt, sealedAt, signedAt) MUST be an RFC 3339 §5.6 date-time, and a verifier MUST refuse any other spelling rather than guess at it: exactly YYYY-MM-DDTHH:MM:SS, an optional fraction of one to nine digits introduced by ., and a zone of Z or ±HH:MM; T and Z uppercase; the date MUST exist (30 February and a non-leap 29 February are refused); hours 00–23, minutes and seconds 00–59 (no leap second); offset hours 00–23 and offset minutes 00–59. A numeric offset denotes the same instant as its UTC equivalent. A bare date, a zone-less time — which a lenient parser reads in the verifier host's own time zone, so the verdict moved with the machine — a space or lowercase separator, a comma fraction and an expanded year are all refused. The reference producer emits YYYY-MM-DDTHH:MM:SS.sssZ, which every conformant verifier accepts.¶

Implementations SHOULD support configurable clock-skew tolerance.¶

A default tolerance of ±30 seconds is RECOMMENDED.¶

A verifier MAY support re-verifying an expired proof for post-hoc audit or forensics, behind an explicit per-call override (allowExpired in the reference implementation, available on intent, delegation, and agent-authority verification alike). The result of such a re-verification is evidence for the record — "this was validly signed while it was live" — never authorization to execute: Invariant 4's fail-closed rule binds execution regardless of the override.¶