Bazaar :: BazaarIdentifiers

The problem they solve

The music industry uses three institutional identifiers to track intellectual property:

ISRC (International Standard Recording Code) — identifies a specific recording

ISWC (International Standard Musical Work Code) — identifies a composition

UPC (Universal Product Code) — identifies a commercial product release

These are assigned by registries — PROs, labels, distributors. An independent artist releasing their first track has none of them. Without them, the work has no stable, cross-platform identifier. Licensing conversations stall. PRO registration is impossible. Downstream sync and broadcast clearance requires human correspondence instead of a lookup.

Bazaar solves this with self-issued identifiers that are cryptographically signed, publicly verifiable, and designed to step aside the moment an institutional identifier is obtained.

What a BazaarIdentifier is

A bazaarIdentifier is a short, deterministic string generated from a canonical payload specific to the work:

bazaar:rid:<base32(SHA-256(artistDid + fileCid + fileChecksum + createdAt))>
bazaar:wid:<base32(SHA-256(artistDid + compositionTitle + writers[] + createdAt))>
bazaar:pid:<base32(SHA-256(artistDid + collectionUri + releaseDate))>

Three types:

The identifiers are generated at upload time and written as immutable fields on the catalog record. They are globally unique without a registry because the artist's DID is always in the payload — no two artists can produce the same identifier for the same work.

The signing authority — why the Storefront DID matters

The identifier alone proves nothing. What makes it evidentiary is the signature attached to it.

Every bazaarIdentifier carries a sig field — a base64url signature produced by the Storefront keypair of the Bazaar deployment, not the artist's personal ATProto keypair. This is a deliberate choice: ATProto OAuth does not expose the artist's private key to the application. The app cannot sign on behalf of the artist's personal DID.

Instead, the app signs with the Storefront keypair and writes the record to the artist's PDS using an OAuth session the artist granted. The ownership proof chain is:

1. Artist authenticated with Bazaar via ATProto OAuth
2. App wrote the catalog record to artist's PDS using that session
3. App signed the bazaarIdentifier using the Storefront keypair (appDid)
4. The record now lives on the artist's PDS, signed by the deployment

To verify:

1. Resolve appDid → /.well-known/did.json → public key
2. Reconstruct canonical payload from record fields
3. Verify sig against payload using public key
4. Confirm the record lives on the artist's PDS
(the record's AT-URI encodes the artist's DID — this is free)

No backend involved. No trust in Bazaar required. The verification is fully public because the app's DID document is a public endpoint.

The kid field on every identifier specifies which app keypair produced the signature, so verification continues to work after key rotation. See Storefront DID and the Key Rotation Strategy (to be documented later).

Drop-in replacement for institutional identifiers

BazaarIdentifiers are explicitly designed to yield to institutional identifiers when those are obtained. Each bazaarIdentifier carries a supersededBy* field:

When the artist obtains an ISRC, they update supersededByIsrc on the identifier (and on the isrc field of the item/recording record). The bazaarRid is not removed — it remains as the historical assertion record, with the ISRC as its declared successor.

This means a downstream system ingesting Bazaar catalog records can use isrc if present, fall back to bazaarRid.id if not, and follow the supersededByIsrc field to find the ISRC when registration eventually occurs. The work is never unidentified at any stage of its lifecycle.