# Publishing Trust Anchor Details at an Internet Domain

Ty Everett (<ty@projectbabbage.com>)

## Abstract

This document outlines a protocol that allows an entity to publish trust anchor details, including a public key, at a location on the internet. The information is stored in the `/manifest.json` file of the domain under the `metanet.trust` key. This approach provides a user-friendly method for individuals to easily retrieve a trusted entity's public key by entering a known domain name.

## Motivation

The internet today has an increasingly complex landscape of entities that users may or may not trust. As systems decentralize, the need to independently verify the identity of a digital entity becomes vital. By allowing entities to publish trust details at known locations (their domains), users are provided with a recognizable and straightforward method to retrieve and validate their public keys, hence building a more trustable web.

## Specification

### Location & Protocol

1. The trust anchor details MUST be published in a file named `manifest.json`.
2. The `manifest.json` file MUST be hosted using the HTTPS protocol. Plain HTTP is not supported.
3. Only Fully Qualified Domain Names (FQDNs) are supported for hosting the `manifest.json` file.

### Data Structure

The trust details should be stored under the `metanet.trust` key in the `manifest.json` file. The `trust` object should be defined with the following properties:

* **name**: The human-readable name of the entity.
* **note**: A brief note describing the role or function of the entity.
* **icon**: A URL pointing to an icon image representing the entity.
* **publicKey**: The public key of the entity in hexadecimal format.

### Validation Rules

1. **name**
   * MUST be a string.
   * MUST contain between 5 to 30 characters, inclusive.
2. **note**
   * MUST be a string.
   * MUST contain between 5 to 50 characters, inclusive.
3. **icon**
   * MUST be a valid image URL.
   * Should be accessed over HTTPS.
4. **publicKey**
   * MUST be a string in DER format.
   * MUST be compressed.
   * MUST use the secp256k1 elliptic curve.
   * The string should start with either "02" or "03".
   * MUST be in hexadecimal format, and 66 characters in length (including the starting "02" or "03").

### Examples

Here is a valid example of a `manifest.json` containing the trust anchor details:

```json
{
  "name": "SigniCert",
  "metanet": {
    "trust": {
      "name": "SigniCert",
      "note": "Certifies legal first and last name, and photos",
      "icon": "https://signia.babbage.systems/images/signiaIcon.png",
      "publicKey": "0295bf1c7842d14babf60daf2c733956c331f9dcb2c79e41f85fd1dda6a3fa4549"
    }
  }
}
```

For this example:

* `name` is "SigniCert", which has a length between 5 and 30 characters.
* `note` has a length between 5 and 50 characters.
* `icon` points to an image hosted over HTTPS.
* `publicKey` is a compressed DER-encoded key using the secp256k1 curve, starting with "02" and is 66 characters long.

### Backwards Compatibility

For migration compatibility, implementations MAY continue reading legacy `babbage.trust` entries, but `metanet.trust` is the canonical key for this specification.

## Conclusion

This technical specification provides a comprehensive framework for entities to publish trust anchor details at a known internet domain. By adhering to the defined structure and validation rules, we ensure a standardized method for users to access and trust these details. This is a step towards creating a more transparent and trustable digital landscape.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://bsv.brc.dev/peer-to-peer/0068.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.