Security Considerations

Document Integrity

The protocol relies on SHA-256 collision resistance for document integrity. SHA-256 is considered cryptographically secure as of this specification's date.

If SHA-256 is compromised in the future, the specification MUST be updated to use a successor hash function. The contentHash format (0x-prefixed, 64 hex characters) can accommodate any 256-bit hash function without format changes.

---

Snapshot Authenticity

The snapshot stored by the ALC API is the authoritative copy. The integrity guarantee depends on:

1. The snapshot being stored immutably (not modifiable after creation)
2. The SHA-256 hash matching the on-chain contentHash

Implementations SHOULD store snapshots in content-addressed storage (IPFS, Arweave) for additional integrity guarantees. Implementations MUST NOT modify snapshots after creation.

The verification flow is deterministic: fetch the snapshot, hash it, compare to the on-chain contentHash. A match is conclusive proof of authenticity.

---

Replay Protection

EIP-712 signatures include chain ID and verifying contract address in the domain separator, preventing:

• Cross-chain replay -- A signature on Tempo cannot be replayed on Base
• Cross-contract replay -- A signature for one IntegraRecord contract cannot be replayed against another

The timestamp and expiry fields in TermsAcceptance provide temporal replay protection:

• timestamp binds the acceptance to a specific moment
• expiry makes the acceptance time-limited (if set)

---

Agent Authorization Scope

The protocol does not enforce agent authorization scope directly -- it provides the infrastructure for recording and verifying it. Enforcement is the responsibility of:

• The tokenizer (defines what agents are authorized to do)
• The terms validation resolver (validates that proposed terms fall within the agent's scope)

Implementations SHOULD validate that agents act within their authorization scope before recording acceptances. The authorizationRef field in EIP-712 signatures enables verifiers to check the delegation chain.

---

Privacy

IntegraRecords on public blockchains are visible to all. The protocol enforces strict separation of concerns:

On-chain (public):

• Addresses (pseudonymous)
• Content hashes (opaque -- the hash reveals nothing about the content)
• Timestamps
• Resolver references

Off-chain (API layer):

• Terms documents
• Contact information
• Personal data

Implementations MUST NOT store personally identifiable information (PII) on-chain. PII SHOULD be stored off-chain in the API layer and referenced by hash.

---

Availability

The ALC API is a service fronting decentralized on-chain records. If the API is unavailable:

• On-chain records remain accessible via direct blockchain queries
• Terms verification can be performed by any party with the snapshot and the contentHash
• Dispute resolution resolvers operate independently on-chain

Implementations SHOULD use multiple deployment models (hosted, self-hosted, third-party hosted) to reduce single-point-of-failure risk. The on-chain records are the ultimate backstop -- the API is a convenience layer, not a single point of truth.