Security Model

StellarProof is designed so that breaching its servers will yield nothing useful because its servers are designed to hold nothing useful.

What an attacker who compromises the database would get

Approved issuer public keys. Revocation roots. Session identifiers. A set of field elements that look like random 256-bit numbers. And credential ciphertext sealed with XChaCha20-Poly1305 to keys derived on each user's own device, which StellarProof will not have and cannot obtain.

What StellarProof itself will not be able to do

StellarProof will not be able to track a user across anchors, and this is a property of the cryptography rather than a policy commitment. A user's credential is bound to the hash of their secret, never the secret itself StellarProof only ever receives the hash. Deriving the per-anchor identifiers that would let anyone follow a user requires the secret itself, which StellarProof will never have.

What colluding anchors will not be able to do

Compare their records and identify a common user. Every anchor will receive a different value derived from the user's secret and the anchor's own ID. The one value that would be identical everywhere the credential commitment is deliberately never revealed, precisely because it would function as a perfect join key.

Revocation that isn't a tracking channel

Revoked credentials will be held in a sparse Merkle tree, and holders will prove non-membership. Only the tree root will be public. A valid credential will reveal no stable identifier at all, and revoking one will say nothing about who was revoked. The revoked list is designed to be served in full rather than answering per-credential queries because answering "is nonce X revoked?" would tell StellarProof exactly which credential is about to be used.