# Auth Layer

## Overview

Authentication in a peer-to-peer (P2P) network is critical, ensuring that only verified peers participate in the network. We introduce an authentication mechanism that leverages BLS signatures, where only authorized peers can connect and broadcast messages. 

## Authentication Protocol

Upon peer connection to the network, it must complete an authentication process before being accepted. The protocol follows these steps:

1. **Challenge Generation**: The new peer receives a unique challenge string upon attempting to connect.
2. **BLS Signature Signing**: The peer must sign the challenge using its private BLS key.
3. **Validation**: The network validates the signed challenge by checking the BLS signature against the operator’s registered public key. If the signature is valid, the peer is authenticated and allowed to participate.

This mechanism prevents unauthorized nodes from connecting.

## Control via AVSGovernance Contract \[Optional] 

This authentication protocol is **optional** and is controlled by the AVS governance contract. The governance contract determines whether authentication is enforced, allowing flexibility in network security policies.

{% hint style="warning" %}
**Important Considerations:**

* Once this feature is enabled, peers running older versions of the client that do not support authentication will no longer be able to connect to upgraded peers.
  {% endhint %}

## Protocol Buffers for Authentication Messages

The authentication protocol defines the following Protobuf messages for communication:

```typescript
@Type.d('AuthRequestProto')
export class AuthRequestProto extends Message<AuthRequestProto> {
  @Field.d(1, 'string', 'required')
  public challenge: string;
}

@Type.d('AuthResponseProto')
export class AuthResponseProto extends Message<AuthResponseProto> {
  @Field.d(1, 'string', 'required')
  public address: string;

  @Field.d(2, 'uint32', 'required')
  public operatorId: number;

  @Field.d(3, 'string', 'required')
  public challenge: string;

  @Field.d(4, 'string', 'required')
  public signature: string;
}
```

***

## CLI Commands for Authentication

Two new CLI commands to facilitate authentication:

### **Signing a Challenge with BLS**

Prompts the operator for their private key and signs the given hashed message.

#### Usage

```bash
othentic-cli operator bls sign-auth [options]

Generate BLS signature for Othentic Auth challenge message

Options:
  --message-hash <data>
  --keystore <keystore>           The file path to the keystore file
  --keystore-password <password>  The file path to the keystore password file
  -h, --help                      display help for command
```

### **Verifying an Authentication Signature**

Verifies if the given signature is valid for the provided message hash and operator ID. You can provide either:

* An **operator ID** (to fetch the BLS public key from the OBLS contract), or
* A **BLS public key** directly.

The `--bls-pub-key` flag accepts a comma-separated list of 4 `uint256` values as returned by the `getOperatorBLSPubKey` function in the OBLS contract. For example:

```
 --bls-pub-key 123...,456..,789,...,10111..
```

#### Usage

```sh
Usage: othentic-cli operator bls verify-auth [options]

Verify signed challenge message with BLS public key

Options:
  --message-hash <data>           Hashed message to be verified (required)
  --signature <signature>         Signature object in JSON format (e.g., {"x":"0x...", "y":"0x..."}) (required)
  --operator-id <operator id>     Operator ID to get BLS public key
  --bls-pub-key <bls public key>  BLS public key to verify the signature
  --keystore <keystore>           The file path to the keystore file
  --keystore-password <password>  The file path to the keystore password file
  -h, --help                      display help for command
```

These commands ensure that authentication can be seamlessly integrated into the P2P network while maintaining security and trust.