Data Security & Privacy

TrackForge's certification system is designed with a strict separation between cryptographic commitments (which are public) and the underlying metadata (which is private). This page documents the technical boundaries that enforce this separation.

Public vs private data

Data that is publicly visible

The following data points are inherently public or become public through the certification process:

Data	Where visible	Why public
ISRC	Certificate metadata, verification response	Industry-standard public identifier for sound recordings.
Certification date	Certificate metadata, verification response	The timestamp is the point of the certification.
Certification version	Certificate metadata, verification response	Required for verifiers to know which schema was used.
Record hash	Certificate metadata, verification response, Merkle tree	SHA-256 digest of the canonical JSON. Reveals nothing about the content.
Merkle root	Batch metadata, blockchain transaction	The single hash anchored to the blockchain. Reveals nothing about individual tracks.
Blockchain transaction ID	Anchor metadata	Publicly visible on the blockchain. Contains only the Merkle root hash.
Block number	Anchor metadata	Public blockchain data.

Data that is never public

The following data is never exposed through public endpoints, blockchain transactions, or the verification page:

Data	Protection	Reason
Writer names	Authenticated API only	Personal data; rights-sensitive.
IPI numbers	Authenticated API only	Personal identifiers within PRO systems.
Writer shares	Authenticated API only	Commercially sensitive; often disputed.
Catalogue names	Authenticated API only	Client confidential.
Track titles	Authenticated API only	Client confidential (until public release).
Artist names	Authenticated API only	Client confidential (until public release).
Canonical JSON	Authenticated API only	Contains all of the above.
Operator audit trails	Authenticated API only	Internal process records.

What the blockchain contains

The blockchain contains exactly one data point per certification batch: the Merkle root hash. This is a 64-character hexadecimal string (256 bits) committed via an OP_RETURN output in a blockchain transaction.

It is computationally infeasible to derive any information about the certified tracks from the Merkle root. SHA-256 is a one-way function: given the hash, there is no known method to reconstruct the input data. The Merkle root is itself a hash of hashes, adding further layers of indirection.

Concretely, examining the blockchain transaction reveals:

OP_RETURN d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5

Nothing in this value indicates that it relates to music metadata, TrackForge, or any specific catalogue. Without the corresponding proof files and canonical JSON, the hash is meaningless.

Verification page privacy

The public verification endpoint (POST /api/v1/certifications/verify) and any future web-based verification page are designed with the following privacy controls:

No cookies

The verification page sets no cookies of any kind — no session cookies, no analytics cookies, no tracking cookies. There is no persistent state stored in the user's browser.

No tracking

No analytics scripts, no third-party trackers, no fingerprinting. The page loads the minimum required assets and nothing else.

Client-side hashing

When a web-based verification interface is provided, the SHA-256 hash of the canonical JSON is computed client-side using the Web Crypto API:

const encoder = new TextEncoder();
const data = encoder.encode(canonicalJson);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

This means the canonical JSON (which contains sensitive writer and rights data) never leaves the user's browser. Only the resulting hash is sent to the server for verification. The server cannot reconstruct the canonical JSON from the hash.

Server-side verification flow

When the server receives a verification request:

1. It computes the SHA-256 hash of the submitted canonical_json.
2. It looks up the hash in the certification database.
3. It returns whether a match exists, along with public metadata (ISRC, certification date, anchor details).

The server does not log, store, or forward the submitted canonical JSON. The verification endpoint is stateless.

Data handling boundaries

Authentication boundary

Endpoint	Auth required	Sensitive data returned
POST /verify	No	No. Returns only hash, ISRC, dates, anchor info.
GET /batch/{batch_id}	Yes	Batch-level aggregates only.
GET /{catalog_id}	Yes	Summary statistics only.
GET /{catalog_id}/{isrc}	Yes	Yes: canonical JSON, writer count.
GET /{catalog_id}/certificate/{isrc}	Yes	Yes: full certificate with canonical JSON.
GET /{catalog_id}/report	Yes	Yes: full catalogue report.
GET /{catalog_id}/chain-of-title	Yes	Yes: rights chain evidence.
GET /{catalog_id}/proof-bundle	Yes	Yes: complete proof archive.

Rate limiting

The public verification endpoint is rate-limited to 100 requests per minute per IP address. This prevents enumeration attacks (attempting to discover certified ISRCs by brute-forcing the endpoint) while allowing legitimate verification use.

Proof bundle security

The proof bundle ZIP archive contains all data needed for independent verification, including canonical JSON and Merkle proofs. It is available only to authenticated users with access to the catalogue. Once downloaded, the security of the proof bundle is the responsibility of the catalogue owner — TrackForge recommends treating it with the same care as other confidential business records.

GDPR-relevant technical controls

Personal data identification

Under GDPR, the following certified fields may constitute personal data:

Field	Personal data?	Basis
Writer names	Yes	Directly identifies natural persons.
IPI numbers	Yes	Unique identifiers linked to natural persons.
Writer shares	Potentially	When combined with writer names, reveals financial arrangements.
Performer names	Yes	Directly identifies natural persons.
ISRC	No	Identifies a recording, not a person.
Track title	No	Not personal data in itself.

Technical measures

1. No personal data on blockchain — The blockchain contains only the Merkle root hash. No personal data is written to any public blockchain.

2. Hash irreversibility — SHA-256 record hashes cannot be reversed to obtain the canonical JSON containing personal data.

3. Access control — All endpoints that return personal data (canonical JSON, certificates, reports) require authentication.

4. No public enumeration — The verification endpoint requires the full canonical JSON as input. An attacker cannot enumerate certified records without already possessing the data.

5. Stateless verification — The public verification endpoint does not log or store submitted canonical JSON.

6. Data minimisation — The canonical JSON includes only rights-determinative fields. Engagement metrics, internal workflow data, and other non-essential data are excluded.

Right to erasure considerations

If a data subject exercises their right to erasure under GDPR Article 17:

• Canonical JSON and certification records stored in the TrackForge database can be deleted.
• Record hashes (SHA-256 digests) stored in the database can be deleted.
• The Merkle root on the blockchain cannot be altered or deleted. However, the Merkle root is a hash of hashes and cannot be linked to any individual without the corresponding proof chain. Deletion of the proof chain and canonical JSON renders the blockchain entry meaningless.

This approach aligns with GDPR Recital 26, which states that the principles of data protection should not apply to information that does not relate to an identified or identifiable natural person, or to personal data rendered anonymous in such a manner that the data subject is no longer identifiable.