Skip to main content
IRON ID
Request a demo

Technology · Trust layer

Built on verifiable standards.

Under every IRON ID product runs one trust layer. This page is for the people who want to look underneath: CTOs, CISOs, architects, auditors and developers.

Request a technical briefingRead the security overview

trust layer active · in the background

InputIdentity
SHA-256
Stateverified
  1. 01Identity
  2. 02Access
  3. 03Organization
  4. 04Assets
  5. 05Cryptography
  6. 06Provenance
  7. 07Proof

Nine layers

One chain, from the person to the proof.

Each layer answers a question an auditor will eventually ask, and each one rests on the one before it.

01Identity

Objective
Establish who is acting: person or machine.
Problem solved
An account is not an identity. Without proof of belonging, the whole chain collapses.
Capability
Human and machine identities, full lifecycle, verification, revocation.
Outcome
Every action traces back to a named actor.
Technology
X.509 certificates · Argon2

Two regimes

Security protects. Proof demonstrates.

One prevents access. The other lets you show what happened. A trust infrastructure needs both; most tools have only one.

Security · what stays hidden

Protect

Encrypted content

Keys and secrets

Access control

Authentication

Isolation between organizations

Proof · what becomes showable

Demonstrate

Fingerprintsha256:1ebb…c9e4

TimestampRFC 3161

SignerX.509 certificate

ProvenanceC2PA manifest

HistoryMerkle log

The same file. Protected on one side, demonstrable on the other, without ever being revealed.

Foundations

Open standards, published, verifiable by a third party.

No proprietary format sits on the path to proof. Every line below is implemented and tested in the product.

IdentityHuman and machine identities, lifecycle, verificationX.509 · Argon2
AuthorizationRoles, permissions, scopes, isolationCentralised policies
StorageEncrypted storage, separation of dutiesAES-256-GCM
SignatureDigital signature and signer certificatesPAdES B-LTA
TrustFingerprints, timestamping, attestations, verificationSHA-256 · ECDSA · RFC 3161
ProvenanceProvenance manifest bound to the contentC2PA
AuditTamper evident log and checkpointsMerkle tree
AnchoringFingerprint anchored to a public ledgerOpenTimestamps · Bitcoin

Anchoring

Thirty two bytes are enough.

What goes onto the public ledger is the fingerprint. Not the document, not its name, not its size, not its type.

  1. 1The filestays in the vault
  2. 2SHA-25632 bytes
  3. 3OpenTimestampssubmitted to the calendar
  4. 4Bitcoinrecorded in a block
What is published32 bytes
What it reveals about the contentnothing

Anchoring confirms within one to six hours. It does not gate legal value, which is acquired at the timestamp.

Evidence bundle

Your proofs outlive your supplier.

Every certified document exports as a self sufficient bundle in a public, documented format. Verify it with the open source tool; nothing in it needs IRON ID to exist.

ironid-evidence-{bundleId}.zip├── manifest.json · signed index├── document/ · content-hash.txt · original├── attestations/ · timestamp.tsr · anchor.ots · c2pa.manifest├── certificates/ · chain-attest.pem├── audit/ · entries.jsonl · inclusion-proof.json · checkpoint.json└── verification/ · how to verify, offline
It guaranteesIt does not guarantee
Content unchanged since sealingThat the document says the truth
A fingerprint existed at a dateWho the depositor really was
Which issuer produced each attestationThat the issuer is trustworthy
The audit log was not rewrittenNothing was omitted before sealing

Your turn

See what happens to a file.

You have just seen the three ideas: the fingerprint, the time, the chain. Run them on your own file — it will not leave this tab.

No upload. The file never leaves this tab.

Proof engine sequence

Simulated attestations
  1. t0Document version createddocument_versionFingerprint recorded, version sealed
  2. t0+1sElectronic timestamprfc3161_timestampRFC 3161 — the content existed at this date
  3. t0+1sProvenance manifestc2pa_manifestC2PA — tamper-evident binding to the content
  4. t0+2sAnchor submittedots_anchorOpenTimestamps — awaiting confirmation
  5. t0+1–6hAnchor confirmedots_anchorFingerprint recorded on Bitcoin

Legal value is acquired at the timestamp, in under a second. The Bitcoin anchor reinforces durability; it is never on the critical path.

The steps below replay the proof engine's real sequence and its real latencies. On an IRON ID account they are produced by the server. Here they are simulated — the fingerprint, however, is genuinely yours.

What we claim

Precise words, on purpose.

On a trust product, an excessive promise is the first thing an adversary will use. Every sentence on this site follows the same rule.

We say

Verifiable proof of integrity, checkable independently

Tamper evident: any modification is detectable

Electronic timestamp (RFC 3161)

Fingerprint anchored on a public, verifiable ledger

Long term verifiable signature format (PAdES B-LTA)

Proofs remain verifiable without IRON ID

We do not say

Tamper proof or impossible to falsify

Legally equivalent to a handwritten signature

Qualified timestamp, until the provider is named

Proof of authorship, rather than of prior existence

End to end encryption, outside the true E2E mode

100 % compliant with any regulation

Go deeper

Talk to the people who built it.

Architecture walkthrough, threat model, verification demo on your own files. Bring your CISO.

Request a demoRequest a quote

Reply within two business days · contact@iron-id.io