FPSF-CPP-002 — CashPack Offline Signer Extension

Extension Layer — NORMATIVE This document extends FPSF-CPP-001 (CashPack Protocol, CPP-1.0). It does not redefine or override any CPP-1.0 data structure, obligation, or Operator interface except where explicitly stated. Where this document is silent, CPP-1.0 governs.

Document Metadata

Field	Value
Document ID	FPSF-CPP-002
Title	CashPack Offline Signer Extension
Version	0.2.0
Status	Draft
Date	2026-08-13
Supersedes	FPSF-CPP-002 v0.1.0
Author(s)	Adalton Reis — [email protected]
Reviewers	—
Organization	Fabric Payment Standards Foundation
Specification Family	CashPack Protocol (CPP)
Conforms To	FPSF-CPP-001 v1.0.0, FPSF-CPD-001
Canonical URL	`https://fabricpaymentstandards.org/specs/cashpack/cpp-002`
Contact	[email protected]
Licence	Apache License 2.0

Summary of Changes from v0.1.0

v0.1.0 modeled every offline hop as a live, symmetric exchange between two peer Certified Devices, each holding an SE, each attesting to the other, each participating in a destructive handoff. Field experience with the intended hardware profile showed this was the wrong shape for the dominant use case (a disconnected, un-powered card authorizing a single outbound transfer) and imposed hardware requirements — sustained local radio, a paired counterparty SE — that the receiving party frequently cannot or need not satisfy.

v0.2.0 replaces the single device model with two Device Classes:

Class N (Signer Card) — battery-less, field-powered (e.g. NFC), no display, no independent connectivity. Authorizes outbound transfers only ("sender-only"). Receives value the same way a hardware wallet receives value: by having previously generated and published a public key, with no live session required.
Class S (Signer Node) — battery-powered, integrated display and input, WiFi and optional cellular connectivity. Self-capable: does not require a companion phone. May act as sender or receiver in a live, mutually-attested Peer Handoff, and reconciles independently over its own network connection.

Both classes share a Key Slot model: the device stores only pre-generated key material and per-slot anti-replay counters, never the CashPack instrument itself. A new Configuration Mode (Section 9) lets the bearer provision empty slots with freshly generated keys, producing receiving public keys ahead of need. A new mandatory Authorization layer (Section 8) requires a PIN or password before any signing operation, addressing unauthorized-use risk that v0.1.0 left largely to the Companion Application's discretion.

1. Scope

CPP-1.0 assumes every renewal and redemption is countersigned by the Operator in real time. This assumption fails when the current bearer has no network access — a common condition for a purpose-built payment card or wearable operating in areas of poor connectivity, or simply while a phone is in airplane mode.

This document specifies CPP-002, an extension that allows a CashPack instrument to be renewed one or more times without contacting the Operator, by having the current bearer authorize the transfer on a Certified Device rather than through an Operator-mediated session. It defines:

Two certified Device Classes with different power, display, and connectivity profiles, and the offline mechanism each supports.
The hardware trust requirements a device MUST satisfy to participate in either class ("Certified Device").
A Key Slot model in which the device persists only key material and control counters, never instrument data.
A mandatory Configuration Mode for provisioning key slots and a mandatory PIN/password Authorization layer gating every signing operation.
The device certification and attestation chain rooted in the Foundation.
The offline transfer protocols for each class and the data structures they produce.
The mandatory reconciliation procedure by which offline transfers are surfaced to, and validated by, the Operator once connectivity is available.

Out of scope: industrial design beyond what Section 6 requires, specific form factor beyond the ID-1 card reference profile, the Companion Application's visual design, any payment rail other than CPP-1.0 CashPack instruments, hierarchical/deterministic key derivation schemes (Section 20), and cellular carrier or eSIM provisioning specifics. This document does not define a new settlement model, a new instrument type, or any consensus mechanism between devices.

2. Relationship to CPP-1.0 and CPD-001

CPP-002 is additive. A CashPack instrument transferred through any combination of Operator-countersigned renewals, Class N tap-sign authorizations, and Class S peer handoffs remains a single CPP-1.0 instrument with a single pack_id, a single Operator, and a single renewal_chain. Offline hops are appended to that chain as distinct entry types (Section 10) once reconciled.

CPP-002 introduces no new concept of Payment or Value beyond what FPSF-CPD-001 already defines. Every offline hop is a Renewal in the CPD-001 sense: it changes current_bearer_pk without changing value, amount, or currency.

A material clarification versus v0.1.0: CPD-001 has never required the incoming party of a renewal to be present, online, or device-equipped at the moment of transfer — the incoming party is fully specified by supplying a public key. v0.1.0's requirement that a receiving Certified Device attest live was a self-imposed constraint of that draft's symmetric handoff design, not a CPD-001 requirement. This revision removes that constraint: receiving a CashPack instrument, whether online or offline, never requires a device to be present. A device is required only to authorize an outbound transfer as the current bearer.

CPP-002 does not introduce a device-to-device consensus mechanism, a distributed ledger among devices, or any settlement authority independent of the Operator. The Operator remains the sole source of truth. Certified Devices are a hardware-enforced custody control, not a second trust root.

3. Terminology

Term	Definition
CPP-Signer	A physical device certified under this extension, of either Device Class.
Device Class N ("Card")	A battery-less, field-powered CPP-Signer with no display or input surface of its own. See Section 6.2.
Device Class S ("Node")	A battery-powered, self-capable CPP-Signer with integrated display, input, and network connectivity. See Section 6.3.
Host	An external system that supplies power, a data channel, network relay, and/or display surface to a Class N device — typically a Companion Application on a smartphone, or a dedicated reader terminal. Class S devices do not require a Host.
Secure Element (SE)	A tamper-resistant hardware component within a CPP-Signer responsible for key generation, key storage, signing, and enforcement of the invariants in Section 4. Private key material MUST NOT leave the SE in any form.
Key Slot	A single unit of on-device key storage: a keypair generated inside the SE, a slot state, and a monotonic per-slot sequence counter. See Section 7.
Configuration Mode	An authorized device session in which empty Key Slots are provisioned with freshly generated keypairs. See Section 9.
Signer PIN	The numeric PIN or password required to authorize signing operations and Configuration Mode. See Section 8.
Device Root Key	An asymmetric key pair generated inside the SE at first boot (or at manufacture, under Foundation-audited conditions) and never exported. Its public key, once certified, is the device's permanent identity.
Device Certificate	A certificate binding a Device Root Key's public key to a device identity, issued by an accredited Device Vendor CA, itself certified by the Foundation Device Root CA.
Device Attestation	A signed statement, using a manufacture-time Attestation Key distinct from the Device Root Key, covering boot integrity, application software identity, device class, and current Device Certificate.
Companion Application	A smartphone or desktop application that renders UI and relays data for a Class N device. It holds no signing authority and cannot construct or alter offline transfer data. Never referred to as a "wallet" in Foundation materials.
Offline Transfer Entry (OTE)	A signed record of a custody change authorized unilaterally by the outgoing bearer's device, with no device required or attested on the incoming side. Used by both classes when the recipient is not present as a live peer. See Section 10.3.
Peer Handoff Entry (PHE)	A signed record of a custody change mutually attested and committed by two live Class S devices in a single session. See Section 10.4.
Custody Chain	The ordered sequence of OTE and/or PHE objects produced since the instrument last had an Operator-countersigned state.
Reconciliation	The mandatory process, performed when a device or its Host regains network access, by which a Custody Chain is submitted to the Operator for validation and folded into the instrument's authoritative `renewal_chain`.
Slot Retirement	The permanent, irreversible destruction of a Key Slot's signing capability immediately after it authorizes an outbound transfer.
Quarantine State	A state assigned by the Operator to an instrument whose Custody Chain cannot be fully validated, pending manual or policy-driven resolution.
Device Revocation List (DRL)	A Foundation- and Vendor-signed list of Device Certificates that MUST no longer be trusted.

4. Trust Model

The Operator remains the single source of truth. An offline hop is provisional until reconciled; it confers no finality on its own.
A CPP-Signer is a hardware-enforced custody control, trusted only to the extent that its attestation chain is valid and unrevoked. No device is a settlement authority and none can itself mark an instrument redeemed, cancelled, or expired.
No device is ever required on the receiving side of a transfer. A recipient is fully specified by a public key, however it was generated. A CPP-Signer's role in the protocol is exclusively to authorize outbound transfers of value it currently holds; a device MAY separately hold value it received, but never because a live device-side step was required to receive it.
Two-factor custody. Possession of the device alone is not sufficient to authorize a signature. Every signing operation additionally requires the Signer PIN (Section 8) — "something you have" plus "something you know." This is the primary control against unauthorized use of a lost or stolen device.
There is no device-to-device consensus. Class S peer sessions do not vote, do not require a quorum, and reference no ledger other than the instrument itself and each device's own attested local state.
Bearer privacy is preserved for offline hops in the same manner as CPP-1.0: intermediate device identities are not disclosed to the Operator beyond what is structurally necessary to validate the Custody Chain at reconciliation (Section 14).
Manufacturer trust is delegated, not absolute. A Device Vendor's ability to issue Device Certificates is itself certified, audited, and revocable by the Foundation (Section 16).
Trust boundaries differ by class, and this difference is intentional rather than a defect: Class S devices can display transfer details on hardware they alone control before the bearer authorizes them, closing the confirmation loop entirely on-device. Class N devices have no display and depend on a Host to present transfer details faithfully before relaying a PIN-authorized sign request; the Signer PIN prevents an untrusted Host from forging a signature outright, but it does not prevent a malicious Host from misrepresenting what it is asking the bearer to authorize. This limitation is named explicitly in Section 19 rather than assumed away.

5. Device Classes

Property	Class N — Signer Card	Class S — Signer Node
Power	Field-harvested (e.g. NFC); no battery	Integrated rechargeable battery
Display	None	Integrated
Input	None (PIN relayed via Host)	Integrated (keypad or touchscreen)
Connectivity	None; depends on a Host for any data relay	WiFi (mandatory); cellular 3G/4G/5G (optional)
Local peer transport	Contactless field only (e.g. ISO/IEC 14443 NFC)	BLE and/or other short-range transport for Peer Handoff
Role in offline transfer	Sender only, via Tap-Sign (Section 11)	Sender or receiver, via Peer Handoff (Section 12); MAY also perform Tap-Sign as a sender
Requires companion phone	Yes, for network relay, display, and PIN entry	No — self-capable
Receives value	Yes, asynchronously, via a previously published slot public key (Section 7); never via a live session	Yes, either asynchronously (as Class N) or live via Peer Handoff
Reference form factor	ID-1 plastic card (ISO/IEC 7810)	Standalone wearable, fob, or handheld terminal
Typical trust anchor	EAL5+/6+ secure microcontroller	EAL5+/6+ secure element plus application processor

A single Custody Chain MAY mix OTE and PHE entries in any order and MAY mix devices of both classes across its hops (Section 13).

6. Hardware Requirements

6.1 Common Requirements (both classes)

Secure Boot. The device MUST implement a Verified Boot Chain rooted in an immutable, factory-programmed public key or key hash. Every stage MUST cryptographically verify the next before executing it. On failure at any stage, the device MUST halt or enter a non-functional recovery mode and MUST NOT unseal SE key material. Boot chain measurements MUST be available to remote attestation.
Secure Element. The device MUST contain an SE (discrete chip, or an equivalently certified isolated execution environment) meeting a Foundation-recognised hardware security standard (e.g. Common Criteria EAL5+ or equivalent; the Foundation publishes an accepted-standards list separately). The Device Root Key MUST be generated on-device inside the SE using an on-die TRNG and MUST NOT be exportable. All Key Slot keypairs (Section 7) MUST likewise be generated inside the SE and MUST NOT be exportable in cleartext under any API, debug interface, or manufacturer backdoor. The SE MUST enforce that only Verified-Boot-attested application software can request signing operations.
Tamper Resistance. The SE MUST implement physical tamper detection (voltage/clock glitch detection, die shield, or equivalent) and MUST zeroise key material on detected tamper events. The device MUST NOT expose a debug or JTAG interface capable of reading SE memory in production units; any such interface MUST be permanently fused off before the device leaves manufacture-time provisioning.
Remote Attestation. The device MUST be able to produce a signed Device Attestation, using a manufacture-time Attestation Key distinct from the Device Root Key, covering boot chain measurements, application software hash, Device Class, and current Device Certificate.
Atomic State Transitions. Every operation that changes Key Slot state (provisioning, retirement) MUST be implemented so that an interruption (power loss, field drop, communication failure) leaves the slot in a well-defined pre- or post-operation state, never an intermediate one. (Informative: platforms offering a hardware or runtime transaction facility — e.g. the transaction commit/rollback primitives common to GlobalPlatform-compliant Java Card implementations — satisfy this by construction.)
Signing algorithm. Ed25519 per CPP-1.0 §3 is the default. Where the SE's certified cryptographic library does not implement Ed25519, the device MAY use ECDSA P-256 under the HSM-constraint allowance already present in CPP-1.0 §3. A device MUST declare its supported signing algorithm(s) in its Device Attestation, and an Operator MUST reject reconciliation of entries signed with an algorithm it does not accept per its Policy Document.

6.2 Class N Additional Requirements

The device MUST derive all operating power from an external field (e.g. an NFC/ISO 14443 reader field) for the duration of any operation and MUST NOT require a battery.
The device MUST support at least ISO/IEC 14443 (Type A or B) as its contactless interface, or an equivalent field-powered contact/contactless standard.
The device MUST support a secure channel to its Host (e.g. a GlobalPlatform SCP-equivalent protocol) sufficient to protect PIN transport and command/response integrity over the field-powered link, per Section 8.4.
The device MUST NOT require, and SHOULD NOT include, a display or physical keypad. Where a manufacturer chooses to add either, the added surface MUST NOT become a required element of the protocol described herein.
(Informative, non-normative: a reference implementation of this profile has been prototyped in ID-1 card form using an EAL5+/6+ secure microcontroller of the class used in existing EMV and eID cards, running a GlobalPlatform-compliant Java Card runtime. This is an example, not a requirement — any SE meeting Section 6.1 qualifies.)

6.3 Class S Additional Requirements

The device MUST include a rechargeable or replaceable battery sufficient for independent operation between charges, per the manufacturer's declared duty cycle.
The device MUST include an integrated display capable of rendering, at minimum, a transfer's amount, currency, and counterparty identifier in human-readable form.
The device MUST include an integrated input surface (physical keypad, touchscreen, or equivalent) sufficient for direct, on-device PIN entry with no relay through any external Host.
The device MUST support WiFi for Reconciliation (Section 14) and MAY additionally support cellular data connectivity (3G/4G/5G) for Reconciliation when WiFi is unavailable.
The device MUST support a local peer transport (e.g. Bluetooth Low Energy) for Peer Handoff sessions (Section 12), independent of any WiFi/cellular connection.
The device MUST be able to complete a full Peer Handoff and, separately, a full Reconciliation without any companion smartphone, application, or other intermediary.

7. Key Slot Model

A CPP-Signer of either class holds a fixed-capacity array of Key Slots, sized at manufacture according to available secure non-volatile memory. The device MUST NOT persist a CashPack instrument, a lock_request, a renewal_chain, or any other instrument-level object. The device's only persistent state is:

Per slot: a keypair (private key non-exportable, public key retrievable), a slot state, and a monotonic sequence counter (outgoing_seq) used for anti-replay.
Device-global: the Device Root Key, Device Certificate, Attestation Key, and the Signer PIN verification object (Section 8).

This is a deliberate minimization: the device has no notion of balance, amount, currency, or instrument status. It is a PIN-gated signing oracle addressed by slot index. All value and instrument-state awareness lives with the Operator and is retrieved by the Host or bearer via the CPP-1.0 GET /v1/cashpack/{pack_id}/status endpoint — never from the device itself.

7.1 Slot States

State	Meaning	Entered via
`EMPTY`	No keypair present. Initial state of every slot at manufacture.	Manufacture; never re-entered.
`PROVISIONED`	A keypair has been generated. The slot's public key MAY be published as a receiving reference and, once value is bound to it by the Operator or a sender, MAY be used to authorize an outbound transfer.	Configuration Mode (Section 9).
`RETIRED`	The slot's signing capability has been permanently destroyed after authorizing exactly one outbound transfer.	Slot Retirement (Section 11.4, 12.4).

RETIRED is terminal. A device MUST NOT reset a RETIRED slot to PROVISIONED or reuse its key material under any circumstance. This is what gives the offline mechanism its double-spend defense: a slot can authorize an outbound transfer at most once, ever, for the lifetime of the device (Section 19).

7.2 Slot Public Key Reference

To publish a receiving address (i.e. offer a PROVISIONED slot's public key as the initial_bearer_pk of a Lock Request, or as the incoming_bearer_pk of any renewal), a device exports:

SlotPublicKeyReference {
    device_id: UUIDv4
    slot_index: integer
    slot_pubkey: Base64url
    device_attestation: DeviceAttestation
    export_signature: Base64url        // SE signature over device_id, slot_index, slot_pubkey
}

export_signature is OPTIONAL to require by an Operator or counterparty — a bare public key is sufficient to receive value, exactly as in CPP-1.0. Where present, it lets a recipient of the reference verify the address was genuinely generated inside a certified device, which MAY be useful for higher-assurance flows (e.g. an Operator crediting a fixed-value instrument directly to a card at point of sale).

7.3 Device-Local Status and Error Codes

In addition to the CPP-1.0 §6 error codes, a CPP-Signer or its Host MUST recognise:

Code	Meaning
`SLOT_CAPACITY_EXCEEDED`	Requested Configuration Mode provisioning exceeds the device's remaining `EMPTY` slots.
`SLOT_NOT_PROVISIONED`	A sign request referenced a slot that is `EMPTY` or `RETIRED`.
`SLOT_ALREADY_RETIRED`	A sign or retirement request referenced an already-`RETIRED` slot (replay attempt).
`PIN_INVALID`	Submitted PIN failed verification; retry counter decremented.
`PIN_LOCKED`	Retry counter exhausted; device refuses further Signer PIN attempts until reset (Section 8.5).
`SESSION_ALREADY_OPEN`	A second concurrent signing or Configuration session was attempted while one is in progress.

8. Authorization: PIN and Anti-Theft Controls

8.1 Requirement

Every CPP-Signer, of either class, MUST require a Signer PIN (numeric PIN or alphanumeric password; Foundation-recommended minimum 6 digits for numeric PINs) before performing any of the following:

Producing a signature (an OTE or PHE outgoing_bearer_signature, or the retirement_proof/handoff_commit_proof that accompanies it).
Entering Configuration Mode (Section 9) to provision new slots.
Changing the Signer PIN itself.

Exporting a SlotPublicKeyReference (Section 7.2) for an already-PROVISIONED slot MAY be permitted without PIN entry, since it discloses no signing capability, but a device MAY require PIN entry for this operation as well at manufacturer or bearer discretion.

8.2 On-Device Enforcement

PIN verification MUST be performed inside the SE against a stored verification object that enforces a bounded retry counter (Foundation-recommended default: 5 consecutive failures). (Informative: this matches the standard behavior of an on-card PIN object such as those exposed by GlobalPlatform-compliant Java Card runtimes, which natively track try-counters and lock state.) The plaintext PIN MUST NOT be persisted anywhere outside the verification object, and MUST NOT be recoverable by any device command.

8.3 Trusted Entry Path — Class S

On a Class S device, the Signer PIN MUST be entered directly on the device's own integrated input surface. It MUST NOT be relayed from, or accessible to, any external Host, companion application, or peer device. This gives Class S a full trusted path: the same device that displays the transfer detail (Section 17) also captures the authorizing PIN, with no third party in the loop.

8.4 Relayed Entry Path — Class N

A Class N device has no input surface of its own. The Signer PIN MUST be relayed from a Host over the secure channel required by Section 6.2. This is a strictly weaker guarantee than Section 8.3, and the specification treats it as such rather than assuming it away:

The secure channel MUST protect the PIN in transit against a passive eavesdropper on the contactless link.
It does not protect the PIN against a compromised or malicious Host itself, which by construction sees the PIN as entered. A malicious terminal that captures a bearer's PIN, combined with later theft or loss of the device, is sufficient to authorize signatures until the retry counter (Section 8.2) or a DRL-based revocation intervenes.
The Foundation RECOMMENDS bearers enter the Signer PIN only through a Foundation-recognised, bearer-owned Companion Application, and treats PIN entry on an arbitrary third-party terminal as an elevated-risk action to be surfaced as such in the Companion Application's UI.
This risk is named explicitly in Section 19 and is a primary reason a bearer may prefer Class S for higher-value use.

8.5 Lockout and Reset

On exhaustion of the retry counter, the device MUST enter a PIN_LOCKED state and MUST refuse all operations gated by Section 8.1 until reset. Reset mechanics (e.g. a Foundation- or Vendor-defined recovery ceremony, or an irreversible factory-reset that destroys all PROVISIONED slot keys) are Vendor-specific and deferred to Section 21; a device MUST NOT implement a silent, unlimited-retry bypass under any operating mode.

8.6 Bounded Auto-Sign Policy (Optional)

A device MAY support a bearer-configured, bounded auto-sign policy (e.g. "authorize transfers up to a fixed ceiling amount without a fresh PIN entry") for OTEs it produces. Such a policy MUST itself be established only during a PIN-verified session, MUST be countersigned by the device's own key as evidence of its terms, and MUST be revocable at any time the bearer can reach the device (directly, for Class S; via a Host, for Class N). Where an OTE is signed under such a policy rather than a fresh PIN entry, its authorization_method field (Section 10.3) MUST reflect that.

9. Configuration Mode: Key Slot Provisioning

9.1 Purpose

Configuration Mode is the process by which a bearer populates EMPTY slots with freshly generated keypairs, producing public keys that can be handed out ahead of need as receiving references — the same workflow, conceptually, as generating a receive address on a hardware wallet, except each address here is an independently generated key rather than one derived from a common seed (Section 20).

9.2 Preconditions

The device MUST NOT be in PIN_LOCKED state.
The Signer PIN MUST be freshly verified for the session (Section 8.1(2)).
For Class N, an active Host session over the required secure channel MUST be established (Section 6.2).
A device MUST reject a Configuration Mode request with SLOT_CAPACITY_EXCEEDED if it would provision more slots than remain EMPTY.

9.3 First-Use Initialization

Before any slot may be provisioned, the device MUST have a Signer PIN set. A factory-fresh device MUST ship with no usable Signer PIN (i.e. incapable of authorizing any signature) and MUST require the bearer to set an initial PIN, over the same trusted or relayed entry path defined in Section 8.3/8.4, as the first step of its first Configuration Mode session.

9.4 Provisioning Procedure

For each EMPTY slot selected for provisioning (individually or as a batch, e.g. "provision the next 20 empty slots"), the SE MUST, as an atomic sequence per Section 6.1:

Invoke the on-die TRNG.
Generate a keypair using the signing algorithm declared in the device's Attestation (Section 6.1).
Initialize the slot's sequence counter (outgoing_seq) to zero.
Transition the slot state EMPTY → PROVISIONED.
Make the slot's public key retrievable via the Slot Public Key Reference export (Section 7.2).

A device MUST support querying, at minimum, the count of slots in each state (EMPTY, PROVISIONED, RETIRED) so a Host or bearer can plan provisioning without exceeding capacity.

9.5 Batch Export

A device MUST support exporting Slot Public Key References for all PROVISIONED slots in a single request, so a Host can publish or display them (e.g. as QR codes, or by submitting one directly to an Operator as a Lock Request's initial_bearer_pk) without a separate device round-trip per key.

9.6 Performance Note

(Informative) Key generation on a constrained SE is not instantaneous. Implementations SHOULD chunk large batch-provisioning requests, and MAY perform provisioning opportunistically during idle time (e.g. while a Class S device is charging, or across successive taps for a Class N device) rather than requiring a single uninterrupted session.

10. Data Structures

10.1 Device Attestation

DeviceAttestation {
    version: "CPP-2.0"
    device_id: UUIDv4
    device_class: "N" | "S"
    device_pubkey: Base64url               // Device Root Key public key
    vendor_id: string
    signing_algorithm: "Ed25519" | "ECDSA-P256"
    boot_measurements: Base64url
    app_software_hash: hex
    issued_at: RFC3339
    vendor_signature: Base64url            // Device Vendor CA signature
}

10.2 Offline Transfer Entry (OTE)

Used whenever the outgoing device authorizes a transfer unilaterally — i.e. the recipient is specified only by a public key, with no live device attesting on the incoming side. This is the sole mechanism available to Class N, and is also available to Class S when the recipient is not present as a live peer.

OfflineTransferEntry {
    ote_id: UUIDv4
    timestamp: RFC3339                         // device or Host local clock, best-effort
    outgoing_device_id: UUIDv4
    outgoing_slot_index: integer
    outgoing_bearer_pk: Base64url               // MUST match instrument current_bearer_pk
    incoming_bearer_pk: Base64url               // supplied by Host/sender; no device required
    prev_chain_digest: hex                      // as in CPP-1.0 chain_digest; supplied by Host
    outgoing_seq: integer                       // this slot's monotonic counter
    authorization_method: "PIN" | "AUTO_SIGN_POLICY"
    outgoing_bearer_signature: Base64url        // signs all fields above
    outgoing_attestation: DeviceAttestation
    retirement_proof: Base64url                 // see Section 11.4
}

Note the absence of any incoming_* device or attestation field: this is the structural change from v0.1.0 that reflects the receiving side never requiring a device.

10.3 Peer Handoff Entry (PHE)

Used only for a live, mutually-attested session between two Class S devices (Section 12). Structurally the symmetric counterpart to the OTE, retaining both sides' attestation.

PeerHandoffEntry {
    phe_id: UUIDv4
    timestamp: RFC3339
    outgoing_device_id: UUIDv4
    outgoing_slot_index: integer
    outgoing_bearer_pk: Base64url
    incoming_device_id: UUIDv4
    incoming_slot_index: integer
    incoming_bearer_pk: Base64url
    prev_chain_digest: hex
    outgoing_seq: integer
    authorization_method: "PIN" | "AUTO_SIGN_POLICY"
    outgoing_bearer_signature: Base64url         // signs all fields above except handoff_commit_proof
    outgoing_attestation: DeviceAttestation
    incoming_attestation: DeviceAttestation
    handoff_commit_proof: Base64url              // see Section 12.4
}

10.4 Custody Chain

An ordered array of OfflineTransferEntry and/or PeerHandoffEntry objects, carried alongside the instrument's CPP-1.0 fields for the duration of its offline life and cleared upon successful Reconciliation (Section 14), at which point each entry is translated into a standard RenewalEntry per CPP-1.0 §3.3.

11. Class N Protocol: Tap-Sign Offline Transfer

11.1 Session Establishment

The Host detects the device entering its field and establishes a session (e.g. ISO/IEC 14443 activation followed by application selection). Host and device negotiate and establish the secure channel required by Section 6.2, over which all subsequent commands, including the PIN (Section 8.4), travel.

11.2 Authorization

The Host relays the Signer PIN. The device verifies it per Section 8.2 and either proceeds or returns PIN_INVALID/PIN_LOCKED.

11.3 Sign Request

The Host, having independently obtained the instrument's current chain_digest and current_bearer_pk (e.g. from the last known instrument state or a prior status query — never from the device, per Section 7), sends a sign request identifying:

The outgoing_slot_index whose public key matches the instrument's current_bearer_pk.
The incoming_bearer_pk (obtained from the recipient by any means — a displayed address, a scanned reference, an Operator-relayed value).
prev_chain_digest.

The device MUST reject the request with SLOT_NOT_PROVISIONED or SLOT_ALREADY_RETIRED if the referenced slot is not in state PROVISIONED, and MUST reject it if the slot's public key does not match the instrument's declared current_bearer_pk supplied by the Host.

The device signs the OTE fields, producing outgoing_bearer_signature.

11.4 Slot Retirement

As a single atomic operation per Section 6.1, the SE MUST:

Persist the signed OTE to the device's local retry buffer (Section 11.5).
Irreversibly destroy the slot's signing capability, transitioning it PROVISIONED → RETIRED.
Emit retirement_proof — an SE-signed statement that steps 1–2 completed, bound to the session.

The device transmits the completed OTE, including retirement_proof, to the Host. Because the device signs only the fields presented to it and has no display of its own, retirement_proof attests that retirement happened correctly; it does not and cannot attest that the bearer was shown accurate transfer details — that guarantee, for Class N, rests with the Host (Section 17).

11.5 Interrupted Session

If field power is lost after Section 11.4 completes on the device but before the Host receives the OTE, the device retains the signed OTE (record only — not signing capability, which is already destroyed) for retransmission on the next session with that Host. This is a deliberate fail-closed design: an interrupted tap leaves the instrument temporarily unusable by the old key (already retired) until the Host successfully retrieves the already-committed OTE, never usable twice.

11.6 Reconciliation Path

A Class N device never contacts the network itself. Its Host is responsible for Reconciliation (Section 14) whenever it has connectivity.

12. Class S Protocol: Peer Handoff Offline Transfer

Available only between two Class S devices, when both bearers are present and their devices can establish a local peer transport session (Section 6.3). For any other recipient, a Class S device acting as sender uses Tap-Sign/OTE exactly as Class N does (Section 11), substituting its own integrated display and input for a Host.

12.1 Discovery and Pairing

The two devices discover each other over the local peer transport and establish a session.

12.2 Attestation Exchange

Both devices exchange DeviceAttestation objects and verify each other's Device Certificate against a locally cached DRL snapshot (Section 15.4). Either device MAY abort here with no state change on either side.

Both devices display the proposed transfer (amount, currency, counterparty identifier as known to the Operator or as declared by the peer) on their own integrated screens. The outgoing bearer authorizes with a fresh PIN entry (or an applicable Section 8.6 policy) on the outgoing device's own input surface. The incoming bearer is not required to authorize anything to receive, but SHOULD be shown a confirmation for awareness.

12.4 Proposal and Commit

Proposal. The incoming device (B) selects a PROVISIONED slot, sends its public key and a session nonce to the outgoing device (A).
A constructs the PeerHandoffEntry (minus handoff_commit_proof) and computes outgoing_bearer_signature.
Commit. A's SE performs, as a single atomic operation with no externally observable intermediate state: a. Persist the signed PHE to A's local Custody Chain log. b. Irreversibly transition A's slot PROVISIONED → RETIRED. c. Emit handoff_commit_proof, bound to the session nonce. A transmits the completed PHE to B.
Acknowledgement. B verifies the entry and handoff_commit_proof, and — only after successful verification — marks its own slot as holding custody of the instrument and appends the entry to its local Custody Chain. B sends a signed acknowledgement to A.

12.5 Interrupted Handoff

If the session drops after step 3 but before step 4 completes, the instrument is temporarily unspendable by any device until B successfully replays the already-committed PHE from A's retained log. A retains the record (not the signing capability, already destroyed) for retransmission. As in v0.1.0, this is a deliberate fail-closed design: an interrupted handoff MUST leave the instrument frozen, never spendable twice.

12.6 Direct Reconciliation

A Class S device, being self-capable, performs Reconciliation (Section 14) itself over its own WiFi or cellular connection, with no companion phone involved.

13. Chain Depth, Expiry, and Mixed-Class Custody Chains

A Custody Chain MUST NOT exceed a Foundation-recommended maximum depth of 5 consecutive unreconciled offline hops (any mixture of OTE and PHE entries) before Reconciliation becomes mandatory before any further transfer, online or offline. Operators MAY set a stricter limit in their Policy Document (Section 18).
An instrument accumulating any offline hops MUST carry an effective expiry no later than the lesser of its original CPP-1.0 expiry and a Foundation-recommended 72-hour offline ceiling from the first unreconciled entry.
A Custody Chain MAY freely mix entry types and device classes across its hops — e.g. an Operator issuance directly to a Class N slot's published address, followed by a Tap-Sign OTE from that card to a Class S node's address, followed by a live Peer Handoff between two Class S nodes. Each hop is validated independently at Reconciliation per its own type (Section 14.3).

14. Reconciliation

14.1 Trigger

A device or its Host MUST initiate Reconciliation for any instrument carrying a non-empty Custody Chain as soon as it regains network access. Neither a Class N Host nor a Class S device MUST permit that instrument to be used in a further online renewal or a redemption request before Reconciliation succeeds.

14.2 Submission

The current bearer's Host (Class N) or the device itself (Class S) submits, to the Operator's /v1/cashpack/renew endpoint (invoked once per Custody Chain entry) or a dedicated /v1/cashpack/reconcile endpoint (RECOMMENDED, for atomic multi-entry submission), the full ordered Custody Chain alongside the last Operator-countersigned instrument state.

14.3 Operator Validation

For each entry in order, the Operator MUST:

Verify outgoing_bearer_signature against outgoing_bearer_pk, and verify outgoing_bearer_pk matches the instrument's current_bearer_pk (or the incoming key of the immediately preceding entry).
Verify prev_chain_digest continuity, exactly as CPP-1.0 §5.2 obligation 5.
Verify outgoing_attestation chains to a valid Foundation Device Root CA via its Device Vendor CA, and that the outgoing device does not appear on the DRL as of the entry's timestamp. For a PeerHandoffEntry, additionally verify incoming_attestation under the same rule.
Verify retirement_proof (OTE) or handoff_commit_proof (PHE) against the outgoing device's attestation key.
Verify offline chain depth and elapsed time do not exceed the limits in Section 13.

On success for the full chain, the Operator MUST translate each entry into a standard CPP-1.0 RenewalEntry, append them to renewal_chain in order, add its own operator_renewal_signature per entry, and recompute chain_digest accordingly. The instrument's Custody Chain is then cleared.

On failure of any single entry, the Operator MUST NOT reconcile entries after the point of failure and MUST set the instrument to Quarantine State (Section 14.4).

14.4 Quarantine State

An instrument in Quarantine State MUST NOT be redeemed or further renewed until resolved. Resolution (manual review, automatic return-to-principal, or partial acceptance up to the last valid entry) is an Operator policy matter; Operators MUST publish their Quarantine resolution policy in their Policy Document (Section 18).

15. Device Revocation List

The Foundation publishes the canonical DRL at /.well-known/cashpack-device-revocations.json, Foundation-signed, updated on a published cadence.
Operators MUST fetch and honour the current DRL at Reconciliation time (Section 14.3, step 3).
Certified Devices SHOULD cache the DRL locally and refresh it opportunistically whenever network access is available (Class S directly; Class N via its Host), so a Class S Attestation Exchange (Section 12.2) can reject a known-revoked peer even while offline, using the most recent cached snapshot. A stale local cache is a known and accepted limitation of offline operation; the Operator's authoritative check at Reconciliation is mandatory regardless of what a device believed locally at the time of the hop.

16. Device Certification Program

The Foundation operates a Device Certification Program, accrediting Device Vendors who may issue Device Certificates under a Foundation-issued Vendor CA certificate, separately for Class N and Class S products (a Vendor MAY be accredited for either or both).
Certification requires an independent audit against Section 6's hardware requirements, performed by a Foundation-recognised laboratory. Class S certification additionally audits the integrity of the on-device display and input trusted path (Section 8.3, Section 17). Class N certification additionally audits the field-power envelope and the Host secure channel implementation (Section 6.2, Section 8.4). The Foundation publishes accepted-standards and accepted-laboratories lists separately from this document.
The Foundation MAY revoke a Vendor's CA certification for cause, propagating as bulk DRL entries for that vendor's device population, subject to a published transition period.
Certification is a hardware and software supply-chain control, not a governance seat, and confers no voting rights or influence over Foundation governance (see FPSF Governance Framework).

Class S. The device MUST clearly present the instrument amount, currency, and counterparty identifier on its own integrated display, and MUST require explicit on-device PIN confirmation, before committing to Section 12.4 Proposal or before signing a Tap-Sign-style OTE as sender. This closes the consent loop entirely within Foundation-certified hardware.
Class N. The Host MUST clearly present the instrument amount, currency, and counterparty identifier to the bearer before relaying a sign request, and MUST require explicit confirmation before requesting a PIN-authorized signature. Because the device itself cannot verify what the Host displayed, the Foundation RECOMMENDS bearers perform Class N sign operations only through a Foundation-recognised Companion Application rather than an arbitrary third-party terminal, and RECOMMENDS Companion Applications visually distinguish a balance/status tap (no PIN, no signature) from a send tap (PIN required, produces an OTE).
The Companion Application, for Class N, holds no signing authority and cannot itself produce, alter, or replay an OTE; it is a display and relay surface only, structurally analogous to a wallet frontend in CPP-1.0 and never itself termed a "wallet" in Foundation materials.
A bounded auto-sign policy (Section 8.6) MUST be established only during a PIN-verified session and MUST remain revocable at any time the bearer can reach the device.

18. Operator Obligations

An Operator supporting CPP-002 MUST extend its Policy Document (CPP-1.0 §4.4) with:

Whether Class N (Tap-Sign/OTE), Class S (Peer Handoff/PHE), or both are accepted.
Whether it accepts a SlotPublicKeyReference.export_signature as a condition of crediting an instrument directly to a device-generated address, or treats a bare public key as sufficient (CPP-1.0 default).
Maximum offline chain depth and maximum offline duration, at or below the Section 13 ceilings.
Its Quarantine resolution policy (Section 14.4).
The signing algorithms it accepts (Ed25519, ECDSA P-256, or both).
The DRL source(s) it honours, if supplementary to the Foundation canonical DRL.

An Operator MUST NOT treat an offline hop as final, and MUST NOT release funds or otherwise recognise a redemption based on an unreconciled Custody Chain.

19. Security Considerations

Threat	Mitigation
Double-spend via key reuse after a signature is produced	Terminal `RETIRED` slot state; irreversible destruction of signing capability as part of the same atomic operation that produces the signature (§7.1, §11.4, §12.4)
Handoff or tap interrupted mid-transfer	Fail-closed design: instrument temporarily frozen, never duplicated (§11.5, §12.5)
Physical extraction of SE key material	Tamper-resistant SE required by certification (§6.1)
Cloned or counterfeit device	Device Certificate chain verification at Attestation Exchange and at Reconciliation (§12.2, §14.3)
Compromised device continuing to transact after detection	Device Revocation List, checked authoritatively at Reconciliation regardless of local cache staleness (§15)
Lost or stolen device used to sign without authorization	Mandatory Signer PIN with bounded retry lockout on every signing operation (§8)
Malicious or compromised Host misrepresenting a transfer's amount or counterparty to a Class N bearer before requesting a PIN	Named, unresolved-by-cryptography risk specific to Class N; mitigated procedurally by recommending a trusted Companion Application, not eliminated by protocol (§8.4, §17)
PIN capture by a malicious terminal combined with later device theft	Bounded retry counter limits exposure; DRL-based revocation for known-compromised devices; risk is explicitly named rather than assumed away (§8.4)
Vendor-level compromise	Vendor CA revocation, bulk DRL propagation, published transition period (§16)
Companion Application forging a transfer	Application holds no signing authority; all signatures originate in the SE (§17)
Unbounded offline exposure to the Operator	Mandatory chain-depth and duration ceilings (§13)
Instrument stranded after Quarantine	Operator-published Quarantine resolution policy (§14.4, §18)
Slot exhaustion preventing further receipt or send	Capacity query and batch provisioning via Configuration Mode; `SLOT_CAPACITY_EXCEEDED` surfaced explicitly rather than failing silently (§9)
Field power glitch during Class N key generation or retirement	Atomic state-transition requirement independent of power continuity (§6.1)

20. Non-Goals

This specification intentionally avoids:

Defining a specific device form factor beyond the ID-1 reference profile for Class N — any form factor meeting Section 6 qualifies.
Introducing consensus, voting, or a distributed ledger among devices.
Granting devices or vendors any settlement authority independent of the Operator.
Defining battery, power, or industrial design requirements beyond Section 6.3's functional minimums.
Defining hierarchical or seed-derived key generation. Each Key Slot's keypair is generated independently; a device does not derive slot keys from a common master seed. Seed-derived provisioning MAY be explored in a future revision (Section 21) but is out of scope here, in part because it would reintroduce an exportable secret (the seed) that Section 6.1's non-exportability requirement is designed to avoid.
Defining the Companion Application's visual design beyond the consent obligations in Section 17.
Defining a PIN reset/recovery ceremony (Section 8.5) — Vendor- and Foundation-specific, deferred.

21. Open Questions and Future Work

PIN recovery ceremony. A normative, Foundation-wide reset procedure for a PIN_LOCKED device is needed; today it is left to Vendors, with a floor requirement that reset MUST NOT be a silent bypass.
Cross-class multi-hop test vectors. Section 13 permits mixed OTE/PHE chains; a conformance test suite exercising realistic mixed chains has not yet been published.
Dynamic slot capacity. Whether a secure firmware update may safely increase a device's slot capacity post-manufacture, and under what attestation implications, is unresolved.
export_signature adoption level. Whether the Foundation should move Section 7.2's provenance signature from OPTIONAL to RECOMMENDED or REQUIRED for Operator-side crediting flows is open, pending Operator feedback.
Cellular/eSIM provisioning for Class S. Carrier-specific data provisioning is out of scope of this document and needs its own reference.
Accepted hardware security standards and laboratories lists. To be published and maintained as a living Foundation reference document, not embedded in this specification.
Seed-derived Key Slot generation. Whether a future revision should offer a deterministic-derivation mode as an alternative to independently generated slots, and how that would interact with the non-exportability requirement of Section 6.1.

Normative References

Reference	Description
FPSF-CPP-001 v1.0.0	CashPack Protocol
FPSF-CPD-001	Canonical Payment Definition
RFC 2119	Key words for use in RFCs to Indicate Requirement Levels
RFC 3339	Date and Time on the Internet: Timestamps
RFC 4648	The Base16, Base32, and Base64 Data Encodings
RFC 7517	JSON Web Key (JWK)
RFC 8032	Edwards-Curve Digital Signature Algorithm (EdDSA)
RFC 8785	JSON Canonicalization Scheme (JCS)
ISO/IEC 7810	Identification cards — Physical characteristics
ISO/IEC 14443	Identification cards — Contactless integrated circuit cards — Proximity cards
ISO/IEC 7816-4	Identification cards — Integrated circuit cards — Organization, security and commands for interchange
FIPS 180-4	Secure Hash Standard (SHA-2 family)

CashPack Offline Signer Extension CPP-002 v0.2.0 · DRAFT · Extends CPP-1.0 · Supersedes v0.1.0 · For Discussion and Adoption © 2026 Fabric Payment Standards Foundation — Licensed under Apache License 2.0

Document Metadata​

Summary of Changes from v0.1.0​

1. Scope​

2. Relationship to CPP-1.0 and CPD-001​

3. Terminology​

4. Trust Model​

5. Device Classes​

6. Hardware Requirements​

6.1 Common Requirements (both classes)​

6.2 Class N Additional Requirements​

6.3 Class S Additional Requirements​

7. Key Slot Model​

7.1 Slot States​

7.2 Slot Public Key Reference​

7.3 Device-Local Status and Error Codes​

8. Authorization: PIN and Anti-Theft Controls​

8.1 Requirement​

8.2 On-Device Enforcement​

8.3 Trusted Entry Path — Class S​

8.4 Relayed Entry Path — Class N​

8.5 Lockout and Reset​

8.6 Bounded Auto-Sign Policy (Optional)​

9. Configuration Mode: Key Slot Provisioning​

9.1 Purpose​

9.2 Preconditions​

9.3 First-Use Initialization​

9.4 Provisioning Procedure​

9.5 Batch Export​

9.6 Performance Note​

10. Data Structures​

10.1 Device Attestation​

10.2 Offline Transfer Entry (OTE)​

10.3 Peer Handoff Entry (PHE)​

10.4 Custody Chain​

11. Class N Protocol: Tap-Sign Offline Transfer​

11.1 Session Establishment​

11.2 Authorization​

11.3 Sign Request​

11.4 Slot Retirement​

11.5 Interrupted Session​

11.6 Reconciliation Path​

12. Class S Protocol: Peer Handoff Offline Transfer​

12.1 Discovery and Pairing​

12.2 Attestation Exchange​

12.3 Consent​

12.4 Proposal and Commit​

12.5 Interrupted Handoff​

12.6 Direct Reconciliation​

13. Chain Depth, Expiry, and Mixed-Class Custody Chains​

14. Reconciliation​

14.1 Trigger​

14.2 Submission​

14.3 Operator Validation​

14.4 Quarantine State​

15. Device Revocation List​

16. Device Certification Program​

17. UI and Bearer Consent​

18. Operator Obligations​

19. Security Considerations​

20. Non-Goals​

21. Open Questions and Future Work​

Normative References​