# 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](/glossary.md#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](/glossary.md#acdc). 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:

<pre class="language-json"><code class="lang-json">{
  "v":"ACDC10JSON0005c8_",
  "d":"EIiGTpV9qNIUeyF-vg7FI-E-LfJmwWzn1bDhgMMNggwm",
<strong>  "i":"ED88Jn6CnWpNbSYz6vp9DOSpJH2_Di5MSwWTf1l34JJm",
</strong>  "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
</code></pre>

### Fields

Schemas for ACDCs follow the [JSON Schema](https://json-schema.org/) 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:

&#x20;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.


---

# 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://ovc.provenant.net/cred-structure.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.