Attesting

Attesting is the Write Path of the Fide Context Protocol. This page defines the protocol specification for how drafted statements are signed into verifiable Attestations.

The Attestation Pattern

A Signed Statement has one or more verifiable Attestations.

Attestation Structure

An Attestation entity contains all the data needed for verification:

The Attestation Fide ID (did:fide:0xa0...) is derived by hashing the canonical JSON of these fields using calculateFideId.

JSONL Storage Format

When attestations are written to JSONL (for broadcasting), the format stores the minimum needed for verification and materialization.

Entity type and source type are not stored separately. They are encoded in the Fide ID (the first two hex characters after 0x) and can be derived by indexers using parseFideId or equivalent. This keeps the JSONL lean while preserving full protocol semantics.

Batch Attestations

FCP uses Merkle trees to enable efficient batch signing:

Selective Disclosure

The power of Merkle trees: you only need to disclose the specific statement you want to prove—not the entire batch.

How it works:

1. The verifier receives: the statement Fide ID, the Merkle proof (2-3 hashes), and the attestation data
2. The verifier reconstructs the path from the statement to the Merkle root
3. If the reconstructed root matches the signed root, the statement is verified

Use cases:

• Employee proves their credential without revealing other employees in the batch
• Medical record: prove one diagnosis without revealing full history
• Large batches: verify one statement without downloading the entire batch

Verification Requirements

To verify a signed statement, implementations must check:

1. Attestation ID Derivation — Re-derive the Attestation Fide ID from the attestation data and confirm it matches
2. Signature Validity — Verify the signature over the Merkle root using the method and address specified
3. Merkle Proof — Verify the statement is included in the batch (proof path leads to signed root)
4. Authority (application-layer) — Confirm the signer has the right to make this statement (e.g., via sec:controller)

Signing Methods

The signing method identifies which cryptographic protocol was used. FCP uses CAIP (Chain Agnostic Improvement Proposals) standards so any blockchain or signature system can verify statements.

The method tells the verifier exactly which signing procedure to use—not just the algorithm name.

CAIP-10 User Addresses

The user address uses CAIP-10 format: chainNamespace:chainReference:address.

For chainless signing methods (for example ed25519), an empty chainReference is valid and expected, e.g. ed25519::abc123....

Why this matters:

1. Verification Routing — Different chains use different cryptographic standards

   • eip155:1:0x... → secp256k1 + Keccak verification
   • solana:mainnet:5ey... → Ed25519 + SHA-256 verification

2. Replay Attack Prevention — Testnet and Mainnet signatures are distinguishable

   • A signature for eip155:11155111:0x... (Sepolia) cannot be replayed as eip155:1:0x... (Mainnet)

3. EIP-712 Domain Enforcement — The chain ID is part of the cryptographic math; signatures are mathematically invalid on different chains

EIP-712 Domain Configuration

For Ethereum, statements are signed within the Fide Context Protocol domain:

Domain:
  name: "Fide Context Protocol"
  version: "1"
  chainId: <chain-specific, e.g., 1 for Mainnet>
  verifyingContract: "0x0000000000000000000000000000000000000000"

The chainId becomes part of the cryptographic math itself. A signature created on Mainnet (chainId: 1) is mathematically incompatible with Testnet (chainId: 11155111).