# Certificates

Canonical: https://docs.projectbabbage.com/docs/concepts/certificates

How Certificates function within Project Babbage, highlighting cryptographic identity proof structures that respect user privacy.

In the BSV application ecosystem, **Certificates** provide verifiable proofs of identity or attributes, securely bound to user-controlled keys. They enable cryptographic attestation of facts (such as a user’s personal details) while preserving privacy through **selective disclosure**. Below is an overview of how certificates work, why they matter, and which BRCs define the format and protocols for creating, revealing, and exchanging them.

## Key Standards

1. **Identity Certificates (BRC-52)**  
   [BRC-52](https://github.com/bitcoin-sv/BRCs/blob/master/peer-to-peer/0052.md) introduces a privacy-centric, open-ended mechanism for linking a user’s public keys with specific identity data. Fields in these certificates are individually encrypted, ensuring users decide which pieces of info they disclose.

2. **Certificate Creation & Revelation (BRC-53)**  
   Adding to BRC-52, [BRC-53](https://github.com/bitcoin-sv/BRCs/blob/master/wallet/0053.md) defines how an application requests that a wallet both generate and prove certificates. It covers the handshake with a **certifier**, how keys are encrypted, and how partial revelations (i.e., selected fields only) are securely accomplished.

3. **Peer-to-Peer Mutual Authentication (BRC-103)**  
   [BRC-103](https://github.com/bitcoin-sv/BRCs/blob/master/peer-to-peer/0103.md) describes a protocol for two peers to mutually verify each other’s identities (and optional attributes). It leverages identity certificates under BRC-52/53 and standardizes the message flow so each party authenticates the other in a symmetrical, secure exchange.

## How Certificates Work

1. **Data Ownership & Encryption**  
   A certificate is composed of fields (e.g., “first_name,” “city,” “profile_picture”) individually encrypted with a unique key, so only the certificate holder can decrypt or re-encrypt them for authorized verifiers.

2. **Certificate Signing**  
   A **certifier**—such as a trusted authority or an automated service—digitally signs the certificate data, guaranteeing that the attributes (once decrypted) are valid and unmodified.

3. **Selective Disclosure**  
   Users retain control over which fields they share. When a verifier requests certain certificate fields, the user’s wallet re-encrypts those fields’ keys for that verifier only. This is the core of BRC-52’s privacy-first design, extended by BRC-53.

4. **Revocation Outpoint**  
   Certificates optionally include an on-chain outpoint that the certifier can spend to revoke a certificate. This real-time blockchain check avoids reliance on off-chain certificate revocation lists.

## Workflow Overview

1. **Application Requests**: An App (or website, service, etc.) asks the user’s wallet (via BRC-53) to create or prove a certificate.  
2. **User Consent**: The wallet prompts the user to confirm what data fields the App can see.  
3. **Certifier Interaction**: If creating a new certificate, the wallet contacts the certifier, obtains signatures, and stores the relevant encryption keys.  
4. **Final Proof**: The wallet supplies the App (or another verifier) with a partially unencrypted certificate (only the allowed fields) and the certifier’s signature.

## Why Certificates Matter

1. **Privacy & Control**  
   Traditional ID systems often expose unnecessary info. Metanet certificates, in contrast, let users reveal only minimal data, safeguarding sensitive details.

2. **Decentralized Identity**  
   There’s no single identity provider that can block or remove your identity. Instead, multiple certifiers can coexist, and you choose whom you trust.

3. **Security & Authenticity**  
   Certificates inherit the cryptographic strength of BSV-based signing. Verifiers can confirm authenticity by checking each certificate’s on-chain revocation status.

4. **Interoperability**  
   By adhering to BRC-52, BRC-53, and BRC-103, any certified data can be shared across apps and wallets with consistent, open protocols rather than one-off integrations.

## Next Steps

- **Check out [MarsCast](https://github.com/p2ppsr/mars-cast)**: A codebase implementing micropayment monetization of Martian weather data, but only if you have a Cool Person Certificate!
- **Learn Identity Certificates**: Read [BRC-52](https://github.com/bitcoin-sv/BRCs/blob/master/peer-to-peer/0052.md) for in-depth data structures and field-level encryption.  
- **Request & Prove**: Implement user flows aligned with [BRC-53](https://github.com/bitcoin-sv/BRCs/blob/master/wallet/0053.md) for ephemeral or persistent certificate issuance and partial proofs.  
- **Mutual Authentication**: Check [BRC-103](https://github.com/bitcoin-sv/BRCs/blob/master/peer-to-peer/0103.md) to see how two peers can authenticate each other (and possibly exchange specifics) for advanced synergy among users, wallets, and apps.

Certificates usher in an era of flexible, user-centric identity on the BSV blockchain, letting you harness cryptographic trust without sacrificing privacy or interoperability.