Two identities in every Bazaar transaction

Every Bazaar purchase involves two distinct cryptographic identities:

  1. 1.

    The artist's ATProto DID — e.g. did:plc:abc123...

  2. 2.

    The Bazaar app storefront DID — did:web:bazaar.whereditgo.diamonds

These are not the same thing, do not overlap, and serve fundamentally different roles. Understanding the distinction is the key to understanding how Bazaar's trust model works.

The artist's DID

An artist's DID is their ATProto identity — issued by a PLC registrar or anchored to a domain they control. It is the identity associated with their PDS (Personal Data Server), where their catalog records, license terms, and listings live.

What the artist's DID proves: "This PDS belongs to this identity. Records written here were written by someone in possession of the corresponding keys."

The artist's DID is used for:

  • Authenticating into Bazaar via ATProto OAuth

  • Authorizing the app to write records to their PDS on their behalf

  • Appearing in catalog record fields like artistDid — asserting authorship of the work

Critically: the artist's DID private key is never exposed to Bazaar. ATProto OAuth grants the app a session token, not the key. The app can write records to the artist's PDS while logged in, but it cannot sign arbitrary payloads with the artist's identity.

The app storefront DID

The Bazaar app storefront DID is a did:web identity anchored to the platform's domain:

did:web:bazaar.whereditgo.diamonds

Resolution is a plain HTTPS fetch:

GET https://bazaar.whereditgo.diamonds/.well-known/did.json

The DID document at that endpoint publishes the app's public verification key(s). The corresponding private key lives in the server's secrets manager and never leaves it.

What the storefront DID proves: "This record was signed by the Bazaar application."

The storefront keypair is used for:

  • Signing purchase.receipt records written to buyer PDSs

  • Signing purchase.consent records written to buyer PDSs

  • Signing bazaarIdentifier fields (bazaarRid, bazaarWid, bazaarPid) on catalog records

Why they are separate

The separation exists because of a fundamental constraint: ATProto OAuth does not expose the artist's private key to the application. The app cannot produce signatures that verify against the artist's DID document.

This is actually correct behavior — the artist should not be handing their signing keys to a third-party application. But it creates a gap: records written to the artist's PDS via OAuth carry no artist-signature, only a session-authorized write. For catalog identifiers and purchase receipts, a signature is needed to make the records independently verifiable.

The solution is the storefront DID: the app has its own keypair, signs the records that need signing, and publishes its public key in its own DID document. Verifiers resolve the app DID rather than the artist DID.

The relationship between the two

The two identities are linked transitively, not directly:

Artist authenticated with Bazaar via ATProto OAuth
  → Artist granted the app a session to write to their PDS
  → App wrote a catalog.item.digital record to the artist's PDS
  → App signed the bazaarRid on that record using the storefront keypair
  → The record's AT-URI encodes the artist's DID (it lives on their PDS)
  → The bazaarRid.sig is verifiable against appDid's public key

A verifier confirming a bazaarIdentifier can establish:

  • The record lives on the artist's PDS (AT-URI says so — free verification)

  • The identifier was signed by the Bazaar app storefront (resolve appDid, verify sig)

  • The artist authorized the app to write to their PDS (implied by the OAuth session used to write the record)

Together these form the ownership assertion: the artist was authenticated, the app acted on their behalf, and the app attested the identifier.

For purchase.receipt records, the relationship is analogous but involves the buyer's PDS:

Buyer authenticated via ATProto OAuth
  → Stripe confirmed payment
  → App signed the receipt using the storefront keypair
  → App wrote the receipt to the buyer's PDS
  → receipt.buyerDid explicitly names the buyer
  → receipt.issuerScope names the artist's storefront
  → receipt.appDid names the signing authority

The receipt is a three-party instrument: buyer, artist, and app — each named explicitly, the app's attestation cryptographically verifiable, the buyer's ownership of the receipt confirmed by the PDS it lives on.