Blue Badge Released

Posted 2024-08-26 23:00 ‐ 4 min read

Blue Badge is a lexicon for defining badges, representing their award, and proving issuance authenticity. There are a lot of ways that this can be applied and used:

A person can display an earned certificate from a class that they completed.
Individuals can collect badges from different swing dance competitions in which they've participated or competed.
A forum member could display their earned badges by creating discussions and assisting other members.
An organization could prove they've earned industry recognition.

This badge lexicon involves attestation, a "trust but verify" of data ownership. Using a cryptographic signature in award records, an issuer can attest that an award record contained in a personal data server is valid.

blue.badge.definition

The blue.badge.definition record defines the badge. When a badge is created, it contains the user-supplied name and text, but it also results in a record that can be referenced as an AT-URI and CID.

{
    "uri": "at://did:plc:puy52u7opoy3gvrv7h7qdy76/blue.badge.definition/6XXzn32gbU",
    "cid": "bafyreifbq7wub6wfuntruagvaaivqsinxyc4mpbfagjka35v4wx7aeu3fe",
    "value": {
        "name": "Adventure Awaits!",
        "text": "You're in for an adventure! Log in for the first time to https://atproto.camp/",
        "$type": "blue.badge.definition"
    }
}

blue.badge.award

The blue.badge.award record is the claim of award, or possession, of a badge. Award records are contained in the personal data server of the handle that received the badge.

{
  "cid": "bafyreiaqx3k3asw2zg7fnvxz2bm4i7ju6xwq7svqkvkgskcclpeuqdzjny",
  "uri": "at://did:plc:cbkjy5n7bk3ax2wplmtjofq2/blue.badge.collection/3l2npthykb226",
  "value": {
    "$type": "blue.badge.award",
    "badge": {
      "cid": "bafyreifbq7wub6wfuntruagvaaivqsinxyc4mpbfagjka35v4wx7aeu3fe",
      "description": "You're in for an adventure! Log in for the first time to https://atproto.camp/.",
      "name": "Adventure Awaits!",
      "uri": "at://did:plc:puy52u7opoy3gvrv7h7qdy76/blue.badge.definition/6XXzn32gbU"
    },
    "did": "did:plc:cbkjy5n7bk3ax2wplmtjofq2",
    "issued": "2024-08-26T22:14:02.000Z",
    "proof": {
      "k": "https://atproto.camp/.well-known/jwks.json#01J67HHM2CCKT98FE20SKPR5EA",
      "s": "2-EaPZELcvu5SL8lS863fta8moqLZcpKlrzFpn7RbUr_B37HZphJa642dJfGNM2BMZGl-YGQync-2pyhoPC4Wg=="
    }
  }
}

Awards contain 4 essential pieces of information:

Who the badge was issued to
When the badge was issued
What badge was issued
Proof that the badge was issued

Proof of issuance includes both the award record's signature and a way to retrieve the key used to verify the signature.*

At this time, the key reference is a URL to a JSON Web Key Set structure, where the key identifier (kid) is in the URL fragment. This is a stop-gap until the did-core assertion method (or a better alternative) can be used.

The signed content used to create the signature is the DAG-CBOR payload of the record.

All the information is used to create the signature to ensure that a record cannot be copied from one repository to another. For example, because the awarded handle's DID is in the signed record, the DID in the record and in the AT-URI can be compared during validation.

In Action

The above award record is live and can be viewed here: https://badge.blue/verify?uri=at://did:plc:cbkjy5n7bk3ax...

To support this lexicon, I've spun up two websites:

https://atproto.camp is a web application that awards badges. The @atproto.camp handle has a collection of badge definitions and exposes JSON web keys that can be used to verify any badges issued.

When you authenticate using OAuth, ATProto Camp can create records in your personal data server. That two-way consent is the core of the award process: Without permission, the issuer cannot write badges to your PDS, and the issuer writes badges at its discretion.

https://badge.blue is the website that is home to the lexicon. It also provides a way to independently verify award AT-URIs.

Discussion and Debate

Supporting verifiable content and attestation in the data-plane is a natural direction that ATProtocol is moving towards. This is an early proof-of-concept that will no doubt change. If you have thoughts, questions, or comments, message me: @ngerakines.me