Credential Structure

Participants in our project do not need a deep understanding of credential structure. However, we provide this information to help with debugging and exploration.

When an issuer issues a credential, they do it either by manually interacting with a UI on their integration agent, or by calling APIs that their integration agent exposes. Either way, the agent populates a JSON data structure, hashes it, and then digitally signs the hash. The issuer's signature is not stored within or beside the data structure, but is instead reported to witnesses (lightweight web servers, analogous to bind servers in DNS, that testify to the public about what the issuer has done). Issuance automatically gives a copy of the credential to the holder, and notifies the world about what you've done.

Sample

All the credentials we'll be using are stored in ACDC format. Basically, they are JSON with some attached base64-encoded binary data; you can handle them as text files and inspect them in any convenient text editor. Here is what an actual credential (in this case, a vLEI with a couple text fields shortened by ellipses, and a binary attachment at the end) looks like:

{
  "v":"ACDC10JSON0005c8_",
  "d":"EIiGTpV9qNIUeyF-vg7FI-E-LfJmwWzn1bDhgMMNggwm",
  "i":"ED88Jn6CnWpNbSYz6vp9DOSpJH2_Di5MSwWTf1l34JJm",
  "ri":"EKfi58Jiv-NVqr6GOrxgxzhrE5RsDaH4QNwv9rCyZCwZ",
  "s":"ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY",
  "a":{
    "d":"EOLRvvUtC4Rhf81jXehqTUZGMjvDc_44EXqQKjb5N-7C",
    "i":"EKXZ8mKY8wL7kFq-WsJX0t6TaLkDFR3aP_-xO7NNMvb2",
    "dt":"2025-08-12T08:41:29.626000+00:00",
    "LEI":"50670047U83746F70E20"
  },
  "e":{
    "d":"EEyVJC9yZKpbIC-LcDhmlS8YhrjD4VIUBZUOibohGXit",
    "qvi":{
      "n":"EMatUqz_u9BizxwOc3JishC4MyXfiWzQadDpgCBA6X9n",
      "s":"EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao"
    }
  },
  "r":{
    "d":"EGZ97EjPSINR-O-KHDN_uw4fdrTxeuRXrqT5ZHHQJujQ",
    "usageDisclaimer":{"l":"Usage of a valid, unexpired, and non -revoked..."},
    "issuanceDisclaimer":{"l":"All information..."}
  }
}-IABEI iGTpV9qNIUeyF-vg7FI-E-LfJmwWzn1bDhgMMNggwm0AAAAAAAAAAAAAAAAAAAAAAAEIBpniUi5yXEsebs1nJShMxvkbLyy4wN6v0hgBBpl0Sl

Fields

Schemas for ACDCs follow the JSON Schema standard. The unique fields in each schema type are inside the a object that lives at the root of the data structure, on the 4th line above. Other fields at the root of the data structure, that are common to all schemas, include:

v (required) Contains a version statement.

d (required) Contains the SAID (CESR-encoded Blake3 hash) of the ACDC. (Nested d fields contain SAIDs of nested JSON objects. These are used for graduated disclosure to accomplish some privacy goals, and they become important in caching as well.)

i (required) In the outermost structure, contains the AID of an issuer. Inside a, contains the AID of the issuee.

ri (optional) Identifies a registry that tracks revocations that might include one for this credential.

s (required) Contains the SAID of a schema to which the associated ACDC conforms.

a (required) Contains additional attributes for this specific ACDC, as defined by its schema.

dt (optional) Contains the date when the issuer claims to have issued the ACDC. This data will correspond closely with a timestamp saved in the issuer's KEL, at the point where the signature on the ACDC was signed and anchored there. The ordering of the signature in the KEL, relative to other key state events, is what is definitive here; the timestamp itself should be viewed more as a hint.

e (optional) Contains edges (in the computer science data graph sense) that connect this ACDC to other data upon which it depends.

r (optional) Contains one or more rules that govern the use of the ACDC. Holding the credential requires a cryptographically nonrepudiable admit action with a wallet, and therefore proves that the holder agreed to these terms and conditions.