# BRC-103: Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol

Ty Everett (ty@projectbabbage.com)

## 1. Abstract

This document specifies a **peer-to-peer** protocol for **mutual authentication** and **signed data exchange**. The protocol uses **certificates**, **nonce-based challenges**, and **digital signatures** to protect the integrity and authenticity of messages, enabling:

- **Selective field disclosure** of certificates without revealing unnecessary information.  
- **Highly extensible message types**, suitable for a variety of use cases such as transaction coordination, identity verification, and arbitrary data sharing.  
- **Interchangeable transport layers**, which can be HTTP, NFC, WebSockets, or any mechanism supporting bidirectional message exchange.

The specification provides a standard approach for issuance, storage, retrieval, and verification of identity certificates, as well as the end-to-end handshake and messaging protocols between peers.

## 2. Motivation

Secure interactions among different wallets and services are critical. These interactions typically require:

- **Proving identity** in a privacy-preserving manner, possibly revealing only some data fields (e.g. “I am over 18” without revealing full date of birth).  
- **Ensuring that both parties are authenticated** to each other (mutual authentication), reducing the risk of man-in-the-middle or impersonation attacks.  

A standard protocol for **mutual authentication** and **certificate exchange** addresses these needs and fosters interoperability between applications, wallets, and vendors.

## 3. Terminology & Definitions

- **Wallet**: An interface or application managing the user’s keys, capable of signing, encrypting, and decrypting data in conformance with [BRC-100](../wallet/0100.md).  
- **Certificate**: A data structure that attests to certain user attributes, signed by a **certifier**.  
- **Master Certificate**: A special form of certificate that has been encrypted field-by-field, each with a unique symmetric key, stored in an internal keyring.  
- **Verifiable Certificate**: A certificate derived from a master certificate, revealing keys for only the fields a particular verifier may see.
- **Peer**: A party participating in communication, using the protocol to exchange messages.  
- **Session**: The state tracking an authenticated channel between two peers.  
- **Nonce**: A random value used once within a cryptographic exchange to ensure freshness and avoid replay attacks.  
- **Signature**: A digital signature produced by the user’s or certifier’s private key.  
- **Transport**: The underlying communication medium that relays messages between peers.

## 4. Certificates and Selective Disclosure

### 4.1 Certificate Format

BRC-103 uses the certificate formats, signature preimage, field encryption rules, master keyrings, and verifier keyrings defined by [BRC-52](./0052.md). BRC-103 messages MUST NOT define an alternate certificate binary layout or alternate certificate signature preimage.

When BRC-103 carries a certificate in JSON, it carries a BRC-52 core certificate plus any applicable BRC-52 unsigned extension members, such as a verifier `keyring`. When BRC-103 carries a certificate in binary, it carries either BRC-52 `CertificateBinary` or a BRC-52 length-prefixed certificate-with-keyring envelope, as required by the surrounding message encoding.

### 4.2 Master Certificate

A **Master Certificate** is a BRC-52 core certificate plus a complete master keyring. It is normally stored by the wallet and is not sent to ordinary verifiers.

### 4.3 Verifiable Certificate

A **Verifiable Certificate** is derived from a master certificate and contains the BRC-52 core certificate plus a verifier-specific `keyring`. It still contains all encrypted fields so the verifier can check the certifier signature over the complete certificate, but it only includes field revelation keys for fields disclosed to that verifier.

### 4.4 Selective Field Encryption

BRC-103 selective disclosure is the BRC-52 selective revelation process:

1. The holder keeps a master certificate whose master keyring can decrypt all fields.
2. For a verifier, the holder decrypts the selected field revelation keys from the master keyring.
3. The holder re-encrypts those field revelation keys for the verifier and includes them in the verifiable certificate `keyring`.

### 4.5 Creation and Verification Processes

Certificate creation, signature verification, field decryption, and revocation checks MUST follow BRC-52. The verifier MUST verify the BRC-52 core certificate signature before accepting any decrypted field and MUST treat a spent non-sentinel `revocationOutpoint` as revoked.

## 5. Peer-to-Peer Messaging Overview

### 5.1 Message Types

Each message exchanged between peers contains:

- **Version**: The protocol version string (e.g. “0.1”).  
- **MessageType**: One of: `initialRequest`, `initialResponse`, `certificateRequest`, `certificateResponse`, `general`.  
- **IdentityKey**: Sender’s public key.  
- **Nonce Fields**: For challenge–response patterns (e.g. `yourNonce`, `initialNonce`).  
- **Signature**: A digital signature by the sender’s private key over the relevant content.  
- **Optional Data**:
  - **Certificates**: A list of verifiable certificates.  
  - **RequestedCertificates**: A set specifying certifiers and certificate types with fields.  
  - **Payload**: Arbitrary data included in `general` messages.

### 5.2 Transports

The protocol does **not** mandate a specific transport. Any medium that can:
1. **Deliver messages** in a reliable or semi-reliable manner, and  
2. **Allow receiving** peer messages,

can be used. HTTP requests, WebSockets, Bluetooth, NFC, or local function calls are all valid.

### 5.3 Session & Nonce Management

A peer typically maintains a **session** record containing:

- **isAuthenticated**: Whether the peer is recognized as fully authenticated.  
- **sessionNonce**: A locally generated random 256-bit value.  
- **peerNonce**: The peer’s random 256-bit value.  
- **peerIdentityKey**: The peer’s public identity key.

A session is created or updated whenever a handshake starts or completes. Nonces and signatures ensure that replaying old messages fails.

## 6. Mutual Authentication Protocol Flow

### 6.1 Handshake Sequence

The handshake typically has **two** messages in the simplest form: an `initialRequest` and an `initialResponse`.

1. **initialRequest**  
   - Sender (A) generates a random nonce (A_Nonce).  
   - A sends `initialRequest` containing:
     - `messageType = "initialRequest"`
     - `identityKey = A_publicKey`
     - `initialNonce = A_Nonce`
     - Optionally, a `requestedCertificates` set if A wants B’s certificates.  

2. **initialResponse**  
   - Receiver (B) verifies the request, creates its own random nonce (B_Nonce).  
   - B sends `initialResponse` containing:
     - `messageType = "initialResponse"`
     - `identityKey = B_publicKey`
     - `initialNonce = B_Nonce` (its own newly created nonce)
     - `yourNonce = A_Nonce` (echoing A’s nonce)
     - Optionally, any certificates B wants to share right away.
     - A **signature** verifying B truly created this message.  

   - When A receives this `initialResponse`, it verifies B’s authenticity via the signature over `(A_Nonce + B_Nonce)`, marking the session as authenticated.

### 6.2 Nonce Creation & Verification

- Each party uses a cryptographically secure random generator for the nonce (e.g., 32 bytes).  
- The verifying side must ensure the nonce is matched or “echoed” in subsequent messages.  
- Optionally, one may use an **HMAC-based** approach to bind nonces to their key, avoiding the need to keep track of all nonces that they created.  

### 6.3 Message Signing & Verification

**Signature** ensures authenticity. The signing steps:

1. Collect relevant data from the message. For instance, a `general` message might sign the raw `payload` array plus ephemeral fields such as `(requestNonce + peerNonce)` to bind the message to the session.  
2. Use the BKDS-based BRC-100 signature creation and verification mechanisms.  
3. Place the resulting signature in the message’s `signature` field.

**Verification**:

1. Recompute the same message preimage.  
2. Verify the signature with the alleged **identityKey**.  
3. If valid, accept the message. Otherwise, reject or treat as an error.

### 6.4 Certificate Requests & Responses

After or during handshake, a peer may request:

- **`certificateRequest`**: “Please provide certificate(s) of type(s) X, issued by Y (or Z).”  
- **`certificateResponse`**: Peer responds by attaching a list of **verifiable certificates** that match the requested type and certifier.  

**Request**:

- Contains a `RequestedCertificates` structure:  
  - `certifiers`: array of public keys representing permissible certifiers.  
  - `types`: a dictionary of `certificateTypeID -> array of fields requested`.  

**Response**:

- Contains an array of **VerifiableCertificates**, each possibly containing:  
  - Encrypted fields.  
  - Re-encrypted keys for the requester.  
  - The certifier’s signature.  

### 6.5 General Message Exchange

Once both sides have completed the handshake (i.e. set `isAuthenticated=true` in their session records), they can exchange arbitrary data:

- **`messageType = "general"`**  
- `payload` can be any binary or text data encoded consistently.  
- The message includes a fresh `nonce` and references the peer’s `nonce` for ephemeral binding to the session.  
- The `signature` covers the payload plus nonces.

## 7. Error Handling & Security Considerations

1. **Replay Attacks**:  
   - Nonces must be unique and used once. The receiver ensures that the same nonce is not accepted more than once.
2. **Man-in-the-Middle**:  
   - The handshake uses mutual signature verification. If a middle party tries to modify data, the signature verification fails.  
3. **Certificate Revocation**:  
   - The `revocationOutpoint` can be polled or monitored in the ledger to confirm it has not been spent. A spent outpoint implies the certificate is revoked Non-zero outpoints must be checked.  
4. **Selective Disclosure**:  
   - Properly encrypt fields with randomly derived keys.  
   - Re-encrypt those keys only for intended verifiers.  
5. **Privilege Escalation**:  
   - Carefully manage session state to ensure a partially authenticated session does not gain privileges.  
6. **Transport Security**:  
   - Although each message is authenticated, transport-level encryption (e.g. TLS) can still be beneficial, especially to hide message lengths or frequencies.
   - This protocol does not encrypt any data by itself.

---

## 8. Implementation Notes

- **Data Types**:  
  - Nonces are 32 bytes.  
  - Public keys are 33 bytes in compressed DER format.  
  - Certificate fields may vary in size, so a length-prefix technique (varint) is standard.
- **Storage**:  
  - A wallet may store certificates in a local database.  
  - A session manager maps `sessionNonce` and `peerIdentityKey` to a single in-memory record.

## 9. Acknowledgments

This protocol is heavily inspired by existing cryptographic handshake approaches (SSH, TLS) and identity-certificate systems (X.509), adapted for a BSV-based environment. Contributors within the ecosystem have refined these ideas to align with BKDS, peer-to-peer exchange, selective disclosure, and other needs.