Beersy
BRC-68

Publishing Trust Anchor Details at an Internet Domain

Deciding whether to trust a means knowing which keys an organisation actually vouches with. This publishes that at the organisation's own domain, so it can be looked up the same way any other website detail is.

Ty Everett2 min read
useruseruserdomain

Summary

Why
There was no standard place to look up a trusted entity's public key using just a domain name people already recognize.
What
BRC-68 defines a way to publish an entity's name, description, icon, and public key inside the file of its HTTPS domain.
How
A developer fetches .json from the entity's domain over HTTPS, reads the metanet.trust object, and validates the name, , icon, and publicKey fields against the spec's rules before trusting that key.

What this lets you do

  • Publish a trust at a domain you control
  • Fetch a public key just by knowing a domain name
  • Validate a publicKey is a proper compressed key
  • Attach a human-readable name and icon to a public key
  • Support legacy babbage.trust entries while migrating to metanet.trust

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

Reference for an AI

Everything an assistant needs to answer questions about BRC-68 accurately, including what it depends on.

The specification

Abstract

This document outlines a protocol that allows an entity to publish trust 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 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 .
    • MUST be compressed.
    • MUST use the 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:

{
  "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.

Was this helpful?

Search Beersy

Search standards by number, title, author or topic