> For the complete documentation index, see [llms.txt](https://docs.zipwire.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zipwire.io/fundamentals/security/attestations/signer-identity-cross-referencing.md). # Signer Identity Cross-Referencing (E-Sign) ## Overview When a respondent cryptographically signs a document in Zipwire Collect, Zipwire looks up whichever prior identity-interesting attestations that signer already holds — an ID check, `IsAHuman`, `HasClearAML`, or an age tier — and cross-references them against the new signing attestation. This lets a reviewer see, and independently verify on-chain, what identity evidence stood behind a given signature, without Zipwire re-asserting or re-verifying those facts itself. Two mechanisms carry this information: * **EAS `refUID`** — the new signing attestation's own on-chain `refUID` field points at exactly one prior attestation (EAS only has one `refUID` slot per attestation). * **`signerIdentityAttestations` Merkle leaf** — a leaf on the signing tree (see [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs.md)) listing *every* identity-interesting attestation found for the signer, not just the one chosen for `refUID`. This only applies to the **respondent's** signing tree. The requestor's file-integrity signing tree does not carry this leaf — that tree concerns the requestor's own file, not the respondent's identity. ## How It's Built ### 1. Find Zipwire scans the signer's own [Idents](/fundamentals/security/understanding-proofpack.md) — the same on-chain-attestation-to-account lookup used elsewhere in the platform — for any attestation whose schema is identity-interesting: | Schema | Priority | | ---------------------------------------------------------------------- | ----------- | | `Private Data` (ID check only — AML-report `Private Data` is excluded) | 0 (highest) | | `IsAHuman` | 1 | | `HasClearAML` | 2 | | Any age tier (`IsThirteen` … `IsTwentyOne`) | 3 (lowest) | See [Attestation Schemas](/zipwire-attest/attestation-schemas.md) for the full schema reference. If a signer holds more than one attestation of the same schema, only the freshest (by on-chain creation time) is kept. ### 2. Choose At most one candidate is picked as the new signing attestation's `refUID`, by priority first (ID check beats `IsAHuman` beats `HasClearAML` beats age), then freshest wins ties within the same priority. An ID check is preferred because it's the most information-rich piece of evidence available; the others are weaker signals kept only as fallbacks. ### 3. Record Every candidate found in step 1 — not just the one chosen for `refUID` — is written into the `signerIdentityAttestations` leaf, each entry flagged with whether it's the one referenced by this attestation's on-chain `refUID`. ## Leaf Structure ```json { "signerIdentityAttestations": { "Description": "Other on-chain attestations found for this signer at the time of signing (e.g. identity or AML checks). These are informational context only - this signing attestation does not itself verify them; a reviewer should query each AttestationUID on the stated network to confirm validity. At most one may be referenced by this attestation's own on-chain refUID field, marked isReferencedByThisAttestation.", "Attestations": [ { "SchemaName": "Private Data", "SchemaUID": "0x20351f973fdec1478924c89dfa533d8f872defa108d9c3c6512267d7e7e5dbc2", "AttestationUID": "0x4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f", "ServiceName": "EAS", "Network": "base-sepolia", "CreatedAtUtc": "2026-06-02T11:04:00Z", "DocsPath": "fundamentals/security/attestations/the-private-data-attestation-merkle-roots", "IsReferencedByThisAttestation": true }, { "SchemaName": "Is A Human", "SchemaUID": "0x8af15e65888f2e3b487e536a4922e277dcfe85b4b18187b0cf9afdb802ba6bb6", "AttestationUID": "0x5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a", "ServiceName": "EAS", "Network": "base-sepolia", "CreatedAtUtc": "2026-05-11T08:47:31Z", "DocsPath": "fundamentals/security/attestations/the-isahuman-attestation-purpose-and-limitations", "IsReferencedByThisAttestation": false } ] } } ``` ### Fields | Field | Meaning | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `SchemaName` | Human-readable schema name (e.g. `Private Data`, `Is A Human`). | | `SchemaUID` | The EAS schema's UID on the stated network. | | `AttestationUID` | The UID of this specific attestation — query this on EAS Scan to verify it independently. | | `ServiceName` | Always `EAS` today (Ethereum Attestation Service). | | `Network` | The chain the attestation lives on, e.g. `base-sepolia`. | | `CreatedAtUtc` | When the referenced attestation was created — not when the signing happened. | | `DocsPath` | Relative path (within this GitBook) to the schema's own reference page, so a reviewer can look up what the schema means. | | `IsReferencedByThisAttestation` | `true` for the single entry (if any) whose `AttestationUID` was also written to this signing attestation's on-chain `refUID`. At most one entry per leaf will be `true`. | ## Important Notes for Verification * **This leaf is informational, not verifying.** The signing attestation does not itself prove any of the listed attestations are valid, unrevoked, or unexpired — a reviewer must independently query each `AttestationUID` on the stated `Network` (e.g. via EAS Scan) to confirm validity. See [Verifying Zipwire's Merkle Root Attestations for Developers](/fundamentals/security/wallet-verification-guide/verifying-zipwires-merkle-root-attestations-for-developers.md). * **Omitted, not empty, when there's nothing to show.** If the signer holds no identity-interesting attestations at signing time, the `signerIdentityAttestations` key is absent from the tree entirely — it is never present as an empty array. * **`refUID` is a hint, not a guarantee.** Because EAS only exposes one `refUID` slot, the chosen reference is the *best available* evidence at signing time by the priority above, not necessarily the most relevant to every downstream use case. Consumers that need a different signal should read the full `Attestations` array rather than relying on `refUID` alone. ## Related Resources * [Attestation Schemas](/zipwire-attest/attestation-schemas.md) * [The "Private Data" Attestation: Merkle Roots](/fundamentals/security/attestations/the-private-data-attestation-merkle-roots.md) * [The "IsAHuman" Attestation: Purpose and Limitations](/fundamentals/security/attestations/the-isahuman-attestation-purpose-and-limitations.md) * [The "HasClearAML" Attestation: Purpose and Limitations](/fundamentals/security/attestations/the-hasclearaml-attestation-purpose-and-limitations.md) * [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs.md) * [Verifying Zipwire's Merkle Root Attestations for Developers](/fundamentals/security/wallet-verification-guide/verifying-zipwires-merkle-root-attestations-for-developers.md) * [Sign It Once, Prove It Forever](/zipwire-collect/signable-documents-cryptographic-proof.md)