# KERIGlos Documentation
KERI Suite Glossary
> This file contains the complete documentation in a single file for LLM consumption.
> For a lightweight index, see https://weboftrust.github.io/WOT-terms/llms.txt
> For individual markdown files, download https://weboftrust.github.io/WOT-terms/markdown.zip
---
title: KERI Suite Glossary
description: This is the KERI Suite Glossary.
source_url:
html: https://weboftrust.github.io/WOT-terms/intro
md: https://weboftrust.github.io/WOT-terms/intro.md
---
# KERI Suite Glossary
This is the KERI Suite Glossary.
Also take a look at:
- [KERIDoc – Documentation](https://weboftrust.github.io/keridoc/)
- [KERISSE – Search engine](https://weboftrust.github.io/kerisse/)
---
title: KERI Suite Glossary
description: This is the KERI Suite Glossary.
source_url:
html: https://weboftrust.github.io/WOT-terms/_01_intro/intro
md: https://weboftrust.github.io/WOT-terms/_01_intro/intro.md
---
# KERI Suite Glossary
This is the KERI Suite Glossary.
Also take a look at:
- [KERIDoc – Documentation](https://weboftrust.github.io/keridoc/)
- [KERISSE – Search engine](https://weboftrust.github.io/kerisse/)
---
title: Indexed In KERISSE
source_url:
html: https://weboftrust.github.io/WOT-terms/_02_overview/indexed-in-KERISSE
md: https://weboftrust.github.io/WOT-terms/_02_overview/indexed-in-KERISSE.md
---
---
title: Overview And Context
source_url:
html: https://weboftrust.github.io/WOT-terms/_02_overview/overview-and-context
md: https://weboftrust.github.io/WOT-terms/_02_overview/overview-and-context.md
---
---
title: Backed And Backerless Issuance And Revocation
source_url:
html: https://weboftrust.github.io/WOT-terms/_03_visualisations/backed-and-backerless-issuance-and-revocation
md: https://weboftrust.github.io/WOT-terms/_03_visualisations/backed-and-backerless-issuance-and-revocation.md
---
---
title: Keri And Acdc Architecture
source_url:
html: https://weboftrust.github.io/WOT-terms/_03_visualisations/keri-and-acdc-architecture
md: https://weboftrust.github.io/WOT-terms/_03_visualisations/keri-and-acdc-architecture.md
---
---
title: Keria Service Architecture
source_url:
html: https://weboftrust.github.io/WOT-terms/_03_visualisations/keria-service-architecture
md: https://weboftrust.github.io/WOT-terms/_03_visualisations/keria-service-architecture.md
---
---
title: Repo Connections
source_url:
html: https://weboftrust.github.io/WOT-terms/_03_visualisations/repo-connections
md: https://weboftrust.github.io/WOT-terms/_03_visualisations/repo-connections.md
---
---
title: Various Visualisations From Slack
source_url:
html: https://weboftrust.github.io/WOT-terms/_03_visualisations/various-visualisations-from-slack
md: https://weboftrust.github.io/WOT-terms/_03_visualisations/various-visualisations-from-slack.md
---
---
title: All Images
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/all-images
md: https://weboftrust.github.io/WOT-terms/_05_resources/all-images.md
---
---
title: KERI Suite Glossary
description: This is the KERI Suite Glossary.
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/intro
md: https://weboftrust.github.io/WOT-terms/_05_resources/intro.md
---
# KERI Suite Glossary
This is the KERI Suite Glossary.
Also take a look at:
- [KERIDoc – Documentation](https://weboftrust.github.io/keridoc/)
- [KERISSE – Search engine](https://weboftrust.github.io/kerisse/)
---
title: Keri.One Labeled
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/keri.one-labeled
md: https://weboftrust.github.io/WOT-terms/_05_resources/keri.one-labeled.md
---
---
title: WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
description: 9286652585568, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-pfeairheller-cesr-proof
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-pfeairheller-cesr-proof.md
---
# WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
title: "CESR Proof Signatures" abbrev: "CESR-PROOF" docname: draft-pfeairheller-cesr-proof-latest category: info
ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
author:
- name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](mailto:Philip.Feairheller@gleif.org)
normative: ACDC: target: [https://datatracker.ietf.org/doc/draft-ssmith-acdc/](https://datatracker.ietf.org/doc/draft-ssmith-acdc/) title: Authentic Data Chained Containers author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021 CESR: target: [https://datatracker.ietf.org/doc/draft-ssmith-cesr/](https://datatracker.ietf.org/doc/draft-ssmith-cesr/) title: Composable Event Streaming Representation (CESR) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
SAID: target: [https://datatracker.ietf.org/doc/draft-ssmith-said/](https://datatracker.ietf.org/doc/draft-ssmith-said/) title: Self-Addressing IDentifier (SAID) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
informative: KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
RFC6901: target: [https://datatracker.ietf.org/doc/html/rfc6901](https://datatracker.ietf.org/doc/html/rfc6901) title: JavaScript Object Notation (JSON) Pointer author:
```
-
name: Paul C. Bryan
-
name: Kris Zyp
-
name: Mark Nottingham
date: 2003
```
JSONPath: target: [https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/](https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/) title: JSONPath - Query expressions for JSON author:
```
-
name: Stefan Gössner
-
name: Glyn Normington
-
name: Carsten Bormann
date: 2021-10-25
```
tags: IETF, CESR, SAID, KERI, ACDC
\--- abstract
CESR Proof Signatures are an extension to the Composable Event Streaming Representation \[CESR\] that provide transposable cryptographic signature attachments on self-addressing data (SAD) \[SAID\]. Any SAD, such as an Authentic Chained Data Container (ACDC) Verifiable Credential \[ACDC\] for example, may be signed with a CESR Proof Signature and streamed along with any other CESR content. In addition, a signed SAD can be embedded inside another SAD and the CESR proof signature attachment can be transposed across envelope boundaries and streamed without losing any cryptographic integrity.
\--- middle
Composable Event Streaming Representation (CESR) is a dual text-binary encoding format that has the unique property of text-binary concatenation composability. The CESR specification not only provides the definition of the streaming format but also the attachment codes needed for differentiating the types of cryptographic material (such as signatures) used as attachments on all event types for the Key Event Receipt Infrastructure (KERI) \[KERI\]. While all KERI event messages are self-addressing data (SAD), there is a broad class of SADs that are not KERI events but that require signature attachments. ACDC Verifiable credentials fit into this class of SADs. With more complex data structures represented as SADs, such as verifiable credentials, there is a need to provide signature attachments on nested subsets of SADs. Similar to indices in indexed controller signatures in KERI that specify the location of the public key they represent, nested SAD signatures need a path mechanism to specify the exact location of the nested content that they are signing. CESR Proof Signatures provide this mechanism with the CESR SAD Path Language and new CESR attachment codes, detailed in this specification.
A primary goal of CESR Proof Signatures is to allow any signed self-addressing data (SAD) to be streamed inline with any other CESR content. In support of that goal, CESR Proof Signatures leverage CESR attachments to define a signature scheme that can be attached to any SAD content serialized as JSON \[JSON\], MessagePack \[MGPK\] or CBOR \[CBOR\]. Using this capability, SADs signed with CESR Proof Signatures can be streamed inline in either the text (T) or binary (B) domain alongside any other KERI event message over, for example TCP or UDP. In addition, signed SADs can be transported via HTTP as a CESR HTTP Request (todo: reference needed).
CESR Proof Signatures can be used to sign as many portions of a SAD as needed, including the entire SAD. The signed subsets are either SADs themselves or the self-addressing identifer (SAID) of a SAD that will be provided out of band. A new CESR count code is included with this specification to allow for multiple signatures on nested portions of a SAD to be grouped together under one attachment. By including a SAD Path in the new CESR attachment for grouping signatures, the entire group of signatures can be transposed across envelope boundaries by changing only the root path of the group attachment code.
There are several events in KERI that can contain context specific embedded self-addressing data (SADs). Exchange events (`exn`) for peer-to-peer communication and Replay events (`rpy`) for responding to data requests as well as Expose events (`exp`) for providing anchored data are all examples of KERI events that contain embedded SADs as part of their payload. If the SAD payload for one of these event types is signed with a CESR attachment, the resulting structure is not embeddable in one of the serializations of map or dictionary like data models. (JSON, CBOR, MessagePack) supported by CESR. To solve this problem, CESR Proof Signatures are transposable across envelope boundaries in that a single SAD signature or an entire signature group on any given SAD can be transposed to attach to the end of an enveloping SAD without losing its meaning. This unique feature is provided by the SAD Path language used in either a SAD signature or the root path designation in the outermost attachment code of any SAD signature group. These paths can be updated to point to the embedded location of the signed SAD inside the envelope. Protocols for verifiable credential issuance and proof presentation can be defined using this capability to embed the same verifiable credential SAD at and location in an enveloping `exn` message as appropriate for the protocol without having to define a unique signature scheme for each protocol.
CESR Proof Signatures defines a SAD Path Language to be used in signature attachments for specifying the location of the SAD content within the signed SAD that a signature attachment is verifying. This path language has a more limited scope than alternatives like JSONPtr \[RFC6901\] or JSONPath \[JSONPath\] and is therefore simpler and more compact when encoding in CESR signature attachments. SADs in CESR and therefore CESR Proof Signatures require static field ordering of all maps. The SAD path language takes advantage of this feature to allow for a Base64 compatible syntax into SADs even when a SAD uses non-Base64 compatible characters for field labels.
The SAD path language contains a single reserved character, the `-` (dash) character. Similar to the `/` (forward slack) character in URLs, the `-` in the SAD Path Language is the path separator between components of the path. The `-` was selected because it is a one of the valid Base64 characters.
The simplest path in the SAD Path Language is a single `-` character representing the root path which specifies the top level of the SAD content.
Root Path
```
-
```
After the root path, path components follow, delimited by the `-` character. Path components may be integer indices into field labels or arrays or may be full field labels. No wildcards are supported by the SAD Path Language.
An example SAD Path using only labels that resolve to map contexts follows:
```
-a-personal
```
In addition, integers can be specified and their meaning is dependent on the context of the SAD.
```
-1-12-personal-0
```
The rules for a SAD Path Language processor are simple. If a path consists of only a single `-`, it represents the root of the SAD and therefore the entire SAD content. Following any `-` character is a path component that points to a field if the current context is a map in the SAD or is an index of an element if the current context is an array. It is an error for any sub-path to resolve to a value this is not a map or an array. Any trailing `-` character in a SAD Path can be ignored.
The root context (after the initial `-`) is always a map. Therefore, the first path component represents a field of that map. The SAD is traversed following the path components as field labels or indexes in arrays until the end of the path is reached. The value at the end of the path is then returned as the resolution of the SAD Path. If the current context is a map and the path component is an integer, the path component represents an index into fields of the map. This feature takes advantage of the static field ordering of SADs and is used against any SAD that contains field labels that use non-Base64 compatible characters or the `-` character. Any combination of integer and field label path components can be used when the current context is a map. All path components MUST be an integer when the current context is an array.
SAD Paths are variable raw size primitives that require CESR variable size codes. We will use the `A` small variable size code for SAD Paths which has 3 code entries being added to the Master Code Table, `4A##`, `5A##` and `6A##` for SAD Paths with 0 lead bytes, 1 lead byte and 2 lead bytes respecively. This small variable size code is reserved for text values that only contain valid Base64 characters. These codes are detailed in Table 2 below. The selector not only encodes the table but also implicitly encodes the number of lead bytes. The variable size is measured in quadlets of 4 characters each in the T domain and equivalently in triplets of 3 bytes each in the B domain. Thus computing the number of characters when parsing or off-loading in the T domain means multiplying the variable size by 4. Computing the number of bytes when parsing or off-loading in the B domain means multiplying the variable size by 3. The two Base64 size characters provide value lengths in quadlets/triplets from 0 to 4095 (64\*_2 -1). This corresponds to path lengths of up to 16,380 characters (4095_ 4) or 12,285 bytes (4095 \* 3).
This section provides some more examples for SAD Path expressions. The examples are based on Authentic Chained Data Containers (ACDCs) representing verifiable credentials.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"home-city": "Durham"
}
},
"p": [
{
"qualifiedIssuerCredential": {
"d": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"i": "Et2DOOu4ivLsjpv89vgv6auPntSLx4CvOhGUxMhxPS24"
}
},
{
"certifiedLender": {
"d": "EglG9JLG6UhkLrrv012NPuLEc1F3ne5vPH_sHGP_QPN0",
"i": "E8YrUcVIqrMtDJHMHDde7LHsrBOpvN38PLKe_JCDzVrA"
}
}
]
}
```
Figure 1. Example ACDC Credential SAD
The examples in Table 1 represent all the features of the SAD Path language when referring to the SAD in Figure 1. along with the CESR text encoding.
| SAD Path | Result | CESR T Domain Encoding |
| --- | --- | --- |
| \- | The root of the SAD | 6AABAAA- |
| \-a-personal | The personal map of the a field | 4AADA-a-personal |
| \-4-5 | The personal map of the a field | 4AAB-4-5 |
| \-4-5-legalName | "John Doe" | 5AAEAA-4-5-legalName |
| \-a-personal-1 | "Durham" | 6AAEAAA-a-personal-1 |
| \-p-1 | The second element in the p array | 4AAB-p-1 |
| \-a-LEI | "254900OPPU84GM83MG36" | 5AACAA-a-LEI |
| \-p-0-0-d | "EIl3MORH...6DZA" | 4AAC-p-0-0-d |
| \-p-0-certifiedLender-i | "E8YrUcVI...zVrA" | 5AAGAA-p-0-certifiedLender-i |
The SAD Path language was chosen over alternatives such as JSONPtr and JSONPath in order to create a more compact representation of a pathing language in the text domain. Many of the features of the alternatives are not needed for CESR Proof Signatures. The only token in the language (`-`) is Base64 compatible. The use of field indices in SADs (which require staticly ordered fields) allows for Base64 compatible pathing even when the field labels of the target SAD are not Base64 compatible. The language accomplishes the goal of uniquely locating any path in a SAD using minimally sufficient means in a manner that allows it to be embedded in a CESR attachment as Base64. Alternative syntaxes would need to be Base64 encoded to be used in a CESR attachment in the text domain thus incurring the additional bandwidth cost of such an encoding.
This specification adds 2 _Counter Four Character Codes_ to the Master Code Table and uses 1 _Small Variable Raw Size Code Type_ and 1 _Large Variable Raw Size Code Type_ from the Master Code Table (each of which have 3 code entries).
The SAD Path Signature counter code is represented by the four character code `-J##`. The first two characters reserve this code for attaching the couplet (SAD Path, Signature Group). The second two characters represent the count in hexidecimal of SAD path signatures are in this attachment. The path is attached in the T domain using the codes described in the next section. The signature group is from either a transferable identifier or a non-transferable identifier and therefore attached using the CESR codes `-F##` or `-C##` respectively as described in the CESR Specification \[CESR\].
The code `A` is reserved as a Small Variable Raw Size Code and `AAA` as a Large Variable Raw Size Code for Base64 URL safe strings. SAD Paths are Base64 URL safe strings and so leverage these codes when encoded in the CESR T domain. To account for the variable nature of path strings, the variable size types reserve 3 codes each with prefix indicators of lead byte size used for adjusting the T domain encoding to multiples of 4 characters and the B domain to multiples of 3 bytes. For the _Small_ codes the prefix indicators are `4`, `5` and `6` representing 0, 1 and 2 lead bytes respectively and for _Large_ codes the prefix indicators are `7`, `8`, and `9` representing 0, 1 and 2 lead bytes respectively. The resulting 6 code entries are displayed in the table that follows.
The additions to the Master Code Table of CESR is shown below:
| Code | Description | Code Length | Count or Index Length | Total Length |
| --- | --- | --- | --- | --- |
| | **Counter Four Character Codes** | | | |
| \-J## | Count of attached qualified Base64 SAD path sig groups path+sig group (trans or non-trans) | 2 | 2 | 4 |
| \-K## | Count of attached qualified Base64 SAD Path groups | 2 | 2 | 4 |
| | **Small Variable Raw Size Code** | | | |
| 4A## | String Base64 Only with 0 Lead Bytes | 2 | 2 | 4 |
| 5A## | String Base64 Only with 1 Lead Byte | 2 | 2 | 4 |
| 6A## | String Base64 Only with 2 Lead Bytes | 2 | 2 | 4 |
| | **Large Variable Raw Size Code** | | | |
| 7AAA#### | String Base64 Only with 0 Lead Bytes | 4 | 4 | 8 |
| 8AAA#### | String Base64 Only with 1 Lead Byte | 4 | 4 | 8 |
| 9AAA#### | String Base64 Only with 2 Lead Bytes | 4 | 4 | 8 |
CESR defines several counter codes for attaching signatures to serialized CESR event messages. For KERI event messages, the signatures in the attachments apply to the entire serialized content of the KERI event message. As all KERI event messages are SADs, the same rules for signing a KERI event message applies to signing SADs for CESR Proof Signatures. A brief review of CESR signatures for transferable and non-transferable identifiers follows. In addition, signatures on nested content must be specified.
Signatures on SAD content require signing the serialized encoding format of the data ensuring that the signature applies to the data over the wire. The serialization for any SAD is identified in the version string which can be found in the `v` field of any KERI event message or ACDC credential. An example version string follows:
```
{
"v": "KERI10JSON00011c_"
}
```
where KERI is the identifier of KERI events followed by the hexidecimal major and minor version code and then the serialized encoding format of the event, JSON in this case. KERI and ACDC support JSON, MessagePack and CBOR currently. Field ordering is important when apply cryptographic signatures and all serialized encoding formats must support static field ordering. Serializing a SAD starts with reading the version string from the SAD field (`v` for KERI and ACDC events message) to determine the serialized encoding format of the message. The serialized encoding format is used to generate the SAID at creation and can not be changed. The event map is serialized using a library that ensures the static field order perserved across serialization and deserialization and the private keys are used to generate the qualified cryptographic material that represents the signatures over the SAD content.
The same serialized encoding format must be used when nesting a SAD in another SAD. For example, an ACDC credential that was issued using JSON can only be embedded and presented in a KERI `exn` presentation event message that uses JSON as its serialized encoding format. That same credential can not be transmitted using CBOR or MessagePack. Controllers can rely on this restriction when verifying signatures of embedded SADs. When processing the signature attachments and resolving the data at a given SAD path, the serialization of the outter most SAD can be used at any depth of the traversal. New verison string processing does not need to occur at nested paths. However, if credential signature verification is pipelined and processed in parallel to the event message such that the event message is not avaiable, the version string of the nested SAD will still be valid and can be used if needed.
Each attached signature is accompanied by a SAD Path that indicates the content that is signed. The path must resolve within the enveloping SAD to either a nested SAD (map) or a SAID (string) of an externally provided SAD. This of course, includes a root path that resolves to the enveloping SAD itself.
Non-transferable identifiers only ever have one public key. In addition, the identifier prefix is identical to the qualified cryptographic material of the public key and therefore no KEL is required to validate the signature of a non-transferable identifier \[KERI\]. The attachment code for witness receipt couplets, used for CESR Proof Signatures, takes this into account. The four character couner code `-C##` is used for non-transferable identifiers and contains the signing identfier prefix and the signature \[CESR\]. Since the verification key can be extracted from the identifier prefix and the identifier can not be rotated, all that is required to validate the signature is the identifier prefix, the data signed and the signature.
Transferable identifiers require full KEL resolution and verfication to determine the correct public key used to sign some content \[KERI\]. In addition, the attachment code used for transferable identifiers, `-F##` must specify the location in the KEL at which point the signature was generated \[CESR\]. To accomplish this, this counter code includes the identifier prefix, the sequence number of the event in the KEL, the digest of the event in the KEL and the indexed signatures (transferable identifiers support multiple public/private keys and require index signatures). Using all the values, one can verify the signature(s) by retrieving the KEL of the identifier prefix and determine the key state at the sequence number along with validating the digest of the event against the actual event. Then using the key(s) at the determined key state, validate the signature(s).
This specification adds two Counter Four Character Codes to the CESR Master Code Table for attaching and grouping transposable signatures on SAD and nested SAD content. The first code (`-J##`) is reserved for attaching a SAD path and the associated signatures on the content at the resolution of the SAD Path (either a SAD or its associated SAID). The second reserved code (`-K##`) is for grouping all SAD Path signature groups under a root path for a given SAD. The root path in the second grouping code provides signature attachment transposability for embedding SAD content in other messages.
The SAD Path Signature Group provides a four character counter code, `-J##`, for attaching an encoded variable length SAD Path along with either a transferable index signature group or non-transferable identifer receipt couplets. The SAD Path identifies the content that this attachment is signing. The path must resolve to either a nested SAD (map) or a SAID (string) of an externally provided SAD within the context of the SAD and root path against which this attachment is applied. Using the following ACDC SAD embedded in a KERI `exn` message:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00",
"r": "/credential/offer",
"a": {
"credential": { // SIGNATURE TARGET OF TRANSPOSED SAD PATH GROUP
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"home": "Durham"
}
}
}
}
}
```
the following signature applies to the nested `credential` SAD signed by a transferable identifier using the transferable index signature group. The example is annotated with spaces and line feeds for clarity and an accompanied table is provided with comments.
```
-JAB
6AAEAAA-a-credential
-FAB
E_T2_p83_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y
-EAB0AAAAAAAAAAAAAAAAAAAAAAB
EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM
-AAD
AA5267UlFg1jHee4Dauht77SzGl8WUC_0oimYG5If3SdIOSzWM8Qs9SFajAilQcozXJVnbkY5stG_K4NbKdNB4AQ
ABBgeqntZW3Gu4HL0h3odYz6LaZ_SMfmITL-Btoq_7OZFe3L16jmOe49Ur108wH7mnBaq2E_0U0N0c5vgrJtDpAQ
ACTD7NDX93ZGTkZBBuSeSGsAQ7u0hngpNTZTK_Um7rUZGnLRNJvo5oOnnC1J2iBQHuxoq8PyjdT3BHS2LiPrs2Cg
```
| code | description |
| --- | --- |
| \-JAB | SAD path signature group counter code 1 following the group |
| 6AAEAAA-a-credential | encoded SAD path designation |
| \-FAB | Trans Indexed Sig Groups counter code 1 following group |
| E\_T2\_p83\_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y | trans prefix of signer for sigs |
| \-EAB0AAAAAAAAAAAAAAAAAAAAAAB | sequence number of est event of signer's public keys for sigs |
| EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM | digest of est event of signer's public keys for sigs |
| \-AAD | Controller Indexed Sigs counter code 3 following sigs |
| AA5267...4AQ | sig 0 |
| ABBgeq...pAQ | sig 1 |
| ACTD7N...2Cg | sig 2 |
The next example demostrates the use of a non-transferable identifier to sign SAD content. In this example, the entire nested SAD located at the `a` field is signed by the non-transferable identfier:
```
-JAB
5AABAA-a
-CAB
BmMfUwIOywRkyc5GyQXfgDA4UOAMvjvnXcaK9G939ArM
0BT7b5PzUBmts-lblgOBzdThIQjKCbq8gMinhymgr4_dD0JyfN6CjZhsOqqUYFmRhABQ-vPywggLATxBDnqQ3aBg
```
| code | description |
| --- | --- |
| \-JAB | SAD path signature group counter code 1 following the group |
| 5AABAA-a | encoded SAD path designation |
| \-CAB | NonTrans witness receipt couplet |
| BmMfUwIOywRkyc5GyQXfgDA4UOAMvjvnXcaK9G939ArM | non-trans prefix of signer of sig |
| 0BT7b5... aBg | sig |
The SAD Path Group provides a four character counter code, `-K##`, for attaching encoded variable length **root** SAD Path along with 1 or more SAD Path Signature Groups. The root SAD Path identifies the root context against which the paths in all included SAD Path Signature Groups are resolved. When parsing a SAD Path Group, if the root path is the single `-` character, all SAD paths are treated as absolute paths. Otherwise, the root path is prepended to the SAD paths in each of the SAD Path Signature Groups. Given the following snippet of a SAD Path Group:
```
-KAB6AABAAA--JAB5AABAA-a...
```
The root path is the single `-` character meaning that all subsequent SAD Paths are absolute and therefore the first path is resolved as the `a` field of the root map of the SAD as seen in the following example:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"city": "Durham"
}
}
}
```
To support nesting of signed SAD content in other SAD content the root path of SAD Path Groups or the path of a SAD Path Signature Group provides transposability of CESR SAD signatures such that a single SAD Path Signature Group or an entire SAD Path Group attachment can be transposed across envelope boundaries by updating the single path or root path to indicate the new location. Extending the example above, the SAD content is now embedded in a KERI `exn` event message as follows:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00"
"r": "/credential/offer"
"a": {
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF TRANSPOSED SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"city": "Durham"
}
}
}
}
```
The same signature gets transposed to the outer `exn` SAD by updating the root path of the `-K##` attachment:
```
-KAB5AABAA-a-JAB5AABAA-a...
```
Now the SAD Path of the first signed SAD content resolves to the `a` field of the `a` field of the streamed `exn` message
The small variable raw side code reserved for SAD Path encoding is `A` which results in the addition of 3 entries (`4A##`, `5A##` and `6A##`) in the Master Code Table for each lead byte configuration. These codes and their use are discussed in detail in CESR Encoding for SAD Path Language.
Additional signatures on nested content can be included in a SAD Path Group and are applied to the serialized data at the resolution of a SAD path in a SAD. Signatures can be applied to the SAID or an entire nested SAD. When verifying a CESR Proof Signature, the content at the resolution of the SAD path is the data that was signed. The choice to sign a SAID or the full SAD effects how the data may be used in presentations and the rules for verifying the signature.
When signing nested SAD content, the serialization used at the time of signing is the only serialization that can be used when presenting the signed data. When transposing the signatures and nesting the signed data, the enveloping SAD must use the same serialization that was used to create the signatures. This is to ensure that all signatures apply to the data over the wire and not a transformation of that data. The serialization can be determined from the version field (`v`) of the nested SAD or any parent of the nested SAD as they are guaranteed to be identical. Consider the following ACDC Credential SAD:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"first": "John",
"last": "Doe"
}
}
}
```
To sign the SAD located at the path `-a`, JSON serialization would be used because the SAD at that path does not have a version field so the version field of its parent is used. The serialization rules (spacing, field ordering, etc) for a SAD would be used for the SAD and the serialization encoding format and the signature would be applied to the bytes of the JSON for that map. Any presentation of the signed data must always include the fully nested SAD. The only valid nesting of this credential would be as follows:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00"
"r": "/credential/apply"
"a": {
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // FULL SAD MUST BE PRESENT
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"first": "John",
"last": "Doe"
}
}
}
}
```
Applying signatures to a SAD with SAIDs in place of fully expanded nested SAD content enables compact credentials for domains with bandwidth restrictions such as IoT. Consider the following fully expanded credential:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"n": "sKHtYSiCdlibuLDS2PTJg1AZXtPhaySZ9O3DoKrRXWY",
"first": "John
"middle": "William"
"last": "Doe"
},
"address": {
"d": "E-0luqYSg6cPcMFmhiAz8VBQObZLmTQPrgsr7Z1j6CA4",
"n": "XiSoVDNvqV8ldofPyTVqQ-EtVPlkIIQTln9Ai0yI05M",
"street": "123 Main St",
"city": "Salt Lake City",
"state": "Utah",
"zipcode": "84157"
},
"phone": {
"d": "E6lty8H2sA_1acq8zg89_kqF194DbF1cDpwA7UPtwjPQ",
"n": "_XKNVntbcIjp12DmsAGhv-R7JRwuzjD6KCHC7Fw3zvU"
"mobile": "555-121-3434",
"home": "555-121-3435",
"work": "555-121-3436",
"fax": "555-121-3437"
}
}
}
}
```
The three nested blocks of the `a` block `legalName`, `address` and `phone` are SADs with a SAID in the `d` field and are candidates for SAID replacement in an issued credential. A compact credential can be created and signed by replacing those three nested blocks with the SAID of each nested SAD. The schema for this verifiable credential would need to specify conditional subschema for the field labels at each nesting location that requires the full schema of the nested SAD or a string for the SAID. The commitment to a SAID in place of a SAD contains nearly the same cryptographic integrity as a commitment to the SAD itself since the SAID is the qualified cryptographic material of a digest of the SAD. The same credential could be converted to a compact credential containing the SAIDs of each nested block and signed as follows:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"address": "E-0luqYSg6cPcMFmhiAz8VBQObZLmTQPrgsr7Z1j6CA4",
"phone": "E6lty8H2sA_1acq8zg89_kqF194DbF1cDpwA7UPtwjPQ"
}
}
```
It is important to note that if this version of the credential is the one issued to the holder and the signature over the entire credential is on the serialized data of this version of the credential it is the only version that can be presented. The full SAD data of the three nested blocks would be delivered out of band from the signed credential. The top level schema would describe the blocks with conditional subschema for each section. The credential signature becomes a cryptographic commitment to the contents of the overall credential as well as the content of each of the blocks and will still validate the presented credential with significantly less bandwidth.
With this approach, credential presentation request and exchange protocols can be created that modify the schema with the conditional subschema, removing the conditions that allow for SAIDs in place of the required (or presented) nested blocks. The modified schema can be used in such a protocol to indicate the required sections to be delivered out of bounds or as a commitment to provide the nested blocks after the crendential presentation has occurred.
{::boilerplate bcp14-tagged}
TODO Security
The Internet Assigned Numbers Authority (IANA) is a standards organization that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Internet Protocol-related symbols and Internet numbers.
This document has no IANA actions.
\--- back
{:numbered="false"}
Dr Sam Smith, Kevin Griffin and the Global Legal Entity Identifier Foundation (GLEIF)
---
title: Draft Pfeairheller Did Keri
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-pfeairheller-did-keri
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-pfeairheller-did-keri.md
---
---
title: Draft Pfeairheller Ptel
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-pfeairheller-ptel
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-pfeairheller-ptel.md
---
---
title: WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
description: 4171595971390, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-acdc
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-acdc.md
---
# WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
title: "Authentic Chained Data Containers (ACDC)" abbrev: "ACDC" category: info
docname: draft-ssmith-acdc-latest
ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
author:
- name: S. Smith organization: ProSapien LLC email: [sam@prosapien.com](mailto:sam@prosapien.com)
normative:
ACDC\_ID: target: [https://github.com/trustoverip/tswg-acdc-specification](https://github.com/trustoverip/tswg-acdc-specification) title: IETF ACDC (Authentic Chained Data Containers) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
KERI\_ID: target: [https://github.com/WebOfTrust/ietf-keri](https://github.com/WebOfTrust/ietf-keri) title: IETF KERI (Key Event Receipt Infrastructure) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
CESR\_ID: target: [https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr) title: IETF CESR (Composable Event Streaming Representation) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
SAID\_ID: target: [https://github.com/WebOfTrust/ietf-said](https://github.com/WebOfTrust/ietf-said) title: IETF SAID (Self-Addressing IDentifier) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
OOBI\_ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF OOBI (Out-Of-Band-Introduction) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
PTEL\_ID: target: [https://github.com/WebOfTrust/ietf-ptel](https://github.com/WebOfTrust/ietf-ptel) title: IETF PTEL (Public Transaction Event Log) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
Proof\_ID: target: [https://github.com/WebOfTrust/ietf-cesr-proof](https://github.com/WebOfTrust/ietf-cesr-proof) title: IETF CESR-Proof Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
IPEX\_ID: target: [https://github.com/WebOfTrust/ietf-ipex](https://github.com/WebOfTrust/ietf-ipex) title: IPEX (Issuance and Presentation EXchange) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
DIDK\_ID: target: [https://github.com/WebOfTrust/ietf-did-keri](https://github.com/WebOfTrust/ietf-did-keri) title: IETF DID-KERI Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
RFC6901: target: [https://datatracker.ietf.org/doc/html/rfc6901](https://datatracker.ietf.org/doc/html/rfc6901) title: JavaScript Object Notation (JSON) Pointer author:
```
-
name: Paul C. Bryan
-
name: Kris Zyp
-
name: Mark Nottingham
date: 2003
```
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
RFC8259: target: [https://datatracker.ietf.org/doc/html/rfc8259](https://datatracker.ietf.org/doc/html/rfc8259) title: JSON (JavaScript Object Notation)
RFC4627: target: [https://datatracker.ietf.org/doc/rfc4627/](https://datatracker.ietf.org/doc/rfc4627/) title: The application/json Media Type for JavaScript Object Notation (JSON)
JSch: target: [https://json-schema.org](https://json-schema.org) title: JSON Schema
JSch\_202012: target: [https://json-schema.org/draft/2020-12/release-notes.html](https://json-schema.org/draft/2020-12/release-notes.html) title: "JSON Schema 2020-12"
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
RFC3986: target: [https://datatracker.ietf.org/doc/html/rfc3986](https://datatracker.ietf.org/doc/html/rfc3986) title: "Uniform Resource Identifier (URI): Generic Syntax"
RFC8820: target: [https://datatracker.ietf.org/doc/html/rfc8820](https://datatracker.ietf.org/doc/html/rfc8820) title: URI Design and Ownership
informative:
ACDC\_WP: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf) title: Authentic Chained Data Containers (ACDC) White Paper
VCEnh: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC\_Enhancement\_Strategy.md](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC_Enhancement_Strategy.md) title: VC Spec Enhancement Strategy Proposal
ACDC\_TF: target: [https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force](https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force) title: ACDC (Authentic Chained Data Container) Task Force
TOIP: target: [https://trustoverip.org](https://trustoverip.org) title: Trust Over IP (ToIP) Foundation
IETF: target: [https://www.ietf.org](https://www.ietf.org) title: IETF (Internet Engineering Task Force
KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
ITPS: target: [https://en.wikipedia.org/wiki/Information-theoretic\_security](https://en.wikipedia.org/wiki/Information-theoretic_security) title: Information-Theoretic and Perfect Security
OTP: target: [https://en.wikipedia.org/wiki/One-time\_pad](https://en.wikipedia.org/wiki/One-time_pad) title: One-Time-Pad
VCphr: target: [https://www.ciphermachinesandcryptology.com/en/onetimepad.htm](https://www.ciphermachinesandcryptology.com/en/onetimepad.htm) title: Vernom Cipher (OTP)
SSplt: target: [https://www.ciphermachinesandcryptology.com/en/secretsplitting.htm](https://www.ciphermachinesandcryptology.com/en/secretsplitting.htm) title: Secret Splitting
SShr: target: [https://en.wikipedia.org/wiki/Secret\_sharing](https://en.wikipedia.org/wiki/Secret_sharing) title: Secret Sharing
CSPRNG: target: [https://en.wikipedia.org/wiki/Cryptographically-secure\_pseudorandom\_number\_generator](https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator) title: Cryptographically-secure pseudorandom number generator (CSPRNG)
IThry: target: [https://en.wikipedia.org/wiki/Information\_theory](https://en.wikipedia.org/wiki/Information_theory) title: Information Theory
CAcc: target: [https://en.wikipedia.org/wiki/Accumulator\_(cryptography)](https://en.wikipedia.org/wiki/Accumulator_\(cryptography\)) title: Cryptographic Accumulator
XORA: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/XORA.md](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/XORA.md) title: XORA (XORed Accumulator)
GLEIF: target: [https://www.gleif.org/en/](https://www.gleif.org/en/) title: GLEIF (Global Legal Entity Identifier Foundation)
vLEI: target: [https://github.com/WebOfTrust/vLEI](https://github.com/WebOfTrust/vLEI) title: vLEI (verifiable Legal Entity Identifier) Definition
GLEIF\_vLEI: target: [https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei](https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei) title: GLEIF vLEI (verifiable Legal Entity Identifier)
GLEIF\_KERI: target: [https://github.com/WebOfTrust/vLEI](https://github.com/WebOfTrust/vLEI) title: GLEIF with KERI Architecture
W3C\_VC: target: [https://www.w3.org/TR/vc-data-model/](https://www.w3.org/TR/vc-data-model/) title: W3C Verifiable Credentials Data Model v1.1
W3C\_DID: target: [https://w3c-ccg.github.io/did-spec/](https://w3c-ccg.github.io/did-spec/) title: W3C Decentralized Identifiers (DIDs) v1.0
Salt: target: [https://medium.com/@fridakahsas/salt-nonces-and-ivs-whats-the-difference-d7a44724a447](https://medium.com/@fridakahsas/salt-nonces-and-ivs-whats-the-difference-d7a44724a447) title: Salts, Nonces, and Initial Values
RB: target: [https://en.wikipedia.org/wiki/Rainbow\_table](https://en.wikipedia.org/wiki/Rainbow_table) title: Rainbow Table
DRB: target: [https://www.commonlounge.com/discussion/2ee3f431a19e4deabe4aa30b43710aa7](https://www.commonlounge.com/discussion/2ee3f431a19e4deabe4aa30b43710aa7) title: Dictionary Attacks, Rainbow Table Attacks and how Password Salting defends against them
BDay: target: [https://en.wikipedia.org/wiki/Birthday\_attack](https://en.wikipedia.org/wiki/Birthday_attack) title: Birthday Attack
BDC: target: [https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/](https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/) title: Birthday Attacks, Collisions, And Password Strength
HCR: target: [https://en.wikipedia.org/wiki/Collision\_resistance](https://en.wikipedia.org/wiki/Collision_resistance) title: Hash Collision Resistance
QCHC: target: [https://cr.yp.to/hash/collisioncost-20090823.pdf](https://cr.yp.to/hash/collisioncost-20090823.pdf) title: "Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete?"
EdSC: target: [https://eprint.iacr.org/2020/823](https://eprint.iacr.org/2020/823) title: "The Provable Security of Ed25519: Theory and Practice Report"
PSEd: target: [https://ieeexplore.ieee.org/document/9519456?denied=](https://ieeexplore.ieee.org/document/9519456?denied=) title: "The Provable Security of Ed25519: Theory and Practice" seriesinfo: 2021 IEEE Symposium on Security and Privacy (SP) author:
```
-
ins: J. Brendel
name: Jacqueline Brendel
-
ins: C. Cremers
name: Cas Cremers
-
ins: D. Jackson
name: Dennis Jackson
-
ins: M. Zhao
name: Mang Zhao
date: 2021-05-24
```
TMEd: target: [https://eprint.iacr.org/2020/1244.pdf](https://eprint.iacr.org/2020/1244.pdf) title: Taming the many EdDSAs
JSchCp: target: "[https://json-schema.org/understanding-json-schema/reference/combining.html"](https://json-schema.org/understanding-json-schema/reference/combining.html%22) title: "Schema Composition in JSON Schema"
JSchRE: target: "[https://json-schema.org/understanding-json-schema/reference/regular\_expressions.html"](https://json-schema.org/understanding-json-schema/reference/regular_expressions.html%22) title: "Regular Expressions in JSON Schema"
JSchId: target: "[https://json-schema.org/understanding-json-schema/structuring.html#schema-identification"](https://json-schema.org/understanding-json-schema/structuring.html#schema-identification%22) title: "JSON Schema Identification"
JSchCx: target: "[https://json-schema.org/understanding-json-schema/structuring.html#base-uri"](https://json-schema.org/understanding-json-schema/structuring.html#base-uri%22) title: "Complex JSON Schema Structuring"
RC: target: [https://en.wikipedia.org/wiki/Ricardian\_contract](https://en.wikipedia.org/wiki/Ricardian_contract) title: Ricardian Contract
CLC: target: [https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=2045818](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818) title: "Chain-Link Confidentiality"
DHKE: target: [https://www.infoworld.com/article/3647751/understand-diffie-hellman-key-exchange.html](https://www.infoworld.com/article/3647751/understand-diffie-hellman-key-exchange.html) title: "Diffie-Hellman Key Exchange"
KeyEx: target: [https://libsodium.gitbook.io/doc/key\_exchange](https://libsodium.gitbook.io/doc/key_exchange) title: Key Exchange
IDSys: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf) title: Identity System Essentials
Hash: target: [https://en.wikipedia.org/wiki/Cryptographic\_hash\_function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) title: Cryptographic Hash Function
Mrkl: target: [https://en.wikipedia.org/wiki/Merkle\_tree](https://en.wikipedia.org/wiki/Merkle_tree) title: Merkle Tree
TwoPI: target: [https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/](https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/) title: Second Pre-image Attack on Merkle Trees
MTSec: target: [https://blog.enuma.io/update/2019/06/10/merkle-trees-not-that-simple.html](https://blog.enuma.io/update/2019/06/10/merkle-trees-not-that-simple.html) title: Merkle Tree Security
DSig: target: [https://en.wikipedia.org/wiki/Digital\_signature](https://en.wikipedia.org/wiki/Digital_signature) title: Digital Signature
Level: target: [https://en.wikipedia.org/wiki/Security\_level](https://en.wikipedia.org/wiki/Security_level) title: Security Level
Twin: target: [https://en.wikipedia.org/wiki/Digital\_twin](https://en.wikipedia.org/wiki/Digital_twin) title: Digital Twin
TMal: target: [https://en.wikipedia.org/wiki/Transaction\_malleability\_problem](https://en.wikipedia.org/wiki/Transaction_malleability_problem) title: Transaction Malleability
PGM: target: [http://ceur-ws.org/Vol-2100/paper26.pdf](http://ceur-ws.org/Vol-2100/paper26.pdf) title: The Property Graph Database Model author: ins: R. Angles name: Renzo Angles date: 2018
Dots: target: [https://arxiv.org/pdf/1006.2361.pdf](https://arxiv.org/pdf/1006.2361.pdf) title: Constructions from Dots and Lines author:
```
-
ins: M. Rodriguez
name: Marko A. Rodriguez
-
ins: P. Neubauer
name: Peter Neubauer
date: 2010
```
KG: target: [https://arxiv.org/pdf/2003.02320.pdf](https://arxiv.org/pdf/2003.02320.pdf) title: Knowledge Graphs
Abuse: target: [https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md](https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md) title: Alice Attempts to Abuse a Verifiable Credential
SKEM: target: [https://eprint.iacr.org/2021/509](https://eprint.iacr.org/2021/509) title: On using the same key pair for Ed25519 and an X25519 based KEM
tags: "IETF, ACDC, CESR, SAID, KERI"
\--- abstract
An authentic chained data container (ACDC) {{ACDC\_ID}}{{ACDC\_WP}}{{VCEnh}} is an IETF {{IETF}} internet draft focused specification being incubated at the ToIP (Trust over IP) foundation {{TOIP}}{{ACDC\_TF}}. An ACDC is a variant of the W3C Verifiable Credential (VC) specification {{W3C\_VC}}. The W3C VC specification depends on the W3C DID (Decentralized IDentifier) specification {{W3C\_DID}}. A major use case for the ACDC specification is to provide GLEIF vLEIs (verifiable Legal Entity Identifiers) {{vLEI}}{{GLEIF\_vLEI}}{{GLEIF\_KERI}}. GLEIF is the Global Legal Entity Identifier Foundation {{GLEIF}}. ACDCs are dependent on a suite of related IETF focused standards associated with the KERI (Key Event Receipt Infrastructure) {{KERI\_ID}}{{KERI}} specification. These include CESR {{CESR\_ID}}, SAID {{SAID\_ID}}, PTEL {{PTEL\_ID}}, CESR-Proof {{Proof\_ID}}, IPEX {{IPEX\_ID}}, did:keri {{DIDK\_ID}}, and OOBI {{OOBI\_ID}}. Some of the major distinguishing features of ACDCs include normative support for chaining, use of composable JSON Schema {{JSch}}{{JSchCp}}, multiple serialization formats, namely, JSON {{JSON}}{{RFC4627}}, CBOR {{CBOR}}{{RFC8949}}, MGPK {{MGPK}}, and CESR {{CESR\_ID}}, support for Ricardian contracts {{RC}}, support for chain-link confidentiality {{CLC}}, a well defined security model derived from KERI {{KERI}}{{KERI\_ID}}, _compact_ formats for resource constrained applications, simple _partial disclosure_ mechanisms and simple _selective disclosure_ mechanisms. ACDCs provision data using a synergy of provenance, protection, and performance.
\--- middle
One primary purpose of the ACDC protocol is to provide granular provenanced proof-of-authorship (authenticity) of their contained data via a tree or chain of linked ACDCs (technically a directed acyclic graph or DAG). Similar to the concept of a chain-of-custody, ACDCs provide a verifiable chain of proof-of-authorship of the contained data. With a little additional syntactic sugar, this primary facility of chained (treed) proof-of-authorship (authenticity) is extensible to a chained (treed) verifiable authentic proof-of-authority (proof-of-authorship-of-authority). A proof-of-authority may be used to provide verifiable authorizations or permissions or rights or credentials. A chained (treed) proof-of-authority enables delegation of authority and delegated authorizations. These proofs of authorship and/or authority provide provenance of an ACDC itself and by association any data that is so conveyed.
The dictionary definition of **_credential_** is _evidence of authority, status, rights, entitlement to privileges, or the like_. Appropriately structured ACDCs may be used as credentials when their semantics provide verifiable evidence of authority. Chained ACDCs may provide delegated credentials.
Chains of ACDCs that merely provide proof-of-authorship (authenticity) of data may be appended to chains of ACDCs that provide proof-of-authority (delegation) to enable verifiable delegated authorized authorship of data. This is a vital facility for authentic data supply chains. Furthermore, any physical supply chain may be measured, monitored, regulated, audited, and/or archived by a data supply chain acting as a digital twin {{Twin}}. Therefore ACDCs provide the critical enabling facility for an authentic data economy and by association an authentic real (twinned) economy.
ACDCs act as securely attributed (authentic) fragments of a distributed _property graph_ (PG) {{PGM}}{{Dots}}. Thus they may be used to construct knowledge graphs expressed as property graphs {{KG}}. ACDCs enable securely-attributed and privacy-protecting knowledge graphs.
The ACDC specification (including its partial and selective disclosure mechanisms) leverages two primary cryptographic operations namely digests and digital signatures {{Hash}}{{DSig}}. These operations when used in an ACDC MUST have a security level, cryptographic strength, or entropy of approximately 128 bits {{Level}}. (See the appendix for a discussion of cryptographic strength and security)
An important property of high-strength cryptographic digests is that a verifiable cryptographic commitment (such as a digital signature) to the digest of some data is equivalent to a commitment to the data itself. ACDCs leverage this property to enable compact chains of ACDCs that anchor data via digests. The data _contained_ in an ACDC may therefore be merely its equivalent anchoring digest. The anchored data is thereby equivalently authenticated or authorized by the chain of ACDCs.
An ACDC may be abstractly modeled as a nested `key: value` mapping. To avoid confusion with the cryptographic use of the term _key_ we instead use the term _field_ to refer to a mapping pair and the terms _field label_ and _field value_ for each member of a pair. These pairs can be represented by two tuples e.g `(label, value)`. We qualify this terminology when necessary by using the term _field map_ to reference such a mapping. _Field maps_ may be nested where a given _field value_ is itself a reference to another _field map_. We call this nested set of fields a _nested field map_ or simply a _nested map_ for short. A _field_ may be represented by a framing code or block delimited serialization. In a block delimited serialization, such as JSON, each _field map_ is represented by an object block with block delimiters such as `{}` {{RFC8259}}{{JSON}}{{RFC4627}}. Given this equivalence, we may also use the term _block_ or _nested block_ as synonymous with _field map_ or _nested field map_. In many programming languages, a field map is implemented as a dictionary or hash table in order to enable performant asynchronous lookup of a _field value_ from its _field label_. Reproducible serialization of _field maps_ requires a canonical ordering of those fields. One such canonical ordering is called insertion or field creation order. A list of `(field, value)` pairs provides an ordered representation of any field map. Most programming languages now support ordered dictionaries or hash tables that provide reproducible iteration over a list of ordered field `(label, value)` pairs where the ordering is the insertion or field creation order. This enables reproducible round trip serialization/deserialization of _field maps_. ACDCs depend on insertion ordered field maps for canonical serialization/deserialization. ACDCs support multiple serialization types, namely JSON, CBOR, MGPK, and CESR but for the sake of simplicity, we will only use JSON herein for examples {{RFC8259}}{{JSON}}. The basic set of normative field labels in ACDC field maps is defined in the following table.
These are reserved field labels at the top level of an ACDC.
| Label | Title | Description |
| --- | --- | --- |
| `v` | Version String | Regexable format: ACDCvvSSSShhhhhh\_ that provides protocol type, version, serialization type, size, and terminator. |
| `d` | Digest (SAID) | Self-referential fully qualified cryptographic digest of enclosing map. |
| `u` | UUID | Random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `i` | Issuer Identifier (AID) | Autonomic IDentifier whose Control authority is established via KERI verifiable key state. |
| `ri` | Registry Identifier | Issuance and/or revocation, transfer, or retraction registry for ACDC derived from Issuer Identifier. |
| `s` | Schema | Either the SAID of a JSON Schema block or the block itself. |
| `a` | Attribute | Either the SAID of a block of attributes or the block itself. |
| `A` | Attribute Aggregate | Either the Aggregate of a selectively disclosable block of attributes or the block itself. |
| `e` | Edge | Either the SAID of a block of edges or the block itself. |
| `r` | Rule | Either the SAID a block of rules or the block itself. |
| `n` | Node | SAID of another ACDC as the terminating point of a directed edge that connects the encapsulating ACDC node to the specified ACDC node as a fragment of a distributed property graph (PG). |
| `o` | Operator | Either unary operator on edge or m-ary operator on edge-group in edge section. Enables expressing of edge logic on edge subgraph. |
| `w` | Weight | Edge weight property that enables default property for directed weighted edges and operators on directed weighted edges. |
| `l` | Legal Language | Text of Ricardian contract clause. |
These may appear at other levels besides the top-level of an ACDC but are nonetheless reserved.
| Label | Title | Description |
| --- | --- | --- |
| `d` | Digest (SAID) | Self-referential fully qualified cryptographic digest of enclosing map. |
| `u` | UUID | Random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `i` | Identifier (AID) | Context dependent AID as determined by its enclosing map such as Issuee Identifier. |
| `n` | Node | SAID of another ACDC as the terminating point (vertex) of a directed edge that connects the encapsulating ACDC node to the specified ACDC node as a fragment of a distributed property graph (PG). |
| `o` | Operator | Either unary operator on edge or m-ary operator on edge-group in edge section. Enables expressing of edge logic on edge subgraph. |
| `w` | Weight | Edge weight property that enables default property for directed weighted edges and operators on directed weighted edges. |
| `l` | Legal Language | Text of Ricardian contract clause. |
The primary field labels are compact in that they use only one or two characters. ACDCs are meant to support resource-constrained applications such as supply chain or IoT (Internet of Things) applications. Compact labels better support resource-constrained applications in general. With compact labels, the over-the-wire verifiable signed serialization consumes a minimum amount of bandwidth. Nevertheless, without loss of generality, a one-to-one normative semantic overlay using more verbose expressive field labels may be applied to the normative compact labels after verification of the over-the-wire serialization. This approach better supports bandwidth and storage constraints on transmission while not precluding any later semantic post-processing. This is a well-known design pattern for resource-constrained applications.
The version string, `v`, field MUST be the first field in any top-level ACDC field map. It provides a regular expression target for determining the serialization format and size (character count) of a serialized ACDC. A stream-parser may use the version string to extract and deserialize (deterministically) any serialized ACDC in a stream of serialized ACDCs. Each ACDC in a stream may use a different serialization type.
The format of the version string is `ACDCvvSSSShhhhhh_`. The first four characters `ACDC` indicate the enclosing field map serialization. The next two characters, `vv` provide the lowercase hexadecimal notation for the major and minor version numbers of the version of the ACDC specification used for the serialization. The first `v` provides the major version number and the second `v` provides the minor version number. For example, `01` indicates major version 0 and minor version 1 or in dotted-decimal notation `0.1`. Likewise `1c` indicates major version 1 and minor version decimal 12 or in dotted-decimal notation `1.12`. The next four characters `SSSS` indicate the serialization type in uppercase. The four supported serialization types are `JSON`, `CBOR`, `MGPK`, and `CESR` for the JSON, CBOR, MessagePack, and CESR serialization standards respectively {{JSON}}{{RFC4627}}{{CBOR}}{{RFC8949}}{{MGPK}}{{CESR\_ID}}. The next six characters provide in lowercase hexadecimal notation the total number of characters in the serialization of the ACDC. The maximum length of a given ACDC is thereby constrained to be _224 = 16,777,216_ characters in length. The final character `-` is the version string terminator. This enables later versions of ACDC to change the total version string size and thereby enable versioned changes to the composition of the fields in the version string while preserving deterministic regular expression extractability of the version string. Although a given ACDC serialization type may have a field map delimiter or framing code characters that appear before (i.e. prefix) the version string field in a serialization, the set of possible prefixes is sufficiently constrained by the allowed serialization protocols to guarantee that a regular expression can determine unambiguously the start of any ordered field map serialization that includes the version string as the first field value. Given the version string, a parser may then determine the end of the serialization so that it can extract the full ACDC from the stream without first deserializing it. This enables performant stream parsing and off-loading of ACDC streams that include any or all of the supported serialization types.
Some fields in ACDCs may have for their value either a _field map_ or a SAID. A SAID follows the SAID protocol {{SAID\_ID}}. Essentially a SAID is a Self-Addressing IDentifier (self-referential content addressable). A SAID is a special type of cryptographic digest of its encapsulating _field map_ (block). The encapsulating block of a SAID is called a SAD (Self-Addressed Data). Using a SAID as a _field value_ enables a more compact but secure representation of the associated block (SAD) from which the SAID is derived. Any nested field map that includes a SAID field (i.e. is, therefore, a SAD) may be compacted into its SAID. The uncompacted blocks for each associated SAID may be attached or cached to optimize bandwidth and availability without decreasing security.
Several top-level ACDC fields may have for their value either a serialized _field map_ or the SAID of that _field map_. Each SAID provides a stable universal cryptographically verifiable and agile reference to its encapsulating block (serialized _field map_). Specifically, the value of top-level `s`, `a`, `e`, and `r` fields may be replaced by the SAID of their associated _field map_. When replaced by their SAID, these top-level sections are in _compact_ form.
Recall that a cryptographic commitment (such as a digital signature or cryptographic digest) on a given digest with sufficient cryptographic strength including collision resistance {{HCR}}{{QCHC}} is equivalent to a commitment to the block from which the given digest was derived. Specifically, a digital signature on a SAID makes a verifiable cryptographic non-repudiable commitment that is equivalent to a commitment on the full serialization of the associated block from which the SAID was derived. This enables reasoning about ACDCs in whole or in part via their SAIDS in a fully interoperable, verifiable, compact, and secure manner. This also supports the well-known bow-tie model of Ricardian Contracts {{RC}}. This includes reasoning about the whole ACDC given by its top-level SAID, `d`, field as well as reasoning about any nested sections using their SAIDS.
The purpose of the UUID, `u`, field in any block is to provide sufficient entropy to the SAID, `d`, field of the associated block to make computationally infeasible any brute force attacks on that block that attempt to discover the block contents from the schema and the SAID. The UUID, `u`, field may be considered a salty nonce {{Salt}}. Without the entropy provided the UUID, `u`, field, an adversary may be able to reconstruct the block contents merely from the SAID of the block and the schema of the block using a rainbow or dictionary attack on the set of field values allowed by the schema {{RB}}{{DRB}}. The effective security level, entropy, or cryptographic strength of the schema-compliant field values may be much less than the cryptographic strength of the SAID digest. Another way of saying this is that the cardinality of the power set of all combinations of allowed field values may be much less than the cryptographic strength of the SAID. Thus an adversary could successfully discover via brute force the exact block by creating digests of all the elements of the power set which may be small enough to be computationally feasible instead of inverting the SAID itself. Sufficient entropy in the `u` field ensures that the cardinality of the power set allowed by the schema is at least as great as the entropy of the SAID digest algorithm itself.
A UUID, `u` field may optionally appear in any block (field map) at any level of an ACDC. Whenever a block in an ACDC includes a UUID, `u`, field then its associated SAID, `d`, field makes a blinded commitment to the contents of that block. The UUID, `u`, field is the blinding factor. This makes that block securely partially disclosable or even selectively disclosable notwithstanding disclosure of the associated schema of the block. The block contents can only be discovered given disclosure of the included UUID field. Likewise when a UUID, `u`, field appears at the top level of an ACDC then that top-level SAID, `d`, field makes a blinded commitment to the contents of the whole ACDC itself. Thus the whole ACDC, not merely some block within the ACDC, may be disclosed in a privacy-preserving (correlation minimizing) manner.
Some fields, such as the `i`, Issuer identifier field MUST each have an AID (Autonomic IDentifier) as its value. An AID is a fully qualified Self-Certifying IDentifier (SCID) that follows the KERI protocol {{KERI}}{{KERI\_ID}}. A related type of identifier field is the `ri`, registry identifier field. The `ri` field is cryptographically derived from the Issuer identifier field value so has securely attributable control authority via the AID from which it is derived. A SCID is derived from one or more `(public, private)` key pairs using asymmetric or public-key cryptography to create verifiable digital signatures {{DSig}}. Each AID has a set of one or more controllers who each control a private key. By virtue of their private key(s), the set of controllers may make statements on behalf of the associated AID that is backed by uniquely verifiable commitments via digital signatures on those statements. Any entity may then verify those signatures using the associated set of public keys. No shared or trusted relationship between the controllers and verifiers is required. The verifiable key state for AIDs is established with the KERI protocol {{KERI}}{{KERI\_ID}}. The use of AIDS enables ACDCs to be used in a portable but securely attributable, fully decentralized manner in an ecosystem that spans trust domains.
Because KERI is agnostic about the namespace for any particular AID, different namespace standards may be used to express KERI AIDs or identifiers derived from AIDs as the value of thes AID related fields in an ACDC. The examples below use the W3C DID namespace specification with the `did:keri` method {{DIDK\_ID}}. But the examples would have the same validity from a KERI perspective if some other supported namespace was used or no namespace was used at all. The latter case consists of a bare KERI AID (identifier prefix) expressed in CESR format {{CESR\_ID}}.
The top-level selectively-disclosable attribute aggregate section, `A`, field value is an aggregate of cryptographic commitments used to make a commitment to a set (bundle) of selectively-disclosable attributes. The value of the attribute aggregate, `A`, field depends on the type of selective disclosure mechanism employed. For example, the aggregate value could be the cryptographic digest of the concatenation of an ordered set of cryptographic digests, a Merkle tree root digest of an ordered set of cryptographic digests, or a cryptographic accumulator.
ACDC leverages several closely related mechanisms for what can be called **_graduated disclosure_**. _Graduated disclosure_ enables adherence to the principle of least disclosure which is expressed as follows:
> The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. {{IDSys}}
To clarify, _graduated disclosure_ enables a potential Discloser to follow the principle of _least disclosure_ by providing the least amount of information i.e. partial, incomplete, or uncorrelatable information needed to further a transaction.
The important insight is that one type of transaction enabled by least disclosure is a transaction that specifically enables further disclosure. In other words, disclose enough to enable more disclosure which in turn may enable even more disclosure. This is the essence of _graduated disclosure_. This progression of successive least graduated disclosures to enable a transaction that itself enables a farther least graduated disclosure forms a recursive loop of least disclosure enabled transactions. In other words, the principle of least disclosure may be applied recursively.
A type of transaction that leverages _graduated disclosure_ to enable further disclosure we call a **_contractually protected disclosure_** transaction. In a contractually protected disclosure, the potential Discloser first makes an offer using the least (partial) disclosure of some information about other information to be disclosed (full disclosure) contingent on the potential Disclosee first agreeing to the contractual terms provided in the offer. The contractual terms could, for example, limit the disclosure to third parties of the yet to be disclosed information. But those contractual terms may also include provisions that protect against liability or other concerns not merely disclosure to third parties.
One special case of a _contractually protected disclosure_ is a **_chain-link confidential disclosure_** {{CLC}}.
Another special case of _contractually protected disclosure_ is a **_contingent-disclosure_**. In a _contingent disclosure_ some contingency is specified in the rule section that places an obligation by some party to make a disclosure when the contingency is satisfied. This might be recourse given the breach of some other term of the contract. When that contingency is met then the contingent disclosure MUST be made by the party whose responsibility it is to satisfy that disclosure obligation. The responsible party may be the Discloser of the ACDC or it may be some other party such as an escrow agent. The contingent disclosure clause may reference a cryptographic commitment to a private ACDC or private attribute ACDC (partial disclosure) that satisfies via its full disclosure the contingent disclosure requirement. Contingent disclosure may be used to limit the actual disclosure of personally identifying information (PII) to a just-in-time, need-to-know basis (i.e upon the contingency) and not a priori. As long as the Discloser and Disclosee trust the escrow agent and the verifiability of the committment, there is no need to disclose PII about the discloser in order to enable a transaction, but merely an agreement to the terms of the contingency. This enables something called **_latent accountability_**. Recourse via PII is latent in the contingent disclosure but is not ever realized (actualized) until recourse is truly needed. The minimizes inadvertent leakage while protecting the Disclosee.
ACDCs employ three specific closely related types of _graduated disclosure_. These are **_compact disclosure_**, **_partial disclosure_**, and **_selective disclosure_**. The mechanism for _compact disclosure_ is a cryptographic digest of the content expressed in the form of a SAID of that content. Both partial and selective disclosure rely on the compact disclosure of content that is also cryptographically blinded or hidden. Content in terms of an ACDC means a block (field map or field map array).
The difference between **_partial disclosure_** and **_selective disclosure_** of a given block is determined by the correlatability of the disclosed field(s) after **_full disclosure_** of the detailed field value with respect to its enclosing block (field map or field map array). A _partially disclosable_ field becomes correlatable after _full disclosure_. Whereas a _selectively disclosable_ field may be excluded from the _full disclosure_ of any other _selectively disclosable_ fields in the _selectively disclosable_ block (usually a field map array). After such _selective disclosure_, the selectively disclosed fields are not correlatable to the so-far undisclosed but selectively disclosable fields in that block (field map array).
When used in the context of _selective disclosure_, _full disclosure_ means detailed disclosure of the selectively disclosed attributes not detailed disclosure of all selectively disclosable attributes. Whereas when used in the context of _partial disclosure_, _full disclosure_ means detailed disclosure of the field map that was so far only partially disclosed.
_Partial disclosure_ is an essential mechanism needed to support both performant exchange of information and contractually protected disclosure such as chain-link confidentiality on exchanged information {{CLC}}. The exchange of only the SAID of a given field map is a type of _partial disclosure_. Another type of _partial disclosure_ is the disclosure of validatable metadata about a detailed field map e.g. the schema of a field map.
The SAID of a field map provides a _compact_ cryptographically equivalent commitment to the yet to be undisclosed field map details. A later exchange of the uncompacted field map detail provides _full disclosure_. Any later _full disclosure_ is verifiable to an earlier _partial disclosure_. Partial disclosure via compact SAIDs enables the scalable repeated verifiable exchange of SAID references to cached full disclosures. Multiple SAID references to cached fully disclosed field maps may be transmitted compactly without redundant retransmission of the full details each time a new reference is transmitted. Likewise, _partial disclosure_ via SAIDs also supports the bow-tie model of Ricardian contracts {{RC}}. Similarly, the schema of a field map is metadata about the structure of the field map this is validatable given the full disclosure of the field map. The details of_compact_ and/or confidential exchange mechanisms that leverage partial disclosure are explained later. When the field map includes sufficient cryptographic entropy such as through a UUID field (salty nonce), then the SAID of that field map effectively blinds the contents of the field map. This enables the field map contents identified by its SAID and characterized by its schema (i.e. partial disclosure) to remain private until later full disclosure.
_Selective disclosure_, on the other hand, is an essential mechanism needed to unbundle in a correlation minimizing way a single commitment by an Issuer to a bundle of fields (i.e. a nested array or list or tuple of fields) as a whole. This allows separating a "stew" (bundle) of "ingredients" (attributes) into its constituent "ingredients" (attributes) without correlating the constituents via the Issuer's commitment to the "stew" (bundle) as a whole.
Notable is the fact that there are no top-level type fields in an ACDC. This is because the schema, `s`, field itself is the type field for the ACDC and its parts. ACDCs follow the design principle of separation of concerns between a data container's actual payload information and the type information of that container's payload. In this sense, type information is metadata, not data. The schema dialect used by ACDCs is JSON Schema 2020-12 {{JSch}}{{JSch\_202012}}. JSON Schema supports composable schema (sub-schema), conditional schema (sub-schema), and regular expressions in the schema. Composability enables a validator to ask and answer complex questions about the type of even optional payload elements while maintaining isolation between payload information and type (structure) information about the payload {{JSchCp}}{{JSchRE}}{{JSchId}}{{JSchCx}}. A static but composed schema allows a verifiably immutable set of variants. Although the set is immutable, the variants enable graduated but secure disclosure. ACDC's use of JSON Schema MUST be in accordance with the ACDC defined profile as defined herein. The exceptions are defined below.
The usual field label for SAID fields in ACDCs is `d`. In the case of the schema section, however, the field label for the SAID of the schema section is `$id`. This repurposes the schema id field label, `$id` as defined by JSON Schema {{JSchId}}{{JSchCx}}. The top-level id, `$id`, field value in a JSON Schema provides a unique identifier of the schema instance. In a usual (non-ACDC) schema the value of the id, `$id`, field is expressed as a URI. This is called the _Base URI_ of the schema. In an ACDC schema, however, the top-level id, `$id`, field value is repurposed. Its value MUST include the SAID of the schema. This ensures that the ACDC schema is static and verifiable to their SAIDS. A verifiably static schema satisfies one of the essential security properties of ACDCs as discussed below. There are several ACDC supported formats for the value of the top-level id, `$id`, field but all of the formats MUST include the SAID of the schema (see below). Correspondingly, the value of the top-level schema, `s`, field MUST be the SAID included in the schema's top-level `$id` field. The detailed schema is either attached or cached and maybe discovered via its SAIDified, id, `$id`, field value.
When an id, '$id', field appears in a sub-schema it indicates a bundled sub-schema called a schema resource {{JSchId}}{{JSchCx}}. The value of the id, '$id', field in any ACDC bundled sub-schema resource MUST include the SAID of that sub-schema using one of the formats described below. The sub-schema so bundled MUST be verifiable against its referenced and embedded SAID value. This ensures secure bundling.
For security reasons, the full schema of an ACDC must be completely self-contained and statically fixed (immutable) for that ACDC. By this, we mean that no dynamic schema references or dynamic schema generation mechanisms are allowed.
Should an adversary successfully attack the source that provides the dynamic schema resource and change the result provided by that reference, then the schema validation on any ACDC that uses that dynamic schema reference may fail. Such an attack effectively revokes all the ACDCs that use that dynamic schema reference. We call this a **_schema revocation_** attack.
More insidiously, an attacker could shift the semantics of the dynamic schema in such a way that although the ACDC still passes its schema validation, the behavior of the downstream processing of that ACDC is changed by the semantic shift. This we call a **_semantic malleability_** attack. It may be considered a new type of _transaction malleability_ attack {{TMal}}.
To prevent both forms of attack, all schema must be static, i.e. schema MUST be SADs and therefore verifiable against their SAIDs.
To elaborate, the serialization of a static schema may be self-contained. A compact commitment to the detailed static schema may be provided by its SAID. In other words, the SAID of a static schema is a verifiable cryptographic identifier for its SAD. Therefore all ACDC compliant schema must be SADs. In other words, they MUST therefore be _SAIDified_. The associated detailed static schema (uncompacted SAD) is cryptographically bound and verifiable to its SAID.
The JSON Schema specification allows complex schema references that may include non-local URI references {{JSchId}}{{JSchCx}}{{RFC3986}}{{RFC8820}}. These references may use the `$id` or `$ref` keywords. A relative URI reference provided by a `$ref` keyword is resolved against the _Base URI_ provided by the top-level `$id` field. When this top-level _Base URI_ is non-local then all relative `$ref` references are therefore also non-local. A non-local URI reference provided by a `$ref` keyword may be resolved without reference to the _Base URI_.
In general, schema indicated by non-local URI references (`$id` or `$ref`) MUST NOT be used because they are not cryptographically end-verifiable. The value of the underlying schema resource so referenced may change (mutate). To restate, a non-local URI schema resource is not end-verifiable to its URI reference because there is no cryptographic binding between URI and resource {{RFC3986}}{{RFC8820}}.
This does not preclude the use of remotely cached SAIDified schema resources because those resources are end-verifiable to their embedded SAID references. Said another way, a SAIDified schema resource is itself a SAD (Self-Address Data) referenced by its SAID. A URI that includes a SAID may be used to securely reference a remote or distributed SAIDified schema resource because that resource is fixed (immutable, nonmalleable) and verifiable to both the SAID in the reference and the embedded SAID in the resource so referenced. To elaborate, a non-local URI reference that includes an embedded cryptographic commitment such as a SAID is verifiable to the underlying resource when that resource is a SAD. This applies to JSON Schema as a whole as well as bundled sub-schema resources.
There ACDC supported formats for the value of the top-level id, `$id`, field are as follows:
- Bare SAIDs may be used to refer to a SAIDified schema as long as the JSON schema validator supports bare SAID references. By default, many if not all JSON schema validators support bare strings (non-URIs) for the _Base URI_ provided by the top-level `$id` field value.
- The `sad:` URI scheme may be used to directly indicate a URI resource that safely returns a verifiable SAD. For example `sad:SAID` where _SAID_ is replaced with the actual SAID of a SAD that provides a verifiable non-local reference to JSON Schema as indicated by the mime-type of `schema+json`.
- The IETF KERI OOBI internet draft specification provides a URL syntax that references a SAD resource by its SAID at the service endpoint indicated by that URL {{OOBI\_ID}}. Such remote OOBI URLs are also safe because the provided SAD resource is verifiable against the SAID in the OOBI URL. Therefore OOBI URLs are also acceptable non-local URI references for JSON Schema {{OOBI\_ID}}{{RFC3986}}{{RFC8820}}.
- The `did:` URI scheme may be used safely to prefix non-local URI references that act to namespace SAIDs expressed as DID URIs or DID URLs. DID resolvers resolve DID URLs for a given DID method such as `did:keri` {{DIDK\_ID}} and may return DID docs or DID doc metadata with SAIDified schema or service endpoints that return SAIDified schema or OOBIs that return SAIDified schema {{RFC3986}}{{RFC8820}}{{OOBI\_ID}}. A verifiable non-local reference in the form of DID URL that includes the schema SAID is resolved safely when it dereferences to the SAD of that SAID. For example, the resolution result returns an ACDC JSON Schema whose id, `$id`, field includes the SAID and returns a resource with JSON Schema mime-type of `schema+json`.
To clarify, ACDCs MUST NOT use complex JSON Schema references which allow _dynamically generated_ schema resources to be obtained from online JSON Schema Libraries {{JSchId}}{{JSchCx}}. The latter approach may be difficult or impossible to secure because a cryptographic commitment to the base schema that includes complex schema (non-relative URI-based) references only commits to the non-relative URI reference and not to the actual schema resource which may change (is dynamic, mutable, malleable). To restate, this approach is insecure because a cryptographic commitment to a complex (non-relative URI-based) reference is NOT equivalent to a commitment to the detailed associated schema resource so referenced if it may change.
ACDCs MUST use static JSON Schema (i.e. _SAIDifiable_ schema). These may include internal relative references to other parts of a fully self-contained static (_SAIDified_) schema or references to static (_SAIDified_) external schema parts. As indicated above, these references may be bare SAIDs, DID URIs or URLs (`did:` scheme), SAD URIs (`sad:` scheme), or OOBI URLs {{OOBI\_ID}}. Recall that a commitment to a SAID with sufficient collision resistance makes an equivalent secure commitment to its encapsulating block SAD. Thus static schema may be either fully self-contained or distributed in parts but the value of any reference to a part must be verifiably static (immutable, nonmalleable) by virtue of either being relative to the self-contained whole or being referenced by its SAID. The static schema in whole or in parts may be attached to the ACDC itself or provided via a highly available cache or data store. To restate, this approach is securely end-verifiable (zero-trust) because a cryptographic commitment to the SAID of a SAIDified schema is equivalent to a commitment to the detailed associated schema itself (SAD).
The schema dialect for ACDC 1.0 is JSON Schema 2020-12 and is indicated by the identifier `"https://json-schema.org/draft/2020-12/schema"` {{JSch}}{{JSch\_202012}}. This is indicated in a JSON Schema via the value of the top-level `$schema` field. Although the value of `$schema` is expressed as a URI, de-referencing does not provide dynamically downloadable schema dialect validation code. This would be an attack vector. The validator MUST control the tooling code dialect used for schema validation and hence the tooling dialect version actually used. A mismatch between the supported tooling code dialect version and the `$schema` string value should cause the validation to fail. The string is simply an identifier that communicates the intended dialect to be processed by the schema validation tool. When provided, the top-level `$schema` field value for ACDC version 1.0 must be "[https://json-schema.org/draft/2020-12/schema"](https://json-schema.org/draft/2020-12/schema%22).
The composed detailed (uncompacted) (bundled) static schema for an ACDC may be cached or attached. But cached, and/or attached static schema is not to be confused with dynamic schema. Nonetheless, while securely verifiable, a remotely cached, _SAIDified_, schema resource may be unavailable. Availability is a separate concern. Unavailable does not mean insecure or unverifiable. ACDCs MUST be verifiable when available. Availability is typically solvable through redundancy. Although a given ACDC application domain or eco-system governance framework may impose schema availability constraints, the ACDC specification itself does not impose any specific availability requirements on Issuers other than schema caches SHOULD be sufficiently available for the intended application of their associated ACDCs. It's up to the Issuer of an ACDC to satisfy any availability constraints on its schema that may be imposed by the application domain or eco-system.
A composable JSON Schema enables the use of any combination of compacted/uncompacted attribute, edge, and rule sections in a provided ACDC. When compact, any one of these sections may be represented merely by its SAID {{JSch}}{{JSchCp}}. When used for the top-level attribute, `a`, edge, `e`, or rule, `r`, section field values, the `oneOf` sub-schema composition operator provides both compact and uncompacted variants. The provided ACDC MUST validate against an allowed combination of the composed variants, either the compact SAID of a block or the full detailed (uncompacted) block for each section. The validator determines what decomposed variants the provided ACDC MUST also validate against. Decomposed variants may be dependent on the type of graduated disclosure, partial, full, or selective. Essentially a composable schema is a verifiable bundle of metadata (composed) about content that then can be verifiably unbundled (decomposed) later. The Issuer makes a single verifiable commitment to the bundle (composed schema) and a recipient may then safely unbundle (decompose) the schema to validate any of the graduated disclosures variants allowed by the composition.
Unlike the other compactifiable sections, it is impossible to define recursively the exact detailed schema as a variant of a `oneOf` composition operator contained in itself. Nonetheless, the provided schema, whether self-contained, attached, or cached MUST validate as a SAD against its provided SAID. It MUST also validate against one of its specified `oneOf` variants.
The compliance of the provided non-schema attribute, `a`, edge, `e`, and rule, `r`, sections MUST be enforced by validating against the composed schema. In contrast, the compliance of the provided composed schema for an expected ACDC type MUST be enforced by the validator. This is because it is not possible to enforce strict compliance of the schema by validating it against itself.
ACDC specific schema compliance requirements are usually specified in the eco-system governance framework for a given ACDC type. Because the SAID of a schema is a unique content-addressable identifier of the schema itself, compliance can be enforced by comparison to the allowed schema SAID in a well-known publication or registry of ACDC types for a given ecosystem governance framework (EGF). The EGF may be solely specified by the Issuer for the ACDCs it generates or be specified by some mutually agreed upon eco-system governance mechanism. Typically the business logic for making a decision about a presentation of an ACDC starts by specifying the SAID of the composed schema for the ACDC type that the business logic is expecting from the presentation. The verified SAID of the actually presented schema is then compared against the expected SAID. If they match then the actually presented ACDC may be validated against any desired decomposition of the expected (composed) schema.
To elaborate, a validator can confirm compliance of any non-schema section of the ACDC against its schema both before and after uncompacted disclosure of that section by using a composed base schema with `oneOf` pre-disclosure and a decomposed schema post-disclosure with the compact `oneOf` option removed. This capability provides a mechanism for secure schema validation of both compact and uncompacted variants that require the Issuer to only commit to the composed schema and not to all the different schema variants for each combination of a given compact/uncompacted section in an ACDC.
One of the most important features of ACDCs is support for Chain-Link Confidentiality {{CLC}}. This provides a powerful mechanism for protecting against un-permissioned exploitation of the data disclosed via an ACDC. Essentially an exchange of information compatible with chain-link confidentiality starts with an offer by the discloser to disclose confidential information to a potential disclosee. This offer includes sufficient metadata about the information to be disclosed such that the disclosee can agree to those terms. Specifically, the metadata includes both the schema of the information to be disclosed and the terms of use of that data once disclosed. Once the disclosee has accepted the terms then full disclosure is made. A full disclosure that happens after contractual acceptance of the terms of use we call _permissioned_ disclosure. The pre-acceptance disclosure of metadata is a form of partial disclosure.
As is the case for compact (uncompacted) ACDC disclosure, Composable JSON Schema, enables the use of the same base schema for both the validation of the partial disclosure of the offer metadata prior to contract acceptance and validation of full or detailed disclosure after contract acceptance {{JSch}}{{JSchCp}}. A cryptographic commitment to the base schema securely specifies the allowable semantics for both partial and full disclosure. Decomposition of the base schema enables a validator to impose more specific semantics at later stages of the exchange process. Specifically, the `oneOf` sub-schema composition operator validates against either the compact SAID of a block or the full block. Decomposing the schema to remove the optional compact variant enables a validator to ensure complaint full disclosure. To clarify, a validator can confirm schema compliance both before and after detailed disclosure by using a composed base schema pre-disclosure and a decomposed schema post-disclosure with the undisclosed options removed. These features provide a mechanism for secure schema-validated contractually-bound partial (and/or selective) disclosure of confidential data via ACDCs.
There are several variants of ACDCs determined by the presence/absence of certain fields and/or the value of those fields. At the top level, the presence (absence), of the UUID, `u`, field produces two variants. These are private (public) respectively. In addition, a present but empty UUID, `u`, field produces a private metadata variant.
Given that there is no top-level UUID, `u`, field in an ACDC, then knowledge of both the schema of the ACDC and the top-level SAID, `d`, field may enable the discovery of the remaining contents of the ACDC via a rainbow table attack {{RB}}{{DRB}}. Therefore, although the top-level, `d`, field is a cryptographic digest, it may not securely blind the contents of the ACDC when knowledge of the schema is available. The field values may be discoverable. Consequently, any cryptographic commitment to the top-level SAID, `d`, field may provide a fixed point of correlation potentially to the ACDC field values themselves in spite of non-disclosure of those field values. Thus an ACDC without a top-level UUID, `u`, field must be considered a **_public_** (non-confidential) ACDC.
Given a top-level UUID, `u`, field, whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of an ACDC may provide a secure cryptographic digest that blinds the contents of the ACDC {{Hash}}. An adversary when given both the schema of the ACDC and the top-level SAID, `d`, field, is not able to discover the remaining contents of the ACDC in a computationally feasible manner such as through a rainbow table attack {{RB}}{{DRB}}. Therefore the top-level, UUID, `u`, field may be used to securely blind the contents of the ACDC notwithstanding knowledge of the schema and top-level, SAID, `d`, field. Moreover, a cryptographic commitment to that that top-level SAID, `d`, field does not provide a fixed point of correlation to the other ACDC field values themselves unless and until there has been a disclosure of those field values. Thus an ACDC with a sufficiently high entropy top-level UUID, `u`, field may be considered a **_private_** (confidential) ACDC. enables a verifiable commitment to the top-level SAID of a private ACDC to be made prior to the disclosure of the details of the ACDC itself without leaking those contents. This is called _partial_ disclosure. Furthermore, the inclusion of a UUID, `u`, field in a block also enables _selective_ disclosure mechanisms described later in the section on selective disclosure.
An empty, top-level UUID, `u`, field appearing in an ACDC indicates that the ACDC is a **_metadata_** ACDC. The purpose of a _metadata_ ACDC is to provide a mechanism for a _Discloser_ to make cryptographic commitments to the metadata of a yet to be disclosed private ACDC without providing any point of correlation to the actual top-level SAID, `d`, field of that yet to be disclosed ACDC. The top-level SAID, `d`, field, of the metadata ACDC, is cryptographically derived from an ACDC with an empty top-level UUID, `u`, field so its value will necessarily be different from that of an ACDC with a high entropy top-level UUID, `u`, field value. Nonetheless, the _Discloser_ may make a non-repudiable cryptographic commitment to the metadata SAID in order to initiate a chain-link confidentiality exchange without leaking correlation to the actual ACDC to be disclosed {{CLC}}. A _Disclosee_ (verifier) may validate the other metadata information in the metadata ACDC before agreeing to any restrictions imposed by the future disclosure. The metadata includes the _Issuer_, the _schema_, the provenancing _edges_, and the _rules_ (terms-of-use). The top-level attribute section, `a`, field value of a _metadata_ ACDC may be empty so that its value is not correlatable across disclosures (presentations). Should the potential _Disclosee_ refuse to agree to the rules then the _Discloser_ has not leaked the SAID of the actual ACDC or the SAID of the attribute block that would have been disclosed.
Given the _metadata_ ACDC, the potential _Disclosee_ is able to verify the _Issuer_, the schema, the provenanced edges, and rules prior to agreeing to the rules. Similarly, an _Issuer_ may use a _metadata_ ACDC to get agreement to a contractual waiver expressed in the rule section with a potential _Issuee_ prior to issuance. Should the _Issuee_ refuse to accept the terms of the waiver then the _Issuer_ has not leaked the SAID of the actual ACDC that would have been issued nor the SAID of its attributes block nor the attribute values themselves.
When a _metadata_ ACDC is disclosed (presented) only the _Discloser's_ signature(s) is attached not the _Issuer's_ signature(s). This precludes the _Issuer's_ signature(s) from being used as a point of correlation until after the _Disclosee_ has agreed to the terms in the rule section. When chain-link confidentiality is used, the _Issuer's_ signatures are not disclosed to the _Disclosee_ until after the _Disclosee_ has agreed to keep them confidential. The _Disclosee_ is protected from forged _Discloser_ because ultimately verification of the disclosed ACDC will fail if the _Discloser_ does not eventually provide verifiable _Issuer's_ signatures. Nonetheless, should the potential _Disclosee_ not agree to the terms of the disclosure expressed in the rule section then the _Issuer's_ signature(s) is not leaked.
An important design goal of ACDCs is they support the sharing of provably authentic data while also protecting against the un-permissioned exploitation of that data. Often the term _privacy protection_ is used to describe similar properties. But a narrow focus on "privacy protection" may lead to problematic design trade-offs. With ACDCs, the primary design goal is not _data privacy protection_ per se but the more general goal of protection from the **_un-permissioned exploitation of data_**. In this light, a _given privacy protection_ mechanism may be employed to help protect against _unpermissioned exploitation of data_ but only when it serves that more general-purpose and not as an end in and of itself.
As described previously, ACDCs employ _graduated disclosure_ mechanisms that satisfy the principle of least disclosure. Requoted here the principle of least disclosure is as follows:
> The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. {{IDSys}}
For example, compact disclosure, partial disclosure, and selective disclosure are all graduated disclosure mechanisms. Contractually protected disclosure leverages graduated disclosure so that contractual protections can be put into place using the least disclosure necessary to that end. This minimizes the leakage of information that can be correlated. One type of contractually protected disclosure is chain-link confidentiality {{CLC}}.
An ACDC may employ several mechanisms to protect against _unpermissioned exploitation of data_. These are:
- Contractually Protected Disclosure
- Chain-link Confidentiality {{CLC}}
- Contingent Disclosure
- Partial Disclosure
- Selective Disclosure
For example, the _partial disclosure_ of portions of an ACDC to enable chain-link confidentiality of the subsequent full disclosure is an application of the principle of least disclosure. Likewise, unbundling only the necessary attributes from a bundled commitment using _selective disclosure_ to enable a correlation minimizing disclosure from that bundle is an application of the principle of least disclosure.
Unpermission exploitation is characterized using a three-party model. The three parties are as follows:
- First-Party = _Discloser_ of data.
- Second-Party = _Disclosee_ of data received from First Party (_Discloser_).
- Third-Party = _Observer_ of data disclosed by First Party (_Discloser_) to Second Party (_Disclosee_).
- implicit permissioned correlation.
- no contractual restrictions on the use of disclosed data.
- explicit permissioned correlation.
- use as permitted by contract
- explicit unpermissioned correlation with other second parties or third parties.
- malicious use in violation of contract
- implicit permissioned correlation.
- no contractual restrictions on the use of observed data.
- explicit unpermissioned correlation via collusion with second parties.
- malicious use in violation of second-party contract
Chain-link confidentiality imposes contractual restrictions and liability on any Disclosee (Second-Party) {{CLC}}. The exchange provides a fair contract consummation mechanism. The essential steps in a chain-link confidentiality exchange are shown below. Other steps may be included in a more comprehensive exchange protocol.
- _Discloser_ provides a non-repudiable _Offer_ with verifiable metadata (sufficient partial disclosure), which includes any terms or restrictions on use.
- _Disclosee_ verifies _Offer_ against composed schema and metadata adherence to desired data.
- _Disclosee_ provides non-repudiable _Accept_ of terms that are contingent on compliant disclosure.
- _Discloser_ provides non-repudiable _Disclosure_ with sufficient compliant detail.
- _Disclosee_ verifies _Disclosure_ using decomposed schema and adherence of disclosed data to _Offer_.
_Disclosee_ may now engage in permissioned use and carries liability as a deterrent against unpermissioned use.
The ordering of the top-level fields when present in an ACDC MUST be as follows, `v`, `d`, `u`, `i`, `ri`, `s`, `a`, `e`, `r`.
The top-level section field values of a compact ACDC are the SAIDs of each uncompacted top-level section. The section field labels are `s`, `a`, `e`, and `r`.
A fully compact public ACDC is shown below.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
A fully compact private ACDC is shown below.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"u": "0ANghkDaG7OY1wjaDAE0qHcg",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
The schema for the compact private ACDC example above is provided below.
```
{
"$id": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Compact Private ACDC",
"description": "Example JSON Schema for a Compact Private ACDC.",
"credentialType": "CompactPrivateACDCExample",
"type": "object",
"required":
[
"v",
"d",
"u",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"u":
{
"description": "ACDC UUID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry ID",
"type": "string"
},
"s": {
"description": "schema SAID",
"type": "string"
},
"a": {
"description": "attribute SAID",
"type": "string"
},
"e": {
"description": "edge SAID",
"type": "string"
},
"r": {
"description": "rule SAID",
"type": "string"
}
},
"additionalProperties": false
}
```
The attribute section in the examples above has been compacted into its SAID. The schema of the compacted attribute section is as follows,
```
{
"a":
{
"description": "attribute section SAID",
"type": "string"
}
}
```
Two variants of an ACDC, namely, namely, **_private (public) attribute_** are defined respectively by the presence (absence) of a UUID, `u`, field in the uncompacted attribute section block.
Two other variants of an ACDC, namely, **_targeted (untargeted)_** are defined respectively by the presence (absence) of an issuee, `i`, field in the uncompacted attribute section block.
Suppose that the un-compacted value of the attribute section as denoted by the attribute section, `a`, field is as follows,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
}
}
```
The SAID, `d`, field at the top level of the uncompacted attribute block is the same SAID used as the compacted value of the attribute section, `a`, field.
Given the absence of a `u` field at the top level of the attributes block, then knowledge of both SAID, `d`, field at the top level of an attributes block and the schema of the attributes block may enable the discovery of the remaining contents of the attributes block via a rainbow table attack {{RB}}{{DRB}}. Therefore the SAID, `d`, field of the attributes block, although, a cryptographic digest, does not securely blind the contents of the attributes block given knowledge of the schema. It only provides compactness, not privacy. Moreover, any cryptographic commitment to that SAID, `d`, field provides a fixed point of correlation potentially to the attribute block field values themselves in spite of non-disclosure of those field values via a compact ACDC. Thus an ACDC without a UUID, `u`, field in its attributes block must be considered a **_public-attribute_** ACDC even when expressed in compact form.
The subschema for the public uncompacted attribute section is shown below,
```
{
"a":
{
"description": "attribute section",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
}
```
Through the use of the JSON Schema `oneOf` composition operator the following composed schema will validate against both the compact and un-compacted value of the attribute section field.
```
{
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute SAID",
"type": "string"
},
{
"description": "uncompacted attribute section",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
```
Consider the following form of an uncompacted private-attribute block,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"u": "0AwjaDAE0qHcgNghkDaG7OY1",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
}
}
```
Given the presence of a top-level UUID, `u`, field of the attribute block whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of the attribute block provides a secure cryptographic digest of the contents of the attribute block {{Hash}}. An adversary when given both the schema of the attribute block and its SAID, `d`, field, is not able to discover the remaining contents of the attribute block in a computationally feasible manner such as a rainbow table attack {{RB}}{{DRB}}. Therefore the attribute block's UUID, `u`, field in a compact ACDC enables its attribute block's SAID, `d`, field to securely blind the contents of the attribute block notwithstanding knowledge of the attribute block's schema and SAID, `d` field. Moreover, a cryptographic commitment to that attribute block's, SAID, `d`, field does not provide a fixed point of correlation to the attribute field values themselves unless and until there has been a disclosure of those field values.
To elaborate, when an ACDC includes a sufficiently high entropy UUID, `u`, field at the top level of its attributes block then the ACDC may be considered a **_private-attributes_** ACDC when expressed in compact form, that is, the attribute block is represented by its SAID, `d`, field and the value of its top-level attribute section, `a`, field is the value of the nested SAID, `d`, field from the uncompacted version of the attribute block. A verifiable commitment may be made to the compact form of the ACDC without leaking details of the attributes. Later disclosure of the uncompacted attribute block may be verified against its SAID, `d`, field that was provided in the compact form as the value of the top-level attribute section, `a`, field.
Because the _Issuee_ AID is nested in the attribute block as that block's top-level, issuee, `i`, field, a presentation exchange (disclosure) could be initiated on behalf of a different AID that has not yet been correlated to the _Issuee_ AID and then only correlated to the Issuee AID after the _Disclosee_ has agreed to the chain-link confidentiality provisions in the rules section of the private-attributes ACDC {{CLC}}.
Through the use of the JSON Schema `oneOf` composition operator, the following composed schema will validate against both the compact and un-compacted value of the private attribute section, `a`, field.
```
{
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute SAID",
"type": "string"
},
{
"description": "uncompacted attribute section",
"type": "object",
"required":
[
"d",
"u",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
```
As described above in the Schema section of this specification, the `oneOf` sub-schema composition operator validates against either the compact SAID of a block or the full block. A validator can use a composed schema that has been committed to by the Issuer to securely confirm schema compliance both before and after detailed disclosure by using the fully composed base schema pre-disclosure and a specific decomposed variant post-disclosure. Decomposing the schema to remove the optional compact variant (i.e. removing the `oneOf` compact option) enables a validator to ensure complaint full disclosure.
Consider the case where the issuee, `i`, field is absent at the top level of the attribute block as shown below,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"temp": 45,
"lat": "N40.3433",
"lon": "W111.7208"
}
}
```
This ACDC has an _Issuer_ but no _Issuee_. Therefore, there is no provably controllable _Target_ AID. This may be thought of as an undirected verifiable attestation or observation of the data in the attributes block by the _Issuer_. One could say that the attestation is addressed to "whom it may concern". It is therefore an **_untargeted_** ACDC, or equivalently an _unissueed_ ACDC. An _untargeted_ ACDC enables verifiable authorship by the Issuer of the data in the attributes block but there is no specified counter-party and no verifiable mechanism for delegation of authority. Consequently, the rule section may only provide contractual obligations of implied counter-parties.
This form of an ACDC provides a container for authentic data only (not authentic data as authorization). But authentic data is still a very important use case. To clarify, an untargeted ACDC enables verifiable authorship of data. An observer such as a sensor that controls an AID may make verifiable non-repudiable measurements and publish them as ACDCs. These may be chained together to provide provenance for or a chain-of-custody of any data. These ACDCs could be used to provide a verifiable data supply chain for any compliance-regulated application. This provides a way to protect participants in a supply chain from imposters. Such data supply chains are also useful as a verifiable digital twin of a physical supply chain {{Twin}}.
A hybrid chain of one or more targeted ACDCs ending in a chain of one or more untargeted ACDCs enables delegated authorized attestations at the tail of that chain. This may be very useful in many regulated supply chain applications such as verifiable authorized authentic datasheets for a given pharmaceutical.
When present at the top level of the attribute section, the issuee, `i`, field value provides the AID of the _Issuee_ of the ACDC. This _Issuee_ AID is a provably controllable identifier that serves as the _Target_ AID. This makes the ACDC a **_targeted_** ACDC or equivalently an _issueed_ ACDC. Targeted ACDCs may be used for many different purposes such as an authorization or a delegation directed at the _Issuee_ AID, i.e. the _Target_. In other words, a _targeted ACDC_ provides a container for authentic data that may also be used as some form of authorization such as a credential that is verifiably bound to the _Issuee_ as targeted by the _Issuer_. Furthermore, by virtue of the targeted _Issuee's_ provable control over its AID, the _targeted ACDC_ may be verifiably presented (disclosed) by the controller of the _Issuee_ AID.
For example, the definition of the term **_credential_** is _evidence of authority, status, rights, entitlement to privileges, or the like_. To elaborate, the presence of an attribute section top-level issuee, `i`, field enables the ACDC to be used as a verifiable credential given by the _Issuer_ to the _Issuee_.
One reason the issuee, `i`, field is nested into the attribute section, `a`, block is to enable the _Issuee_ AID to be private or partially or selectively disclosable. The _Issuee_ may also be called the _Holder_ or _Subject_ of the ACDC. But here we use the more semantically precise albeit less common terms of _Issuer_ and _Issuee_. The ACDC is issued from or by an _Issuer_ and is issued to or for an _Issuee_. This precise terminology does not bias or color the role (function) that an _Issuee_ plays in the use of an ACDC. What the presence of _Issuee_ AID does provide is a mechanism for control of the subsequent use of the ACDC once it has been issued. To elaborate, because the issuee, `i`, field value is an AID, by definition, there is a provable controller of that AID. Therefore that _Issuee_ controller may make non-repudiable commitments via digital signatures on behalf of its AID. Therefore subsequent use of the ACDC by the _Issuee_ may be securely attributed to the _Issuee_.
Importantly the presence of an issuee, `i`, field enables the associated _Issuee_ to make authoritative verifiable presentations or disclosures of the ACDC. A designated _Issuee_also better enables the initiation of presentation exchanges of the ACDC between that _Issuee_ as _Discloser_ and a _Disclosee_ (verifier).
In addition, because the _Issuee_ is a specified counter-party the _Issuer_ may engage in a contract with the _Issuee_ that the _Issuee_ agrees to by virtue of its non-repudiable signature on an offer of the ACDC prior to its issuance. This agreement may be a pre-condition to the issuance and thereby impose liability waivers or other terms of use on that _Issuee_.
Likewise, the presence of an issuee, `i`, field, enables the _Issuer_ to use the ACDC as a contractual vehicle for conveying an authorization to the _Issuee_. This enables verifiable delegation chains of authority because the _Issuee_ in one ACDC may become the _Issuer_ in some other ACDC. Thereby an _Issuer_ may delegate authority to an _Issuee_ who may then become a verifiably authorized _Issuer_ that then delegates that authority (or an attenuation of that authority) to some other verifiably authorized _Issuee_ and so forth.
In the compact ACDC examples above, the edge section has been compacted into merely the SAID of that section. Suppose that the un-compacted value of the edge section denoted by the top-level edge, `e`, field is as follows,
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
}
}
```
The edge section's top-level SAID, `d`, field is the SAID of the edge block and is the same SAID used as the compacted value of the ACDC's top-level edge, `e`, field. Each edge in the edge section gets its own field with its own local label. The value of the field may be a sub-block or in the simplest case a string. In the example above, the edge label is `"boss"`. Note that each edge does NOT include a type field. The type of each edge is provided by the schema vis-a-vis the label of that edge. This is in accordance with the design principle of ACDCs that may be succinctly expressed as "type-is-schema". This approach varies somewhat from many property graphs which often do not have a schema {{PGM}}{{Dots}}{{KG}}. Because ACDCs have a schema for other reasons, however, they leverage that schema to provide edge types with a cleaner separation of concerns. Notwithstanding, this separation, an edge sub-block may include a constraint on the type of the ACDC to which that edge points by including the SAID of the schema of the pointed-to ACDC as a property of that edge.
A main distinguishing feature of a _property graph_ (PG) is that both nodes and edges may have a set of properties {{PGM}}{{Dots}}{{KG}}. These might include modifiers that influence how the connected node is to be combined or place a constraint on the allowed type(s) of connected nodes.
There several reserved field labels for edge sub-blocks. These are detailed in the table below. Each edge sub-block may have other non-reserved field labels as needed for a particular edge type.
| Label | Title | Description |
| --- | --- | --- |
| `d` | Digest (SAID) | Optional, self-referential fully qualified cryptographic digest of enclosing edge map. |
| `u` | UUID | Optional random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `s` | Schema | Optional SAID of the JSON Schema block of the far node ACDC. |
| `n` | Node | Required SAID of the far ACDC as the terminating point of a directed edge that connects the edge's encapsulating near ACDC to the specified far ACDC as a fragment of a distributed property graph (PG). |
| `o` | Operator | Optional as either a unary operator on edge or an m-ary operator on edge-group in edge section. Enables expression of the edge logic on edge subgraph. |
| `w` | Weight | Optional edge weight property that enables default property for directed weighted edges and operators that use weights. |
The node, `n`, field is required. The SAID, `d`, UUID, `u`, schema, `s`, operator, `o`, and weight, `w`, fields are optional. To clarify, each edge sub-block MUST have a node, `n`, field and MAY have any combination of SAID, `d`, UUID, `u`, schema, `s`, operator, `o`, or weight, `w`, fields.
When present, the SAID, `d`, field MUST appear as the first field in the edge sub-block. When present,the value of the SAID, `d` field MUST be the SAID of its enclosing edge sub-block.
A UUID, `u`, field MUST not appear unless there is also a SAID, `d` field. When present, the UUID, `u`, field must appear immediately after as the SAID, `d`, field in the edge sub-block. When present, the value of the UUID, `u` is a pseudorandom string with approximately 128 bits of cryptographic entropy. The UUID, `u`, field acts as a salty nonce to hide the values of the edge sub-block in spite of knowledge of the edge sub-blocks SAID, `d`, field and its, the edge's, actual near schema (not its far node schema field).
When the edge sub-block does NOT include a SAID, `d`, field then the node, `n`, field MUST appear as the first field in the edge sub-block, i.e. it follows the SAID, `d`, field which is first. When the edge sub-block does include a SAID, `d`, field then the node, `n`, field MUST appear as the second field in the edge sub-block.
The value of the required node, `n`, field is the SAID of the ACDC to which the edge connects i.e. the node, `n`, field indicated, designates, references, or "points to" another ACDC. The edge is directed _from_ the _near_ node that is the ACDC in which the edge sub-block resides and is directed _to_ the _far_ node that is the ACDC indicated by the node, `n`, field of that edge sub-block. In order for the edge (chain) to be valid, the ACDC validator MUST confirm that the SAID of the provided _far_ ACDC matches the node, `n`, field value given in the edge sub-block in _near_ ACDC and MUST confirm that the provided _far_ ACDC satisfies its own schema.
When present, the schema, `s` field must appear immediately following the node `n`, field in the edge sub-block. When present, the value of the schema, `s` field MUST be the SAID of the top-level schema, `s`, field of the ACDC indicated by the edge's far node, `n`, field. When the schema, `s`, field is present in an edge sub-block, in order for the edge (chain) to be valid, the ACDC validator, after validating that the provided _far_ ACDC indicated by the node, `n`, field satisfies its (the far ACDC's) own schema, MUST also confirm that the value of the edge's schema, `s`, field matches the SAID of the far ACDC's schema as indicated by its top-level schema, `s`, field.
The following example adds both SAID, `d`, and schema, `s`, fields (edge properties) to the edge sub-block.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn9y",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"s": "ELIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdYerzw"
}
}
}
```
When present, the operator, `o` field must appear immediately following all of the SAID, `d`, node, `n`, or schema, `s`, fields in the edge sub-block. The function of the operator field is explained in a later section.
When present, the weight, `w` field must appear immediately following all of the SAID, `d`, node, `n`, schema, `s`, or operator, `o`, fields in the edge sub-block. The function of the weight field is explained in a later section.
Abstractly, an ACDC with one or more edges may be a fragment of a distributed property graph. However, the local label does not enable the direct unique global resolution of a given edge including its properties other than a trivial edge with only one property, its node, `n` field. To enable an edge with additional properties to be globally uniquely resolvable, that edge's block MUST have a SAID, `d`, field. Because a SAID is a cryptographic digest it will universally and uniquely identify an edge with a given set of properties {{Hash}}. This allows ACDCs to be used as secure fragments of a globally distributed property graph (PG). This enables a property graph to serve as a global knowledge graph in a secure manner that crosses trust domains {{PGM}}{{Dots}}{{KG}}. This is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
Given that an individual edge's property block includes a SAID, `d`, field then a compact representation of the edge's property block is provided by replacing it with its SAID. This may be useful for complex edges with many properties. This is called a **_compact edge_**. This is shown as follows,
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn"
}
}
```
Each edge's properties may be blinded by its SAID, `d`, field (i.e. be private) if its properties block includes a UUID, `u` field. As with UUID, `u`, fields used elsewhere in ACDC, if the UUID, `u`, field value has sufficient entropy then the values of the properties of its enclosing block are not discoverable in a computationally feasible manner merely given the schema for the edge block and its SAID, `d` field. This is called a **_private edge_**. When a private edge is provided in compact form then the edge detail is hidden and is partially disclosable. An uncompacted private edge is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
When an edge points to a _private_ ACDC, a _Discloser_ may choose to use a metadata version of that private ACDC when presenting the node, `n`, field of that edge prior to acceptance of the terms of disclosure. The _Disclosee_ can verify the metadata of the private node without the _Discloser_ exposing the actual node contents via the actual node SAID or other attributes.
Private ACDCs (nodes) and private edges may be used in combination to prevent an un-permissioned correlation of the distributed property graph.
When an edge sub-block has only one field that is its node, `n`, field then the edge block may use an alternate simplified compact form where the labeled edge field value is the value of its node, `n`, field. The schema for that particular edge label, in this case, `"boss"`, will indicate that the edge value is a node SAID and not the edge sub-block SAID as would be the case for the normal compact form shown above. This alternate compact form is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
}
```
When the top-level edge section, `e`, field includes more than one edge there is a need or opportunity to define the logic for evaluating those edges with respect to validating the ACDC itself with respect to the validity of the other ACDCs it is connected two. More than one edge creates a provenance tree not simply a provenance chain. The obvious default for a chain is that all links in the chain must be valid in order for the chain itself to be valid, or more precisely for the tail of the chain to be valid. If any links between the head and the tail are broken (invalid) then the tail is not valid. This default logic may not be so useful in all cases when a given ACDC is the tail of multiple parallel chains (i.e. a branching node in a tree of chains). Therefore provided herein is the syntax for exactly specifying the operations to perform on each edge and groups of edges in its edge section.
There are three types of labels in edge sub-blocks:
- Reserved Field Labels (Metadata). `d` for SAID of block `u` for UUID (salty nonce) `n` for node SAID (far ACDC) `s` for schema SAID ( far ACDC) `o` for operator `w` for weight
- Edge Field Map Labels (Single Edges) any value except reserved values above
- Edge-Group Field Map Labels (Aggregates of Edges) any value except reserved values above
There are two types of field-maps or blocks that may appear as values of fields within an edge section, `e`, field either at the top level or nested:
- Edge-Group. An _**edge-group**_ MUST NOT have a node, `n`, metadata field. Its non-metadata field values may include other (sub) edge-group blocks, edge blocks or other properties.
- Edge. An _**edge**_ MUST have a node, `n`, metadata field. Its non-metadata field values MUST NOT include edge-group blocks or other edge blocks but may include other types of properties. From a graph perspective, _edge_ blocks terminate at their node, `n`, field and are not themselves nestable. An _edge_ block is a leaf with respect to any nested _edge-group_ blocks in which the edge appears. It is therefore also a leaf with respect to its enclosing top-level edge section, `e`, field. The ACDC node that an edge points to may have its own edge-groups or edges in that node's own top-level edge section.
The top-level edge section, `e`, field value is always an _edge-group_ block.
With respect to the granularity of a property graph consisting of ACDCs as nodes, nested edge-groups within a given top-level edge field, `e`, field of a given ACDC constitute a sub-graph whose nodes are edge-groups not ACDCs. One of the attractive features of property graphs (PGs) is their support for different edge and node types which enables nested sub-graphs such as is being employed here to support the expression of complex logical or aggregative operations on groups of edges (as subnodes) within the top-level edge section, `e`, field of an ACDC (as supernode).
The meaning of the operator, `o`, metadata field label depends on which type of block it appears in.
- When appearing in an edge-group block then the operator, `o`, field value is an aggregating (m-ary) operator, such as, `OR`, `AND`, `AVG`, `NAND`, `NOR` etc. Its operator applies to all the edges or edge-groups that appear in that edge-group block.
- When appearing in an edge block then the operator, `o`, field value is a unary operator like `NOT`. When more than one unary operator applies to a given edge then the value of the operator, `o`, field is a list of those unary operators.
Weighted directed edges represent degrees of confidence or likelihood. PGs with weighted directed edges are commonly used for machine learning or reasoning under uncertainty. The weight, `w` field provides a reserved label for the primary weight. To elaborate, many aggregating operators used for automated reasoning such as the weighted average, `WAVG`, operator or ranking aggregation operators, depend on each edge having a weight. To simplify the semantics for such operators, the weight, `w`, field is the reserved field label for weighting. Other fields with other labels could provide other types of weights but having a default label, namely `w`, simplifies the default definitions of weighted operators.
The following example adds a weight property to the edge sub-block as indicated by the weight, `w`, field.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
There are two basic m-ary operators defined for ACDCs. These are,
| M-ary Operator | Description | Type | Default |
| --- | --- | --- | --- |
| `AND` | All edges or edge-groups in the edge group MUST be valid for the edge-group to be valid | Combination | Yes |
| `OR` | Only one of the edges or edge-groups in the edge group MUST be valid for the edge-group to be valid | Combination | No |
There are three special unary operators defined for ACDCs. These are,
| Unary Operator | Description | Type | Default |
| --- | --- | --- | --- |
| `I2I` | Issuee-To-Issuer, Issuer AID of this ACDC must Issuee AID of node the edge points to | Constraint | Yes |
| `NI2I` | Not-Issuee-To-Issuer, Issuer AID if any of this ACDC MAY or MAY NOT be Issuee AID of node that the edge points to | Constraint | No |
| `DI2I` | Delegated-Issuee-To-Issuer, Issuer AID of this ACDC MUST be either the Issuee AID or delegated AID of the Issuee AID of the node the edge points to | Constraint | No |
Many ACDC chains use targeted ACDCs (i.e. have Issuees). A chain of Issuer-To-Issuee-To-Issuer targeted ACDCs in which each Issuee becomes the Issuer of the next ACDC in the chain can be used to provide a chain-of-authority. A common use case of a chain-of-authority is a delegation chain for authorization.
The `I2I` unary operator when present means that the Issuer AID of the current ACDC in which the edge resides MUST be the Issuee AID of the node that the edge points to. This also means therefore that the ACDC node pointed to by the edge must also be a targeted ACDC. This is the default value when none of `I2I`, `NI2I`, or `DI2I` is present.
The `NI2I` unary operator when present removes or nullifies any requirement expressed by the dual `I2I` operator described above. In other words, any requirement that the Issuer AID of the current ACDC in which the edge resides MUST be the Issuee AID, if any, of the node the edge points to is relaxed (not applicable). To clarify, when operative (present), the `NI2I` operator means that both an untargeted ACDC or targeted ACDC as the node pointed to by the edge may still be valid even when untargeted or if targeted even when the Issuer of the ACDC in which the edge appears is not the Issuee AID, of that node the edge points to.
The `DI2I` unary operator when present expands the class of allowed Issuer AIDs of the node the edge resides in to include not only the Issuee AID but also any delegated AIDS of the Issuee of the node the edge points to. This also means therefore that the ACDC node pointed to by the edge must also be a targeted ACDC.
If more than one of the `I2I`, `NI2I`, or `DI2I` operators appear in an operator, `o`, field list then the last one appearing in the list is the operative one.
When the operator, `o`, field is missing in an edge-group block. The default value for the operator, `o`, field is `AND`.
When the operator, `o`, field is missing or empty in an edge block, or is present but does not include any of the `I2I`, `NI2I` or `DI2I` operators then,
If the node pointed to by the edge is a targeted ACDC, i.e. has an Issuee, by default it is assumed that the `I2I` operator is appended to the operator, `o`, field's effective list value.
If the node pointed to by the edge block is a non-targeted ACDC i.e., does not have an Issuee, by default, it is assumed that the `NI2I` operator is appended to the operator, `o`, field's effective list value.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "NOT",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "OR",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"o": "NI2I",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"o": ["NI2I", "NOT"],
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
},
"food":
{
"o": "OR",
"power": "med",
"plum":
{
"n": "EQIYPvAu6DZAIl3AORH3dCdoFOLe71iheqcywJcnjtJt",
"o": "NI2I"
},
"pear":
{
"n": "EJtQIYPvAu6DZAIl3AORH3dCdoFOLe71iheqcywJcnjt",
"o": "NI2I"
}
}
}
}
```
When an ECR vLEI is issued by the QVI it is not chained, Issuer-to-Issuee, via the LE credential. A more accurate way of expressing the chaining would be to use the `AND` operator to include both the LE and QVI credentials as edges in the ECR and also to apply the unary `NI2I` to the LE credential instead of only chaining the ECR to the LE and not chaining to ECR to the QVI at all.
In the following example: The top-level edge-block uses the default of `AND` and the `qvi` edge uses the default of `I2I` because it points to a targeted ACDC. The `le` edge, on the other hand, points to a targeted ACDC. It uses the unary operator, `NI2I` in its operator, `o`, field so that it will be accepted it even though its targeted Issuee is not the Issuer of the current credential.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"qvi":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
},
"le":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "NI2I"
}
}
}
```
This provides a simple but highly expressive syntax for applying (m-ary) aggregating operators to nestable groups of edges and unary operators to edges individually within those groups. This is a general approach with high expressive power. It satisfies many business logic requirements similar to that of SGL.
Certainly, an even more expressive syntax could be developed. The proposed syntax, however, is relatively simple and compact. It has intelligent defaults and is sufficiently general in scope to satisfy all the currently contemplated use cases.
The intelligent defaults for the operator, `o`, field, including the default application of the `I2I` or `NI2I` unary operator, means that in most current use cases, the operator, `o`, field, does not even need to be present.
In general, the discovery of the details of an ACDC referenced as a node, `n` field value, in an edge sub-block begins with the node SAID or the SAID of the associated edge sub-block. Because a SAID is a cryptographic digest with high collision resistance it provides a universally unique identifier to the referenced ACDC as a node. The Discovery of a service endpoint URL that provides database access to a copy of the ACDC may be bootstrapped via an OOBI (Out-Of-Band-Introduction) that links the service endpoint URL to the SAID of the ACDC {{OOBI\_ID}}. Alternatively, the _Issuer_ may provide as an attachment at the time of issuance a copy of the referenced ACDC. In either case, after a successful exchange, the _Issuee_ or recipient of any ACDC will have either a copy or a means of obtaining a copy of any referenced ACDCs as nodes in the edge sections of all ACDCs so chained. That Issuee or recipient will then have everything it needs to make a successful disclosure to some other _Disclosee_. This is the essence of _percolated_ discovery.
In the compact ACDC examples above, the rule section has been compacted into merely the SAID of that section. Suppose that the un-compacted value of the rule section denoted by the top-level rule, `r`, field is as follows,
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
The purpose of the rule section is to provide a Ricardian Contract {{RC}}. The important features of a Ricardian contract are that it be both human and machine-readable and referenceable by a cryptographic digest. A JSON encoded document or block such as the rule section block is a practical example of both a human and machine-readable document. The rule section's top-level SAID, `d`, field provides the digest. This provision supports the bow-tie model of Ricardian Contracts {{RC}}. Ricardian legal contracts may be hierarchically structured into sections and subsections with named or numbered clauses in each section. The labels on the clauses may follow such a hierarchical structure using nested maps or blocks. These provisions enable the rule section to satisfy the features of a Ricardian contract.
To elaborate, the rule section's top-level SAID, `d`, field is the SAID of that block and is the same SAID used as the compacted value of the rule section, `r`, field that appears at the top level of the ACDC. Each clause in the rule section gets its own field. Each clause also has its own local label.
The legal, `l`, field in each block provides the associated legal language.
Note there are no type fields in the rule section. The type of a contract and the type of each clause is provided by the schema vis-a-vis the label of that clause. This follows the ACDC design principle that may be succinctly expressed as "type-is-schema".
Each rule section clause may also have its own clause SAID, `d`, field. Clause SAIDs enable reference to individual clauses, not merely the whole contract as given by the rule section's top-level SAID, `d`, field.
An example rule section with clause SAIDs is provided below.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
The use of clause SAIDS enables a compact form of a set of clauses where each clause value is the SAID of the corresponding clause. For example,
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"liabilityDisclaimer": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw"
}
}
```
The disclosure of some clauses may be pre-conditioned on acceptance of chain-link confidentiality. In this case, some clauses may benefit from partial disclosure. Thus clauses may be blinded by their SAID, `d`, field when the clause block includes a sufficiently high entropy UUID, `u`, field. The use of a clause UUID enables the compact form of a clause to NOT be discoverable merely from the schema for the clause and its SAID via rainbow table attack {{RB}}{{DRB}}. Therefore such a clause may be partially disclosable. These are called **_private clauses_**. A private clause example is shown below.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"u": "0AHcgNghkDaG7OY1wjaDAE0q",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
An alternate simplified compact form uses the value of the legal, `l`, field as the value of the clause field label. The schema for a specific clause label will indicate that the field value, for a given clause label is the legal language itself and not the clause block's SAID, `d`, field as is the normal compact form shown above. This alternate simple compact form is shown below. In this form individual clauses are not compactifiable and are fully self-contained.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE",
"liabilityDisclaimer": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
```
In compact form, the discovery of either the rule section as a whole or a given clause begins with the provided SAID. Because the SAID, `d`, field of any block is a cryptographic digest with high collision resistance it provides a universally unique identifier to the referenced block details (whole rule section or individual clause). The discovery of a service endpoint URL that provides database access to a copy of the rule section or to any of its clauses may be bootstrapped via an OOBI (Out-Of-Band-Introduction) that links the service endpoint URL to the SAID of the respective block {{OOBI\_ID}}. Alternatively, the issuer may provide as an attachment at issuance a copy of the referenced contract associated with the whole rule section or any clause. In either case, after a successful issuance exchange, the Issuee or holder of any ACDC will have either a copy or a means of obtaining a copy of any referenced contracts in whole or in part of all ACDCs so issued. That Issuee or recipient will then have everything it needs to subsequently make a successful presentation or disclosure to a Disclosee. This is the essence of percolated discovery.
The ACDC chaining enables disclosure-specific issuance of bespoke ACDCs. A given Discloser of an ACDC issued by some Issuer may want to augment the disclosure with additional contractual obligations or additional information sourced by the Discloser where those augmentations are specific to a given context such as a specific Disclosee. Instead of complicating the presentation exchange to accommodate such disclosure-specific augmentations, a given Disloser issues its own bespoke ACDC that includes the other ACDC of the other Issuer by reference via an edge in the bespoke ACDC. This means that the normal validation logic and tooling for a chained ACDC can be applied without complicating the presentation exchange logic. Furthermore, attributes in other ACDCs pointed to by edges in the bespoke ACDC may be addressed by attributes in the bespoke ACDC using JSON Pointer or CESR-Proof SAD Path references that are relative to the node SAID in the edge {{RFC6901}}{{Proof\_ID}}.
For example, this approach enables the bespoke ACDC to identify (name) the Disclosee directly as the Issuee of the bespoke ACDC. This enables contractual legal language in the rule section of the bespoke ACDC that reference the Issuee of that ACDC as a named party. Signing the agreement to the offer of that bespoke ACDC consummates a contract between named Issuer and named Issuee. This approach means that custom or bespoke presentations do not need additional complexity or extensions. Extensibility comes from reusing the tooling for issuing ACDCs to issue a bespoke or disclosure-specific ACDC. When the only purpose of the bespoke ACDC is to augment the contractual obligations associated with the disclosure then the attribute section, `a`, field value of the bespoke ACD may be empty or it may include properties whose only purpose is to support the bespoke contractual language.
Similarly, this approach effectively enables a type of _rich presentation_ or combined disclosure where multiple ACDCs may be referenced by edges in the bespoke ACDC that each contributes some attribute(s) to the effective set of attributes referenced in the bespoke ACDC. The bespoke ACDC enables the equivalent of a _rich presentation_ without requiring any new tooling {{Abuse}}.
Consider the following disclosure-specific ACDC. The Issuer is the Discloser, the Issuee is the Disclosee. The rule section includes a context-specific (anti) assimilation clause that limits the use of the information to a single one-time usage purpose, that is in this case, admittance to a restaurant. The ACDC includes an edge that references some other ACDC that may for example be a coupon or gift card. The attribute section includes the date and place of admittance.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "EGGeIZ8a8FWS7a646jrVPTzlSkUPqs4reAXRZOkogZ2A",
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"date": "2022-08-22T17:50:09.988921+00:00",
"place": "GoodFood Restaurant, 953 East Sheridan Ave, Cody WY 82414 USA"
},
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"other":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
},
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"Assimilation":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuee hereby explicitly and unambiguously agrees to NOT assimilate, aggregate, correlate, or otherwise use in combination with other information available to the Issuee, the information, in whole or in part, referenced by this container or any containers recursively referenced by the edge section, for any purpose other than that expressly permitted by the Purpose clause."
},
"Purpose":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "One-time admittance of Issuer by Issuee to eat at place on date as specified in attribute section."
}
}
}
```
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
},
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"s": "EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71",
"w": "high"
}
},
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
```
{
"$id": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Public ACDC",
"description": "Example JSON Schema Public ACDC.",
"credentialType": "PublicACDCExample",
"type": "object",
"required":
[
"v",
"d",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry ID",
"type": "string"
},
"s":
{
"description": "schema section",
"oneOf":
[
{
"description": "schema section SAID",
"type": "string"
},
{
"description": "schema detail",
"type": "object"
}
]
},
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute section SAID",
"type": "string"
},
{
"description": "attribute detail",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute section SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
},
"e":
{
"description": "edge section",
"oneOf":
[
{
"description": "edge section SAID",
"type": "string"
},
{
"description": "edge detail",
"type": "object",
"required":
[
"d",
"boss"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"boss":
{
"description": "boss edge",
"type": "object",
"required":
[
"d",
"n",
"s",
"w"
],
"properties":
{
"d":
{
"description": "edge SAID",
"type": "string"
},
"n":
{
"description": "far node SAID",
"type": "string"
},
"s":
{
"description": "far node schema SAID",
"type": "string",
"const": "EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71"
},
"w":
{
"description": "edge weight",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
},
"r":
{
"description": "rule section",
"oneOf":
[
{
"description": "rule section SAID",
"type": "string"
},
{
"description": "rule detail",
"type": "object",
"required":
[
"d",
"warrantyDisclaimer",
"liabilityDisclaimer"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"warrantyDisclaimer":
{
"description": "warranty disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
},
"liabilityDisclaimer":
{
"description": "liability disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
}
},
"additionalProperties": false
}
```
As explained previously, the primary difference between _partial disclosure_ and _selective disclosure_ is determined by the correlatability with respect to its encompassing block after _full disclosure_ of the detailed field value. A _partially disclosable_ field becomes correlatable to its encompassing block after its _full disclosure_. Whereas a _selectively disclosable_ field may be excluded from the _full disclosure_ of any other selectively disclosable fields in its encompassing block. After selective disclosure, the selectively disclosed fields are not correlatable to the so-far undisclosed but selectively disclosable fields in the same encompassing block. In this sense, _full disclosure_ means detailed disclosure of the selectively disclosed attributes not detailed disclosure of all selectively disclosable attributes.
Recall that _partial_ disclosure is an essential mechanism needed to support chain-link confidentiality {{CLC}}. The chain-link confidentiality exchange _offer_ requires _partial disclosure_, and _full disclosure_ only happens after _acceptance_ of the _offer_. _Selective_ disclosure, on the other hand, is an essential mechanism needed to unbundle in a correlation minimizing way a single commitment by an Issuer to a bundle of fields (i.e. a nested block or array of fields). This allows separating a "stew" of "ingredients" (attributes) into its constituent "ingredients" (attributes) without correlating the constituents via the stew.
ACDCs, as a standard, benefit from a minimally sufficient approach to selective disclosure that is simple enough to be universally implementable and adoptable. This does not preclude support for other more sophisticated but optional approaches. But the minimally sufficient approach should be universal so that at least one selective disclosure mechanism be made available in all ACDC implementations. To clarify, not all instances of an ACDC must employ the minimal selective disclosure mechanisms as described herein but all ACDC implementations must support any instance of an ACDC that employs the minimal selective disclosure mechanisms as described above.
The ACDC chaining mechanism reduces the need for selective disclosure in some applications. Many non-ACDC verifiable credentials provide bundled precisely because there is no other way to associate the attributes in the bundle. These bundled credentials could be refactored into a graph of ACDCs. Each of which is separately disclosable and verifiable thereby obviating the need for selective disclosure.
Nonetheless, some applications require bundled attributes and therefore may benefit from the independent selective disclosure of bundled attributes. This is provided by **_selectively disclosable attribute_** ACDCs.
The use of a revocation registry is an example of a type of bundling, not of attributes in a credential, but uses of a credential in different contexts. Unbundling the usage contexts may be beneficial. This is provided by **_bulk-issued_** ACDCs.
Finally, in the case where the correlation of activity of an Issuee across contexts even when the ACDC used in those contexts is not correlatable may be addressed of a variant of bulk-issued ACDCs that have **_unique issuee AIDs_** with an independent TEL registry per issuee instance. This provides non-repudiable (recourse supporting) disclosure while protecting from the malicious correlation between second parties and other second and/or third-parties as to who (Issuee) is involved in a presentation.
In any case, the set of selective disclosure mechanisms we call tiered selective disclosure which allows a user or implementer to better trade-off protection vs. complexity and performance. A tiered selective disclosure me
The basic selective disclosure mechanism shared by all is comprised of a single aggregated blinded commitment to a list of blinded commitments to undisclosed values. Membership of any blinded commitment to a value in the list of aggregated blinded commitments may be proven without leaking (disclosing) the unblinded value belonging to any other blinded commitment in the list. This enables provable selective disclosure of the unblinded values. When a non-repudiable digital signature is created on the aggregated blinded commitment then any disclosure of a given value belonging to a given blinded commitment in the list is also non-repudiable. This approach does not require any more complex cryptography than digests and digital signatures. This satisfies the design ethos of minimally sufficient means. The primary drawback of this approach is verbosity. It trades ease and simplicity and _adoptability_ of implementation for size. Its verbosity may be mitigated by replacing the list of blinded commitments with a Merkle tree of those commitments where the Merkle tree root becomes the aggregated blinded commitment.
Given sufficient cryptographic entropy of the blinding factors, collision resistance of the digests, and unforgeability of the digital signatures, either inclusion proof format (list or Merkle tree digest) prevents a potential disclosee or adversary from discovering in a computationally feasible way the values of any undisclosed blinded value details from the combination of the schema of those value details and either the aggregated blinded commitment and/or the list of aggregated blinded commitments {{Hash}}{{HCR}}{{QCHC}}{{Mrkl}}{{TwoPI}}{{MTSec}}. A potential disclosee or adversary would also need both the blinding factor and the actual value details.
Selective disclosure in combination with partial disclosure for chain-link confidentiality provides comprehensive correlation minimization because a discloser may use a non-disclosing metadata ACDC prior to acceptance by the disclosee of the terms of the chain-link confidentiality expressed in the rule section {{CLC}}. Thus only malicious disclosees who violate chain-link confidentiality may correlate between independent disclosures of the value details of distinct members in the list of aggregated blinded commitments. Nonetheless, they are not able to discover any as-of-yet undisclosed (unblinded) value details.
In a **_selectively disclosable attribute_** ACDC, the set of attributes is provided as an array of blinded blocks. Each attribute in the set has its own dedicated blinded block. Each block has its own SAID, `d`, field and UUID, `u`, field in addition to its attribute field or fields. When an attribute block has more than one attribute field then the set of fields in that block are not independently selectively disclosable but MUST be disclosed together as a set. Notable is that the field labels of the selectively disclosable attributes are also blinded because they only appear within the blinded block. This prevents un-permissioned correlation via contextualized variants of a field label that appear in a selectively disclosable block. For example, localized or internationalized variants where each variant's field label(s) each use a different language or some other context correlatable information in the field labels themselves.
A selectively-disclosable attribute section appears at the top level using the field label `A`. This is distinct from the field label `a` for a non-selectively-disclosable attribute section. This makes clear (unambiguous) the semantics of the attribute section's associated schema. This also clearly reflects the fact that the value of a compact variant of selectively-disclosable attribute section is an "aggregate" not a SAID. As described previously, the top-level selectively-disclosable attribute aggregate section, `A`, field value is an aggregate of cryptographic commitments used to make a commitment to a set (bundle) of selectively-disclosable attributes. The derivation of its value depends on the type of selective disclosure mechanism employed. For example, the aggregate value could be the cryptographic digest of the concatenation of an ordered set of cryptographic digests, a Merkle tree root digest of an ordered set of cryptographic digests, or a cryptographic accumulator.
The _Issuee_ attribute block is absent from an uncompacted untargeted selectively disclosable ACDC as follows:
```
{
"A":
[
{
"d": "ELIr9Bf7V_NHwY1lkgveY4-Frn9y2PY9XgOcLxUderzw",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"score": 96
},
{
"d": "E9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-",
"u": "0AghkDaG7OY1wjaDAE0qHcgN",
"name": "Jane Doe"
}
]
}
```
The _Issuee_ attribute block is present in an uncompacted untargeted selectively disclosable ACDC as follows:
```
{
"A":
[
{
"d": "ErzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-9XgOcLxUde",
"u": "0AqHcgNghkDaG7OY1wjaDAE0",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA"
},
{
"d": "ELIr9Bf7V_NHwY1lkgveY4-Frn9y2PY9XgOcLxUderzw",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"score": 96
},
{
"d": "E9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-",
"u": "0AghkDaG7OY1wjaDAE0qHcgN",
"name": "Jane Doe"
}
]
}
```
Given that each attribute block's UUID, `u`, field has sufficient cryptographic entropy, then each attribute block's SAID, `d`, field provides a secure cryptographic digest of its contents that effectively blinds the attribute value from discovery given only its Schema and SAID. To clarify, the adversary despite being given both the schema of the attribute block and its SAID, `d`, field, is not able to discover the remaining contents of the attribute block in a computationally feasible manner such as a rainbow table attack {{RB}}{{DRB}}. Therefore the UUID, `u`, field of each attribute block enables the associated SAID, `d`, field to securely blind the block's contents notwithstanding knowledge of the block's schema and that SAID, `d`, field. Moreover, a cryptographic commitment to that SAID, `d`, field does not provide a fixed point of correlation to the associated attribute (SAD) field values themselves unless and until there has been specific disclosure of those field values themselves.
Given a total of _N_ elements in the attributes array, let _ai_ represent the SAID, `d`, field of the attribute at zero-based index _i_. More precisely the set of attributes is expressed as the ordered set,
_{ai for all i in {0, ..., N-1}}_.
The ordered set of _ai_ may be also expressed as a list, that is,
_\[a0, a1, ...., aN-1\]_.
Because the selectively-disclosable attributes are provided by an array (list), the uncompacted variant in the schema uses an array of items and the `anyOf` composition operator to allow one or more of the items to be disclosed without requiring all to be disclosed. Thus both the `oneOf` and `anyOf` composition operators are used. The `oneOf` is used to provide compact partial disclosure of the aggregate, _A_, as the value of the top-level selectively-disclosable attribute section, `A`, field in its compact variant and the nested `anyOf` operator is used to enable selective disclosure in the uncompacted selectively-disclosable variant.
```
{
"A":
{
"description": "selectively disclosable attribute aggregate section",
"oneOf":
[
{
"description": "attribute aggregate",
"type": "string"
},
{
"description": "selectively disclosable attribute details",
"type": "array",
"uniqueItems": true,
"items":
{
"anyOf":
[
{
"description": "issuer attribute",
"type": "object",
"required":
[
"d",
"u",
"i"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"i":
{
"description": "issuer SAID",
"type": "string"
}
},
"additionalProperties": false
},
{
"description": "score attribute",
"type": "object",
"required":
[
"d",
"u",
"score"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"score":
{
"description": "score value",
"type": "integer"
}
},
"additionalProperties": false
},
{
"description": "name attribute",
"type": "object",
"required":
[
"d",
"u",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"name":
{
"description": "name value",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
],
"additionalProperties": false
}
}
```
All the _ai_ in the list are aggregated into a single aggregate digest denoted _A_ by computing the digest of their ordered concatenation. This is expressed as follows:
_A = H(C(ai for all i in {0, ..., N-1}))_ where _H_ is the digest (hash) operator and _C_ is the concatentation operator.
To be explicit, using the targeted example above, let _a0_ denote the SAID of the _Issuee_ attribute, _a1_ denote the SAID of the _score_ attribute, and _a2_ denote the SAID of the _name_ attribute then the aggregated digest _A_ is computed as follows:
_A = H(C(a0, a1, a2))_.
Equivalently using _+_ as the infix concatenation operator, we have,
_A = H(a0 + a1 + a2)_
Given sufficient collision resistance of the digest operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements {{BDC}}{{BDay}}{{QCHC}}{{HCR}}{{Hash}}.
In compact form, the value of the selectively-disclosable top-level attribute section, `A`, field is set to the aggregated value _A_. This aggregate _A_ makes a blinded cryptographic commitment to the all the ordered elements in the list,
_\[a0, a1, ...., aN-1\]_.
Moreover because each _ai_ element also makes a blinded commitment to its block's (SAD) attribute value(s), disclosure of any given _ai_ element does not expose or disclose any discoverable information detail about either its own or another block's attribute value(s). Therefore one may safely disclose the full list of _ai_ elements without exposing the blinded block attribute values.
Proof of inclusion in the list consists of checking the list for a matching value. A computationally efficient way to do this is to create a hash table or B-tree of the list and then check for inclusion via lookup in the hash table or B-tree.
To protect against later forgery given a later compromise of the signing keys of the Issuer, the issuer MUST anchor an issuance proof digest seal to the ACDC in its KEL. This seal binds the signing key state to the issuance. There are two cases. In the first case, an issuance/revocation registry is used. In the second case, an issuance/revocation registry is not used.
When the ACDC is registered using an issuance/revocation TEL (Transaction Event Log) then the issuance proof seal digest is the SAID of the issuance (inception) event in the ACDC's TEL entry. The issuance event in the TEL includes the SAID of the ACDC. This binds the ACDC to the issuance proof seal in the Issuer's KEL through the TEL entry.
When the ACDC is not registered using an issuance/revocation TEL then the issuance proof seal digest is the SAID of the ACDC itself.
In either case, this issuance proof seal makes a verifiable binding between the issuance of the ACDC and the key state of the Issuer at the time of issuance. Because aggregated value _A_ provided as the attribute section, `A`, field, value is bound to the SAID of the ACDC which is also bound to the key state via the issuance proof seal, the attribute details of each attribute block are also bound to the key state.
The requirement of an anchored issuance proof seal means that the forger Must first successfully publish in the KEL of the issuer an inclusion proof digest seal bound to a forged ACDC. This makes any forgery attempt detectable. To elaborate, the only way to successfully publish such a seal is in a subsequent interaction event in a KEL that has not yet changed its key state via a rotation event. Whereas any KEL that has changed its key state via a rotation must be forked before the rotation. This makes the forgery attempt either both detectable and recoverable via rotation in any KEL that has not yet changed its key state or detectable as duplicity in any KEL that has changed its key state. In any event, the issuance proof seal ensures detectability of any later attempt at forgery using compromised keys.
Given that aggregate value _A_ appears as the compact value of the top-level attribute section, `A`, field, the selective disclosure of the attribute at index _j_ may be proven to the disclosee with four items of information. These are:
- The actual detailed disclosed attribute block itself (at index _j_) with all its fields.
- The list of all attribute block digests, _\[a0, a1, ...., aN-1\]_ that includes _aj_.
- The ACDC in compact form with selectively-disclosable attribute section, `A`, field value set to aggregate _A_.
- The signature(s), _s_, of the Issuee on the ACDC's top-level SAID, `d`, field.
The actual detailed disclosed attribute block is only disclosed after the disclosee has agreed to the terms of the rules section. Therefore, in the event the potential disclosee declines to accept the terms of disclosure, then a presentation of the compact version of the ACDC and/or the list of attribute digests, _\[a0, a1, ...., aN-1\]_. does not provide any point of correlation to any of the attribute values themselves. The attributes of block _j_ are hidden by _aj_ and the list of attribute digests _\[a0, a1, ...., aN-1\]_ is hidden by the aggregate _A_. The partial disclosure needed to enable chain-link confidentiality does not leak any of the selectively disclosable details.
The disclosee may then verify the disclosure by:
- computing _aj_ on the selectively disclosed attribute block details.
- confirming that the computed _aj_ appears in the provided list _\[a0, a1, ...., aN-1\]_.
- computing _A_ from the provided list _\[a0, a1, ...., aN-1\]_.
- confirming that the computed _A_ matches the value, _A_, of the selectively-disclosable attribute section, `A`, field value in the provided ACDC.
- computing the top-level SAID, `d`, field of the provided ACDC.
- confirming the presence of the issuance seal digest in the Issuer's KEL
- confirming that the issuance seal digest in the Issuer's KEL is bound to the ACDC top-level SAID, `d`, field either directly or indirectly through a TEL registry entry.
- verifying the provided signature(s) of the Issuee on the provided top-level SAID, `d` field value.
The last 3 steps that culminate with verifying the signature(s) require determining the key state of the Issuer at the time of issuance, this may require additional verification steps as per the KERI, PTEL, and CESR-Proof protocols.
A private selectively disclosable ACDC provides significant correlation minimization because a presenter may use a metadata ACDC prior to acceptance by the disclosee of the terms of the chain-link confidentiality expressed in the rule section {{CLC}}. Thus only malicious disclosees who violate chain-link confidentiality may correlate between presentations of a given private selectively disclosable ACDC. Nonetheless, they are not able to discover any undisclosed attributes.
The inclusion proof via aggregated list may be somewhat verbose when there are a large number of attribute blocks in the selectively disclosable attribute section. A more efficient approach is to create a Merkle tree of the attribute block digests and let the aggregate, _A_, be the Merkle tree root digest {{Mrkl}}. Specifically, set the value of the top-level selectively-disclosable attribute section, `A`, field to the aggregate, _A_ whose value is the Merkle tree root digest {{Mrkl}}.
The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes {{TwoPI}}{{MTSec}}. The discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, _aj_ contributed to the Merkle tree root digest, _A_. For ACDCs with a small number of attributes the added complexity of the Merkle tree approach may not be worth the savings in verbosity.
The amount of data transferred between the Issuer and Issuee (or recipient in the case of an untargeted ACDC) at issuance of a selectively disclosable attribute ACDC may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUDI, `u`, fields from a shared secret salt {{Salt}}.
There are several ways that the Issuer may securely share that secret salt. Given that an Ed25519 key pair(s) controls each of the Issuer and Issuee AIDs, (or recipient AID in the case of an untargeted ACDC) a corresponding X15519 asymmetric encryption key pair(s) may be derived from each controlling Ed25519 key pair(s) {{EdSC}}{{PSEd}}{{TMEd}}{{SKEM}}. An X25519 public key may be securely derived from an Ed25519 public key {{KeyEx}}{{SKEM}}. Likewise, an X25519 private key may be securely derived from an Ed25519 private key {{KeyEx}}{{SKEM}}.
In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key {{KeyEx}}{{DHKE}}. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived.
In a non-interactive approach, the Issuer derives an X25519 asymmetric public encryption key from the Issuee's (recipient's) public Ed25519 public key. The Issuer then encrypts the secret salt with that public asymmetric encryption key and signs the encryption with the Issuer's private Ed25519 signing key. This is transmitted to the Issuee, who verifies the signature and decrypts the secret salt using the private X25519 decryption key derived from the Issuee's private Ed25519 key. This non-interactive approach is more scalable for AIDs that are controlled with a multi-sig group of signing keys. The Issuer can broadcast to all members of the Issuee's (or recipient's) multi-sig signing group individually asymmetrically encrypted and signed copies of the secret salt.
In addition to the secret salt, the Issuer provides to the Issuee (recipient) a template of the ACDC but with empty UUID, `u`, and SAID, `d`, fields in each block with such fields. Each UUID, `u`, field value is then derived from the shared salt with a path prefix that indexes a specific block. Given the UUID, `u`, field value, the SAID, `d`, field value may then be derived. Likewise, both compact and uncompacted versions of the ACDC may then be generated. The derivation path for the top-level UUID, `u`, field (for private ACDCS), is the string "0" and derivation path the the the zeroth indexed attribute in the attributes array is the string "0/0". Likewise, the next attribute's derivation path is the string "0/1" and so forth.
In addition to the shared salt and ACDC template, the Issuer also provides its signature(s) on its own generated compact version ACDC. The Issuer may also provide references to the anchoring issuance proof seals. Everything else an Issuee (recipient) needs to make a verifiable presentation/disclosure can be computed at the time of presentation/disclosure by the Issuee.
The purpose of bulk issuance is to enable the Issuee to more efficiently use ACDCs with unique SAIDs to isolate and minimize correlation across different usage contexts. Each member of a set of bulk-issued ACDCs is essentially the same ACDC but with a unique SAID. This enables public commitments to each of the unqiue ACDC SAIDs without correlating between them. A private ACDC may be effectively issued in bulk as a set. In its basic form, the only difference between each ACDC is the top-level SAID, _d_, and UUID, _u_ field values. To elaborate, bulk issuance enables the use of un-correlatable copies while minimizing the associated data transfer and storage requirements involved in the issuance. Essentially each copy (member) of a bulk issued ACDC set shares a template that both the Issuer and Issuee use to generate on-the-fly a given ACDC in that set without requiring that the Issuer and Issuee exchange and store a unique copy of each member of the set independently. This minimizes the data transfer and storage requirements for both the Issuer and the Issuee. The Issuer is only required to provide a single signature for the bulk issued aggregate value _B_ defined below. The same signature may be used to provide proof of issuance of any member of the bulk issued set. The signature on _B_ and _B_ itself are points of correlation but these need only be disclosed after contractually protected disclosure is in place, i.e no permissioned correlation. Thus correlation requires a colluding second party who enagages in unpermissioned correlation.
An ACDC provenance chain is connected via references to the SAIDs given by the top-level SAID, `d`, fields of the ACDCs in that chain. A given ACDC thereby makes commitments to other ACDCs. Expressed another way, an ACDC may be a node in a directed graph of ACDCs. Each directed edge in that graph emanating from one ACDC includes a reference to the SAID of some other connected ACDC. These edges provide points of correlation to an ACDC via their SAID reference. Private bulk issued ACDCs enable the Issuee to better control the correlatability of presentations using different presentation strategies.
For example, the Issuee could use one copy of a bulk-issued private ACDC per presentation even to the same verifier. This strategy would consume the most copies. It is essentially a one-time-use ACDC strategy. Alternatively, the Issuee could use the same copy for all presentations to the same verifier and thereby only permit the verifier to correlate between presentations it received directly but not between other verifiers. This limits the consumption to one copy per verifier. In yet another alternative, the Issuee could use one copy for all presentations in a given context with a group of verifiers, thereby only permitting correlation among that group.
In this context, we are talking about permissioned correlation. Any verifier that has received a complete presentation of a private ACDC has access to all the fields disclosed by the presentation but the terms of the chain-link confidentiality agreement may forbid sharing those field values outside a given context. Thus an Issuee may use a combination of bulk issued ACDCs with chain-link confidentiality to control permissioned correlation of the contents of an ACDC while allowing the SAID of the ACDC to be more public. The SAID of a private ACDC does not expose the ACDC contents to an un-permissioned third party. Unique SAIDs belonging to bulk issued ACDCs prevent third parties from making a provable correlation between ACDCs via their SAIDs in spite of those SAIDs being public. This does not stop malicious verifiers (as second parties) from colluding and correlating against the disclosed fields but it does limit provable correlation to the information disclosed to a given group of malicious colluding verifiers. To restate unique SAIDs per copy of a set of private bulk issued ACDC prevent un-permissioned third parties from making provable correlations, in spite of those SAIDs being public, unless they collude with malicious verifiers (second parties).
In some applications, chain-link-confidentiality is insufficient to deter un-permissioned correlation. Some verifiers may be malicious with sufficient malicious incentives to overcome whatever counter incentives the terms of the contractual chain-link confidentiality may impose. In these cases, more aggressive technological anti-correlation mechanisms such as bulk issued ACDCs may be useful. To elaborate, in spite of the fact that chain-link confidentiality terms of use may forbid such malicious correlation, making such correlation more difficult technically may provide better protection than chain-link confidentiality alone {{CLC}}.
It is important to note that any group of colluding malicious verifiers may always make a statistical correlation between presentations despite technical barriers to cryptographically provable correlation. We call this contextual linkability. In general, there is no cryptographic mechanism that precludes statistical correlation among a set of colluding verifiers because they may make cryptographically unverifiable or unprovable assertions about information presented to them that may be proven as likely true using merely statistical correlation techniques. Linkability due the context of the disclosure itself may defeat any unlinkability guarantees of a cryptographic technique. Thus without contractually protected disclosure, contextual linkability in spite of cryptographic unlinkability may make the complexity of using advanced cryptographic mechanisms to provide unlinkability an exercise in diminishing returns.
The amount of data transferred between the Issuer and Issuee (or recipient of an untargeted ACDC) at issuance of a set of bulk issued ACDCs may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUID, `u`, fields from a shared secret salt {{Salt}}.
As described above, there are several ways that the Issuer may securely share a secret salt. Given that the Issuer and Issuee (or recipient when untargeted) AIDs are each controlled by an Ed25519 key pair(s), a corresponding X15519 asymmetric encryption key pair(s) may be derived from the controlling Ed25519 key pair(s) {{EdSC}}{{PSEd}}{{TMEd}}. An X25519 public key may be securely derived from an Ed25519 public key {{KeyEx}}{{SKEM}}. Likewise, an X25519 private key may be securely derived from an Ed25519 private key {{KeyEx}}{{SKEM}}.
In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key {{KeyEx}}{{DHKE}}. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived.
In a non-interactive approach, the Issuer derives an X25519 asymmetric public encryption key from the Issuee's (or recipient's) public Ed25519 public key. The Issuer then encrypts the secret salt with that public asymmetric encryption key and signs the encryption with the Issuer's private Ed25519 signing key. This is transmitted to the Issuee, who verifies the signature and decrypts the secret salt using the private X25519 decryption key derived from the Issuee's private Ed25519 key. This non-interactive approach is more scalable for AIDs that are controlled with a multi-sig group of signing keys. The Issuer can broadcast to all members of the Issuee's (or recipient's) multi-sig signing group individually asymmetrically encrypted and signed copies of the secret salt.
In addition to the secret salt, the Issuer also provides a template of the private ACDC but with empty UUID, `u`, and SAID, `d`, fields at the top-level of each nested block with such fields. Each UUID, `u`, field value is then derived from the shared salt with a deterministic path prefix that indexes both its membership in the bulk issued set and its location in the ACDC. Given the UUID, `u`, field value, the associated SAID, `d`, field value may then be derived. Likewise, both full and compact versions of the ACDC may then be generated. This generation is analogous to that described in the section for selective disclosure ACDCs but extended to a set of private ACDCs.
The initial element in each deterministic derivation path is the string value of the bulk-issued member's copy index _k_, such as "0", "1", "2" etc. Specifically, if _k_ denotes the index of an ordered set of bulk issued private ACDCs of size _M_, the derivation path starts with the string _"k"_ where _k_ is replaced with the decimal or hexadecimal textual representation of the numeric index _k_. Furthermore, a bulk-issued private ACDC with a private attribute section uses _"k"_ to derive its top-level UUID and _"k/0"_ to derive its attribute section UUID. This hierarchical path is extended to any nested private attribute blocks. This approach is further extended to enable bulk issued selective disclosure ACDCs by using a similar hierarchical derivation path for the UUID field value in each of the selectively disclosable blocks in the array of attributes. For example, the path _"k/j"_ is used to generate the UUID of attribute index _j_ at bulk-issued ACDC index _k_.
In addition to the shared salt and ACDC template, the Issuer also provides a list of signatures of SAIDs, one for each SAID of each copy of the associated compact bulk-issued ACDC. The Issuee (or recipient) can generate on-demand each compact or uncompacted ACDC from the template, the salt, and its index _k_. The Issuee does not need to store a copy of each bulk issued ACDC, merely the template, the salt, and the list of signatures.
The Issuer MUST also anchor in its KEL an issuance proof digest seal of the set of bulk issued ACDCs. The issuance proof digest seal makes a cryptographic commitment to the set of top-level SAIDS belonging to the bulk issued ACDCs. This protects against later forgery of ACDCs in the event the Issuer's signing keys become compromised. A later attempt at forgery requires a new event or new version of an event that includes a new anchoring issuance proof digest seal that makes a cryptographic commitment to the set of newly forged ACDC SAIDS. This new anchoring event of the forgery is therefore detectable.
Similarly, to the process of generating a selective disclosure attribute ACDC, the issuance proof digest is an aggregate that is aggregated from all members in the bulk-issued set of ACDCs. The complication of this approach is that it must be done in such a way as to not enable provable correlation by a third party of the actual SAIDS of the bulk-issued set of ACDCs. Therefore the actual SAIDs must not be aggregated but blinded commitments to those SAIDs instead. With blinded commitments, knowledge of any or all members of such a set does not disclose the membership of any SAID unless and until it is unblinded. Recall that the purpose of bulk issuance is to allow the SAID of an ACDC in a bulk issued set to be used publicly without correlating it in an un-permissioned provable way to the SAIDs of the other members.
The basic approach is to compute the aggregate denoted, _B_, as the digest of the concatenation of a set of blinded digests of bulk issued ACDC SAIDS. Each ACDC SAID is first blinded via concatenation to a UUID (salty nonce) and then the digest of that concatenation is concatenated with the other blinded SAID digests. Finally, a digest of that concatenation provides the aggregate.
Suppose there are _M_ ACDCs in a bulk issued set. Using zero-based indexing for each member of the bulk issued set of ACDCs, such that index _k_ satisfies _k in {0, ..., M-1}, let_ dk _denote the top-level SAID of an ACDC in an ordered set of bulk-issued ACDCs. Let_ vk _denote the UUID (salty nonce) or blinding factor that is used to blind that said. The blinding factor,_ vk_, is NOT the top-level UUID, `u`, field of the ACDC itself but an entirely different UUID used to blind the ACDC's SAID for the purpose of aggregation. The derivation path for_ vk _from the shared secret salt is_ "k." _where_ k\* is the index of the bulk-issued ACDC.
Let _ck = vk + dk_, denote the blinding concatenation where _+_ is the infix concatenation operator. Then the blinded digest, _bk_, is given by, _bk = H(ck) = H(vk + dk)_, where _H_ is the digest operator. Blinding is performed by a digest of the concatenation of the binding factor, _vk_, with the SAID, _dk_ instead of XORing the two. An XOR of two elements whose bit count is much greater than 2 is not vulnerable to a birthday table attack {{BDay}}{{DRB}}{{BDC}}. In order to XOR, however, the two must be of the same length. Different SAIDs MAY be of different lengths, however, and MAY therefore require different length blinding factors. Because concatenation is length independent it is simpler to implement.
The aggregation of blinded digests, _B_, is given by, _B = H(C(bk for all k in {0, ..., M-1}))_, where _C_ is the concatenation operator and _H_ is the digest operator. This aggregate, _B_, provides the issuance proof digest.
The aggregate, _B_, makes a blinded cryptographic commitment to the ordered elements in the list _\[b0, b1, ...., bM-1\]_. A commitment to _B_ is a commitment to all the _bk_ and hence all the dk.
Given sufficient collision resistance of the digest operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements {{BDC}}{{BDay}}{{QCHC}}{{HCR}}{{Hash}}.
Disclosure of any given _bk_ element does not expose or disclose any discoverable information detail about either the SAID of its associated ACDC or any other ACDC's SAID. Therefore one may safely disclose the full list of _bk_ elements without exposing the blinded bulk issued SAID values, dk.
Proof of inclusion in the list of blinded digests consists of checking the list for a matching value. A computationally efficient way to do this is to create a hash table or B-tree of the list and then check for inclusion via lookup in the hash table or B-tree.
A proof of inclusion of an ACDC in a bulk-issued set requires disclosure of _vk_ which is only disclosed after the disclosee has accepted (agreed to) the terms of the rule section. Therefore, in the event the _Disclosee_ declines to accept the terms of disclosure, then a presentation/disclosure of the compact version of the ACDC does not provide any point of correlation to any other SAID of any other ACDC from the bulk set that contributes to the aggregate _B_. In addition, because the other SAIDs are hidden by each _bk_ inside the aggregate, _B_, even a presentation/disclosure of, _\[b0, b1, ...., bM-1\]_ does not provide any point of correlation to the actual bulk-issued ACDC without disclosure of its _vk_. Indeed if the _Discloser_ uses a metadata version of the ACDC in its _offer_ then even its SAID is not disclosed until after acceptance of terms in the rule section.
To protect against later forgery given a later compromise of the signing keys of the Issuer, the issuer MUST anchor an issuance proof seal to the ACDC in its KEL. This seal binds the signing key state to the issuance. There are two cases. In the first case, an issuance/revocation registry is used. In the second case, an issuance/revocation registry is not used.
When the ACDC is registered using an issuance/revocation TEL (Transaction Event Log) then the issuance proof seal digest is the SAID of the issuance (inception) event in the ACDC's TEL entry. The issuance event in the TEL uses the aggregate value, _B_, as its identifier value. This binds the aggregate, _B_, to the issuance proof seal in the Issuer's KEL through the TEL.
Recall that the usual purpose of a TEL is to provide a verifiable data registry that enables dynamic revocation of an ACDC via a state of the TEL. A verifier checks the state at the time of use to check if the associated ACDC has been revoked. The Issuer controls the state of the TEL. The registry identifier, `ri`, field is used to identify the public registry which usually provides a unique TEL entry for each ACDC. Typically the identifier of each TEL entry is the SAID of the TEL's inception event which is a digest of the event's contents which include the SAID of the ACDC. In the bulk issuance case, however, the TEL's inception event contents include the aggregate, _B_, instead of the SAID of a given ACDC. Recall that the goal is to generate an aggregate value that enables an Issuee to selectively disclose one ACDC in a bulk-issued set without leaking the other members of the set to un-permissioned parties (second or third). Using the aggregate, _B_ of blinded ACDC saids as the TEL registry entry identifier allows all members of the bulk-issued set to share the same TEL without any third party being able to discover which TEL any ACDC is using in an un-permissioned provable way. Moreover, a second party may not discover in an un-permissioned way any other ACDCs from the bulk-issued set not specifically disclosed to that second party. In order to prove to which TEL a specific bulk issued ACDC belongs, the full inclusion proof must be disclosed.
When the ACDC is not registered using an issuance/revocation TEL then the issuance proof seal digest is the aggregate, _B_, itself.
In either case, this issuance proof seal makes a verifiable binding between the issuance of all the ACDCs in the bulk issued set and the key state of the Issuer at the time of issuance.
A _Discloser_ may make a basic provable non-repudiable selective disclosure of a given bulk issued ACDC, at index _k_ by providing to the _Disclosee_ four items of information (proof of inclusion). These are as follows:
- The ACDC in compact form (at index _k_) where _dk_ as the value of its top-level SAID, `d`, field.
- The blinding factor, _vk_ from which _bk = H(vk + dk)_ may be computed.
- The list of all blinded SAIDs, _\[b0, b1, ...., bM-1\]_ that includes _bk_.
- A reference to the anchoring seal in the Issuer's KEL or TEL that references the aggregate _B_. The event that references the seal or the TEL event that references _B_ must be signed by the issuer so the signature on either event itself is sufficient to prove authorized issuance.
The aggregate _B_ is a point of unpermissioned correlation but not permissioned correlation. To remove _B_ as a point of unpermissioned correlation requires using _independent TEL bulk-issued ACDCs_ described in the section so named below.
A _Disclosee_ may then verify the disclosure by:
- computing _dj_ on the disclosed compact ACDC.
- computing _bk = H(vk + dk)_
- confirming that the computed _bk_ appears in the provided list _\[b0, b1, ...., bM-1\]_.
- computing the aggregate _B_ from the provided list _\[b0, b1, ...., bM-1\]_..
- confirming the presence of an issuance seal digest in the Issuer's KEL that makes a commitment to the aggregate, _B_, either directly or indirectly through a TEL registry entry. This provides proof of authorized issuance.
The last 3 steps that culminate with verifying the anchoring seal also require verifying the key state of the Issuer at the time of issuance, this may require additional verification steps as per the KERI, PTEL, and CESR-Proof protocols.
The requirement of an anchored issuance proof seal of the aggregate _B_ means that the forger MUST first successfully publish in the KEL of the issuer an inclusion proof digest seal bound to a set of forged bulk issued ACDCs. This makes any forgery attempt detectable. To elaborate, the only way to successfully publish such a seal is in a subsequent interaction event in a KEL that has not yet changed its key state via a rotation event. Whereas any KEL that has changed its key state via a rotation must be forked before the rotation. This makes the forgery attempt either both detectable and recoverable via rotation in any KEL that has not yet changed its key state or detectable as duplicity in any KEL that has changed its key state. In any event, the issuance proof seal makes any later attempt at forgery using compromised keys detectable.
The inclusion proof via aggregated list may be somewhat verbose when there are a very large number of bulk issued ACDCs in a given set. A more efficient approach is to create a Merkle tree of the blinded SAID digests, _bk_ and set the aggregate _B_ value as the Merkle tree root digest {{Mrkl}}.
The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes {{TwoPI}}{{MTSec}}. The discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, _bk_ contributed to the Merkle tree root digest. For a small numbered bulk-issued set of ACDCs, the added complexity of the Merkle tree approach may not be worth the savings in verbosity.
One potential point of provable but un-permissioned correlation among any group of colluding malicious _Disclosees_ (Second-Party verifiers) may arise when the same Issuee AID is used for presentation/disclosure to all _Disclosees_ in that group. Recall that the contents of private ACDCs are not disclosed except to permissioned _Disclosees_ (Second-Parties). Thus a common _Issuee_ AID would only be a point of correlation for a group of colluding malicious verifiers. But in some cases removing this un-permissioned point of correlation may be desirable.
One solution to this problem is for the _Issuee_ to use a unique AID for the copy of a bulk-issued ACDC presented to each _Disclosee_ in a given context. This requires that each ACDC copy in the bulk-issued set use a unique _Issuee_ AID. This would enable the _Issuee_ in a given context to minimize provable correlation by malicious _Disclosees_ against any given _Issuee_ AID. In this case, the bulk issuance process may be augmented to include the derivation of a unique Issuee AID in each copy of the bulk-issued ACDC by including in the inception event that defines a given Issuee's self-addressing AID, a digest seal derived from the shared salt and copy index _k_. The derivation path for the digest seal is _"k/0."_ where _k_ is the index of the ACDC. To clarify _"k/0."_ specifies the path to generate the UUID to be included in the inception event that generates the Issuee AID for the ACDC at index _k_. This can be generated on-demand by the _Issuee_. Each unique _Issuee_ AID would also need its own KEL. But generation and publication of the associated KEL can be delayed until the bulk-issued ACDC is actually used. This approach completely isolates a given _Issuee_ AID to a given context with respect to the use of a bulk-issued private ACDC. This protects against even the un-permissioned correlation among a group of malicious Disclosees (Second Parties) via the Issuee AID.
In some applications, it is desirable that the current state of a transaction event log (TEL) be hidden or blinded such that the only way for a potential verifier of the state to observe that state is when the controller of a designated AID discloses it at the time of presentation. This designated AID we call the Discloser. Typically for ACDCs that have an Issuee, the Discloser is the Issuee, but the Issuer could designate any AID as the Discloser. Only the Discloser will be able to unblind the state to a potential Disclosee.
In a blindable state TEL, the state disclosure is interactive. A Disclosee may only observe the state when unblinded via an interactive exchange with the Discloser. After disclosure, the Discloser may then request that the Issuer update the state with a new blinding factor (_the blind_). The Disclosee cannot then observe the current state of the TEL without yet another disclosure interaction with the Discloser.
The blind is derived from a secret salt shared between the Issuer and the designated Discloser. The current blind is derived from this salt, and the sequence number of the TEL event is so blinded. To elaborate, the derivation path for the blind is the sequence number of the TEL event, which in combination with the salt, produces a universally unique salty nonce for the blind. Only the Issuer and Discloser have a copy of the secret salt, so only they can derive the current blind. The Issuer provides a service endpoint to which the Discloser can make a signed request to update the blind. Each new event in the TEL MUST change the blinding factor but MAY or MAY NOT change the actual blinded state. Only the Issuer can change the actual blinded state. Because each updated event in the TEL has a new blinding factor regardless of an actual change of state or not, an observer can not correlate state changes to event updates as long as the Issuer regularly updates the blinding factor by issuing a new TEL event.
Blindable State TEL events use a unique event type, `upd`. The event state is hidden in the `a` field, whose value is the blinded SAID of a field map that holds the TEL state. The field map's SAID is its `d` field. The blinding factor is provided in the field map's `u` field. The SAID of the associated ACDC is in the field map's `i` field or else the aggregate value for bulk issued ACDCs. The actual state of the TEL for that ACDC is provided by other fields in the `a`, field map. A simple state could use the `s` field for state or status.
When the `u` field is missing or empty, then the event is not blindable. When the `u` field has sufficient entropy, then the SAID of the enclosing field map effectively blinds the state provided by that map. The discloser must disclose the field map to the Disclosee, who can verify that its SAID matches the SAID in the TEL. A subsequent update event entered into that TEL will then re-blind the state of the TEL so that any prior Disclosees may no longer verify the current state of the TEL.
| Label | Description | Notes |
| --- | --- | --- |
| v | version string | |
| d | event digest | SAID |
| s | sequence number of event | |
| t | message type of event | `upd` |
| dt | issuer system data/time in iso format | |
| p | prior event digest | SAID |
| ri | registry identifier from management TEL | |
| ra | registry anchor to management TEL | |
| a | state attributed digest | SAID |
| Label | Description | Notes |
| --- | --- | --- |
| d | attribute digest | SAID |
| u | salty nonce blinding factor | UUID |
| i | namespaced identifier of VC or aggregate when bulk issued | SAID or Aggregate |
| s | state value | `issued` or `revoked` |
Recall that the purpose of using the aggregate _B_ for a bulk-issued set from which the TEL identifier is derived is to enable a set of bulk-issued ACDCs to share a single public TEL and/or a single anchoring seal in the Issuer's KEL without enabling un-permissioned correlation to any other members of the bulk set by virtue of the shared aggregate _B_ used for either the TEL or anchoring seal in the KEL. When using a TEL this enables the issuance/revocation/transfer state of all copies of a set of bulk-issued ACDCs to be provided by a single TEL which minimizes the storage and compute requirements on the TEL registry while providing selective disclosure to prevent un-permissioned correlation via the public TEL. When using an anchoring seal, this enables one signature to provide proof of inclusion in the bulk-issued aggregate _B_.
However, in some applications where chain-link confidentiality does not sufficiently deter malicious provable correlation by Disclosees (Second-Party verifiers), an Issuee may benefit from using ACDC with independent TELs or independent aggregates _B_ but that are still bulk-issued.
In this case, the bulk issuance process must be augmented so that each uniquely identified copy of the ACDC gets its own TEL entry (or equivalently its own aggregate _B_) in the registry. Each Disclosee (verifier) of a full presentation/disclosure of a given copy of the ACDC only receives proof of one uniquely identified TEL and can NOT provably correlate the TEL state of one presentation to any other presentation because the ACDC SAID, the TEL identifier, and the signature of the issuer on each aggregate _B_ will be different for each copy. There is, therefore no point of provable correlation, permissioned or otherwise. One could for example, modulate this apprach by having a set of smaller bulk issued sets that are more contextualized than one large bulk issued set.
The obvious drawbacks of this approach (independent unique TELs for each private ACDC) are that the size of the registry database increases as a multiple of the number of copies of each bulk-issued ACDC and every time an Issuer must change the TEL state of a given set of copies it must change the state of multiple TELs in the registry. This imposes both a storage and computation burden on the registry. The primary advantage of this approach, however, is that each copy of a private ACDC has a uniquely identified TEL. This minimizes un-permissioned Third-Party exploitation via provable correlation of TEL identifiers even with colluding Second-Party verifiers. They are limited to statistical correlation techniques.
In this case, the set of private ACDCs may or may not share the same Issuee AID because for all intents and purposes each copy appears to be a different ACDC even when issued to the same Issuee. Nonetheless, using unique Issuee AIDs may further reduce correlation by malicious Disclosees (Second-Party verifiers) beyond using independent TELs.
To summarize the main benefit of this approach, in spite of its storage and compute burden, is that in some applications chain-link confidentiality does not sufficiently deter un-permissioned malicious collusion. Therefore completely independent bulk-issued ACDCs may be used.
ToDo
Append-only verifiable data structures have strong security properties that simplify end-verifiability & foster decentralization.
Append-only provides permission-less extensibility by downstream issuers, presenters, and/or verifiers
Each ACDC has a universally-unique content-based identifier with a universally-unique content-based schema identifier.
Fully decentralized name-spacing.
Custom fields are appended via chaining via one or more custom ACDCs defined by custom schema (type-is-schema).
No need for centralized permissioned name-space registries to resolve name-space collisions.
The purposes of a registry now become merely schema discovery or schema blessing for a given context or ecosystem.
The reach of the registry is tuned to the reach of desired interoperability by the ecosystem participants.
Human meaningful labels on SAIDs are local context only.
Versioning is simplified because edges still verify if new schema are backwards compatible. (persistent data structure model).
The compact disclosure and distribute property graph fragment mechanisms in ACDC can be leveraged to enable high performance at scale. Simply using SAIDs and signed SAIDs of ACDCs in whole or in part enables compact but securely attributed and verifiable references to ACDCs to be employed anywhere performance is an issue. Only the SAID and its signature need be transmitted to verify secure attribution of the data represented by the SAID. Later receipt of the data may be verified against the SAID. The signature does not need to be re-verified because a signature on a SAID is making a unique (to within the cryptographic strength of the SAID) commitment to the data represented by the SAID. The actual detailed ACDC in whole or in part may then be cached or provided on-demand or just-in-time.
Hierarchical decomposition of data into a distributed verifiable property graph, where each ACDC is a distributed graph fragment, enables performant reuse of data or more compactly performant reuse of SAIDs and their signatures. The metadata and attribute sections of each ACDC provide a node in the graph and the edge section of each ACDC provides the edges to that node. Higher-up nodes in the graph with many lower-level nodes need only be transmitted, verified, and cached once per every node or leaf in the branch not redundantly re-transmitted and re-verified for each node or leaf as is the case for document-based verifiable credentials where the whole equivalent of the branched (graph) structure must be contained in one document. This truly enables the bow-tie model popularized by Ricardian contracts, not merely for contracts, but for all data authenticated, authorized, referenced, or conveyed by ACDCs.
For crypto-systems with _perfect-security_, the critical design parameter is the number of bits of entropy needed to resist any practical brute force attack. In other words, when a large random or pseudo-random number from a cryptographic strength pseudo-random number generator (CSPRNG) {{CSPRNG}} expressed as a string of characters is used as a seed or private key to a cryptosystem with _perfect-security_, the critical design parameter is determined by the amount of random entropy in that string needed to withstand a brute force attack. Any subsequent cryptographic operations must preserve that minimum level of cryptographic strength. In information theory {{IThry}}{{ITPS}} the entropy of a message or string of characters is measured in bits. Another way of saying this is that the degree of randomness of a string of characters can be measured by the number of bits of entropy in that string. Assuming conventional non-quantum computers, the convention wisdom is that, for systems with information-theoretic or perfect security, the seed/key needs to have on the order of 128 bits (16 bytes, 32 hex characters) of entropy to practically withstand any brute force attack. A cryptographic quality random or pseudo-random number expressed as a string of characters will have essentially as many bits of entropy as the number of bits in the number. For other crypto-systems such as digital signatures that do not have perfect security, the size of the seed/key may need to be much larger than 128 bits in order to maintain 128 bits of cryptographic strength.
An N-bit long base-2 random number has 2N different possible values. Given that no other information is available to an attacker with perfect security, the attacker may need to try every possible value before finding the correct one. Thus the number of attempts that the attacker would have to try maybe as much as 2N-1. Given available computing power, one can easily show that 128 is a large enough N to make brute force attack computationally infeasible.
Let's suppose that the adversary has access to supercomputers. Current supercomputers can perform on the order of one quadrillion operations per second. Individual CPU cores can only perform about 4 billion operations per second, but a supercomputer will parallelly employ many cores. A quadrillion is approximately 250 = 1,125,899,906,842,624. Suppose somehow an adversary had control over one million (220 = 1,048,576) supercomputers which could be employed in parallel when mounting a brute force attack. The adversary could then try 250 _220 = 270 values per second (assuming very conservatively that each try only took one operation). There are about 3600_ 24 \* 365 = 313,536,000 = 2log2313536000\=224.91 ~= 225 seconds in a year. Thus this set of a million super computers could try 250+20+25 = 295 values per year. For a 128-bit random number this means that the adversary would need on the order of 2128-95 = 233 = 8,589,934,592 years to find the right value. This assumes that the value of breaking the cryptosystem is worth the expense of that much computing power. Consequently, a cryptosystem with perfect security and 128 bits of cryptographic strength is computationally infeasible to break via brute force attack.
The highest level of cryptographic security with respect to a cryptographic secret (seed, salt, or private key) is called _information-theoretic security_ {{ITPS}}. A cryptosystem that has this level of security cannot be broken algorithmically even if the adversary has nearly unlimited computing power including quantum computing. It must be broken by brute force if at all. Brute force means that in order to guarantee success the adversary must search for every combination of key or seed. A special case of _information-theoretic security_ is called _perfect-security_ {{ITPS}}. _Perfect-security_ means that the ciphertext provides no information about the key. There are two well-known cryptosystems that exhibit _perfect security_. The first is a _one-time-pad_ (OTP) or Vernum Cipher {{OTP}}{{VCphr}}, the other is _secret splitting_ {{SSplt}}, a type of secret sharing {{SShr}} that uses the same technique as a _one-time-pad_.
{::boilerplate bcp14-tagged}
- `SAID` - Self-Addressing Identifier - any identifier which is deterministically generated out of the content, digest of the content
Refer to the body of the specification. Security considerations are included in the context of each section. The ACDC specification is security driven so the specification itself is riddled with discussions of the security considerations in the context in which those discussions are most understandable and relevant.
This document has no IANA actions.
\--- back
{:numbered="false"}
ACDC community.
---
title: Draft Ssmith Cesr
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-cesr
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-cesr.md
---
---
title: WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
description: 8203357166114, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-ipex
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-ipex.md
---
# WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
title: "Issuance and Presentation Exchange Protocol" abbrev: "IPEX" category: info
docname: draft-ssmith-ipex-latest v: 3 area: AREA workgroup: WG Working Group keyword: Internet-Draft venue: group: WG type: Working Group mail: [WG@example.com](mailto:WG@example.com) arch: [https://example.com/WG](https://example.com/WG) github: USER/REPO latest: [https://example.com/LATEST](https://example.com/LATEST)
author:
- fullname: Samuel M. Smith organization: ProSapien LLC email: "[sam@prosapien.com](mailto:sam@prosapien.com)"
- name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](mailto:Philip.Feairheller@gleif.org)
normative:
IPEX-ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF IPEX (Issuance and Presentation EXchange) Prototocol Internet Draft author:
```
-
ins: S. Smith
name: Samuel M. Smith
org: ProSapien LLC
-
name: Phil Feairheller
organization: GLEIF
email: Philip.Feairheller@gleif.org
date: 2022
```
ACDC-ID: target: [https://github.com/trustoverip/tswg-acdc-specification](https://github.com/trustoverip/tswg-acdc-specification) title: IETF ACDC (Authentic Chained Data Containers) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
OOBI-ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF OOBI (Out-Of-Band-Introduction) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
KERI-ID: target: [https://github.com/WebOfTrust/ietf-keri](https://github.com/WebOfTrust/ietf-keri) title: IETF KERI (Key Event Receipt Infrastructure) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
SAID-ID: target: [https://github.com/WebOfTrust/ietf-said](https://github.com/WebOfTrust/ietf-said) title: IETF SAID (Self-Addressing IDentifier) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
CESR-ID: target: [https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr) title: IETF CESR (Composable Event Streaming Representation) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
PTEL-ID: target: [https://github.com/WebOfTrust/ietf-ptel](https://github.com/WebOfTrust/ietf-ptel) title: IETF PTEL (Public Transaction Event Log) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
Proof-ID: target: [https://github.com/WebOfTrust/ietf-cesr-proof](https://github.com/WebOfTrust/ietf-cesr-proof) title: IETF CESR-Proof Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
DIDK-ID: target: [https://github.com/WebOfTrust/ietf-did-keri](https://github.com/WebOfTrust/ietf-did-keri) title: IETF DID-KERI Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
RFC8259: target: [https://datatracker.ietf.org/doc/html/rfc8259](https://datatracker.ietf.org/doc/html/rfc8259) title: JSON (JavaScript Object Notation)
RFC4627: target: [https://datatracker.ietf.org/doc/rfc4627/](https://datatracker.ietf.org/doc/rfc4627/) title: The application/json Media Type for JavaScript Object Notation (JSON)
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
JSch: target: [https://json-schema.org](https://json-schema.org) title: JSON Schema
JSch\_202012: target: [https://json-schema.org/draft/2020-12/release-notes.html](https://json-schema.org/draft/2020-12/release-notes.html) title: "JSON Schema 2020-12"
informative:
KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
IDSys: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf) title: Identity System Essentials
RC: target: [https://en.wikipedia.org/wiki/Ricardian\_contract](https://en.wikipedia.org/wiki/Ricardian_contract) title: Ricardian Contract
CLC: target: [https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=2045818](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818) title: "Chain-Link Confidentiality"
\--- abstract
The Issuance and Presentation Exchange (IPEX) Protocol provides a uniform mechanism for the issuance and presentation of ACDCs {{ACDC-ID}} in a securely attributable manner. A single protocol is able to work for both types of exchanges by recognizing that all exchanges (both issuance and presentation) may be modeled as the disclosure of information by a Discloser to a Disclosee. The difference between exchange types is the information disclosed not the mechanism for disclosure. Furthermore, the chaining mechanism of ACDCs and support for both targeted and untargeted ACDCs provide sufficient variability to accommodate the differences in applications or use cases without requiring a difference in the exchange protocol itself. This greatly simplifies the exchange protocol. This simplification has two primary advantages. The first is enhanced security. A well-delimited protocol can be designed and analyzed to minimize and mitigate attack mechanisms. The second is convenience. A standard simple protocol is easier to implement, support, update, understand, and adopt. The tooling is more consistent.
This IPEX {{IPEX-ID}} protocol leverages important features of ACDCs and ancillary protocols such as CESR {{CESR-ID}}, SAIDs {{SAID-ID}}, and CESR-Proofs {{Proof-ID}} as well as Ricardian contracts {{RC}} and graduated disclosure (partial, selective, full) to enable contractually protected disclosure. Contractually protected disclosure includes both chain-link confidential {{CLC}} and contingent disclosure {{ACDC-ID}}.
\--- middle
TODO Introduction
Presentation Exchange : An exchange that provides disclosure of one or more ACDCs between a _Discloser_ and a _Disclosee_.
A presentation exchange is the process by which authenticatable information may be exchanged between two parties, namely, the _Discloser_ and _Disclosee_.
ACDC : Type of data as issuance concretely defined by the ACDC specification {{ACDC-ID}}.
Discloser : An ACDC in a disclosure is _disclosed by_ the _Discloser_.
Disclosee : An ACDC in a disclosure is _disclosed to_ the _Disclosee_.
Issuer : An _ACDC_ is _issued by_ the _Issuer_. The _Issuer_ identifier (AID) appears in the top level of the ACDC.
Issuee : An _ACDC_ is optionally _issued to_ the _Issuee_. When present, the _Issuee_ identifier (AID) appears at the top level of the attribute section or in the attribute list at the top level of the attribute aggregate section of the ACDC.
Each _ACDC_ MUST have an _Issuer_ and MAY have an _Issuee_.
The set of _ACDCs_ so disclosed in a _presentation exchange_ MUST be chained. This set of chained _ACDCs_ define a directed acyclic graph (DAG) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
Each _ACDC_ itself defines a graph fragment consisting of one vertex and zero or more directed edges. Each directed edge contained in an _ACDC_ points to a vertex contained in another _ACDC_. The ACDC that contains the origin vertex of the DAG is called the _origin_ or _primary_ ACDC of the _presentation exchange_.
The disclosure performed by a presentation exchange MAY be _graduated_ and MAY be _contractually protected_.
Issuance Exchange : A special case of a _presentation exchange_ where the _Discloser_ is the _Issuer_ of the _origin_ (Primary) _ACDC_ of the DAG formed by the set of chained ACDCs so disclosed.
In an _issuance exchange_, when the _origin_ ACDC has an _Issuee_, the _Disclosee_ MAY also be the _origin_ ACDC's _Issuee_.
Disclosures via Presentations Exchanges may be contractually protected by Chain-Link Confidentiality (i.e a Chain-Link Confidential disclosure). The chaining in this case is different from the chaining described above between Issuances in a DAG of chained Issuances. Chain-link confidentiality, in contrast, chains together a sequence of Disclosees. Each Disclosee in the sequence in turn is the Discloser to the next Disclosee. The terms-of-use of the original disclosure as applied to the original Disclosee MUST be applied by each subsequent Discloser to each subsequent Disclosee via each of the subsequent disclosures (presentation exchanges). These terms-of-use typically constrain disclosure to only approved parties, i.e. imbue the chain of disclosures with some degree of confidentiality. These terms-of-use are meant to contractually protect the data rights of the original Issuer or Issuee of the data being disclosed.
| Discloser | Disclosee | Initiate | Contents | Description |
| --- | --- | --- | --- | --- |
| | `apply` | Y | schema or its SAID, attribute field label list, signature on `apply` or its SAID | schema SAID is type of ACDC, optional label list for selective disclosure, CESR-Proof signature |
| `spurn` | | N | | rejects `apply` |
| `offer` | | Y | metadata ACDC or its SAID, signature on `offer` or its SAID | includes schema or its SAID, other partial disclosures, selective disclosure label list, CESR-Proof signature |
| | `spurn` | N | | rejects `offer` |
| | `agree` | N | signature on `offer` or its SAID | CESR-Proof signature |
| `spurn` | | N | | rejects `agree` |
| `grant` | | Y | full or selective disclosure ACDC, signature on `grant` or its SAID | includes attribute values, CESR-Proof signature |
| | `admit` | N | signature on `grant` or its SAID | CESR-Proof signature |
All the variants of an ACDC are various degrees of expansion of the compact variant. Therefore, an Issuer commitment via a signature to any variant of ACDC (compact, full, etc) makes a cryptographic commitment to the top-level section fields shared by all variants of that ACDC because the value of a top level section field is either the SAD or the SAID of the SAD of the associated section. Both a SAD and its SAID, when signed, each provide a verifiable commitment to the SAD. In the former the signature verification is directly agains the SAD itself. In the latter, the SAID as digest must first be verified against its SAD and then the signature on the SAID may be verified. This indirect verifiablity assumes that the cryptographic strength of the SAID digest is equivalent to the cryptographic strength of the signature used to sign it. To clarify, because all variants share the same top level structure as the compact variant, then a signature on any variant may be used to verify the Issuer's committment to any other variant either directly or indirectly, in whole or in part on a top-level section by top-level section basis. This cross-variant Issuer commitment verifiability is an essential property that supports graduated disclosure by the Disclosee of any or all variants wether it be full, compact, metadata, partial, selective, bulk issued, or contractually protected.
To elaborate, the SAID of a given variant is useful even when it is not the SAID of the variant the Issuer signed because during graduated disclosure the Discloser MAY choose to sign that given variant to fullfill a given step in an IPEX graduated disclosure transaction. The Discloser thereby can make a verifiable disclosure in a given step of the SAD of a given variant that fulfills a commitment made in a prior step via its signature on merely the SAID of the SAD of the variant so disclosed.
For example, the Metadata variant of an ACDC will have a different SAID than the Compact variant because some of the top-level field values may be empty in the Metadata variant. One can think of the The metadata variant as a partial manifest that only includes those top level sections that the Discloser is committing to disclose in order to induce the Disclosee to agree to the contractual terms of use when disclosed. The IPEX transaction is between the Discloser and Disclosee, who both may make non-repudiable commitments via signing to each other. Typically this means that the Discloser will eventually need to fulfull its commitment with a proof of disclosure to the Disclosee. This proof may be satisfied with either directly against the Discloser's signature on the the actual disclosed SAD or indirectly agaisnt the Discloser's signature on the SAID of the actual disclosed SAD. In addition, the Disclosee will typically require a proof of issuance via a non-repudiable signature by the Issuer on a variant of the disclosed SAD that is verifiable (directly or indirectly) against the variant that is the disclosed SAD.
To summarize, when the Issuer commits to the composed schema of an ACDC it is committing to all the variants so composed. As described above, the top level field values in the compact variant enable verification against a disclosure of any of the other Issuer committed variants because they all share the same top level structure. This applies even to the metadata variant in spite of it only providing values for some top level sections and not others. The verifiablity of a top level section is separable.
Consequently, the IPEX protocol must specify how a validator does validation of any variant in a graduated disclosure. To restate there are two proofs that a Discloser must provide. The first is proof of issuance and the second is proof of disclosure. In the former, the Discloser provide the variant via its SAD that was actually signed (as SAD or SAID of SAD) by the Issuer in order for the Disclosee to verify authentic issuance via the signature on that variant. In the latter, the Discloser must disclose any other Issuer enabled (via schema composition) variants that the Discloser offered to disclose as part of the graduated disclosure process.
The goal is to define a validation process (set of rules) that works for all variants of an ACDC and for all types of graduated disclosure of that ACDC.
For example, in the bulk issuance of an ACDC, the Issuer only signs the blinded SAID of the SAD that is the Compact variant of the ACDC not the SAD itself. This enable a Discloser to make a proof of inclusion of the ACDC in a bulk issuance set by unblinding the signature on the blinded SAID without leaking correlation to anything but the blinded SAID itself. To clarify, the Disclosee can verify the signature on the SAID without to prove set inclusion with needing the disclosure of any other information about the ACDC. Issuer signing of the SAID not the SAD also has the side benefit of minimizing the computation of large numbers of bulk issued signatures.
The Issuer MUST provide a signature on the SAID of the most compact variant defined by the schema of the ACDC. When more than one variant is defined by the schema via the oneOf composition operator for any top-level field, the most compact variant MUST appear as the first entry in the oneOf list. When only one variant of each top-level field is defined by the schema, that variant is therefore by defintion the most compact variant.
The different variants of an ACDC form a hash tree (using SAIDs) that is analogous to a Merkle Tree. Signing the top-level SAID of the compact version of the ACDC is equivalent to signing the Merkle Root of a Merkle Tree. Different variants of an ACDC (SADs with SAIDs) correspond to different paths through a Merkle tree. The process of verifying that a SAD via its SAID of a section is included in a schema authorized variant down from the top-level SAID is equivalent to a Merkle Tree proof of inclusion along a path in the Merkel Tree down from its Root. This allows a single signature to provide proof of Issuance of the presentation of any schema authorized variants of the ACDC.
An Issuer MAY provide signatures of the SAIDS of other variants, as well as signatures of the SADs of other variants.
Proof of issuance is provided by disclosing the SAID of the most compact variant and the signature by the Issuer on that SAID.
Proof of disclosure is provided by disclosing the SAD of the most compact variant and then recursively disclosing the nested SADs of each of the top level sections of the most compact variant as needed for the promised disclosure.
Thus for any disclosed variant of an ACDC, the Disclosee need only verify only one proof of issuance as defined above and may need to verify a different proof of disclosure for each disclosed variant as defined above.
The following schema supports a compact variant
```
{
"$id": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Public ACDC",
"description": "Example JSON Schema Public ACDC.",
"credentialType": "PublicACDCExample",
"type": "object",
"required":
[
"v",
"d",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry AID",
"type": "string"
},
"s":
{
"description": "schema section",
"oneOf":
[
{
"description": "schema section SAID",
"type": "string"
},
{
"description": "schema detail",
"type": "object"
},
]
},
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute section SAID",
"type": "string"
},
{
"description": "attribute detail",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute section SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false,
}
]
},
"e":
{
"description": "edge section",
"oneOf":
[
{
"description": "edge section SAID",
"type": "string"
},
{
"description": "edge detail",
"type": "object",
"required":
[
"d",
"boss"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"boss":
{
"description": "boss edge",
"type": "object",
"required":
[
"d",
"n",
's',
"w"
],
"properties":
{
"d":
{
"description": "edge SAID",
"type": "string"
},
"n":
{
"description": "far node SAID",
"type": "string"
},
"s":
{
"description": "far node schema SAID",
"type": "string",
"const": ""EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71"
},
"w":
{
"description": "edge weight",
"type": "string"
},
"additionalProperties": false
},
},
"additionalProperties": false
}
]
},
"r":
{
"description": "rule section",
"oneOf":
[
{
"description": "rule section SAID",
"type": "string"
},
{
"description": "rule detail",
"type": "object",
"required":
[
"d",
"warrantyDisclaimer",
"liabilityDisclaimer"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"warrantyDisclaimer":
{
"description": "warranty disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
},
"liabilityDisclaimer":
{
"description": "liability disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
}
},
"additionalProperties": false
}
```
The following JSON field map serialization satisfies the rules for most compact variant of the schema above.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
The Issuer signs the SAID, `d` field value of the field map above.
{::boilerplate bcp14-tagged}
TODO Security
This document has no IANA actions.
\--- back
{:numbered="false"}
TODO acknowledge.
---
title: Draft Ssmith Keri
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-keri
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-keri.md
---
---
title: Draft Ssmith Oobi
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-oobi
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-oobi.md
---
---
title: Draft Ssmith Said
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-said
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/draft-ssmith-said.md
---
---
title: IdentifierTheory Ssmith Uidt
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/IdentifierTheory-ssmith-uidt
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/IdentifierTheory-ssmith-uidt.md
---
---
title: Kli Demo 2022
source_url:
html: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/kli-demo-2022
md: https://weboftrust.github.io/WOT-terms/_05_resources/mdfiles/kli-demo-2022.md
---
---
title: Concepts
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/concepts
md: https://weboftrust.github.io/WOT-terms/_06_concepts/concepts.md
---
---
title: KERI Suite Glossary
description: This is the KERI Suite Glossary.
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/intro
md: https://weboftrust.github.io/WOT-terms/_06_concepts/intro.md
---
# KERI Suite Glossary
This is the KERI Suite Glossary.
Also take a look at:
- [KERIDoc – Documentation](https://weboftrust.github.io/keridoc/)
- [KERISSE – Search engine](https://weboftrust.github.io/kerisse/)
---
title: Keri Dev Env
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/keri-dev-env
md: https://weboftrust.github.io/WOT-terms/_06_concepts/keri-dev-env.md
---
---
title: Mindmap
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/mindmap
md: https://weboftrust.github.io/WOT-terms/_06_concepts/mindmap.md
---
---
title: Roadmap
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/roadmap
md: https://weboftrust.github.io/WOT-terms/_06_concepts/roadmap.md
---
---
title: Contribute To Weboftrust Github
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/contribute-to-weboftrust-github
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/contribute-to-weboftrust-github.md
---
---
title: Create A Basic Acdc Graph
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/create-a-basic-acdc-graph
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/create-a-basic-acdc-graph.md
---
---
title: Current Open Issues
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/current-open-issues
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/current-open-issues.md
---
---
title: KERI Suite Glossary
description: This is the KERI Suite Glossary.
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/intro
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/intro.md
---
# KERI Suite Glossary
This is the KERI Suite Glossary.
Also take a look at:
- [KERIDoc – Documentation](https://weboftrust.github.io/keridoc/)
- [KERISSE – Search engine](https://weboftrust.github.io/kerisse/)
---
title: Issue A Credential
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/issue-a-credential
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/issue-a-credential.md
---
---
title: Make A Schema
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/make-a-schema
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/make-a-schema.md
---
---
title: Present A Credential
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/present-a-credential
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/present-a-credential.md
---
---
title: Set Up Basic Keri Network
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/set-up-basic-keri-network
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/set-up-basic-keri-network.md
---
---
title: Verify A Credential
source_url:
html: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/verify-a-credential
md: https://weboftrust.github.io/WOT-terms/_06_concepts/how-to/verify-a-credential.md
---
---
title: KERI Suite Glossary
description: This is the KERI Suite Glossary.
source_url:
html: https://weboftrust.github.io/WOT-terms/_07_education/intro
md: https://weboftrust.github.io/WOT-terms/_07_education/intro.md
---
# KERI Suite Glossary
This is the KERI Suite Glossary.
Also take a look at:
- [KERIDoc – Documentation](https://weboftrust.github.io/keridoc/)
- [KERISSE – Search engine](https://weboftrust.github.io/kerisse/)
---
title: Keri Mooc
source_url:
html: https://weboftrust.github.io/WOT-terms/_07_education/keri-mooc
md: https://weboftrust.github.io/WOT-terms/_07_education/keri-mooc.md
---
---
title: Q And A Security
source_url:
html: https://weboftrust.github.io/WOT-terms/_07_education/q-and-a-security
md: https://weboftrust.github.io/WOT-terms/_07_education/q-and-a-security.md
---
---
title: Q And A
source_url:
html: https://weboftrust.github.io/WOT-terms/_07_education/q-and-a
md: https://weboftrust.github.io/WOT-terms/_07_education/q-and-a.md
---
---
title: Tutorials
source_url:
html: https://weboftrust.github.io/WOT-terms/_07_education/tutorials
md: https://weboftrust.github.io/WOT-terms/_07_education/tutorials.md
---
---
title: WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
description: 4171595971390, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/_08_annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
md: https://weboftrust.github.io/WOT-terms/_08_annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc.md
---
# WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
title: "Authentic Chained Data Containers (ACDC)" abbrev: "ACDC" category: info
docname: draft-ssmith-acdc-latest
ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
author:
- name: S. Smith organization: ProSapien LLC email: [sam@prosapien.com](mailto:sam@prosapien.com)
normative:
ACDC\_ID: target: [https://github.com/trustoverip/tswg-acdc-specification](https://github.com/trustoverip/tswg-acdc-specification) title: IETF ACDC (Authentic Chained Data Containers) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
KERI\_ID: target: [https://github.com/WebOfTrust/ietf-keri](https://github.com/WebOfTrust/ietf-keri) title: IETF KERI (Key Event Receipt Infrastructure) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
CESR\_ID: target: [https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr) title: IETF CESR (Composable Event Streaming Representation) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
SAID\_ID: target: [https://github.com/WebOfTrust/ietf-said](https://github.com/WebOfTrust/ietf-said) title: IETF SAID (Self-Addressing IDentifier) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
OOBI\_ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF OOBI (Out-Of-Band-Introduction) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
PTEL\_ID: target: [https://github.com/WebOfTrust/ietf-ptel](https://github.com/WebOfTrust/ietf-ptel) title: IETF PTEL (Public Transaction Event Log) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
Proof\_ID: target: [https://github.com/WebOfTrust/ietf-cesr-proof](https://github.com/WebOfTrust/ietf-cesr-proof) title: IETF CESR-Proof Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
IPEX\_ID: target: [https://github.com/WebOfTrust/ietf-ipex](https://github.com/WebOfTrust/ietf-ipex) title: IPEX (Issuance and Presentation EXchange) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
DIDK\_ID: target: [https://github.com/WebOfTrust/ietf-did-keri](https://github.com/WebOfTrust/ietf-did-keri) title: IETF DID-KERI Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
RFC6901: target: [https://datatracker.ietf.org/doc/html/rfc6901](https://datatracker.ietf.org/doc/html/rfc6901) title: JavaScript Object Notation (JSON) Pointer author:
```
-
name: Paul C. Bryan
-
name: Kris Zyp
-
name: Mark Nottingham
date: 2003
```
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
RFC8259: target: [https://datatracker.ietf.org/doc/html/rfc8259](https://datatracker.ietf.org/doc/html/rfc8259) title: JSON (JavaScript Object Notation)
RFC4627: target: [https://datatracker.ietf.org/doc/rfc4627/](https://datatracker.ietf.org/doc/rfc4627/) title: The application/json Media Type for JavaScript Object Notation (JSON)
JSch: target: [https://json-schema.org](https://json-schema.org) title: JSON Schema
JSch\_202012: target: [https://json-schema.org/draft/2020-12/release-notes.html](https://json-schema.org/draft/2020-12/release-notes.html) title: "JSON Schema 2020-12"
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
RFC3986: target: [https://datatracker.ietf.org/doc/html/rfc3986](https://datatracker.ietf.org/doc/html/rfc3986) title: "Uniform Resource Identifier (URI): Generic Syntax"
RFC8820: target: [https://datatracker.ietf.org/doc/html/rfc8820](https://datatracker.ietf.org/doc/html/rfc8820) title: URI Design and Ownership
informative:
ACDC\_WP: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf) title: Authentic Chained Data Containers (ACDC) White Paper
VCEnh: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC\_Enhancement\_Strategy.md](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC_Enhancement_Strategy.md) title: VC Spec Enhancement Strategy Proposal
ACDC\_TF: target: [https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force](https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force) title: ACDC (Authentic Chained Data Container) Task Force
TOIP: target: [https://trustoverip.org](https://trustoverip.org) title: Trust Over IP (ToIP) Foundation
IETF: target: [https://www.ietf.org](https://www.ietf.org) title: IETF (Internet Engineering Task Force
KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
ITPS: target: [https://en.wikipedia.org/wiki/Information-theoretic\_security](https://en.wikipedia.org/wiki/Information-theoretic_security) title: Information-Theoretic and Perfect Security
OTP: target: [https://en.wikipedia.org/wiki/One-time\_pad](https://en.wikipedia.org/wiki/One-time_pad) title: One-Time-Pad
VCphr: target: [https://www.ciphermachinesandcryptology.com/en/onetimepad.htm](https://www.ciphermachinesandcryptology.com/en/onetimepad.htm) title: Vernom Cipher (OTP)
SSplt: target: [https://www.ciphermachinesandcryptology.com/en/secretsplitting.htm](https://www.ciphermachinesandcryptology.com/en/secretsplitting.htm) title: Secret Splitting
SShr: target: [https://en.wikipedia.org/wiki/Secret\_sharing](https://en.wikipedia.org/wiki/Secret_sharing) title: Secret Sharing
CSPRNG: target: [https://en.wikipedia.org/wiki/Cryptographically-secure\_pseudorandom\_number\_generator](https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator) title: Cryptographically-secure pseudorandom number generator (CSPRNG)
IThry: target: [https://en.wikipedia.org/wiki/Information\_theory](https://en.wikipedia.org/wiki/Information_theory) title: Information Theory
CAcc: target: [https://en.wikipedia.org/wiki/Accumulator\_(cryptography)](https://en.wikipedia.org/wiki/Accumulator_\(cryptography\)) title: Cryptographic Accumulator
XORA: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/XORA.md](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/XORA.md) title: XORA (XORed Accumulator)
GLEIF: target: [https://www.gleif.org/en/](https://www.gleif.org/en/) title: GLEIF (Global Legal Entity Identifier Foundation)
vLEI: target: [https://github.com/WebOfTrust/vLEI](https://github.com/WebOfTrust/vLEI) title: vLEI (verifiable Legal Entity Identifier) Definition
GLEIF\_vLEI: target: [https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei](https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei) title: GLEIF vLEI (verifiable Legal Entity Identifier)
GLEIF\_KERI: target: [https://github.com/WebOfTrust/vLEI](https://github.com/WebOfTrust/vLEI) title: GLEIF with KERI Architecture
W3C\_VC: target: [https://www.w3.org/TR/vc-data-model/](https://www.w3.org/TR/vc-data-model/) title: W3C Verifiable Credentials Data Model v1.1
W3C\_DID: target: [https://w3c-ccg.github.io/did-spec/](https://w3c-ccg.github.io/did-spec/) title: W3C Decentralized Identifiers (DIDs) v1.0
Salt: target: [https://medium.com/@fridakahsas/salt-nonces-and-ivs-whats-the-difference-d7a44724a447](https://medium.com/@fridakahsas/salt-nonces-and-ivs-whats-the-difference-d7a44724a447) title: Salts, Nonces, and Initial Values
RB: target: [https://en.wikipedia.org/wiki/Rainbow\_table](https://en.wikipedia.org/wiki/Rainbow_table) title: Rainbow Table
DRB: target: [https://www.commonlounge.com/discussion/2ee3f431a19e4deabe4aa30b43710aa7](https://www.commonlounge.com/discussion/2ee3f431a19e4deabe4aa30b43710aa7) title: Dictionary Attacks, Rainbow Table Attacks and how Password Salting defends against them
BDay: target: [https://en.wikipedia.org/wiki/Birthday\_attack](https://en.wikipedia.org/wiki/Birthday_attack) title: Birthday Attack
BDC: target: [https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/](https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/) title: Birthday Attacks, Collisions, And Password Strength
HCR: target: [https://en.wikipedia.org/wiki/Collision\_resistance](https://en.wikipedia.org/wiki/Collision_resistance) title: Hash Collision Resistance
QCHC: target: [https://cr.yp.to/hash/collisioncost-20090823.pdf](https://cr.yp.to/hash/collisioncost-20090823.pdf) title: "Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete?"
EdSC: target: [https://eprint.iacr.org/2020/823](https://eprint.iacr.org/2020/823) title: "The Provable Security of Ed25519: Theory and Practice Report"
PSEd: target: [https://ieeexplore.ieee.org/document/9519456?denied=](https://ieeexplore.ieee.org/document/9519456?denied=) title: "The Provable Security of Ed25519: Theory and Practice" seriesinfo: 2021 IEEE Symposium on Security and Privacy (SP) author:
```
-
ins: J. Brendel
name: Jacqueline Brendel
-
ins: C. Cremers
name: Cas Cremers
-
ins: D. Jackson
name: Dennis Jackson
-
ins: M. Zhao
name: Mang Zhao
date: 2021-05-24
```
TMEd: target: [https://eprint.iacr.org/2020/1244.pdf](https://eprint.iacr.org/2020/1244.pdf) title: Taming the many EdDSAs
JSchCp: target: "[https://json-schema.org/understanding-json-schema/reference/combining.html"](https://json-schema.org/understanding-json-schema/reference/combining.html%22) title: "Schema Composition in JSON Schema"
JSchRE: target: "[https://json-schema.org/understanding-json-schema/reference/regular\_expressions.html"](https://json-schema.org/understanding-json-schema/reference/regular_expressions.html%22) title: "Regular Expressions in JSON Schema"
JSchId: target: "[https://json-schema.org/understanding-json-schema/structuring.html#schema-identification"](https://json-schema.org/understanding-json-schema/structuring.html#schema-identification%22) title: "JSON Schema Identification"
JSchCx: target: "[https://json-schema.org/understanding-json-schema/structuring.html#base-uri"](https://json-schema.org/understanding-json-schema/structuring.html#base-uri%22) title: "Complex JSON Schema Structuring"
RC: target: [https://en.wikipedia.org/wiki/Ricardian\_contract](https://en.wikipedia.org/wiki/Ricardian_contract) title: Ricardian Contract
CLC: target: [https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=2045818](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818) title: "Chain-Link Confidentiality"
DHKE: target: [https://www.infoworld.com/article/3647751/understand-diffie-hellman-key-exchange.html](https://www.infoworld.com/article/3647751/understand-diffie-hellman-key-exchange.html) title: "Diffie-Hellman Key Exchange"
KeyEx: target: [https://libsodium.gitbook.io/doc/key\_exchange](https://libsodium.gitbook.io/doc/key_exchange) title: Key Exchange
IDSys: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf) title: Identity System Essentials
Hash: target: [https://en.wikipedia.org/wiki/Cryptographic\_hash\_function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) title: Cryptographic Hash Function
Mrkl: target: [https://en.wikipedia.org/wiki/Merkle\_tree](https://en.wikipedia.org/wiki/Merkle_tree) title: Merkle Tree
TwoPI: target: [https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/](https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/) title: Second Pre-image Attack on Merkle Trees
MTSec: target: [https://blog.enuma.io/update/2019/06/10/merkle-trees-not-that-simple.html](https://blog.enuma.io/update/2019/06/10/merkle-trees-not-that-simple.html) title: Merkle Tree Security
DSig: target: [https://en.wikipedia.org/wiki/Digital\_signature](https://en.wikipedia.org/wiki/Digital_signature) title: Digital Signature
Level: target: [https://en.wikipedia.org/wiki/Security\_level](https://en.wikipedia.org/wiki/Security_level) title: Security Level
Twin: target: [https://en.wikipedia.org/wiki/Digital\_twin](https://en.wikipedia.org/wiki/Digital_twin) title: Digital Twin
TMal: target: [https://en.wikipedia.org/wiki/Transaction\_malleability\_problem](https://en.wikipedia.org/wiki/Transaction_malleability_problem) title: Transaction Malleability
PGM: target: [http://ceur-ws.org/Vol-2100/paper26.pdf](http://ceur-ws.org/Vol-2100/paper26.pdf) title: The Property Graph Database Model author: ins: R. Angles name: Renzo Angles date: 2018
Dots: target: [https://arxiv.org/pdf/1006.2361.pdf](https://arxiv.org/pdf/1006.2361.pdf) title: Constructions from Dots and Lines author:
```
-
ins: M. Rodriguez
name: Marko A. Rodriguez
-
ins: P. Neubauer
name: Peter Neubauer
date: 2010
```
KG: target: [https://arxiv.org/pdf/2003.02320.pdf](https://arxiv.org/pdf/2003.02320.pdf) title: Knowledge Graphs
Abuse: target: [https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md](https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md) title: Alice Attempts to Abuse a Verifiable Credential
SKEM: target: [https://eprint.iacr.org/2021/509](https://eprint.iacr.org/2021/509) title: On using the same key pair for Ed25519 and an X25519 based KEM
tags: "IETF, ACDC, CESR, SAID, KERI"
\--- abstract
An authentic chained data container (ACDC) {{ACDC\_ID}}{{ACDC\_WP}}{{VCEnh}} is an IETF {{IETF}} internet draft focused specification being incubated at the ToIP (Trust over IP) foundation {{TOIP}}{{ACDC\_TF}}. An ACDC is a variant of the W3C Verifiable Credential (VC) specification {{W3C\_VC}}. The W3C VC specification depends on the W3C DID (Decentralized IDentifier) specification {{W3C\_DID}}. A major use case for the ACDC specification is to provide GLEIF vLEIs (verifiable Legal Entity Identifiers) {{vLEI}}{{GLEIF\_vLEI}}{{GLEIF\_KERI}}. GLEIF is the Global Legal Entity Identifier Foundation {{GLEIF}}. ACDCs are dependent on a suite of related IETF focused standards associated with the KERI (Key Event Receipt Infrastructure) {{KERI\_ID}}{{KERI}} specification. These include CESR {{CESR\_ID}}, SAID {{SAID\_ID}}, PTEL {{PTEL\_ID}}, CESR-Proof {{Proof\_ID}}, IPEX {{IPEX\_ID}}, did:keri {{DIDK\_ID}}, and OOBI {{OOBI\_ID}}. Some of the major distinguishing features of ACDCs include normative support for chaining, use of composable JSON Schema {{JSch}}{{JSchCp}}, multiple serialization formats, namely, JSON {{JSON}}{{RFC4627}}, CBOR {{CBOR}}{{RFC8949}}, MGPK {{MGPK}}, and CESR {{CESR\_ID}}, support for Ricardian contracts {{RC}}, support for chain-link confidentiality {{CLC}}, a well defined security model derived from KERI {{KERI}}{{KERI\_ID}}, _compact_ formats for resource constrained applications, simple _partial disclosure_ mechanisms and simple _selective disclosure_ mechanisms. ACDCs provision data using a synergy of provenance, protection, and performance.
\--- middle
One primary purpose of the ACDC protocol is to provide granular provenanced proof-of-authorship (authenticity) of their contained data via a tree or chain of linked ACDCs (technically a directed acyclic graph or DAG). Similar to the concept of a chain-of-custody, ACDCs provide a verifiable chain of proof-of-authorship of the contained data. With a little additional syntactic sugar, this primary facility of chained (treed) proof-of-authorship (authenticity) is extensible to a chained (treed) verifiable authentic proof-of-authority (proof-of-authorship-of-authority). A proof-of-authority may be used to provide verifiable authorizations or permissions or rights or credentials. A chained (treed) proof-of-authority enables delegation of authority and delegated authorizations. These proofs of authorship and/or authority provide provenance of an ACDC itself and by association any data that is so conveyed.
The dictionary definition of **_credential_** is _evidence of authority, status, rights, entitlement to privileges, or the like_. Appropriately structured ACDCs may be used as credentials when their semantics provide verifiable evidence of authority. Chained ACDCs may provide delegated credentials.
Chains of ACDCs that merely provide proof-of-authorship (authenticity) of data may be appended to chains of ACDCs that provide proof-of-authority (delegation) to enable verifiable delegated authorized authorship of data. This is a vital facility for authentic data supply chains. Furthermore, any physical supply chain may be measured, monitored, regulated, audited, and/or archived by a data supply chain acting as a digital twin {{Twin}}. Therefore ACDCs provide the critical enabling facility for an authentic data economy and by association an authentic real (twinned) economy.
ACDCs act as securely attributed (authentic) fragments of a distributed _property graph_ (PG) {{PGM}}{{Dots}}. Thus they may be used to construct knowledge graphs expressed as property graphs {{KG}}. ACDCs enable securely-attributed and privacy-protecting knowledge graphs.
The ACDC specification (including its partial and selective disclosure mechanisms) leverages two primary cryptographic operations namely digests and digital signatures {{Hash}}{{DSig}}. These operations when used in an ACDC MUST have a security level, cryptographic strength, or entropy of approximately 128 bits {{Level}}. (See the appendix for a discussion of cryptographic strength and security)
An important property of high-strength cryptographic digests is that a verifiable cryptographic commitment (such as a digital signature) to the digest of some data is equivalent to a commitment to the data itself. ACDCs leverage this property to enable compact chains of ACDCs that anchor data via digests. The data _contained_ in an ACDC may therefore be merely its equivalent anchoring digest. The anchored data is thereby equivalently authenticated or authorized by the chain of ACDCs.
An ACDC may be abstractly modeled as a nested `key: value` mapping. To avoid confusion with the cryptographic use of the term _key_ we instead use the term _field_ to refer to a mapping pair and the terms _field label_ and _field value_ for each member of a pair. These pairs can be represented by two tuples e.g `(label, value)`. We qualify this terminology when necessary by using the term _field map_ to reference such a mapping. _Field maps_ may be nested where a given _field value_ is itself a reference to another _field map_. We call this nested set of fields a _nested field map_ or simply a _nested map_ for short. A _field_ may be represented by a framing code or block delimited serialization. In a block delimited serialization, such as JSON, each _field map_ is represented by an object block with block delimiters such as `{}` {{RFC8259}}{{JSON}}{{RFC4627}}. Given this equivalence, we may also use the term _block_ or _nested block_ as synonymous with _field map_ or _nested field map_. In many programming languages, a field map is implemented as a dictionary or hash table in order to enable performant asynchronous lookup of a _field value_ from its _field label_. Reproducible serialization of _field maps_ requires a canonical ordering of those fields. One such canonical ordering is called insertion or field creation order. A list of `(field, value)` pairs provides an ordered representation of any field map. Most programming languages now support ordered dictionaries or hash tables that provide reproducible iteration over a list of ordered field `(label, value)` pairs where the ordering is the insertion or field creation order. This enables reproducible round trip serialization/deserialization of _field maps_. ACDCs depend on insertion ordered field maps for canonical serialization/deserialization. ACDCs support multiple serialization types, namely JSON, CBOR, MGPK, and CESR but for the sake of simplicity, we will only use JSON herein for examples {{RFC8259}}{{JSON}}. The basic set of normative field labels in ACDC field maps is defined in the following table.
These are reserved field labels at the top level of an ACDC.
| Label | Title | Description |
| --- | --- | --- |
| `v` | Version String | Regexable format: ACDCvvSSSShhhhhh\_ that provides protocol type, version, serialization type, size, and terminator. |
| `d` | Digest (SAID) | Self-referential fully qualified cryptographic digest of enclosing map. |
| `u` | UUID | Random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `i` | Issuer Identifier (AID) | Autonomic IDentifier whose Control authority is established via KERI verifiable key state. |
| `ri` | Registry Identifier | Issuance and/or revocation, transfer, or retraction registry for ACDC derived from Issuer Identifier. |
| `s` | Schema | Either the SAID of a JSON Schema block or the block itself. |
| `a` | Attribute | Either the SAID of a block of attributes or the block itself. |
| `A` | Attribute Aggregate | Either the Aggregate of a selectively disclosable block of attributes or the block itself. |
| `e` | Edge | Either the SAID of a block of edges or the block itself. |
| `r` | Rule | Either the SAID a block of rules or the block itself. |
| `n` | Node | SAID of another ACDC as the terminating point of a directed edge that connects the encapsulating ACDC node to the specified ACDC node as a fragment of a distributed property graph (PG). |
| `o` | Operator | Either unary operator on edge or m-ary operator on edge-group in edge section. Enables expressing of edge logic on edge subgraph. |
| `w` | Weight | Edge weight property that enables default property for directed weighted edges and operators on directed weighted edges. |
| `l` | Legal Language | Text of Ricardian contract clause. |
These may appear at other levels besides the top-level of an ACDC but are nonetheless reserved.
| Label | Title | Description |
| --- | --- | --- |
| `d` | Digest (SAID) | Self-referential fully qualified cryptographic digest of enclosing map. |
| `u` | UUID | Random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `i` | Identifier (AID) | Context dependent AID as determined by its enclosing map such as Issuee Identifier. |
| `n` | Node | SAID of another ACDC as the terminating point (vertex) of a directed edge that connects the encapsulating ACDC node to the specified ACDC node as a fragment of a distributed property graph (PG). |
| `o` | Operator | Either unary operator on edge or m-ary operator on edge-group in edge section. Enables expressing of edge logic on edge subgraph. |
| `w` | Weight | Edge weight property that enables default property for directed weighted edges and operators on directed weighted edges. |
| `l` | Legal Language | Text of Ricardian contract clause. |
The primary field labels are compact in that they use only one or two characters. ACDCs are meant to support resource-constrained applications such as supply chain or IoT (Internet of Things) applications. Compact labels better support resource-constrained applications in general. With compact labels, the over-the-wire verifiable signed serialization consumes a minimum amount of bandwidth. Nevertheless, without loss of generality, a one-to-one normative semantic overlay using more verbose expressive field labels may be applied to the normative compact labels after verification of the over-the-wire serialization. This approach better supports bandwidth and storage constraints on transmission while not precluding any later semantic post-processing. This is a well-known design pattern for resource-constrained applications.
The version string, `v`, field MUST be the first field in any top-level ACDC field map. It provides a regular expression target for determining the serialization format and size (character count) of a serialized ACDC. A stream-parser may use the version string to extract and deserialize (deterministically) any serialized ACDC in a stream of serialized ACDCs. Each ACDC in a stream may use a different serialization type.
The format of the version string is `ACDCvvSSSShhhhhh_`. The first four characters `ACDC` indicate the enclosing field map serialization. The next two characters, `vv` provide the lowercase hexadecimal notation for the major and minor version numbers of the version of the ACDC specification used for the serialization. The first `v` provides the major version number and the second `v` provides the minor version number. For example, `01` indicates major version 0 and minor version 1 or in dotted-decimal notation `0.1`. Likewise `1c` indicates major version 1 and minor version decimal 12 or in dotted-decimal notation `1.12`. The next four characters `SSSS` indicate the serialization type in uppercase. The four supported serialization types are `JSON`, `CBOR`, `MGPK`, and `CESR` for the JSON, CBOR, MessagePack, and CESR serialization standards respectively {{JSON}}{{RFC4627}}{{CBOR}}{{RFC8949}}{{MGPK}}{{CESR\_ID}}. The next six characters provide in lowercase hexadecimal notation the total number of characters in the serialization of the ACDC. The maximum length of a given ACDC is thereby constrained to be _224 = 16,777,216_ characters in length. The final character `-` is the version string terminator. This enables later versions of ACDC to change the total version string size and thereby enable versioned changes to the composition of the fields in the version string while preserving deterministic regular expression extractability of the version string. Although a given ACDC serialization type may have a field map delimiter or framing code characters that appear before (i.e. prefix) the version string field in a serialization, the set of possible prefixes is sufficiently constrained by the allowed serialization protocols to guarantee that a regular expression can determine unambiguously the start of any ordered field map serialization that includes the version string as the first field value. Given the version string, a parser may then determine the end of the serialization so that it can extract the full ACDC from the stream without first deserializing it. This enables performant stream parsing and off-loading of ACDC streams that include any or all of the supported serialization types.
Some fields in ACDCs may have for their value either a _field map_ or a SAID. A SAID follows the SAID protocol {{SAID\_ID}}. Essentially a SAID is a Self-Addressing IDentifier (self-referential content addressable). A SAID is a special type of cryptographic digest of its encapsulating _field map_ (block). The encapsulating block of a SAID is called a SAD (Self-Addressed Data). Using a SAID as a _field value_ enables a more compact but secure representation of the associated block (SAD) from which the SAID is derived. Any nested field map that includes a SAID field (i.e. is, therefore, a SAD) may be compacted into its SAID. The uncompacted blocks for each associated SAID may be attached or cached to optimize bandwidth and availability without decreasing security.
Several top-level ACDC fields may have for their value either a serialized _field map_ or the SAID of that _field map_. Each SAID provides a stable universal cryptographically verifiable and agile reference to its encapsulating block (serialized _field map_). Specifically, the value of top-level `s`, `a`, `e`, and `r` fields may be replaced by the SAID of their associated _field map_. When replaced by their SAID, these top-level sections are in _compact_ form.
Recall that a cryptographic commitment (such as a digital signature or cryptographic digest) on a given digest with sufficient cryptographic strength including collision resistance {{HCR}}{{QCHC}} is equivalent to a commitment to the block from which the given digest was derived. Specifically, a digital signature on a SAID makes a verifiable cryptographic non-repudiable commitment that is equivalent to a commitment on the full serialization of the associated block from which the SAID was derived. This enables reasoning about ACDCs in whole or in part via their SAIDS in a fully interoperable, verifiable, compact, and secure manner. This also supports the well-known bow-tie model of Ricardian Contracts {{RC}}. This includes reasoning about the whole ACDC given by its top-level SAID, `d`, field as well as reasoning about any nested sections using their SAIDS.
The purpose of the UUID, `u`, field in any block is to provide sufficient entropy to the SAID, `d`, field of the associated block to make computationally infeasible any brute force attacks on that block that attempt to discover the block contents from the schema and the SAID. The UUID, `u`, field may be considered a salty nonce {{Salt}}. Without the entropy provided the UUID, `u`, field, an adversary may be able to reconstruct the block contents merely from the SAID of the block and the schema of the block using a rainbow or dictionary attack on the set of field values allowed by the schema {{RB}}{{DRB}}. The effective security level, entropy, or cryptographic strength of the schema-compliant field values may be much less than the cryptographic strength of the SAID digest. Another way of saying this is that the cardinality of the power set of all combinations of allowed field values may be much less than the cryptographic strength of the SAID. Thus an adversary could successfully discover via brute force the exact block by creating digests of all the elements of the power set which may be small enough to be computationally feasible instead of inverting the SAID itself. Sufficient entropy in the `u` field ensures that the cardinality of the power set allowed by the schema is at least as great as the entropy of the SAID digest algorithm itself.
A UUID, `u` field may optionally appear in any block (field map) at any level of an ACDC. Whenever a block in an ACDC includes a UUID, `u`, field then its associated SAID, `d`, field makes a blinded commitment to the contents of that block. The UUID, `u`, field is the blinding factor. This makes that block securely partially disclosable or even selectively disclosable notwithstanding disclosure of the associated schema of the block. The block contents can only be discovered given disclosure of the included UUID field. Likewise when a UUID, `u`, field appears at the top level of an ACDC then that top-level SAID, `d`, field makes a blinded commitment to the contents of the whole ACDC itself. Thus the whole ACDC, not merely some block within the ACDC, may be disclosed in a privacy-preserving (correlation minimizing) manner.
Some fields, such as the `i`, Issuer identifier field MUST each have an AID (Autonomic IDentifier) as its value. An AID is a fully qualified Self-Certifying IDentifier (SCID) that follows the KERI protocol {{KERI}}{{KERI\_ID}}. A related type of identifier field is the `ri`, registry identifier field. The `ri` field is cryptographically derived from the Issuer identifier field value so has securely attributable control authority via the AID from which it is derived. A SCID is derived from one or more `(public, private)` key pairs using asymmetric or public-key cryptography to create verifiable digital signatures {{DSig}}. Each AID has a set of one or more controllers who each control a private key. By virtue of their private key(s), the set of controllers may make statements on behalf of the associated AID that is backed by uniquely verifiable commitments via digital signatures on those statements. Any entity may then verify those signatures using the associated set of public keys. No shared or trusted relationship between the controllers and verifiers is required. The verifiable key state for AIDs is established with the KERI protocol {{KERI}}{{KERI\_ID}}. The use of AIDS enables ACDCs to be used in a portable but securely attributable, fully decentralized manner in an ecosystem that spans trust domains.
Because KERI is agnostic about the namespace for any particular AID, different namespace standards may be used to express KERI AIDs or identifiers derived from AIDs as the value of thes AID related fields in an ACDC. The examples below use the W3C DID namespace specification with the `did:keri` method {{DIDK\_ID}}. But the examples would have the same validity from a KERI perspective if some other supported namespace was used or no namespace was used at all. The latter case consists of a bare KERI AID (identifier prefix) expressed in CESR format {{CESR\_ID}}.
The top-level selectively-disclosable attribute aggregate section, `A`, field value is an aggregate of cryptographic commitments used to make a commitment to a set (bundle) of selectively-disclosable attributes. The value of the attribute aggregate, `A`, field depends on the type of selective disclosure mechanism employed. For example, the aggregate value could be the cryptographic digest of the concatenation of an ordered set of cryptographic digests, a Merkle tree root digest of an ordered set of cryptographic digests, or a cryptographic accumulator.
ACDC leverages several closely related mechanisms for what can be called **_graduated disclosure_**. _Graduated disclosure_ enables adherence to the principle of least disclosure which is expressed as follows:
> The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. {{IDSys}}
To clarify, _graduated disclosure_ enables a potential Discloser to follow the principle of _least disclosure_ by providing the least amount of information i.e. partial, incomplete, or uncorrelatable information needed to further a transaction.
The important insight is that one type of transaction enabled by least disclosure is a transaction that specifically enables further disclosure. In other words, disclose enough to enable more disclosure which in turn may enable even more disclosure. This is the essence of _graduated disclosure_. This progression of successive least graduated disclosures to enable a transaction that itself enables a farther least graduated disclosure forms a recursive loop of least disclosure enabled transactions. In other words, the principle of least disclosure may be applied recursively.
A type of transaction that leverages _graduated disclosure_ to enable further disclosure we call a **_contractually protected disclosure_** transaction. In a contractually protected disclosure, the potential Discloser first makes an offer using the least (partial) disclosure of some information about other information to be disclosed (full disclosure) contingent on the potential Disclosee first agreeing to the contractual terms provided in the offer. The contractual terms could, for example, limit the disclosure to third parties of the yet to be disclosed information. But those contractual terms may also include provisions that protect against liability or other concerns not merely disclosure to third parties.
One special case of a _contractually protected disclosure_ is a **_chain-link confidential disclosure_** {{CLC}}.
Another special case of _contractually protected disclosure_ is a **_contingent-disclosure_**. In a _contingent disclosure_ some contingency is specified in the rule section that places an obligation by some party to make a disclosure when the contingency is satisfied. This might be recourse given the breach of some other term of the contract. When that contingency is met then the contingent disclosure MUST be made by the party whose responsibility it is to satisfy that disclosure obligation. The responsible party may be the Discloser of the ACDC or it may be some other party such as an escrow agent. The contingent disclosure clause may reference a cryptographic commitment to a private ACDC or private attribute ACDC (partial disclosure) that satisfies via its full disclosure the contingent disclosure requirement. Contingent disclosure may be used to limit the actual disclosure of personally identifying information (PII) to a just-in-time, need-to-know basis (i.e upon the contingency) and not a priori. As long as the Discloser and Disclosee trust the escrow agent and the verifiability of the committment, there is no need to disclose PII about the discloser in order to enable a transaction, but merely an agreement to the terms of the contingency. This enables something called **_latent accountability_**. Recourse via PII is latent in the contingent disclosure but is not ever realized (actualized) until recourse is truly needed. The minimizes inadvertent leakage while protecting the Disclosee.
ACDCs employ three specific closely related types of _graduated disclosure_. These are **_compact disclosure_**, **_partial disclosure_**, and **_selective disclosure_**. The mechanism for _compact disclosure_ is a cryptographic digest of the content expressed in the form of a SAID of that content. Both partial and selective disclosure rely on the compact disclosure of content that is also cryptographically blinded or hidden. Content in terms of an ACDC means a block (field map or field map array).
The difference between **_partial disclosure_** and **_selective disclosure_** of a given block is determined by the correlatability of the disclosed field(s) after **_full disclosure_** of the detailed field value with respect to its enclosing block (field map or field map array). A _partially disclosable_ field becomes correlatable after _full disclosure_. Whereas a _selectively disclosable_ field may be excluded from the _full disclosure_ of any other _selectively disclosable_ fields in the _selectively disclosable_ block (usually a field map array). After such _selective disclosure_, the selectively disclosed fields are not correlatable to the so-far undisclosed but selectively disclosable fields in that block (field map array).
When used in the context of _selective disclosure_, _full disclosure_ means detailed disclosure of the selectively disclosed attributes not detailed disclosure of all selectively disclosable attributes. Whereas when used in the context of _partial disclosure_, _full disclosure_ means detailed disclosure of the field map that was so far only partially disclosed.
_Partial disclosure_ is an essential mechanism needed to support both performant exchange of information and contractually protected disclosure such as chain-link confidentiality on exchanged information {{CLC}}. The exchange of only the SAID of a given field map is a type of _partial disclosure_. Another type of _partial disclosure_ is the disclosure of validatable metadata about a detailed field map e.g. the schema of a field map.
The SAID of a field map provides a _compact_ cryptographically equivalent commitment to the yet to be undisclosed field map details. A later exchange of the uncompacted field map detail provides _full disclosure_. Any later _full disclosure_ is verifiable to an earlier _partial disclosure_. Partial disclosure via compact SAIDs enables the scalable repeated verifiable exchange of SAID references to cached full disclosures. Multiple SAID references to cached fully disclosed field maps may be transmitted compactly without redundant retransmission of the full details each time a new reference is transmitted. Likewise, _partial disclosure_ via SAIDs also supports the bow-tie model of Ricardian contracts {{RC}}. Similarly, the schema of a field map is metadata about the structure of the field map this is validatable given the full disclosure of the field map. The details of_compact_ and/or confidential exchange mechanisms that leverage partial disclosure are explained later. When the field map includes sufficient cryptographic entropy such as through a UUID field (salty nonce), then the SAID of that field map effectively blinds the contents of the field map. This enables the field map contents identified by its SAID and characterized by its schema (i.e. partial disclosure) to remain private until later full disclosure.
_Selective disclosure_, on the other hand, is an essential mechanism needed to unbundle in a correlation minimizing way a single commitment by an Issuer to a bundle of fields (i.e. a nested array or list or tuple of fields) as a whole. This allows separating a "stew" (bundle) of "ingredients" (attributes) into its constituent "ingredients" (attributes) without correlating the constituents via the Issuer's commitment to the "stew" (bundle) as a whole.
Notable is the fact that there are no top-level type fields in an ACDC. This is because the schema, `s`, field itself is the type field for the ACDC and its parts. ACDCs follow the design principle of separation of concerns between a data container's actual payload information and the type information of that container's payload. In this sense, type information is metadata, not data. The schema dialect used by ACDCs is JSON Schema 2020-12 {{JSch}}{{JSch\_202012}}. JSON Schema supports composable schema (sub-schema), conditional schema (sub-schema), and regular expressions in the schema. Composability enables a validator to ask and answer complex questions about the type of even optional payload elements while maintaining isolation between payload information and type (structure) information about the payload {{JSchCp}}{{JSchRE}}{{JSchId}}{{JSchCx}}. A static but composed schema allows a verifiably immutable set of variants. Although the set is immutable, the variants enable graduated but secure disclosure. ACDC's use of JSON Schema MUST be in accordance with the ACDC defined profile as defined herein. The exceptions are defined below.
The usual field label for SAID fields in ACDCs is `d`. In the case of the schema section, however, the field label for the SAID of the schema section is `$id`. This repurposes the schema id field label, `$id` as defined by JSON Schema {{JSchId}}{{JSchCx}}. The top-level id, `$id`, field value in a JSON Schema provides a unique identifier of the schema instance. In a usual (non-ACDC) schema the value of the id, `$id`, field is expressed as a URI. This is called the _Base URI_ of the schema. In an ACDC schema, however, the top-level id, `$id`, field value is repurposed. Its value MUST include the SAID of the schema. This ensures that the ACDC schema is static and verifiable to their SAIDS. A verifiably static schema satisfies one of the essential security properties of ACDCs as discussed below. There are several ACDC supported formats for the value of the top-level id, `$id`, field but all of the formats MUST include the SAID of the schema (see below). Correspondingly, the value of the top-level schema, `s`, field MUST be the SAID included in the schema's top-level `$id` field. The detailed schema is either attached or cached and maybe discovered via its SAIDified, id, `$id`, field value.
When an id, '$id', field appears in a sub-schema it indicates a bundled sub-schema called a schema resource {{JSchId}}{{JSchCx}}. The value of the id, '$id', field in any ACDC bundled sub-schema resource MUST include the SAID of that sub-schema using one of the formats described below. The sub-schema so bundled MUST be verifiable against its referenced and embedded SAID value. This ensures secure bundling.
For security reasons, the full schema of an ACDC must be completely self-contained and statically fixed (immutable) for that ACDC. By this, we mean that no dynamic schema references or dynamic schema generation mechanisms are allowed.
Should an adversary successfully attack the source that provides the dynamic schema resource and change the result provided by that reference, then the schema validation on any ACDC that uses that dynamic schema reference may fail. Such an attack effectively revokes all the ACDCs that use that dynamic schema reference. We call this a **_schema revocation_** attack.
More insidiously, an attacker could shift the semantics of the dynamic schema in such a way that although the ACDC still passes its schema validation, the behavior of the downstream processing of that ACDC is changed by the semantic shift. This we call a **_semantic malleability_** attack. It may be considered a new type of _transaction malleability_ attack {{TMal}}.
To prevent both forms of attack, all schema must be static, i.e. schema MUST be SADs and therefore verifiable against their SAIDs.
To elaborate, the serialization of a static schema may be self-contained. A compact commitment to the detailed static schema may be provided by its SAID. In other words, the SAID of a static schema is a verifiable cryptographic identifier for its SAD. Therefore all ACDC compliant schema must be SADs. In other words, they MUST therefore be _SAIDified_. The associated detailed static schema (uncompacted SAD) is cryptographically bound and verifiable to its SAID.
The JSON Schema specification allows complex schema references that may include non-local URI references {{JSchId}}{{JSchCx}}{{RFC3986}}{{RFC8820}}. These references may use the `$id` or `$ref` keywords. A relative URI reference provided by a `$ref` keyword is resolved against the _Base URI_ provided by the top-level `$id` field. When this top-level _Base URI_ is non-local then all relative `$ref` references are therefore also non-local. A non-local URI reference provided by a `$ref` keyword may be resolved without reference to the _Base URI_.
In general, schema indicated by non-local URI references (`$id` or `$ref`) MUST NOT be used because they are not cryptographically end-verifiable. The value of the underlying schema resource so referenced may change (mutate). To restate, a non-local URI schema resource is not end-verifiable to its URI reference because there is no cryptographic binding between URI and resource {{RFC3986}}{{RFC8820}}.
This does not preclude the use of remotely cached SAIDified schema resources because those resources are end-verifiable to their embedded SAID references. Said another way, a SAIDified schema resource is itself a SAD (Self-Address Data) referenced by its SAID. A URI that includes a SAID may be used to securely reference a remote or distributed SAIDified schema resource because that resource is fixed (immutable, nonmalleable) and verifiable to both the SAID in the reference and the embedded SAID in the resource so referenced. To elaborate, a non-local URI reference that includes an embedded cryptographic commitment such as a SAID is verifiable to the underlying resource when that resource is a SAD. This applies to JSON Schema as a whole as well as bundled sub-schema resources.
There ACDC supported formats for the value of the top-level id, `$id`, field are as follows:
- Bare SAIDs may be used to refer to a SAIDified schema as long as the JSON schema validator supports bare SAID references. By default, many if not all JSON schema validators support bare strings (non-URIs) for the _Base URI_ provided by the top-level `$id` field value.
- The `sad:` URI scheme may be used to directly indicate a URI resource that safely returns a verifiable SAD. For example `sad:SAID` where _SAID_ is replaced with the actual SAID of a SAD that provides a verifiable non-local reference to JSON Schema as indicated by the mime-type of `schema+json`.
- The IETF KERI OOBI internet draft specification provides a URL syntax that references a SAD resource by its SAID at the service endpoint indicated by that URL {{OOBI\_ID}}. Such remote OOBI URLs are also safe because the provided SAD resource is verifiable against the SAID in the OOBI URL. Therefore OOBI URLs are also acceptable non-local URI references for JSON Schema {{OOBI\_ID}}{{RFC3986}}{{RFC8820}}.
- The `did:` URI scheme may be used safely to prefix non-local URI references that act to namespace SAIDs expressed as DID URIs or DID URLs. DID resolvers resolve DID URLs for a given DID method such as `did:keri` {{DIDK\_ID}} and may return DID docs or DID doc metadata with SAIDified schema or service endpoints that return SAIDified schema or OOBIs that return SAIDified schema {{RFC3986}}{{RFC8820}}{{OOBI\_ID}}. A verifiable non-local reference in the form of DID URL that includes the schema SAID is resolved safely when it dereferences to the SAD of that SAID. For example, the resolution result returns an ACDC JSON Schema whose id, `$id`, field includes the SAID and returns a resource with JSON Schema mime-type of `schema+json`.
To clarify, ACDCs MUST NOT use complex JSON Schema references which allow _dynamically generated_ schema resources to be obtained from online JSON Schema Libraries {{JSchId}}{{JSchCx}}. The latter approach may be difficult or impossible to secure because a cryptographic commitment to the base schema that includes complex schema (non-relative URI-based) references only commits to the non-relative URI reference and not to the actual schema resource which may change (is dynamic, mutable, malleable). To restate, this approach is insecure because a cryptographic commitment to a complex (non-relative URI-based) reference is NOT equivalent to a commitment to the detailed associated schema resource so referenced if it may change.
ACDCs MUST use static JSON Schema (i.e. _SAIDifiable_ schema). These may include internal relative references to other parts of a fully self-contained static (_SAIDified_) schema or references to static (_SAIDified_) external schema parts. As indicated above, these references may be bare SAIDs, DID URIs or URLs (`did:` scheme), SAD URIs (`sad:` scheme), or OOBI URLs {{OOBI\_ID}}. Recall that a commitment to a SAID with sufficient collision resistance makes an equivalent secure commitment to its encapsulating block SAD. Thus static schema may be either fully self-contained or distributed in parts but the value of any reference to a part must be verifiably static (immutable, nonmalleable) by virtue of either being relative to the self-contained whole or being referenced by its SAID. The static schema in whole or in parts may be attached to the ACDC itself or provided via a highly available cache or data store. To restate, this approach is securely end-verifiable (zero-trust) because a cryptographic commitment to the SAID of a SAIDified schema is equivalent to a commitment to the detailed associated schema itself (SAD).
The schema dialect for ACDC 1.0 is JSON Schema 2020-12 and is indicated by the identifier `"https://json-schema.org/draft/2020-12/schema"` {{JSch}}{{JSch\_202012}}. This is indicated in a JSON Schema via the value of the top-level `$schema` field. Although the value of `$schema` is expressed as a URI, de-referencing does not provide dynamically downloadable schema dialect validation code. This would be an attack vector. The validator MUST control the tooling code dialect used for schema validation and hence the tooling dialect version actually used. A mismatch between the supported tooling code dialect version and the `$schema` string value should cause the validation to fail. The string is simply an identifier that communicates the intended dialect to be processed by the schema validation tool. When provided, the top-level `$schema` field value for ACDC version 1.0 must be "[https://json-schema.org/draft/2020-12/schema"](https://json-schema.org/draft/2020-12/schema%22).
The composed detailed (uncompacted) (bundled) static schema for an ACDC may be cached or attached. But cached, and/or attached static schema is not to be confused with dynamic schema. Nonetheless, while securely verifiable, a remotely cached, _SAIDified_, schema resource may be unavailable. Availability is a separate concern. Unavailable does not mean insecure or unverifiable. ACDCs MUST be verifiable when available. Availability is typically solvable through redundancy. Although a given ACDC application domain or eco-system governance framework may impose schema availability constraints, the ACDC specification itself does not impose any specific availability requirements on Issuers other than schema caches SHOULD be sufficiently available for the intended application of their associated ACDCs. It's up to the Issuer of an ACDC to satisfy any availability constraints on its schema that may be imposed by the application domain or eco-system.
A composable JSON Schema enables the use of any combination of compacted/uncompacted attribute, edge, and rule sections in a provided ACDC. When compact, any one of these sections may be represented merely by its SAID {{JSch}}{{JSchCp}}. When used for the top-level attribute, `a`, edge, `e`, or rule, `r`, section field values, the `oneOf` sub-schema composition operator provides both compact and uncompacted variants. The provided ACDC MUST validate against an allowed combination of the composed variants, either the compact SAID of a block or the full detailed (uncompacted) block for each section. The validator determines what decomposed variants the provided ACDC MUST also validate against. Decomposed variants may be dependent on the type of graduated disclosure, partial, full, or selective. Essentially a composable schema is a verifiable bundle of metadata (composed) about content that then can be verifiably unbundled (decomposed) later. The Issuer makes a single verifiable commitment to the bundle (composed schema) and a recipient may then safely unbundle (decompose) the schema to validate any of the graduated disclosures variants allowed by the composition.
Unlike the other compactifiable sections, it is impossible to define recursively the exact detailed schema as a variant of a `oneOf` composition operator contained in itself. Nonetheless, the provided schema, whether self-contained, attached, or cached MUST validate as a SAD against its provided SAID. It MUST also validate against one of its specified `oneOf` variants.
The compliance of the provided non-schema attribute, `a`, edge, `e`, and rule, `r`, sections MUST be enforced by validating against the composed schema. In contrast, the compliance of the provided composed schema for an expected ACDC type MUST be enforced by the validator. This is because it is not possible to enforce strict compliance of the schema by validating it against itself.
ACDC specific schema compliance requirements are usually specified in the eco-system governance framework for a given ACDC type. Because the SAID of a schema is a unique content-addressable identifier of the schema itself, compliance can be enforced by comparison to the allowed schema SAID in a well-known publication or registry of ACDC types for a given ecosystem governance framework (EGF). The EGF may be solely specified by the Issuer for the ACDCs it generates or be specified by some mutually agreed upon eco-system governance mechanism. Typically the business logic for making a decision about a presentation of an ACDC starts by specifying the SAID of the composed schema for the ACDC type that the business logic is expecting from the presentation. The verified SAID of the actually presented schema is then compared against the expected SAID. If they match then the actually presented ACDC may be validated against any desired decomposition of the expected (composed) schema.
To elaborate, a validator can confirm compliance of any non-schema section of the ACDC against its schema both before and after uncompacted disclosure of that section by using a composed base schema with `oneOf` pre-disclosure and a decomposed schema post-disclosure with the compact `oneOf` option removed. This capability provides a mechanism for secure schema validation of both compact and uncompacted variants that require the Issuer to only commit to the composed schema and not to all the different schema variants for each combination of a given compact/uncompacted section in an ACDC.
One of the most important features of ACDCs is support for Chain-Link Confidentiality {{CLC}}. This provides a powerful mechanism for protecting against un-permissioned exploitation of the data disclosed via an ACDC. Essentially an exchange of information compatible with chain-link confidentiality starts with an offer by the discloser to disclose confidential information to a potential disclosee. This offer includes sufficient metadata about the information to be disclosed such that the disclosee can agree to those terms. Specifically, the metadata includes both the schema of the information to be disclosed and the terms of use of that data once disclosed. Once the disclosee has accepted the terms then full disclosure is made. A full disclosure that happens after contractual acceptance of the terms of use we call _permissioned_ disclosure. The pre-acceptance disclosure of metadata is a form of partial disclosure.
As is the case for compact (uncompacted) ACDC disclosure, Composable JSON Schema, enables the use of the same base schema for both the validation of the partial disclosure of the offer metadata prior to contract acceptance and validation of full or detailed disclosure after contract acceptance {{JSch}}{{JSchCp}}. A cryptographic commitment to the base schema securely specifies the allowable semantics for both partial and full disclosure. Decomposition of the base schema enables a validator to impose more specific semantics at later stages of the exchange process. Specifically, the `oneOf` sub-schema composition operator validates against either the compact SAID of a block or the full block. Decomposing the schema to remove the optional compact variant enables a validator to ensure complaint full disclosure. To clarify, a validator can confirm schema compliance both before and after detailed disclosure by using a composed base schema pre-disclosure and a decomposed schema post-disclosure with the undisclosed options removed. These features provide a mechanism for secure schema-validated contractually-bound partial (and/or selective) disclosure of confidential data via ACDCs.
There are several variants of ACDCs determined by the presence/absence of certain fields and/or the value of those fields. At the top level, the presence (absence), of the UUID, `u`, field produces two variants. These are private (public) respectively. In addition, a present but empty UUID, `u`, field produces a private metadata variant.
Given that there is no top-level UUID, `u`, field in an ACDC, then knowledge of both the schema of the ACDC and the top-level SAID, `d`, field may enable the discovery of the remaining contents of the ACDC via a rainbow table attack {{RB}}{{DRB}}. Therefore, although the top-level, `d`, field is a cryptographic digest, it may not securely blind the contents of the ACDC when knowledge of the schema is available. The field values may be discoverable. Consequently, any cryptographic commitment to the top-level SAID, `d`, field may provide a fixed point of correlation potentially to the ACDC field values themselves in spite of non-disclosure of those field values. Thus an ACDC without a top-level UUID, `u`, field must be considered a **_public_** (non-confidential) ACDC.
Given a top-level UUID, `u`, field, whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of an ACDC may provide a secure cryptographic digest that blinds the contents of the ACDC {{Hash}}. An adversary when given both the schema of the ACDC and the top-level SAID, `d`, field, is not able to discover the remaining contents of the ACDC in a computationally feasible manner such as through a rainbow table attack {{RB}}{{DRB}}. Therefore the top-level, UUID, `u`, field may be used to securely blind the contents of the ACDC notwithstanding knowledge of the schema and top-level, SAID, `d`, field. Moreover, a cryptographic commitment to that that top-level SAID, `d`, field does not provide a fixed point of correlation to the other ACDC field values themselves unless and until there has been a disclosure of those field values. Thus an ACDC with a sufficiently high entropy top-level UUID, `u`, field may be considered a **_private_** (confidential) ACDC. enables a verifiable commitment to the top-level SAID of a private ACDC to be made prior to the disclosure of the details of the ACDC itself without leaking those contents. This is called _partial_ disclosure. Furthermore, the inclusion of a UUID, `u`, field in a block also enables _selective_ disclosure mechanisms described later in the section on selective disclosure.
An empty, top-level UUID, `u`, field appearing in an ACDC indicates that the ACDC is a **_metadata_** ACDC. The purpose of a _metadata_ ACDC is to provide a mechanism for a _Discloser_ to make cryptographic commitments to the metadata of a yet to be disclosed private ACDC without providing any point of correlation to the actual top-level SAID, `d`, field of that yet to be disclosed ACDC. The top-level SAID, `d`, field, of the metadata ACDC, is cryptographically derived from an ACDC with an empty top-level UUID, `u`, field so its value will necessarily be different from that of an ACDC with a high entropy top-level UUID, `u`, field value. Nonetheless, the _Discloser_ may make a non-repudiable cryptographic commitment to the metadata SAID in order to initiate a chain-link confidentiality exchange without leaking correlation to the actual ACDC to be disclosed {{CLC}}. A _Disclosee_ (verifier) may validate the other metadata information in the metadata ACDC before agreeing to any restrictions imposed by the future disclosure. The metadata includes the _Issuer_, the _schema_, the provenancing _edges_, and the _rules_ (terms-of-use). The top-level attribute section, `a`, field value of a _metadata_ ACDC may be empty so that its value is not correlatable across disclosures (presentations). Should the potential _Disclosee_ refuse to agree to the rules then the _Discloser_ has not leaked the SAID of the actual ACDC or the SAID of the attribute block that would have been disclosed.
Given the _metadata_ ACDC, the potential _Disclosee_ is able to verify the _Issuer_, the schema, the provenanced edges, and rules prior to agreeing to the rules. Similarly, an _Issuer_ may use a _metadata_ ACDC to get agreement to a contractual waiver expressed in the rule section with a potential _Issuee_ prior to issuance. Should the _Issuee_ refuse to accept the terms of the waiver then the _Issuer_ has not leaked the SAID of the actual ACDC that would have been issued nor the SAID of its attributes block nor the attribute values themselves.
When a _metadata_ ACDC is disclosed (presented) only the _Discloser's_ signature(s) is attached not the _Issuer's_ signature(s). This precludes the _Issuer's_ signature(s) from being used as a point of correlation until after the _Disclosee_ has agreed to the terms in the rule section. When chain-link confidentiality is used, the _Issuer's_ signatures are not disclosed to the _Disclosee_ until after the _Disclosee_ has agreed to keep them confidential. The _Disclosee_ is protected from forged _Discloser_ because ultimately verification of the disclosed ACDC will fail if the _Discloser_ does not eventually provide verifiable _Issuer's_ signatures. Nonetheless, should the potential _Disclosee_ not agree to the terms of the disclosure expressed in the rule section then the _Issuer's_ signature(s) is not leaked.
An important design goal of ACDCs is they support the sharing of provably authentic data while also protecting against the un-permissioned exploitation of that data. Often the term _privacy protection_ is used to describe similar properties. But a narrow focus on "privacy protection" may lead to problematic design trade-offs. With ACDCs, the primary design goal is not _data privacy protection_ per se but the more general goal of protection from the **_un-permissioned exploitation of data_**. In this light, a _given privacy protection_ mechanism may be employed to help protect against _unpermissioned exploitation of data_ but only when it serves that more general-purpose and not as an end in and of itself.
As described previously, ACDCs employ _graduated disclosure_ mechanisms that satisfy the principle of least disclosure. Requoted here the principle of least disclosure is as follows:
> The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. {{IDSys}}
For example, compact disclosure, partial disclosure, and selective disclosure are all graduated disclosure mechanisms. Contractually protected disclosure leverages graduated disclosure so that contractual protections can be put into place using the least disclosure necessary to that end. This minimizes the leakage of information that can be correlated. One type of contractually protected disclosure is chain-link confidentiality {{CLC}}.
An ACDC may employ several mechanisms to protect against _unpermissioned exploitation of data_. These are:
- Contractually Protected Disclosure
- Chain-link Confidentiality {{CLC}}
- Contingent Disclosure
- Partial Disclosure
- Selective Disclosure
For example, the _partial disclosure_ of portions of an ACDC to enable chain-link confidentiality of the subsequent full disclosure is an application of the principle of least disclosure. Likewise, unbundling only the necessary attributes from a bundled commitment using _selective disclosure_ to enable a correlation minimizing disclosure from that bundle is an application of the principle of least disclosure.
Unpermission exploitation is characterized using a three-party model. The three parties are as follows:
- First-Party = _Discloser_ of data.
- Second-Party = _Disclosee_ of data received from First Party (_Discloser_).
- Third-Party = _Observer_ of data disclosed by First Party (_Discloser_) to Second Party (_Disclosee_).
- implicit permissioned correlation.
- no contractual restrictions on the use of disclosed data.
- explicit permissioned correlation.
- use as permitted by contract
- explicit unpermissioned correlation with other second parties or third parties.
- malicious use in violation of contract
- implicit permissioned correlation.
- no contractual restrictions on the use of observed data.
- explicit unpermissioned correlation via collusion with second parties.
- malicious use in violation of second-party contract
Chain-link confidentiality imposes contractual restrictions and liability on any Disclosee (Second-Party) {{CLC}}. The exchange provides a fair contract consummation mechanism. The essential steps in a chain-link confidentiality exchange are shown below. Other steps may be included in a more comprehensive exchange protocol.
- _Discloser_ provides a non-repudiable _Offer_ with verifiable metadata (sufficient partial disclosure), which includes any terms or restrictions on use.
- _Disclosee_ verifies _Offer_ against composed schema and metadata adherence to desired data.
- _Disclosee_ provides non-repudiable _Accept_ of terms that are contingent on compliant disclosure.
- _Discloser_ provides non-repudiable _Disclosure_ with sufficient compliant detail.
- _Disclosee_ verifies _Disclosure_ using decomposed schema and adherence of disclosed data to _Offer_.
_Disclosee_ may now engage in permissioned use and carries liability as a deterrent against unpermissioned use.
The ordering of the top-level fields when present in an ACDC MUST be as follows, `v`, `d`, `u`, `i`, `ri`, `s`, `a`, `e`, `r`.
The top-level section field values of a compact ACDC are the SAIDs of each uncompacted top-level section. The section field labels are `s`, `a`, `e`, and `r`.
A fully compact public ACDC is shown below.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
A fully compact private ACDC is shown below.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"u": "0ANghkDaG7OY1wjaDAE0qHcg",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
The schema for the compact private ACDC example above is provided below.
```
{
"$id": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Compact Private ACDC",
"description": "Example JSON Schema for a Compact Private ACDC.",
"credentialType": "CompactPrivateACDCExample",
"type": "object",
"required":
[
"v",
"d",
"u",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"u":
{
"description": "ACDC UUID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry ID",
"type": "string"
},
"s": {
"description": "schema SAID",
"type": "string"
},
"a": {
"description": "attribute SAID",
"type": "string"
},
"e": {
"description": "edge SAID",
"type": "string"
},
"r": {
"description": "rule SAID",
"type": "string"
}
},
"additionalProperties": false
}
```
The attribute section in the examples above has been compacted into its SAID. The schema of the compacted attribute section is as follows,
```
{
"a":
{
"description": "attribute section SAID",
"type": "string"
}
}
```
Two variants of an ACDC, namely, namely, **_private (public) attribute_** are defined respectively by the presence (absence) of a UUID, `u`, field in the uncompacted attribute section block.
Two other variants of an ACDC, namely, **_targeted (untargeted)_** are defined respectively by the presence (absence) of an issuee, `i`, field in the uncompacted attribute section block.
Suppose that the un-compacted value of the attribute section as denoted by the attribute section, `a`, field is as follows,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
}
}
```
The SAID, `d`, field at the top level of the uncompacted attribute block is the same SAID used as the compacted value of the attribute section, `a`, field.
Given the absence of a `u` field at the top level of the attributes block, then knowledge of both SAID, `d`, field at the top level of an attributes block and the schema of the attributes block may enable the discovery of the remaining contents of the attributes block via a rainbow table attack {{RB}}{{DRB}}. Therefore the SAID, `d`, field of the attributes block, although, a cryptographic digest, does not securely blind the contents of the attributes block given knowledge of the schema. It only provides compactness, not privacy. Moreover, any cryptographic commitment to that SAID, `d`, field provides a fixed point of correlation potentially to the attribute block field values themselves in spite of non-disclosure of those field values via a compact ACDC. Thus an ACDC without a UUID, `u`, field in its attributes block must be considered a **_public-attribute_** ACDC even when expressed in compact form.
The subschema for the public uncompacted attribute section is shown below,
```
{
"a":
{
"description": "attribute section",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
}
```
Through the use of the JSON Schema `oneOf` composition operator the following composed schema will validate against both the compact and un-compacted value of the attribute section field.
```
{
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute SAID",
"type": "string"
},
{
"description": "uncompacted attribute section",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
```
Consider the following form of an uncompacted private-attribute block,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"u": "0AwjaDAE0qHcgNghkDaG7OY1",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
}
}
```
Given the presence of a top-level UUID, `u`, field of the attribute block whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of the attribute block provides a secure cryptographic digest of the contents of the attribute block {{Hash}}. An adversary when given both the schema of the attribute block and its SAID, `d`, field, is not able to discover the remaining contents of the attribute block in a computationally feasible manner such as a rainbow table attack {{RB}}{{DRB}}. Therefore the attribute block's UUID, `u`, field in a compact ACDC enables its attribute block's SAID, `d`, field to securely blind the contents of the attribute block notwithstanding knowledge of the attribute block's schema and SAID, `d` field. Moreover, a cryptographic commitment to that attribute block's, SAID, `d`, field does not provide a fixed point of correlation to the attribute field values themselves unless and until there has been a disclosure of those field values.
To elaborate, when an ACDC includes a sufficiently high entropy UUID, `u`, field at the top level of its attributes block then the ACDC may be considered a **_private-attributes_** ACDC when expressed in compact form, that is, the attribute block is represented by its SAID, `d`, field and the value of its top-level attribute section, `a`, field is the value of the nested SAID, `d`, field from the uncompacted version of the attribute block. A verifiable commitment may be made to the compact form of the ACDC without leaking details of the attributes. Later disclosure of the uncompacted attribute block may be verified against its SAID, `d`, field that was provided in the compact form as the value of the top-level attribute section, `a`, field.
Because the _Issuee_ AID is nested in the attribute block as that block's top-level, issuee, `i`, field, a presentation exchange (disclosure) could be initiated on behalf of a different AID that has not yet been correlated to the _Issuee_ AID and then only correlated to the Issuee AID after the _Disclosee_ has agreed to the chain-link confidentiality provisions in the rules section of the private-attributes ACDC {{CLC}}.
Through the use of the JSON Schema `oneOf` composition operator, the following composed schema will validate against both the compact and un-compacted value of the private attribute section, `a`, field.
```
{
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute SAID",
"type": "string"
},
{
"description": "uncompacted attribute section",
"type": "object",
"required":
[
"d",
"u",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
```
As described above in the Schema section of this specification, the `oneOf` sub-schema composition operator validates against either the compact SAID of a block or the full block. A validator can use a composed schema that has been committed to by the Issuer to securely confirm schema compliance both before and after detailed disclosure by using the fully composed base schema pre-disclosure and a specific decomposed variant post-disclosure. Decomposing the schema to remove the optional compact variant (i.e. removing the `oneOf` compact option) enables a validator to ensure complaint full disclosure.
Consider the case where the issuee, `i`, field is absent at the top level of the attribute block as shown below,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"temp": 45,
"lat": "N40.3433",
"lon": "W111.7208"
}
}
```
This ACDC has an _Issuer_ but no _Issuee_. Therefore, there is no provably controllable _Target_ AID. This may be thought of as an undirected verifiable attestation or observation of the data in the attributes block by the _Issuer_. One could say that the attestation is addressed to "whom it may concern". It is therefore an **_untargeted_** ACDC, or equivalently an _unissueed_ ACDC. An _untargeted_ ACDC enables verifiable authorship by the Issuer of the data in the attributes block but there is no specified counter-party and no verifiable mechanism for delegation of authority. Consequently, the rule section may only provide contractual obligations of implied counter-parties.
This form of an ACDC provides a container for authentic data only (not authentic data as authorization). But authentic data is still a very important use case. To clarify, an untargeted ACDC enables verifiable authorship of data. An observer such as a sensor that controls an AID may make verifiable non-repudiable measurements and publish them as ACDCs. These may be chained together to provide provenance for or a chain-of-custody of any data. These ACDCs could be used to provide a verifiable data supply chain for any compliance-regulated application. This provides a way to protect participants in a supply chain from imposters. Such data supply chains are also useful as a verifiable digital twin of a physical supply chain {{Twin}}.
A hybrid chain of one or more targeted ACDCs ending in a chain of one or more untargeted ACDCs enables delegated authorized attestations at the tail of that chain. This may be very useful in many regulated supply chain applications such as verifiable authorized authentic datasheets for a given pharmaceutical.
When present at the top level of the attribute section, the issuee, `i`, field value provides the AID of the _Issuee_ of the ACDC. This _Issuee_ AID is a provably controllable identifier that serves as the _Target_ AID. This makes the ACDC a **_targeted_** ACDC or equivalently an _issueed_ ACDC. Targeted ACDCs may be used for many different purposes such as an authorization or a delegation directed at the _Issuee_ AID, i.e. the _Target_. In other words, a _targeted ACDC_ provides a container for authentic data that may also be used as some form of authorization such as a credential that is verifiably bound to the _Issuee_ as targeted by the _Issuer_. Furthermore, by virtue of the targeted _Issuee's_ provable control over its AID, the _targeted ACDC_ may be verifiably presented (disclosed) by the controller of the _Issuee_ AID.
For example, the definition of the term **_credential_** is _evidence of authority, status, rights, entitlement to privileges, or the like_. To elaborate, the presence of an attribute section top-level issuee, `i`, field enables the ACDC to be used as a verifiable credential given by the _Issuer_ to the _Issuee_.
One reason the issuee, `i`, field is nested into the attribute section, `a`, block is to enable the _Issuee_ AID to be private or partially or selectively disclosable. The _Issuee_ may also be called the _Holder_ or _Subject_ of the ACDC. But here we use the more semantically precise albeit less common terms of _Issuer_ and _Issuee_. The ACDC is issued from or by an _Issuer_ and is issued to or for an _Issuee_. This precise terminology does not bias or color the role (function) that an _Issuee_ plays in the use of an ACDC. What the presence of _Issuee_ AID does provide is a mechanism for control of the subsequent use of the ACDC once it has been issued. To elaborate, because the issuee, `i`, field value is an AID, by definition, there is a provable controller of that AID. Therefore that _Issuee_ controller may make non-repudiable commitments via digital signatures on behalf of its AID. Therefore subsequent use of the ACDC by the _Issuee_ may be securely attributed to the _Issuee_.
Importantly the presence of an issuee, `i`, field enables the associated _Issuee_ to make authoritative verifiable presentations or disclosures of the ACDC. A designated _Issuee_also better enables the initiation of presentation exchanges of the ACDC between that _Issuee_ as _Discloser_ and a _Disclosee_ (verifier).
In addition, because the _Issuee_ is a specified counter-party the _Issuer_ may engage in a contract with the _Issuee_ that the _Issuee_ agrees to by virtue of its non-repudiable signature on an offer of the ACDC prior to its issuance. This agreement may be a pre-condition to the issuance and thereby impose liability waivers or other terms of use on that _Issuee_.
Likewise, the presence of an issuee, `i`, field, enables the _Issuer_ to use the ACDC as a contractual vehicle for conveying an authorization to the _Issuee_. This enables verifiable delegation chains of authority because the _Issuee_ in one ACDC may become the _Issuer_ in some other ACDC. Thereby an _Issuer_ may delegate authority to an _Issuee_ who may then become a verifiably authorized _Issuer_ that then delegates that authority (or an attenuation of that authority) to some other verifiably authorized _Issuee_ and so forth.
In the compact ACDC examples above, the edge section has been compacted into merely the SAID of that section. Suppose that the un-compacted value of the edge section denoted by the top-level edge, `e`, field is as follows,
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
}
}
```
The edge section's top-level SAID, `d`, field is the SAID of the edge block and is the same SAID used as the compacted value of the ACDC's top-level edge, `e`, field. Each edge in the edge section gets its own field with its own local label. The value of the field may be a sub-block or in the simplest case a string. In the example above, the edge label is `"boss"`. Note that each edge does NOT include a type field. The type of each edge is provided by the schema vis-a-vis the label of that edge. This is in accordance with the design principle of ACDCs that may be succinctly expressed as "type-is-schema". This approach varies somewhat from many property graphs which often do not have a schema {{PGM}}{{Dots}}{{KG}}. Because ACDCs have a schema for other reasons, however, they leverage that schema to provide edge types with a cleaner separation of concerns. Notwithstanding, this separation, an edge sub-block may include a constraint on the type of the ACDC to which that edge points by including the SAID of the schema of the pointed-to ACDC as a property of that edge.
A main distinguishing feature of a _property graph_ (PG) is that both nodes and edges may have a set of properties {{PGM}}{{Dots}}{{KG}}. These might include modifiers that influence how the connected node is to be combined or place a constraint on the allowed type(s) of connected nodes.
There several reserved field labels for edge sub-blocks. These are detailed in the table below. Each edge sub-block may have other non-reserved field labels as needed for a particular edge type.
| Label | Title | Description |
| --- | --- | --- |
| `d` | Digest (SAID) | Optional, self-referential fully qualified cryptographic digest of enclosing edge map. |
| `u` | UUID | Optional random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `s` | Schema | Optional SAID of the JSON Schema block of the far node ACDC. |
| `n` | Node | Required SAID of the far ACDC as the terminating point of a directed edge that connects the edge's encapsulating near ACDC to the specified far ACDC as a fragment of a distributed property graph (PG). |
| `o` | Operator | Optional as either a unary operator on edge or an m-ary operator on edge-group in edge section. Enables expression of the edge logic on edge subgraph. |
| `w` | Weight | Optional edge weight property that enables default property for directed weighted edges and operators that use weights. |
The node, `n`, field is required. The SAID, `d`, UUID, `u`, schema, `s`, operator, `o`, and weight, `w`, fields are optional. To clarify, each edge sub-block MUST have a node, `n`, field and MAY have any combination of SAID, `d`, UUID, `u`, schema, `s`, operator, `o`, or weight, `w`, fields.
When present, the SAID, `d`, field MUST appear as the first field in the edge sub-block. When present,the value of the SAID, `d` field MUST be the SAID of its enclosing edge sub-block.
A UUID, `u`, field MUST not appear unless there is also a SAID, `d` field. When present, the UUID, `u`, field must appear immediately after as the SAID, `d`, field in the edge sub-block. When present, the value of the UUID, `u` is a pseudorandom string with approximately 128 bits of cryptographic entropy. The UUID, `u`, field acts as a salty nonce to hide the values of the edge sub-block in spite of knowledge of the edge sub-blocks SAID, `d`, field and its, the edge's, actual near schema (not its far node schema field).
When the edge sub-block does NOT include a SAID, `d`, field then the node, `n`, field MUST appear as the first field in the edge sub-block, i.e. it follows the SAID, `d`, field which is first. When the edge sub-block does include a SAID, `d`, field then the node, `n`, field MUST appear as the second field in the edge sub-block.
The value of the required node, `n`, field is the SAID of the ACDC to which the edge connects i.e. the node, `n`, field indicated, designates, references, or "points to" another ACDC. The edge is directed _from_ the _near_ node that is the ACDC in which the edge sub-block resides and is directed _to_ the _far_ node that is the ACDC indicated by the node, `n`, field of that edge sub-block. In order for the edge (chain) to be valid, the ACDC validator MUST confirm that the SAID of the provided _far_ ACDC matches the node, `n`, field value given in the edge sub-block in _near_ ACDC and MUST confirm that the provided _far_ ACDC satisfies its own schema.
When present, the schema, `s` field must appear immediately following the node `n`, field in the edge sub-block. When present, the value of the schema, `s` field MUST be the SAID of the top-level schema, `s`, field of the ACDC indicated by the edge's far node, `n`, field. When the schema, `s`, field is present in an edge sub-block, in order for the edge (chain) to be valid, the ACDC validator, after validating that the provided _far_ ACDC indicated by the node, `n`, field satisfies its (the far ACDC's) own schema, MUST also confirm that the value of the edge's schema, `s`, field matches the SAID of the far ACDC's schema as indicated by its top-level schema, `s`, field.
The following example adds both SAID, `d`, and schema, `s`, fields (edge properties) to the edge sub-block.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn9y",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"s": "ELIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdYerzw"
}
}
}
```
When present, the operator, `o` field must appear immediately following all of the SAID, `d`, node, `n`, or schema, `s`, fields in the edge sub-block. The function of the operator field is explained in a later section.
When present, the weight, `w` field must appear immediately following all of the SAID, `d`, node, `n`, schema, `s`, or operator, `o`, fields in the edge sub-block. The function of the weight field is explained in a later section.
Abstractly, an ACDC with one or more edges may be a fragment of a distributed property graph. However, the local label does not enable the direct unique global resolution of a given edge including its properties other than a trivial edge with only one property, its node, `n` field. To enable an edge with additional properties to be globally uniquely resolvable, that edge's block MUST have a SAID, `d`, field. Because a SAID is a cryptographic digest it will universally and uniquely identify an edge with a given set of properties {{Hash}}. This allows ACDCs to be used as secure fragments of a globally distributed property graph (PG). This enables a property graph to serve as a global knowledge graph in a secure manner that crosses trust domains {{PGM}}{{Dots}}{{KG}}. This is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
Given that an individual edge's property block includes a SAID, `d`, field then a compact representation of the edge's property block is provided by replacing it with its SAID. This may be useful for complex edges with many properties. This is called a **_compact edge_**. This is shown as follows,
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn"
}
}
```
Each edge's properties may be blinded by its SAID, `d`, field (i.e. be private) if its properties block includes a UUID, `u` field. As with UUID, `u`, fields used elsewhere in ACDC, if the UUID, `u`, field value has sufficient entropy then the values of the properties of its enclosing block are not discoverable in a computationally feasible manner merely given the schema for the edge block and its SAID, `d` field. This is called a **_private edge_**. When a private edge is provided in compact form then the edge detail is hidden and is partially disclosable. An uncompacted private edge is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
When an edge points to a _private_ ACDC, a _Discloser_ may choose to use a metadata version of that private ACDC when presenting the node, `n`, field of that edge prior to acceptance of the terms of disclosure. The _Disclosee_ can verify the metadata of the private node without the _Discloser_ exposing the actual node contents via the actual node SAID or other attributes.
Private ACDCs (nodes) and private edges may be used in combination to prevent an un-permissioned correlation of the distributed property graph.
When an edge sub-block has only one field that is its node, `n`, field then the edge block may use an alternate simplified compact form where the labeled edge field value is the value of its node, `n`, field. The schema for that particular edge label, in this case, `"boss"`, will indicate that the edge value is a node SAID and not the edge sub-block SAID as would be the case for the normal compact form shown above. This alternate compact form is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
}
```
When the top-level edge section, `e`, field includes more than one edge there is a need or opportunity to define the logic for evaluating those edges with respect to validating the ACDC itself with respect to the validity of the other ACDCs it is connected two. More than one edge creates a provenance tree not simply a provenance chain. The obvious default for a chain is that all links in the chain must be valid in order for the chain itself to be valid, or more precisely for the tail of the chain to be valid. If any links between the head and the tail are broken (invalid) then the tail is not valid. This default logic may not be so useful in all cases when a given ACDC is the tail of multiple parallel chains (i.e. a branching node in a tree of chains). Therefore provided herein is the syntax for exactly specifying the operations to perform on each edge and groups of edges in its edge section.
There are three types of labels in edge sub-blocks:
- Reserved Field Labels (Metadata). `d` for SAID of block `u` for UUID (salty nonce) `n` for node SAID (far ACDC) `s` for schema SAID ( far ACDC) `o` for operator `w` for weight
- Edge Field Map Labels (Single Edges) any value except reserved values above
- Edge-Group Field Map Labels (Aggregates of Edges) any value except reserved values above
There are two types of field-maps or blocks that may appear as values of fields within an edge section, `e`, field either at the top level or nested:
- Edge-Group. An _**edge-group**_ MUST NOT have a node, `n`, metadata field. Its non-metadata field values may include other (sub) edge-group blocks, edge blocks or other properties.
- Edge. An _**edge**_ MUST have a node, `n`, metadata field. Its non-metadata field values MUST NOT include edge-group blocks or other edge blocks but may include other types of properties. From a graph perspective, _edge_ blocks terminate at their node, `n`, field and are not themselves nestable. An _edge_ block is a leaf with respect to any nested _edge-group_ blocks in which the edge appears. It is therefore also a leaf with respect to its enclosing top-level edge section, `e`, field. The ACDC node that an edge points to may have its own edge-groups or edges in that node's own top-level edge section.
The top-level edge section, `e`, field value is always an _edge-group_ block.
With respect to the granularity of a property graph consisting of ACDCs as nodes, nested edge-groups within a given top-level edge field, `e`, field of a given ACDC constitute a sub-graph whose nodes are edge-groups not ACDCs. One of the attractive features of property graphs (PGs) is their support for different edge and node types which enables nested sub-graphs such as is being employed here to support the expression of complex logical or aggregative operations on groups of edges (as subnodes) within the top-level edge section, `e`, field of an ACDC (as supernode).
The meaning of the operator, `o`, metadata field label depends on which type of block it appears in.
- When appearing in an edge-group block then the operator, `o`, field value is an aggregating (m-ary) operator, such as, `OR`, `AND`, `AVG`, `NAND`, `NOR` etc. Its operator applies to all the edges or edge-groups that appear in that edge-group block.
- When appearing in an edge block then the operator, `o`, field value is a unary operator like `NOT`. When more than one unary operator applies to a given edge then the value of the operator, `o`, field is a list of those unary operators.
Weighted directed edges represent degrees of confidence or likelihood. PGs with weighted directed edges are commonly used for machine learning or reasoning under uncertainty. The weight, `w` field provides a reserved label for the primary weight. To elaborate, many aggregating operators used for automated reasoning such as the weighted average, `WAVG`, operator or ranking aggregation operators, depend on each edge having a weight. To simplify the semantics for such operators, the weight, `w`, field is the reserved field label for weighting. Other fields with other labels could provide other types of weights but having a default label, namely `w`, simplifies the default definitions of weighted operators.
The following example adds a weight property to the edge sub-block as indicated by the weight, `w`, field.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
There are two basic m-ary operators defined for ACDCs. These are,
| M-ary Operator | Description | Type | Default |
| --- | --- | --- | --- |
| `AND` | All edges or edge-groups in the edge group MUST be valid for the edge-group to be valid | Combination | Yes |
| `OR` | Only one of the edges or edge-groups in the edge group MUST be valid for the edge-group to be valid | Combination | No |
There are three special unary operators defined for ACDCs. These are,
| Unary Operator | Description | Type | Default |
| --- | --- | --- | --- |
| `I2I` | Issuee-To-Issuer, Issuer AID of this ACDC must Issuee AID of node the edge points to | Constraint | Yes |
| `NI2I` | Not-Issuee-To-Issuer, Issuer AID if any of this ACDC MAY or MAY NOT be Issuee AID of node that the edge points to | Constraint | No |
| `DI2I` | Delegated-Issuee-To-Issuer, Issuer AID of this ACDC MUST be either the Issuee AID or delegated AID of the Issuee AID of the node the edge points to | Constraint | No |
Many ACDC chains use targeted ACDCs (i.e. have Issuees). A chain of Issuer-To-Issuee-To-Issuer targeted ACDCs in which each Issuee becomes the Issuer of the next ACDC in the chain can be used to provide a chain-of-authority. A common use case of a chain-of-authority is a delegation chain for authorization.
The `I2I` unary operator when present means that the Issuer AID of the current ACDC in which the edge resides MUST be the Issuee AID of the node that the edge points to. This also means therefore that the ACDC node pointed to by the edge must also be a targeted ACDC. This is the default value when none of `I2I`, `NI2I`, or `DI2I` is present.
The `NI2I` unary operator when present removes or nullifies any requirement expressed by the dual `I2I` operator described above. In other words, any requirement that the Issuer AID of the current ACDC in which the edge resides MUST be the Issuee AID, if any, of the node the edge points to is relaxed (not applicable). To clarify, when operative (present), the `NI2I` operator means that both an untargeted ACDC or targeted ACDC as the node pointed to by the edge may still be valid even when untargeted or if targeted even when the Issuer of the ACDC in which the edge appears is not the Issuee AID, of that node the edge points to.
The `DI2I` unary operator when present expands the class of allowed Issuer AIDs of the node the edge resides in to include not only the Issuee AID but also any delegated AIDS of the Issuee of the node the edge points to. This also means therefore that the ACDC node pointed to by the edge must also be a targeted ACDC.
If more than one of the `I2I`, `NI2I`, or `DI2I` operators appear in an operator, `o`, field list then the last one appearing in the list is the operative one.
When the operator, `o`, field is missing in an edge-group block. The default value for the operator, `o`, field is `AND`.
When the operator, `o`, field is missing or empty in an edge block, or is present but does not include any of the `I2I`, `NI2I` or `DI2I` operators then,
If the node pointed to by the edge is a targeted ACDC, i.e. has an Issuee, by default it is assumed that the `I2I` operator is appended to the operator, `o`, field's effective list value.
If the node pointed to by the edge block is a non-targeted ACDC i.e., does not have an Issuee, by default, it is assumed that the `NI2I` operator is appended to the operator, `o`, field's effective list value.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "NOT",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "OR",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"o": "NI2I",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"o": ["NI2I", "NOT"],
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
},
"food":
{
"o": "OR",
"power": "med",
"plum":
{
"n": "EQIYPvAu6DZAIl3AORH3dCdoFOLe71iheqcywJcnjtJt",
"o": "NI2I"
},
"pear":
{
"n": "EJtQIYPvAu6DZAIl3AORH3dCdoFOLe71iheqcywJcnjt",
"o": "NI2I"
}
}
}
}
```
When an ECR vLEI is issued by the QVI it is not chained, Issuer-to-Issuee, via the LE credential. A more accurate way of expressing the chaining would be to use the `AND` operator to include both the LE and QVI credentials as edges in the ECR and also to apply the unary `NI2I` to the LE credential instead of only chaining the ECR to the LE and not chaining to ECR to the QVI at all.
In the following example: The top-level edge-block uses the default of `AND` and the `qvi` edge uses the default of `I2I` because it points to a targeted ACDC. The `le` edge, on the other hand, points to a targeted ACDC. It uses the unary operator, `NI2I` in its operator, `o`, field so that it will be accepted it even though its targeted Issuee is not the Issuer of the current credential.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"qvi":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
},
"le":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "NI2I"
}
}
}
```
This provides a simple but highly expressive syntax for applying (m-ary) aggregating operators to nestable groups of edges and unary operators to edges individually within those groups. This is a general approach with high expressive power. It satisfies many business logic requirements similar to that of SGL.
Certainly, an even more expressive syntax could be developed. The proposed syntax, however, is relatively simple and compact. It has intelligent defaults and is sufficiently general in scope to satisfy all the currently contemplated use cases.
The intelligent defaults for the operator, `o`, field, including the default application of the `I2I` or `NI2I` unary operator, means that in most current use cases, the operator, `o`, field, does not even need to be present.
In general, the discovery of the details of an ACDC referenced as a node, `n` field value, in an edge sub-block begins with the node SAID or the SAID of the associated edge sub-block. Because a SAID is a cryptographic digest with high collision resistance it provides a universally unique identifier to the referenced ACDC as a node. The Discovery of a service endpoint URL that provides database access to a copy of the ACDC may be bootstrapped via an OOBI (Out-Of-Band-Introduction) that links the service endpoint URL to the SAID of the ACDC {{OOBI\_ID}}. Alternatively, the _Issuer_ may provide as an attachment at the time of issuance a copy of the referenced ACDC. In either case, after a successful exchange, the _Issuee_ or recipient of any ACDC will have either a copy or a means of obtaining a copy of any referenced ACDCs as nodes in the edge sections of all ACDCs so chained. That Issuee or recipient will then have everything it needs to make a successful disclosure to some other _Disclosee_. This is the essence of _percolated_ discovery.
In the compact ACDC examples above, the rule section has been compacted into merely the SAID of that section. Suppose that the un-compacted value of the rule section denoted by the top-level rule, `r`, field is as follows,
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
The purpose of the rule section is to provide a Ricardian Contract {{RC}}. The important features of a Ricardian contract are that it be both human and machine-readable and referenceable by a cryptographic digest. A JSON encoded document or block such as the rule section block is a practical example of both a human and machine-readable document. The rule section's top-level SAID, `d`, field provides the digest. This provision supports the bow-tie model of Ricardian Contracts {{RC}}. Ricardian legal contracts may be hierarchically structured into sections and subsections with named or numbered clauses in each section. The labels on the clauses may follow such a hierarchical structure using nested maps or blocks. These provisions enable the rule section to satisfy the features of a Ricardian contract.
To elaborate, the rule section's top-level SAID, `d`, field is the SAID of that block and is the same SAID used as the compacted value of the rule section, `r`, field that appears at the top level of the ACDC. Each clause in the rule section gets its own field. Each clause also has its own local label.
The legal, `l`, field in each block provides the associated legal language.
Note there are no type fields in the rule section. The type of a contract and the type of each clause is provided by the schema vis-a-vis the label of that clause. This follows the ACDC design principle that may be succinctly expressed as "type-is-schema".
Each rule section clause may also have its own clause SAID, `d`, field. Clause SAIDs enable reference to individual clauses, not merely the whole contract as given by the rule section's top-level SAID, `d`, field.
An example rule section with clause SAIDs is provided below.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
The use of clause SAIDS enables a compact form of a set of clauses where each clause value is the SAID of the corresponding clause. For example,
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"liabilityDisclaimer": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw"
}
}
```
The disclosure of some clauses may be pre-conditioned on acceptance of chain-link confidentiality. In this case, some clauses may benefit from partial disclosure. Thus clauses may be blinded by their SAID, `d`, field when the clause block includes a sufficiently high entropy UUID, `u`, field. The use of a clause UUID enables the compact form of a clause to NOT be discoverable merely from the schema for the clause and its SAID via rainbow table attack {{RB}}{{DRB}}. Therefore such a clause may be partially disclosable. These are called **_private clauses_**. A private clause example is shown below.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"u": "0AHcgNghkDaG7OY1wjaDAE0q",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
An alternate simplified compact form uses the value of the legal, `l`, field as the value of the clause field label. The schema for a specific clause label will indicate that the field value, for a given clause label is the legal language itself and not the clause block's SAID, `d`, field as is the normal compact form shown above. This alternate simple compact form is shown below. In this form individual clauses are not compactifiable and are fully self-contained.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE",
"liabilityDisclaimer": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
```
In compact form, the discovery of either the rule section as a whole or a given clause begins with the provided SAID. Because the SAID, `d`, field of any block is a cryptographic digest with high collision resistance it provides a universally unique identifier to the referenced block details (whole rule section or individual clause). The discovery of a service endpoint URL that provides database access to a copy of the rule section or to any of its clauses may be bootstrapped via an OOBI (Out-Of-Band-Introduction) that links the service endpoint URL to the SAID of the respective block {{OOBI\_ID}}. Alternatively, the issuer may provide as an attachment at issuance a copy of the referenced contract associated with the whole rule section or any clause. In either case, after a successful issuance exchange, the Issuee or holder of any ACDC will have either a copy or a means of obtaining a copy of any referenced contracts in whole or in part of all ACDCs so issued. That Issuee or recipient will then have everything it needs to subsequently make a successful presentation or disclosure to a Disclosee. This is the essence of percolated discovery.
The ACDC chaining enables disclosure-specific issuance of bespoke ACDCs. A given Discloser of an ACDC issued by some Issuer may want to augment the disclosure with additional contractual obligations or additional information sourced by the Discloser where those augmentations are specific to a given context such as a specific Disclosee. Instead of complicating the presentation exchange to accommodate such disclosure-specific augmentations, a given Disloser issues its own bespoke ACDC that includes the other ACDC of the other Issuer by reference via an edge in the bespoke ACDC. This means that the normal validation logic and tooling for a chained ACDC can be applied without complicating the presentation exchange logic. Furthermore, attributes in other ACDCs pointed to by edges in the bespoke ACDC may be addressed by attributes in the bespoke ACDC using JSON Pointer or CESR-Proof SAD Path references that are relative to the node SAID in the edge {{RFC6901}}{{Proof\_ID}}.
For example, this approach enables the bespoke ACDC to identify (name) the Disclosee directly as the Issuee of the bespoke ACDC. This enables contractual legal language in the rule section of the bespoke ACDC that reference the Issuee of that ACDC as a named party. Signing the agreement to the offer of that bespoke ACDC consummates a contract between named Issuer and named Issuee. This approach means that custom or bespoke presentations do not need additional complexity or extensions. Extensibility comes from reusing the tooling for issuing ACDCs to issue a bespoke or disclosure-specific ACDC. When the only purpose of the bespoke ACDC is to augment the contractual obligations associated with the disclosure then the attribute section, `a`, field value of the bespoke ACD may be empty or it may include properties whose only purpose is to support the bespoke contractual language.
Similarly, this approach effectively enables a type of _rich presentation_ or combined disclosure where multiple ACDCs may be referenced by edges in the bespoke ACDC that each contributes some attribute(s) to the effective set of attributes referenced in the bespoke ACDC. The bespoke ACDC enables the equivalent of a _rich presentation_ without requiring any new tooling {{Abuse}}.
Consider the following disclosure-specific ACDC. The Issuer is the Discloser, the Issuee is the Disclosee. The rule section includes a context-specific (anti) assimilation clause that limits the use of the information to a single one-time usage purpose, that is in this case, admittance to a restaurant. The ACDC includes an edge that references some other ACDC that may for example be a coupon or gift card. The attribute section includes the date and place of admittance.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "EGGeIZ8a8FWS7a646jrVPTzlSkUPqs4reAXRZOkogZ2A",
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"date": "2022-08-22T17:50:09.988921+00:00",
"place": "GoodFood Restaurant, 953 East Sheridan Ave, Cody WY 82414 USA"
},
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"other":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
},
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"Assimilation":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuee hereby explicitly and unambiguously agrees to NOT assimilate, aggregate, correlate, or otherwise use in combination with other information available to the Issuee, the information, in whole or in part, referenced by this container or any containers recursively referenced by the edge section, for any purpose other than that expressly permitted by the Purpose clause."
},
"Purpose":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "One-time admittance of Issuer by Issuee to eat at place on date as specified in attribute section."
}
}
}
```
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
},
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"s": "EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71",
"w": "high"
}
},
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
```
{
"$id": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Public ACDC",
"description": "Example JSON Schema Public ACDC.",
"credentialType": "PublicACDCExample",
"type": "object",
"required":
[
"v",
"d",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry ID",
"type": "string"
},
"s":
{
"description": "schema section",
"oneOf":
[
{
"description": "schema section SAID",
"type": "string"
},
{
"description": "schema detail",
"type": "object"
}
]
},
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute section SAID",
"type": "string"
},
{
"description": "attribute detail",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute section SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
},
"e":
{
"description": "edge section",
"oneOf":
[
{
"description": "edge section SAID",
"type": "string"
},
{
"description": "edge detail",
"type": "object",
"required":
[
"d",
"boss"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"boss":
{
"description": "boss edge",
"type": "object",
"required":
[
"d",
"n",
"s",
"w"
],
"properties":
{
"d":
{
"description": "edge SAID",
"type": "string"
},
"n":
{
"description": "far node SAID",
"type": "string"
},
"s":
{
"description": "far node schema SAID",
"type": "string",
"const": "EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71"
},
"w":
{
"description": "edge weight",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
},
"r":
{
"description": "rule section",
"oneOf":
[
{
"description": "rule section SAID",
"type": "string"
},
{
"description": "rule detail",
"type": "object",
"required":
[
"d",
"warrantyDisclaimer",
"liabilityDisclaimer"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"warrantyDisclaimer":
{
"description": "warranty disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
},
"liabilityDisclaimer":
{
"description": "liability disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
}
},
"additionalProperties": false
}
```
As explained previously, the primary difference between _partial disclosure_ and _selective disclosure_ is determined by the correlatability with respect to its encompassing block after _full disclosure_ of the detailed field value. A _partially disclosable_ field becomes correlatable to its encompassing block after its _full disclosure_. Whereas a _selectively disclosable_ field may be excluded from the _full disclosure_ of any other selectively disclosable fields in its encompassing block. After selective disclosure, the selectively disclosed fields are not correlatable to the so-far undisclosed but selectively disclosable fields in the same encompassing block. In this sense, _full disclosure_ means detailed disclosure of the selectively disclosed attributes not detailed disclosure of all selectively disclosable attributes.
Recall that _partial_ disclosure is an essential mechanism needed to support chain-link confidentiality {{CLC}}. The chain-link confidentiality exchange _offer_ requires _partial disclosure_, and _full disclosure_ only happens after _acceptance_ of the _offer_. _Selective_ disclosure, on the other hand, is an essential mechanism needed to unbundle in a correlation minimizing way a single commitment by an Issuer to a bundle of fields (i.e. a nested block or array of fields). This allows separating a "stew" of "ingredients" (attributes) into its constituent "ingredients" (attributes) without correlating the constituents via the stew.
ACDCs, as a standard, benefit from a minimally sufficient approach to selective disclosure that is simple enough to be universally implementable and adoptable. This does not preclude support for other more sophisticated but optional approaches. But the minimally sufficient approach should be universal so that at least one selective disclosure mechanism be made available in all ACDC implementations. To clarify, not all instances of an ACDC must employ the minimal selective disclosure mechanisms as described herein but all ACDC implementations must support any instance of an ACDC that employs the minimal selective disclosure mechanisms as described above.
The ACDC chaining mechanism reduces the need for selective disclosure in some applications. Many non-ACDC verifiable credentials provide bundled precisely because there is no other way to associate the attributes in the bundle. These bundled credentials could be refactored into a graph of ACDCs. Each of which is separately disclosable and verifiable thereby obviating the need for selective disclosure.
Nonetheless, some applications require bundled attributes and therefore may benefit from the independent selective disclosure of bundled attributes. This is provided by **_selectively disclosable attribute_** ACDCs.
The use of a revocation registry is an example of a type of bundling, not of attributes in a credential, but uses of a credential in different contexts. Unbundling the usage contexts may be beneficial. This is provided by **_bulk-issued_** ACDCs.
Finally, in the case where the correlation of activity of an Issuee across contexts even when the ACDC used in those contexts is not correlatable may be addressed of a variant of bulk-issued ACDCs that have **_unique issuee AIDs_** with an independent TEL registry per issuee instance. This provides non-repudiable (recourse supporting) disclosure while protecting from the malicious correlation between second parties and other second and/or third-parties as to who (Issuee) is involved in a presentation.
In any case, the set of selective disclosure mechanisms we call tiered selective disclosure which allows a user or implementer to better trade-off protection vs. complexity and performance. A tiered selective disclosure me
The basic selective disclosure mechanism shared by all is comprised of a single aggregated blinded commitment to a list of blinded commitments to undisclosed values. Membership of any blinded commitment to a value in the list of aggregated blinded commitments may be proven without leaking (disclosing) the unblinded value belonging to any other blinded commitment in the list. This enables provable selective disclosure of the unblinded values. When a non-repudiable digital signature is created on the aggregated blinded commitment then any disclosure of a given value belonging to a given blinded commitment in the list is also non-repudiable. This approach does not require any more complex cryptography than digests and digital signatures. This satisfies the design ethos of minimally sufficient means. The primary drawback of this approach is verbosity. It trades ease and simplicity and _adoptability_ of implementation for size. Its verbosity may be mitigated by replacing the list of blinded commitments with a Merkle tree of those commitments where the Merkle tree root becomes the aggregated blinded commitment.
Given sufficient cryptographic entropy of the blinding factors, collision resistance of the digests, and unforgeability of the digital signatures, either inclusion proof format (list or Merkle tree digest) prevents a potential disclosee or adversary from discovering in a computationally feasible way the values of any undisclosed blinded value details from the combination of the schema of those value details and either the aggregated blinded commitment and/or the list of aggregated blinded commitments {{Hash}}{{HCR}}{{QCHC}}{{Mrkl}}{{TwoPI}}{{MTSec}}. A potential disclosee or adversary would also need both the blinding factor and the actual value details.
Selective disclosure in combination with partial disclosure for chain-link confidentiality provides comprehensive correlation minimization because a discloser may use a non-disclosing metadata ACDC prior to acceptance by the disclosee of the terms of the chain-link confidentiality expressed in the rule section {{CLC}}. Thus only malicious disclosees who violate chain-link confidentiality may correlate between independent disclosures of the value details of distinct members in the list of aggregated blinded commitments. Nonetheless, they are not able to discover any as-of-yet undisclosed (unblinded) value details.
In a **_selectively disclosable attribute_** ACDC, the set of attributes is provided as an array of blinded blocks. Each attribute in the set has its own dedicated blinded block. Each block has its own SAID, `d`, field and UUID, `u`, field in addition to its attribute field or fields. When an attribute block has more than one attribute field then the set of fields in that block are not independently selectively disclosable but MUST be disclosed together as a set. Notable is that the field labels of the selectively disclosable attributes are also blinded because they only appear within the blinded block. This prevents un-permissioned correlation via contextualized variants of a field label that appear in a selectively disclosable block. For example, localized or internationalized variants where each variant's field label(s) each use a different language or some other context correlatable information in the field labels themselves.
A selectively-disclosable attribute section appears at the top level using the field label `A`. This is distinct from the field label `a` for a non-selectively-disclosable attribute section. This makes clear (unambiguous) the semantics of the attribute section's associated schema. This also clearly reflects the fact that the value of a compact variant of selectively-disclosable attribute section is an "aggregate" not a SAID. As described previously, the top-level selectively-disclosable attribute aggregate section, `A`, field value is an aggregate of cryptographic commitments used to make a commitment to a set (bundle) of selectively-disclosable attributes. The derivation of its value depends on the type of selective disclosure mechanism employed. For example, the aggregate value could be the cryptographic digest of the concatenation of an ordered set of cryptographic digests, a Merkle tree root digest of an ordered set of cryptographic digests, or a cryptographic accumulator.
The _Issuee_ attribute block is absent from an uncompacted untargeted selectively disclosable ACDC as follows:
```
{
"A":
[
{
"d": "ELIr9Bf7V_NHwY1lkgveY4-Frn9y2PY9XgOcLxUderzw",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"score": 96
},
{
"d": "E9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-",
"u": "0AghkDaG7OY1wjaDAE0qHcgN",
"name": "Jane Doe"
}
]
}
```
The _Issuee_ attribute block is present in an uncompacted untargeted selectively disclosable ACDC as follows:
```
{
"A":
[
{
"d": "ErzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-9XgOcLxUde",
"u": "0AqHcgNghkDaG7OY1wjaDAE0",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA"
},
{
"d": "ELIr9Bf7V_NHwY1lkgveY4-Frn9y2PY9XgOcLxUderzw",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"score": 96
},
{
"d": "E9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-",
"u": "0AghkDaG7OY1wjaDAE0qHcgN",
"name": "Jane Doe"
}
]
}
```
Given that each attribute block's UUID, `u`, field has sufficient cryptographic entropy, then each attribute block's SAID, `d`, field provides a secure cryptographic digest of its contents that effectively blinds the attribute value from discovery given only its Schema and SAID. To clarify, the adversary despite being given both the schema of the attribute block and its SAID, `d`, field, is not able to discover the remaining contents of the attribute block in a computationally feasible manner such as a rainbow table attack {{RB}}{{DRB}}. Therefore the UUID, `u`, field of each attribute block enables the associated SAID, `d`, field to securely blind the block's contents notwithstanding knowledge of the block's schema and that SAID, `d`, field. Moreover, a cryptographic commitment to that SAID, `d`, field does not provide a fixed point of correlation to the associated attribute (SAD) field values themselves unless and until there has been specific disclosure of those field values themselves.
Given a total of _N_ elements in the attributes array, let _ai_ represent the SAID, `d`, field of the attribute at zero-based index _i_. More precisely the set of attributes is expressed as the ordered set,
_{ai for all i in {0, ..., N-1}}_.
The ordered set of _ai_ may be also expressed as a list, that is,
_\[a0, a1, ...., aN-1\]_.
Because the selectively-disclosable attributes are provided by an array (list), the uncompacted variant in the schema uses an array of items and the `anyOf` composition operator to allow one or more of the items to be disclosed without requiring all to be disclosed. Thus both the `oneOf` and `anyOf` composition operators are used. The `oneOf` is used to provide compact partial disclosure of the aggregate, _A_, as the value of the top-level selectively-disclosable attribute section, `A`, field in its compact variant and the nested `anyOf` operator is used to enable selective disclosure in the uncompacted selectively-disclosable variant.
```
{
"A":
{
"description": "selectively disclosable attribute aggregate section",
"oneOf":
[
{
"description": "attribute aggregate",
"type": "string"
},
{
"description": "selectively disclosable attribute details",
"type": "array",
"uniqueItems": true,
"items":
{
"anyOf":
[
{
"description": "issuer attribute",
"type": "object",
"required":
[
"d",
"u",
"i"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"i":
{
"description": "issuer SAID",
"type": "string"
}
},
"additionalProperties": false
},
{
"description": "score attribute",
"type": "object",
"required":
[
"d",
"u",
"score"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"score":
{
"description": "score value",
"type": "integer"
}
},
"additionalProperties": false
},
{
"description": "name attribute",
"type": "object",
"required":
[
"d",
"u",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"name":
{
"description": "name value",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
],
"additionalProperties": false
}
}
```
All the _ai_ in the list are aggregated into a single aggregate digest denoted _A_ by computing the digest of their ordered concatenation. This is expressed as follows:
_A = H(C(ai for all i in {0, ..., N-1}))_ where _H_ is the digest (hash) operator and _C_ is the concatentation operator.
To be explicit, using the targeted example above, let _a0_ denote the SAID of the _Issuee_ attribute, _a1_ denote the SAID of the _score_ attribute, and _a2_ denote the SAID of the _name_ attribute then the aggregated digest _A_ is computed as follows:
_A = H(C(a0, a1, a2))_.
Equivalently using _+_ as the infix concatenation operator, we have,
_A = H(a0 + a1 + a2)_
Given sufficient collision resistance of the digest operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements {{BDC}}{{BDay}}{{QCHC}}{{HCR}}{{Hash}}.
In compact form, the value of the selectively-disclosable top-level attribute section, `A`, field is set to the aggregated value _A_. This aggregate _A_ makes a blinded cryptographic commitment to the all the ordered elements in the list,
_\[a0, a1, ...., aN-1\]_.
Moreover because each _ai_ element also makes a blinded commitment to its block's (SAD) attribute value(s), disclosure of any given _ai_ element does not expose or disclose any discoverable information detail about either its own or another block's attribute value(s). Therefore one may safely disclose the full list of _ai_ elements without exposing the blinded block attribute values.
Proof of inclusion in the list consists of checking the list for a matching value. A computationally efficient way to do this is to create a hash table or B-tree of the list and then check for inclusion via lookup in the hash table or B-tree.
To protect against later forgery given a later compromise of the signing keys of the Issuer, the issuer MUST anchor an issuance proof digest seal to the ACDC in its KEL. This seal binds the signing key state to the issuance. There are two cases. In the first case, an issuance/revocation registry is used. In the second case, an issuance/revocation registry is not used.
When the ACDC is registered using an issuance/revocation TEL (Transaction Event Log) then the issuance proof seal digest is the SAID of the issuance (inception) event in the ACDC's TEL entry. The issuance event in the TEL includes the SAID of the ACDC. This binds the ACDC to the issuance proof seal in the Issuer's KEL through the TEL entry.
When the ACDC is not registered using an issuance/revocation TEL then the issuance proof seal digest is the SAID of the ACDC itself.
In either case, this issuance proof seal makes a verifiable binding between the issuance of the ACDC and the key state of the Issuer at the time of issuance. Because aggregated value _A_ provided as the attribute section, `A`, field, value is bound to the SAID of the ACDC which is also bound to the key state via the issuance proof seal, the attribute details of each attribute block are also bound to the key state.
The requirement of an anchored issuance proof seal means that the forger Must first successfully publish in the KEL of the issuer an inclusion proof digest seal bound to a forged ACDC. This makes any forgery attempt detectable. To elaborate, the only way to successfully publish such a seal is in a subsequent interaction event in a KEL that has not yet changed its key state via a rotation event. Whereas any KEL that has changed its key state via a rotation must be forked before the rotation. This makes the forgery attempt either both detectable and recoverable via rotation in any KEL that has not yet changed its key state or detectable as duplicity in any KEL that has changed its key state. In any event, the issuance proof seal ensures detectability of any later attempt at forgery using compromised keys.
Given that aggregate value _A_ appears as the compact value of the top-level attribute section, `A`, field, the selective disclosure of the attribute at index _j_ may be proven to the disclosee with four items of information. These are:
- The actual detailed disclosed attribute block itself (at index _j_) with all its fields.
- The list of all attribute block digests, _\[a0, a1, ...., aN-1\]_ that includes _aj_.
- The ACDC in compact form with selectively-disclosable attribute section, `A`, field value set to aggregate _A_.
- The signature(s), _s_, of the Issuee on the ACDC's top-level SAID, `d`, field.
The actual detailed disclosed attribute block is only disclosed after the disclosee has agreed to the terms of the rules section. Therefore, in the event the potential disclosee declines to accept the terms of disclosure, then a presentation of the compact version of the ACDC and/or the list of attribute digests, _\[a0, a1, ...., aN-1\]_. does not provide any point of correlation to any of the attribute values themselves. The attributes of block _j_ are hidden by _aj_ and the list of attribute digests _\[a0, a1, ...., aN-1\]_ is hidden by the aggregate _A_. The partial disclosure needed to enable chain-link confidentiality does not leak any of the selectively disclosable details.
The disclosee may then verify the disclosure by:
- computing _aj_ on the selectively disclosed attribute block details.
- confirming that the computed _aj_ appears in the provided list _\[a0, a1, ...., aN-1\]_.
- computing _A_ from the provided list _\[a0, a1, ...., aN-1\]_.
- confirming that the computed _A_ matches the value, _A_, of the selectively-disclosable attribute section, `A`, field value in the provided ACDC.
- computing the top-level SAID, `d`, field of the provided ACDC.
- confirming the presence of the issuance seal digest in the Issuer's KEL
- confirming that the issuance seal digest in the Issuer's KEL is bound to the ACDC top-level SAID, `d`, field either directly or indirectly through a TEL registry entry.
- verifying the provided signature(s) of the Issuee on the provided top-level SAID, `d` field value.
The last 3 steps that culminate with verifying the signature(s) require determining the key state of the Issuer at the time of issuance, this may require additional verification steps as per the KERI, PTEL, and CESR-Proof protocols.
A private selectively disclosable ACDC provides significant correlation minimization because a presenter may use a metadata ACDC prior to acceptance by the disclosee of the terms of the chain-link confidentiality expressed in the rule section {{CLC}}. Thus only malicious disclosees who violate chain-link confidentiality may correlate between presentations of a given private selectively disclosable ACDC. Nonetheless, they are not able to discover any undisclosed attributes.
The inclusion proof via aggregated list may be somewhat verbose when there are a large number of attribute blocks in the selectively disclosable attribute section. A more efficient approach is to create a Merkle tree of the attribute block digests and let the aggregate, _A_, be the Merkle tree root digest {{Mrkl}}. Specifically, set the value of the top-level selectively-disclosable attribute section, `A`, field to the aggregate, _A_ whose value is the Merkle tree root digest {{Mrkl}}.
The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes {{TwoPI}}{{MTSec}}. The discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, _aj_ contributed to the Merkle tree root digest, _A_. For ACDCs with a small number of attributes the added complexity of the Merkle tree approach may not be worth the savings in verbosity.
The amount of data transferred between the Issuer and Issuee (or recipient in the case of an untargeted ACDC) at issuance of a selectively disclosable attribute ACDC may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUDI, `u`, fields from a shared secret salt {{Salt}}.
There are several ways that the Issuer may securely share that secret salt. Given that an Ed25519 key pair(s) controls each of the Issuer and Issuee AIDs, (or recipient AID in the case of an untargeted ACDC) a corresponding X15519 asymmetric encryption key pair(s) may be derived from each controlling Ed25519 key pair(s) {{EdSC}}{{PSEd}}{{TMEd}}{{SKEM}}. An X25519 public key may be securely derived from an Ed25519 public key {{KeyEx}}{{SKEM}}. Likewise, an X25519 private key may be securely derived from an Ed25519 private key {{KeyEx}}{{SKEM}}.
In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key {{KeyEx}}{{DHKE}}. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived.
In a non-interactive approach, the Issuer derives an X25519 asymmetric public encryption key from the Issuee's (recipient's) public Ed25519 public key. The Issuer then encrypts the secret salt with that public asymmetric encryption key and signs the encryption with the Issuer's private Ed25519 signing key. This is transmitted to the Issuee, who verifies the signature and decrypts the secret salt using the private X25519 decryption key derived from the Issuee's private Ed25519 key. This non-interactive approach is more scalable for AIDs that are controlled with a multi-sig group of signing keys. The Issuer can broadcast to all members of the Issuee's (or recipient's) multi-sig signing group individually asymmetrically encrypted and signed copies of the secret salt.
In addition to the secret salt, the Issuer provides to the Issuee (recipient) a template of the ACDC but with empty UUID, `u`, and SAID, `d`, fields in each block with such fields. Each UUID, `u`, field value is then derived from the shared salt with a path prefix that indexes a specific block. Given the UUID, `u`, field value, the SAID, `d`, field value may then be derived. Likewise, both compact and uncompacted versions of the ACDC may then be generated. The derivation path for the top-level UUID, `u`, field (for private ACDCS), is the string "0" and derivation path the the the zeroth indexed attribute in the attributes array is the string "0/0". Likewise, the next attribute's derivation path is the string "0/1" and so forth.
In addition to the shared salt and ACDC template, the Issuer also provides its signature(s) on its own generated compact version ACDC. The Issuer may also provide references to the anchoring issuance proof seals. Everything else an Issuee (recipient) needs to make a verifiable presentation/disclosure can be computed at the time of presentation/disclosure by the Issuee.
The purpose of bulk issuance is to enable the Issuee to more efficiently use ACDCs with unique SAIDs to isolate and minimize correlation across different usage contexts. Each member of a set of bulk-issued ACDCs is essentially the same ACDC but with a unique SAID. This enables public commitments to each of the unqiue ACDC SAIDs without correlating between them. A private ACDC may be effectively issued in bulk as a set. In its basic form, the only difference between each ACDC is the top-level SAID, _d_, and UUID, _u_ field values. To elaborate, bulk issuance enables the use of un-correlatable copies while minimizing the associated data transfer and storage requirements involved in the issuance. Essentially each copy (member) of a bulk issued ACDC set shares a template that both the Issuer and Issuee use to generate on-the-fly a given ACDC in that set without requiring that the Issuer and Issuee exchange and store a unique copy of each member of the set independently. This minimizes the data transfer and storage requirements for both the Issuer and the Issuee. The Issuer is only required to provide a single signature for the bulk issued aggregate value _B_ defined below. The same signature may be used to provide proof of issuance of any member of the bulk issued set. The signature on _B_ and _B_ itself are points of correlation but these need only be disclosed after contractually protected disclosure is in place, i.e no permissioned correlation. Thus correlation requires a colluding second party who enagages in unpermissioned correlation.
An ACDC provenance chain is connected via references to the SAIDs given by the top-level SAID, `d`, fields of the ACDCs in that chain. A given ACDC thereby makes commitments to other ACDCs. Expressed another way, an ACDC may be a node in a directed graph of ACDCs. Each directed edge in that graph emanating from one ACDC includes a reference to the SAID of some other connected ACDC. These edges provide points of correlation to an ACDC via their SAID reference. Private bulk issued ACDCs enable the Issuee to better control the correlatability of presentations using different presentation strategies.
For example, the Issuee could use one copy of a bulk-issued private ACDC per presentation even to the same verifier. This strategy would consume the most copies. It is essentially a one-time-use ACDC strategy. Alternatively, the Issuee could use the same copy for all presentations to the same verifier and thereby only permit the verifier to correlate between presentations it received directly but not between other verifiers. This limits the consumption to one copy per verifier. In yet another alternative, the Issuee could use one copy for all presentations in a given context with a group of verifiers, thereby only permitting correlation among that group.
In this context, we are talking about permissioned correlation. Any verifier that has received a complete presentation of a private ACDC has access to all the fields disclosed by the presentation but the terms of the chain-link confidentiality agreement may forbid sharing those field values outside a given context. Thus an Issuee may use a combination of bulk issued ACDCs with chain-link confidentiality to control permissioned correlation of the contents of an ACDC while allowing the SAID of the ACDC to be more public. The SAID of a private ACDC does not expose the ACDC contents to an un-permissioned third party. Unique SAIDs belonging to bulk issued ACDCs prevent third parties from making a provable correlation between ACDCs via their SAIDs in spite of those SAIDs being public. This does not stop malicious verifiers (as second parties) from colluding and correlating against the disclosed fields but it does limit provable correlation to the information disclosed to a given group of malicious colluding verifiers. To restate unique SAIDs per copy of a set of private bulk issued ACDC prevent un-permissioned third parties from making provable correlations, in spite of those SAIDs being public, unless they collude with malicious verifiers (second parties).
In some applications, chain-link-confidentiality is insufficient to deter un-permissioned correlation. Some verifiers may be malicious with sufficient malicious incentives to overcome whatever counter incentives the terms of the contractual chain-link confidentiality may impose. In these cases, more aggressive technological anti-correlation mechanisms such as bulk issued ACDCs may be useful. To elaborate, in spite of the fact that chain-link confidentiality terms of use may forbid such malicious correlation, making such correlation more difficult technically may provide better protection than chain-link confidentiality alone {{CLC}}.
It is important to note that any group of colluding malicious verifiers may always make a statistical correlation between presentations despite technical barriers to cryptographically provable correlation. We call this contextual linkability. In general, there is no cryptographic mechanism that precludes statistical correlation among a set of colluding verifiers because they may make cryptographically unverifiable or unprovable assertions about information presented to them that may be proven as likely true using merely statistical correlation techniques. Linkability due the context of the disclosure itself may defeat any unlinkability guarantees of a cryptographic technique. Thus without contractually protected disclosure, contextual linkability in spite of cryptographic unlinkability may make the complexity of using advanced cryptographic mechanisms to provide unlinkability an exercise in diminishing returns.
The amount of data transferred between the Issuer and Issuee (or recipient of an untargeted ACDC) at issuance of a set of bulk issued ACDCs may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUID, `u`, fields from a shared secret salt {{Salt}}.
As described above, there are several ways that the Issuer may securely share a secret salt. Given that the Issuer and Issuee (or recipient when untargeted) AIDs are each controlled by an Ed25519 key pair(s), a corresponding X15519 asymmetric encryption key pair(s) may be derived from the controlling Ed25519 key pair(s) {{EdSC}}{{PSEd}}{{TMEd}}. An X25519 public key may be securely derived from an Ed25519 public key {{KeyEx}}{{SKEM}}. Likewise, an X25519 private key may be securely derived from an Ed25519 private key {{KeyEx}}{{SKEM}}.
In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key {{KeyEx}}{{DHKE}}. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived.
In a non-interactive approach, the Issuer derives an X25519 asymmetric public encryption key from the Issuee's (or recipient's) public Ed25519 public key. The Issuer then encrypts the secret salt with that public asymmetric encryption key and signs the encryption with the Issuer's private Ed25519 signing key. This is transmitted to the Issuee, who verifies the signature and decrypts the secret salt using the private X25519 decryption key derived from the Issuee's private Ed25519 key. This non-interactive approach is more scalable for AIDs that are controlled with a multi-sig group of signing keys. The Issuer can broadcast to all members of the Issuee's (or recipient's) multi-sig signing group individually asymmetrically encrypted and signed copies of the secret salt.
In addition to the secret salt, the Issuer also provides a template of the private ACDC but with empty UUID, `u`, and SAID, `d`, fields at the top-level of each nested block with such fields. Each UUID, `u`, field value is then derived from the shared salt with a deterministic path prefix that indexes both its membership in the bulk issued set and its location in the ACDC. Given the UUID, `u`, field value, the associated SAID, `d`, field value may then be derived. Likewise, both full and compact versions of the ACDC may then be generated. This generation is analogous to that described in the section for selective disclosure ACDCs but extended to a set of private ACDCs.
The initial element in each deterministic derivation path is the string value of the bulk-issued member's copy index _k_, such as "0", "1", "2" etc. Specifically, if _k_ denotes the index of an ordered set of bulk issued private ACDCs of size _M_, the derivation path starts with the string _"k"_ where _k_ is replaced with the decimal or hexadecimal textual representation of the numeric index _k_. Furthermore, a bulk-issued private ACDC with a private attribute section uses _"k"_ to derive its top-level UUID and _"k/0"_ to derive its attribute section UUID. This hierarchical path is extended to any nested private attribute blocks. This approach is further extended to enable bulk issued selective disclosure ACDCs by using a similar hierarchical derivation path for the UUID field value in each of the selectively disclosable blocks in the array of attributes. For example, the path _"k/j"_ is used to generate the UUID of attribute index _j_ at bulk-issued ACDC index _k_.
In addition to the shared salt and ACDC template, the Issuer also provides a list of signatures of SAIDs, one for each SAID of each copy of the associated compact bulk-issued ACDC. The Issuee (or recipient) can generate on-demand each compact or uncompacted ACDC from the template, the salt, and its index _k_. The Issuee does not need to store a copy of each bulk issued ACDC, merely the template, the salt, and the list of signatures.
The Issuer MUST also anchor in its KEL an issuance proof digest seal of the set of bulk issued ACDCs. The issuance proof digest seal makes a cryptographic commitment to the set of top-level SAIDS belonging to the bulk issued ACDCs. This protects against later forgery of ACDCs in the event the Issuer's signing keys become compromised. A later attempt at forgery requires a new event or new version of an event that includes a new anchoring issuance proof digest seal that makes a cryptographic commitment to the set of newly forged ACDC SAIDS. This new anchoring event of the forgery is therefore detectable.
Similarly, to the process of generating a selective disclosure attribute ACDC, the issuance proof digest is an aggregate that is aggregated from all members in the bulk-issued set of ACDCs. The complication of this approach is that it must be done in such a way as to not enable provable correlation by a third party of the actual SAIDS of the bulk-issued set of ACDCs. Therefore the actual SAIDs must not be aggregated but blinded commitments to those SAIDs instead. With blinded commitments, knowledge of any or all members of such a set does not disclose the membership of any SAID unless and until it is unblinded. Recall that the purpose of bulk issuance is to allow the SAID of an ACDC in a bulk issued set to be used publicly without correlating it in an un-permissioned provable way to the SAIDs of the other members.
The basic approach is to compute the aggregate denoted, _B_, as the digest of the concatenation of a set of blinded digests of bulk issued ACDC SAIDS. Each ACDC SAID is first blinded via concatenation to a UUID (salty nonce) and then the digest of that concatenation is concatenated with the other blinded SAID digests. Finally, a digest of that concatenation provides the aggregate.
Suppose there are _M_ ACDCs in a bulk issued set. Using zero-based indexing for each member of the bulk issued set of ACDCs, such that index _k_ satisfies _k in {0, ..., M-1}, let_ dk _denote the top-level SAID of an ACDC in an ordered set of bulk-issued ACDCs. Let_ vk _denote the UUID (salty nonce) or blinding factor that is used to blind that said. The blinding factor,_ vk_, is NOT the top-level UUID, `u`, field of the ACDC itself but an entirely different UUID used to blind the ACDC's SAID for the purpose of aggregation. The derivation path for_ vk _from the shared secret salt is_ "k." _where_ k\* is the index of the bulk-issued ACDC.
Let _ck = vk + dk_, denote the blinding concatenation where _+_ is the infix concatenation operator. Then the blinded digest, _bk_, is given by, _bk = H(ck) = H(vk + dk)_, where _H_ is the digest operator. Blinding is performed by a digest of the concatenation of the binding factor, _vk_, with the SAID, _dk_ instead of XORing the two. An XOR of two elements whose bit count is much greater than 2 is not vulnerable to a birthday table attack {{BDay}}{{DRB}}{{BDC}}. In order to XOR, however, the two must be of the same length. Different SAIDs MAY be of different lengths, however, and MAY therefore require different length blinding factors. Because concatenation is length independent it is simpler to implement.
The aggregation of blinded digests, _B_, is given by, _B = H(C(bk for all k in {0, ..., M-1}))_, where _C_ is the concatenation operator and _H_ is the digest operator. This aggregate, _B_, provides the issuance proof digest.
The aggregate, _B_, makes a blinded cryptographic commitment to the ordered elements in the list _\[b0, b1, ...., bM-1\]_. A commitment to _B_ is a commitment to all the _bk_ and hence all the dk.
Given sufficient collision resistance of the digest operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements {{BDC}}{{BDay}}{{QCHC}}{{HCR}}{{Hash}}.
Disclosure of any given _bk_ element does not expose or disclose any discoverable information detail about either the SAID of its associated ACDC or any other ACDC's SAID. Therefore one may safely disclose the full list of _bk_ elements without exposing the blinded bulk issued SAID values, dk.
Proof of inclusion in the list of blinded digests consists of checking the list for a matching value. A computationally efficient way to do this is to create a hash table or B-tree of the list and then check for inclusion via lookup in the hash table or B-tree.
A proof of inclusion of an ACDC in a bulk-issued set requires disclosure of _vk_ which is only disclosed after the disclosee has accepted (agreed to) the terms of the rule section. Therefore, in the event the _Disclosee_ declines to accept the terms of disclosure, then a presentation/disclosure of the compact version of the ACDC does not provide any point of correlation to any other SAID of any other ACDC from the bulk set that contributes to the aggregate _B_. In addition, because the other SAIDs are hidden by each _bk_ inside the aggregate, _B_, even a presentation/disclosure of, _\[b0, b1, ...., bM-1\]_ does not provide any point of correlation to the actual bulk-issued ACDC without disclosure of its _vk_. Indeed if the _Discloser_ uses a metadata version of the ACDC in its _offer_ then even its SAID is not disclosed until after acceptance of terms in the rule section.
To protect against later forgery given a later compromise of the signing keys of the Issuer, the issuer MUST anchor an issuance proof seal to the ACDC in its KEL. This seal binds the signing key state to the issuance. There are two cases. In the first case, an issuance/revocation registry is used. In the second case, an issuance/revocation registry is not used.
When the ACDC is registered using an issuance/revocation TEL (Transaction Event Log) then the issuance proof seal digest is the SAID of the issuance (inception) event in the ACDC's TEL entry. The issuance event in the TEL uses the aggregate value, _B_, as its identifier value. This binds the aggregate, _B_, to the issuance proof seal in the Issuer's KEL through the TEL.
Recall that the usual purpose of a TEL is to provide a verifiable data registry that enables dynamic revocation of an ACDC via a state of the TEL. A verifier checks the state at the time of use to check if the associated ACDC has been revoked. The Issuer controls the state of the TEL. The registry identifier, `ri`, field is used to identify the public registry which usually provides a unique TEL entry for each ACDC. Typically the identifier of each TEL entry is the SAID of the TEL's inception event which is a digest of the event's contents which include the SAID of the ACDC. In the bulk issuance case, however, the TEL's inception event contents include the aggregate, _B_, instead of the SAID of a given ACDC. Recall that the goal is to generate an aggregate value that enables an Issuee to selectively disclose one ACDC in a bulk-issued set without leaking the other members of the set to un-permissioned parties (second or third). Using the aggregate, _B_ of blinded ACDC saids as the TEL registry entry identifier allows all members of the bulk-issued set to share the same TEL without any third party being able to discover which TEL any ACDC is using in an un-permissioned provable way. Moreover, a second party may not discover in an un-permissioned way any other ACDCs from the bulk-issued set not specifically disclosed to that second party. In order to prove to which TEL a specific bulk issued ACDC belongs, the full inclusion proof must be disclosed.
When the ACDC is not registered using an issuance/revocation TEL then the issuance proof seal digest is the aggregate, _B_, itself.
In either case, this issuance proof seal makes a verifiable binding between the issuance of all the ACDCs in the bulk issued set and the key state of the Issuer at the time of issuance.
A _Discloser_ may make a basic provable non-repudiable selective disclosure of a given bulk issued ACDC, at index _k_ by providing to the _Disclosee_ four items of information (proof of inclusion). These are as follows:
- The ACDC in compact form (at index _k_) where _dk_ as the value of its top-level SAID, `d`, field.
- The blinding factor, _vk_ from which _bk = H(vk + dk)_ may be computed.
- The list of all blinded SAIDs, _\[b0, b1, ...., bM-1\]_ that includes _bk_.
- A reference to the anchoring seal in the Issuer's KEL or TEL that references the aggregate _B_. The event that references the seal or the TEL event that references _B_ must be signed by the issuer so the signature on either event itself is sufficient to prove authorized issuance.
The aggregate _B_ is a point of unpermissioned correlation but not permissioned correlation. To remove _B_ as a point of unpermissioned correlation requires using _independent TEL bulk-issued ACDCs_ described in the section so named below.
A _Disclosee_ may then verify the disclosure by:
- computing _dj_ on the disclosed compact ACDC.
- computing _bk = H(vk + dk)_
- confirming that the computed _bk_ appears in the provided list _\[b0, b1, ...., bM-1\]_.
- computing the aggregate _B_ from the provided list _\[b0, b1, ...., bM-1\]_..
- confirming the presence of an issuance seal digest in the Issuer's KEL that makes a commitment to the aggregate, _B_, either directly or indirectly through a TEL registry entry. This provides proof of authorized issuance.
The last 3 steps that culminate with verifying the anchoring seal also require verifying the key state of the Issuer at the time of issuance, this may require additional verification steps as per the KERI, PTEL, and CESR-Proof protocols.
The requirement of an anchored issuance proof seal of the aggregate _B_ means that the forger MUST first successfully publish in the KEL of the issuer an inclusion proof digest seal bound to a set of forged bulk issued ACDCs. This makes any forgery attempt detectable. To elaborate, the only way to successfully publish such a seal is in a subsequent interaction event in a KEL that has not yet changed its key state via a rotation event. Whereas any KEL that has changed its key state via a rotation must be forked before the rotation. This makes the forgery attempt either both detectable and recoverable via rotation in any KEL that has not yet changed its key state or detectable as duplicity in any KEL that has changed its key state. In any event, the issuance proof seal makes any later attempt at forgery using compromised keys detectable.
The inclusion proof via aggregated list may be somewhat verbose when there are a very large number of bulk issued ACDCs in a given set. A more efficient approach is to create a Merkle tree of the blinded SAID digests, _bk_ and set the aggregate _B_ value as the Merkle tree root digest {{Mrkl}}.
The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes {{TwoPI}}{{MTSec}}. The discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, _bk_ contributed to the Merkle tree root digest. For a small numbered bulk-issued set of ACDCs, the added complexity of the Merkle tree approach may not be worth the savings in verbosity.
One potential point of provable but un-permissioned correlation among any group of colluding malicious _Disclosees_ (Second-Party verifiers) may arise when the same Issuee AID is used for presentation/disclosure to all _Disclosees_ in that group. Recall that the contents of private ACDCs are not disclosed except to permissioned _Disclosees_ (Second-Parties). Thus a common _Issuee_ AID would only be a point of correlation for a group of colluding malicious verifiers. But in some cases removing this un-permissioned point of correlation may be desirable.
One solution to this problem is for the _Issuee_ to use a unique AID for the copy of a bulk-issued ACDC presented to each _Disclosee_ in a given context. This requires that each ACDC copy in the bulk-issued set use a unique _Issuee_ AID. This would enable the _Issuee_ in a given context to minimize provable correlation by malicious _Disclosees_ against any given _Issuee_ AID. In this case, the bulk issuance process may be augmented to include the derivation of a unique Issuee AID in each copy of the bulk-issued ACDC by including in the inception event that defines a given Issuee's self-addressing AID, a digest seal derived from the shared salt and copy index _k_. The derivation path for the digest seal is _"k/0."_ where _k_ is the index of the ACDC. To clarify _"k/0."_ specifies the path to generate the UUID to be included in the inception event that generates the Issuee AID for the ACDC at index _k_. This can be generated on-demand by the _Issuee_. Each unique _Issuee_ AID would also need its own KEL. But generation and publication of the associated KEL can be delayed until the bulk-issued ACDC is actually used. This approach completely isolates a given _Issuee_ AID to a given context with respect to the use of a bulk-issued private ACDC. This protects against even the un-permissioned correlation among a group of malicious Disclosees (Second Parties) via the Issuee AID.
In some applications, it is desirable that the current state of a transaction event log (TEL) be hidden or blinded such that the only way for a potential verifier of the state to observe that state is when the controller of a designated AID discloses it at the time of presentation. This designated AID we call the Discloser. Typically for ACDCs that have an Issuee, the Discloser is the Issuee, but the Issuer could designate any AID as the Discloser. Only the Discloser will be able to unblind the state to a potential Disclosee.
In a blindable state TEL, the state disclosure is interactive. A Disclosee may only observe the state when unblinded via an interactive exchange with the Discloser. After disclosure, the Discloser may then request that the Issuer update the state with a new blinding factor (_the blind_). The Disclosee cannot then observe the current state of the TEL without yet another disclosure interaction with the Discloser.
The blind is derived from a secret salt shared between the Issuer and the designated Discloser. The current blind is derived from this salt, and the sequence number of the TEL event is so blinded. To elaborate, the derivation path for the blind is the sequence number of the TEL event, which in combination with the salt, produces a universally unique salty nonce for the blind. Only the Issuer and Discloser have a copy of the secret salt, so only they can derive the current blind. The Issuer provides a service endpoint to which the Discloser can make a signed request to update the blind. Each new event in the TEL MUST change the blinding factor but MAY or MAY NOT change the actual blinded state. Only the Issuer can change the actual blinded state. Because each updated event in the TEL has a new blinding factor regardless of an actual change of state or not, an observer can not correlate state changes to event updates as long as the Issuer regularly updates the blinding factor by issuing a new TEL event.
Blindable State TEL events use a unique event type, `upd`. The event state is hidden in the `a` field, whose value is the blinded SAID of a field map that holds the TEL state. The field map's SAID is its `d` field. The blinding factor is provided in the field map's `u` field. The SAID of the associated ACDC is in the field map's `i` field or else the aggregate value for bulk issued ACDCs. The actual state of the TEL for that ACDC is provided by other fields in the `a`, field map. A simple state could use the `s` field for state or status.
When the `u` field is missing or empty, then the event is not blindable. When the `u` field has sufficient entropy, then the SAID of the enclosing field map effectively blinds the state provided by that map. The discloser must disclose the field map to the Disclosee, who can verify that its SAID matches the SAID in the TEL. A subsequent update event entered into that TEL will then re-blind the state of the TEL so that any prior Disclosees may no longer verify the current state of the TEL.
| Label | Description | Notes |
| --- | --- | --- |
| v | version string | |
| d | event digest | SAID |
| s | sequence number of event | |
| t | message type of event | `upd` |
| dt | issuer system data/time in iso format | |
| p | prior event digest | SAID |
| ri | registry identifier from management TEL | |
| ra | registry anchor to management TEL | |
| a | state attributed digest | SAID |
| Label | Description | Notes |
| --- | --- | --- |
| d | attribute digest | SAID |
| u | salty nonce blinding factor | UUID |
| i | namespaced identifier of VC or aggregate when bulk issued | SAID or Aggregate |
| s | state value | `issued` or `revoked` |
Recall that the purpose of using the aggregate _B_ for a bulk-issued set from which the TEL identifier is derived is to enable a set of bulk-issued ACDCs to share a single public TEL and/or a single anchoring seal in the Issuer's KEL without enabling un-permissioned correlation to any other members of the bulk set by virtue of the shared aggregate _B_ used for either the TEL or anchoring seal in the KEL. When using a TEL this enables the issuance/revocation/transfer state of all copies of a set of bulk-issued ACDCs to be provided by a single TEL which minimizes the storage and compute requirements on the TEL registry while providing selective disclosure to prevent un-permissioned correlation via the public TEL. When using an anchoring seal, this enables one signature to provide proof of inclusion in the bulk-issued aggregate _B_.
However, in some applications where chain-link confidentiality does not sufficiently deter malicious provable correlation by Disclosees (Second-Party verifiers), an Issuee may benefit from using ACDC with independent TELs or independent aggregates _B_ but that are still bulk-issued.
In this case, the bulk issuance process must be augmented so that each uniquely identified copy of the ACDC gets its own TEL entry (or equivalently its own aggregate _B_) in the registry. Each Disclosee (verifier) of a full presentation/disclosure of a given copy of the ACDC only receives proof of one uniquely identified TEL and can NOT provably correlate the TEL state of one presentation to any other presentation because the ACDC SAID, the TEL identifier, and the signature of the issuer on each aggregate _B_ will be different for each copy. There is, therefore no point of provable correlation, permissioned or otherwise. One could for example, modulate this apprach by having a set of smaller bulk issued sets that are more contextualized than one large bulk issued set.
The obvious drawbacks of this approach (independent unique TELs for each private ACDC) are that the size of the registry database increases as a multiple of the number of copies of each bulk-issued ACDC and every time an Issuer must change the TEL state of a given set of copies it must change the state of multiple TELs in the registry. This imposes both a storage and computation burden on the registry. The primary advantage of this approach, however, is that each copy of a private ACDC has a uniquely identified TEL. This minimizes un-permissioned Third-Party exploitation via provable correlation of TEL identifiers even with colluding Second-Party verifiers. They are limited to statistical correlation techniques.
In this case, the set of private ACDCs may or may not share the same Issuee AID because for all intents and purposes each copy appears to be a different ACDC even when issued to the same Issuee. Nonetheless, using unique Issuee AIDs may further reduce correlation by malicious Disclosees (Second-Party verifiers) beyond using independent TELs.
To summarize the main benefit of this approach, in spite of its storage and compute burden, is that in some applications chain-link confidentiality does not sufficiently deter un-permissioned malicious collusion. Therefore completely independent bulk-issued ACDCs may be used.
ToDo
Append-only verifiable data structures have strong security properties that simplify end-verifiability & foster decentralization.
Append-only provides permission-less extensibility by downstream issuers, presenters, and/or verifiers
Each ACDC has a universally-unique content-based identifier with a universally-unique content-based schema identifier.
Fully decentralized name-spacing.
Custom fields are appended via chaining via one or more custom ACDCs defined by custom schema (type-is-schema).
No need for centralized permissioned name-space registries to resolve name-space collisions.
The purposes of a registry now become merely schema discovery or schema blessing for a given context or ecosystem.
The reach of the registry is tuned to the reach of desired interoperability by the ecosystem participants.
Human meaningful labels on SAIDs are local context only.
Versioning is simplified because edges still verify if new schema are backwards compatible. (persistent data structure model).
The compact disclosure and distribute property graph fragment mechanisms in ACDC can be leveraged to enable high performance at scale. Simply using SAIDs and signed SAIDs of ACDCs in whole or in part enables compact but securely attributed and verifiable references to ACDCs to be employed anywhere performance is an issue. Only the SAID and its signature need be transmitted to verify secure attribution of the data represented by the SAID. Later receipt of the data may be verified against the SAID. The signature does not need to be re-verified because a signature on a SAID is making a unique (to within the cryptographic strength of the SAID) commitment to the data represented by the SAID. The actual detailed ACDC in whole or in part may then be cached or provided on-demand or just-in-time.
Hierarchical decomposition of data into a distributed verifiable property graph, where each ACDC is a distributed graph fragment, enables performant reuse of data or more compactly performant reuse of SAIDs and their signatures. The metadata and attribute sections of each ACDC provide a node in the graph and the edge section of each ACDC provides the edges to that node. Higher-up nodes in the graph with many lower-level nodes need only be transmitted, verified, and cached once per every node or leaf in the branch not redundantly re-transmitted and re-verified for each node or leaf as is the case for document-based verifiable credentials where the whole equivalent of the branched (graph) structure must be contained in one document. This truly enables the bow-tie model popularized by Ricardian contracts, not merely for contracts, but for all data authenticated, authorized, referenced, or conveyed by ACDCs.
For crypto-systems with _perfect-security_, the critical design parameter is the number of bits of entropy needed to resist any practical brute force attack. In other words, when a large random or pseudo-random number from a cryptographic strength pseudo-random number generator (CSPRNG) {{CSPRNG}} expressed as a string of characters is used as a seed or private key to a cryptosystem with _perfect-security_, the critical design parameter is determined by the amount of random entropy in that string needed to withstand a brute force attack. Any subsequent cryptographic operations must preserve that minimum level of cryptographic strength. In information theory {{IThry}}{{ITPS}} the entropy of a message or string of characters is measured in bits. Another way of saying this is that the degree of randomness of a string of characters can be measured by the number of bits of entropy in that string. Assuming conventional non-quantum computers, the convention wisdom is that, for systems with information-theoretic or perfect security, the seed/key needs to have on the order of 128 bits (16 bytes, 32 hex characters) of entropy to practically withstand any brute force attack. A cryptographic quality random or pseudo-random number expressed as a string of characters will have essentially as many bits of entropy as the number of bits in the number. For other crypto-systems such as digital signatures that do not have perfect security, the size of the seed/key may need to be much larger than 128 bits in order to maintain 128 bits of cryptographic strength.
An N-bit long base-2 random number has 2N different possible values. Given that no other information is available to an attacker with perfect security, the attacker may need to try every possible value before finding the correct one. Thus the number of attempts that the attacker would have to try maybe as much as 2N-1. Given available computing power, one can easily show that 128 is a large enough N to make brute force attack computationally infeasible.
Let's suppose that the adversary has access to supercomputers. Current supercomputers can perform on the order of one quadrillion operations per second. Individual CPU cores can only perform about 4 billion operations per second, but a supercomputer will parallelly employ many cores. A quadrillion is approximately 250 = 1,125,899,906,842,624. Suppose somehow an adversary had control over one million (220 = 1,048,576) supercomputers which could be employed in parallel when mounting a brute force attack. The adversary could then try 250 _220 = 270 values per second (assuming very conservatively that each try only took one operation). There are about 3600_ 24 \* 365 = 313,536,000 = 2log2313536000\=224.91 ~= 225 seconds in a year. Thus this set of a million super computers could try 250+20+25 = 295 values per year. For a 128-bit random number this means that the adversary would need on the order of 2128-95 = 233 = 8,589,934,592 years to find the right value. This assumes that the value of breaking the cryptosystem is worth the expense of that much computing power. Consequently, a cryptosystem with perfect security and 128 bits of cryptographic strength is computationally infeasible to break via brute force attack.
The highest level of cryptographic security with respect to a cryptographic secret (seed, salt, or private key) is called _information-theoretic security_ {{ITPS}}. A cryptosystem that has this level of security cannot be broken algorithmically even if the adversary has nearly unlimited computing power including quantum computing. It must be broken by brute force if at all. Brute force means that in order to guarantee success the adversary must search for every combination of key or seed. A special case of _information-theoretic security_ is called _perfect-security_ {{ITPS}}. _Perfect-security_ means that the ciphertext provides no information about the key. There are two well-known cryptosystems that exhibit _perfect security_. The first is a _one-time-pad_ (OTP) or Vernum Cipher {{OTP}}{{VCphr}}, the other is _secret splitting_ {{SSplt}}, a type of secret sharing {{SShr}} that uses the same technique as a _one-time-pad_.
{::boilerplate bcp14-tagged}
- `SAID` - Self-Addressing Identifier - any identifier which is deterministically generated out of the content, digest of the content
Refer to the body of the specification. Security considerations are included in the context of each section. The ACDC specification is security driven so the specification itself is riddled with discussions of the security considerations in the context in which those discussions are most understandable and relevant.
This document has no IANA actions.
\--- back
{:numbered="false"}
ACDC community.
---
title: WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
description: 9286652585568, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/_08_annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
md: https://weboftrust.github.io/WOT-terms/_08_annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof.md
---
# WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
title: "CESR Proof Signatures" abbrev: "CESR-PROOF" docname: draft-pfeairheller-cesr-proof-latest category: info
ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
author:
- name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](mailto:Philip.Feairheller@gleif.org)
normative: ACDC: target: [https://datatracker.ietf.org/doc/draft-ssmith-acdc/](https://datatracker.ietf.org/doc/draft-ssmith-acdc/) title: Authentic Data Chained Containers author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021 CESR: target: [https://datatracker.ietf.org/doc/draft-ssmith-cesr/](https://datatracker.ietf.org/doc/draft-ssmith-cesr/) title: Composable Event Streaming Representation (CESR) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
SAID: target: [https://datatracker.ietf.org/doc/draft-ssmith-said/](https://datatracker.ietf.org/doc/draft-ssmith-said/) title: Self-Addressing IDentifier (SAID) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
informative: KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
RFC6901: target: [https://datatracker.ietf.org/doc/html/rfc6901](https://datatracker.ietf.org/doc/html/rfc6901) title: JavaScript Object Notation (JSON) Pointer author:
```
-
name: Paul C. Bryan
-
name: Kris Zyp
-
name: Mark Nottingham
date: 2003
```
JSONPath: target: [https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/](https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/) title: JSONPath - Query expressions for JSON author:
```
-
name: Stefan Gössner
-
name: Glyn Normington
-
name: Carsten Bormann
date: 2021-10-25
```
tags: IETF, CESR, SAID, KERI, ACDC
\--- abstract
CESR Proof Signatures are an extension to the Composable Event Streaming Representation \[CESR\] that provide transposable cryptographic signature attachments on self-addressing data (SAD) \[SAID\]. Any SAD, such as an Authentic Chained Data Container (ACDC) Verifiable Credential \[ACDC\] for example, may be signed with a CESR Proof Signature and streamed along with any other CESR content. In addition, a signed SAD can be embedded inside another SAD and the CESR proof signature attachment can be transposed across envelope boundaries and streamed without losing any cryptographic integrity.
\--- middle
Composable Event Streaming Representation (CESR) is a dual text-binary encoding format that has the unique property of text-binary concatenation composability. The CESR specification not only provides the definition of the streaming format but also the attachment codes needed for differentiating the types of cryptographic material (such as signatures) used as attachments on all event types for the Key Event Receipt Infrastructure (KERI) \[KERI\]. While all KERI event messages are self-addressing data (SAD), there is a broad class of SADs that are not KERI events but that require signature attachments. ACDC Verifiable credentials fit into this class of SADs. With more complex data structures represented as SADs, such as verifiable credentials, there is a need to provide signature attachments on nested subsets of SADs. Similar to indices in indexed controller signatures in KERI that specify the location of the public key they represent, nested SAD signatures need a path mechanism to specify the exact location of the nested content that they are signing. CESR Proof Signatures provide this mechanism with the CESR SAD Path Language and new CESR attachment codes, detailed in this specification.
A primary goal of CESR Proof Signatures is to allow any signed self-addressing data (SAD) to be streamed inline with any other CESR content. In support of that goal, CESR Proof Signatures leverage CESR attachments to define a signature scheme that can be attached to any SAD content serialized as JSON \[JSON\], MessagePack \[MGPK\] or CBOR \[CBOR\]. Using this capability, SADs signed with CESR Proof Signatures can be streamed inline in either the text (T) or binary (B) domain alongside any other KERI event message over, for example TCP or UDP. In addition, signed SADs can be transported via HTTP as a CESR HTTP Request (todo: reference needed).
CESR Proof Signatures can be used to sign as many portions of a SAD as needed, including the entire SAD. The signed subsets are either SADs themselves or the self-addressing identifer (SAID) of a SAD that will be provided out of band. A new CESR count code is included with this specification to allow for multiple signatures on nested portions of a SAD to be grouped together under one attachment. By including a SAD Path in the new CESR attachment for grouping signatures, the entire group of signatures can be transposed across envelope boundaries by changing only the root path of the group attachment code.
There are several events in KERI that can contain context specific embedded self-addressing data (SADs). Exchange events (`exn`) for peer-to-peer communication and Replay events (`rpy`) for responding to data requests as well as Expose events (`exp`) for providing anchored data are all examples of KERI events that contain embedded SADs as part of their payload. If the SAD payload for one of these event types is signed with a CESR attachment, the resulting structure is not embeddable in one of the serializations of map or dictionary like data models. (JSON, CBOR, MessagePack) supported by CESR. To solve this problem, CESR Proof Signatures are transposable across envelope boundaries in that a single SAD signature or an entire signature group on any given SAD can be transposed to attach to the end of an enveloping SAD without losing its meaning. This unique feature is provided by the SAD Path language used in either a SAD signature or the root path designation in the outermost attachment code of any SAD signature group. These paths can be updated to point to the embedded location of the signed SAD inside the envelope. Protocols for verifiable credential issuance and proof presentation can be defined using this capability to embed the same verifiable credential SAD at and location in an enveloping `exn` message as appropriate for the protocol without having to define a unique signature scheme for each protocol.
CESR Proof Signatures defines a SAD Path Language to be used in signature attachments for specifying the location of the SAD content within the signed SAD that a signature attachment is verifying. This path language has a more limited scope than alternatives like JSONPtr \[RFC6901\] or JSONPath \[JSONPath\] and is therefore simpler and more compact when encoding in CESR signature attachments. SADs in CESR and therefore CESR Proof Signatures require static field ordering of all maps. The SAD path language takes advantage of this feature to allow for a Base64 compatible syntax into SADs even when a SAD uses non-Base64 compatible characters for field labels.
The SAD path language contains a single reserved character, the `-` (dash) character. Similar to the `/` (forward slack) character in URLs, the `-` in the SAD Path Language is the path separator between components of the path. The `-` was selected because it is a one of the valid Base64 characters.
The simplest path in the SAD Path Language is a single `-` character representing the root path which specifies the top level of the SAD content.
Root Path
```
-
```
After the root path, path components follow, delimited by the `-` character. Path components may be integer indices into field labels or arrays or may be full field labels. No wildcards are supported by the SAD Path Language.
An example SAD Path using only labels that resolve to map contexts follows:
```
-a-personal
```
In addition, integers can be specified and their meaning is dependent on the context of the SAD.
```
-1-12-personal-0
```
The rules for a SAD Path Language processor are simple. If a path consists of only a single `-`, it represents the root of the SAD and therefore the entire SAD content. Following any `-` character is a path component that points to a field if the current context is a map in the SAD or is an index of an element if the current context is an array. It is an error for any sub-path to resolve to a value this is not a map or an array. Any trailing `-` character in a SAD Path can be ignored.
The root context (after the initial `-`) is always a map. Therefore, the first path component represents a field of that map. The SAD is traversed following the path components as field labels or indexes in arrays until the end of the path is reached. The value at the end of the path is then returned as the resolution of the SAD Path. If the current context is a map and the path component is an integer, the path component represents an index into fields of the map. This feature takes advantage of the static field ordering of SADs and is used against any SAD that contains field labels that use non-Base64 compatible characters or the `-` character. Any combination of integer and field label path components can be used when the current context is a map. All path components MUST be an integer when the current context is an array.
SAD Paths are variable raw size primitives that require CESR variable size codes. We will use the `A` small variable size code for SAD Paths which has 3 code entries being added to the Master Code Table, `4A##`, `5A##` and `6A##` for SAD Paths with 0 lead bytes, 1 lead byte and 2 lead bytes respecively. This small variable size code is reserved for text values that only contain valid Base64 characters. These codes are detailed in Table 2 below. The selector not only encodes the table but also implicitly encodes the number of lead bytes. The variable size is measured in quadlets of 4 characters each in the T domain and equivalently in triplets of 3 bytes each in the B domain. Thus computing the number of characters when parsing or off-loading in the T domain means multiplying the variable size by 4. Computing the number of bytes when parsing or off-loading in the B domain means multiplying the variable size by 3. The two Base64 size characters provide value lengths in quadlets/triplets from 0 to 4095 (64\*_2 -1). This corresponds to path lengths of up to 16,380 characters (4095_ 4) or 12,285 bytes (4095 \* 3).
This section provides some more examples for SAD Path expressions. The examples are based on Authentic Chained Data Containers (ACDCs) representing verifiable credentials.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"home-city": "Durham"
}
},
"p": [
{
"qualifiedIssuerCredential": {
"d": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"i": "Et2DOOu4ivLsjpv89vgv6auPntSLx4CvOhGUxMhxPS24"
}
},
{
"certifiedLender": {
"d": "EglG9JLG6UhkLrrv012NPuLEc1F3ne5vPH_sHGP_QPN0",
"i": "E8YrUcVIqrMtDJHMHDde7LHsrBOpvN38PLKe_JCDzVrA"
}
}
]
}
```
Figure 1. Example ACDC Credential SAD
The examples in Table 1 represent all the features of the SAD Path language when referring to the SAD in Figure 1. along with the CESR text encoding.
| SAD Path | Result | CESR T Domain Encoding |
| --- | --- | --- |
| \- | The root of the SAD | 6AABAAA- |
| \-a-personal | The personal map of the a field | 4AADA-a-personal |
| \-4-5 | The personal map of the a field | 4AAB-4-5 |
| \-4-5-legalName | "John Doe" | 5AAEAA-4-5-legalName |
| \-a-personal-1 | "Durham" | 6AAEAAA-a-personal-1 |
| \-p-1 | The second element in the p array | 4AAB-p-1 |
| \-a-LEI | "254900OPPU84GM83MG36" | 5AACAA-a-LEI |
| \-p-0-0-d | "EIl3MORH...6DZA" | 4AAC-p-0-0-d |
| \-p-0-certifiedLender-i | "E8YrUcVI...zVrA" | 5AAGAA-p-0-certifiedLender-i |
The SAD Path language was chosen over alternatives such as JSONPtr and JSONPath in order to create a more compact representation of a pathing language in the text domain. Many of the features of the alternatives are not needed for CESR Proof Signatures. The only token in the language (`-`) is Base64 compatible. The use of field indices in SADs (which require staticly ordered fields) allows for Base64 compatible pathing even when the field labels of the target SAD are not Base64 compatible. The language accomplishes the goal of uniquely locating any path in a SAD using minimally sufficient means in a manner that allows it to be embedded in a CESR attachment as Base64. Alternative syntaxes would need to be Base64 encoded to be used in a CESR attachment in the text domain thus incurring the additional bandwidth cost of such an encoding.
This specification adds 2 _Counter Four Character Codes_ to the Master Code Table and uses 1 _Small Variable Raw Size Code Type_ and 1 _Large Variable Raw Size Code Type_ from the Master Code Table (each of which have 3 code entries).
The SAD Path Signature counter code is represented by the four character code `-J##`. The first two characters reserve this code for attaching the couplet (SAD Path, Signature Group). The second two characters represent the count in hexidecimal of SAD path signatures are in this attachment. The path is attached in the T domain using the codes described in the next section. The signature group is from either a transferable identifier or a non-transferable identifier and therefore attached using the CESR codes `-F##` or `-C##` respectively as described in the CESR Specification \[CESR\].
The code `A` is reserved as a Small Variable Raw Size Code and `AAA` as a Large Variable Raw Size Code for Base64 URL safe strings. SAD Paths are Base64 URL safe strings and so leverage these codes when encoded in the CESR T domain. To account for the variable nature of path strings, the variable size types reserve 3 codes each with prefix indicators of lead byte size used for adjusting the T domain encoding to multiples of 4 characters and the B domain to multiples of 3 bytes. For the _Small_ codes the prefix indicators are `4`, `5` and `6` representing 0, 1 and 2 lead bytes respectively and for _Large_ codes the prefix indicators are `7`, `8`, and `9` representing 0, 1 and 2 lead bytes respectively. The resulting 6 code entries are displayed in the table that follows.
The additions to the Master Code Table of CESR is shown below:
| Code | Description | Code Length | Count or Index Length | Total Length |
| --- | --- | --- | --- | --- |
| | **Counter Four Character Codes** | | | |
| \-J## | Count of attached qualified Base64 SAD path sig groups path+sig group (trans or non-trans) | 2 | 2 | 4 |
| \-K## | Count of attached qualified Base64 SAD Path groups | 2 | 2 | 4 |
| | **Small Variable Raw Size Code** | | | |
| 4A## | String Base64 Only with 0 Lead Bytes | 2 | 2 | 4 |
| 5A## | String Base64 Only with 1 Lead Byte | 2 | 2 | 4 |
| 6A## | String Base64 Only with 2 Lead Bytes | 2 | 2 | 4 |
| | **Large Variable Raw Size Code** | | | |
| 7AAA#### | String Base64 Only with 0 Lead Bytes | 4 | 4 | 8 |
| 8AAA#### | String Base64 Only with 1 Lead Byte | 4 | 4 | 8 |
| 9AAA#### | String Base64 Only with 2 Lead Bytes | 4 | 4 | 8 |
CESR defines several counter codes for attaching signatures to serialized CESR event messages. For KERI event messages, the signatures in the attachments apply to the entire serialized content of the KERI event message. As all KERI event messages are SADs, the same rules for signing a KERI event message applies to signing SADs for CESR Proof Signatures. A brief review of CESR signatures for transferable and non-transferable identifiers follows. In addition, signatures on nested content must be specified.
Signatures on SAD content require signing the serialized encoding format of the data ensuring that the signature applies to the data over the wire. The serialization for any SAD is identified in the version string which can be found in the `v` field of any KERI event message or ACDC credential. An example version string follows:
```
{
"v": "KERI10JSON00011c_"
}
```
where KERI is the identifier of KERI events followed by the hexidecimal major and minor version code and then the serialized encoding format of the event, JSON in this case. KERI and ACDC support JSON, MessagePack and CBOR currently. Field ordering is important when apply cryptographic signatures and all serialized encoding formats must support static field ordering. Serializing a SAD starts with reading the version string from the SAD field (`v` for KERI and ACDC events message) to determine the serialized encoding format of the message. The serialized encoding format is used to generate the SAID at creation and can not be changed. The event map is serialized using a library that ensures the static field order perserved across serialization and deserialization and the private keys are used to generate the qualified cryptographic material that represents the signatures over the SAD content.
The same serialized encoding format must be used when nesting a SAD in another SAD. For example, an ACDC credential that was issued using JSON can only be embedded and presented in a KERI `exn` presentation event message that uses JSON as its serialized encoding format. That same credential can not be transmitted using CBOR or MessagePack. Controllers can rely on this restriction when verifying signatures of embedded SADs. When processing the signature attachments and resolving the data at a given SAD path, the serialization of the outter most SAD can be used at any depth of the traversal. New verison string processing does not need to occur at nested paths. However, if credential signature verification is pipelined and processed in parallel to the event message such that the event message is not avaiable, the version string of the nested SAD will still be valid and can be used if needed.
Each attached signature is accompanied by a SAD Path that indicates the content that is signed. The path must resolve within the enveloping SAD to either a nested SAD (map) or a SAID (string) of an externally provided SAD. This of course, includes a root path that resolves to the enveloping SAD itself.
Non-transferable identifiers only ever have one public key. In addition, the identifier prefix is identical to the qualified cryptographic material of the public key and therefore no KEL is required to validate the signature of a non-transferable identifier \[KERI\]. The attachment code for witness receipt couplets, used for CESR Proof Signatures, takes this into account. The four character couner code `-C##` is used for non-transferable identifiers and contains the signing identfier prefix and the signature \[CESR\]. Since the verification key can be extracted from the identifier prefix and the identifier can not be rotated, all that is required to validate the signature is the identifier prefix, the data signed and the signature.
Transferable identifiers require full KEL resolution and verfication to determine the correct public key used to sign some content \[KERI\]. In addition, the attachment code used for transferable identifiers, `-F##` must specify the location in the KEL at which point the signature was generated \[CESR\]. To accomplish this, this counter code includes the identifier prefix, the sequence number of the event in the KEL, the digest of the event in the KEL and the indexed signatures (transferable identifiers support multiple public/private keys and require index signatures). Using all the values, one can verify the signature(s) by retrieving the KEL of the identifier prefix and determine the key state at the sequence number along with validating the digest of the event against the actual event. Then using the key(s) at the determined key state, validate the signature(s).
This specification adds two Counter Four Character Codes to the CESR Master Code Table for attaching and grouping transposable signatures on SAD and nested SAD content. The first code (`-J##`) is reserved for attaching a SAD path and the associated signatures on the content at the resolution of the SAD Path (either a SAD or its associated SAID). The second reserved code (`-K##`) is for grouping all SAD Path signature groups under a root path for a given SAD. The root path in the second grouping code provides signature attachment transposability for embedding SAD content in other messages.
The SAD Path Signature Group provides a four character counter code, `-J##`, for attaching an encoded variable length SAD Path along with either a transferable index signature group or non-transferable identifer receipt couplets. The SAD Path identifies the content that this attachment is signing. The path must resolve to either a nested SAD (map) or a SAID (string) of an externally provided SAD within the context of the SAD and root path against which this attachment is applied. Using the following ACDC SAD embedded in a KERI `exn` message:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00",
"r": "/credential/offer",
"a": {
"credential": { // SIGNATURE TARGET OF TRANSPOSED SAD PATH GROUP
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"home": "Durham"
}
}
}
}
}
```
the following signature applies to the nested `credential` SAD signed by a transferable identifier using the transferable index signature group. The example is annotated with spaces and line feeds for clarity and an accompanied table is provided with comments.
```
-JAB
6AAEAAA-a-credential
-FAB
E_T2_p83_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y
-EAB0AAAAAAAAAAAAAAAAAAAAAAB
EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM
-AAD
AA5267UlFg1jHee4Dauht77SzGl8WUC_0oimYG5If3SdIOSzWM8Qs9SFajAilQcozXJVnbkY5stG_K4NbKdNB4AQ
ABBgeqntZW3Gu4HL0h3odYz6LaZ_SMfmITL-Btoq_7OZFe3L16jmOe49Ur108wH7mnBaq2E_0U0N0c5vgrJtDpAQ
ACTD7NDX93ZGTkZBBuSeSGsAQ7u0hngpNTZTK_Um7rUZGnLRNJvo5oOnnC1J2iBQHuxoq8PyjdT3BHS2LiPrs2Cg
```
| code | description |
| --- | --- |
| \-JAB | SAD path signature group counter code 1 following the group |
| 6AAEAAA-a-credential | encoded SAD path designation |
| \-FAB | Trans Indexed Sig Groups counter code 1 following group |
| E\_T2\_p83\_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y | trans prefix of signer for sigs |
| \-EAB0AAAAAAAAAAAAAAAAAAAAAAB | sequence number of est event of signer's public keys for sigs |
| EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM | digest of est event of signer's public keys for sigs |
| \-AAD | Controller Indexed Sigs counter code 3 following sigs |
| AA5267...4AQ | sig 0 |
| ABBgeq...pAQ | sig 1 |
| ACTD7N...2Cg | sig 2 |
The next example demostrates the use of a non-transferable identifier to sign SAD content. In this example, the entire nested SAD located at the `a` field is signed by the non-transferable identfier:
```
-JAB
5AABAA-a
-CAB
BmMfUwIOywRkyc5GyQXfgDA4UOAMvjvnXcaK9G939ArM
0BT7b5PzUBmts-lblgOBzdThIQjKCbq8gMinhymgr4_dD0JyfN6CjZhsOqqUYFmRhABQ-vPywggLATxBDnqQ3aBg
```
| code | description |
| --- | --- |
| \-JAB | SAD path signature group counter code 1 following the group |
| 5AABAA-a | encoded SAD path designation |
| \-CAB | NonTrans witness receipt couplet |
| BmMfUwIOywRkyc5GyQXfgDA4UOAMvjvnXcaK9G939ArM | non-trans prefix of signer of sig |
| 0BT7b5... aBg | sig |
The SAD Path Group provides a four character counter code, `-K##`, for attaching encoded variable length **root** SAD Path along with 1 or more SAD Path Signature Groups. The root SAD Path identifies the root context against which the paths in all included SAD Path Signature Groups are resolved. When parsing a SAD Path Group, if the root path is the single `-` character, all SAD paths are treated as absolute paths. Otherwise, the root path is prepended to the SAD paths in each of the SAD Path Signature Groups. Given the following snippet of a SAD Path Group:
```
-KAB6AABAAA--JAB5AABAA-a...
```
The root path is the single `-` character meaning that all subsequent SAD Paths are absolute and therefore the first path is resolved as the `a` field of the root map of the SAD as seen in the following example:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"city": "Durham"
}
}
}
```
To support nesting of signed SAD content in other SAD content the root path of SAD Path Groups or the path of a SAD Path Signature Group provides transposability of CESR SAD signatures such that a single SAD Path Signature Group or an entire SAD Path Group attachment can be transposed across envelope boundaries by updating the single path or root path to indicate the new location. Extending the example above, the SAD content is now embedded in a KERI `exn` event message as follows:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00"
"r": "/credential/offer"
"a": {
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF TRANSPOSED SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"city": "Durham"
}
}
}
}
```
The same signature gets transposed to the outer `exn` SAD by updating the root path of the `-K##` attachment:
```
-KAB5AABAA-a-JAB5AABAA-a...
```
Now the SAD Path of the first signed SAD content resolves to the `a` field of the `a` field of the streamed `exn` message
The small variable raw side code reserved for SAD Path encoding is `A` which results in the addition of 3 entries (`4A##`, `5A##` and `6A##`) in the Master Code Table for each lead byte configuration. These codes and their use are discussed in detail in CESR Encoding for SAD Path Language.
Additional signatures on nested content can be included in a SAD Path Group and are applied to the serialized data at the resolution of a SAD path in a SAD. Signatures can be applied to the SAID or an entire nested SAD. When verifying a CESR Proof Signature, the content at the resolution of the SAD path is the data that was signed. The choice to sign a SAID or the full SAD effects how the data may be used in presentations and the rules for verifying the signature.
When signing nested SAD content, the serialization used at the time of signing is the only serialization that can be used when presenting the signed data. When transposing the signatures and nesting the signed data, the enveloping SAD must use the same serialization that was used to create the signatures. This is to ensure that all signatures apply to the data over the wire and not a transformation of that data. The serialization can be determined from the version field (`v`) of the nested SAD or any parent of the nested SAD as they are guaranteed to be identical. Consider the following ACDC Credential SAD:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"first": "John",
"last": "Doe"
}
}
}
```
To sign the SAD located at the path `-a`, JSON serialization would be used because the SAD at that path does not have a version field so the version field of its parent is used. The serialization rules (spacing, field ordering, etc) for a SAD would be used for the SAD and the serialization encoding format and the signature would be applied to the bytes of the JSON for that map. Any presentation of the signed data must always include the fully nested SAD. The only valid nesting of this credential would be as follows:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00"
"r": "/credential/apply"
"a": {
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // FULL SAD MUST BE PRESENT
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"first": "John",
"last": "Doe"
}
}
}
}
```
Applying signatures to a SAD with SAIDs in place of fully expanded nested SAD content enables compact credentials for domains with bandwidth restrictions such as IoT. Consider the following fully expanded credential:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"n": "sKHtYSiCdlibuLDS2PTJg1AZXtPhaySZ9O3DoKrRXWY",
"first": "John
"middle": "William"
"last": "Doe"
},
"address": {
"d": "E-0luqYSg6cPcMFmhiAz8VBQObZLmTQPrgsr7Z1j6CA4",
"n": "XiSoVDNvqV8ldofPyTVqQ-EtVPlkIIQTln9Ai0yI05M",
"street": "123 Main St",
"city": "Salt Lake City",
"state": "Utah",
"zipcode": "84157"
},
"phone": {
"d": "E6lty8H2sA_1acq8zg89_kqF194DbF1cDpwA7UPtwjPQ",
"n": "_XKNVntbcIjp12DmsAGhv-R7JRwuzjD6KCHC7Fw3zvU"
"mobile": "555-121-3434",
"home": "555-121-3435",
"work": "555-121-3436",
"fax": "555-121-3437"
}
}
}
}
```
The three nested blocks of the `a` block `legalName`, `address` and `phone` are SADs with a SAID in the `d` field and are candidates for SAID replacement in an issued credential. A compact credential can be created and signed by replacing those three nested blocks with the SAID of each nested SAD. The schema for this verifiable credential would need to specify conditional subschema for the field labels at each nesting location that requires the full schema of the nested SAD or a string for the SAID. The commitment to a SAID in place of a SAD contains nearly the same cryptographic integrity as a commitment to the SAD itself since the SAID is the qualified cryptographic material of a digest of the SAD. The same credential could be converted to a compact credential containing the SAIDs of each nested block and signed as follows:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"address": "E-0luqYSg6cPcMFmhiAz8VBQObZLmTQPrgsr7Z1j6CA4",
"phone": "E6lty8H2sA_1acq8zg89_kqF194DbF1cDpwA7UPtwjPQ"
}
}
```
It is important to note that if this version of the credential is the one issued to the holder and the signature over the entire credential is on the serialized data of this version of the credential it is the only version that can be presented. The full SAD data of the three nested blocks would be delivered out of band from the signed credential. The top level schema would describe the blocks with conditional subschema for each section. The credential signature becomes a cryptographic commitment to the contents of the overall credential as well as the content of each of the blocks and will still validate the presented credential with significantly less bandwidth.
With this approach, credential presentation request and exchange protocols can be created that modify the schema with the conditional subschema, removing the conditions that allow for SAIDs in place of the required (or presented) nested blocks. The modified schema can be used in such a protocol to indicate the required sections to be delivered out of bounds or as a commitment to provide the nested blocks after the crendential presentation has occurred.
{::boilerplate bcp14-tagged}
TODO Security
The Internet Assigned Numbers Authority (IANA) is a standards organization that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Internet Protocol-related symbols and Internet numbers.
This document has no IANA actions.
\--- back
{:numbered="false"}
Dr Sam Smith, Kevin Griffin and the Global Legal Entity Identifier Foundation (GLEIF)
---
title: WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
description: 8203357166114, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/_08_annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
md: https://weboftrust.github.io/WOT-terms/_08_annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex.md
---
# WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
title: "Issuance and Presentation Exchange Protocol" abbrev: "IPEX" category: info
docname: draft-ssmith-ipex-latest v: 3 area: AREA workgroup: WG Working Group keyword: Internet-Draft venue: group: WG type: Working Group mail: [WG@example.com](mailto:WG@example.com) arch: [https://example.com/WG](https://example.com/WG) github: USER/REPO latest: [https://example.com/LATEST](https://example.com/LATEST)
author:
- fullname: Samuel M. Smith organization: ProSapien LLC email: "[sam@prosapien.com](mailto:sam@prosapien.com)"
- name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](mailto:Philip.Feairheller@gleif.org)
normative:
IPEX-ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF IPEX (Issuance and Presentation EXchange) Prototocol Internet Draft author:
```
-
ins: S. Smith
name: Samuel M. Smith
org: ProSapien LLC
-
name: Phil Feairheller
organization: GLEIF
email: Philip.Feairheller@gleif.org
date: 2022
```
ACDC-ID: target: [https://github.com/trustoverip/tswg-acdc-specification](https://github.com/trustoverip/tswg-acdc-specification) title: IETF ACDC (Authentic Chained Data Containers) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
OOBI-ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF OOBI (Out-Of-Band-Introduction) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
KERI-ID: target: [https://github.com/WebOfTrust/ietf-keri](https://github.com/WebOfTrust/ietf-keri) title: IETF KERI (Key Event Receipt Infrastructure) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
SAID-ID: target: [https://github.com/WebOfTrust/ietf-said](https://github.com/WebOfTrust/ietf-said) title: IETF SAID (Self-Addressing IDentifier) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
CESR-ID: target: [https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr) title: IETF CESR (Composable Event Streaming Representation) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
PTEL-ID: target: [https://github.com/WebOfTrust/ietf-ptel](https://github.com/WebOfTrust/ietf-ptel) title: IETF PTEL (Public Transaction Event Log) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
Proof-ID: target: [https://github.com/WebOfTrust/ietf-cesr-proof](https://github.com/WebOfTrust/ietf-cesr-proof) title: IETF CESR-Proof Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
DIDK-ID: target: [https://github.com/WebOfTrust/ietf-did-keri](https://github.com/WebOfTrust/ietf-did-keri) title: IETF DID-KERI Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
RFC8259: target: [https://datatracker.ietf.org/doc/html/rfc8259](https://datatracker.ietf.org/doc/html/rfc8259) title: JSON (JavaScript Object Notation)
RFC4627: target: [https://datatracker.ietf.org/doc/rfc4627/](https://datatracker.ietf.org/doc/rfc4627/) title: The application/json Media Type for JavaScript Object Notation (JSON)
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
JSch: target: [https://json-schema.org](https://json-schema.org) title: JSON Schema
JSch\_202012: target: [https://json-schema.org/draft/2020-12/release-notes.html](https://json-schema.org/draft/2020-12/release-notes.html) title: "JSON Schema 2020-12"
informative:
KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
IDSys: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf) title: Identity System Essentials
RC: target: [https://en.wikipedia.org/wiki/Ricardian\_contract](https://en.wikipedia.org/wiki/Ricardian_contract) title: Ricardian Contract
CLC: target: [https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=2045818](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818) title: "Chain-Link Confidentiality"
\--- abstract
The Issuance and Presentation Exchange (IPEX) Protocol provides a uniform mechanism for the issuance and presentation of ACDCs {{ACDC-ID}} in a securely attributable manner. A single protocol is able to work for both types of exchanges by recognizing that all exchanges (both issuance and presentation) may be modeled as the disclosure of information by a Discloser to a Disclosee. The difference between exchange types is the information disclosed not the mechanism for disclosure. Furthermore, the chaining mechanism of ACDCs and support for both targeted and untargeted ACDCs provide sufficient variability to accommodate the differences in applications or use cases without requiring a difference in the exchange protocol itself. This greatly simplifies the exchange protocol. This simplification has two primary advantages. The first is enhanced security. A well-delimited protocol can be designed and analyzed to minimize and mitigate attack mechanisms. The second is convenience. A standard simple protocol is easier to implement, support, update, understand, and adopt. The tooling is more consistent.
This IPEX {{IPEX-ID}} protocol leverages important features of ACDCs and ancillary protocols such as CESR {{CESR-ID}}, SAIDs {{SAID-ID}}, and CESR-Proofs {{Proof-ID}} as well as Ricardian contracts {{RC}} and graduated disclosure (partial, selective, full) to enable contractually protected disclosure. Contractually protected disclosure includes both chain-link confidential {{CLC}} and contingent disclosure {{ACDC-ID}}.
\--- middle
TODO Introduction
Presentation Exchange : An exchange that provides disclosure of one or more ACDCs between a _Discloser_ and a _Disclosee_.
A presentation exchange is the process by which authenticatable information may be exchanged between two parties, namely, the _Discloser_ and _Disclosee_.
ACDC : Type of data as issuance concretely defined by the ACDC specification {{ACDC-ID}}.
Discloser : An ACDC in a disclosure is _disclosed by_ the _Discloser_.
Disclosee : An ACDC in a disclosure is _disclosed to_ the _Disclosee_.
Issuer : An _ACDC_ is _issued by_ the _Issuer_. The _Issuer_ identifier (AID) appears in the top level of the ACDC.
Issuee : An _ACDC_ is optionally _issued to_ the _Issuee_. When present, the _Issuee_ identifier (AID) appears at the top level of the attribute section or in the attribute list at the top level of the attribute aggregate section of the ACDC.
Each _ACDC_ MUST have an _Issuer_ and MAY have an _Issuee_.
The set of _ACDCs_ so disclosed in a _presentation exchange_ MUST be chained. This set of chained _ACDCs_ define a directed acyclic graph (DAG) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
Each _ACDC_ itself defines a graph fragment consisting of one vertex and zero or more directed edges. Each directed edge contained in an _ACDC_ points to a vertex contained in another _ACDC_. The ACDC that contains the origin vertex of the DAG is called the _origin_ or _primary_ ACDC of the _presentation exchange_.
The disclosure performed by a presentation exchange MAY be _graduated_ and MAY be _contractually protected_.
Issuance Exchange : A special case of a _presentation exchange_ where the _Discloser_ is the _Issuer_ of the _origin_ (Primary) _ACDC_ of the DAG formed by the set of chained ACDCs so disclosed.
In an _issuance exchange_, when the _origin_ ACDC has an _Issuee_, the _Disclosee_ MAY also be the _origin_ ACDC's _Issuee_.
Disclosures via Presentations Exchanges may be contractually protected by Chain-Link Confidentiality (i.e a Chain-Link Confidential disclosure). The chaining in this case is different from the chaining described above between Issuances in a DAG of chained Issuances. Chain-link confidentiality, in contrast, chains together a sequence of Disclosees. Each Disclosee in the sequence in turn is the Discloser to the next Disclosee. The terms-of-use of the original disclosure as applied to the original Disclosee MUST be applied by each subsequent Discloser to each subsequent Disclosee via each of the subsequent disclosures (presentation exchanges). These terms-of-use typically constrain disclosure to only approved parties, i.e. imbue the chain of disclosures with some degree of confidentiality. These terms-of-use are meant to contractually protect the data rights of the original Issuer or Issuee of the data being disclosed.
| Discloser | Disclosee | Initiate | Contents | Description |
| --- | --- | --- | --- | --- |
| | `apply` | Y | schema or its SAID, attribute field label list, signature on `apply` or its SAID | schema SAID is type of ACDC, optional label list for selective disclosure, CESR-Proof signature |
| `spurn` | | N | | rejects `apply` |
| `offer` | | Y | metadata ACDC or its SAID, signature on `offer` or its SAID | includes schema or its SAID, other partial disclosures, selective disclosure label list, CESR-Proof signature |
| | `spurn` | N | | rejects `offer` |
| | `agree` | N | signature on `offer` or its SAID | CESR-Proof signature |
| `spurn` | | N | | rejects `agree` |
| `grant` | | Y | full or selective disclosure ACDC, signature on `grant` or its SAID | includes attribute values, CESR-Proof signature |
| | `admit` | N | signature on `grant` or its SAID | CESR-Proof signature |
All the variants of an ACDC are various degrees of expansion of the compact variant. Therefore, an Issuer commitment via a signature to any variant of ACDC (compact, full, etc) makes a cryptographic commitment to the top-level section fields shared by all variants of that ACDC because the value of a top level section field is either the SAD or the SAID of the SAD of the associated section. Both a SAD and its SAID, when signed, each provide a verifiable commitment to the SAD. In the former the signature verification is directly agains the SAD itself. In the latter, the SAID as digest must first be verified against its SAD and then the signature on the SAID may be verified. This indirect verifiablity assumes that the cryptographic strength of the SAID digest is equivalent to the cryptographic strength of the signature used to sign it. To clarify, because all variants share the same top level structure as the compact variant, then a signature on any variant may be used to verify the Issuer's committment to any other variant either directly or indirectly, in whole or in part on a top-level section by top-level section basis. This cross-variant Issuer commitment verifiability is an essential property that supports graduated disclosure by the Disclosee of any or all variants wether it be full, compact, metadata, partial, selective, bulk issued, or contractually protected.
To elaborate, the SAID of a given variant is useful even when it is not the SAID of the variant the Issuer signed because during graduated disclosure the Discloser MAY choose to sign that given variant to fullfill a given step in an IPEX graduated disclosure transaction. The Discloser thereby can make a verifiable disclosure in a given step of the SAD of a given variant that fulfills a commitment made in a prior step via its signature on merely the SAID of the SAD of the variant so disclosed.
For example, the Metadata variant of an ACDC will have a different SAID than the Compact variant because some of the top-level field values may be empty in the Metadata variant. One can think of the The metadata variant as a partial manifest that only includes those top level sections that the Discloser is committing to disclose in order to induce the Disclosee to agree to the contractual terms of use when disclosed. The IPEX transaction is between the Discloser and Disclosee, who both may make non-repudiable commitments via signing to each other. Typically this means that the Discloser will eventually need to fulfull its commitment with a proof of disclosure to the Disclosee. This proof may be satisfied with either directly against the Discloser's signature on the the actual disclosed SAD or indirectly agaisnt the Discloser's signature on the SAID of the actual disclosed SAD. In addition, the Disclosee will typically require a proof of issuance via a non-repudiable signature by the Issuer on a variant of the disclosed SAD that is verifiable (directly or indirectly) against the variant that is the disclosed SAD.
To summarize, when the Issuer commits to the composed schema of an ACDC it is committing to all the variants so composed. As described above, the top level field values in the compact variant enable verification against a disclosure of any of the other Issuer committed variants because they all share the same top level structure. This applies even to the metadata variant in spite of it only providing values for some top level sections and not others. The verifiablity of a top level section is separable.
Consequently, the IPEX protocol must specify how a validator does validation of any variant in a graduated disclosure. To restate there are two proofs that a Discloser must provide. The first is proof of issuance and the second is proof of disclosure. In the former, the Discloser provide the variant via its SAD that was actually signed (as SAD or SAID of SAD) by the Issuer in order for the Disclosee to verify authentic issuance via the signature on that variant. In the latter, the Discloser must disclose any other Issuer enabled (via schema composition) variants that the Discloser offered to disclose as part of the graduated disclosure process.
The goal is to define a validation process (set of rules) that works for all variants of an ACDC and for all types of graduated disclosure of that ACDC.
For example, in the bulk issuance of an ACDC, the Issuer only signs the blinded SAID of the SAD that is the Compact variant of the ACDC not the SAD itself. This enable a Discloser to make a proof of inclusion of the ACDC in a bulk issuance set by unblinding the signature on the blinded SAID without leaking correlation to anything but the blinded SAID itself. To clarify, the Disclosee can verify the signature on the SAID without to prove set inclusion with needing the disclosure of any other information about the ACDC. Issuer signing of the SAID not the SAD also has the side benefit of minimizing the computation of large numbers of bulk issued signatures.
The Issuer MUST provide a signature on the SAID of the most compact variant defined by the schema of the ACDC. When more than one variant is defined by the schema via the oneOf composition operator for any top-level field, the most compact variant MUST appear as the first entry in the oneOf list. When only one variant of each top-level field is defined by the schema, that variant is therefore by defintion the most compact variant.
The different variants of an ACDC form a hash tree (using SAIDs) that is analogous to a Merkle Tree. Signing the top-level SAID of the compact version of the ACDC is equivalent to signing the Merkle Root of a Merkle Tree. Different variants of an ACDC (SADs with SAIDs) correspond to different paths through a Merkle tree. The process of verifying that a SAD via its SAID of a section is included in a schema authorized variant down from the top-level SAID is equivalent to a Merkle Tree proof of inclusion along a path in the Merkel Tree down from its Root. This allows a single signature to provide proof of Issuance of the presentation of any schema authorized variants of the ACDC.
An Issuer MAY provide signatures of the SAIDS of other variants, as well as signatures of the SADs of other variants.
Proof of issuance is provided by disclosing the SAID of the most compact variant and the signature by the Issuer on that SAID.
Proof of disclosure is provided by disclosing the SAD of the most compact variant and then recursively disclosing the nested SADs of each of the top level sections of the most compact variant as needed for the promised disclosure.
Thus for any disclosed variant of an ACDC, the Disclosee need only verify only one proof of issuance as defined above and may need to verify a different proof of disclosure for each disclosed variant as defined above.
The following schema supports a compact variant
```
{
"$id": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Public ACDC",
"description": "Example JSON Schema Public ACDC.",
"credentialType": "PublicACDCExample",
"type": "object",
"required":
[
"v",
"d",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry AID",
"type": "string"
},
"s":
{
"description": "schema section",
"oneOf":
[
{
"description": "schema section SAID",
"type": "string"
},
{
"description": "schema detail",
"type": "object"
},
]
},
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute section SAID",
"type": "string"
},
{
"description": "attribute detail",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute section SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false,
}
]
},
"e":
{
"description": "edge section",
"oneOf":
[
{
"description": "edge section SAID",
"type": "string"
},
{
"description": "edge detail",
"type": "object",
"required":
[
"d",
"boss"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"boss":
{
"description": "boss edge",
"type": "object",
"required":
[
"d",
"n",
's',
"w"
],
"properties":
{
"d":
{
"description": "edge SAID",
"type": "string"
},
"n":
{
"description": "far node SAID",
"type": "string"
},
"s":
{
"description": "far node schema SAID",
"type": "string",
"const": ""EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71"
},
"w":
{
"description": "edge weight",
"type": "string"
},
"additionalProperties": false
},
},
"additionalProperties": false
}
]
},
"r":
{
"description": "rule section",
"oneOf":
[
{
"description": "rule section SAID",
"type": "string"
},
{
"description": "rule detail",
"type": "object",
"required":
[
"d",
"warrantyDisclaimer",
"liabilityDisclaimer"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"warrantyDisclaimer":
{
"description": "warranty disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
},
"liabilityDisclaimer":
{
"description": "liability disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
}
},
"additionalProperties": false
}
```
The following JSON field map serialization satisfies the rules for most compact variant of the schema above.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
The Issuer signs the SAID, `d` field value of the field map above.
{::boilerplate bcp14-tagged}
TODO Security
This document has no IANA actions.
\--- back
{:numbered="false"}
TODO acknowledge.
---
title: WebOfTrust-keria-main-docs-protocol
description: signify-keria-request-authentication-protocol--skrap-, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/_08_annotated-copies/WebOfTrust-keria-main-docs-protocol
md: https://weboftrust.github.io/WOT-terms/_08_annotated-copies/WebOfTrust-keria-main-docs-protocol.md
---
# WebOfTrust-keria-main-docs-protocol
The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces.
1. Boot Interface - Exposes one endpoint for Agent Worker initialization.
2. Admin Interface - The REST API for command and control operations from the Signify Client.
3. KERI Protocol Interface - CESR over HTTP endpoint for KERI protocol interactions with the rest of the world.
This separation allows for the Boot interface to be expose to internal infrastructure only (or disabled all together) while exposing the other two interfaces externally. If a KERIA instance is launched in static worker mode, meaning all agent workers are configured at start up only the Boot interface can be disabled completely.
To initiate a connection between a Signify Client and a KERIA agent, the two sides will exchange KERI AIDs with the Signify Client AID (called the "Client AID") being the delegator for the KERIA agent worker AID (called the "Agent AID"). To establish the connection the following steps are performed:
The Signify Client generates the client AID as a transferable AID with a single signing key and single rotation key and provides the signed inception event out-of-bands to the KERIA service through the Boot interface. The HTTP request must be signed by the client AID using Signify Request Authentication described below. The algorithm for generating the signing and rotation key pairs for Client AID is as follows:
1. Prepend the 128 bit random salt derivation code ('0A') plus the blank qualified base 64 character ('A') to the provided 21 character passcode
2. Stretch the passcode derivation using Argon2 to generate an Ed25519 private key from the provided "tier" and paths of `signify:controller00` and `signify:controller01` for the signing key and rotation key respectively.
3. Use the qualified base64 of the signing public key and the qualified base64 of the Blake3 digest of the rotation public key in the inception event.
The follow is an example of a Client AID generated by the SignifyPy (Python implementation) Signify Client with a passcode of `0123456789abcdefghijk`
```
{
"v": "KERI10JSON00012b_",
"t": "icp",
"d": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose", // Client AID
"s": "0",
"kt": "1",
"k": [
"DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc" // Derived from passcode as salt, kidx = 0
],
"nt": "1",
"n": [
"EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL" // Derived from passcode as salt, kidx = 1, Blake3 Hashed
],
"bt": "0",
"b": [],
"c": [],
"a": []
}
```
The KERIA service will create an Agent Worker on behalf of the new client and create the delegated, transferable Agent AID with a single signing key and single rotation key specifying the Client AID as its delegator in its inception event.
The KERIA service will return the Agent AID inception event in a signed HTTP response, signed by the Agent AID. Agent AID keys can be generated using a salt or truly random depending on the requirements of the service hosting the KERIA service.
```
{
"v": "KERI10JSON00015f_",
"t": "dip", // Delegated AID
"d": "EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei",
"i": "EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei", // Agent AID
"s": "0",
"kt": "1",
"k": [
"DMZh_y-H5C3cSbZZST-fqnsmdNTReZxIh0t2xSTOJQ8a"
],
"nt": "1",
"n": [
"EM9M2EQNCBK0MyAhVYBvR98Q0tefpvHgE-lHLs82XgqC"
],
"bt": "0",
"b": [],
"c": [],
"a": [],
"di": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose" // Delegated signing authority from Client AID
}
```
_Note that all HTTP requests against the Admin Interface must be signed by the Client AID and expect all responses to be signed by the Agent AID._
The Signify Client will approve the delegation of the client AID with an interaction event that it sends back to the KERIA service over the Admin interface.
Once these steps are complete the Signify Client can begin using the rest of the Admin interface to create AIDs, issue credentials, etc.
Document the steps for retrieving state from the Admin interface and updating.
The KERIA service supports the following key generation methods where the Signify Client generates the keys and only ever sends encrypted key material (if any) to the server.
1. Salty Keys - HDK key chain generated from a salt per aid that is encrypted and stored server.
2. Randy Keys - Randomly generated keys (signing and rotation) that are encrypted and store on the server.
3. Sandy Keys - Keys generated from a different salt for inception and each rotation.
4. Group Keys - Signify Client/KERIA Service AIDs participating in a distributed group multisig AID.
5. HSM Keys - Signify Client uses a Signify HSM Integration Module (SHIM) to manage keys and signatures.
For all key generation methods, the Signify Client creates and signs all KERI events, credentials, etc. ensuring that unencrypted private key material never leaves the client. The key generate methods are descrive in more detail in the following sections.
The Salty Key algorithm is used to create a hierarchical deterministic key chain for each AID by generating a unique random salt for each AID and stretching the salt using Argon2 with a `path` that is calculated from the AIDs index relative to all other AIDs and the key index calculated by the total number of signing and rotation keys over the lifetime of the AID.
The salt for each AID is encrypted with the X25519 encryption key generated from the passcode and stored on the server with other AID metadata, including the AID index and current key index.
The Signify Client API must accept the AID salt as an optional parameter to creating Salty Key AIDs allowing users to manage AID salts externally or to share Salts across AIDs if required.
The following Python data class represents the metadata storage for Salty Key AIDs:
```
class SaltyPrm:
"""
Salty prefix's parameters for creating new key pairs
"""
sxlt: str = '' # qualified b64 encoded AID salt
pidx: int = 0 # prefix index for this keypair sequence
kidx: int = 0 # key index for this keypair sequence
stem: str = '' # default unique path stem for salty algo
tier: str = '' # security tier for stretch index salty algo
dcode: str = '' # next digest hasing code
icodes: list = field(default_factory=list) # current signing key seed codes
ncodes: list = field(default_factory=list) # next key seed codes
transferable: bool = False
```
Document the procedure for rotating a new Salt in for a Salty Key AID.
The Randy Key algorithm allows for all signing and rotation private keys to be generated solely from entropy and encrypted with the X25519 encryption key generated from the passcode and stored on the server alongside other AID metadata.
The server stores the encrypted private key material for signing and rotation keys in separate LMBD sub-databases as indexed qualified base 64 CESR encoded Cipher representations.
The Group Key algorithm is a special key generation algorith for distributed group multisig AIDs that does not manage and keys at all. Instead this algoritm allows for the specification of an AID of one of the other three types to be the "local" participant in a distributed group multisig AID.
All signing operations must be performed on the Signify Client on behalf of the "local" AID for this Signify Client indexed based on the local AID's location in both the signing key list and the rotation key list.
The SignifyPy Signify Client defines an experimental interface for declaring external modules that can be used as Signify HSM Integration Modules to allow all key generation and event signing to occur in an external Hardware Security Module (HSM).
Two sample implementations have been defined to date, one using the Google KSM and one using a Trezure One external HSM.
The following psuedo Python class represents the current, experimental interface a SHIM has to implememnt to work with SignifyPy. It is anticipated that each Signify Client implementation defines a similar interface.
```
class Shim:
def incept(self, transferable=True):
""" Create an AID using the Google KSM for key generation and event signing.
Parameters:
transferable (bool): True means create a transferable AID which allows for key rotation
Returns:
keys (list): list of qualified base64 public signing key deriviations based on the codes passed into init
ndigs (list): list of qualified base64 digests of public rotation key derivations based on the codes
passed into init
"""
def rotate(self, ncount, transferable):
""" Rotate an AID using the Google KSM for key generation and event signing.
Parameters:
ncount (int): number of new rotation keys to generate
transferable (bool): True means create a transferable AID which allows for key rotation
Returns:
keys (list): list of qualified base64 public signing key deriviations based on the codes passed into init
ndigs (list): list of qualified base64 digests of public rotation key derivations based on the codes
passed into init
"""
def sign(self, ser, indexed=True, indices=None, ondices=None, **_):
"""
Parameters:
ser (bytes): content to be signed
indexed (bool): True means generated indexed signatures
indices (list): Optional list of indices to use when generating indexed signatures
ondices (list): Optional list of rotation indices to use when generating dual indexed signatures
**_: Placeholder
Returns:
sigs (list): list of qualified base64 signatures over the based in ser
"""
```
To perform a passcode rotation, the Signify Client requires both old and new passcodes and must perform the following steps:
1. Encrypted the old passcode with X25519 key generated from the new passcode.
2. Perform a partial rotation of the Client AID as described below.
3. Decrypt all salts with X25519 key from old passcode for Salty Keys, validate them against current public keys, encrypt with X25519 key from new passcode
4. Decrypt all keys with X25519 key from old passcode for Randy Keys, validate them against current public keys, encrypt with X25519 key from new passcode
5. Send all rotation event and all recrypted material in a POST request to the agent on `/agent/`
To provide post-quantum secure passcode recovery, a passcode recovery must be accompanied by partial rotation of the Client AID. This partial rotation is possible because the user will have to provide both old and new passcodes to initiate the process.
The partial rotation of the Client AID is accomplished by using the old passcode to regenerate the the prior rotation key pair called `R0` from the latest establishment event. In addition, two new key pairs are generated from the new passocde, one used for signing authority (S0) and one used for rotation authority (R1) in the new rotation event.
The public key for `S0` is used as the first signing key in the new rotation event; it is giving a fractionally weighted threshold of "1". The public key for `R0` is used as the second signing key in the new rotation event; it is giving a fractionally weighted threshold of "0". A Blake3 has is created of the public key for `R1` and is used as the next rotation key commitment.
The rotation event is signed with the private keys of both `S0` and `R0`. An example of a partial rotation event of the Client AID from above follows with its signatures:
```
{
"v": "KERI10JSON000195_",
"t": "rot",
"d": "EGTAY6x1tTbOO27LCy3poh5iW0Oa2Cq1s7wsVnj152Zi",
"i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"s": "1",
"p": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"kt": [
"1", // Threshold for key derived from NEW passcode, has full signing authority
"0" // Threshold for key derived from OLD passcode, no signing authority
],
"k": [
"DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc", // Derived from NEW passcode as salt, kidx = 0
"DHMAZEksiqGxlNKnm0pSAyMRPK1ZKyBfGV8q_B9r6pLs" // Derived from OLD passcode as salt, kidx = 1 (matches previous rotation key)
],
"nt": "1",
"n": [
"EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL" // Derived from NEW passcode as salt, kidx = 1, Blake3 Hashed
],
"bt": "0",
"br": [],
"ba": [],
"a": []
}
```
With the following attached signatures:
```
[
"AADuzJ4zU8MkLBPP8Os9UPbTvNqoQ4YDImNkTjfknWgJW25V6EmwZ59PXas0zKhxtp_dOhvkPqtqIhgarOFwt7sC",
"2AABAACRZGDB7s4hmYnt7vTYGWCawhnqHndWUy_rtR_L8mfNmrJ4N5S05wAZ6w5RoL68h1HjIzO7ZuiF30XBz1cC6eUA"
]
```
The first signature satisfies the current signing threshold and has only one index, 0 for signing key index. The second signature satifies the prior rotation threshold and thus uses dual index code to specify a current signing index of 1 and a prior signing index of 0.
The following steps are followed to accept the passcode rotation:
1. Verify and accept the Client AID rotation
2. Verify the signature on the request against the NEW signing key of the Client AID
3. Save encrypted old passcode
4. Update all Salty Key encrypted salts
5. Update all Randy Key encrypted keys
6. Delete encrypted old passcode
When each Agent Worker is loaded it will check for a saved old passcode to detect an aborted passcode rotation. If a saved encrypted old passcode is found the Agent Worker will notify the client in the response to the state call that a passcode rotation recovery is needed and lock out all other operations until it is completed successfully.
To perform a passcode rotation recovery, the Signify Client requires only the new passcode and must perform the following steps:
1. Retrieve the encrypted old passcode and decrypt it with X25519 key generated from the new passcode.
2. Perform a revised partial rotation of the Client AID where you rotate out to a new next key not new signing key.
3. Attempt to decrypt all salts with the X25519 keys from both the old and new passcode for Salty Keys
4. For any salt still encrypted with the old passcode, encrypt with X25519 key from new passcode
5. Attempt to decrypt all keys with the X25519 keys from both the old and new passcode for Randy Keys
6. Validate them against current public keys and for any key still encrypted with the old passcode, encrypt with X25519 key from new passcode
7. Send all rotation event and all recrypted material in a POST request to the agent on `/agent/`
Signify clients must sign all requests to the KERIA Admin Interface using the latest signing key of the Client AID and must expect all responses from the KERIA service be signed by the latest signing key of the Agent AID. Both request and response signing rely on the same set of HTTP headers to accomplish request/response signing.
Document `Signify-Resource` and `Signify-Timestamp` headers here.
Document the `Signature-Input` header here with link to [https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html](https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html)
Document the signing method and `Signature` header.
---
title: 2022 02 07 Verifiable LEI (VLEI) Ecosystem Information Trust Policies Prep 1.0 Publication V0.1 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-02-07_verifiable-LEI-(vLEI)-Ecosystem-Information-Trust-Policies-Prep-1.0-Publication_v0.1_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-02-07_verifiable-LEI-(vLEI)-Ecosystem-Information-Trust-Policies-Prep-1.0-Publication_v0.1_work.md
---
---
title: 2022 02 07 Vlei Q A V1.1 Final
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-02-07_vlei-q-a_v1.1-final
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-02-07_vlei-q-a_v1.1-final.md
---
---
title: 2022 10 28 Qualified VLEI Issuer VLEI Identifer Credential GF Prep 1.0 Publication V0.9 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-10-28_Qualified-vLEI-Issuer-vLEI-Identifer-Credential-GF-Prep-1.0-Publication_v0.9_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-10-28_Qualified-vLEI-Issuer-vLEI-Identifer-Credential-GF-Prep-1.0-Publication_v0.9_work.md
---
---
title: 2022 11 01 GLEIF Identifier GF Prep 1.0 Publication V0.6 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-01_GLEIF-Identifier-GF-Prep-1.0-Publication_v0.6_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-01_GLEIF-Identifier-GF-Prep-1.0-Publication_v0.6_work.md
---
---
title: 2022 11 22 Legal Entity VLEI Credential GF Prep 1.0 Publication V0.12 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-22_Legal-Entity-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-22_Legal-Entity-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work.md
---
---
title: 2022 11 23 Legal Entity Engagement Context Role VLEI Credential GF Prep 1.0 Publication V0.12 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-23_Legal-Entity-Engagement-Context-Role-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-23_Legal-Entity-Engagement-Context-Role-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work.md
---
---
title: 2022 11 23 Legal Entity Official Organizational Role VLEI Credential GF Prep 1.0 Publication V0.12 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-23_Legal-Entity-Official-Organizational-Role-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-23_Legal-Entity-Official-Organizational-Role-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work.md
---
---
title: 1
Introduction
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-30_Legal-Entity-QVI-AUTH-vLEI-Credential-GF-Prep-1.0-Publication_v0.6_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-11-30_Legal-Entity-QVI-AUTH-vLEI-Credential-GF-Prep-1.0-Publication_v0.6_work.md
---
# 1
Introduction
---
title: 1
Related Specifications
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-01_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part 3-vLEI-Credential-Schema-Registry-Prep-1.0-Publication_v0.1_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-01_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part 3-vLEI-Credential-Schema-Registry-Prep-1.0-Publication_v0.1_work.md
---
# 1
Related Specifications
---
title: 2022 12 06 Appendix 1 Non Disclosure Agreement V1.0 Final
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_appendix-1-non-disclosure-agreement_v1.0_final
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_appendix-1-non-disclosure-agreement_v1.0_final.md
---
---
title: 2022 12 06 Appendix 2 Vlei Issuer Qualification Program Manual V1.0 Final
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_appendix-2-vlei-issuer-qualification-program-manual_v1.0_final
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_appendix-2-vlei-issuer-qualification-program-manual_v1.0_final.md
---
---
title: 2022 12 06 Appendix 3 Vlei Issuer Qualification Program Checklist V1.0 Final
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_appendix-3-vlei-issuer-qualification-program-checklist_v1.0_final
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_appendix-3-vlei-issuer-qualification-program-checklist_v1.0_final.md
---
---
title: 2022 12 06 Appendix 4 Vlei Issuer Contact Details V1.0 Final
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final.md
---
---
title: 2022 12 06 Verifiable LEI (VLEI) Ecosystem Governance Framework Technical Requirements Part1 KERI Infrastructure Prep 1.0 Publication V0.6 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part1-KERI-Infrastructure-Prep-1.0-Publication_v0.6_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part1-KERI-Infrastructure-Prep-1.0-Publication_v0.6_work.md
---
---
title: 2022 12 06 Verifiable LEI (VLEI) Ecosystem Governance Framework Technical Requirements Part2 VLEI Credentials V0.3 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part2-vLEI-Credentials_v0.3_work
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-06_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part2-vLEI-Credentials_v0.3_work.md
---
---
title: 2022 12 16 Legal Entity QVI AUTH VLEI Credential Governance Framework V1.0 Final
source_url:
html: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-16_Legal-Entity-QVI-AUTH-vLEI-Credential-Governance-Framework_v1.0_final
md: https://weboftrust.github.io/WOT-terms/_gleif/2022-12-16_Legal-Entity-QVI-AUTH-vLEI-Credential-Governance-Framework_v1.0_final.md
---
---
title: Glossary Digital.Govt.Nz
source_url:
html: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-digital.govt.nz
md: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-digital.govt.nz.md
---
---
title: Glossary Essiflab
source_url:
html: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-essiflab
md: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-essiflab.md
---
---
title: Glossary Nist
source_url:
html: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-nist
md: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-nist.md
---
---
title: Glossary Toip
source_url:
html: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-toip
md: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-toip.md
---
---
title: Glossary Toipdidweb
source_url:
html: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-toipdidweb
md: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-toipdidweb.md
---
---
title: Glossary W3cdid
source_url:
html: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-w3cdid
md: https://weboftrust.github.io/WOT-terms/_glossaries-external/glossary-w3cdid.md
---
---
title: Cheat Sheet Writing Page
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/cheat-sheet-writing-page
md: https://weboftrust.github.io/WOT-terms/_how-we-did/cheat-sheet-writing-page.md
---
---
title: Check And Accept Pr Production Edusite Locally
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/check-and-accept-pr-production-edusite-locally
md: https://weboftrust.github.io/WOT-terms/_how-we-did/check-and-accept-pr-production-edusite-locally.md
---
---
title: Create Omnigraffle Infographic And Convert To Svg
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/create-omnigraffle-infographic-and-convert-to-svg
md: https://weboftrust.github.io/WOT-terms/_how-we-did/create-omnigraffle-infographic-and-convert-to-svg.md
---
---
title: Create Search Index
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/create-search-index
md: https://weboftrust.github.io/WOT-terms/_how-we-did/create-search-index.md
---
---
title: Create Terms Link Table
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/create-terms-link-table
md: https://weboftrust.github.io/WOT-terms/_how-we-did/create-terms-link-table.md
---
---
title: Docusaurus Process
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/docusaurus-process
md: https://weboftrust.github.io/WOT-terms/_how-we-did/docusaurus-process.md
---
---
title: Edit Metadata
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/edit-metadata
md: https://weboftrust.github.io/WOT-terms/_how-we-did/edit-metadata.md
---
---
title: Embed Github Hosted Image In Github Wiki Page
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/embed-github-hosted-image-in-github-wiki-page
md: https://weboftrust.github.io/WOT-terms/_how-we-did/embed-github-hosted-image-in-github-wiki-page.md
---
---
title: File System
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/file-system
md: https://weboftrust.github.io/WOT-terms/_how-we-did/file-system.md
---
---
title: Fill Out Terms Toip Wiki
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/fill-out-terms-toip-wiki
md: https://weboftrust.github.io/WOT-terms/_how-we-did/fill-out-terms-toip-wiki.md
---
---
title: Install Project Kerisse
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/install-project-kerisse
md: https://weboftrust.github.io/WOT-terms/_how-we-did/install-project-kerisse.md
---
---
title: KERI Suite Glossary
description: This is the KERI Suite Glossary.
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/intro
md: https://weboftrust.github.io/WOT-terms/_how-we-did/intro.md
---
# KERI Suite Glossary
This is the KERI Suite Glossary.
Also take a look at:
- [KERIDoc – Documentation](https://weboftrust.github.io/keridoc/)
- [KERISSE – Search engine](https://weboftrust.github.io/kerisse/)
---
title: Ip Rights Scraping
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/ip-rights-scraping
md: https://weboftrust.github.io/WOT-terms/_how-we-did/ip-rights-scraping.md
---
---
title: Javascript Jsdoc
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/javascript-jsdoc
md: https://weboftrust.github.io/WOT-terms/_how-we-did/javascript-jsdoc.md
---
---
title: Kerific Browser Extension
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/kerific-browser-extension
md: https://weboftrust.github.io/WOT-terms/_how-we-did/kerific-browser-extension.md
---
---
title: Kerific Discord Bot
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/kerific-discord-bot
md: https://weboftrust.github.io/WOT-terms/_how-we-did/kerific-discord-bot.md
---
---
title: Load Glossary Weboftrust In Docusaurus
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/load-glossary-weboftrust-in-docusaurus
md: https://weboftrust.github.io/WOT-terms/_how-we-did/load-glossary-weboftrust-in-docusaurus.md
---
---
title: Organization Of Github Action Scripts
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/organization-of-Github-Action-scripts
md: https://weboftrust.github.io/WOT-terms/_how-we-did/organization-of-Github-Action-scripts.md
---
---
title: Overrides
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/overrides
md: https://weboftrust.github.io/WOT-terms/_how-we-did/overrides.md
---
---
title: Typesense Search Install Config
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/typesense-search-install-config
md: https://weboftrust.github.io/WOT-terms/_how-we-did/typesense-search-install-config.md
---
---
title: Why Terms Wot Manage Structure
source_url:
html: https://weboftrust.github.io/WOT-terms/_how-we-did/why-terms-wot-manage-structure
md: https://weboftrust.github.io/WOT-terms/_how-we-did/why-terms-wot-manage-structure.md
---
---
title: access-controlled-interaction
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/access-controlled-interaction
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/access-controlled-interaction.md
---
# access-controlled-interaction
Access controlled actions like submitting a report. If you already have that report then load balancer needs a mechanism to drop repeated requests.
Source: Samuel Smith / Daniel Hardman / Lance Byrd - Zoom meeting KERI Suite Jan 16 2024; discussion minute 30-60 min
Replay attacks are less of a concern, other than DDoS attack using resubmissions.
[Registration Interaction](https://weboftrust.github.io/WOT-terms/docs/glossary/registration-interaction.md)
---
title: ACDC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ACDC
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ACDC.md
---
# ACDC
[authentic chained data container](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md)
---
title: ADC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ADC
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ADC.md
---
# ADC
[Authentic data container](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-data-container.md)
---
title: ADR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ADR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ADR.md
---
# ADR
[Architectural Decision Record](https://weboftrust.github.io/WOT-terms/docs/glossary/architectural-decision-record.md)
---
title: agency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/agency
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/agency.md
---
# agency
Agents can be people, edge computers and the functionality within [wallets](https://github.com/trustoverip/acdc/wiki/_new#digital-identity-wallet). The service an agent offers is [agency](https://weboftrust.github.io/WOT-terms/docs/glossary/agency.md).
---
title: custodial-agent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/agent
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/agent.md
---
# custodial-agent
An [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) owned by an individual who has granted [signing authority](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-authority.md) to a custodian who is usually also the host of the running agent software. Using [partial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md) to facilitate custodial key management the owner of the identifier retains [rotational authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md) and thus the ability to "fire" the custodian at any time without requiring the cooperation of the custodian.
Custodial Agents are important for individuals who may not be comfortable managing their own [signing keys](https://weboftrust.github.io/WOT-terms/docs/glossary/digital-signature.md) and agent software but still want to participate in a decentralized identity ecosystem and they enable a software as a service business model without centralizing control on the service provider.
(Source: Philip Feairheller)
Since ninety-nine percent of people in the world might not feel comfortable taking responsibility for their own practical [key management](https://weboftrust.github.io/WOT-terms/docs/glossary/key-management.md) but still want to be stay in control over their assets and be able to hire and fire service providers, this functionality is considered a key feature for KERI and ACDC.
---
title: SAID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/AID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/AID.md
---
# SAID
[Self-addressing identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md)
---
title: ambient-verifiability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ambient-verifiability
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ambient-verifiability.md
---
# ambient-verifiability
Verifiable by anyone, anywhere, at anytime. Although this seems a general term, it was first used in the context of KERI by Sam Smith.
_Ambient Duplicity Detection_ is an example of ambient verifiability that describes the possibility of detecting duplicity by anyone, anywhere, anytime.
As soon as you limit any of the parameters of location, time or who can verify, it's not 'ambient verifiability' anymore. For a signature to be ambiently verifiable, it needs to have no restrictions on these parameters.
---
title: ample
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ample
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ample.md
---
# ample
The minimum required number of participants in an event to have a [supermajority](https://weboftrust.github.io/WOT-terms/docs/glossary/supermajority.md) so that one and only one agreement or consensus on an event may be reached. This is a critical part of the [KAACE](https://weboftrust.github.io/WOT-terms/docs/glossary/KAACE.md) agreement algorithm (consensus) in KERI for establishing consensus between witnesses on the key state of a KERI identifier.
This consensus on key state forms the basis for accountability for a KERI controller, or what a person who controls a KERI identifier may be held legally responsible for.
This supermajority is also called a _sufficient majority_ that is labeled _immune_ from certain kinds of attacks or faults.
From section **11.4.2.4 Immune** of v2.60 of the KERI whitepaper,
> Satisfaction of this constraint guarantees that at most one sufficient agreement occurs or none at all despite a dishonest controller but where at most F of the witnesses are potentially faulty.
Ample Agreement Constraint:
Can apply to either
1) a group of KERI witnesses for a witnessed event or 2) a group of KERI identifier controllers participating in a multi-signature group.
Ample witnesses avoids problems of accidental lockout from a multisig group which would occur if the signing threshold for the multisig group was set lower than the "ample" number of participants.
N = Number of total participants
M = Number of participants needed to get the guarantees of "ample"
Python code implementation from [keri.core.eventing.py](https://github.com/WebOfTrust/keripy/blob/development/src/keri/core/eventing.py) of the `ample` algorithm used in [KAACE](https://weboftrust.github.io/WOT-terms/docs/glossary/KAACE.md):
```
def ample(n, f=None, weak=True):
"""
Returns int as sufficient immune (ample) majority of n when n >=1
otherwise returns 0
Parameters:
n is int total number of elements
f is int optional fault number
weak is Boolean
If f is not None and
weak is True then minimize m for f
weak is False then maximize m for f that satisfies n >= 3*f+1
Else
weak is True then find maximum f and minimize m
weak is False then find maximum f and maximize m
n,m,f are subject to
f >= 1 if n > 0
n >= 3*f+1
(n+f+1)/2 <= m <= n-f
"""
n = max(0, n) # no negatives
if f is None:
f1 = max(1, max(0, n - 1) // 3) # least floor f subject to n >= 3*f+1
f2 = max(1, ceil(max(0, n - 1) / 3)) # most ceil f subject to n >= 3*f+1
if weak: # try both fs to see which one has lowest m
return min(n, ceil((n + f1 + 1) / 2), ceil((n + f2 + 1) / 2))
else:
return min(n, max(0, n - f1, ceil((n + f1 + 1) / 2)))
else:
f = max(0, f)
m1 = ceil((n + f + 1) / 2)
m2 = max(0, n - f)
if m2 < m1 and n > 0:
raise ValueError("Invalid f={} is too big for n={}.".format(f, n))
if weak:
return min(n, m1, m2)
else:
return min(n, max(m1, m2))
```
---
title: APC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/APC
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/APC.md
---
# APC
[Authentic provenance chain](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-provenance-chain.md)
---
title: KAPI
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/API
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/API.md
---
# KAPI
Application programmer interfaces (APIs) for the various components in the KERI ecosystem such as Controllers, Agents, Witnesses, Watchers, Registrars etc need by which they can share information. The unique properties of the KERI protocol require APIs that preserve those properties. We call the set of APIs the KERI API.
[Source Kapi Repo](https://github.com/WebOfTrust/kapi/blob/main/kapi.md)
---
title: append-only-event-logs
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/append-only-event-logs
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/append-only-event-logs.md
---
# append-only-event-logs
Append-only is a property of computer data storage such that new data can be appended to the storage, but where existing data is immutable.
A blockchain is an example of an append-only log. The events can be transactions. Bitcoin is a well-known Append only log where the events are _totally ordered_ and signed transfers of control over unspent transaction output.
More on [Wikipedia](https://en.wikipedia.org/wiki/Append-only)
---
title: application-programming-interface
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/application-programming-interface
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/application-programming-interface.md
---
# application-programming-interface
An application programming interface (API) is a way for two or more [computer programs](https://en.wikipedia.org/wiki/Computer_program) to communicate with each other. It is a type of software [interface](https://en.wikipedia.org/wiki/Interface_\(computing\)), offering a service to other pieces of [software](https://en.wikipedia.org/wiki/Software).
A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term [API](https://weboftrust.github.io/WOT-terms/docs/glossary/API.md) may refer either to the specification or to the implementation.
More on [source](https://en.wikipedia.org/wiki/API) Wikipedia.
---
title: architectural-decision-record
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/architectural-decision-record
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/architectural-decision-record.md
---
# architectural-decision-record
Is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant.
[Source adr.github.io](https://adr.github.io/)
---
title: attributional-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/attributional-trust
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/attributional-trust.md
---
# attributional-trust
KERI offers cryptographic root-of-trust to establish attributional trust. In the real world you'd also need [reputational trust](https://weboftrust.github.io/WOT-terms/docs/glossary/reputational-trust.md). You can't have reputation without attributional trust.
Read more in source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf)
[Out-of-band Introduction](https://weboftrust.github.io/WOT-terms/docs/glossary/out-of-band-introduction.md)s (OOBIs) to establish attributional trust, like its done with OOBIs in KERI, is not the same as the high friction costs of establishing reputational trust by going through the heavy lifting of [identity assurance](https://weboftrust.github.io/WOT-terms/docs/glossary/identity-assurance.md) by a to be trusted middle-men party, like [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md).
---
title: authentic-chained-data-container
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-chained-data-container
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-chained-data-container.md
---
# authentic-chained-data-container
a directed acyclic graph with properties to provide a verifiable chain of [proof-of-authorship](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authorship.md). See the full [specification](https://trustoverip.github.io/tswg-acdc-specification/)
Source: Dr. S.Smith, 2024
Explained briefly, an ACDC or [ADC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-data-container.md) proves digital data consistency and authenticity in one go. An ACDC cryptographically secures commitment to the data contained, and its identifiers are self-addressing, which means they point to themselves and are also contained in the data.
---
title: authentic-data-container
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-data-container
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-data-container.md
---
# authentic-data-container
A mechanism for conveying data that allows the [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) of its content to be proved.
**Instance**
A [Verifiable Credential](https://w3.org/TR/vc-data-model/) is an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md).
---
title: authentic-data
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-data
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-data.md
---
# authentic-data
[Integer](https://weboftrust.github.io/WOT-terms/docs/glossary/integrity.md) and [Provenanced](https://weboftrust.github.io/WOT-terms/docs/glossary/provenance.md) data.
Source: Timothy Ruff, #IIW37
---
title: authentic-provenance-chain
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-provenance-chain
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-provenance-chain.md
---
# authentic-provenance-chain
Interlinked [presentations](https://weboftrust.github.io/WOT-terms/docs/glossary/presentation-exchange.md) of evidence that allow data to be tracked back to its origin in an objectively [verifiable](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable.md) way.
---
title: authentic-web
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-web
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authentic-web.md
---
# authentic-web
The authentic web is the internet as a whole giant verifiable data structure. Also called _Web5_. The web will be one big graph. That's the mental model of the 'authentic web'.
- `Signed at rest` - the data never throws away any signature of data. Because otherwise we can't validate data in the future
- `Key state at rest` - you need to solve this hard problem too. This is the hard problem [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) solves.
- `Signed in motion` - signatures get thrown away. You use ephemeral identifiers. You have to do everything anew every time you want to reconstruct a verifiable data structure. Therefore we need 'Signed at rest'.
- You can append to any part of the (directed-acyclic) [graph](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md)
- You can hop into the graph to verify any fragment of the graph
- You don't have to sign the data,you just have to sign hashes of this data
- Every tree that gets integrated in this giant graph-forest has its own [Root of Trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md)
KERI solves all hard problems of the authentic web in a scalable manner.
See more in [Concepts](https://weboftrust.github.io/keridoc/docs/concepts/concepts?level=2) behind KERI
---
title: authenticity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authenticity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authenticity.md
---
# authenticity
The quality of having an objectively verifiable origin ; contrast [veracity](https://weboftrust.github.io/WOT-terms/docs/glossary/veracity.md). When a newspaper publishes a story about an event, every faithful reproduction of that story may be _authentic_ — but that does not mean the story was _true_ (has _veracity_).
Authenticity is strongly related to digital [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md). Ideally it should be [verifiable](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable.md) (to a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md)). The future picture therein is the [Authentic Web](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-web.md).
The three properties, authenticity, confidentiality, and privacy inhabit a trade space. ... One can have any two of the three (privacy, authenticity, confidentiality) at the highest level but not all three.
The trilemma insists that one must make a trade-off by prioritizing one or two properties over a third.
The ToIP [design goals](https://github.com/trustoverip/TechArch/blob/main/spec.md#61-design-goals) reflect that trade-off and provide an order of importance. The design goals indicate that one should start with high authenticity, then high confidentiality, and then as high as possible privacy, given there is no trade-off with respect to the other two.
More on [Source](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md) Samuel Smith SPAC whitepaper.
- [confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/confidentiality.md)
- [privacy](https://weboftrust.github.io/WOT-terms/docs/glossary/privacy.md)
---
title: authoritative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authoritative
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authoritative.md
---
# authoritative
Established control [authority](https://weboftrust.github.io/WOT-terms/docs/glossary/authority.md) over an identifier, that has received attestations to it, e.g. control over the identifier has been verified to its root-of-trust. So the (control over the) identifier is 'authoritative' because it can be considered accurate, renowned, honourable and / or respected.
Also used to describe [PKI](https://weboftrust.github.io/WOT-terms/docs/glossary/PKI.md) key pairs that have this feature.
1. Author: creator, [source-of-truth](https://weboftrust.github.io/WOT-terms/docs/glossary/source-of-truth.md)
2. Authentic: provable origin, [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md)
3. Authorized: consent, [loci-of-control](https://weboftrust.github.io/WOT-terms/docs/glossary/loci-of-control.md)
4. **Authoritative: accurate, reputable**
"A4" data control securely is established via [self-certifying](https://weboftrust.github.io/WOT-terms/docs/glossary/self-certifying-identifier.md) pseudonymous identifiers
[Source](https://youtu.be/L82O9nqHjRE) Samuel M. Smith
---
title: signing-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authority
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authority.md
---
# signing-authority
The authority to sign on behalf of the controller of the authoritative key pair. Often in situation where delegation has taken place, e.g. a custodial agent. These are limited rights because [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md) is not included.
The original controller of an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md) can hold exclusive [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md). Because control authority is split between two key sets, the first for signing-authority and the second ([pre-rotated](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-rotation.md)) for [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md), the associated thresholds and key list can be structured in such a way that a designated [custodial agent](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-agent.md) can hold signing authority while the original controller can hold exclusive rotation authority.
---
title: broken-object-level-authorization
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authorization
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authorization.md
---
# broken-object-level-authorization
Refers to [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) flaws where users can access data they shouldn't, due to inadequate permission checks on individual (sub)objects.
---
title: authorized-vlei-representative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authorized-vlei-representative
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/authorized-vlei-representative.md
---
# authorized-vlei-representative
Also 'AVR'. This a representative of a Legal Entity that are authorized by the [DAR](https://weboftrust.github.io/WOT-terms/docs/glossary/DAR.md) of a Legal Entity to request issuance and revocation of:
- vLEI Legal Entity Credentials
- Legal Entity Official Organizational Role vLEI Credentials ([OOR](https://weboftrust.github.io/WOT-terms/docs/glossary/official-organizational-role.md) vLEI Credentials)
- Legal Entity Engagement Context Role vLEI Credentials ([ECR](https://weboftrust.github.io/WOT-terms/docs/glossary/engagement-context-role.md) vLEI Credentials).
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: autonomic-computing-systems
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-computing-systems
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-computing-systems.md
---
# autonomic-computing-systems
Self managing computing systems using algorithmic governance, from the 90's way way way before DAOs. KERI creator Sam Smith worked at funded Navy research in the 90's on autonomic survivable systems as in "self-healing" systems: "We called them autonomic way back then".
---
title: root-autonomic-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-identifier.md
---
# root-autonomic-identifier
An entity may provide the [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) for some ecosystem (with delegation )via its root [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md). Let’s call this the _RID_ for "root AID". The RID must be protected using the highest level of [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) in its [key management](https://weboftrust.github.io/WOT-terms/docs/glossary/key-management.md).
Although through the use of a [multi-valent](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-valent.md) key management infrastructure, the entity can employ extreme protection of the RID while still enabling more performant key management infrastructure for its operations.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: autonomic-identity-system
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-identity-system
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-identity-system.md
---
# autonomic-identity-system
an identity system that includes a primary root-of-trust in self-certifying identifiers that are strongly bound at issuance to a cryptographic signing (public, private) key pair. An AIS enables any entity to establish control over an AN in an independent, interoperable, and portable way.
Source: Dr. S.Smith, 2024
There's nobody that can intervene with the establishment of the authenticity of a control operation because you can verify all the way back to the root-of-trust.
---
title: autonomic-namespace
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-namespace
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-namespace.md
---
# autonomic-namespace
a namespace that is self-certifying and hence self-administrating. An AN has a self-certifying prefix that provides cryptographic verification of root control authority over its namespace. All derived AIDs in the same AN share the same root-of-trust, source-of-truth, and locus-of-control (RSL). The governance of the namespace is, therefore, unified into one entity, that is, the controller who is/holds the root authority over the namespace.
Source: Dr. S.Smith, 2024
Namespaces are, therefore, portable and truly self-sovereign.
---
title: autonomic-trust-basis
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-trust-basis
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-trust-basis.md
---
# autonomic-trust-basis
When we use an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) as the [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) we form a so-called _autonomic trust basis_. This is diagrammed as follows:
Two other trust bases are in common use for identifier systems. One we call _algorithmic_, the other is .
An algorithmic trust basis relies on some network of nodes running some type of Byzantine fault tolerant totally ordering distributed consensus algorithm for its root-of-trust. These networks are more commonly known as a shared ledger or blockchain such as Bitcoin, Ethereum, or Sovrin
The other commonly used trust basis in identifier systems is an _administrative_ or organizational _trust basis_, i.e. a trusted entity. This is neither [secure](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) nor [decentralized](https://weboftrust.github.io/WOT-terms/docs/glossary/decentralized-identifier.md).
---
title: AVR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/AVR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/AVR.md
---
# AVR
[Authorized vLEI Representative](https://weboftrust.github.io/WOT-terms/docs/glossary/authorized-vlei-representative.md)
---
title: ledger-backer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/backer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/backer.md
---
# ledger-backer
A [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) in KERI that is ledger-registered. It's a type of [backer](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md) that proof its authenticity by a signing key anchored to the public key of a data item on a (public) blockchain.
---
title: BADA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/BADA
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/BADA.md
---
# BADA
[Best available data acceptance mechanism](https://weboftrust.github.io/WOT-terms/docs/glossary/best-available-data-acceptance-mechanism.md)
---
title: base-media-type
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/base-media-type
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/base-media-type.md
---
# base-media-type
`credential` plus `ld` plus `json`.
Other media types of credentials are allowed by must provide either unidirectional or bidirectional transformations. So, for example, we would create credential+acdc+json and provide a unidirectional transformation to credential+ld+json.
We are going for `credential` plus `acdc` plus `json` without `@context`. The main objection to use `@context` is that it can change the meaning of a credential. The other way around: ACDCs will include W3C credentials.
Media types will be used to differentiate between types of credentials and verifiable credentials.
---
title: base64
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/base64
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/base64.md
---
# base64
In [computer programming](https://en.wikipedia.org/wiki/Computer_programming), Base64 is a group of [binary-to-text encoding](https://en.wikipedia.org/wiki/Binary-to-text_encoding) schemes that represent [binary data](https://en.wikipedia.org/wiki/Binary_data) (more specifically, a sequence of 8-bit bytes) in sequences of 24 bits that can be represented by four 6-bit Base64 digits.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Base64)
---
title: bespoke-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bespoke-credential
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bespoke-credential.md
---
# bespoke-credential
It's an [issuance](https://weboftrust.github.io/WOT-terms/docs/glossary/issuance-event.md) of the disclosure or presentation of other ACDCs. _Bespoke_ means _Custom_ or _tailor made_. A bespoke credential serves as an on-the-fly contract with the issuee; it's a self-referencing and self-contained contract between the issuer and the verifier. Mind you, here the issuer and issuee are merely the discloser and disclosee of another (set of) ACDC(s).
If I want consent terms attached to a presentation of an (set of) ACDC(s).
Consider a disclosure-specific ACDC, aka tailor made, custom or bespoke. The Issuer is the Discloser, the Issuee is the Disclosee. The rule section includes a context-specific (anti) assimilation clause that limits the use of the information to a single one-time usage purpose, that is for example, admittance to a restaurant. The ACDC includes an edge that references some other ACDC that may for example be a coupon or gift card. The attribute section could include the date and place of admittance.
For the code of this example, see this [section 11.1 in Github](https://weboftrust.github.io/ietf-acdc/draft-ssmith-acdc.html#section-11.1)
We can use all the tools available for issuance and presentation we already have.
Similar to a presentation exchange, a verifier will first be asked for what they are looking for, secondly the discloser creates the dataset and publishes only the structure and the fields. To accomplish this, thirdly a compact ACDC will be issued (you publish the fields, not the content) and then issuer asks to sign it first. After signing, the disclosee can get the content associated with the on-the-fly contract.
More at [Github source](https://weboftrust.github.io/ietf-acdc/draft-ssmith-acdc.html#name-disclosure-specific-bespoke)
---
title: best-available-data-acceptance-mechanism
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/best-available-data-acceptance-mechanism
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/best-available-data-acceptance-mechanism.md
---
# best-available-data-acceptance-mechanism
The BADA security model provides a degree of [replay attack](https://weboftrust.github.io/WOT-terms/docs/glossary/replay-attack.md) protection. The attributate originator (issuer, author, source) is provided by an attached signature couple or quadruple. A single reply could have multiple originators. When used as an [authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/authorization.md) the reply attributes may include the identifier of the authorizer and the logic for processing the associated route may require a matching attachment. BADA is part of [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md)'s [Zero Trust Computing Architecture for Data Management](https://hackmd.io/Qsrfj7Y-TIGl5ESvrxWGxw): How to support Secure Async Data Flow Routing in KERI enabled Applications.
- [Run off the crud](https://weboftrust.github.io/WOT-terms/docs/glossary/run-off-the-crud.md)
- [RUN](https://weboftrust.github.io/WOT-terms/docs/glossary/read-update-nullify.md)
---
title: bexter
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bexter
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bexter.md
---
# bexter
The class variable length text that is used in CESR and preserves the round-trip transposability using Base64 URL safe-only encoding even though the text variable length.
From [readthedocs.io](https://keripy.readthedocs.io/en/latest/?badge=latest)
Bexter is subclass of Matter, cryptographic material, for variable length strings that only contain Base64 URL safe characters, i.e. Base64 text (bext).
When created using the 'bext' paramaeter, the encoded matter in qb64 format in the text domain is more compact than would be the case if the string were passed in as raw bytes. The text is used as is to form the value part of the qb64 version not including the leader.
Due to ambiguity that arises from pre-padding bext whose length is a multiple of three with one or more 'A' chars. Any bext that starts with an 'A' and whose length is either a multiple of 3 or 4 may not round trip. Bext with a leading 'A' whose length is a multiple of four may have the leading 'A' stripped when round tripping.
- Bexter(bext='ABBB').bext == 'BBB'
- Bexter(bext='BBB').bext == 'BBB'
- Bexter(bext='ABBB').qb64 == '4AABABBB' == Bexter(bext='BBB').qb64
To avoid this problem, only use for applications of base 64 strings that never start with 'A'
Examples: base64 text strings:
- bext = ""
- qb64 = '4AAA'
- bext = "-"
- qb64 = '6AABAAA-'
- bext = "-A"
- qb64 = '5AABAA-A'
- bext = "-A-"
- qb64 = '4AABA-A-'
- bext = "-A-B"
- qb64 = '4AAB-A-B'
- CESR encoded paths for nested SADs and SAIDs
- CESR encoded fractionally weighted threshold expressions
Inherited Properties: (See Matter) .pad is int number of pad chars given raw .code is str derivation code to indicate cypher suite .raw is bytes crypto material only without code .index is int count of attached crypto material by context (receipts) .qb64 is str in Base64 fully qualified with derivation code + crypto mat .qb64b is bytes in Base64 fully qualified with derivation code + crypto mat .qb2 is bytes in binary with derivation code + crypto material .transferable is Boolean, True when transferable derivation code False otherwise Properties: .text is the Base64 text value, .qb64 with text code and leader removed. Hidden: .\_pad is method to compute .pad property .\_code is str value for .code property .\_raw is bytes value for .raw property .\_index is int value for .index property .\_infil is method to compute fully qualified Base64 from .raw and .code .\_exfil is method to extract .code and .raw from fully qualified Base64 Methods: """
---
title: BFT
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/BFT
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/BFT.md
---
# BFT
[Byzantine fault tolerance](https://weboftrust.github.io/WOT-terms/docs/glossary/byzantine-fault-tolerance.md)
---
title: binding
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/binding
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/binding.md
---
# binding
The technique of connecting two data elements together. In the context of [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md) it's the association of data or an [identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md) with another identifier or a subject (a person, organization or machine), thereby lifting the privacy of the subject through that connection, i.e. **binding**.
---
title: bis
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bis
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bis.md
---
# bis
bis = backed vc issue, registry-backed transaction event log credential issuance
---
title: bivalent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bivalent
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bivalent.md
---
# bivalent
A nested set of layered delegations in a [delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md) tree, wraps each layer with compromise recovery protection of the next higher layer. This maintains the security of the root layer for compromise recovery all the way out to the leaves in spite of the leaves using less secure key management methods.
To elaborate, in a [cooperative delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/cooperative-delegation.md), the key generation and storage functions of the delegator and delegate, in terms of controlling private keys, may be completely isolated from each other. This means that each may use its own independent key management infrastructure with no movement of private keys between the two infrastructures. We call this a **bivalent** key management infrastructure.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
[Multivalent](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-valent.md) [Univalent](https://weboftrust.github.io/WOT-terms/docs/glossary/univalent.md)
---
title: blake3
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/blake3
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/blake3.md
---
# blake3
BLAKE3 is a relatively young (2020) cryptographic hash function based on Bao and BLAKE2.
BLAKE3 is a single algorithm with many desirable features (parallelism, XOF, KDF, PRF and MAC), in contrast to BLAKE and BLAKE2, which are algorithm families with multiple variants. BLAKE3 has a [binary tree](https://en.wikipedia.org/wiki/Binary_tree) structure, so it supports a practically unlimited degree of parallelism (both SIMD and multithreading) given long enough input.
The official [Rust](https://en.wikipedia.org/wiki/Rust_\(programming_language\)) and [C](https://en.wikipedia.org/wiki/C_\(programming_language\)) implementations[\[24\]](https://en.wikipedia.org/wiki/BLAKE_\(hash_function\)?wprov=srpw1_0#cite_note-BLAKE3-repo-24) are [dual-licensed](https://en.wikipedia.org/wiki/Multi-licensing) as public domain ([CC0](https://en.wikipedia.org/wiki/CC0)) and the [Apache License](https://en.wikipedia.org/wiki/Apache_License).
BLAKE3 is designed to be as fast as possible. It is consistently a few times faster than BLAKE2. The BLAKE3 compression function is closely based on that of BLAKE2s, with the biggest difference being that the number of rounds is reduced from 10 to 7, a change based on the assumption that current cryptography is too conservative. In addition to providing parallelism, the Merkle tree format also allows for verified streaming (on-the-fly verifying) and incremental updates.
---
title: blind-oobi
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/blind-oobi
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/blind-oobi.md
---
# blind-oobi
A blind [OOBI](https://weboftrust.github.io/WOT-terms/docs/glossary/OOBI.md) means that you have some mechanisms in place for verifying the [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) instead of via the OOBI itself. A blind OOBI is essentially a [URL](https://weboftrust.github.io/WOT-terms/docs/glossary/URL.md). It's called "blind" because the witness is not in the OOBI itself. You haves other ways of verifying the AID supplied.
A blind OOBI through an AID that is on some witness list and has been verified to root-of-trust already. So you know the human being behind this referred AID. Because it's an AID that has a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md) out there, which has been securely established, you can trust it. So a blind OOBI makes a via-via commitment.
A natural person that you trust is an owner of an AID. Then you cryptographically commit this AID to another AID through some mechanism (e.g. a witness list).
> "Here's my public key and here's my AID and because this in an another witness list I trust it."
A 'blind' AID becomes "unblind" when you establish a direct relationship with human being who controls the referenced AID. You shortcut the blind OOBI because you established a direct OOBI to the formerly reference AID.
type 2 authentication: minimise the friction | TBW prio 3 |
Authentication by reference, latent authenticity
---
title: blinded-revocation-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/blinded-revocation-registry
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/blinded-revocation-registry.md
---
# blinded-revocation-registry
The current state of a [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) (TEL) **may be hidden or blinded** such that _the only way_ for a potential verifier of the state to observe that state is _when the controller of a designated AID discloses it_ at the time of presentation.
| TBW: BE CAREFUL WITH THE REST, JUST TEXT SNIPPETS TYPED IN FROM A CONVERSATION |
No information can be obtained via a [rainbow table attack](https://weboftrust.github.io/WOT-terms/docs/glossary/rainbow-table-attack.md) because the hash has enough [entropy](https://weboftrust.github.io/WOT-terms/docs/glossary/entropy.md) added to it.
| TBW | on the basis of the last half hour of the recording ACDC meetup Dec 6 }
The issuer creates and signs the bulk issuance set of credentials and shares a salt with the presenters. The shared salt correlates between the issuer and the issuee, but that is the worst problem we have to consider, which is acceptable.
See more in the section [blindable state tel](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#blindable-state-tel)
The presenter does the decomposition in a way that allows a verifier to conclude: "Yes that was an approved schema issued by the issuer!"
---
title: BOLA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/BOLA
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/BOLA.md
---
# BOLA
[Broken Object Level Authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/broken-object-level-authorization.md)
---
title: bran
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bran
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/bran.md
---
# bran
A cryptographic string used as a primary input, a seed, for creating key material for and [autonomic-identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md).
This is used in Signify TS:
- `Controller` [constructor argument](https://github.com/WebOfTrust/signify-ts/blob/516539f8bb68c8504e10221bf144a54b8c507dc3/src/keri/app/controller.ts#L104C77-L104C89)
```
constructor(bran: string, tier: Tier, ridx: number = 0, state: any | null = null) {
this.bran = MtrDex.Salt_128 + 'A' + bran.substring(0, 21) // qb64 salt for seed
this.stem = "signify:controller"
this.tier = tier
this.ridx = ridx
this.salter = new Salter({ qb64: this.bran, tier: this.tier })
...
```
Quote, a Zoom chat message, from Dr. Sam Smith on 8/22/23 in the Tuesday morning KERI & ACDC ToIP specification discussion call:
> We already use seed and salt for something else so bran is related to seed so we used a term that was evocative of its use but not conflict with already used seed
---
title: branch
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/branch
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/branch.md
---
# branch
In software development a 'branch' refers to the result of branching: the duplication of an object under version control for further separate modification.
Branching, in [version control](https://en.wikipedia.org/wiki/Version_control) and [software configuration management](https://en.wikipedia.org/wiki/Software_configuration_management), is the duplication of an object under version control (such as a [source code](https://en.wikipedia.org/wiki/Source_code) file or a [directory tree](https://en.wikipedia.org/wiki/Directory_tree)). Each object can thereafter be modified separately and in parallel so that the objects become different. In this context the objects are called branches. The users of the version control system can branch any branch.
---
title: broken-object-level-authorization
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/broken-object-level-authorization
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/broken-object-level-authorization.md
---
# broken-object-level-authorization
Refers to [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) flaws where users can access data they shouldn't, due to inadequate permission checks on individual (sub)objects.
---
title: brv
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/brv
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/brv.md
---
# brv
brv = backed vc revoke, registry-backed transaction event log credential revocation
---
title: byzantine-agreement
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/byzantine-agreement
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/byzantine-agreement.md
---
# byzantine-agreement
(non PoW) Byzantine Agreement is [Byzantine fault tolerance](https://weboftrust.github.io/WOT-terms/docs/glossary/byzantine-fault-tolerance.md) of distributed computing systems that enable them to come to consensus despite arbitrary behavior from a fraction of the nodes in the network. BA consensus makes no assumptions about the behavior of nodes in the system. Practical Byzantine Fault Tolerance (pBFT) is the prototypical model for Byzantine agreement, and it can reach consensus fast and efficiently while concurrently decoupling consensus from resources (i.e., financial stake in PoS or electricity in PoW).
[More](https://blockonomi.com/stellar-consensus-protocol/) about the Stellar consensus protocol
```
"What if PBFT and Stellar had a baby?
that was missing liveness and total ordering
but had safety and was completely decentralized, portable, and permission-less?
It would be named KERI."
SamMSmith
```
---
title: byzantine-fault-tolerance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/byzantine-fault-tolerance
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/byzantine-fault-tolerance.md
---
# byzantine-fault-tolerance
A Byzantine fault (also interactive consistency, source congruency, error avalanche, [Byzantine agreement](https://weboftrust.github.io/WOT-terms/docs/glossary/byzantine-agreement.md) problem, Byzantine generals problem, and Byzantine failure) is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed.
The term takes its name from an allegory, the "Byzantine Generals Problem", developed to describe a situation in which, in order to avoid catastrophic failure of the system, the system's actors must agree on a concerted strategy, but some of these actors are unreliable. In a Byzantine fault, a component such as a server can inconsistently appear as both failed and functioning to failure-detection systems, presenting different symptoms to different observers. It is difficult for the other components to declare it failed and shut it out of the network because they need first to reach a consensus regarding which component has failed in the first place. Byzantine fault tolerance (BFT) is the dependability of a fault-tolerant computer system to such conditions.
A system has Byzantine Fault Tolerance (BFT) when it can keep functioning correctly as long as two-thirds of the network agrees or reaches a consensus. BFT is a property or characteristic of a system that can resist up to one-third of the nodes failing or acting maliciously.
The pBFT model primarily focuses on providing a practical Byzantine state machine replication that tolerates Byzantine faults (malicious nodes) through an assumption that there are independent node failures and manipulated messages propagated by specific, independent nodes. The algorithm is designed to work in asynchronous systems and is optimized to be high-performance with an impressive overhead runtime and only a slight increase in latency. More on Wikipedia about
- [Byzantine Fault](https://en.wikipedia.org/wiki/Byzantine_fault)
- [pBFT](https://en.bitcoinwiki.org/wiki/PBFT) : An article that explains practical BFT.
- [Here](https://blockonomi.com/practical-byzantine-fault-tolerance/)'s a complete beginners guide.
---
title: CBOR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CBOR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CBOR.md
---
# CBOR
[Concise Binary Object Representation](https://weboftrust.github.io/WOT-terms/docs/glossary/concise-binary-object-representation.md)
---
title: certificate-transparency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/certificate-transparency
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/certificate-transparency.md
---
# certificate-transparency
Certificate Transparency (CT) is an Internet security standard and open source framework for monitoring and auditing digital certificates. The standard creates a system of public logs that seek to eventually record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates. As of 2021, Certificate Transparency is mandatory for all SSL/TLS certificates.
Certificate Transparency was a response to the 2011 attack on DigiNotar and other Certificate Authorities. These attacks showed that the lack of transparency in the way CAs operated was a significant risk to the Web Public Key Infrastructure. It led to the creation of this ambitious project to improve security online by bringing accountability to the system that protects HTTPS.
More on [certificate.transparency.dev](https://certificate.transparency.dev/) and [Wikipedia](https://en.wikipedia.org/wiki/Certificate_Transparency).
---
title: cesr-proof-signatures
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cesr-proof-signatures
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cesr-proof-signatures.md
---
# cesr-proof-signatures
CESR Proof Signatures is an extension to the Composable Event Streaming Representation \[CESR\] that provides transposable cryptographic signature attachments on self-addressing data [(SAD)](https://weboftrust.github.io/WOT-terms/docs/glossary/SAD.md). Any SAD, such as an Authentic Chained Data Container (ACDC) Verifiable Credential \[ACDC\], for example, may be signed with a CESR Proof Signature and streamed along with any other CESR content. In addition, a signed SAD can be embedded inside another SAD, and the CESR proof signature attachment can be transposed across envelope boundaries and streamed without losing any cryptographic integrity.
(Philip Feairheller, IETF-cesr-proof)
---
title: CESR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CESR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CESR.md
---
# CESR
[composable event streaming representation](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md)
---
title: cesride
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cesride
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cesride.md
---
# cesride
is concerned with parsing CESR primitives.
Cesride is built from cryptographic primitives that are named clearly and concisely. There are:
- [Diger](https://weboftrust.github.io/WOT-terms/docs/glossary/diger.md)
- [Verfer](https://weboftrust.github.io/WOT-terms/docs/glossary/verfer.md)
- [Signer](https://weboftrust.github.io/WOT-terms/docs/glossary/signer.md)
- [Siger](https://weboftrust.github.io/WOT-terms/docs/glossary/siger.md)
- [Cigar](https://weboftrust.github.io/WOT-terms/docs/glossary/cigar.md)
- [Salter](https://weboftrust.github.io/WOT-terms/docs/glossary/salter.md)
Each primitive will have methods attached to it that permit one to generate and parse the qualified base2 or [base64](https://weboftrust.github.io/WOT-terms/docs/glossary/base64.md) representation.
Common methods you'll find:
- `.qb64()` - qualified base-64 representation of cryptographic material as a string
- `.qb64b()` - qualified base-64 representation of cryptographic material as octets (bytes)
- `.qb2()` - qualified base-2 representation of cryptographic material as octets (bytes)
- `.code()` - qualifying code (describes the type of cryptographic material)
- `.raw()` - raw cryptographic material (unqualified) as octets (bytes)
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
[Parside](https://weboftrust.github.io/WOT-terms/docs/glossary/parside.md)
---
title: chain-link-confidentiality
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/chain-link-confidentiality
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/chain-link-confidentiality.md
---
# chain-link-confidentiality
Chains together a sequence of [Disclosees](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md) which may also include a set of constraints on data usage by both second and third parties expressed in legal language such that the constraints apply to all recipients of the disclosed data thus the phrase "chain link" confidentiality. Each Disclosee in the sequence in turn is the [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) to the next Disclosee.
This is the primary mechanism of granting digital data rights through binding information exchange to confidentiality laws. Confidentiality is dynamically negotiated on a per-event, per-data exchange basis according to the data that is being shared in a given exchange.
Disclosures via [Presentations Exchanges](https://weboftrust.github.io/WOT-terms/docs/glossary/presentation-exchange.md) may be contractually protected by Chain-Link Confidentiality (i.e. a Chain-Link Confidential disclosure). The chaining in this case is different from the chaining described above between Issuances in a [DAG](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) of chained Issuances. Chain-link confidentiality, in contrast, chains together a sequence of Disclosees.
More info at [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#chain-link-confidentiality)
An important article on the topic can be found here:
[Woodrow Hartzog “Chain-Link Confidentiality”](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818)
---
title: chain-of-custody
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/chain-of-custody
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/chain-of-custody.md
---
# chain-of-custody
From Wikipedia ([Source](https://en.wikipedia.org/wiki/Chain_of_custody)): Chain of custody (CoC), in legal contexts, is the chronological documentation or [paper trail](https://en.wiktionary.org/wiki/paper_trail) that records the sequence of custody, control, transfer, analysis, and disposition of materials, including physical or electronic [evidence](https://en.wikipedia.org/wiki/Evidence). Of particular importance in criminal cases, the concept is also applied in civil litigation and more broadly in drug testing of athletes and in [supply chain management](https://en.wikipedia.org/wiki/Supply_chain_management), e.g. to improve the [traceability](https://en.wikipedia.org/wiki/Traceability) of food products, or to provide assurances that wood products originate from [sustainably managed forests](https://en.wikipedia.org/wiki/Sustainable_forest_management).
It is often a tedious process that has been required for evidence to be shown legally in court. Now, however, with new portable technology that allows accurate laboratory quality results from the scene of the crime, the chain of custody is often much shorter which means evidence can be processed for court much faster.
([Source](https://en.wikipedia.org/wiki/Chain_of_custody))
---
title: cigar
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cigar
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cigar.md
---
# cigar
An **_un_**[indexed signature](https://weboftrust.github.io/WOT-terms/docs/glossary/indexed-signature.md).
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: claim
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/claim
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/claim.md
---
# claim
An assertion of the truth of something, typically one which is disputed or in doubt. A set of claims might convey personally identifying information: name, address, date of birth and citizenship, for example. ([Source](https://www.identityblog.com/?p=352)).
---
title: CLC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CLC
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CLC.md
---
# CLC
[Chain link confidential](https://weboftrust.github.io/WOT-terms/docs/glossary/chain-link-confidentiality.md)
---
title: clone
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/clone
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/clone.md
---
# clone
A copy of a system that is - and works exactly as the original
In [computing](https://en.wikipedia.org/wiki/Computing), a clone is [hardware](https://en.wikipedia.org/wiki/Computer_hardware) or [software](https://en.wikipedia.org/wiki/Software) that is designed to function in exactly the same way as another system.
A specific subset of clones are remakes (or remades), which are revivals of old, obsolete, or discontinued products.
[Source Wikipedia](https://en.wikipedia.org/wiki/Clone_\(computing\))
---
title: cloud-agent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cloud-agent
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cloud-agent.md
---
# cloud-agent
Cloud agent is software that is installed on the cloud server instances in order to provide security, monitoring, and analysis solutions for the cloud. They actually provide information and helps to provide control over cloud entities.
_Paraphrased by @henkvancann based on [source](https://www.cloudopedia.com/cloud-agent/)_.
Also see [Agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md).
Cloud computing[\[1\]](https://en.wikipedia.org/wiki/Cloud_computing?wprov=srpw1_1#cite_note-urlAn_Introduction_to_Dew_Computing:_Definition''',_Concept_and_Implications_-_IEEE_Journals_&_Magazine-1) is the on-demand availability of [computer](https://en.wikipedia.org/wiki/Computer) [system resources](https://en.wikipedia.org/wiki/System_resource), especially data storage ([cloud storage](https://en.wikipedia.org/wiki/Cloud_storage)) and [computing power](https://en.wikipedia.org/wiki/Computing_power), without direct active management by the user.
[More](https://en.wikipedia.org/wiki/Cloud_computing) at source on Wikipedia
---
title: code-table-selector
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/code-table-selector
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/code-table-selector.md
---
# code-table-selector
the first character in the text code of [CESR stream](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md) that determines which [code table](https://weboftrust.github.io/WOT-terms/docs/glossary/code-table.md) to use, either a default code table or a code table selector character when not the default code table. Thus the 1 character text code table must do double duty. It must provide selectors for the different text code tables and also provide type codes for the most popular primitives that have a pad size of 1 that appear is the default code table.
See row 1.
---
title: code-table
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/code-table
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/code-table.md
---
# code-table
a code table is the Internet's most comprehensive yet simple resource for browsing and searching for [alt codes](https://www.codetable.net/altkeycodes), [ascii codes](https://www.codetable.net/asciikeycodes), [entities in html](https://www.codetable.net/entitiesinhtml), [unicode characters](https://www.codetable.net/unicodecharacters), and [unicode groups and categories](https://www.codetable.net/groups).
[Source](https://www.codetable.net)
Multiple text and binary code tables exist to pre-pend characters before the respective stream parts to characterize ([self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md)) them or group them.
---
title: cold-start-stream-parsing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cold-start-stream-parsing
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cold-start-stream-parsing.md
---
# cold-start-stream-parsing
After a reboot (or cold start), a stream processor looks for framing information to know how to parse groups of elements in the stream.
If that framing information is ambiguous then the parser may become confused and require yet another cold start. While processing a given stream a parser may become confused especially if a portion of the stream is malformed in some way. This usually requires flushing the stream and forcing a cold start to resynchronize the parser to subsequent stream elements.
Better than flushing the stream and forcing a cold start is a re-synchronization mechanism that does not require flushing the in-transit buffers but merely skipping to the next well-defined stream element boundary in order to execute a cold start.
_See an example_ in the [source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#cold-start-stream-parsing-problem)
Special CESR count codes support re-synchronization at each boundary between interleaved CESR and other serializations like JSON, CBOR, or MGPK.
---
title: collective-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/collective-signature
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/collective-signature.md
---
# collective-signature
a group signature scheme, that (i) is shared by a set of signing groups and (ii) combined collective signature shared by several signing groups and several individual signers. The protocol of the first type is constructed and described in detail. It is possible to modify the described protocol which allows transforming the protocol of the first type into the protocol of the second type. The proposed collective signature protocols have significant merits, one of which is connected with possibility of their practical using on the base of the existing public key infrastructures.
[Source](https://link.springer.com/chapter/10.1007/978-981-10-7512-4_20)
Collective signature have a variable length as a function of the number of signers.
---
title: collision
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/collision
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/collision.md
---
# collision
In cryptography and identity _collision_ generally refers to something going wrong because an identical result has been produced but it refers to - or points to - different sources or assets backing this result.
E.g. two hashes collide, meaning two different digital sources produce the same hash.
Another example is [name(space) collision](https://en.wikipedia.org/wiki/Naming_collision).
A circumstance where two or more identifiers in a given [namespace](https://weboftrust.github.io/WOT-terms/docs/glossary/namespace.md) or a given scope cannot be unambiguously resolved.
[Source Wikipedia](https://en.wikipedia.org/wiki/Naming_collision)
---
title: compact-variant
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/compact-variant
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/compact-variant.md
---
# compact-variant
Either a [most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version of an ACDC or the [fully compact](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-compact.md) version of an ACDC. An [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) commitment via a signature to any variant of ACDC (compact, full, etc) makes a cryptographic commitment to the top-level section fields shared by all variants of that ACDC because the value of a [top level section field](https://weboftrust.github.io/WOT-terms/docs/glossary/top-level-section.md) is either the [SAD](https://weboftrust.github.io/WOT-terms/docs/glossary/SAD.md) or the [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md) of the SAD of the associated section.
All the variants of an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) are various degrees of expansion of the compact variant.
More at [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md)
[Fully (expanded)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-expanded.md) version of an ACDC
[Fully compact(ed)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-compact.md) version of an ACDC
[Most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version of an ACDC.
---
title: complementary-integrity-verification
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/complementary-integrity-verification
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/complementary-integrity-verification.md
---
# complementary-integrity-verification
A mechanism that can verify integrity independent of needing access to a previous instance or reference version of the information for comparison.
Source: Neil Thomson
Independent Integrity Verification is what is achieved by use of a public key from the data "controller" such that it does not need to compare received data/messages against the sent data/message.
The already verified chain up to a certain point in time in the past (previous instance or reference version) no longer needs to be verified.
> Example: The tail of a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) that has been verified to its [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) on a certain date and time, can be cut off. You don't need to verify this any more from this date.
[integrity](https://weboftrust.github.io/WOT-terms/docs/glossary/integrity.md)
[verified integrity](https://weboftrust.github.io/WOT-terms/docs/glossary/verified-integrity.md)
---
title: text-binary-concatenation-composability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/composability
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/composability.md
---
# text-binary-concatenation-composability
An encoding has _composability_ when any set of [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) concatenated primitives expressed in either the text domain or binary domain may be converted as a group to the other domain and back again without loss.
CESR is fully text binary concatenation composable.
Use Google Translate to translate a piece of text from English to Dutch. Subsequently, keep copy pasting the resulting “to:” text into the “from:” field. The message changes until it comes to a standstill where you can keep swapping the texts without them changing.
The conclusion is: Google Translate is not composable!
By contrast, CESR is composable. The _analogy_ lies in the fact that we consider two languages. Suppose the English in the Google Translate example is _readable, text based_ in CESR and Dutch is the _binary_ form in CESR. Within these two CESR “languages”, text-based and binary, you can concatenate and swap freely as many times as you like — the data won’t change in between in their binary or text form no matter what content you express with them.
More explanation in [source](https://medium.com/happy-blockchains/cesr-one-of-sam-smiths-inventions-is-as-controversial-as-genius-d757f36b88f8).
---
title: composable-event-streaming-representation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/composable-event-streaming-representation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/composable-event-streaming-representation.md
---
# composable-event-streaming-representation
Also called 'CESR'. This compact encoding scheme fully supports both textual and binary streaming applications of attached crypto material of all types. This approach includes [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) in both the textual and binary streaming domains. The [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md) may be the minimum possible but still composable size.
Making composability a guaranteed property allows future extensible support of new compositions of streaming formats based on pre-existing core primitives and compositions of core primitives. This enables optimized stream processing in both the binary and text domains.
---
title: composable
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/composable
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/composable.md
---
# composable
[Composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md)
---
title: concatenation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/concatenation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/concatenation.md
---
# concatenation
In [formal language theory](https://en.wikipedia.org/wiki/Formal_language) and [computer programming](https://en.wikipedia.org/wiki/Computer_programming), string concatenation is the operation of joining [character strings](https://en.wikipedia.org/wiki/Character_string_\(computer_science\)) [end-to-end](https://en.wiktionary.org/wiki/end-to-end). For example, the concatenation of "snow" and "ball" is "snowball".
More on source [Wikipedia page](https://en.wikipedia.org/wiki/Concatenation)
In CESR Concatenation is an important property of CESR's [Composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md); it is associative and may be applied to any two [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md) or any two groups or sets of concatenated primitives.
The composability property of CESR allows us to create arbitrary compositions of primitives via concatenation in either the text or binary domain and then convert the composition en masse to the other domain and then de-concatenate the result without loss. The [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) property of the primitives enables de-concatenation.
---
title: concise-binary-object-representation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/concise-binary-object-representation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/concise-binary-object-representation.md
---
# concise-binary-object-representation
a binary serialization format, similar in concept to JSON but aiming for greater conciseness. Defined in \[[RFC7049](https://trustoverip.github.io/tswg-keri-specification/#ref:RFC7049)\].
Source: Dr. S.Smith, 2024
It is a binary data [serialization](https://en.wikipedia.org/wiki/Serialization) format loosely based on [JSON](https://en.wikipedia.org/wiki/JSON) authored by C. Bormann. Like JSON it allows the transmission of data objects that contain [name–value pairs](https://en.wikipedia.org/wiki/Attribute%E2%80%93value_pair), but in a more concise manner. This increases processing and transfer speeds at the cost of [human readability](https://en.wikipedia.org/wiki/Human-readable_medium).
It is defined in IETF [RFC](https://en.wikipedia.org/wiki/RFC_\(identifier\)) [8949](https://datatracker.ietf.org/doc/html/rfc8949).[\[1\]](https://en.wikipedia.org/wiki/CBOR#cite_note-:0-1)
CBOR was inspired by [MessagePack](https://en.wikipedia.org/wiki/MessagePack), which was developed and promoted by Sadayuki Furuhashi. CBOR extended MessagePack, particularly by allowing to distinguish text strings from byte strings, which was implemented in 2013 in MessagePack.[\[4\]](https://en.wikipedia.org/wiki/CBOR#cite_note-4)[\[5\]](https://en.wikipedia.org/wiki/CBOR#cite_note-rfc8949-5)
[CBOR](https://en.wikipedia.org/wiki/CBOR)
---
title: secure-private-authentic-confidentiality
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/confidentiality
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/confidentiality.md
---
# secure-private-authentic-confidentiality
ToIP Trust Spanning Layer Group realized we do have a secure authentication layer (KERI) but we don't have a secure confidentiality and privacy mechanism. Sam Smith proposes SPAC paper to define this. Related: [https://www.usenix.org/system/files/sec22-cohen.pdf](https://www.usenix.org/system/files/sec22-cohen.pdf)
If someone has set up a public AID, with public Witnesses we don't have a mechanism to support private communication with this AID | TBW |
[SPAC paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md)
Tech meet KERI [recording](https://hackmd.io/-soUScAqQEaSw5MJ71899w#2023-06-27) from minute 35, date June 29 2023 and also discussed Tech meeting KERI Aug 3 2023 from minute 30 or so till end.
---
title: configuration-files
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/configuration-files
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/configuration-files.md
---
# configuration-files
In [computing](https://en.wikipedia.org/wiki/Computing), configuration files (commonly known simply as config files) are [files](https://en.wikipedia.org/wiki/Computer_file) used to configure the [parameters](https://en.wikipedia.org/wiki/Parameter_\(computer_programming\)) and [initial settings](https://en.wikipedia.org/wiki/Initialization_\(programming\)) for some [computer programs](https://en.wikipedia.org/wiki/Computer_program). They are used for user [applications](https://en.wikipedia.org/wiki/Application_software), [server processes](https://en.wikipedia.org/wiki/Server_\(computing\)) and [operating system](https://en.wikipedia.org/wiki/Operating_system) settings.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Configuration_file)
---
title: consensus-mechanism
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/consensus-mechanism
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/consensus-mechanism.md
---
# consensus-mechanism
How groups of entitities come to decisions. In general to learn about consensus mechanisms read any textbook on decision making, automated reasoning, multi-objective decision making, operations research etc.
A fundamental problem in distributed computing and multi-agent systems is to achieve overall system reliability in the presence of a number of faulty processes. This often requires coordinating processes to reach consensus, or agree on some data value that is needed during computation.
More on [wikipedia](https://en.wikipedia.org/wiki/Consensus_\(computer_science\)) or in this [2018 report](https://cryptoresearch.report/crypto-research/consensus-mechanisms/) from the cryptocurrency field.
---
title: content-addressable-hash
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/content-addressable-hash
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/content-addressable-hash.md
---
# content-addressable-hash
Finding content by a hash of this content, generated by a one-way hash function applied to the content.
Content addressing is a way to find data in a network using its content rather than its location. The way we do is by taking the content of the content and hashing it. Try uploading an image to IPFS and get the hash using the below button.
Content Addressable Storage systems work by passing the content of the file through a [cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) to generate a unique key, the "content address". The [file system](https://en.wikipedia.org/wiki/File_system)'s [directory](https://en.wikipedia.org/wiki/Directory_\(computing\)) stores these addresses and a pointer to the physical storage of the content. Because an attempt to store the same file will generate the same key, CAS systems ensure that the files within them are unique, and because changing the file will result in a new key, CAS systems _provide assurance that the file is unchanged_.
In the IPFS ecosystem, this hash is called Content Identifier, or CID.
---
title: contextual-linkability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/contextual-linkability
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/contextual-linkability.md
---
# contextual-linkability
Refers to the condition where vendors or other data capture points provide enough context at point of capture to be able to use statistical correlation with existing data sets to link any of a person's disclosed attributes to a set of already known data points about a given person.
This sort of linkability nullifies the perceived protection of [selective disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md) through [zero knowledge proofs](https://weboftrust.github.io/WOT-terms/docs/glossary/zero-knowledge-proofs.md) since the disclosed data can be combined with context to easily link the disclosed data to an existing profile of the person.
These threats mainly focus on a subject (the entity) who wants to hide as much of his identifiable information (or at least make it as unlikable as possible). This can occur when the subject wants to authenticate himself to a certain service (multiple authentication principles are shown in the tree), but also during regular communication (browsing, client-server requests, etc.) by means of the contextual information connected or linked to the the activity or communication.
More at [source](https://www.linddun.org/linkability)
[Contractually protected disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/contractually-protected-disclosure.md) is the primary defense against contextual linkability.
Cameras in stores are already able to identify you due to the extremely high prevalence of modern security systems who do facial recognition or mobile device ping recognition on each person entering the premises of a store. In the context of you buying stuff in their store they can capture data linked to you and then go and sell your data to third parties since there is an implicit grant of permission to use the data and also since there are no legal constraints on the distribution of that data.
Just have a look at what "they" are doing:
[https://linkgraph.io/blog/how-to-contextual-link-building/](https://linkgraph.io/blog/how-to-contextual-link-building/)
---
title: contingent-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/contingent-disclosure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/contingent-disclosure.md
---
# contingent-disclosure
Contingent disclosure is a privacy-preserving mechanism where only specific information or attributes are disclosed under defined conditions. It enables the selective sharing of data such that only the required information is revealed to a relying party, without exposing other unrelated or sensitive details. [Chain link confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/chain-link-confidentiality.md) is a form of contingent disclosure.
| TBW prio 1 |
---
title: contractually-protected-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/contractually-protected-disclosure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/contractually-protected-disclosure.md
---
# contractually-protected-disclosure
a discloser of an ACDC that leverages a Graduated Disclosure so that contractual protections can be put into place to minimize the leakage of information that can be correlated. A Contractually Protected Disclosure partially or selectively reveals the information contained within the ACDC in the initial interaction with the recipient and discloses further information only after the recipient agrees to the terms established by the discloser. More information may be progressively revealed as the recipient agrees to additional terms.
Source: Dr. S. Smith
Usage of schema-based and contract-based controls to limit the exchange of information to provide both mechanical and legal protection on the sharing of data.
Mechanical protection is composed of sharing the schema of the data to be shared prior to sharing the actual data contents. This mechanical protection is then combined through the IPEX protocol with disclosures of legal contracts to be agreed to prior to sharing the desired data contents.
Once the legal agreements have been met then the disclosure mechanism exchanges the desired data contents.
This is also the most elaborate form of disclosure by an [IPEX](https://weboftrust.github.io/WOT-terms/docs/glossary/IPEX.md). Contractually protected disclosure includes both [chain-link confidential](https://weboftrust.github.io/WOT-terms/docs/glossary/chain-link-confidentiality.md) and [contingent disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/contingent-disclosure.md).
Paraphrased by @henkvancann based on [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#discussion)
This [IPEX](https://weboftrust.github.io/WOT-terms/docs/glossary/IPEX.md) protocol leverages important features of [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md)s and ancillary protocols such as [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md), [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md)s, and [CESR-Proofs](https://weboftrust.github.io/WOT-terms/docs/glossary/cesr-proof-signatures.md) as well as [Ricardian contract](https://weboftrust.github.io/WOT-terms/docs/glossary/ricardian-contract.md)s and graduated disclosure (partial, selective, full) to enable contractually protected disclosure. Contractually protected disclosure includes both \[chain-link confidential\](https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/chain-link confidential.md) and \[contingent disclosure\](https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/contingent disclosure.md).
The disclosure performed by a presentation exchange MAY be [graduated](https://weboftrust.github.io/WOT-terms/docs/glossary/graduated-disclosure.md) and MAY be [contractually](https://weboftrust.github.io/WOT-terms/docs/glossary/contractually-protected-disclosure.md) protected.
---
title: control-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/control-authority
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/control-authority.md
---
# control-authority
In identity systems Control Authority is who controls what and that is the primary factor in determining the basis for trust in them. The entity with _control authority_ takes action through operations that affect the
- creation (inception)
- updating
- rotation
- revocation
- deletion
- and delegation of the **authentication factors and their relation to the identifier**.
How these events are ordered and their dependence on previous operations is important. The record of these operations is the source of truth for the identity system.
In the 2022 implementation of [KeriPy](https://weboftrust.github.io/WOT-terms/docs/glossary/keripy.md) two [rotations](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md) were required to _change_ control authority. In new rotation rules, you can rotate to new keys that aren't in the prior next key [digests](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md). You just need to reach the appropriate thresholds of _prior-next-threshold_ and _current-signing-threshold_. So you now only need one rotation to change control authority.
**Note**: This change was the forcing function to require [dual indexed codes](https://weboftrust.github.io/WOT-terms/docs/glossary/dual-indexed-codes.md) in CESR.
---
title: controller
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/controller
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/controller.md
---
# controller
an entity that can cryptographically prove the control authority over an AID and make changes on the associated KEL. A controller of a multi-sig AID may consist of multiple controlling entities.
Source: Dr. S.Smith, 2024
A controller is a controlling entity (person, organization, or autonomous software) of an identifier. For an [autonomic identifier (AID)](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md), a controlling entity has the capability to make changes to the [key event log (KEL)](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of the AID. This capability is typically asserted by the control of a set of cryptographic keys used by software acting on behalf of the controller, though it might also be asserted via other mechanisms.
At any point in time, an identifier has at least one but may have more than one controlling entity. This set of controlling entities constitutes the controller. Without loss of generality, when the context is unambiguous, the term controller may refer either to the whole set or a member of the set of controlling entities.
All [key events](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event.md) on the identifier must include a signature from the sole controlling entity when there is only one controlling entity or at least one signature from one of the controlling entities when there is more than one. Typically, when there is more than one controlling entity, control is established via signatures from all or a subset of controlling entities. This is called [multi-signature (multi-sig)](https://weboftrust.github.io/WOT-terms/docs/glossary/multisig.md). In a threshold multi-sig scheme, the control authority is split among the controlling entities, where each is assigned a weight. In this case, the control authority over the identifier is established via signatures from a subset of controlling entities whose combined weights exceed an agreed threshold. These thresholded multiple signatures may be expressed as a single collective threshold signature when a collective signing scheme is used.
The control authority over an identifier can also be divided into signing authority and rotation authority. The controller of the identifier may grant their authority to other entities. For example, in [custodial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-rotation.md), the controller grants a designated custodial agent the signing authority while retaining their rotation authority. In the case of a [delegated identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/delegated-identifier.md), the delegated identifier is granted some degree of control authority from its delegating identifier.
---
title: cooperative-delegation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cooperative-delegation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cooperative-delegation.md
---
# cooperative-delegation
The way KERI addresses the [security-cost-performance architecture trade-off](https://weboftrust.github.io/WOT-terms/docs/glossary/security-cost-performance-architecture-trade-off.md) is via [delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md) of identifier prefixes. Delegation includes a delegator and a delegate. For this reason we may call this a cooperative delegation. This is a somewhat **novel form of delegation**.
A major advantage of cooperative delegation is the delegator’s key management protects the delegate’s via recovery by the delegator. With cooperative delegation, any exploiter that compromises only the delegate’s authoritative keys may not capture control authority of the delegate. Any exploit of the delegate only is recoverable by the delegator.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: coroutines
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/coroutines
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/coroutines.md
---
# coroutines
Computer programs that can be suspended and resumed at will.
Coroutines are [computer program](https://en.wikipedia.org/wiki/Computer_program) components that generalize [subroutines](https://en.wikipedia.org/wiki/Subroutine) for [non-preemptive multitasking](https://en.wikipedia.org/wiki/Non-preemptive_multitasking), by allowing execution to be suspended and resumed. Coroutines are well-suited for implementing familiar program components such as [cooperative tasks](https://en.wikipedia.org/wiki/Cooperative_multitasking), [exceptions](https://en.wikipedia.org/wiki/Exception_handling), [event loops](https://en.wikipedia.org/wiki/Event_loop), [iterators](https://en.wikipedia.org/wiki/Iterator), [infinite lists](https://en.wikipedia.org/wiki/Lazy_evaluation) and [pipes](https://en.wikipedia.org/wiki/Pipeline_\(software\)).
More on source [Wikipedia](https://en.wikipedia.org/wiki/Coroutine)
---
title: unpermissioned-correlation
description: a correlation established between two or more disclosed ACDCs whereby the discloser of the ACDCs does not permit the disclosee to establish such a correlation.
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/correlation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/correlation.md
---
# unpermissioned-correlation
a correlation established between two or more disclosed ACDCs whereby the discloser of the ACDCs does not permit the disclosee to establish such a correlation.
Source: Dr. S. Smith
---
title: count-code
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/count-code
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/count-code.md
---
# count-code
[Group framing code](https://weboftrust.github.io/WOT-terms/docs/glossary/group-framing-code.md)
---
title: vlei-role-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/credential
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/credential.md
---
# vlei-role-credential
It is a [vLEI credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md) that attests to a role within a legal entity to an individual or an entity. It cryptographically proves that the individual or entity is authorized to act in that role on behalf of the legal entity.
---
title: CRUD
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CRUD
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CRUD.md
---
# CRUD
Is acronym for the traditional _client-server_ database update policy is CRUD (**Create, Read, Update, Delete**).
CRUD as opposed to [RUN](https://weboftrust.github.io/WOT-terms/docs/glossary/RUN.md) which is the acronym for the new peer-to-peer end-verifiable monotonic update policy.
We [RUN off the CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/run-off-the-crud.md), which means that because the source of truth for each data item is a decentralized controller Peer, a given database hosted by any Peer does not create records in the traditional sense of a server creating records for a client.
---
title: crypto-libraries
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/crypto-libraries
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/crypto-libraries.md
---
# crypto-libraries
Cryptography libraries deal with cryptography algorithms and have API function calls to each of the supported features.
Criteria to chose one or the other:
- Open Source (most of them are)
- Compliant with standards
- Key operations include key generation algorithms, key exchange agreements and public key cryptography standards.
- Supported cryptographic hash functions
- Implementations of message authentication code (MAC) algorithms
- Implementations of block ciphers
- Hardware-assisted support
- Code size and code to comment ratio
- Composable derivation codes
See a [comparison here](https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries) at Wikipedia.
---
title: cryptocurrency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptocurrency
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptocurrency.md
---
# cryptocurrency
A digital asset designed to work as a medium of exchange wherein individual coin ownership records are stored in a digital ledger or computerized database using strong cryptography to secure transaction record entries, to control the creation of additional digital coin records.
See [more](https://en.wikipedia.org/wiki/Cryptocurrency) on source Wikipedia.
KERI doesn't need total global ordering, whereas cryptocurrencies do need this. As a consequence has been designed, without the need of a consensus-based distributed ledger (blockchain).
KERI doesn't provide for a currency system, however a KERI-based system can be easily extended with a money - or token system.
See also Non Fungible Tokens.
---
title: cryptographic-commitment-scheme
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptographic-commitment-scheme
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptographic-commitment-scheme.md
---
# cryptographic-commitment-scheme
is a cryptographic primitive that allows one to commit to a chosen value (or chosen statement) while keeping it hidden to others, with the ability to reveal the committed value later.
Commitment schemes are designed so that a party cannot change the value or statement after they have committed to it: that is, commitment schemes are _binding_.
More on [wikipedia](https://en.wikipedia.org/wiki/Commitment_scheme)
---
title: cryptographic-primitive
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptographic-primitive
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptographic-primitive.md
---
# cryptographic-primitive
the serialization of a value associated with a cryptographic operation including but not limited to a digest (hash), a salt, a seed, a private key, a public key, or a signature.
Source: Dr. S.Smith, 2024
Cryptographic primitives are well-established, low-level [cryptographic](https://en.wikipedia.org/wiki/Cryptography) algorithms that are frequently used to build [cryptographic protocols](https://en.wikipedia.org/wiki/Cryptographic_protocol) for [computer security](https://en.wikipedia.org/wiki/Computer_security) systems. These routines include, but are not limited to, [one-way hash functions](https://en.wikipedia.org/wiki/One-way_hash_function) and [encryption functions](https://en.wikipedia.org/wiki/Cipher).
More on source [Wikipedia-page](https://en.wikipedia.org/wiki/Cryptographic_primitive)
In KERI and ACDC it a serialization of a unitary value associated with a cryptographic operation including but not limited to a digest (hash), a salt, a seed, a private key, a public key, or a signature. All primitives in KERI MUST be expressed in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md).
The more general term [primitive](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md).
---
title: cryptographic-strength
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptographic-strength
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptographic-strength.md
---
# cryptographic-strength
The term "cryptographically strong" is often used to describe an encryption algorithm, and implies, in comparison to some other algorithm (which is thus cryptographically weak), greater resistance to attack. But it can also be used to describe hashing and unique identifier and filename creation algorithms.
More on [Wikipedia](https://en.wikipedia.org/wiki/Strong_cryptography)
---
title: cryptonym
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptonym
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/cryptonym.md
---
# cryptonym
a cryptographic pseudonymous identifier represented by a string of characters derived from a random or pseudo-random secret seed or salt via a one-way cryptographic function with a sufficiently high degree of cryptographic strength (e.g., 128 bits, see appendix on [cryptographic strength](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptographic-strength.md). A cryptonym is a type of [primitive](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md).
Due to the [entropy](https://weboftrust.github.io/WOT-terms/docs/glossary/entropy.md) in its derivation, a cryptonym is a universally unique identifier, and only the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) of the secret [salt](https://weboftrust.github.io/WOT-terms/docs/glossary/salt.md) or [seed](https://weboftrust.github.io/WOT-terms/docs/glossary/seed.md) from which the cryptonym is derived may prove control over the cryptonym. Therefore, the derivation function MUST be associated with the cryptonym and may be encoded as part of the cryptonym itself.
Source [Smith, ietf-keri draft](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md)
A code name, call sign, or cryptonym is a [code word](https://en.wikipedia.org/wiki/Code_word_\(figure_of_speech\)) or name used, sometimes clandestinely, to refer to another name, word, project, or person.
Source [Wikipedia](https://en.wikipedia.org/wiki/Code_name)
---
title: CSPRNG
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CSPRNG
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CSPRNG.md
---
# CSPRNG
means "Cryptographically Secure Pseudorandom Number Generator," which means that a sequence of numbers (bits, bytes...) that is produced from an algorithm that is deterministic (the sequence is generated from some unknown internal state), hence pseudorandom is also cryptographically secure, or not.
(Source: [https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng](https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng))
It is cryptographically secure if nobody can _reliably distinguish_ the output from true randomness, even if the PRNG algorithm is perfectly known (but not its internal state). A non-cryptographically secure PRNG would fool basic statistical tests but can be distinguished from true randomness by an intelligent attacker.
(Source: [https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng](https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng))
[PRNG](https://weboftrust.github.io/WOT-terms/docs/glossary/PRNG.md)
---
title: CT
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CT
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/CT.md
---
# CT
[Certificate transparency](https://weboftrust.github.io/WOT-terms/docs/glossary/certificate-transparency.md)
---
title: custodial-agent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/custodial-agent
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/custodial-agent.md
---
# custodial-agent
An [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) owned by an individual who has granted [signing authority](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-authority.md) to a custodian who is usually also the host of the running agent software. Using [partial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md) to facilitate custodial key management the owner of the identifier retains [rotational authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md) and thus the ability to "fire" the custodian at any time without requiring the cooperation of the custodian.
Custodial Agents are important for individuals who may not be comfortable managing their own [signing keys](https://weboftrust.github.io/WOT-terms/docs/glossary/digital-signature.md) and agent software but still want to participate in a decentralized identity ecosystem and they enable a software as a service business model without centralizing control on the service provider.
(Source: Philip Feairheller)
Since ninety-nine percent of people in the world might not feel comfortable taking responsibility for their own practical [key management](https://weboftrust.github.io/WOT-terms/docs/glossary/key-management.md) but still want to be stay in control over their assets and be able to hire and fire service providers, this functionality is considered a key feature for KERI and ACDC.
---
title: custodial-rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/custodial-rotation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/custodial-rotation.md
---
# custodial-rotation
Rotation is based on control authority that is split between two key sets. The first for signing authority and the second (pre-rotated) for rotation authority, the associated thresholds and key list can be structured so that a designated custodial agent can hold signing authority, while the original controller can hold exclusive rotation authority.
[Partial pre-rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md) supports the vital use case of custodial key rotation to authorize a [custodial agent](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-agent.md).
Paraphrased by @henkvancann based on the [IETF-KERI draft 2022](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md) by Samual Smith.
---
title: DAG
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DAG
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DAG.md
---
# DAG
[Directed acyclic graph](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md)
---
title: DAR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DAR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DAR.md
---
# DAR
[Designated Authorized Representatives](https://weboftrust.github.io/WOT-terms/docs/glossary/designated-authorized-representative.md)
---
title: data-anchor
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/data-anchor
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/data-anchor.md
---
# data-anchor
Data anchors are [digests](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md) of digital data, that uniquely identify this data. The digest is the anchor and can be used to identify - and point to the data at the same time.
The act of creating the digest of arbitrary data and then hook (or reference) the digest to (in) another data structure is called 'anchoring data'.
[SADs](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-data.md) are a type of data anchors.
[Link anchors](https://en.wikipedia.org/wiki/Hyperlink#Anchor_links) are a totally different concepts.
---
title: dead-drop
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dead-drop
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dead-drop.md
---
# dead-drop
In cybersecurity or digital privacy scenarios, the term "dead drop" refers to encrypted or secure virtual spaces where information can be deposited or retrieved anonymously. In the credentials field, the presenter controls the disclosure, so you can't re-identify the data.
Discussed in tech meet KERI [recording](https://hackmd.io/-soUScAqQEaSw5MJ71899w#2023-06-27), date June 27 2023.
---
title: decentralized-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/decentralized-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/decentralized-identifier.md
---
# decentralized-identifier
Decentralized identifiers (DID) are a new type of identifier that enables verifiable, decentralized digital identity. A _DID_ refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID.
[Source](https://www.w3.org/TR/did-core/) W3C.org.
In contrast to typical, federated identifiers, _DIDs_ have been designed so that they may be **decoupled from centralized registries**, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party.
[Source](https://www.w3.org/TR/did-core/) W3C.org.
_DIDs_ are _URIs_ that associate a _DID subject_ with a _DID document_ allowing trustable interactions associated with that subject.
[Source](https://www.w3.org/TR/did-core/) W3C.org.
---
title: decentralized-identity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/decentralized-identity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/decentralized-identity.md
---
# decentralized-identity
is a technology that uses cryptography to allow individuals to create and control their own unique identifiers. They can use these identifiers to obtain `Verifiable Credentials` from trusted organizations and, subsequently, present elements of these credentials as proof of claims about themselves. In this model, the individual takes ownership of their own identity and does not need to cede control to centralized service providers or companies.
[ToIP main glossary](https://glossary.trustoverip.org/#term:decentralized-identity)
`KERI`s definition of decentralization (centralization) is about _control_ not _spatial distribution_. In our definition _decentralized_ is not necessarily the same as _distributed_. By distributed we mean that activity happens at more than one site. Thus decentralization is about _control_ and distribution is about _place_. To elaborate, when we refer to decentralized infrastructure we mean infrastructure under decentralized (centralized) control no matter its spatial distribution. Thus _decentralized infrastructure_ is infrastructure sourced or controlled by more than one `entity`.
---
title: decentralized-key-management-infrastructure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/decentralized-key-management-infrastructure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/decentralized-key-management-infrastructure.md
---
# decentralized-key-management-infrastructure
a key management infrastructure that does not rely on a single entity for the integrity and security of the system as a whole. Trust in a DKMI is decentralized through the use of technologies that make it possible for geographically and politically disparate entities to reach an agreement on the key state of an identifier [DPKI](https://trustoverip.github.io/tswg-keri-specification/#term:dpki).
Source: Dr. S.Smith, 2024
Decentralized Public Key Infrastructure ([DPKI](https://ldapwiki.com/wiki/DPKI) or [Decentralized Key Management System](https://ldapwiki.com/wiki/Decentralized%20Key%20Management%20System) ([DKMS](https://ldapwiki.com/wiki/DKMS)) goal is to ensure that no single [third-party](https://ldapwiki.com/wiki/Third-party) can compromise the [integrity](https://ldapwiki.com/wiki/Integrity) and [security](https://ldapwiki.com/wiki/Security) of the system as as whole.
[Source](https://ldapwiki.com/wiki/Decentralized%20Public%20Key%20Infrastructure)
---
title: DEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DEL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DEL.md
---
# DEL
[Duplicitous event log](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicitous-event-log.md)
---
title: delegated-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/delegated-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/delegated-identifier.md
---
# delegated-identifier
Matches the act of [delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md) with the appropriate digital twin. Consequently when applied recursively, delegation may be used to compose arbitrarily complex trees of hierarchical (delegative) key management event streams. This is a most powerful capability that may provide an essential building block for a generic universal decentralized key management infrastructure (DKMI) that is also compatible with the demand of generic event streaming applications.
More in the [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
The KERI design approach is to build composable primitives instead of custom functionality that is so typical of other DKMI approaches:
- [transferable identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable-identifier.md)
- [non-transferable identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable-identifier.md)
- delegated identifiers
---
title: delegation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/delegation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/delegation.md
---
# delegation
A person or group of persons officially elected or appointed to represent another or others.
Delegation can be defined as “the act of empowering to act for another”. With this bestowed power, a person, usually a subordinate, is able to carry out specific activities (normally given by a manager or supervisor). Delegation is a management tool designed to increase the efficiency of an organization. It allows for the goals of the organization to be broken down into tasks and assigned to the team member best suited for the duty.
---
title: derivation-code
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/derivation-code
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/derivation-code.md
---
# derivation-code
To properly extract and use the [public key](https://weboftrust.github.io/WOT-terms/docs/glossary/public-key-infrastructure.md) embedded in a [self-certifying identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-certifying-identifier.md) we need to know the cryptographic _signing scheme_ used by the [key pair](https://weboftrust.github.io/WOT-terms/docs/glossary/key-pair.md). KERI includes this very compactly in the identifier, by replacing the pad character (a character used to fill a void to able to always end up with a fixed length public key) with a special character that encodes the derivation process. We call this the _derivation code_.
> For example suppose that the 44 character Base-64 with trailing pad character for the public key is as follows: `F5pxRJP6THrUtlDdhh07hJEDKrJxkcR9m5u1xs33bhp=` If B is the value of the derivation code then the resultant self-contained string is as follows: `BF5pxRJP6THrUtlDdhh07hJEDKrJxkcR9m5u1xs33bhp`
All crypto material appears in `KERI` in a fully [qualified](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified.md) representation. This includes a derivation code prepended to the crypto-material. 
[Key derivation functions](https://en.wikipedia.org/wiki/Key_derivation_function) are not related to the pre-pended derivation codes used in KERI.
---
title: designated-aliases
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/designated-aliases
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/designated-aliases.md
---
# designated-aliases
An AID controller can designate aliases which are AID controlled identifiers such as a did:keri, did:webs, etc. The [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) controller issues a designated aliases attestation (no issuee) that lists the identifiers and manages the status through a registry anchored to their KEL. See the [designated aliases docs](https://weboftrust.github.io/schema/desig-aliases)
---
title: designated-authorized-representative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/designated-authorized-representative
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/designated-authorized-representative.md
---
# designated-authorized-representative
Also 'DAR'. These are representatives of a Legal Entity that are authorized by the Legal Entity to act officially on behalf of the Legal Entity. DARs can authorize:
1. vLEI Issuer Qualification Program Checklists
2. execute the vLEI Issuer Qualification Agreement
3. provide designate/replace Authorized vLEI Representatives ([AVR](https://weboftrust.github.io/WOT-terms/docs/glossary/authorized-vlei-representative.md)s).
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: DHT
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DHT
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DHT.md
---
# DHT
[Distributed hash table](https://weboftrust.github.io/WOT-terms/docs/glossary/distributed-hash-table.md)
---
title: DID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DID.md
---
# DID
[Decentralized Identifier](https://github.com/trustoverip/acdc/wiki/decentralized-identifier)
---
title: diger
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/diger
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/diger.md
---
# diger
A _primitive_ that represents a [digest](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md). It has the ability to [verify](https://weboftrust.github.io/WOT-terms/docs/glossary/verify.md) that an input hashes to its raw value.
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: signed-digest
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/digest
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/digest.md
---
# signed-digest
commitment to content, by digitally signing a digest of this content.
---
title: digital-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/digital-signature
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/digital-signature.md
---
# digital-signature
A _digital_ signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A valid digital signature, where the prerequisites are satisfied, gives a recipient very strong reason to believe that the message was created by a known sender (authentication), and that the message was not altered in transit (integrity).
There are `digital signatures` and [Electronic signatures](https://weboftrust.github.io/WOT-terms/docs/glossary/electronic-signature.md), the latter are quite different in purpose and practical use.
---
title: dip
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dip
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dip.md
---
# dip
dip = delcept, delegated inception
---
title: indirect-mode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/direct-mode
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/direct-mode.md
---
# indirect-mode
Two primary trust modalities motivated the KERI design, One of these is the _indirect_ (one-to-many) mode, which depends on witnessed key event receipt logs (KERL) as a secondary root-of-trust for validating events. This gives rise to the acronym KERI for key event receipt infrastructure.
The indirect mode extends that trust basis with witnessed key event receipt logs ([KERL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md)) for validating events. The security and accountability guarantees of indirect mode are provided by [KA2CE](https://weboftrust.github.io/WOT-terms/docs/glossary/KA2CE.md) or KERI’s Agreement Algorithm for Control Establishment among a set of witnesses.
[Source: Abstract KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
To protect a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) when engaging with some other controller’s identifier, be it [verification](https://weboftrust.github.io/WOT-terms/docs/glossary/verification.md), control authority establishment, or [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection, are based on an ability to _replay_ the sequence of key events (key event history or log) of that identifier. There are two main operational modes for providing replay capability that are distinguished by the degree of availability of the identifier’s controller when creating and promulgating the key events.
With _indirect mode_, the promulgation of events to a validator may happen even when the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) is not attached to the network and therefore not able to communicate directly with a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md). Indirect mode supports high (nearly continuous) availability of the key event history to any validator. This means that other components must be trusted to promulgate key events when the controller is not attached to the network. Indirect mode is compatible with identifiers for one-to-many exchanges or any-wise relationships (a controller with any others). A single indirect mode identifier may be used for a public service or business or otherwise when building brand and reputation in that identifier is important. An indirect mode identifier may also be used for private one-to-one or select groups but where intermittent availability is not tolerable.
More in [Source: chapter Protocol Operational Modes in KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
The protocol may operate in two basic modes, called direct and indirect. The availability and consistency attack surfaces are different for the two modes and hence the mitigation properties of the protocol are likewise mode specific. [Source: chapter Security concerns in KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
[Direct mode](https://weboftrust.github.io/WOT-terms/docs/glossary/direct-mode.md)
---
title: directed-acyclic-graph
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/directed-acyclic-graph
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/directed-acyclic-graph.md
---
# directed-acyclic-graph
From Wikipedia ([source](https://en.wikipedia.org/wiki/Directed_acyclic_graph)):
In [mathematics](https://en.wikipedia.org/wiki/Mathematics), particularly [graph theory](https://en.wikipedia.org/wiki/Graph_theory), and [computer science](https://en.wikipedia.org/wiki/Computer_science), a directed acyclic graph (DAG [/ˈdæɡ/](https://en.wikipedia.org/wiki/Help:IPA/English) ([listen](https://upload.wikimedia.org/wikipedia/commons/5/5a/En-us-DAG.ogg))) is a [directed graph](https://en.wikipedia.org/wiki/Directed_graph) with no [directed cycles](https://en.wikipedia.org/wiki/Cycle_graph#Directed_cycle_graph). That is, it consists of [vertices](https://en.wikipedia.org/wiki/Vertex_\(graph_theory\)) and [edges](https://en.wikipedia.org/wiki/Edge_\(graph_theory\)) (also called arcs), with each edge directed from one vertex to another.
Following directions in a DAG will never form a closed loop. Steps through a DAG are finite. That's the main reason to choose for a DAG.
From Wikipedia ([source](https://en.wikipedia.org/wiki/Directed_acyclic_graph)):
A directed graph is a DAG if and only if it can be [topologically ordered](https://en.wikipedia.org/wiki/Topological_ordering), by arranging the vertices as a linear ordering that is consistent with all edge directions.
From Wikipedia ([source](https://en.wikipedia.org/wiki/Directed_acyclic_graph)):
DAGs have numerous scientific and computational applications, ranging from biology (evolution, family trees, epidemiology) to information science (citation networks) to computation (scheduling).
---
title: disclosee
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/disclosee
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/disclosee.md
---
# disclosee
a role of an entity that is a recipient to which an ACDC is disclosed. A Disclosee may or may not be the Issuee of the disclosed ACDC.
Source: Dr. S. Smith
---
title: discloser
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/discloser
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/discloser.md
---
# discloser
a role of an entity that discloses an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md). A Discloser may or may not be the Issuer of the disclosed ACDC.
Source: Dr. S. Smith
---
title: percolated-information-discovery
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/discovery
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/discovery.md
---
# percolated-information-discovery
In the [OOBI](https://weboftrust.github.io/WOT-terms/docs/glossary/OOBI.md) protocol, a discovery mechanism for the [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) and the [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) protocols is provided by a bootstrap that enables Percolated Information Discovery (PID), which is based on Invasion Percolation Theory.
After related information for discovery and verification is bootstrapped from the OOBI, subsequent authorization is non-interactive, thus making it highly scalable. This provides what we call zero-trust percolated discovery or speedy percolated discovery.
Percolation means that each discoverer, in turn, may share what it discovers with any subsequent discoverers. Since the information so discovered is end-verifiable, the percolation mechanism and percolating intermediaries do not need to be trusted.
[Percolation theory](https://en.wikipedia.org/wiki/Percolation_theory) is a mathematical framework used to study the behavior of connected clusters in random systems. It was originally developed to understand the flow of fluids through porous media, but it has since found applications in various fields, including physics, mathematics, computer science, and social sciences.
Invasion percolation is a specific variant of percolation theory that models the infiltration of a fluid into a porous medium. It is used to study how a fluid, such as a gas or liquid, spreads through a random network of interconnected sites or pores.
The invasion process follows the principle of least resistance, where the fluid seeks the path of least resistance through the porous medium. As the invasion progresses, the fluid selectively infiltrates the sites with lower resistance, forming a connected cluster of invaded sites. The invaded cluster grows by adding new invaded sites through the neighboring dry sites with the lowest resistance.
[Percolated discovery](https://weboftrust.github.io/WOT-terms/docs/glossary/percolated-discovery.md)
---
title: distributed-hash-table
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/distributed-hash-table
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/distributed-hash-table.md
---
# distributed-hash-table
It is a distributed system that provides a lookup service similar to a hash table: key-value pairs are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key. The main advantage of a DHT is that nodes can be added or removed with minimum work around re-distributing keys.
Keys are unique identifiers which map to particular values, which in turn can be anything from addresses, to documents, to arbitrary data.
(Source: [Wikipedia](https://en.wikipedia.org/wiki/Distributed_hash_table))
---
title: DKMI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DKMI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DKMI.md
---
# DKMI
[Decentralized key management infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/decentralized-key-management-infrastructure.md)
---
title: dnd
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dnd
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dnd.md
---
# dnd
Do Not Delegate is a flag/attribute for an AID, and this is default set to "you can delegate."
---
title: domain-name
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/domain-name
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/domain-name.md
---
# domain-name
A domain name is a [string](https://en.wikipedia.org/wiki/String_\(computer_science\)) that identifies a realm of administrative autonomy, authority or control within the [Internet](https://en.wikipedia.org/wiki/Internet). Domain names are used in various networking contexts and for application-specific naming and addressing purposes.
More on [Source Wikipedia](https://en.wikipedia.org/wiki/Domain_name).
---
title: trust-domain
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/domain
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/domain.md
---
# trust-domain
A trust domain is the ecosystem of interactions that rely on a trust basis. A trust basis binds controllers, identifiers, and key-pairs. _For example the Facebook ecosystem of social interactions is a trust domain that relies on Facebook’s identity system of usernames and passwords as its trust basis._
([Source whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf))
A trust domain is a domain that the system trusts to authenticate users. In other words, if a user or application is authenticated by a trusted domain, this authentication is accepted by all domains that trust the authenticating domain.
A more technical meaning of 'domain' is on the internet: [domain name](https://weboftrust.github.io/WOT-terms/docs/glossary/domain-name.md).
---
title: double-spend-proof
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/double-spend-proof
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/double-spend-proof.md
---
# double-spend-proof
Total global ordering of transactions so that value can’t be spent twice at the same time from the unit of value. Or in everyday language: you can't spend your money twice.
The most important feature of a [cryptocurrency](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptocurrency.md) is that it must be double spend proof. Because KERI's key event operations are idempotent they do not need to be double spend proofed, so we can greatly simplify the distributed consensus algorithm in KERI. Which makes KERI relatively more attractive for many applications including IoT applications by comparison.
As a result of the relaxation of double spend proofing, KERI is able to break the distributed consensus algorithm into two halves and simplify it in the process. The two halves are the _promulgation_ half (by witnesses) and the _confirmation_ half (by valdators).
---
title: DPKI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DPKI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/DPKI.md
---
# DPKI
[Decentralized key management infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/decentralized-key-management-infrastructure.md)
---
title: drt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/drt
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/drt.md
---
# drt
drt = deltate, delegated rotation
---
title: dual-indexed-codes
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dual-indexed-codes
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dual-indexed-codes.md
---
# dual-indexed-codes
a context-specific coding scheme, for the common use case of thresholded multi-signature schemes in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md).
One way to compactly associated each signature with its public key is to include in the text code for that signature the index into the ordered set of public keys. A popular signature raw binary size is 64 bytes which has a pad size of 2. This gives two code characters for a compact text code. The first character is the selector and type code. The second character is the Base64 encoded integer index.
More at source [Github Repo Ietf-CESR](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md)
---
title: dual-text-binary-encoding-format
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dual-text-binary-encoding-format
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/dual-text-binary-encoding-format.md
---
# dual-text-binary-encoding-format
An encoding format that allows for both text and binary encoding format, which is fully interchangeable. The [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) property enables the round trip conversion en-masse of concatenated primitives between the text domain and binary domain while maintaining the separability of individual primitives.
Read more in [source](https://github.com/trustoverip/tswg-cesr-specification/blob/main/draft-ssmith-cesr.md) of Samuel Smith
- [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md)
- [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md)
---
title: duplicitous-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/duplicitous-event-log
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/duplicitous-event-log.md
---
# duplicitous-event-log
This is a record of inconsistent event messages produced by a given controller or witness with respect to a given [KERL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md). The duplicitous events are indexed to the corresponding event in a KERL.
A duplicitous event is represented by a set of two or more provably mutually [inconsistent](https://weboftrust.github.io/WOT-terms/docs/glossary/inconsistency.md) event messages with respect to a KERL. Each [juror](https://weboftrust.github.io/WOT-terms/docs/glossary/juror.md) keeps a duplicitous event log (DEL) for each [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) and all designated witnesses with respect to a KERL. Any [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) may confirm [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) by examining a DEL.
---
title: duplicity-detection
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/duplicity-detection
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/duplicity-detection.md
---
# duplicity-detection
A mechanism to detect [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) in cryptographically secured event logs.
Duplicity detection, which protects, _not against an external attacker_, but against a malicious [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) does require access to [watchers](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) that are also recording duplicitous events.
---
title: threshold-of-accountable-duplicity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/duplicity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/duplicity.md
---
# threshold-of-accountable-duplicity
The threshold of accountable duplicity (TOAD) is a threshold number `M` that the controller declares to accept accountability for an event when any subset `M` of the `N` witnesses confirm that event. The threshold `M` indicates the minimum number of confirming witnesses the controller deems sufficient given some number `F` of potentially faulty witnesses, given that `M >= N - F`. This enables a controller to provide itself with any degree of protection it deems necessary given this accountability.
Note that what may be sufficient for a controller may not be sufficient for a validator. To clarify, let `MC` denote the threshold size of a sufficient agreement from the perspective of a controller and let `MV` denote the threshold size of a sufficient agreement from the perspective of a validator. Typically, `MV >= MC`.
A controller declares TOAD in its [key event log (KEL)](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) during the [key inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md) and may edit it during subsequent [key rotation events](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md).
A highly available system needs some degree of fault tolerance. The purpose of the threshold of accountability is to enable fault tolerance of the key event service with respect to faulty behavior by either the controller or witnesses. The principal controller fault exhibits duplicitous behavior in the use of its keys. In this case, the threshold serves as the threshold of accountable duplicity. The threshold lets a validator know when it may hold the controller accountable for duplicitous behavior. Without a threshold, a validator may choose to hold a controller accountable upon any evidence of duplicity which may make the service fragile in the presence of any degree of such faulty behavior. The primary way that a validator may hold a controller accountable is to stop trusting any use of the associated identifier. This destroys any value in the identifier and does not allow the controller to recover from an exploit. Recall that the one purpose of rotation keys (pre-rotated unexposed) is to enable recovery from compromised interaction signing keys. A compromised interaction signing key may exhibit duplicitous behavior on the part of the controller. A threshold of accountable duplicity enables a validator to distinguish between potentially recoverable duplicity such as the use of a compromised signing key and non-recoverable duplicity such as the use of a compromised rotation key. This better protects both the validator and the controller and improves the robustness of the service.
---
title: E2E
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/E2E
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/E2E.md
---
# E2E
[End-to-end](https://weboftrust.github.io/WOT-terms/docs/glossary/end-to-end.md)
---
title: eclipse-attack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/eclipse-attack
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/eclipse-attack.md
---
# eclipse-attack
An eclipse attack is a [P2P](https://weboftrust.github.io/WOT-terms/docs/glossary/peer-to-peer.md) network-based attack. Eclipse attack can only be performed on nodes that accept incoming connections from other nodes, and not all nodes accept incoming connections.
In a bitcoin network, by default, there are a maximum of 117 incoming TCP connections and 8 outgoing TCP connections.
[Source](https://www.geeksforgeeks.org/what-is-an-eclipse-attack/)
The only attack on KERI possible is an eclipse attack, so the larger your watcher network reach is the better your protection from this type of attack. The only limitation is a resource constraint.
[Source Samuel Smith / Phil Feairheller](https://hackmd.io/-soUScAqQEaSw5MJ71899w?view#2022-09-06)
Eclipse attacks are possible because nodes within the network are unable to connect with all other nodes and can connect with a limited number of neighboring nodes. This limitation might make it seem convenient for attackers to isolate a node from the rest of the network, but it is not an easy task.
More at [Source GeeksforGeeks](https://www.geeksforgeeks.org/what-is-an-eclipse-attack/)
---
title: ECR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ECR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ECR.md
---
# ECR
[Engagement context role](https://weboftrust.github.io/WOT-terms/docs/glossary/engagement-context-role.md)
---
title: electronic-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/electronic-signature
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/electronic-signature.md
---
# electronic-signature
An electronic signature, or e-signature, refers to data in electronic form, which is logically associated with other data in electronic form and which is used by the signatory to sign. This type of signature has the same legal standing as a handwritten signature as long as it adheres to the requirements of the specific regulation under which it was created (e.g., eIDAS in the European Union, NIST-DSS in the USA or ZertES in Switzerland).
_Electronic_ signatures are a legal concept _distinct_ from **[digital signatures](https://weboftrust.github.io/WOT-terms/docs/glossary/digital-signature.md), a cryptographic mechanism** often used to implement electronic signatures. While an electronic signature can be as simple as a name entered in an electronic document, digital signatures are increasingly used in e-commerce and in regulatory filings to implement electronic signatures in a cryptographically protected way.
---
title: encrypt-sender-sign-receiver
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/encrypt-sender-sign-receiver
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/encrypt-sender-sign-receiver.md
---
# encrypt-sender-sign-receiver
An authenticated encryption approach, using [PKI](https://weboftrust.github.io/WOT-terms/docs/glossary/PKI.md). It covers [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) and [confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/confidentiality.md).
---
title: end-role
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/end-role
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/end-role.md
---
# end-role
An end role is an authorization for one [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) to serve in a role for another [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md).
For example, declaring that your [Agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) is serving in the role of [Agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) for your business AIDs.
Source: Phil Feairheller
---
title: end-to-end
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/end-to-end
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/end-to-end.md
---
# end-to-end
Inter-host communication and data flow transformations, considered in motion and at rest.
1. E2E Security. Inter-host communication must be end-to-end signed/encrypted and data must be stored signed/encrypted. Data is signed/encrypted in motion and at rest.
2. E2E Provenance. Data flow transformations must be end-to-end provenanced using verifiable data items (verifiable data chains or VCs). Every change shall be provenanced.
Paraphrased from source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: end-verifiable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/end-verifiable
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/end-verifiable.md
---
# end-verifiable
When a log is _end verifiable_, it means that the log may be verified by any end user that receives a copy. No trust in intervening infrastructure is needed to verify the log and validate the content.
[End‐verifiability](https://weboftrust.github.io/WOT-terms/docs/glossary/end‐verifiability.md)
---
title: engagement-context-role
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/engagement-context-role
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/engagement-context-role.md
---
# engagement-context-role
A person that represents the [Legal Entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md) in a functional or in another context role and is issued an ECR [vLEI Credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md).
On the basis of [Legal entity engagement context role vLEI credential governance framework](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md) an ECR [vLEI Credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md) is **issued to** an engagement context role (ECR).
---
title: Self-sovereign identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/entity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/entity.md
---
# Self-sovereign identifier
Self-sovereign identity is a decentralized identity architecture that implements the Principles of SSI — principally that it puts the identity controller (e.g., a natural person or organization) directly in control of the identifiers and credentials they use to assert their digital identity.
Source: ToIP main glossary
The definition started in the blog "[The Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)" by Christopher Allen in 2016. has not resulted in a consensus today. While some see the ten principles of SSI that Allen proposed as the definition of SSI, he formulated them as "a departure point to provoke a discussion about what's truly important". And it is obvious that what is important differs per [party](https://essif-lab.github.io/framework/docs/terms/party).
[Source eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/self-sovereign-identity)
---
title: entropy
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/entropy
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/entropy.md
---
# entropy
Unpredictable information. Often used as a _secret_ or as input to a _key_ generation algorithm.
[Entropy](https://en.wikipedia.org/wiki/Entropy_\(information_theory\))
The term entropy is also used to describe the degree of unpredictability of a message. Entropy is then measured in bits. The degree or strength of randomness determines how difficult it would be for someone else to reproduce the same large random number. This is called _collision resistance_.
---
title: ephemeral
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ephemeral
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ephemeral.md
---
# ephemeral
Lasting for a markedly brief time. Having a short lifespan.
In the context of identifiers is often referred to as identifiers for one time use; or throw-away identifiers.
---
title: escrow-state
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/escrow-state
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/escrow-state.md
---
# escrow-state
The current state of all the temporary storage locations (what events are waiting for what other information) that KERI protocol needs to keep track of, due to its fully asynchronous nature.
Since the KERI protocol is fully asynchronous, there is no way to guarantee that events will arrive in order to be processed successfully. This includes things like anchoring events for transaction event logs for credentials (the TEL even could arrive before the anchoring event) and signatures arriving on a multisig event.
To account for this asynchronous nature, implementations need to "escrow" events (store them temporarily) while waiting for other events or additional signatures to show up. The current state of all the temporary storage locations (what events are waiting for what other information) is called the "escrow state".
Source: Philip Feairheller
An physical [Escrow State](https://www.answers.com/Q/What_is_an_escrow_state) that you might know from Real Estate transaction is not at all related to the one we define.
---
title: escrow
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/escrow
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/escrow.md
---
# escrow
'Escrow' **as a noun** is a (legal) arrangement in which a third party temporarily holds money or property until a particular condition has been met.
'Escrow' **as a verb**: we use it in protocol design to handle out of order events. Store the event and wait for the other stuff to show up and then continue processing of the event. So _escrowing_ is the process of storing this event. We root back to the event later.
---
title: ESSR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ESSR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ESSR.md
---
# ESSR
[Encrypt‐Sender‐Sign‐Receiver](https://github.com/WebOfTrust/WOT-terms/wiki/encrypt-sender-sign-receiver)
---
title: non-establishment-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/establishment-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/establishment-event.md
---
# non-establishment-event
a Key event that does not change the current Key state for an AID. Typically, the purpose of a Non-establishment event is to anchor external data to a given Key state as established by the most recent prior Establishment event for an AID.
Source: Dr. S. Smith
A key event tieing or anchoring a data payload to the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of an identifier. This data payload includes a set of one or more [seals](https://weboftrust.github.io/WOT-terms/docs/glossary/seal.md) each of which anchor data to the key event.
The data payload event may be used to make verifiable, authoritative statements on behalf of the identifier controller.
These might include authorizations of encryption keys, communication routes, service endpoints, and so forth.
Transactions or workflows composed of non-establishment events are secured by virtue of being included in the verifiable key event sequence with the verifiable authoritative establishment events.
A non-establishment event is a key event that does not change the current key-state for an AID.
Source [KERI Whitepaper Section 7.22 page 46](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
A non-establishment event is a key event that does not change the current key-state for an [identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md). The event (only) ties or anchors digital data to the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of the identifier.
_(@henkvancann)_
---
title: exn
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/exn
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/exn.md
---
# exn
exn = exchange
---
title: exp
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/exp
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/exp.md
---
# exp
exp = expose, sealed data exposition
---
title: extensible-business-reporting-language
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/extensible-business-reporting-language
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/extensible-business-reporting-language.md
---
# extensible-business-reporting-language
XBRL is the open international standard for digital business reporting, managed by a global not for profit consortium, XBRL International.
XBRL provides a language in which reporting terms can be authoritatively defined. Those terms can then be used to uniquely represent the contents of financial statements or other kinds of compliance, performance and business reports. XBRL lets reporting information move between organisations rapidly, accurately and digitally.
[Source](https://www.xbrl.org/the-standard/what/an-introduction-to-xbrl/)
XBRL stands for **eXtensible Business Reporting Language**. It is one of a family of “XML” languages which is becoming a standard means of communicating information between businesses and on the internet.
[Source](https://in.xbrl.org/about-us/what-is-xbrl/)
---
title: FFI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/FFI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/FFI.md
---
# FFI
[Foreign Function Interface](https://weboftrust.github.io/WOT-terms/docs/glossary/foreign-function-interface.md)
---
title: field-map
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/field-map
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/field-map.md
---
# field-map
A traditional `key:value` pair renamed to avoid confusing with the cryptographic use of the term 'key'.
To avoid confusion with the cryptographic use of the term key we instead use the term field to refer to a mapping pair and the terms _field label_ and _field value_ for each member of a pair. These pairs can be represented by two tuples e.g (`label, value`). We qualify this terminology when necessary by using the term _field map_ to reference such a mapping.
Field maps may be nested where a given field value is itself a reference to another field map. We call this nested set of fields a nested field map or simply a nested map for short.
---
title: first-seen
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/first-seen
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/first-seen.md
---
# first-seen
refers to the first instance of a [Message](https://weboftrust.github.io/WOT-terms/docs/glossary/message.md) received by any [Witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) or [Watcher](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md). The first-seen event is always seen, and can never be unseen. It forms the basis for [Duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection in KERI-based systems.
Source: Dr. S.Smith
A "First seen" event in KERI refers to the first event received by a validator, such as a witness. The event is valid and fits the available tail sequence number in the validator's KEL and, therefore, is accepted into the validator's KEL. This rule has no effect on the timing of what has arrived in escrow. For example, in escrow, there can be garbage. Assuming a watched set of validators agree on the first-seen events and thus also agree on the KELs, the watchers of those validators will propagate only those first-seen events within microseconds.
From the perspective of a validator, the rule is "First seen, always seen, never unseen."
Different validators might have a different _first-seen_ number for the same originating transaction event. In the case of duplicitous (inconsistent) interaction events originating from the controller (of the current signing key(s)), which might not be discovered until after a key rotation, a recovery process involving judges and jury may be triggered. More [here](https://trustoverip.github.io/tswg-keri-specification/#superseding-rules-for-recovery-at-a-given-location-sn-sequence-number). Validators will not provide an outdated KEL or Event once an erroneous KEL has been corrected.
---
title: foreign-function-interface
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/foreign-function-interface
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/foreign-function-interface.md
---
# foreign-function-interface
Is a mechanism by which a program written in one, usually an [interpreted](https://en.wikipedia.org/wiki/Interpreted_\(programming_languages\)) (scripted), [programming language](https://en.wikipedia.org/wiki/Programming_language) that can call routines or make use of services written or compiled in another one.
More on Source: [https://en.wikipedia.org/wiki/Foreign\_function\_interface](https://en.wikipedia.org/wiki/Foreign_function_interface)
To have the output from RUST-based developed (e.g. cesride) consumed by higher level languages.
---
title: frame-code
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/frame-code
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/frame-code.md
---
# frame-code
[Framing code](https://weboftrust.github.io/WOT-terms/docs/glossary/framing-code.md)
---
title: full-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/full-disclosure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/full-disclosure.md
---
# full-disclosure
a disclosure of an ACDC that discloses the full details of some or all of its field maps. In the context of [Selective Disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md), Full Disclosure means detailed disclosure of the selectively disclosed attributes, not the detailed disclosure of all selectively disclosable attributes. In the context of [Partial Disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-disclosure.md), Full Disclosure means detailed disclosure of the field map that was so far only partially disclosed.
Source: Dr. S. Smith
A disclosure of data in all its details.
When used in the context of [selective disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md), full disclosure means _detailed disclosure of the selectively disclosed attributes_ not detailed disclosure of all selectively disclosable attributes. Whereas when used in the context of [partial disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-disclosure.md), full disclosure means _detailed disclosure of the [field map](https://weboftrust.github.io/WOT-terms/docs/glossary/field-map.md)_ that was so far only partially disclosed.
---
title: fully-compact
description: definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/fully-compact
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/fully-compact.md
---
# fully-compact
The most compact form of an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md). This is the only signed variant of an ACDC and this signature is anchored in a [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) (TEL) for the ACDC. This is one valid choice for an ACDC schema.
This form is part of the [graduated disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/graduated-disclosure.md) mechanism in ACDCs.
The extra a fully compact version has to offer over a [most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version is the anchoring to the [Tranaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md). Here were various proofs ([hashes](https://weboftrust.github.io/WOT-terms/docs/glossary/distributed-hash-table.md)) can be "stored" which are optional in all kind of [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) variants.
[Fully (expanded)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-expanded.md) version of an ACDC
[Most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version of an ACDC.
A fully compact ACDC is like the core of an onion and the fully expanded ACDC is like rest of the outer layers of the onion. Turn this onion inside-out: you only need to sign the core (most compact), and then the whole onion (expanded version) would verify. The complete (expanded) onion is the most user friendly information bulb you can get, and you don't need to peel off all the rings of the onion to securely attribute _all_ the information to the controller of the [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md) that signed the core.
You can present any version of the onion you like: only the core, one partially stripped back, one layer at a time, or the whole thing (fully expanded). This illustrates part of the rational for why ACDCs matter. They offer a layered, graduated disclosure mechanism of verifiable credentials never seen before in the SSI field.
---
title: fully-expanded
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/fully-expanded
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/fully-expanded.md
---
# fully-expanded
The most user-friendly version of an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) credential. It doesn't need to be signed and typically is not signed since the most compact version which is signed can be computed from this form and then the signature can be looked up in the [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/TEL.md) of the ACDC in question.
Regarding the graduated disclosure objective this form is the one with the highest amount of disclosure for a given node of an ACDC graph.
[Fully compact(ed)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-compact.md) version of an ACDC
[Most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version of an ACDC.
---
title: GAR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/GAR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/GAR.md
---
# GAR
[GLEIF authorized representative](https://weboftrust.github.io/WOT-terms/docs/glossary/gleif-authorized-representative.md)
---
title: ghost-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ghost-credential
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ghost-credential.md
---
# ghost-credential
Is a valid credential within in a 90 days grace period (the revocation transaction time frame before it's booked to revocation registry).
When a relationship needs to be terminated with a [QVI](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md) and the QVI has not revoked their credentials (yet) then those credentials become ghost credentials.
| TBW prio 3 |
---
title: gleif-authorized-representative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/gleif-authorized-representative
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/gleif-authorized-representative.md
---
# gleif-authorized-representative
A representative of GLEIF authorized to perform the identity verifications requirements needed to issue the [QVI](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md) [vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) Credential.
Source: [GLEIF Ecosystem Governance Framework v1.0 Glossary](https://www.gleif.org/media/pages/vlei/introducing-the-vlei-ecosystem-governance-framework/0349aa74c5-1678443743/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-glossary_v1.0_final.pdf)
---
title: GLEIF
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/GLEIF
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/GLEIF.md
---
# GLEIF
Global Legal Entity Identifier Foundation
[https://www.gleif.org/en](https://www.gleif.org/en)
---
title: GLEIS
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/GLEIS
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/GLEIS.md
---
# GLEIS
Global Legal Entity Identifier System
---
title: gnu-privacy-guard
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/gnu-privacy-guard
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/gnu-privacy-guard.md
---
# gnu-privacy-guard
also GnuPG; is a free-software replacement for Symantec's PGP cryptographic software suite. It is compliant with RFC 4880, the IETF standards-track specification of OpenPGP. Modern versions of PGP are interoperable with GnuPG and other OpenPGP-compliant systems.
More on [wikipedia](https://en.wikipedia.org/wiki/GNU_Privacy_Guard)
See more about the closely related and often-confusing term [PGP](https://weboftrust.github.io/WOT-terms/docs/glossary/PGP.md).
---
title: vlei-ecosystem-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/governance-framework
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/governance-framework.md
---
# vlei-ecosystem-governance-framework
The Verifiable LEI (vLEI) Ecosystem [Governance Framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md) Information Trust Policies. It's a **document** that defines the information security, privacy, availability, confidentiality and processing integrity policies that apply to all vLEI Ecosystem Members.
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: GPG
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/GPG
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/GPG.md
---
# GPG
[Gnu privacy guard](https://weboftrust.github.io/WOT-terms/docs/glossary/gnu-privacy-guard.md)
---
title: graduated-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/graduated-disclosure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/graduated-disclosure.md
---
# graduated-disclosure
a disclosure of an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) that does not reveal its entire content in the initial interaction with the recipient and, instead, partially or selectively reveals only the information contained within the ACDC necessary to further a transaction with the recipient. A Graduated disclosure may involve multiple steps where more information is progressively revealed as the recipient satisfies the conditions set by the [discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md). [Compact disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/compact-disclosure.md), [Partial disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-disclosure.md), [Selective disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md), and [Full disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/full-disclosure.md) are all Graduated disclosure mechanisms.
Source: Dr. S. Smith
Lifting confidentiality step by step: Selectively disclosing more data as time and/or necessity progresses, offering backward verifiability of earlier issued cryptographic proofs.
You proof your insurance policy without disclosing details before enjoying extreme sports. Only when something goes wrong, e.g., 1 in 100, do you disclose the data. This way confidentiality is kept in 99% of the cases.
Disclosure performed by a presentation exchange that has cross-variant (see [compact variant](https://weboftrust.github.io/WOT-terms/docs/glossary/compact-variant.md)) Issuer commitment verifiability as an essential property. It supports graduated disclosure by the [Disclosee](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md) of any or all variants wether it be full, compact, metadata, partial, selective, bulk issued, or contractually protected.
Paraphrased by @henkvancann based on [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#discussion)
The [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md) of a given variant is useful even when it is not the SAID of the variant the [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) signed because during graduated disclosure the [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) MAY choose to sign that given variant to fulfil a given step in an IPEX graduated disclosure transaction.
The disclosure performed by a presentation exchange MAY be [graduated](https://weboftrust.github.io/WOT-terms/docs/glossary/graduated-disclosure.md) and MAY be [contractually](https://weboftrust.github.io/WOT-terms/docs/glossary/contractually-protected-disclosure.md) protected.
- [Partial Disclosure](https://github.com/trustoverip/acdc/wiki/partial-disclosure)
- [Selective Disclosure](https://github.com/trustoverip/acdc/wiki/selective-disclosure)
- [Full Disclosure](https://github.com/trustoverip/acdc/wiki/full-disclosure)
| TBW | check prio 1
---
title: graph-fragment
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/graph-fragment
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/graph-fragment.md
---
# graph-fragment
An ACDC is a verifiable data structure and _part of a graph_, consisting of a node property and one or two edge proporties.
---
title: group-code
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/group-code
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/group-code.md
---
# group-code
[Group framing code](https://weboftrust.github.io/WOT-terms/docs/glossary/group-framing-code.md)
---
title: group-framing-code
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/group-framing-code
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/group-framing-code.md
---
# group-framing-code
special Framing Codes that can be specified to support groups of Primitives which make them pipelinable. Self-framing grouping using Count Codes is one of the primary advantages of composable encoding.
Source: Dr. S. Smith
special framing codes can be specified to support groups of [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md) in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md). Grouping enables [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md). Other suitable terms for these special framing codes are _group codes_ or _count codes_ for short. These are suitable terms because these framing codes can be used to count characters, primitives in a group, or groups of primitives in a larger group when parsing and off-loading a stream of CESR primitives.
[Source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#count-group-or-framing-codes)
One of the primary advantages of composable encoding is that we can use special framing code to support the above mentioned grouping.
---
title: hab
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hab
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hab.md
---
# hab
A Hab is a keystore for one identifier. The Python implementation in [KERIpy](https://weboftrust.github.io/WOT-terms/docs/glossary/keripy.md), also used by [KERIA](https://weboftrust.github.io/WOT-terms/docs/glossary/keria.md) uses [LMDB](http://www.lmdb.tech/doc/) to store key material and all other data.
Many Habs are included within and managed by a [Habery](https://weboftrust.github.io/WOT-terms/docs/glossary/habery.md).
---
title: habery
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/habery
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/habery.md
---
# habery
'Hab' comes from ‘Habitat’. It’s a place where multi-sigs and AIDs are linked. Habery manages a collection of [Habs](https://weboftrust.github.io/WOT-terms/docs/glossary/hab.md). A Hab is a data structure (a Python object).
The only hit (2022) in a Google search pointing to a github site 'habery DOT github DOT io' is NOT related.
| TBW |-prio2
---
title: hardware-security-module
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hardware-security-module
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hardware-security-module.md
---
# hardware-security-module
A HSM is a physical computing device that safeguards and manages secrets (most importantly [digital keys](https://en.wikipedia.org/wiki/Digital_keys)), performs [encryption](https://en.wikipedia.org/wiki/Encryption) and decryption functions for [digital signatures](https://en.wikipedia.org/wiki/Digital_signature), strong [authentication](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) and other cryptographic functions.
More in source [Wikipedia](https://en.wikipedia.org/wiki/Hardware_security_module)
---
title: hierarchical-asynchronous-coroutines-and-input-output
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hierarchical-asynchronous-coroutines-and-input-output
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hierarchical-asynchronous-coroutines-and-input-output.md
---
# hierarchical-asynchronous-coroutines-and-input-output
HIO is an acronym which stands for 'Weightless hierarchical asynchronous coroutines and I/O in Python'.
It's Rich Flow Based Programming Hierarchical Structured Concurrency with Asynchronous IO. That mouthful of terms has been explained further on [Github](https://github.com/ioflo/hio).
HIO builds on very early work on hierarchical structured concurrency with lifecycle contexts from [ioflo](https://ioflo.com/), [ioflo github](https://github.com/ioflo/ioflo), and [ioflo manuals](https://github.com/ioflo/ioflo_manuals).
[Repo ioflo hio](https://github.com/ioflo/hio)
---
title: hierarchical-composition
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hierarchical-composition
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hierarchical-composition.md
---
# hierarchical-composition
Encoding protocol that is composable in a hierarchy and enables [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md) (multiplexing and de-multiplexing) of complex streams in either text or compact binary. This allows management at scale for high-bandwidth applications.
| TBW prio2 |
Because of [count codes](https://weboftrust.github.io/WOT-terms/docs/glossary/count-code.md) and the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) - and [concatenation](https://weboftrust.github.io/WOT-terms/docs/glossary/concatenation.md) property in CESR, [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md) is possible, which then uses [multiplexing](https://weboftrust.github.io/WOT-terms/docs/glossary/multiplexing.md) (combining [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) primitives) and _de-multiplexing_ (unravelling self-framing [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md)).
---
title: hierchical-deterministic-keys
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hierchical-deterministic-keys
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hierchical-deterministic-keys.md
---
# hierchical-deterministic-keys
An HDK type is a deterministic Bitcoin wallet derived from a known [seed](https://weboftrust.github.io/WOT-terms/docs/glossary/seed.md) that allows child keys to be created from the parent key. Because the child key is generated from a known seed, a relationship between the child and parent keys is invisible to anyone without that seed.
The HD protocol (BIP 32) can generate a near-infinite number of child keys from a deterministically generated seed (chain code) from its parent, allowing you to recreate those exact same child keys as long as you have the seed.
More at [W3 source](https://www.w3.org/2016/04/blockchain-workshop/interest/robles.html)
---
title: hio
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hio
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/hio.md
---
# hio
Weightless hierarchical asynchronous coroutines and I/O in Python.
Rich Flow Based Programming Hierarchical Structured Concurrency with Asynchronous IO.
This very technical topic can best be studied further at the Github [Repository](https://github.com/ioflo/hio)
Choosing HIO complies with the asynchronous nature of KERI, the minimal sufficient means design principle of KERI and the leading KERIpy implementation.
---
title: Home
description: Welcome to the WebofTrust terms wiki!
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/Home
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/Home.md
---
# Home
The wiki also serves the glossary terms for the underlying and related techniques to ACDC, like KERI, CESR and OOBI.
There are a few [practical rules](https://wiki.trustoverip.org/display/HOME/Terms+Wikis) from the originator ToIP to get these wiki terms through their equivalent [github actions script](https://github.com/WebOfTrust/WOT-terms/actions/workflows/content-fetch-and-deploy-update-glossary.yml), please:
1. beware all new wiki items you **create**, lead to new .md files. We'd like to know
2. introduce lowercase names with spaces (they will convert into lower case names with dashes between the words)
3. start with **\## Definition** header; [example](https://github.com/WebOfTrust/WOT-terms/wiki/composable-event-streaming-representation)
4. start with uppercase abbreviations with only the "**\## See**" header; [example](https://github.com/WebOfTrust/WOT-terms/wiki/CESR)
5. don't **delete** items (i.e. .md files) but make clear they are depreciated and / or link to the new concept / term
6. don't change or **update** the name of an item single handed, for it might change the concept / meaning for other people and create dead links for those who **read** - or link to the term. Please open an issue or a PR to discuss first.
7. any other immediate updates and amendments welcome, the revisions are available for us to be able to (partially) revert if something unwanted or unexpected happens.
The _weboftrust_ wiki glossary is currently our input tool for our KERI Suite glossary. However, we regularly scrape the wiki into [KERISSE](http://kerisse.org), we add features and metadata, we connect relevant matching terms from related glossaries and finally we index it for the KERI Suite Search Engine (KERISSE).
_Have fun CRU-ing!_
'\* CRU=Create Read Update
---
title: HSM
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/HSM
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/HSM.md
---
# HSM
[Hardware security model](https://weboftrust.github.io/WOT-terms/docs/glossary/hardware-security-module.md)
---
title: I-O
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/I-O
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/I-O.md
---
# I-O
[Input output](https://weboftrust.github.io/WOT-terms/docs/glossary/input-output.md)
---
title: IANA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/IANA
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/IANA.md
---
# IANA
[Internet assigned numbers authority](https://weboftrust.github.io/WOT-terms/docs/glossary/internet-assigned-numbers-authority.md)
---
title: icp
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/icp
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/icp.md
---
# icp
icp = incept, inception
---
title: identifier-system
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/identifier-system
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/identifier-system.md
---
# identifier-system
a system for uniquely identifying (public) identities
The International Standard Name Identifier (ISNI) is an identifier system for uniquely identifying the public identities of contributors to media content such as books, television programmes, and newspaper articles. Such an identifier consists of 16 digits. It can optionally be displayed as divided into four blocks. More info on [Wikipedia page](https://en.wikipedia.org/wiki/International_Standard_Name_Identifier)
1. Completeness. Every unique object must be assigned an identifier.
2. Uniqueness. Each identifier is a unique sequence.
3. Exclusivity. Each identifier is assigned to a unique object, and to no other object.
4. Authenticity. The objects that receive identification must be verified as the objects that they are intended to be.
5. Aggregation. There must be a mechanism to aggregate all of the data, and only that data, that is properly associated with the identifier (i.e., to bundle all of the data that belong to the uniquely identified object).
6. Permanence. The identifiers and the associated data must be permanent.
7. Reconciliation. There should be a mechanism whereby the data associated with a unique, identified object in one resource can be merged with the data held in another resource, for the same unique object. This process, which requires comparison, authentication, and merging, is known as reconciliation.
8. Immutability. In addition to being permanent (i.e., never destroyed or lost), the identifier must never change (
9. Security. The identifier system should be as little vulnerable to malicious attack as possible.
10. Documentation and quality assurance. Protocols must be written for establishing the identifier system, for assigning identifiers, for protecting the system, and for monitoring the system.
11. Centrality. The subject's identifier is the central "key" to which every event for the subject is attached.
12. Autonomy. An identifier system has a life of its own.
By (_@henkvancann_) based on this [source](https://www.sciencedirect.com/topics/computer-science/identifier-system)
KERI is an thin-layered identifier system generator, offering globally portable identifiers, secure attribution to their root-of-trust, and chained verifiable credential containers (ACDC) to them.
Verifiable Credentials (VCs) and the emerging role of the LEI: Verifiable Credentials are digitally signed credentials that are not only tamper-resistant but capable of being verified in decentralized manner. vLEIs are based on the Trust over IP Authentic Chained Data Container (ACDC) specification (based on the Key Event Receipt Infrastructure (KERI) protocol ([github.com/WebOfTrust/keri](http://github.com/WebOfTrust/keri)), both Internet Engineering Task Force (IETF) draft specifications). Verifiable Credentials are digitally signed credentials that are not only tamper-resistant but capable of being verified in decentralized manner. vLEIs are based on the Trust over IP Authentic Chained Data Container (ACDC) specification (based on the Key Event Receipt Infrastructure (KERI) protocol ([github.com/WebOfTrust/keri](http://github.com/WebOfTrust/keri)), both Internet Engineering Task Force (IETF) draft specifications). More info on [GLEIF site](https://www.gleif.org/en/vlei/introducing-the-verifiable-lei-vlei)
---
title: verifiable-legal-entity-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/identifier.md
---
# verifiable-legal-entity-identifier
Verifiable credentials are issued by authorized validation agents ([QVIs](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md)) under the governance of [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md), who delegate tasks to these agents. They provide cryptographic proof that the information about a legal entity, as linked to its Legal Entity Identifier (LEI), is verifiably authentic, accurate, and up-to-date.
The v in vLEI stands for “verifiable”, but what does that mean? In this case, "verifiable" comes from “Verifiable Credential”. A verifiable credential is just a collection of information with a mechanism that allows a computer to verify that the information has not been modified and that the information was originally stated to be correct by some third party (maybe a bank or the driving license authority). Often (almost always really), the information will include a link to the entity the information is about.
[Here](https://rapidlei.com/what-is-vlei/) at Rapidlei.
---
title: identity-assurance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/identity-assurance
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/identity-assurance.md
---
# identity-assurance
The heavy-lifting to be done by a trusted (middle-man) party to establish - and then offer reputational trust. An example of such a party is [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md). Instead, KERI is for [attributional trust](https://weboftrust.github.io/WOT-terms/docs/glossary/attributional-trust.md). In the real world you need both.
Read more in source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf)
A trusted party might use out-of-band procedures to assure the identity of people (representing parties) but it's not the same as [Out-of-band Introduction](https://weboftrust.github.io/WOT-terms/docs/glossary/out-of-band-introduction.md)s (OOBIs) to establish attributional trust, which is done with KERI.
---
title: Self-sovereign identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/identity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/identity.md
---
# Self-sovereign identifier
Self-sovereign identity is a decentralized identity architecture that implements the Principles of SSI — principally that it puts the identity controller (e.g., a natural person or organization) directly in control of the identifiers and credentials they use to assert their digital identity.
Source: ToIP main glossary
The definition started in the blog "[The Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)" by Christopher Allen in 2016. has not resulted in a consensus today. While some see the ten principles of SSI that Allen proposed as the definition of SSI, he formulated them as "a departure point to provoke a discussion about what's truly important". And it is obvious that what is important differs per [party](https://essif-lab.github.io/framework/docs/terms/party).
[Source eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/self-sovereign-identity)
---
title: inception-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/inception-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/inception-event.md
---
# inception-event
an [Establishment Event](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md) that provides the incepting information needed to derive an AID and establish its initial Key state.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
An inception event is an establishment key event that represents the creation operation of an identifier, including its derivation and its initial set of controlling keys as well as other inception or configuration data for supporting infrastructure.
This is the information needed to derive an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) and establish its initial key-state.
There may be one and only one inception event operation performed on an identifier.
Source [KERI Whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
**In brief: It's the signed version of a statement containing the inception event with some extra data.**
(_@henkvancann_)
The inception data must include the public key, the identifier derivation from that public key, and may include other configuration data. The identifier derivation may be simply represented by the `derivation code`. A statement that includes the inception data with attached signature made with the private key comprises a cryptographic commitment to the derivation and configuration of the identifier that may be cryptographically verified by any entity that receives it.
A KERI inception statement is completely self-contained. No additional infrastructure is needed or more importantly must be trusted in order to verify the derivation and initial configuration (inception) of the identifier. The initial trust basis for the identifier is simply the signed inception statement.
(_SamMSmith_)
---
title: inception
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/inception
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/inception.md
---
# inception
The operation of creating an AID by binding it to the initial set of authoritative keypairs and any other associated information. This operation is made verifiable and duplicity evident upon acceptance as the inception event that begins the AID's KEL.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: internal-inconsistency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/inconsistency
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/inconsistency.md
---
# internal-inconsistency
Internal is used to describe things that exist or happen inside an [entity](https://weboftrust.github.io/WOT-terms/docs/glossary/entity.md). In our scope of digital [identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md) its (in)consistency is considered within the defining data structures and related data stores.
In [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md), you are protected against internal inconsistency by the hash chain data structure of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) because the only [authority](https://weboftrust.github.io/WOT-terms/docs/glossary/authority.md) that can sign the log is the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) itself.
---
title: indexed-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/indexed-signature
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/indexed-signature.md
---
# indexed-signature
Also called _siger_. An indexed signature attachment is used when signing anything with a multi-key autonomic identifier. The index is included as part of the attachment, so a verifier knows which of the multiple public keys was used to generate a specific signature.
Source:Philip Feairheller
An indexed signature attachment would look something like:
```
03.
```
All encoded as [qualified](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified.md) [base64](https://weboftrust.github.io/WOT-terms/docs/glossary/base64.md). A verifier would then know to use the AID’s public key located at index 3 in the list of public keys to verify the signature.
Source:Philip Feairheller
In addition, [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) signatures can also be attached as indexed signatures. So a verifier can determine which witness signed a particular [receipt](https://weboftrust.github.io/WOT-terms/docs/glossary/receipt.md). This is useful when witnesses are receipting an event and only attaching their own signature. The [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) knows which witness signed the receipt by looking up the index in their list of witnesses for that event.
Source:Philip Feairheller
---
title: indirect-mode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/indirect-mode
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/indirect-mode.md
---
# indirect-mode
Two primary trust modalities motivated the KERI design, One of these is the _indirect_ (one-to-many) mode, which depends on witnessed key event receipt logs (KERL) as a secondary root-of-trust for validating events. This gives rise to the acronym KERI for key event receipt infrastructure.
The indirect mode extends that trust basis with witnessed key event receipt logs ([KERL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md)) for validating events. The security and accountability guarantees of indirect mode are provided by [KA2CE](https://weboftrust.github.io/WOT-terms/docs/glossary/KA2CE.md) or KERI’s Agreement Algorithm for Control Establishment among a set of witnesses.
[Source: Abstract KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
To protect a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) when engaging with some other controller’s identifier, be it [verification](https://weboftrust.github.io/WOT-terms/docs/glossary/verification.md), control authority establishment, or [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection, are based on an ability to _replay_ the sequence of key events (key event history or log) of that identifier. There are two main operational modes for providing replay capability that are distinguished by the degree of availability of the identifier’s controller when creating and promulgating the key events.
With _indirect mode_, the promulgation of events to a validator may happen even when the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) is not attached to the network and therefore not able to communicate directly with a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md). Indirect mode supports high (nearly continuous) availability of the key event history to any validator. This means that other components must be trusted to promulgate key events when the controller is not attached to the network. Indirect mode is compatible with identifiers for one-to-many exchanges or any-wise relationships (a controller with any others). A single indirect mode identifier may be used for a public service or business or otherwise when building brand and reputation in that identifier is important. An indirect mode identifier may also be used for private one-to-one or select groups but where intermittent availability is not tolerable.
More in [Source: chapter Protocol Operational Modes in KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
The protocol may operate in two basic modes, called direct and indirect. The availability and consistency attack surfaces are different for the two modes and hence the mitigation properties of the protocol are likewise mode specific. [Source: chapter Security concerns in KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
[Direct mode](https://weboftrust.github.io/WOT-terms/docs/glossary/direct-mode.md)
---
title: input-output
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/input-output
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/input-output.md
---
# input-output
In [computing](https://en.wikipedia.org/wiki/Computing), input/output (I/O, or informally io or IO) is the communication between an information processing system, such as a [computer](https://en.wikipedia.org/wiki/Computer), and the outside world, possibly a human or another information processing system. [Inputs](https://en.wikipedia.org/wiki/Information) are the signals or [data](https://en.wikipedia.org/wiki/Data_\(computing\)) received by the system and outputs are the signals or data sent from it. The term can also be used as part of an action; to "perform I/O" is to perform an [input or output operation](https://en.wikipedia.org/wiki/I/O_scheduling).
[Input/Output](https://en.wikipedia.org/wiki/Input/output)
---
title: inquisitor
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/inquisitor
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/inquisitor.md
---
# inquisitor
In the ACDC context it's a general term for someone (in a validating role) that launches an inquiry at some KERI [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md).
An inquisitor was an [official](https://en.wikipedia.org/wiki/Official) (usually with [judicial](https://en.wikipedia.org/wiki/Judicial) or investigative functions) in an [inquisition](https://en.wikipedia.org/wiki/Inquisition) – an organization or program intended to eliminate [heresy](https://en.wikipedia.org/wiki/Heresy) and other things contrary to the [doctrine](https://en.wikipedia.org/wiki/Doctrine) or teachings.
Source: [Wikipedia](https://en.wikipedia.org/wiki/Inquisitor)
---
title: verified-integrity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/integrity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/integrity.md
---
# verified-integrity
A mechanism that can unambiguously assess whether the information is/continues to be whole, sound and unimpaired
- In KERI's secure attribution focus integrity is verified by [internal consistency](https://weboftrust.github.io/WOT-terms/docs/glossary/internal-inconsistency.md) of [KE(R)L](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md) and [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) plus [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection.
- In ACDC the [self addressing identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md) (SAID) takes of verified integrity at all times by design
- The streaming protocol CESR has verifiable integrity due to it's code tables and round-robin [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md).
[integrity](https://weboftrust.github.io/WOT-terms/docs/glossary/integrity.md)
[(complementary) integrity verification](https://weboftrust.github.io/WOT-terms/docs/glossary/complementary-integrity-verification.md)
---
title: interaction-event
description: Non-establishment Event that anchors external data to the key-state as established by the most recent prior establishment event.
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interaction-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interaction-event.md
---
# interaction-event
Non-establishment Event that anchors external data to the key-state as established by the most recent prior establishment event.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: non-interactive-authentication-design
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interactive-authentication-design
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interactive-authentication-design.md
---
# non-interactive-authentication-design
A group of approaches having non-interactive mechanisms that pose unique problems because they do not allow a challenge response reply handshake. A request is submitted that is self-authenticating without additional interaction.
The main benefits of non-interactive authentication are scalability and path independent end-to-end verifiability. These benefits become more important in decentralized applications that employ [zero-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/zero-trust.md) architectures.
More in [source](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw) Keri Request Authentication Mechanism (KRAM) by Samuel Smith
[Interactive authentication design](https://weboftrust.github.io/WOT-terms/docs/glossary/interactive-authentication-design.md)
---
title: interceptor
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interceptor
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interceptor.md
---
# interceptor
a [keria](https://weboftrust.github.io/WOT-terms/docs/glossary/keria.md) class that allows to push events that are happening inside the cloud agent to other backend processes. It is similar to the notifier class but it is used to "notify" other web services.
[https://github.com/WebOfTrust/keria/pull/67](https://github.com/WebOfTrust/keria/pull/67)
---
title: Interleaved Serialisation
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interleaved-serialisation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interleaved-serialisation.md
---
---
title: internal-inconsistency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/internal-inconsistency
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/internal-inconsistency.md
---
# internal-inconsistency
Internal is used to describe things that exist or happen inside an [entity](https://weboftrust.github.io/WOT-terms/docs/glossary/entity.md). In our scope of digital [identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md) its (in)consistency is considered within the defining data structures and related data stores.
In [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md), you are protected against internal inconsistency by the hash chain data structure of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) because the only [authority](https://weboftrust.github.io/WOT-terms/docs/glossary/authority.md) that can sign the log is the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) itself.
---
title: internet-assigned-numbers-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/internet-assigned-numbers-authority
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/internet-assigned-numbers-authority.md
---
# internet-assigned-numbers-authority
is the organization that oversees the allocation of [IP](https://www.techtarget.com/searchunifiedcommunications/definition/Internet-Protocol) addresses to internet service providers ([ISPs](https://www.techtarget.com/whatis/definition/ISP)).
[Source](https://www.techtarget.com/whatis/definition/IANA-Internet-Assigned-Numbers-Authority)
In addition to global [IP addressing](https://www.techtarget.com/whatis/definition/IP-address-Internet-Protocol-Address), IANA is also responsible for domain name system ([DNS](https://www.techtarget.com/searchnetworking/definition/domain-name-system)) root zone management, autonomous system numbers and any "unique parameters and protocol values" for the internet community.
[Source](https://www.techtarget.com/whatis/definition/IANA-Internet-Assigned-Numbers-Authority)
[Wikipedia](https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority)
---
title: interoperability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interoperability
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interoperability.md
---
# interoperability
Interoperability is a characteristic of a product or system to work with other products or systems. While the term was initially defined for [information technology](https://en.wikipedia.org/wiki/Information_technology) or [systems engineering](https://en.wikipedia.org/wiki/Systems_engineering) services to allow for information exchange.
[More on source Wikipedia](https://en.wikipedia.org/wiki/Interoperability)
[Identifier interoperability](https://www.doi.org/factsheets/Identifier_Interoper.html) enables users to re-use these identifiers (and their associated data) across different applications. Such interoperability of identifiers encompasses not only technical aspects of interoperability but consideration of the purpose and community of use of the identifiers.
[Source](https://www.doi.org/factsheets/Identifier_Interoper.html)
If two or more systems use common [data formats](https://en.wikipedia.org/wiki/File_format) and [communication protocols](https://en.wikipedia.org/wiki/Communication_protocol) and are capable of communicating with each other, they exhibit syntactic interoperability. [XML](https://en.wikipedia.org/wiki/XML) and [SQL](https://en.wikipedia.org/wiki/SQL) are examples of common data formats and protocols. Lower-level data formats also contribute to syntactic interoperability, ensuring that alphabetical characters are stored in the same [ASCII](https://en.wikipedia.org/wiki/ASCII) or a [Unicode](https://en.wikipedia.org/wiki/Unicode) format in all the communicating systems.
[More on source Wikipedia](https://en.wikipedia.org/wiki/Interoperability)
Beyond the ability of two or more computer systems to exchange information, [semantic interoperability](https://en.wikipedia.org/wiki/Semantic_interoperability) is the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end users of both systems.
[Cross-domain interoperability](https://en.wikipedia.org/wiki/Cross-domain_interoperability) involves multiple social, organizational, political, legal entities working together for a common interest or information exchange.
[More on source Wikipedia](https://en.wikipedia.org/wiki/Interoperability)
---
title: interoperable
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interoperable
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/interoperable.md
---
# interoperable
[Interoperability](https://weboftrust.github.io/WOT-terms/docs/glossary/interoperability.md)
---
title: ip-address
description: An Internet Protocol address (IP address) is a numerical label such as '192.0.2.1' that is connected to a computer network that uses the Internet Protocol for communication. An IP address serves two main functions: network interface identification) and location addressing.
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ip-address
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ip-address.md
---
# ip-address
An Internet Protocol address (IP address) is a numerical label such as '192.0.2.1' that is connected to a [computer network](https://en.wikipedia.org/wiki/Computer_network) that uses the [Internet Protocol](https://en.wikipedia.org/wiki/Internet_Protocol) for communication. An IP address serves two main functions: network interface [identification](https://en.wikipedia.org/wiki/Identification_\(information\)) and location [addressing](https://en.wikipedia.org/wiki/Network_address).
Much more on source [Wikipedia](https://en.wikipedia.org/wiki/IP_address)
---
title: IPEX
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/IPEX
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/IPEX.md
---
# IPEX
[Issuance and presentation exchange protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/issuance-and-presentation-exchange-protocol.md)
---
title: iss
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/iss
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/iss.md
---
# iss
iss = vc issue, verifiable credential issuance
---
title: issuance-and-presentation-exchange-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuance-and-presentation-exchange-protocol
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuance-and-presentation-exchange-protocol.md
---
# issuance-and-presentation-exchange-protocol
provides a uniform mechanism for the issuance and presentation of ACDCs in a securely attributable manner.
A single protocol is able to work for both types of exchanges ([issuance](https://weboftrust.github.io/WOT-terms/docs/glossary/issuance-exchange.md) and [presentation](https://weboftrust.github.io/WOT-terms/docs/glossary/presentation-exchange.md)) by recognizing that all exchanges (both issuance and presentation) may be modeled as the disclosure of information by a [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) to a [Disclosee](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md).
The _difference_ between exchange types is _the information disclosed not the mechanism for disclosure_.
([Source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md))
---
title: issuance-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuance-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuance-event.md
---
# issuance-event
The initial transaction event log event anchored to the issuing AID’s key event log that represents the issuance of an ACDC credential.
Source: Philip Feairheller.
It's a sort of "[inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md)" of a verifiable credential.
---
title: issuance-exchange
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuance-exchange
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuance-exchange.md
---
# issuance-exchange
A special case of a [presentation exchange](https://weboftrust.github.io/WOT-terms/docs/glossary/presentation-exchange.md) where the [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) is the [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) of the origin (Primary) ACDC of the [DAG](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) formed by the set of chained [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md)s so disclosed.
In an issuance exchange, when the origin ACDC has an [Issuee](https://weboftrust.github.io/WOT-terms/docs/glossary/issuee.md), the [Disclosee](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md) MAY also be the origin ACDC's Issuee.
---
title: issuee
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuee
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuee.md
---
# issuee
a role of an entity to which the claims of an ACDC are asserted.
Source: Dr. S. Smith
An [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) is optionally issued to the Issuee. When present, the Issuee identifier ([AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md)) appears at the top level of the attribute section or in the attribute list at the top level of the attribute aggregate section of the ACDC.
Each ACDC MUST have an [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) and MAY have an [Issuee](https://weboftrust.github.io/WOT-terms/docs/glossary/issuee.md). The set of [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md)s so disclosed in a presentation exchange MUST be chained. This set of chained ACDCs define a [directed acyclic graph](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
---
title: qualified-vlei-issuer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/issuer.md
---
# qualified-vlei-issuer
The contracting party to the vLEI Issuer Qualification Agreement that has been qualified by GLEIF as a Qualified vLEI Issuer.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
Is an authoritative role at the GLEIF organization that is mandated to issue [vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) credentials to others.
---
title: ixn
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ixn
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ixn.md
---
# ixn
[JSON](https://weboftrust.github.io/WOT-terms/docs/glossary/JSON.md) field name (attribute) for Interaction Event; its content (value) contains a hash pointer. All [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) events are anchored in a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) in either ixn ([interaction](https://weboftrust.github.io/WOT-terms/docs/glossary/interaction-event.md)) or [rot](https://weboftrust.github.io/WOT-terms/docs/glossary/rot.md) ([rotation event](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md)s). This is the foundation enabling a verifiable credential protocol to be built on top of KERI.
[Source](https://kentbull.com/2023/03/09/keri-tutorial-series-treasure-hunting-in-abydos-issuing-and-verifying-a-credential-acdc/) Kent Bull 2023
[rot](https://weboftrust.github.io/WOT-terms/docs/glossary/rot.md)
---
title: Javascript Object Notation (JSON)
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/javascript-object-notation-(JSON)
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/javascript-object-notation-(JSON).md
---
---
title: javascript-object-signing-and-encryption
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/javascript-object-signing-and-encryption
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/javascript-object-signing-and-encryption.md
---
# javascript-object-signing-and-encryption
is a framework intended to provide a method to securely transfer claims (such as authorization information) between parties. The JOSE framework provides a collection of specifications to serve this purpose.
Related: `JWK`, `JWT`. [More info](https://jose.readthedocs.io/en/latest/)
---
title: JOSE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/JOSE
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/JOSE.md
---
# JOSE
[Javascript object signing and encryption](https://weboftrust.github.io/WOT-terms/docs/glossary/javascript-object-signing-and-encryption.md)
---
title: JSON
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/JSON
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/JSON.md
---
# JSON
[JavaScript Object Notation](https://weboftrust.github.io/WOT-terms/docs/glossary/javascript-object-notation.md)
---
title: judge
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/judge
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/judge.md
---
# judge
A judge is an entity or component that examines the entries of one or more [KERLs](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md) and DELs of a given identifier to validate that the event history is from a non-[duplicitous](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) controller and has been witnessed by a sufficient number of non-duplicitous [witnesses](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) such that it may be trusted or conversely not-trusted by a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md).
A judge determines current \[authoritative\] key set for identifier from the [key event receipt logs](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md) from a set of witnesses. Judges transmit the 'judgement' of watchers concerning duplicity.
Example AT&T vs T-Mobile. The only "fault" that is apparent, is an attack on the KEL. And that can only occur via key compromise. So a successful multi-threshold attack causing [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) is the only thing [watchers](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) are looking for.
So even competitors will want to share across the entire ecosystem. Similar to certificate transparency, all competitors in the internet hosting space share the information with each other because it is in their best interest to eliminate fraud / duplicity.
Paraphrased by @henkvancann based on [source Samuel Smith / Phil Feairheller](https://hackmd.io/-soUScAqQEaSw5MJ71899w?view#2022-09-06)
---
title: juror
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/juror
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/juror.md
---
# juror
A juror has the basic task of performing [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection on events and event receipts.
---
title: jury
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/jury
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/jury.md
---
# jury
The jury is the set of entities or components acting as [jurors](https://weboftrust.github.io/WOT-terms/docs/glossary/juror.md).
---
title: KA2CE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KA2CE
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KA2CE.md
---
# KA2CE
[KERI agreement algorithm for control establishment](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-agreement-algorithm-for-control-establishment.md)
---
title: KAACE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KAACE
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KAACE.md
---
# KAACE
[KERI agreement algorithm for control establishment](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-agreement-algorithm-for-control-establishment.md)
---
title: KAPI
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KAPI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KAPI.md
---
# KAPI
Application programmer interfaces (APIs) for the various components in the KERI ecosystem such as Controllers, Agents, Witnesses, Watchers, Registrars etc need by which they can share information. The unique properties of the KERI protocol require APIs that preserve those properties. We call the set of APIs the KERI API.
[Source Kapi Repo](https://github.com/WebOfTrust/kapi/blob/main/kapi.md)
---
title: keep
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keep
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keep.md
---
# keep
Is KERI's and ACDC's user interface that uses the keripy agent for its backend. It uses the REST API exposed from the keripy agent.
Source: Philip Feairheller
Keep is a task orientated application for managing [AIDs](https://github.com/WebOfTrust/ietf-keri) in ecosystems, e.g. the [vLEI Ecosystem](https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei).
Keep can be used to:
- establish and manage local AIDs
- create, join and manage distributed Multi-Sig AIDs (with or without delegation)
- issue and revoke credentials specified within the vLEI Ecosystem
More info on [Github repo](https://github.com/WebOfTrust/keep) of Keep.
---
title: KEL
description: A Key Event Log.
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KEL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KEL.md
---
# KEL
A Key Event Log.
[Key Event Log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md)
---
title: keri-agreement-algorithm-for-control-establishment
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-agreement-algorithm-for-control-establishment
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-agreement-algorithm-for-control-establishment.md
---
# keri-agreement-algorithm-for-control-establishment
Agreement on an event in a key event log [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md) means each [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) has observed the exact version of the event and each witness’ [receipt](https://weboftrust.github.io/WOT-terms/docs/glossary/receipt.md) has been received by every other witness.
Control establishment means that the set of agreeing witnesses, along with the controller of the identifier and associated keypairs, create a verifiable way to establish control authority for an identifier by reading all of the events in the KEL that have been agreed upon by the witnesses and the controller.
'KA2CE' '[KA2CE](https://weboftrust.github.io/WOT-terms/docs/glossary/KA2CE.md)' and 'KAACE'.
The agreement with KA2CE is as follows: "... the controller first creates its own receipt of the event and then promulgates the receipted event to witnesses in order to gather their promulgated receipts.
In this algorithm, an agreement consists of a specific version of an event with verifiable receipts. (signatures) from the controller and a set of witnesses.
A state of agreement about a version of an event with respect to a set of witnesses means that each witness in that set has witnessed the same version of that event, and each witness’ receipt in that set has been promulgated to every other witness in that set."
Source [KERI Whitepaper Section 11.4.2 Agreement](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
A newly invented algorithm that is a simplification of PBFT class algorithms, separation of control of distributed consensus using distinct promulgation (witness) and confirmation (watcher) networks (new invention), but many non-BFT consensus algorithms do something similar, and one BFT algorithm, Stellar, does something similar but not the same.
What if PBFT and Stellar had a baby missing liveness and total ordering but had safety and were completely decentralized, portable, and permissionless? It would be named KERI.
(SamMSmith)
---
title: keri-command-line-interface
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-command-line-interface
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-command-line-interface.md
---
# keri-command-line-interface
Command line tool used to create identifiers, manage keys, query for KELs and participate in delegated identifiers or multi-signature group identifiers. It also includes operations for running witnesses, watchers and cloud agents to establish a cloud presence for any identifier.
Most commands require a “name” parameter which references a named Habitat (think wallet) for performing the operation.
[IIW34 presentation slides](https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68_0_5)
---
title: keri-event-stream
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-event-stream
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-event-stream.md
---
# keri-event-stream
A stream of verifiable KERI data, consisting of the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) and other data such as a [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md). This data is a CESR event stream (TODO: link to IANA application/cesr media type) and may be serialized in a file using [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md) encoding. We refer to these _CESR stream resources_ as KERI event streams to simplify the vocabulary.
Source `did:webs` [ToIP specification](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
---
title: keri-improvement-doc
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-improvement-doc
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-improvement-doc.md
---
# keri-improvement-doc
These docs are modular so teams of contributors can independently work and create PRs of individual KIDs; KIDs answer the question "how we do it". We add commentary to the indivudual KIDs that elaborate on the why. It has been split from the how to not bother implementors with the why.
---
title: keri-ox
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-ox
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-ox.md
---
# keri-ox
The RUST programming-language implementation of the [KERI](https://github.com/trustoverip/acdc/wiki/KERI) protocol.
---
title: keri-request-authentication-method
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-request-authentication-method
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-request-authentication-method.md
---
# keri-request-authentication-method
All requests from a web client must use KRAM (KERI Request Authentication Method) for replay attack protection. The method is essentially based on each request body needing to include a date time string field in ISO-8601 format that must be within an acceptable time window relative to the server's date time. See the [KRAM Github repo](https://github.com/WebOfTrust/kram/blob/main/README.md)
Source [SKWA GitHub repo](https://github.com/WebOfTrust/skwa), more info in [HackMD.io write-up](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw)
[SKWA](https://weboftrust.github.io/WOT-terms/docs/glossary/SKWA.md)
---
title: keri-suite-search-engine
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-suite-search-engine
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-suite-search-engine.md
---
# keri-suite-search-engine
KERISSE is the Docusaurus [self-education site](https://weboftrust.github.io/WOT-terms/) of Web-of-Trust GitHub repo with Typesense search facilities. Because of its focus on well-versed developers in the field of [SSI](https://weboftrust.github.io/WOT-terms/docs/glossary/SSI.md) and the support of their journey to understand the structure of the code and how things work in the [KERI suite](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-suite.md) it's more a search engine that drills down on documentation.
[kerific](https://weboftrust.github.io/WOT-terms/docs/glossary/kerific.md) is a front-end tool that show all available glossary-definition in [KERISSE](https://weboftrust.github.io/WOT-terms/docs/glossary/KERISSE.md) for matching words in any web text; combined in the [Dictionary SSI](https://weboftrust.github.io/keridoc/docs/dictionary?level=2). This is based on a large JSON file
---
title: keri-suite
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-suite
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keri-suite.md
---
# keri-suite
The _KERI suite_ is the set of inter-related developments (KERI, ACDC, OOBI, CESR, IPEX, etc) under the Web-of -Trust user on Github
---
title: KERI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KERI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KERI.md
---
# KERI
[Key event receipt infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md)
---
title: keria
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keria
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keria.md
---
# keria
KERI Agent in the cloud. The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces.
1. Boot Interface - Exposes one endpoint for Agent Worker initialization.
2. Admin Interface - The REST API for command and control operations from the Signify Client.
3. KERI Protocol Interface - CESR over HTTP endpoint for KERI protocol interactions with the rest of the world.
More at [Source Github repo](https://github.com/WebOfTrust/keria/blob/main/docs/protocol.md)
---
title: keride
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keride
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keride.md
---
# keride
is a _Rust_ programming language library for [Key Event Receipt Infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md). Among its features is [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md), signing, prefixing, pathing, and parsing.
More on [Github repo](https://github.com/WebOfTrust/keride)
---
title: keridemlia
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keridemlia
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keridemlia.md
---
# keridemlia
It is a contraction of [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md) and [Kademlia](https://en.wikipedia.org/wiki/Kademlia). It's the distributed database of Witness IP-addresses based on a [Distributed Hash Table](https://weboftrust.github.io/WOT-terms/docs/glossary/distributed-hash-table.md). It also does the CNAME - stuff that [Domain Name](https://weboftrust.github.io/WOT-terms/docs/glossary/domain-name.md) Services (DNS) offers for KERI: the mapping between an identifier and it's controller AID stored in the KEL to its current wittness AID and the wittness AID to the IP address.
(@henkvancann)
---
title: kerific
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/kerific
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/kerific.md
---
# kerific
_kerific_ is a front plugin or extension that currently only works for Chrome and Brave. It matches words in any text on the web that is parseable for kerific and offers buttons to various glossaries and definitions in the [SSI](https://weboftrust.github.io/WOT-terms/docs/glossary/self-sovereign-identity.md) field.
All glossaries that [KERISSE](https://weboftrust.github.io/WOT-terms/docs/glossary/KERISSE.md) is allowed to scrape are combined in the [Dictionary SSI](https://weboftrust.github.io/keridoc/docs/dictionary?level=2). This is based on a large JSON file, which kerific uses to match words in any text and serve the combined glossaries.
It is in the [Chrome Webstore](https://chromewebstore.google.com/detail/kerific/ckbmkbbmnfbeecfmoiohobcdmopekgmp?hl=nl)
---
title: KERIMask
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KERIMask
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KERIMask.md
---
# KERIMask
A wallet similar to _MetaMask_, the manifestation will be a browser extension and it will connect to KERIA servers in order for a person to control AIDs from their browser.
As of October 2023 KERIMask is only planned.
[Signify keria request authentication protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/signify-keria-request-authentication-protocol.md)
---
title: Slack Archive
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keripy
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keripy.md
---
# Slack Archive
---
title: KERISSE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KERISSE
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KERISSE.md
---
# KERISSE
[KERI suite search engine](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-suite-search-engine.md)
---
title: KERL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KERL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KERL.md
---
# KERL
[Key event receipt log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md)
---
title: kever
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/kever
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/kever.md
---
# kever
Kever is a key event verifier.
---
title: key-compromise
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-compromise
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-compromise.md
---
# key-compromise
Basically there are three infrastructures that are included in “key management” systems that must be protected:
- Key pair creation and storage
- Event signing
- Event signature verification So when we say “key compromise” we really mean compromise of one of those three things.
More in the security sections of [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf)
---
title: key-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-log
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-log.md
---
# key-event-log
a Verifiable data structure that is a backward and forward chained, signed, append-only log of key events for an AID. The first entry in a KEL must be the one and only Inception event of that AID.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
KELs are hash-chained Key Events. These are blockchains in a narrow definition, but not in the sense of ordering (not ordered) or global consensus mechanisms (which is not needed). (SamMSmith)
A KEL is KERI's VDS: the proof of key state of its identifier.
---
title: key-event-message
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-message
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-message.md
---
# key-event-message
Message whose body is a key event and whose attachments may include signatures on its body.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: key-event-receipt-infrastructure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-receipt-infrastructure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-receipt-infrastructure.md
---
# key-event-receipt-infrastructure
or the KERI protocol, is an identity system-based secure overlay for the Internet.
Source: Dr. S.Smtih
It's a new approach to decentralized identifiers and decentralized key management that promises significant benefits for `SSI` (self-sovereign identity) and `ToIP` (Trust over IP) infrastructure.
(_@drummondreed_)
KERI is an identifier system that fixes the internet. It's a fully decentralized permission-less key management architecture. It solves the `secure attribution problem` to its identifiers and allows portability.
(_@henkvancann_)
While attribution has always been a non-exact science, we could come as close to attribution as “beyond a reasonable doubt”, those days are over with KERI.
KERI provides a trust spanning layer for the internet, because **the protocol solves the secure attribution problem** in a general, portable, fully decentralized way. There are more types of trust IN KERI but they all depend on the most important _attributive_ trust. From KERI we've learned that _secure attribution_ is the essential problem for _any_ `identifier system` to solve.
---
title: key-event-receipt-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-receipt-log
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-receipt-log.md
---
# key-event-receipt-log
a key event receipt log is a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/kel.md) that also includes all the consistent key event receipt [Message](https://weboftrust.github.io/WOT-terms/docs/glossary/message.md)s created by the associated set of witnesses. See annex [Key event receipt log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md).
Source: Dr. S.Smith
Signed Key Events, keeping track of establishment events. To begin with the inception event and any number of rotation events. We call that the establishment subsequence. The Key Event Receipt Logs are built from receipts of events signed by the witnesses of those events (these are called commitments); these are also append-only but not hash-chained. (@henkvancann)
---
title: key-event-receipt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-receipt
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event-receipt.md
---
# key-event-receipt
message whose body references a Key event and whose attachments must include one or more signatures on that Key event.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: key-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-event.md
---
# key-event
Concretely, it is the serialized data structure of an entry in the Key event log (KEL) for an AID. Abstractly, the data structure itself. Key events come in different types and are used primarily to establish or change the authoritative set of keypairs and/or anchor other data to the authoritative set of keypairs at the point in the KEL actualized by a particular entry.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
Events happening to controlling keys of an identifier recorded in a Key Event Log (KEL).
A _key event_ is data structure that consist of a header (Key Event header), a configuration section (Key Event Data spans Header and configuration) and signatures (Key event Message spans Data and signatures)
(_@henkvancann_)
---
title: key-management
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-management
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-management.md
---
# key-management
management of cryptographic keys in a crypto-system. This includes dealing with the generation, exchange, storage, use, crypto-shredding (destruction) and replacement of keys (also [rotation](#key-rotation)). It includes cryptographic protocol design, key servers, user procedures, and other relevant protocols.
Successful key management is critical to the _security_ of a crypto-system. It is the more challenging side of cryptography in a sense that it involves aspects of social engineering such as system policy, user training, organizational and departmental interactions, and coordination between all of these elements, in contrast to pure mathematical practices that can be automated.
More on [wikipedia](https://en.wikipedia.org/wiki/Key_management)
---
title: key-pair
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-pair
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-pair.md
---
# key-pair
is a private key and its corresponding public key resulting from a one-way crypto-graphical function; a key pair is used with an asymmetric-key (public-key) algorithm in a so called [Public Key Infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/public-key-infrastructure.md) (PKI).
---
title: key-state
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-state
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-state.md
---
# key-state
a set of currently authoritative keypairs for an AID and any other information necessary to secure or establish control authority over an AID. This includes current keys, prior next key digests, current thresholds, prior next thresholds, witnesses, witness thresholds, and configurations.
A key state of an AID is first established through an inception event and may be altered by subsequent rotation events.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
A set of authoritative keys for an AID and other essential information necessary to establish, evolve, verify, and validate control-signing authority for that AID. This information includes the current public keys and their thresholds (for a multi-signature scheme); pre-rotated key digests and their thresholds; [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md)es and their thresholds; and configurations. An AID’s key state is first established through its [inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md) and may evolve via subsequent [rotation event](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md)s. Thus, an AID’s key state is time-dependent.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: key-stretching
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-stretching
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-stretching.md
---
# key-stretching
In [cryptography](https://en.wikipedia.org/wiki/Cryptography), key stretching techniques are used to make a possibly weak [key](https://en.wikipedia.org/wiki/Key_\(cryptography\)), typically a [password](https://en.wikipedia.org/wiki/Password) or [passphrase](https://en.wikipedia.org/wiki/Passphrase), more secure against a [brute-force attack](https://en.wikipedia.org/wiki/Brute-force_attack) by increasing the resources (time and possibly space) it takes to test each possible key.
Passwords or passphrases created by humans are often short or predictable enough to allow [password cracking](https://en.wikipedia.org/wiki/Password_cracking), and key stretching is intended to make such attacks more difficult by complicating a basic step of trying a single password candidate. Key stretching also improves security in some real-world applications where the key length has been constrained, by mimicking a longer key length from the perspective of a brute-force attacker.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Key_stretching)
---
title: key-transparency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-transparency
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key-transparency.md
---
# key-transparency
provides a lookup service for generic records and a public, tamper-proof audit log of all record changes. While being publicly auditable, individual records are only revealed in response to queries for specific IDs.
- Key Transparency can be used as a _public key discovery service_ to authenticate users and provides a mechanism to keep the service accountable.
- Key Transparency empowers account owners to reliably see what public keys have been associated with their account, and it can be used by senders to see how long an account has been active and stable before trusting it. [Source](https://github.com/google/keytransparency/)
Key Transparency does this by using piece of blockchain technology called a Merkle Tree.
More on [Stackexchange](https://security.stackexchange.com/questions/149125/how-does-key-transparency-work) how key transparency works.
(_@henkvancann_)
---
title: stale-key
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/key.md
---
# stale-key
A stale key is an outdated or expired encryption key that should no longer be used for securing data
[Stale (key) event](https://weboftrust.github.io/WOT-terms/docs/glossary/stale-event.md)
---
title: keystore
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keystore
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/keystore.md
---
# keystore
A keystore in KERI is the encrypted data store that hold the private keys for a collection of AIDs.
Source: Philip Feairheller.
KERI explicitly distinguishes [keystore](https://weboftrust.github.io/WOT-terms/docs/glossary/keystore.md) and [wallet](https://weboftrust.github.io/WOT-terms/docs/glossary/wallet.md); the latter being a superset of the former. [Keep](https://weboftrust.github.io/WOT-terms/docs/glossary/keep.md) is KERI's and ACDC's user interface with Keripy agent API as a back end.
A [Java Keystore](https://en.wikipedia.org/wiki/Java_KeyStore) is a non-related concept!
---
title: KID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KID.md
---
# KID
[KERI improvement doc](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-improvement-doc.md)
---
title: kli
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/kli
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/kli.md
---
# kli
[KERI command line interface](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-command-line-interface.md)
---
title: KRAM
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KRAM
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/KRAM.md
---
# KRAM
[KERI Request Authentication Method](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-request-authentication-method.md)
---
title: ksn
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ksn
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ksn.md
---
# ksn
ksn = state, key state notice
---
title: large-language-model
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/large-language-model
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/large-language-model.md
---
# large-language-model
A large language model (LLM) is a [language model](https://en.wikipedia.org/wiki/Language_model) consisting of a [neural network](https://en.wikipedia.org/wiki/Artificial_neural_network) with many parameters (typically billions of weights or more), trained on large quantities of unlabeled text using [self-supervised learning](https://en.wikipedia.org/wiki/Self-supervised_learning) or [semi-supervised learning](https://en.wikipedia.org/wiki/Semi-supervised_learning).
More on [Source Wikipedia](https://en.wikipedia.org/wiki/Large_language_model)
---
title: lead-bytes
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/lead-bytes
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/lead-bytes.md
---
# lead-bytes
In order to avoid confusion with the use of the term [pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pad.md) character, when [pre-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-pad.md)ding with bytes that are not replaced later, we use the term **lead bytes**. So lead-bytes are added "pre-conversion".
The term [pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pad.md) may be confusing not merely because both ways use a type of padding but it is also true that the number of pad characters when padding _post-conversion_ equals the number of lead bytes when padding _pre-conversion_.
---
title: ledger-backer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ledger-backer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ledger-backer.md
---
# ledger-backer
A [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) in KERI that is ledger-registered. It's a type of [backer](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md) that proof its authenticity by a signing key anchored to the public key of a data item on a (public) blockchain.
---
title: legal-entity-engagement-context-role-vlei-credential-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legal-entity-engagement-context-role-vlei-credential-governance-framework
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legal-entity-engagement-context-role-vlei-credential-governance-framework.md
---
# legal-entity-engagement-context-role-vlei-credential-governance-framework
A document that details the requirements for [vLEI Role Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-role-credential.md) **issued to** representatives of a Legal Entity _in other than official roles_ but in functional or other context of engagement.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
- [Legal entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md)
- [Engagement context role (ECR)](https://weboftrust.github.io/WOT-terms/docs/glossary/engagement-context-role.md)
- [vLEI credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md)
- [Governance framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md)
---
title: legal-entity-official-organizational-role-vlei-credential-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legal-entity-official-organizational-role-vlei-credential-governance-framework
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legal-entity-official-organizational-role-vlei-credential-governance-framework.md
---
# legal-entity-official-organizational-role-vlei-credential-governance-framework
A document that details the requirements for [vLEI Role Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-role-credential.md) **issued to** official representatives of a Legal Entity.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
- [Legal entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md)
- [Official organizational role (OOR)](https://weboftrust.github.io/WOT-terms/docs/glossary/official-organizational-role.md)
- [vLEI credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md)
- [Governance framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md)
---
title: legal-entity-vlei-credential-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legal-entity-vlei-credential-governance-framework
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legal-entity-vlei-credential-governance-framework.md
---
# legal-entity-vlei-credential-governance-framework
A _document_ that details the requirements for vLEI Credential **issued by** a [Qualified vLEI Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified-vlei-issuer.md) to a [Legal Entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md).
---
title: legal-entity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legal-entity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legal-entity.md
---
# legal-entity
Unique parties that are legally or financially responsible for the performance of financial transactions or have the legal right in their jurisdiction to enter independently into legal contracts.
As defined in ISO 17442:2020, includes, but is not limited to, the unique parties above, regardless of whether they are incorporated or constituted in some other way (e.g., trust, partnership, contractual). It includes governmental organizations and supranationals and individuals when acting in a business capacity but excludes natural persons. It also includes international branches.
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: legitimized-human-meaningful-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legitimized-human-meaningful-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/legitimized-human-meaningful-identifier.md
---
# legitimized-human-meaningful-identifier
An [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) and its associated self-certifying trust basis gives rise to a trust domain for associated cryptographically verifiable non-repudiable statements. Every other type of identifier including human meaningful identifiers may then be secured in this resultant trust domain via an [end-verifiable](https://weboftrust.github.io/WOT-terms/docs/glossary/end-verifiable.md) [authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/authorization.md). This authorization legitimizes that human meaningful identifier as an LID through its association with an AID. The result is a secured trust domain specific identifier couplet of aid|lid.
Human meaningfulness has two limiting characteristics: _scarcity_ and _security_. Scarcity exhibits itself in various undesirable ways such as name squatting, or race conditions to register or otherwise assert control. More importantly, there is no inherent security property of a human meaningful identifier. This makes them insecure by default. Happily an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md) comes to rescue.
The trust domain of an AID provides a context in which to interpret the appearance of any LID. The AID is implied by the context. This means that the AID may not need to be prepended or appear with the LID. This allows the human meaningfulness of the LID to exhibit itself without being encumbered by the AID.
This model of an _aid|lid couplet_ unifies all desirable identifier properties into one identifier system model. The AID part provides the security infrastructure while the LID part provides the application specific human meaningfulness. The connection between the two is provided by a legitimizing authorization represented by the |.
---
title: vLEI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LEI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LEI.md
---
# vLEI
[Verifiable legal entity identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-legal-entity-identifier.md)
---
title: levels-of-assurance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/levels-of-assurance
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/levels-of-assurance.md
---
# levels-of-assurance
Identity and other trust decisions are often not binary. They are judgement calls. Any time that judgement is not a simple “Yes/No” answer, you have the option for levels of assurance. Also 'LoA'.
KERI has the same LOAs for entropy and trust in human behavior preserving the security of key pairs and preserving their own privacy. It has high LOAs for the cryptographic bindings of controllers and identifiers. Also the validation of witnesses and watchtowers has high a LOA.
---
title: LID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LID.md
---
# LID
[Legitimized human meaningful identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/legitimized-human-meaningful-identifier.md)
---
title: listed-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/listed-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/listed-identifier.md
---
# listed-identifier
Is a list in an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) of authorised did:webs identifier + method; the list appears in the metadata of the did:webs DID-doc.
Source: paraphrased Samuel Smith, Zoom meeting _KERI dev_ Thursday Nov 9 2023
---
title: liveness
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/liveness
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/liveness.md
---
# liveness
Liveness refers to a set of properties of concurrent systems, that require a system to make progress despite the fact that its concurrently executing components ("processes") may have to "take turns" in critical sections, parts of the program that cannot be simultaneously run by multiple processes.
A _liveness_ property in concurrent systems states that "something good will eventually occur".
Liveness guarantees are important properties in operating systems and distributed systems.
Unlike liveness properties, [safety properties](#safety-properties) can be violated by a finite execution of a distributed system. All properties can be expressed as the intersection of safety and liveness properties.
| TBW | prio 2 how is liveness important in distributed systems? how does KERI guarantee liveness}
On [wikipedia](https://en.wikipedia.org/wiki/Liveness)
---
title: LLM
description: See Large Language Model
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LLM
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LLM.md
---
# LLM
---
title: LoA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LoA
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LoA.md
---
# LoA
[Levels of assurance](https://weboftrust.github.io/WOT-terms/docs/glossary/levels-of-assurance.md)
---
title: LoC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LoC
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/LoC.md
---
# LoC
[Loci of control](https://weboftrust.github.io/WOT-terms/docs/glossary/loci-of-control.md)
---
title: loci-of-control
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/loci-of-control
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/loci-of-control.md
---
# loci-of-control
Locus of control is the degree to which people believe that they, as opposed to external forces (beyond their influence), have control over the outcome of events in their lives. Also 'LoC'.
More on [wikipedia](https://en.wikipedia.org/wiki/Locus_of_control)
In SSI loci-of-control was decribed by Tim Bouma in 2019: 
In KERI this is further developed:
- Key Event Promulgation Service = from the `controller`'s point.
- key event confirmation service = from the `validator`'s point.
The separation of promulgation and confirmation into two separate _loci-of-control_, one the controller’s, and the other the validator’s simplifies the interaction space between these two parties.
The design principle of separating the loci-of-control between controllers and validators removes one of the major drawbacks of total ordered distributed consensus algorithms, that is, shared governance over the pool of nodes that provide the consensus algorithm.
The primary purpose of the [KA2CE](#keri-agreement-algorithm-for-control-establishment) algorithm is to protect the controller’s ability to promulgate the authoritative copy of its key event history despite external attack. This includes maintaining a sufficient degree of availability such that any validator may obtain an authoritative copy on demand.
---
title: locked-state
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/locked-state
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/locked-state.md
---
# locked-state
The default status a KERI data store is in once it has been created using a [passcode](https://weboftrust.github.io/WOT-terms/docs/glossary/passcode.md); it is by default encrypted.
---
title: management-TEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/management-TEL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/management-TEL.md
---
# management-TEL
[Management transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/management-transaction-event-log.md)
---
title: management-transaction-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/management-transaction-event-log
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/management-transaction-event-log.md
---
# management-transaction-event-log
A 'management [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md)' will signal the creation of the _Virtual Credential Registry [(VCR)](https://weboftrust.github.io/WOT-terms/docs/glossary/VCR.md)_ and track the list of _Registrars_ that will act as _[Backers](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md)_ for the individual _transaction event logs (TELs)_ for each [virtual credential](https://weboftrust.github.io/WOT-terms/docs/glossary/virtual-credential.md) (VC).
---
title: media-type
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/media-type
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/media-type.md
---
# media-type
A Media type (formerly known as _MIME type_) is a standard way to indicate the nature and format of a file, in the same way as 'image/jpeg' for JPEG images, used on the internet.
It is a two-part identifier for file formats and format contents transmitted on the internet. Their purpose is somewhat similar to file extensions in that they identify the intended data format.
The [Internet Assigned Numbers Authority (IANA)](https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority) is the official authority for the standardization and publication of these classifications.
Source: [Wikipedia](https://en.wikipedia.org/wiki/Media_type)
The [Internet Assigned Numbers Authority (IANA)](https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority) is the official authority for the standardization and publication of these classifications.
Source: [Wikipedia](https://en.wikipedia.org/wiki/Media_type)
The more important criteria are:
- Standard Format: MIME types must adhere to the format type/subtype
- Registered with IANA: Although, ideally, MIME types should be registered with the Internet Assigned Numbers Authority ([IANA](https://weboftrust.github.io/WOT-terms/docs/glossary/IANA.md)), ensuring they are part of a recognized standard, we consider Experimental or Proposed MIME types as being a valid MIME type as well.
---
title: message
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/message
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/message.md
---
# message
a serialized data structure that comprises its body and a set of serialized data structures that are its attachments. Attachments may include but are not limited to signatures on the body.
Source: Dr. S.Smith
Consists of a serialized data structure that comprises its body and a set of serialized data structures that are its attachments. Attachments may include but are not limited to signatures on the body.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: messagepack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/messagepack
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/messagepack.md
---
# messagepack
MessagePack is a [computer](https://en.wikipedia.org/wiki/Computer) data interchange format. It is a binary form for representing simple [data structures](https://en.wikipedia.org/wiki/Data_structure) like [arrays](https://en.wikipedia.org/wiki/Array_data_structure) and [associative arrays](https://en.wikipedia.org/wiki/Associative_array). MessagePack aims to be as compact and simple as possible. The official implementation is available in a variety of languages
[MessagePack](https://en.wikipedia.org/wiki/MessagePack)
---
title: MFA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/MFA
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/MFA.md
---
# MFA
[Multi-factor Authentication](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-factor-authentication.md)
---
title: MIME-type
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/MIME-type
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/MIME-type.md
---
# MIME-type
[Media type](https://weboftrust.github.io/WOT-terms/docs/glossary/media-type.md)
---
title: moobi
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/moobi
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/moobi.md
---
# moobi
Multi [OOBI](https://weboftrust.github.io/WOT-terms/docs/glossary/OOBI.md) would allow to share a bunch of different end-points (oobis) all at once. A way for a single store to share multiple endpoints for that store.
Those oobis would still need a way to authorize the endpoint provider, the endpoint role, for each of the different things. A multi-sig becomes a messy collaboration effort, especially when you take into account signing at the edge. You would need an authorization record for each end-point. And then pass this to all the members and ask them to collaborate.
Source: Philip Feairheller [KERI-dev meeting](https://github.com/WebOfTrust/keri/discussions/39) July 27 2023
---
title: most-compact
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/most-compact
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/most-compact.md
---
# most-compact
An [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) that, for a given level of disclosure, is as compact as it can be, which means
- it has the [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md)s for each section that are not disclosed
- it has expanded sections that are disclosed
Multiple forms of a single ACDC can be called the "most compact" version, given that each level of [graduated disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/graduated-disclosure.md) will have a "most compacted" version. If all the blocks are expanded to a most compact version, then it becomes fully expanded. If all the blocks are replaced with SAIDs then it becomes fully compacted.
This form is a part of the graduated disclosure objective.
[Fully (expanded)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-expanded.md) version of an ACDC
[Fully compact(ed)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-compact.md) version of an ACDC
---
title: multi-factor-authentication
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multi-factor-authentication
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multi-factor-authentication.md
---
# multi-factor-authentication
Authentication by combining multiple security factors. Well-known factors are _what you know_, _what you have_ and _what you are_.
Multi-factor authentication (MFA; two-factor authentication, or 2FA, along with similar terms) is an [electronic authentication](https://en.wikipedia.org/wiki/Electronic_authentication) method in which a user is granted access to a website or application only after successfully presenting two or more pieces of evidence (or factors) to an [authentication](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) mechanism.
[Source Wikipedia](https://en.wikipedia.org/wiki/Multi-factor_authentication)
---
title: multi-valent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multi-valent
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multi-valent.md
---
# multi-valent
A [delegator](https://weboftrust.github.io/WOT-terms/docs/glossary/delegator.md) may have multiple [delegates](https://weboftrust.github.io/WOT-terms/docs/glossary/delegate.md), thereby enabling elastic horizontal scalability. Multiple delegates from a single delegator. Furthermore, each delegate may act as a delegator for its own delegates to form a _nested delegation tree_.
This allows mapping key management infrastructures to any hierarchically structured organization's computing infrastructure. With this construction, both security and performance trade-offs may be made as appropriate. Such an extended delegation setup we call a multivalent key management infrastructure.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
[Univalent](https://weboftrust.github.io/WOT-terms/docs/glossary/univalent.md) [Bivalent](https://weboftrust.github.io/WOT-terms/docs/glossary/bivalent.md)
---
title: multicodec
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multicodec
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multicodec.md
---
# multicodec
Is a self-describing multi-format, it wraps other formats with a tiny bit of self-description. A multi-codec identifier is both a variant (variable length integer) and the code identifying data.
See more at [GitHub Multi-codec](https://github.com/multiformats/multicodec)
Multi-codec is an agreed-upon codec table. It is designed for use in binary representations, such as keys or identifiers (i.e CID). It is then used as a prefix to identify the data that follows.
---
title: multiplexing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multiplexing
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multiplexing.md
---
# multiplexing
In [telecommunications](https://en.wikipedia.org/wiki/Telecommunications) and [computer networking](https://en.wikipedia.org/wiki/Computer_network), multiplexing (sometimes contracted to _muxing_) is a method by which multiple analog or digital signals are combined into one signal over a [shared medium](https://en.wikipedia.org/wiki/Shared_medium). The aim is to share a scarce resource - a physical [transmission medium](https://en.wikipedia.org/wiki/Transmission_medium).
More on source [Wikipedia-page](https://en.wikipedia.org/wiki/Multiplexing)
Because of [count codes](https://weboftrust.github.io/WOT-terms/docs/glossary/count-code.md) and the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) - and [concatenation](https://weboftrust.github.io/WOT-terms/docs/glossary/concatenation.md) property in CESR, [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md) is possible, which then uses _multiplexing_ (combining [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) primitives) and _de-multiplexing_ (unravelling self-framing [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md)). The addition of group framing codes as independently composable primitives enables [hierarchical compositions](https://weboftrust.github.io/WOT-terms/docs/glossary/hierarchical-composition.md).
---
title: multisig
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multisig
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/multisig.md
---
# multisig
also multi-signature or multisignature; is a [digital signature](https://en.wikipedia.org/wiki/Digital_signature) scheme which allows a group of users to sign a single piece of digital data.
Paraphrased by @henkvancann from Wikipedia [source](https://en.wikipedia.org/wiki/Multisignature)
The KERI team has conceptually chosen for minimal sufficient means and so-called _dumb crypto_: "'Dumb technology' is freely available, understandable to everyone and easy to implement. In our case: just hashes and digital signatures."
KERI has thresholded set of [non-repudiable](https://weboftrust.github.io/WOT-terms/docs/glossary/non-repudiable.md) signatures.
KERI's CESR, and therefore KERI and ACDC is extensible with the latest more sophisticated multi-signature schemes like Schnorr signatures.
---
title: naive-conversion
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/naive-conversion
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/naive-conversion.md
---
# naive-conversion
Non-CESR Base64 conversion. How people are used to using the Base64 encode and decode. Without [pre-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-pad.md)ding etc all the stuff CESR does to ensure aligns on 24 bit boundaries so [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) never uses the '=' pad character. But naive [Base64](https://weboftrust.github.io/WOT-terms/docs/glossary/base64.md) will pad if the length is not 24 bit aligned.
Source: Samuel Smith in [issue 34](https://github.com/WebOfTrust/ietf-cesr/issues/34)
Naive conversion is a text to binary conversion or vice versa that doesn't anticipate on either [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) and / or on the [concatenation](https://weboftrust.github.io/WOT-terms/docs/glossary/concatenation.md) capability of the result of such an operation.
In the [IETF draft CESR](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#conversions) there's much attention for naive [Base64](https://weboftrust.github.io/WOT-terms/docs/glossary/base64.md) conversions, because it helps explaining the necessity of stable code characters and padding in CESR to achieve:
- [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md)
- round-robin [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md)
- [concatenation](https://weboftrust.github.io/WOT-terms/docs/glossary/concatenation.md) options
- [pipelined](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md) streaming
---
title: namespace
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/namespace
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/namespace.md
---
# namespace
In an identity system, an identifier can be generalized to a _namespace_ to provide a systematic way of organizing identifiers for related resources and their attributes. A namespace is a grouping of symbols or identifiers for a set of related objects.
A namespace employs some scheme for assigning identifiers to the elements of the namespace. A simple name-spacing scheme uses a prefix or prefixes in a hierarchical fashion to compose identifiers. The following is an example of a namespace scheme for addresses within the USA that uses a hierarchy of prefixes:
```
state.county.city.zip.street.number.
```
An example element in this namespace may be identified with the following:
```
utah.wasatch.heber.84032.main.150S.
```
---
title: ndigs
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ndigs
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ndigs.md
---
# ndigs
Digests of public keys, not keys themselves. The reason to use ndigs is to prove control over public keys or to hide keys. It's used in Keripy and consists of a list of qualified base64 digests of public rotation key derivations.
---
title: nested-cooperative-delegated-identifiers
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/nested-cooperative-delegated-identifiers
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/nested-cooperative-delegated-identifiers.md
---
# nested-cooperative-delegated-identifiers
In KERI delegations are cooperative, this means that both the delegator and delegate must contribute to a delegation. The delegator creates a cryptographic commitment in either a rotation or interaction event via a seal in a delegated establishment event. The delegate creates a cryptographic commitment in its establishment event via a seal to the delegating event.
Each commitment is signed respectively by the committer. This cooperative delegation together with special superseding recovery rules for events enables cooperative recovery.
This superseding rule may be recursively applied to multiple levels of delegation, thereby enabling recovery of any set of keys signing or pre-rotated in any lower levels by a superseding rotation delegation at the next higher level. This cascades the security of the key management infrastructure of higher levels to lower levels. This is a distinctive security feature of the cooperative delegation of identifiers in KERI.
More in chapter Nested Delegation Recovery of the [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
---
title: NFT
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/NFT
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/NFT.md
---
# NFT
[Non-fungible token](https://weboftrust.github.io/WOT-terms/docs/glossary/non-fungible-token.md)
---
title: non-establishment-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-establishment-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-establishment-event.md
---
# non-establishment-event
a Key event that does not change the current Key state for an AID. Typically, the purpose of a Non-establishment event is to anchor external data to a given Key state as established by the most recent prior Establishment event for an AID.
Source: Dr. S. Smith
A key event tieing or anchoring a data payload to the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of an identifier. This data payload includes a set of one or more [seals](https://weboftrust.github.io/WOT-terms/docs/glossary/seal.md) each of which anchor data to the key event.
The data payload event may be used to make verifiable, authoritative statements on behalf of the identifier controller.
These might include authorizations of encryption keys, communication routes, service endpoints, and so forth.
Transactions or workflows composed of non-establishment events are secured by virtue of being included in the verifiable key event sequence with the verifiable authoritative establishment events.
A non-establishment event is a key event that does not change the current key-state for an AID.
Source [KERI Whitepaper Section 7.22 page 46](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
A non-establishment event is a key event that does not change the current key-state for an [identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md). The event (only) ties or anchors digital data to the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of the identifier.
_(@henkvancann)_
---
title: non-fungible-token
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-fungible-token
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-fungible-token.md
---
# non-fungible-token
A non-fungible token (NFT) is a [financial security](https://en.wikipedia.org/wiki/Security_\(finance\)) consisting of digital data stored in a [blockchain](https://en.wikipedia.org/wiki/Blockchain), a form of [distributed ledger](https://en.wikipedia.org/wiki/Distributed_ledger).
The ownership of an NFT is recorded in a blockchain, and can be transferred by the owner, allowing NFTs to be sold and traded. NFTs can be created by anybody, and require few or no coding skills to create. NFTs typically contain references to [digital files](https://en.wikipedia.org/wiki/Digital_file) such as photos, videos, and audio.
Because NFTs are uniquely identifiable assets, they differ from [cryptocurrencies](https://en.wikipedia.org/wiki/Cryptocurrencies), which are [fungible](https://en.wikipedia.org/wiki/Fungibility).
There's nothing "non fungible" about a non-fungible token in our perspective. It's just another unique identifier controlled by a public private key pair. The fact that NFTs uniquely identify a digital entity isn't very impressive, because of their
- security flaw : the security is dependent on the host ledger the NFT is anchored to
- transferability flaw : you need a transaction to transfer ownership on the host blockchain, controlling keys can't be rotated
- monetization flaw : there's no good reason whatsoever to mingle the value aspect and the uniqueness property of a digital asset; unfortunately, that's what NFTs are doing.
Uniqueness tokenization done correctly is to be praised. Moreover, **it's recommended to look into KERI identifiers and ACDC veracity claims to support the value of the identifiers**, whose monetary value can be recorded elsewhere and separately from the identifier system. Key (pre-)rotation can transfer ownership of a unique digital asset without the need for a transaction on a blockchain.
Sometimes an NFT doesn't only uniquely represent a digital asset: it can be the digital twin of - and is also (hopefully) backed by - a real-life asset. Even in this perspective, KERI and ACDC are more inclusive, because in the KERI/ACDC case we are dealing with globally portable unique digital twins, not anchored to, i.e. locked in, a blockchain.
---
title: non-interactive-authentication-design
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-interactive-authentication-design
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-interactive-authentication-design.md
---
# non-interactive-authentication-design
A group of approaches having non-interactive mechanisms that pose unique problems because they do not allow a challenge response reply handshake. A request is submitted that is self-authenticating without additional interaction.
The main benefits of non-interactive authentication are scalability and path independent end-to-end verifiability. These benefits become more important in decentralized applications that employ [zero-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/zero-trust.md) architectures.
More in [source](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw) Keri Request Authentication Mechanism (KRAM) by Samuel Smith
[Interactive authentication design](https://weboftrust.github.io/WOT-terms/docs/glossary/interactive-authentication-design.md)
---
title: non-normative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-normative
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-normative.md
---
# non-normative
A theory is called non-normative if it does not do what has described under '[Normative](https://weboftrust.github.io/WOT-terms/docs/glossary/normative.md)'. In general, the purpose of non-normative theories is not to give answers, but rather to describe possibilities or predict what might happen as a result of certain actions.
[Source](https://www.quora.com/What-is-the-difference-between-normative-and-non-normative?share=1).
---
title: non-repudiable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-repudiable
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-repudiable.md
---
# non-repudiable
Non-repudiation refers to a situation where a statement's author **cannot successfully dispute** its authorship or the validity of an associated contract, signature or commitment.
The term is often seen in a legal setting when the authenticity of a signature is being challenged. In such an instance, the authenticity is being "repudiated".
Any non-repudiable signature made with the private key may be verified by extracting the public key from either the identifier itself or incepting information uniquely associated with the cryptographic derivation process for the identifier. In a basic SCID, the mapping between an identifier and its controlling public key is self-contained in the identifier itself.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#self-certifying-identifier-scid)
The function of KERI's identifier-system security overlay is to establish the authenticity (or authorship) of the message payload in an IP Packet by verifiably attributing it to a cryptonymous self-certifying identifier (AID) via an attached set of one or more asymmetric keypair-based non-repudiable digital signatures. The current valid set of associated asymmetric keypair(s) is proven via a verifiable data structure called a key event log (KEL).
An authenticatable (verifiable) internet message (packet) or data item includes the identifier and data in its payload. Attached to the payload is a digital signature(s) made with the private key(s) from the controlling keypair(s). Given the identifier in a message, any verifier of a message (data item) can use the identifier system mapping to look up the public key(s) belonging to the controlling keypair(s). The verifier can then verify the attached signature(s) using that public key(s). **Because the payload includes the identifier, the signature makes a non-repudiable cryptographic commitment to both the source identifier and the data in the payload.**
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#identifier-system-security-overlay)
---
title: non-transferable-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-transferable-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-transferable-identifier.md
---
# non-transferable-identifier
Controlling keys over this identifier cannot be rotated and therefore this identifier is [non-transferable](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable.md) to other control.
An identifier of this type has specific positive features like short-lived, peer to peer, one-time use, discardable, etc. that are very practical in certain use cases. Moreover non-transferable identifiers are much easier to govern than persistent identifiers that are [transferable](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable.md).
The KERI design approach is to build composable primitives instead of custom functionality that is so typical of other DKMI approaches:
- [transferable identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable-identifier.md)
- non-transferable identifiers
- [delegated identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/delegated-identifier.md)
---
title: non-transferable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-transferable
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/non-transferable.md
---
# non-transferable
No [capacity to transfer](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable.md) (the control over) a certain digital asset in an unobstructed or loss-less manner. As opposed to [transferable](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable.md).
For example not legally transferable to the ownership of another entity.
A specific type of identifier we distinguish is a [non-transferable identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable-identifier.md); it is has specific positive features like short-lived, peer to peer, one-time use, discardable, etc. that are very practical in certain use cases.
---
title: normative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/normative
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/normative.md
---
# normative
a theory is “normative” if it, in some sense, tells you what you should do - what action you should take. If it includes a usable procedure for determining the optimal action in a given scenario.
[Source](https://www.quora.com/What-is-the-difference-between-normative-and-non-normative?share=1).
---
title: official-organizational-role
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/official-organizational-role
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/official-organizational-role.md
---
# official-organizational-role
Also 'OOR'. A person that represents the Legal Entity in an official organizational role and is issued an OOR vLEI Credential.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: one-way-function
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/one-way-function
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/one-way-function.md
---
# one-way-function
In computer science, a one-way function is a function that is easy to compute on every input, but hard to invert given the image of a random input. Here, "easy" and "hard" are to be understood in the sense of computational complexity theory, specifically the theory of polynomial time problems.
More on [Wikipedia](https://en.wikipedia.org/wiki/One-way_function)
---
title: OOBI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/OOBI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/OOBI.md
---
# OOBI
[Out-of-band introduction](https://weboftrust.github.io/WOT-terms/docs/glossary/out-of-band-introduction.md)
---
title: OOR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/OOR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/OOR.md
---
# OOR
[Official Organizational Role](https://weboftrust.github.io/WOT-terms/docs/glossary/official-organizational-role.md)
---
title: opcode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/opcode
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/opcode.md
---
# opcode
Opcodes are meant to provide stream processing instructions that are more general and flexible than simply concatenated primitives or groups of primitives.
A yet to be determined stack based virtual machine could be executed using a set of opcodes that provides primitive, primitive group, or stream processing instructions. This would enable highly customizable uses for [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md).
The ‘\_’ selector is reserved for the yet to be defined [opcode](https://weboftrust.github.io/WOT-terms/docs/glossary/opcode.md) table or tables.
---
title: out-of-band-introduction
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/out-of-band-introduction
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/out-of-band-introduction.md
---
# out-of-band-introduction
Out-of-band Introductions (OOBIs) are discovery and validation of IP resources for [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md) autonomic identifiers. **Discovery via URI, trust via KERI.**
The simplest form of a KERI OOBI is a namespaced string, a tuple, a mapping, a structured message, or structured attachment that contains both a KERI AID and a URL. The OOBI associates the URL with the AID.
In tuple form, this abstractly
```
(url, aid)
```
and concretely
```
("http://8.8.5.6:8080/oobi", "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM")
```
Validation is done based on [BADA](https://weboftrust.github.io/WOT-terms/docs/glossary/best-available-data-acceptance-mechanism.md) More in [KERI OOBI draft spec](https://hackmd.io/MxTAIBQTRkWU4-w140tNuA?view) and [KERI OOBI explained - draft](https://medium.com/p/510467856035).
From the [IETF draft specification](https://datatracker.ietf.org/doc/html/draft-ssmith-oobi):
An Out-Of-Band Introduction (OOBI) provides a discovery mechanism that associates a given URI or URL with a given AID (\[autonomic identifier\](https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/autonomic-identifier-(AID.md) or [self-addressing identifier (SAID)](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md)). The URI provided by an OOBI acts as a service endpoint for the discovery of verifiable information about the AID or SAID. As such an OOBI itself is not trusted but must be verified.
To clarify, any information obtained from the service endpoint provided in the OOBI must be verified by some other mechanism. An OOBI, however, enables any internet and web search infrastructure to act as an out-of-band infrastructure to discover information that is verified using an in-band mechanism or protocol. The primary in-band verification protocol is [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md).
---
title: owner
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/owner
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/owner.md
---
# owner
[Owner](https://github.com/trustoverip/toip/wiki/owner) in ToIP glossary
---
title: ownership
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ownership
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ownership.md
---
# ownership
[Ownership](https://github.com/trustoverip/toip/wiki/ownership) in ToIP glossary
---
title: P2P
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/P2P
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/P2P.md
---
# P2P
[Peer to peer](https://weboftrust.github.io/WOT-terms/docs/glossary/peer-to-peer.md)
---
title: pre-pad
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pad
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pad.md
---
# pre-pad
the action and / or result of prepending a string with _leading_ pad characters to align to a certain length in bits or bytes.
There are two ways to provide the required alignment on 24-bit boundaries to satisfy the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) property. One is [post-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/post-pad.md), with trailing pad characters `=`, the text domain encoding to ensure that the text domain primitive has a total size (length) that is an integer multiple of 4. This is what [naive Base64 encoding](https://weboftrust.github.io/WOT-terms/docs/glossary/naive-conversion.md) does.
The other way is to _pre-pad_ leading bytes of zeros to the raw binary value before conversion to Base64 to ensure the total size of the raw binary value with pre-pad bytes is an integer multiple of 3 bytes. This ensures that the size in characters of the Base64 conversion of the pre-padded raw binary is an integer multiple of 4 characters.
[Source IEFT CESR draft](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#code-characters-and-lead-bytes)
---
title: parside
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/parside
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/parside.md
---
# parside
is a bunch of generators. Responsible for pulling out a stream of bits from a CESR stream and parse it. Sam Smith suggested for Parside to not iterate stuff, only parse chunks delimited by the [count code](https://weboftrust.github.io/WOT-terms/docs/glossary/count-code.md). (Source Cesride: meeting Feb 2 2023)
CESR primitives are self-framing (which is relatively new). That means that you can construct your parser modually. We can dispatch the parsing of the stream to an entity. The [strip parameter](https://weboftrust.github.io/WOT-terms/docs/glossary/strip-parameter.md) tells us what part will be parsed be which code.
1. Parside should be concerned with parsing group codes, [cesride](https://weboftrust.github.io/WOT-terms/docs/glossary/cesride.md) concerned with parsing primitives.
2. Parside will contain a [count code](https://weboftrust.github.io/WOT-terms/docs/glossary/count-code.md) at the beginning of the stream, each cesr primitive is self framing, JSON is not; hence the [Version string](https://weboftrust.github.io/WOT-terms/docs/glossary/version-string.md).
3. Parside could "load" the tables it supports for dynamically loaded code tables
4. Parside could look at how/if we can return an interator/generator
Source Cesride: meeting Feb 2 2023 notes
> Cesride parses the CESR primitives
> Parside parses the [group codes](https://weboftrust.github.io/WOT-terms/docs/glossary/group-code.md)
| TBW |
- [Version code](https://weboftrust.github.io/WOT-terms/docs/glossary/version-code.md)
- [Version string](https://weboftrust.github.io/WOT-terms/docs/glossary/version-string.md)
- [Strip parameter](https://weboftrust.github.io/WOT-terms/docs/glossary/strip-parameter.md)
- [Cesride](https://weboftrust.github.io/WOT-terms/docs/glossary/cesride.md)
- [Sniffer](https://weboftrust.github.io/WOT-terms/docs/glossary/sniffer.md)
Source Cesride: meeting Feb 2 2023
Parside should start with a default version for CESR. Anytime it gets a version count code it changes the version and also elevates to the top level (the version count code must appear at the top level). The version count code determines which CESR table to load when parsing the stream. The [sniffer](https://weboftrust.github.io/WOT-terms/docs/glossary/sniffer.md) detects if CESR binary, CESR Text, JSON, CBOR, MGPK. If any of the last three then the parser regexes to find the version string inside the JSON, CBOR, and MGPK and from the version string extracts the number of characters/bytes that is the length of the JSON, CBOR, or MGPK. The parser then resumes sniffing. When the sniff is CESR then when at the top level looks for the CESR version count code or any other count codes. The interpretation of the count codes is dependent on the version count code that is why the Parser has to start with a default version count code because the stream may not begin with a version code or may have resumed after a cold restart. When a count code is parsed then the parser may descend into parsing whats inside group for a group count code which may recursively nest down a ways.
Source Slack Cesride thread: Feb 2 2023
---
title: partial-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/partial-disclosure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/partial-disclosure.md
---
# partial-disclosure
a disclosure of an ACDC that partially discloses its field maps using Compact Disclosure. The Compact Disclosure provides a cryptographically equivalent commitment to the yet-to-be-disclosed content, and the later exchange of the uncompacted content is verifiable to an earlier Partial Disclosure. Unlike Selective disclosure, a partially disclosable field becomes correlatable to its encompassing block after its Full Disclosure.
Source: Dr. S. Smith
An ACDC attribute section can be a nested branch in a tree. Partial disclosure is the weaker version because you can either decide to disclose or not. Selective disclosure is more fine-grained.
[Selective disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md) is a from partial disclosure that has a different cryptographic fundament: a sort of cryptographic aggregator (not an accumulator).
Source: distilled from ACDC Zoom meeting, date March 28, 2023
---
title: partial-pre-rotation
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/partial-pre-rotation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/partial-pre-rotation.md
---
# partial-pre-rotation
[Partial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md)
---
title: partial-rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/partial-rotation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/partial-rotation.md
---
# partial-rotation
The pre-rotation mechanism supports partial pre-rotation or **more exactly partial rotation of pre-rotated keypairs**. It's a rotation operation on a set of pre-rotated keys that may keep some keys in reserve (i.e unexposed) while exposing others as needed.
Partial rotation serves two important purposes:
- [Reserve rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/reserve-rotation.md)
- [Custodial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-rotation.md)
Paraphrased by @henkvancann on the bases of the [IETF-KERI draft 2022](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md) by Samual Smith.
A valid rotation operation requires the satisfaction of two different thresholds. These are the current [threshold](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-threshold.md) of the given [rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md) ([establishment](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md)) event with respect to its associated current public key list and the next threshold from the given rotation event's most recent prior establishment event with respect to its associated blinded next key [digest](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md) list. For short, we denote the next threshold from the most recent prior establishment event as the prior next threshold, and the list of unblinded public keys taken from the blinded key digest list from the most recent prior establishment event as the prior next key list. Explication of the elements of the prior next key list requires exposing or unblinding the underlying public keys committed to by their corresponding digests that appear in the next key digest list of the most recent prior establishment event. The unexposed (blinded) public keys MAY be held in reserve.
More in [Source](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#partial-pre-rotation-detail)
---
title: party
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/party
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/party.md
---
# party
An entity who participates or is concerned in an action, proceeding, plan, etc.
Source: ToIP
---
title: passcode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/passcode
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/passcode.md
---
# passcode
A password, sometimes called a passcode (for example in [Apple](https://en.wikipedia.org/wiki/Apple_Inc.) devices), is secret data, typically a string of characters, usually used to confirm a user's identity.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Password)
---
title: pathing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pathing
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pathing.md
---
# pathing
It was designed to sign portions of a credential aimed at complex cases like
- a credential embedded in another credential
- multiple signers, only signing portions of a credential (partial signing)
In these cases, we provide a path (using SAD path language) to what is signed. _We have never used it for credentials_, however we do need it for **forwarding in KERI embedded messages** - see [video discussion](https://us06web.zoom.us/rec/play/qEL79NTkwi4KHrC7ytfy4pYJySOvjpL_gqMSiTxEBl9uXPaeUSaQdka_65xLKP1yozaakqIlYpIX4Yxc.xN0-4LkaqWOZqDjg?canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fus06web.zoom.us%2Frec%2Fshare%2F9RtKAuTNe1417D-4tgdLzmdsrRz63EuaBOysMQU4EZ0ysw4aaZXsIXo1tIRNdzyC.FJhPr84fMxOsGoQN).
We don't sign our credentials, you shouldn't either!
Source: Philip Feairheller, July 20 2023, KERI-dev meeting
---
title: payload
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/payload
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/payload.md
---
# payload
The term 'payload' is used to distinguish between the 'interesting' information in a chunk of data or similar and the overhead to support it. The payload refers to the interesting part.
It is borrowed from transportation, where it refers to the part of the load that 'pays': for example, a tanker truck may carry 20 tons of oil, but the fully loaded vehicle weighs much more than that - there's the vehicle itself, the driver, fuel, the tank, etc. It costs money to move all these, but the customer only cares about (and pays for) the oil, hence, 'pay-load'. [Source](https://softwareengineering.stackexchange.com/questions/158603/what-does-the-term-payload-mean-in-programming).
Now payload in `KERI`. The payload of an item in an `Event Log` is one the following cryptographic building blocks in KERI:
- a content digest hash
- a root hash of a Merkle-tree
- a public key Note tha KERI never puts raw data or privacy-sensitive data in a `KEL` or `KERL`.
---
title: peer-to-peer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/peer-to-peer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/peer-to-peer.md
---
# peer-to-peer
Peer-to-peer (P2P) computing or networking is a [distributed application](https://en.wikipedia.org/wiki/Distributed_application) architecture that partitions tasks or workloads between peers. Peers are **equally privileged**, [equipotent](https://en.wikipedia.org/wiki/Equipotent) participants in the network. They are said to form a peer-to-peer network of [nodes](https://en.wikipedia.org/wiki/Node_\(networking\))
More on source [Wikipedia](https://en.wikipedia.org/wiki/Peer-to-peer)
---
title: percolated-information-discovery
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/percolated-information-discovery
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/percolated-information-discovery.md
---
# percolated-information-discovery
In the [OOBI](https://weboftrust.github.io/WOT-terms/docs/glossary/OOBI.md) protocol, a discovery mechanism for the [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) and the [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) protocols is provided by a bootstrap that enables Percolated Information Discovery (PID), which is based on Invasion Percolation Theory.
After related information for discovery and verification is bootstrapped from the OOBI, subsequent authorization is non-interactive, thus making it highly scalable. This provides what we call zero-trust percolated discovery or speedy percolated discovery.
Percolation means that each discoverer, in turn, may share what it discovers with any subsequent discoverers. Since the information so discovered is end-verifiable, the percolation mechanism and percolating intermediaries do not need to be trusted.
[Percolation theory](https://en.wikipedia.org/wiki/Percolation_theory) is a mathematical framework used to study the behavior of connected clusters in random systems. It was originally developed to understand the flow of fluids through porous media, but it has since found applications in various fields, including physics, mathematics, computer science, and social sciences.
Invasion percolation is a specific variant of percolation theory that models the infiltration of a fluid into a porous medium. It is used to study how a fluid, such as a gas or liquid, spreads through a random network of interconnected sites or pores.
The invasion process follows the principle of least resistance, where the fluid seeks the path of least resistance through the porous medium. As the invasion progresses, the fluid selectively infiltrates the sites with lower resistance, forming a connected cluster of invaded sites. The invaded cluster grows by adding new invaded sites through the neighboring dry sites with the lowest resistance.
[Percolated discovery](https://weboftrust.github.io/WOT-terms/docs/glossary/percolated-discovery.md)
---
title: persistent-data-structure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/persistent-data-structure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/persistent-data-structure.md
---
# persistent-data-structure
An append only verifiable data structure. What we sign may not change.
The approach that ACDCs take to data structures -- making them immutable and thus distributable and concurrency-friendly -- is very similar to the one [advocated and implemented by Clojure](https://github.com/candera/clojure-data-structures#collections-are-immutable).
The persistent data structure is a graph
---
title: persistent-identifier
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/persistent-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/persistent-identifier.md
---
# persistent-identifier
[Transferable Identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable-identifier.md)
---
title: PGP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PGP
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PGP.md
---
# PGP
[Pretty good privacy](https://weboftrust.github.io/WOT-terms/docs/glossary/pretty-good-privacy.md)
---
title: PID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PID.md
---
# PID
[percolated information discovery](https://weboftrust.github.io/WOT-terms/docs/glossary/percolated-information-discovery.md)
---
title: pii
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pii
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pii.md
---
# pii
personally identifiable information
---
title: pipelining
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pipelining
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pipelining.md
---
# pipelining
In [computing](https://en.wikipedia.org/wiki/Computing), a pipeline, also known as a data pipeline, is a set of [data](https://en.wikipedia.org/wiki/Data) processing elements connected in series, where the output of one element is the input of the next one. The elements of a pipeline are often executed in parallel or in time-sliced fashion. Some amount of [buffer storage](https://en.wikipedia.org/wiki/Buffer_\(computer_science\)) is often inserted between elements.
More on source [Wikipedia-page](https://en.wikipedia.org/wiki/Pipeline_\(computing\))
If you have a stream coming in, you have to look ahead how big a chunk of data can be. We call this a logical atomic data chunk.
With JSON I don’t know where the end is, so I have to parse the initial stream to find out. That's slow.
That once you have a block of data, that you can pull off chunks and de-multiplex from the stream into cores and multiplex them back into the streams. Cores in big datacenters are now max 5 GHz, a pipeline is 40 GHz. So you have to be able to do pipelining (split off over many cores). [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) is the only streaming protocol that has this anticipation on board.
Source: Samuel Smith, KERI Zoom meeting Dec 5 2023.
[Multiplexing](https://weboftrust.github.io/WOT-terms/docs/glossary/multiplexing.md)
---
title: PKI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PKI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PKI.md
---
# PKI
[Public key infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/public-key-infrastructure.md)
---
title: post-pad
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/post-pad
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/post-pad.md
---
# post-pad
the action and / or result of extending a string with _trailing_ pad characters to align to a certain length in bits or bytes.
There are two ways to provide the required alignment on 24-bit boundaries to satisfy the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) property. One is _post-pad_, with trailing pad characters `=`, the text domain encoding to ensure that the text domain primitive has a total size (length) that is an integer multiple of 4. This is what [naive Base64 encoding](https://weboftrust.github.io/WOT-terms/docs/glossary/naive-conversion.md) does.
The other way is to [pre-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-pad.md) leading bytes of zeros to the raw binary value before conversion to Base64 to ensure the total size of the raw binary value with pre-pad bytes is an integer multiple of 3 bytes. This ensures that the size in characters of the Base64 conversion of the pre-padded raw binary is an integer multiple of 4 characters.
[Source IEFT CESR draft](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#code-characters-and-lead-bytes)
---
title: post-quantum
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/post-quantum
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/post-quantum.md
---
# post-quantum
In cryptography, post-quantum cryptography (PQC) (sometimes referred to as quantum-proof, quantum-safe or quantum-resistant) refers to cryptographic algorithms (usually public-key algorithms) that are thought to be secure against a cryptanalytic attack by a quantum computer.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Post-quantum_cryptography)
Although individual public-private key pairs are most probably not post-quantum proof, by design the pre-rotation mechanism in KERI is post-quantum proof; which means that in the projected future presence of quantum computers KERI will still be safe. Basically, this safety is established by rotating keys before a brute force quantum attack can be effective. As quantum computers might get faster or more effective over time, the rotation intervals simply become shorter and/or increased [entropy](https://weboftrust.github.io/WOT-terms/docs/glossary/entropy.md) might be used for key generation.
---
title: pre-pad
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pre-pad
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pre-pad.md
---
# pre-pad
the action and / or result of prepending a string with _leading_ pad characters to align to a certain length in bits or bytes.
There are two ways to provide the required alignment on 24-bit boundaries to satisfy the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) property. One is [post-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/post-pad.md), with trailing pad characters `=`, the text domain encoding to ensure that the text domain primitive has a total size (length) that is an integer multiple of 4. This is what [naive Base64 encoding](https://weboftrust.github.io/WOT-terms/docs/glossary/naive-conversion.md) does.
The other way is to _pre-pad_ leading bytes of zeros to the raw binary value before conversion to Base64 to ensure the total size of the raw binary value with pre-pad bytes is an integer multiple of 3 bytes. This ensures that the size in characters of the Base64 conversion of the pre-padded raw binary is an integer multiple of 4 characters.
[Source IEFT CESR draft](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#code-characters-and-lead-bytes)
---
title: pre-rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pre-rotation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pre-rotation.md
---
# pre-rotation
Cryptographic commitment to next rotated key set in previous rotation or [inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md).
The main purpose of [key rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md) it to either prevent or recover from a successful compromise of one or more private keys by an exploiter. Given a potentially compromised private key, an exploiter could sign statements and even capture full control over the identifier by rotating the current key pair.
Pre-rotation mitigates successful exploit of a given set of signing private keys. There are several assumptions listed in [chapter Pre-rotation of the KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf) about the circumstances under which pre-rotation is able to sustain this mitigation, e.g. it assumes that the private keys remains private until after issuance of the associated identifier.
Pre-rotation is a new invention in KERI. Pre-rotation is a cryptographic commitment (a hash) to the next private/public key in the rotation-scheme.
[Source: chapter Pre-rotation in whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
---
title: prefix
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/prefix
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/prefix.md
---
# prefix
A prefix that is composed of a basic Base-64 (URL safe) derivation code pre-pended to Base-64 encoding of a basic public digital signing key.
Including the derivation code in the prefix binds the derivation process along with the public key to the resultant identifier.
> An example of the prefix with a one character derivation code and a 32 byte public key encoded into a 44 character Based-64 string follows: `BDKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0`
---
title: presentation-exchange
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/presentation-exchange
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/presentation-exchange.md
---
# presentation-exchange
An exchange that provides disclosure of one or more [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md)s between a Discloser and a Disclosee.
A presentation exchange is the process by which [authenticatable](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) information may be exchanged between two parties, namely, the [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) and [Disclosee](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md).
Each ACDC MUST have an [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) and MAY have an [Issuee](https://weboftrust.github.io/WOT-terms/docs/glossary/issuee.md). The set of [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md)s so disclosed in a presentation exchange MUST be chained. This set of chained ACDCs define a [directed acyclic graph](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
---
title: pretty-good-privacy
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pretty-good-privacy
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pretty-good-privacy.md
---
# pretty-good-privacy
Is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. Phil Zimmermann developed PGP in 1991.
More on [wikipedia](https://en.wikipedia.org/wiki/Pretty_Good_Privacy)
So also the often confusing [GPG](https://weboftrust.github.io/WOT-terms/docs/glossary/GPG.md) term.
---
title: primary-root-of-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/primary-root-of-trust
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/primary-root-of-trust.md
---
# primary-root-of-trust
In KERI a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) that is cryptographically verifiable all the way to its current controlling key pair in a PKI.
The characteristic _primary_ is one-on-one related to the **entropy** used for the creation of (the seed of) the private keys.
---
title: primitive
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/primitive
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/primitive.md
---
# primitive
a serialization of a unitary value. All Primitives in KERI must be expressed in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md).
Source: Dr. S.Smith
In general in computing a 'primitive' is the simplest type of programming language item. It may also refer to the smallest processing unit accessible by a programmer.
[Source](https://www.techopedia.com/definition/3860/primitive)
See [Cryptographic primitive](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptographic-primitive.md)
In KERI and ACDC it a serialization of a unitary value. A [cryptographic primitive](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptographic-primitive.md) is the KERI-suite sense is the serialization of a value associated with a cryptographic operation including but not limited to a digest (hash), a salt, a seed, a private key, a public key, or a signature. All primitives in KERI MUST be expressed in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md).
---
title: privacy-washing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/privacy-washing
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/privacy-washing.md
---
# privacy-washing
De-identification so that it provides a personal data safe harbour and could be legally acceptable forwarded.
We might need legally enforced pressure for it to be no longer acceptable that you've _un-seen_ the (re-identifiable) personal data.
"Once you see, you can't un-see".
---
title: privacy
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/privacy
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/privacy.md
---
# privacy
Privacy is the ability of an individual or group to seclude themselves or information about themselves, and thereby express themselves selectively.
The domain of privacy partially overlaps with [security](https://en.wikipedia.org/wiki/Security), which can include the concepts of appropriate use and protection of information. Privacy may also take the form of [bodily integrity](https://en.wikipedia.org/wiki/Bodily_integrity).
More on source [Wikipedia](https://en.wikipedia.org/wiki/Privacy)
The three properties, authenticity, confidentiality, and privacy inhabit a trade space. ... One can have any two of the three (privacy, authenticity, confidentiality) at the highest level but not all three.
The trilemma insists that one must make a trade-off by prioritizing one or two properties over a third.
The ToIP [design goals](https://github.com/trustoverip/TechArch/blob/main/spec.md#61-design-goals) reflect that trade-off and provide an order of importance. The design goals indicate that one should start with high authenticity, then high confidentiality, and then as high as possible privacy, given there is no trade-off with respect to the other two.
More on [Source](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md) Samuel Smith SPAC whitepaper.
- [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md)
- [confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/confidentiality.md)
---
title: PRNG
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PRNG
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PRNG.md
---
# PRNG
means "Pseudorandom Number Generator" which means that a sequence of numbers (bits, bytes...) is produced from an algorithm which looks random, but is in fact deterministic (the sequence is generated from some unknown internal state), hence pseudorandom.
Such pseudorandomness can be cryptographically secure, or not. It is cryptographically secure if nobody can reliably distinguish the output from true randomness, even if the PRNG algorithm is perfectly known (but not its internal state). A non-cryptographically secure PRNG would fool basic statistical tests but can be distinguished from true randomness by an intelligent attacker.
(Source: [https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng](https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng))
[CSPRNG](https://weboftrust.github.io/WOT-terms/docs/glossary/CSPRNG.md)
---
title: promiscuous-mode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/promiscuous-mode
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/promiscuous-mode.md
---
# promiscuous-mode
It is the mode a [watcher](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) runs in. A watcher uses the same code as a [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md). However a watcher does so "lacking standards of selection; acting without careful judgment; indiscriminate". Or "Showing little forethought or critical judgment; casual."
[Source](https://www.wordnik.com/words/promiscuous)
The function of watcher is different from a witness, however they can both use the same protocol and code, just in a distinct mode.
---
title: proof-of-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/proof-of-authority
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/proof-of-authority.md
---
# proof-of-authority
Proof that somebody or something has certain rights or permissions. It's about _data_. Whereas [proof of authorship](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authorship.md) is about _data_ and its original creator.
A proof-of-authority provides verifiable authorizations or permissions or rights or credentials.
_Proof of authorship_ and [proof of authority](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authority.md) are integrated in [Authentic Chained Data Containers (ACDCs)](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md):
- ACDCs provide a verifiable chain of proof-of-`authorship` of the contained data
- A proof-of-`authority` may be used to provide verifiable authorizations or permissions or rights or credentials. A chained (treed) proof-of-authority enables delegation of authority and delegated authorizations. These proofs of authorship and/or authority provide provenance of an ACDC itself and by association any data that is so conveyed.
([source](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#introduction))
The data contained in an ACDC is a book written by Terlalu Bonito; the ACDC also contains anchoring digest, signed by the author at publishing date. Terlalu has sold all rights to publish the book to Liz Smiley The ownership of the book matches the current [control](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) over the book and its digital twin: the proof of authority by the chain of ACDCs.
Proof of authority (PoA) is also an [algorithm](https://en.wikipedia.org/wiki/Algorithm) used with [blockchains](https://en.wikipedia.org/wiki/Blockchain) that delivers comparatively fast transactions through a consensus mechanism based on identity as a stake.
([Source](https://en.wikipedia.org/wiki/Proof_of_authority))
This is NOT what we mean in SSI, KERI and ACDC.
---
title: proof-of-authorship
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/proof-of-authorship
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/proof-of-authorship.md
---
# proof-of-authorship
Proof that somebody or something has originally created certain content. It's about _data_'s inception. Whereas [proof-of-authority](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authority.md) is about _rights_ attached to this data.
For example, a [signature](https://en.wikipedia.org/wiki/Signature) constitutes direct proof of [authorship](https://en.wikipedia.org/wiki/Authorship); less directly, [handwriting analysis](https://en.wikipedia.org/wiki/Handwriting_analysis) may be submitted as proof of authorship of a document.[\[21\]](https://en.wikipedia.org/wiki/Proof_\(truth\)?wprov=srpw1_0#cite_note-21) [Privileged information](https://en.wikipedia.org/wiki/Secret) in a document can serve as proof that the document's author had access to that information; such access might in turn establish the location of the author at certain time, which might then provide the author with an [alibi](https://en.wikipedia.org/wiki/Alibi).
[Source](https://en.wikipedia.org/wiki/Proof_\(truth\))
_Proof of authorship_ and [proof of authority](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authority.md) are integrated in [Authentic Chained Data Containers (ACDCs)](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) constituting an [Authentic Provenance Chain (APC)](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-provenance-chain.md):
- ACDCs provide a verifiable chain of proof-of-`authorship` of the contained data
- A proof-of-`authority` may be used to provide verifiable authorizations or permissions or rights or credentials. A chained (treed) proof-of-authority enables delegation of authority and delegated authorizations. These proofs of authorship and/or authority provide provenance of an ACDC itself and by association any data that is so conveyed.
([source](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#introduction))
The data contained in an ACDC is a book written by Terlalu Bonito; the ACDC also contains anchoring digest, signed by the author at publishing date. Terlalu has sold all rights to publish the book to Liz Smiley The ownership of the book matches the current [control](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) over the book and its digital twin: the proof of authority by the chain of ACDCs.
---
title: WebOfTrust-keria-main-docs-protocol
description: signify-keria-request-authentication-protocol--skrap-, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/protocol
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/protocol.md
---
# WebOfTrust-keria-main-docs-protocol
The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces.
1. Boot Interface - Exposes one endpoint for Agent Worker initialization.
2. Admin Interface - The REST API for command and control operations from the Signify Client.
3. KERI Protocol Interface - CESR over HTTP endpoint for KERI protocol interactions with the rest of the world.
This separation allows for the Boot interface to be expose to internal infrastructure only (or disabled all together) while exposing the other two interfaces externally. If a KERIA instance is launched in static worker mode, meaning all agent workers are configured at start up only the Boot interface can be disabled completely.
To initiate a connection between a Signify Client and a KERIA agent, the two sides will exchange KERI AIDs with the Signify Client AID (called the "Client AID") being the delegator for the KERIA agent worker AID (called the "Agent AID"). To establish the connection the following steps are performed:
The Signify Client generates the client AID as a transferable AID with a single signing key and single rotation key and provides the signed inception event out-of-bands to the KERIA service through the Boot interface. The HTTP request must be signed by the client AID using Signify Request Authentication described below. The algorithm for generating the signing and rotation key pairs for Client AID is as follows:
1. Prepend the 128 bit random salt derivation code ('0A') plus the blank qualified base 64 character ('A') to the provided 21 character passcode
2. Stretch the passcode derivation using Argon2 to generate an Ed25519 private key from the provided "tier" and paths of `signify:controller00` and `signify:controller01` for the signing key and rotation key respectively.
3. Use the qualified base64 of the signing public key and the qualified base64 of the Blake3 digest of the rotation public key in the inception event.
The follow is an example of a Client AID generated by the SignifyPy (Python implementation) Signify Client with a passcode of `0123456789abcdefghijk`
```
{
"v": "KERI10JSON00012b_",
"t": "icp",
"d": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose", // Client AID
"s": "0",
"kt": "1",
"k": [
"DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc" // Derived from passcode as salt, kidx = 0
],
"nt": "1",
"n": [
"EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL" // Derived from passcode as salt, kidx = 1, Blake3 Hashed
],
"bt": "0",
"b": [],
"c": [],
"a": []
}
```
The KERIA service will create an Agent Worker on behalf of the new client and create the delegated, transferable Agent AID with a single signing key and single rotation key specifying the Client AID as its delegator in its inception event.
The KERIA service will return the Agent AID inception event in a signed HTTP response, signed by the Agent AID. Agent AID keys can be generated using a salt or truly random depending on the requirements of the service hosting the KERIA service.
```
{
"v": "KERI10JSON00015f_",
"t": "dip", // Delegated AID
"d": "EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei",
"i": "EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei", // Agent AID
"s": "0",
"kt": "1",
"k": [
"DMZh_y-H5C3cSbZZST-fqnsmdNTReZxIh0t2xSTOJQ8a"
],
"nt": "1",
"n": [
"EM9M2EQNCBK0MyAhVYBvR98Q0tefpvHgE-lHLs82XgqC"
],
"bt": "0",
"b": [],
"c": [],
"a": [],
"di": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose" // Delegated signing authority from Client AID
}
```
_Note that all HTTP requests against the Admin Interface must be signed by the Client AID and expect all responses to be signed by the Agent AID._
The Signify Client will approve the delegation of the client AID with an interaction event that it sends back to the KERIA service over the Admin interface.
Once these steps are complete the Signify Client can begin using the rest of the Admin interface to create AIDs, issue credentials, etc.
Document the steps for retrieving state from the Admin interface and updating.
The KERIA service supports the following key generation methods where the Signify Client generates the keys and only ever sends encrypted key material (if any) to the server.
1. Salty Keys - HDK key chain generated from a salt per aid that is encrypted and stored server.
2. Randy Keys - Randomly generated keys (signing and rotation) that are encrypted and store on the server.
3. Sandy Keys - Keys generated from a different salt for inception and each rotation.
4. Group Keys - Signify Client/KERIA Service AIDs participating in a distributed group multisig AID.
5. HSM Keys - Signify Client uses a Signify HSM Integration Module (SHIM) to manage keys and signatures.
For all key generation methods, the Signify Client creates and signs all KERI events, credentials, etc. ensuring that unencrypted private key material never leaves the client. The key generate methods are descrive in more detail in the following sections.
The Salty Key algorithm is used to create a hierarchical deterministic key chain for each AID by generating a unique random salt for each AID and stretching the salt using Argon2 with a `path` that is calculated from the AIDs index relative to all other AIDs and the key index calculated by the total number of signing and rotation keys over the lifetime of the AID.
The salt for each AID is encrypted with the X25519 encryption key generated from the passcode and stored on the server with other AID metadata, including the AID index and current key index.
The Signify Client API must accept the AID salt as an optional parameter to creating Salty Key AIDs allowing users to manage AID salts externally or to share Salts across AIDs if required.
The following Python data class represents the metadata storage for Salty Key AIDs:
```
class SaltyPrm:
"""
Salty prefix's parameters for creating new key pairs
"""
sxlt: str = '' # qualified b64 encoded AID salt
pidx: int = 0 # prefix index for this keypair sequence
kidx: int = 0 # key index for this keypair sequence
stem: str = '' # default unique path stem for salty algo
tier: str = '' # security tier for stretch index salty algo
dcode: str = '' # next digest hasing code
icodes: list = field(default_factory=list) # current signing key seed codes
ncodes: list = field(default_factory=list) # next key seed codes
transferable: bool = False
```
Document the procedure for rotating a new Salt in for a Salty Key AID.
The Randy Key algorithm allows for all signing and rotation private keys to be generated solely from entropy and encrypted with the X25519 encryption key generated from the passcode and stored on the server alongside other AID metadata.
The server stores the encrypted private key material for signing and rotation keys in separate LMBD sub-databases as indexed qualified base 64 CESR encoded Cipher representations.
The Group Key algorithm is a special key generation algorith for distributed group multisig AIDs that does not manage and keys at all. Instead this algoritm allows for the specification of an AID of one of the other three types to be the "local" participant in a distributed group multisig AID.
All signing operations must be performed on the Signify Client on behalf of the "local" AID for this Signify Client indexed based on the local AID's location in both the signing key list and the rotation key list.
The SignifyPy Signify Client defines an experimental interface for declaring external modules that can be used as Signify HSM Integration Modules to allow all key generation and event signing to occur in an external Hardware Security Module (HSM).
Two sample implementations have been defined to date, one using the Google KSM and one using a Trezure One external HSM.
The following psuedo Python class represents the current, experimental interface a SHIM has to implememnt to work with SignifyPy. It is anticipated that each Signify Client implementation defines a similar interface.
```
class Shim:
def incept(self, transferable=True):
""" Create an AID using the Google KSM for key generation and event signing.
Parameters:
transferable (bool): True means create a transferable AID which allows for key rotation
Returns:
keys (list): list of qualified base64 public signing key deriviations based on the codes passed into init
ndigs (list): list of qualified base64 digests of public rotation key derivations based on the codes
passed into init
"""
def rotate(self, ncount, transferable):
""" Rotate an AID using the Google KSM for key generation and event signing.
Parameters:
ncount (int): number of new rotation keys to generate
transferable (bool): True means create a transferable AID which allows for key rotation
Returns:
keys (list): list of qualified base64 public signing key deriviations based on the codes passed into init
ndigs (list): list of qualified base64 digests of public rotation key derivations based on the codes
passed into init
"""
def sign(self, ser, indexed=True, indices=None, ondices=None, **_):
"""
Parameters:
ser (bytes): content to be signed
indexed (bool): True means generated indexed signatures
indices (list): Optional list of indices to use when generating indexed signatures
ondices (list): Optional list of rotation indices to use when generating dual indexed signatures
**_: Placeholder
Returns:
sigs (list): list of qualified base64 signatures over the based in ser
"""
```
To perform a passcode rotation, the Signify Client requires both old and new passcodes and must perform the following steps:
1. Encrypted the old passcode with X25519 key generated from the new passcode.
2. Perform a partial rotation of the Client AID as described below.
3. Decrypt all salts with X25519 key from old passcode for Salty Keys, validate them against current public keys, encrypt with X25519 key from new passcode
4. Decrypt all keys with X25519 key from old passcode for Randy Keys, validate them against current public keys, encrypt with X25519 key from new passcode
5. Send all rotation event and all recrypted material in a POST request to the agent on `/agent/`
To provide post-quantum secure passcode recovery, a passcode recovery must be accompanied by partial rotation of the Client AID. This partial rotation is possible because the user will have to provide both old and new passcodes to initiate the process.
The partial rotation of the Client AID is accomplished by using the old passcode to regenerate the the prior rotation key pair called `R0` from the latest establishment event. In addition, two new key pairs are generated from the new passocde, one used for signing authority (S0) and one used for rotation authority (R1) in the new rotation event.
The public key for `S0` is used as the first signing key in the new rotation event; it is giving a fractionally weighted threshold of "1". The public key for `R0` is used as the second signing key in the new rotation event; it is giving a fractionally weighted threshold of "0". A Blake3 has is created of the public key for `R1` and is used as the next rotation key commitment.
The rotation event is signed with the private keys of both `S0` and `R0`. An example of a partial rotation event of the Client AID from above follows with its signatures:
```
{
"v": "KERI10JSON000195_",
"t": "rot",
"d": "EGTAY6x1tTbOO27LCy3poh5iW0Oa2Cq1s7wsVnj152Zi",
"i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"s": "1",
"p": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"kt": [
"1", // Threshold for key derived from NEW passcode, has full signing authority
"0" // Threshold for key derived from OLD passcode, no signing authority
],
"k": [
"DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc", // Derived from NEW passcode as salt, kidx = 0
"DHMAZEksiqGxlNKnm0pSAyMRPK1ZKyBfGV8q_B9r6pLs" // Derived from OLD passcode as salt, kidx = 1 (matches previous rotation key)
],
"nt": "1",
"n": [
"EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL" // Derived from NEW passcode as salt, kidx = 1, Blake3 Hashed
],
"bt": "0",
"br": [],
"ba": [],
"a": []
}
```
With the following attached signatures:
```
[
"AADuzJ4zU8MkLBPP8Os9UPbTvNqoQ4YDImNkTjfknWgJW25V6EmwZ59PXas0zKhxtp_dOhvkPqtqIhgarOFwt7sC",
"2AABAACRZGDB7s4hmYnt7vTYGWCawhnqHndWUy_rtR_L8mfNmrJ4N5S05wAZ6w5RoL68h1HjIzO7ZuiF30XBz1cC6eUA"
]
```
The first signature satisfies the current signing threshold and has only one index, 0 for signing key index. The second signature satifies the prior rotation threshold and thus uses dual index code to specify a current signing index of 1 and a prior signing index of 0.
The following steps are followed to accept the passcode rotation:
1. Verify and accept the Client AID rotation
2. Verify the signature on the request against the NEW signing key of the Client AID
3. Save encrypted old passcode
4. Update all Salty Key encrypted salts
5. Update all Randy Key encrypted keys
6. Delete encrypted old passcode
When each Agent Worker is loaded it will check for a saved old passcode to detect an aborted passcode rotation. If a saved encrypted old passcode is found the Agent Worker will notify the client in the response to the state call that a passcode rotation recovery is needed and lock out all other operations until it is completed successfully.
To perform a passcode rotation recovery, the Signify Client requires only the new passcode and must perform the following steps:
1. Retrieve the encrypted old passcode and decrypt it with X25519 key generated from the new passcode.
2. Perform a revised partial rotation of the Client AID where you rotate out to a new next key not new signing key.
3. Attempt to decrypt all salts with the X25519 keys from both the old and new passcode for Salty Keys
4. For any salt still encrypted with the old passcode, encrypt with X25519 key from new passcode
5. Attempt to decrypt all keys with the X25519 keys from both the old and new passcode for Randy Keys
6. Validate them against current public keys and for any key still encrypted with the old passcode, encrypt with X25519 key from new passcode
7. Send all rotation event and all recrypted material in a POST request to the agent on `/agent/`
Signify clients must sign all requests to the KERIA Admin Interface using the latest signing key of the Client AID and must expect all responses from the KERIA service be signed by the latest signing key of the Agent AID. Both request and response signing rely on the same set of HTTP headers to accomplish request/response signing.
Document `Signify-Resource` and `Signify-Timestamp` headers here.
Document the `Signature-Input` header here with link to [https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html](https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html)
Document the signing method and `Signature` header.
---
title: provenance
description: Defintion
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/provenance
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/provenance.md
---
# provenance
From Wikipedia ([Source](https://en.wikipedia.org/wiki/Provenance)):
Provenance (from the [French](https://en.wikipedia.org/wiki/French_language) provenir, 'to come from/forth') is the chronology of the ownership, custody or location of a historical object. The term was originally mostly used in relation to [works of art](https://en.wikipedia.org/wiki/Works_of_art) but is now used in similar senses in a wide range of fields, including [archaeology](https://en.wikipedia.org/wiki/Archaeology), [paleontology](https://en.wikipedia.org/wiki/Paleontology), [archives](https://en.wikipedia.org/wiki/Archive), [manuscripts](https://en.wikipedia.org/wiki/Manuscript), printed books, the [circular economy](https://en.wikipedia.org/wiki/Circular_economy), and science and computing.
The primary purpose of tracing the provenance of an object or entity is normally to provide contextual and circumstantial evidence for its original production or discovery, by establishing, as far as practicable, its later history, especially the sequences of its formal ownership, custody and places of storage. The practice has a particular value in helping [authenticate](https://en.wikipedia.org/wiki/Authentication) objects. Comparative techniques, expert opinions and the results of scientific tests may also be used to these ends, but establishing provenance is essentially a matter of [documentation](https://en.wikipedia.org/wiki/Document). The term dates to the 1780s in English. Provenance is conceptually comparable to the legal term [chain of custody](https://en.wikipedia.org/wiki/Chain_of_custody).
([Source](https://en.wikipedia.org/wiki/Provenance))
[Authentic chained data containers (ACDC)](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) establish provenance in two coherent ways:
- historic documentation of cryptographic verifiable key states and data consistency (result: secure attribution)
- historic documentation of [credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/credential.md) (result: attested [veracity](https://weboftrust.github.io/WOT-terms/docs/glossary/veracity.md))
(_@henkvancann_)
---
title: provenanced
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/provenanced
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/provenanced.md
---
# provenanced
The act of verifying [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) or quality of documented history or origin of something.
Focus on authenticity. See [provenance](https://weboftrust.github.io/WOT-terms/docs/glossary/provenance.md).
---
title: pseudo-random-number
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pseudo-random-number
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/pseudo-random-number.md
---
# pseudo-random-number
A (set of) value(s) or element(s) that is statistically random, but it is derived from a known starting point and is typically repeated over and over.
Pseudo-random numbers provide necessary values for processes that require randomness, such as creating test signals or for synchronizing sending and receiving devices in a spread spectrum transmission.
It is called "pseudo" random, **because the algorithm can repeat the sequence**, and the numbers are thus not entirely random.
[Source](https://www.pcmag.com/encyclopedia/term/pseudo-random-numbers)
---
title: PTEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PTEL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/PTEL.md
---
# PTEL
[Public transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/public-transaction-event-log.md)
---
title: public-key-infrastructure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/public-key-infrastructure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/public-key-infrastructure.md
---
# public-key-infrastructure
Is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.
More on [Wikipedia](https://en.wikipedia.org/wiki/Public_key_infrastructure)
---
title: public-transaction-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/public-transaction-event-log
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/public-transaction-event-log.md
---
# public-transaction-event-log
is a public hash-linked data structure of transactions that can be used to track state anchored to a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md).
A Public Verifiable Credential Registry can be represented in several [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/TEL.md)s to establish issuance or revocation state of a [Verifiable Credential](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md) (VC).
The [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md) is used to establish control authority over the keys used to commit to the events of the TEL and sign the VC. The events of the TEL are used to establish the issuance or revocation state of the VCs issued by the controller of the identifier represented by the KEL.
[Source: pfeairheller](https://github.com/WebOfTrust/ietf-ptel/blob/main/draft-pfeairheller-ptel.md)
---
title: public-verifiable-credential-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/public-verifiable-credential-registry
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/public-verifiable-credential-registry.md
---
# public-verifiable-credential-registry
is a form of a [Verifiable Data Registry](https://github.com/trustoverip/toip/wiki/credential-registry) that tracks the issuance/revocation state of credentials issued by the controller of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md). Two types of TELs will be used for this purpose: [management TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/management-transaction-event-log.md) and [VC TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/virtual-credential-transaction-event-log.md).
The first type of [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) is the _management TEL_ and will signal the creation of the Registry and track the list of Registrars that will act as [Backers](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md) for the individual TELs for each [VC](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md). The second type of TEL is the _VC TEL_, which will track the issued or revoked state of each VC and will contain a reference to its corresponding management TEL.
| TBW | prio2
---
title: QAR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/QAR
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/QAR.md
---
# QAR
[QVI Authorized Representative](https://weboftrust.github.io/WOT-terms/docs/glossary/qvi-authorized-representative.md)
---
title: qry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qry
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qry.md
---
# qry
qry = query
---
title: qualified-vlei-issuer-vlei-credential-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qualified-vlei-issuer-vlei-credential-governance-framework
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qualified-vlei-issuer-vlei-credential-governance-framework.md
---
# qualified-vlei-issuer-vlei-credential-governance-framework
A _document_ that details the requirements to enable this Credential to be **issued by** [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md) **to** [Qualified vLEI Issuers](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified-vlei-issuer.md) which allows the Qualified vLEI Issuers to issue, verify and revoke [Legal Entity vLEI Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity-vlei-credential-governance-framework.md), [Legal Entity Official Organizational Role vLEI Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity-official-organizational-role-vlei-credential-governance-framework.md), and [Legal Entity Engagement Context Role vLEI Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md).
---
title: qualified-vlei-issuer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qualified-vlei-issuer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qualified-vlei-issuer.md
---
# qualified-vlei-issuer
The contracting party to the vLEI Issuer Qualification Agreement that has been qualified by GLEIF as a Qualified vLEI Issuer.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
Is an authoritative role at the GLEIF organization that is mandated to issue [vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) credentials to others.
---
title: qualified
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qualified
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qualified.md
---
# qualified
When qualified, a cryptographic primitive includes a prepended derivation code (as a [proem](https://weboftrust.github.io/WOT-terms/docs/glossary/proem.md)), that indicates the cryptographic algorithm or suite used for that derivation.
This simplifies and compactifies the essential information needed to use that cryptographic primitive. All cryptographic primitives expressed in either text or binary CESR are qualified by definition [CESR-ID](https://weboftrust.github.io/ietf-keri/draft-ssmith-keri.html#CESR-ID). Qualification is an essential property of CESR [\[CESR-ID\](https://weboftrust.github.io/ietf-keri/draft-ssmith-keri.html#CESR-ID)](https://weboftrust.github.io/ietf-keri/draft-ssmith-keri.html#section-2-2.4.1)
[Sam Smith, IETF-keri](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: qvi-authorized-representative
description: A designated representative of a QVI authorized, to conduct QVI operations with GLEIF and Legal Entities. Also referring to a person in the role of a QAR.
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qvi-authorized-representative
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/qvi-authorized-representative.md
---
# qvi-authorized-representative
A designated representative of a [QVI](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md) authorized, to conduct QVI operations with GLEIF and [Legal Entities](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md). Also referring to a person in the role of a QAR.
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: QVI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/QVI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/QVI.md
---
# QVI
[Qualified vLEI issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified-vlei-issuer.md)
---
title: race-condition
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/race-condition
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/race-condition.md
---
# race-condition
A race condition or race hazard is the condition of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.
[Source](https://en.wikipedia.org/wiki/Race_condition).
| TBW prio 2 |
---
title: rainbow-table-attack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rainbow-table-attack
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rainbow-table-attack.md
---
# rainbow-table-attack
A rainbow table attack is a password-cracking method that uses a special table (a “rainbow table”) to crack the password hashes in a database.
Applications don’t store passwords in plaintext, but instead encrypt passwords using [hashes](https://weboftrust.github.io/WOT-terms/docs/glossary/content-addressable-hash.md). After the user enters their password to login, it is converted to hashes, and the result is compared with the stored hashes on the server to look for a match. If they match, the user is [authenticated](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) and able to log in.
More on [source](https://www.beyondidentity.com/glossary/rainbow-table-attack)
---
title: rct
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rct
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rct.md
---
# rct
rct = receipt
---
title: read-update-nullify
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/read-update-nullify
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/read-update-nullify.md
---
# read-update-nullify
Read, update, nullify are a set of actions you (or a server) can take on data. "Read" means to view it, "update" means to change it, and "nullify" means to invalidate it, but not "Delete" it. Mind you, there's also no "Create".
- [Run off the CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/run-off-the-crud.md)
- [BADA](https://weboftrust.github.io/WOT-terms/docs/glossary/BADA.md)
---
title: receipt-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/receipt-log
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/receipt-log.md
---
# receipt-log
ordered record of all key event receipts for a given set of witnesses.
---
title: receipt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/receipt
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/receipt.md
---
# receipt
event message or reference with one or more witness signatures.
See Also:
[key event receipt](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt.md)
---
title: reconciliation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/reconciliation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/reconciliation.md
---
# reconciliation
Reconciliation is the process in which you decide to accept a fork of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) or not.
Source: Samuel Smith, Zoom meeting Jan 2 2024.
- You might not have to abandon your identifier after key compromise
- Only few people will see your reconciliation or clean up
---
title: redundant-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/redundant-credential
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/redundant-credential.md
---
# redundant-credential
Multiple credentials issued by the same issuer (e.g. a [QVI](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md)). They do not have anything to do with each other. They are independently valid.
If a QVI issues two instances of the same credential, and is able to only revoke one. This is a governance issue and this behaviour of a QVI is not recommended. But it can be done this way (issue two revoke one) and it leaves the outside world with one other valid credential.
---
title: registrar
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/registrar
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/registrar.md
---
# registrar
identifiers that serve as backers for each [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) (TEL) under its provenance. This list of Registrars can be rotated with events specific to a certain type of TEL. In this way, a Registrar is analogous to a Backer in KERI KELs and Registrar lists are analogous to Backer lists in KERI KELs.
---
title: registration-interaction
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/registration-interaction
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/registration-interaction.md
---
# registration-interaction
Setup/Registration interaction, new AID and authorization to establish access control. You present a ([vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md)) credential. You don't want that captured and misused. Narrowing the scope to a certain role (e.g. Document Submitter) is a pre-registration via [delegatable](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md) authority.
The [Credential](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md) is like a bearer token. Does it matter if the credential was delivered by the [issuee](https://weboftrust.github.io/WOT-terms/docs/glossary/issuee.md)? The token is [proof of the authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authority.md), but does the delivery require the issuee signature? Depends on the context. If it is an idempotent process resubmission has no effect.
Source: Samuel Smith / Daniel Hardman / Lance Byrd - Zoom meeting KERI Suite Jan 16 2024; discussion minute 30-60 min
is important, depending on the context or governance model the issuance itself needs / should / could be signed.
[Access-controlled interaction](https://weboftrust.github.io/WOT-terms/docs/glossary/access-controlled-interaction.md)
---
title: verifiable-data-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/registry
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/registry.md
---
# verifiable-data-registry
A role a system might perform by mediating issuance and verification of ACDCs. See [verifiable data registry](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-data-registries).
Source: Dr. S. Smith
a [Verifiable Data Structure](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-data-structure.md) that has actual content.
It contains either a log of signed statements or a cryptographic commitment ([digest](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md)) to those statements (via a Merkle tree or hash chained data structure).
---
title: replay-attack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/replay-attack
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/replay-attack.md
---
# replay-attack
A _replay attack_ occurs when a cybercriminal eavesdrops on a secure network communication, intercepts it, and then fraudulently delays or resends it to misdirect the receiver into doing what the hacker wants.
The added danger of replay attacks is that a hacker doesn't even need advanced skills to decrypt a message after capturing it from the network. The attack could be successful simply by resending the whole thing.
More on **how it works** and **stopping** replay attacks at [source](https://www.kaspersky.com/resource-center/definitions/replay-attack)
---
title: repo
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/repo
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/repo.md
---
# repo
Software is our line of work. In this, 'repo' is the short hand for 'Repository', mostly referring to a software repo(sitory) on [Github.com](https://github.com), Gitlab ([https://gitlab.com](https://gitlab.com)) or other software repository hosting services.
A software repository, is a storage location for [software packages](https://en.wikipedia.org/wiki/Package_format). Often a table of contents is also stored, along with metadata. A software repository is typically managed by [source control](https://en.wikipedia.org/wiki/Version_control) or repository managers. [Package managers](https://en.wikipedia.org/wiki/Package_manager) allow automatically installing and updating repositories (sometimes called "packages").
[software repository](https://en.wikipedia.org/wiki/Software_repository)
---
title: reputation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/reputation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/reputation.md
---
# reputation
Consistent behaviour over time on the basis of which anyone else makes near-future decisions.
Source: Samuel Smith at IIW37.
---
title: reputational-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/reputational-trust
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/reputational-trust.md
---
# reputational-trust
Established by a trusted party offering [Identity Assurance](https://weboftrust.github.io/WOT-terms/docs/glossary/identity-assurance.md).
---
title: reserve-rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/reserve-rotation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/reserve-rotation.md
---
# reserve-rotation
One important use case for [partial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md) is to enable pre-rotated key pairs designated in one [establishment event](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md) **to be held in reserve and not exposed** at the next (immediately subsequent) establishment event.
Source [IETF-KERI draft 2022](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md) by Samual Smith.
---
title: rev
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rev
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rev.md
---
# rev
rev = vc revoke, verifiable credential revocation
---
title: revocation-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/revocation-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/revocation-event.md
---
# revocation-event
An event that revokes [control authority](https://weboftrust.github.io/WOT-terms/docs/glossary/control-authority.md) over an [identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md). From that point in time the authoritative key-pairs at hand are not valid anymore.
The time stamp of a revocation is useful but not for security purposes, it can be gamed by an attacker. KERI should be fitted in a way so that it's _not possible_ to rewrite history. The tool we have is the ordering of the events in a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md).
[Revocation](https://weboftrust.github.io/WOT-terms/docs/glossary/revocation.md)
A temporary revocation of a grant or privilege is called a suspension. We don't have this type of state or event in KERI.
---
title: revocation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/revocation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/revocation.md
---
# revocation
Revocation is the act of [recall](https://en.wiktionary.org/wiki/recall) or [annulment](https://en.wikipedia.org/wiki/Annulment). It is the cancelling of an act, the recalling of a grant or privilege, or the making [void](https://en.wikipedia.org/wiki/Void_\(law\)) of some [deed](https://en.wikipedia.org/wiki/Deed) previously existing.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Revocation)
The term revocation has two completely different meanings in the identity space. In key management one may speak of revoking keys. With statement issuance, authorization issuance, or credential issuance, one may speak of revoking an authorization statement, a token, or a credential.
This becomes confusing when the act of revoking keys also implicitly revokes the [authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/authorization.md) of statements signed with those keys. Any statement may be effectively authorized by virtue of the attached signature(s) made with a set of [authoritative](https://weboftrust.github.io/WOT-terms/docs/glossary/authoritative.md) keys. The statement itself may be authorizing some other function in the system. So, the verification of the signature on an authorizing statement is essential to determining the authoritativeness of the associated authorized function. To clarify when an authorization is conveyed via a signed statement, the signature acts to authorize the statement.
KERI terminology usually avoids confusion between [rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md) and revocation because a key rotation operation is the equivalent of a key revocation operation **followed by a key replacement operation**. So one operation, rotate, is implemented instead of two operations (revoke and replace).
**A bare key revocation is indicated by replacement with a null key.** So only one operation is needed, that is, rotate where a special case of rotation is to rotate to a null key.
[Revocation event](https://weboftrust.github.io/WOT-terms/docs/glossary/revocation-event.md)
---
title: ricardian-contract
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ricardian-contract
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ricardian-contract.md
---
# ricardian-contract
The Ricardian contract, as invented by Ian Grigg in 1996, is a method of recording a document as a [contract](https://en.wikipedia.org/wiki/Contract) at law, and linking it securely to other systems, such as accounting, for the contract as an issuance of value.
It is robust through use of identification by [cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function), transparent through use of readable text for legal prose and efficient through [markup language](https://en.wikipedia.org/wiki/Markup_language) to extract essential information.
More at [source Wikipedia](https://en.wikipedia.org/wiki/Ricardian_contract)
Ricardian contracts provide a human readable twin to the seals and and signatures (commitments) in binary format in [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md).
---
title: RID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/RID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/RID.md
---
# RID
[Root autonomic identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/root-autonomic-identifier.md)
---
title: root-autonomic-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/root-autonomic-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/root-autonomic-identifier.md
---
# root-autonomic-identifier
An entity may provide the [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) for some ecosystem (with delegation )via its root [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md). Let’s call this the _RID_ for "root AID". The RID must be protected using the highest level of [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) in its [key management](https://weboftrust.github.io/WOT-terms/docs/glossary/key-management.md).
Although through the use of a [multi-valent](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-valent.md) key management infrastructure, the entity can employ extreme protection of the RID while still enabling more performant key management infrastructure for its operations.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: secondary-root-of-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/root-of-trust
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/root-of-trust.md
---
# secondary-root-of-trust
In KERI its a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) that, for its secure attribution, depends on another verifiable data structure (VDS) which MUST be a [primary root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/primary-root-of-trust.md).
By its nature and cryptographic anchoring via [seals](https://weboftrust.github.io/WOT-terms/docs/glossary/seal.md) to a primary root-of-trust, a secondary root-of-trust still has a high level of trustability and can be automatically verified.
---
title: rot
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rot
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rot.md
---
# rot
[JSON](https://weboftrust.github.io/WOT-terms/docs/glossary/JSON.md) field name (attribute) for Rotation Event; its content (value) contains a hash pointer. All [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) events are anchored in a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) in either ixn ([interaction](https://weboftrust.github.io/WOT-terms/docs/glossary/interaction-event.md)) or [rot](https://weboftrust.github.io/WOT-terms/docs/glossary/rot.md) ([rotation event](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md)s). This is the foundation enabling a verifiable credential protocol to be built on top of KERI.
[Source](https://kentbull.com/2023/03/09/keri-tutorial-series-treasure-hunting-in-abydos-issuing-and-verifying-a-credential-acdc/) Kent Bull 2023
[ixn](https://weboftrust.github.io/WOT-terms/docs/glossary/ixn.md)
---
title: rotation-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rotation-authority
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rotation-authority.md
---
# rotation-authority
The (exclusive) right to rotate the authoritative key pair and establish changed control authority.
The original controller of an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md) can hold exclusive rotation authority. Because control authority is split between two key sets, the first for [signing authority](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-authority.md) and the second ([pre-rotated](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-rotation.md)) for rotation authority, the associated thresholds and key list can be structured in such a way that a designated [custodial agent](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-agent.md) can hold signing authority while the original controller can hold exclusive rotation authority.
---
title: rotation-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rotation-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rotation-event.md
---
# rotation-event
an Establishment Event that provides the information needed to change the Key state, which includes a change to the set of [authoritative](https://weboftrust.github.io/WOT-terms/docs/glossary/authoritative.md) keypairs for an AID.
Source: Dr. S.Smith
An [establishment event](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md) representing a transfer of root control authority of an identifier from the current set of controlling keys to new set committed to in the prior establishment event (inception or rotation) as the pre-rotated key pair set.
Source [KERI Whitepaper Section 7.21 page 46](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
This event provides the information needed to change the key-state including a change to the set of [authoritative](https://weboftrust.github.io/WOT-terms/docs/glossary/authoritative.md) keypairs for an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md).
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
We start with a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) in public/private key-pair that is bound to an identifier derived from the key-pair. From this key-pair and then we can rotate controlling authority to other key-pairs with signed rotation messages (events). These rotation messages are witnessed by witnesses designated in the inception event and any subsequent rotation events. Upon completion of successful witnessing a receipt message is sent back to the identity controller performing the rotation and the controller keeps track of these receipts in a [key event receipt log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md).
The infrastructure needed to keep track of these key events including inception events, rotation events, and non-establishment events is key event receipt infrastructure, thus the acronym "KERI": [Key Event Receipt Infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md).\\
_(SamASmith)_
---
title: rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rotation
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rotation.md
---
# rotation
The operation of revoking and replacing the set of [authoritative](https://weboftrust.github.io/WOT-terms/docs/glossary/authoritative.md) [key pairs](https://weboftrust.github.io/WOT-terms/docs/glossary/key-pair.md) for an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md). This operation is made verifiable and [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) evident upon acceptance as a rotation event that is appended to the AID's [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md).
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: rpy
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rpy
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/rpy.md
---
# rpy
rpy = reply
---
title: run-off-the-crud
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/run-off-the-crud
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/run-off-the-crud.md
---
# run-off-the-crud
_RUN off the [CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/CRUD.md)_ is an alternative to the traditional [CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/CRUD.md) approach to defining basic operations on resources in data management systems (e.g., databases, APIs). RUN stands for Read, Update, Nullify and bears a nuanced approach to deletion.
Why is it preferred ('run off') over the CRUD (Create, Update, Delete)?
Consider the need to protect '_authentic data_' in a decentralized environment.
In a decentralized control model, the data always originates from a controller (aka client). The data created (sourced) by the controller follows the principle of '_Non-Interactive Replay Monotonicity_' to be able to protect the data from a replay (events are changed) or a deletion (some events are deleted) attacks. That is to say, the data (or events comprising it) is never deleted, it's rather always added to via updates. Each update, therefore, forms a verifiable, continuous log ( e.g. by providing growing sequence number, date timestamp, etc for each update). To enable invalidation of data, a special update, called Nullify, is used.
The client, therefore, updates the server (it's peer or peers), which just maintains the log following certain rules (see [BADA](https://weboftrust.github.io/WOT-terms/docs/glossary/best-available-data-acceptance-mechanism.md) - Best Available Data Acceptance).
To summarise, the server can only Read the log, add Updates to it, including Nullifying ones. So _no_ Create or Delete.
---
title: RUN
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/RUN
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/RUN.md
---
# RUN
The acronym for the new peer-to-peer end-verifiable monotonic update policy is RUN (**Read, Update, Nullify**).
RUN as opposed to [CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/CRUD.md) which is the traditional client-server database update policy.
We [RUN off the CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/run-off-the-crud.md), which means that because the source of truth for each data item is a decentralized controller Peer, a given database hosted by any Peer does not create records in the traditional sense of a server creating records for a client.
---
title: SAD
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SAD
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SAD.md
---
# SAD
[Self addressing data](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-data.md)
---
title: SAID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SAID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SAID.md
---
# SAID
[Self-addressing identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md)
---
title: sally
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/sally
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/sally.md
---
# sally
is an implementation of a verification service and acting as a reporting server. It is purpose-built software for the vLEI ecosystem to allow participants in the vLEI ecosystem present credentials, so the [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md) Reporting API can show what [vLEIs](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) are; issued to [Legal Entities](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md).
The Sally [vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) Audit Reporting Agent _receives presentations of credentials_ and notices of [revocation](https://weboftrust.github.io/WOT-terms/docs/glossary/revocation-event.md), verifies the structure and cryptographic integrity of the credential or revocation event and performs a POST to the configured webhook [URL](https://weboftrust.github.io/WOT-terms/docs/glossary/URL.md)
[Source](https://github.com/GLEIF-IT/sally)
---
title: salt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/salt
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/salt.md
---
# salt
random data fed as an additional input to a one-way function that hashes data.
Source: Dr. S. Smith
In [cryptography](https://en.wikipedia.org/wiki/Cryptography), a salt is [random](https://en.wikipedia.org/wiki/Random_Number_Generator) data that is used as an additional input to a [one-way function](https://en.wikipedia.org/wiki/One-way_function) that [hashes](https://en.wikipedia.org/wiki/Cryptographic_hash_function) [data](https://en.wikipedia.org/wiki/Data_\(computing\)), a [password](https://en.wikipedia.org/wiki/Password) or [passphrase](https://en.wikipedia.org/wiki/Passphrase).
Salts are used to safeguard passwords in storage. Historically, only a cryptographic hash function of the password was stored on a system, but over time, additional safeguards were developed to protect against duplicate or common passwords being identifiable (as their hashes are identical).[\[2\]](https://en.wikipedia.org/wiki/Salt_\(cryptography\)#cite_note-2) Salting is one such protection.
[Wikipedia](https://en.wikipedia.org/wiki/Salt_\(cryptography\))
---
title: salter
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/salter
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/salter.md
---
# salter
A primitive that represents a [seed](https://weboftrust.github.io/WOT-terms/docs/glossary/seed.md). It has the ability to generate new [Signer](https://weboftrust.github.io/WOT-terms/docs/glossary/signer.md)s.
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: salty-nonce-blinding-factor
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/salty-nonce-blinding-factor
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/salty-nonce-blinding-factor.md
---
# salty-nonce-blinding-factor
For ease of sharing a secret and hiding information with this secret of Blindable State TELs we use a Salty Nonce Blinding Factor. You’d like to hide the state of certain credentials to some verifiers in the future, while keeping the state verifiable for others.
A way to share the key to blind/unblind the state of a TEL is
- [HTOP, HMAC-Based One-Time Password](https://datatracker.ietf.org/doc/html/rfc6238)
- [Time-Based One-Time Password](https://datatracker.ietf.org/doc/html/rfc6238)
- HDKM, Hierarchical Deterministic Key Management, based on a shared master key you could split off subkeys in a predictable manner.
The blinding is performed by the issuer, the issuee could request the blinding.
I don’t want my employment states shared in the future with former possible employers.
[Blindable State TEL](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#blindable-state-tel)
---
title: SATP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SATP
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SATP.md
---
# SATP
[Secure asset transfer protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/secure-asset-transfer-protocol.md)
---
title: schema-namespace-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/schema-namespace-registry
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/schema-namespace-registry.md
---
# schema-namespace-registry
a centrally managed [schema registry](https://weboftrust.github.io/WOT-terms/docs/glossary/schema-registry.md) where corporations or individuals reserve schemas within a specific [namespace](https://weboftrust.github.io/WOT-terms/docs/glossary/namespace.md) in order to have an interoperable schema that is labeled with a corporation-specific or individual-specific namespace.
[Graphs](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) in ACDC have decentralised the old-school schema registry, so it's [interoperable](https://weboftrust.github.io/WOT-terms/docs/glossary/interoperability.md) by design.
---
title: schema-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/schema-registry
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/schema-registry.md
---
# schema-registry
Central [registry](https://weboftrust.github.io/WOT-terms/docs/glossary/registry.md) for credential schemas based on namespaces.
ACDCs and SAIDS **eliminated the need** for a centrally controlled namespace registry for credential schemas.
From our vocabulary that contains the term "[Public verifiable credential registry](https://weboftrust.github.io/WOT-terms/docs/glossary/public-verifiable-credential-registry.md)" there's follow-up on ToIP definitions like | TBW |
[Syntio](https://www.syntio.net/en/labs-musings/schema-registry-comparison/) comparison of (old-school?) centralized schema registries.
This source has conceptual explanations in diagrams like the one below and code examples. However, **be aware that ACDC solves this in a different way** with [KERI-based verifiable data structures](https://weboftrust.github.io/WOT-terms/docs/glossary/VDS.md) and [graph fragments](https://weboftrust.github.io/WOT-terms/docs/glossary/graph-fragment.md).
---
title: SCID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SCID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SCID.md
---
# SCID
[Self-certifying identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-certifying-identifier.md)
---
title: seal
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/seal
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/seal.md
---
# seal
a seal is a cryptographic commitment in the form of a cryptographic digest or hash tree root (Merkle root) that anchors arbitrary data or a tree of hashes of arbitrary data to a particular event in the key event sequence.
Source: Dr. S. Smith
A cryptographic commitment in the form of a cryptographic digest or hash tree root (Merkle root) that anchors arbitrary data or a tree of hashes of arbitrary data to a particular event in the key event sequence.
Source [KERI Whitepaper section 7.23 page 47](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
A seal is a cryptographic proof in a secondary root-of-trust (e.g. TEL) that is anchored in a primary-root-of-trust (e.g.KEL).
Source Same Smith
The payload of the seal becomes immutable and the controller commits a signature to the seal.
| TBW prio 2 |
---
title: secondary-root-of-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secondary-root-of-trust
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secondary-root-of-trust.md
---
# secondary-root-of-trust
In KERI its a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) that, for its secure attribution, depends on another verifiable data structure (VDS) which MUST be a [primary root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/primary-root-of-trust.md).
By its nature and cryptographic anchoring via [seals](https://weboftrust.github.io/WOT-terms/docs/glossary/seal.md) to a primary root-of-trust, a secondary root-of-trust still has a high level of trustability and can be automatically verified.
---
title: secure-asset-transfer-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secure-asset-transfer-protocol
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secure-asset-transfer-protocol.md
---
# secure-asset-transfer-protocol
An IETF protocol (and working group) in the making (as of mid 2022) for moving assets between blockchains.
[About SATP working group](https://datatracker.ietf.org/wg/satp/about/)
KERI has portable identifiers per definition. KERI identifier are not locked into silos like distributed ledgers. KERI IDs have their own native hash-chained data structures (KEL, KERL and TEL).
---
title: secure-attribution
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secure-attribution
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secure-attribution.md
---
# secure-attribution
Secure attribution is strongly related to _making and proving statements_. A [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) makes statements to the a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) or [verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md), who in turn validates the statements issued. A [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) "_owns_" the statement: content and attribution via digital signatures. Secure attribution is "whodunit?!" in cyberspace.
_Secure attribution of a statement_ is a way of proving that **the statement is an authentic statement of the `controller`**.
In the context of KERI and ACDC _secure_ means a **`Validator` may cryptographically verify** the statement.
---
title: secure-private-authentic-confidentiality
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secure-private-authentic-confidentiality
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secure-private-authentic-confidentiality.md
---
# secure-private-authentic-confidentiality
ToIP Trust Spanning Layer Group realized we do have a secure authentication layer (KERI) but we don't have a secure confidentiality and privacy mechanism. Sam Smith proposes SPAC paper to define this. Related: [https://www.usenix.org/system/files/sec22-cohen.pdf](https://www.usenix.org/system/files/sec22-cohen.pdf)
If someone has set up a public AID, with public Witnesses we don't have a mechanism to support private communication with this AID | TBW |
[SPAC paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md)
Tech meet KERI [recording](https://hackmd.io/-soUScAqQEaSw5MJ71899w#2023-06-27) from minute 35, date June 29 2023 and also discussed Tech meeting KERI Aug 3 2023 from minute 30 or so till end.
---
title: secure
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/secure.md
---
# secure
[Security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md)
---
title: security-cost-performance-architecture-trade-off
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/security-cost-performance-architecture-trade-off
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/security-cost-performance-architecture-trade-off.md
---
# security-cost-performance-architecture-trade-off
The degree of protection offered by a key management infrastructure usually forces a trade-off between security, cost, and performance.
Typically, key generation happens relatively infrequently compared to event signing. But highly secure key generation may not support highly performant signing. This creates an architecture trade-off problem.
Paraphrased from source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: security-overlay-properties-trillema
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/security-overlay-properties-trillema
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/security-overlay-properties-trillema.md
---
# security-overlay-properties-trillema
An identifier system has some degree of any combination of the three properties [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md), [privacy](https://weboftrust.github.io/WOT-terms/docs/glossary/privacy.md) and [confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/confidentiality.md), but not all three completely.
The reason a system may not provide all three completely is that no single cryptographic operation provides all three properties.
As a result any cryptographic system must layer the operations. But layering exposes weaknesses due to the separation between the layers. Because no single layer can exhibit all three properties, one must pick one or two properties for the bottom layer and then layer on top the remaining property or properties on one or more layers.
Source: Universal Identifier Theory by Samuel Smith
---
title: threshold-structure-security
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/security
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/security.md
---
# threshold-structure-security
A threshold structure for security allows for weaker key management or execution environment infrastructure individually, but achieve greater overall security by multiplying the number of attack surfaces that an attacker must overcome to compromise a system.
With threshold structures, overall security may be greater than the security of any of the individual parts.
In [MFA](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-factor-authentication.md) the combination of two factors, something you have and something you know, may be much more secure than either of the factors by themselves.
Threshold structures may be employed in a complementary manner to trusted execution environments ([TEE](https://weboftrust.github.io/WOT-terms/docs/glossary/trusted-execution-environment.md)) for security. The two types of security are complementary.
This applies to KERI as well. The [witnesses](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) and [watchers](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) independently multiply the attack surfaces of the promulgation and the confirmation networks such that each witness or watcher respectively may be relatively insecure but the system as a whole may be highly secure.
Numerous papers discuss how secure a distributed consensus pool may be. But when comparing _apples_ (key management and trusted execution environment (TEE) approach to security) to _oranges_ (distributed consensus approach to security) its hard to say that the security of a distributed consensus algorithm is necessarily less secure than the key management infra-structure root-of-trust of any of its nodes. Although as a general rule, in an apples to apples comparison, _more complex is less secure_.
Source: Universal Identifier Theory by Samuel Smith
---
title: seed
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/seed
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/seed.md
---
# seed
In cryptography a 'seed' is a _pseudorandomly_ generated number, often expressed in representation of a series of words.
Paraphrased from [wikipedia](https://en.wikipedia.org/wiki/Random_seed)
```
broken toddler farm argue elder behind sea ramp cake rabbit renew option combine guilt inflict sentence what desert manage angry manual grit copy hundred
```
Test [here](https://iancoleman.io/bip39/) yourself.
Although sequences that are closer to truly random can be generated using [hardware random number generators](https://en.wikipedia.org/wiki/Hardware_random_number_generator), pseudorandom number generators are important in practice for their speed in number generation and their reproducibility.
Source [wikipedia](https://en.wikipedia.org/wiki/Pseudorandom_number_generator)
---
title: selective-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/selective-disclosure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/selective-disclosure.md
---
# selective-disclosure
a disclosure of an ACDC that selectively discloses its attributes using Compact Disclosure. The set of selectively disclosable attributes is provided as an array of blinded blocks where each attribute in the set has its own dedicated blinded block. Unlike Partial Disclosure, the selectively disclosed fields are not correlatable to the so far undisclosed but selectively disclosable fields in the same encompassing block. Source: Dr. S. Smith
Selective disclosure is a from partial disclosure that has a different cryptographic fundament: a sort of cryptographic aggregator (not an accumulator).
Selective disclosure is a list of field maps. You can choose to blind and publish every single field map, but you have to disclosure all the field maps, either blinded or published.
It is an aggregator because you have to disclosure all the blinded fields when you do the selective disclosure.
[Partial Disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-disclosure.md)
Source: distilled from ACDC Zoom meeting, date March 28, 2023
---
title: self-addressing-data
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-addressing-data
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-addressing-data.md
---
# self-addressing-data
an identifier that is content-addressable and self-referential. A SAID is uniquely and cryptographically bound to a serialization of data that includes the SAID as a component in that serialization [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/said.md).
Source: Dr. S. Smith
While all KERI event messages are self-addressing data (SAD), there is a broad class of SADs that are not KERI events but that require signature attachments. ACDC Verifiable credentials fit into this class of SADs. With more complex data structures represented as SADs, such as verifiable credentials, there is a need to provide signature attachments on nested subsets of SADs.
(Philip Feairheller, ietf-cesr-proof)
---
title: self-addressing-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-addressing-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-addressing-identifier.md
---
# self-addressing-identifier
any identifier that is deterministically generated out of the content, or a digest of the content.
Source: Dr. S. Smtih
An identifier that is deterministically generated from and embedded in the content it identifies, making it and its data mutually tamper-evident.
1. Fully populate the data that the SAID will identify, leaving a placeholder for the value of the SAID itself.
2. Canonicalize the data, if needed. The result is called the SAID's **identifiable basis**.
3. Hash the _identifiable basis_. The result is the value of the SAID.
4. Replace the placeholder in _identifiable basis_ the with the newly generated identifier, so the SAID is embedded in the data it identifies. The result is called the **saidified data.**
1. Canonicalize the data, if needed. The result is **claimed saidified data**.
2. In the _claimed saidified data_, replace the SAID value with a placeholder. The result is the **identifiable basis** for the SAID.
3. Hash the _identifiable basis_.
4. Compare the hash value to the SAID. If they are equal, then the SAID identifies the _claimed saidified data_.
- how data is canonicalized
- which hash algorithm is used
- which placeholder is used
- how the bytes produced by the hash algorithm are encoded
- how the SAID value is formatted
A terse way to describe a SAID and its data is to write an expression that consists of the token `SAID` followed by a token with field names in canonical order, where the field containing the SAID itsef is marked by the suffix `=said`. For example, the saidification of a simple `ContactInfo` data structure might be given as `SAID(name, address, phone, email, id=said)`.
---
title: Self-certifying identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-certifying-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-certifying-identifier.md
---
# Self-certifying identifier
a type of Cryptonym that is uniquely cryptographically derived from the public key of an asymmetric signing keypair (public, private).
Source: Dr. S. Smith
A Self-Certifying Identifier (SCID) cryptographically binds an identifier to one or more public/private key pairs. It is an identifier that can be proven to be the one and only identifier tied to a public key using cryptography alone.
A [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) issues an own Identifier by binding a generated public private key pair to an identifier. After this a controller is able to sign the identifier and create a certificate. Also called a _cryptonym_. The simplest form of a self-certifying identifier includes either the public key or a unique fingerprint of the public key as a [prefix](https://weboftrust.github.io/WOT-terms/docs/glossary/prefix.md) in the identifier.
- Self-contained secure cryptographic [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md)
- Decentralized control via [private key management](https://weboftrust.github.io/WOT-terms/docs/glossary/PKI.md)
- Universally unique identifiers
A self-certifying identifier (SCID) is a type of [cryptonym](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptonym.md) that is uniquely cryptographically derived from the public key of an asymmetric non-repudiable signing keypair, (public, private).
It is self-certifying or more precisely **self-authenticating** because it does not rely on a trusted entity. The [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) of a non-repudiable signature made with the private key may be verified by extracting the public key from either the identifier itself or incepting information uniquely associated with the cryptographic derivation process for the identifier. In a _basic SCID_, the mapping between an identifier and its controlling public key is self-contained in the identifier itself. A basic SCID is [ephemeral](https://weboftrust.github.io/WOT-terms/docs/glossary/ephemeral.md) i.e. it does not support [rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md) of its keypairs in the event of key weakness or compromise and therefore must be abandoned once the controlling private key becomes weakened or compromised from exposure.
---
title: self-framing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-framing
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-framing.md
---
# self-framing
a textual or binary encoding that begins with type, size, and value so that a parser knows how many characters (when textual) or bytes (when binary) to extract from the stream for a given element without parsing the rest of the characters or bytes in the element is Self-Framing.
A self-framing Primitive may be extracted without needing any additional delimiting characters. Thus, a stream of concatenated Primitives may be extracted without the need to encapsulate each Primitive inside a set of delimiters or an envelope.
Source [Samual M Smith](https://www.ietf.org/archive/id/draft-ssmith-cesr-02.txt)
A self-framing text primitive may be parsed without needing any additional delimiting characters. Thus a stream of concatenated primitives may be individually parsed without the need to encapsulate the primitives inside textual delimiters or envelopes. Thus a textual self-framing encoding provides the core capability for a streaming text protocol like [STOMP](https://en.wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocol) or [RAET](https://github.com/RaetProtocol/raet).
Although a first class textual encoding of cryptographic primitives is the primary motivation for the [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md) protocol defined herein, CESR is sufficiently flexible and extensible to support other useful data types, such as, integers of various sizes, floating point numbers, date-times as well as generic text. Thus this protocol is generally useful to encode in text data data structures of all types not merely those that contain cryptographic primitives.
---
title: Self-sovereign identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-sovereign-identity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-sovereign-identity.md
---
# Self-sovereign identifier
Self-sovereign identity is a decentralized identity architecture that implements the Principles of SSI — principally that it puts the identity controller (e.g., a natural person or organization) directly in control of the identifiers and credentials they use to assert their digital identity.
Source: ToIP main glossary
The definition started in the blog "[The Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)" by Christopher Allen in 2016. has not resulted in a consensus today. While some see the ten principles of SSI that Allen proposed as the definition of SSI, he formulated them as "a departure point to provoke a discussion about what's truly important". And it is obvious that what is important differs per [party](https://essif-lab.github.io/framework/docs/terms/party).
[Source eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/self-sovereign-identity)
---
title: self-sovereignty
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-sovereignty
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/self-sovereignty.md
---
# self-sovereignty
[Self sovereignty](https://github.com/trustoverip/toip/wiki/self-sovereignty) in Trust over IP wiki.
---
title: server-sent-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/server-sent-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/server-sent-event.md
---
# server-sent-event
Mailbox notifications; a streaming service for the agent U/I, to get notifications from the KERI system itself.
---
title: service-endpoint
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/service-endpoint
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/service-endpoint.md
---
# service-endpoint
In our context we consider a **web service endpoint** which is a [URL](https://weboftrust.github.io/WOT-terms/docs/glossary/uniform-resource-locator.md) at which clients of specific service can get access to the service.
By referencing that URL, clients can get to operations provided by that service.
Paraphrased from [source](https://study.com/academy/lesson/what-is-web-service-endpoint-definition-concept.html)
---
title: siger
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/siger
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/siger.md
---
# siger
[Indexed signature](https://weboftrust.github.io/WOT-terms/docs/glossary/indexed-signature.md)
---
title: signed-digest
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signed-digest
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signed-digest.md
---
# signed-digest
commitment to content, by digitally signing a digest of this content.
---
title: signer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signer.md
---
# signer
A primitive that represents a private key. It has the ability to create Sigers and Cigars (signatures).
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: signify-keria-request-authentication-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signify-keria-request-authentication-protocol
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signify-keria-request-authentication-protocol.md
---
# signify-keria-request-authentication-protocol
SKRAP is a client to the KERIA server. Mobile clients will be using SKRAP to connect to KERI [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md)s via [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md)s in the new, multi-tenant Mark II Agent server, [KERIA](https://weboftrust.github.io/WOT-terms/docs/glossary/keria.md).
Also, browser extensions will use SKRAP in order to use a wallet similar to _MetaMask_, except it will be KERIMask, and it will be a browser extension. [KERIMask](https://weboftrust.github.io/WOT-terms/docs/glossary/KERIMask.md) will connect to KERIA servers in order for a person to control AIDs from their browser extension.
SKRAP is also usable from HSMs and hardware wallets because the keys from the hardware wallet, along with some app code, connect through SKRAP to agents running in a KERIA server.
[Signify](https://weboftrust.github.io/WOT-terms/docs/glossary/signify.md) signs things at the edge. This includes [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md)s. KERIA will be used to send communications between agents. The things KERIA sends are signed by Signify.
Source: Kent Bull in KERI Slack May 2023
The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces.
1. Boot Interface - Exposes one endpoint for Agent Worker initialization.
2. Admin Interface - The REST API for command and control operations from the Signify Client.
3. KERI Protocol Interface - CESR over HTTP endpoint for KERI protocol interactions with the rest of the world.
This separation allows for the Boot interface to be expose to internal infrastructure only (or disabled all together) while exposing the other two interfaces externally. If a KERIA instance is launched in static worker mode, meaning all agent workers are configured at start up only the Boot interface can be disabled completely.
More at source [Github Signify](https://github.com/WebOfTrust/signify/blob/main/protocol.md)
---
title: Slack Archive
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signify
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signify.md
---
# Slack Archive
---
title: signing-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signing-authority
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signing-authority.md
---
# signing-authority
The authority to sign on behalf of the controller of the authoritative key pair. Often in situation where delegation has taken place, e.g. a custodial agent. These are limited rights because [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md) is not included.
The original controller of an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md) can hold exclusive [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md). Because control authority is split between two key sets, the first for signing-authority and the second ([pre-rotated](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-rotation.md)) for [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md), the associated thresholds and key list can be structured in such a way that a designated [custodial agent](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-agent.md) can hold signing authority while the original controller can hold exclusive rotation authority.
---
title: signing-threshold
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signing-threshold
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/signing-threshold.md
---
# signing-threshold
Is the minimum number of valid signatures to satisfy the requirement for successful verification in a [Threshold Signature Scheme](https://weboftrust.github.io/WOT-terms/docs/glossary/threshold-signature-scheme.md).
In a 2-of-3 signature scheme the threshold is 2. This means that 2 valid signatures are enough to fulfil the required signature.
---
title: simple-keri-for-web-auth
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/simple-keri-for-web-auth
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/simple-keri-for-web-auth.md
---
# simple-keri-for-web-auth
A [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) implementation that sacrifices performance or other non-security feature for usability. In general a narrow application of KERI may not require all the features of KERI but those features that it does support must still be secure.
More on source [Github Repo SKWA](https://github.com/WebOfTrust/skwa).
Designed for private clouds, just like [Keep](https://weboftrust.github.io/WOT-terms/docs/glossary/keep.md). [Signify](https://weboftrust.github.io/WOT-terms/docs/glossary/signify.md) is designed for public clouds.
---
title: single-signature-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/single-signature-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/single-signature-identifier.md
---
# single-signature-identifier
or single sig identifier; is an identifier controlled by a one-of-one signing [keypair](https://weboftrust.github.io/WOT-terms/docs/glossary/key-pair.md)
---
title: SKRAP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SKRAP
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SKRAP.md
---
# SKRAP
[Signify/KERIA Request Authentication Protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/signify-keria-request-authentication-protocol.md)
---
title: SKWA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SKWA
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SKWA.md
---
# SKWA
[Simple KERI for web auth](https://weboftrust.github.io/WOT-terms/docs/glossary/simple-keri-for-web-auth.md)
---
title: sniffable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/sniffable
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/sniffable.md
---
# sniffable
A stream is _sniffable_ as soon as it starts with a group code or field map; in fact this is how our parser ([Parside](https://weboftrust.github.io/WOT-terms/docs/glossary/parside.md)) works. and detects if the CESR stream contains a certain datablock. The datablock of CESR binary, CESR Text, JSON, CBOR, MGPK have an Object code or the Group code (binary or text) and it's always a recognizable and unique _three bit combination_.
We have the Cold start problem of a stream: you don't where to start recognizing structured data.
So a stream is either sniffable or not, when it has or has not the fore-mentioned group- or object-codes.
Source: Sam Smith, Zoom Meeting KERI, Dec 5 2023
[Sniffer](https://weboftrust.github.io/WOT-terms/docs/glossary/sniffer.md)
---
title: sniffer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/sniffer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/sniffer.md
---
# sniffer
The _sniffer_ is part of [Parside](https://weboftrust.github.io/WOT-terms/docs/glossary/parside.md) and detects if the CESR stream contains CESR binary, CESR Text, JSON, CBOR, MGPK.
If any of JSON, CBOR, MGPK then the parser regexes to find the [version string](https://weboftrust.github.io/WOT-terms/docs/glossary/version-string.md) inside the JSON, CBOR, and MGPK and from the version string extracts the number of characters/bytes that is the length of the JSON, CBOR, or MGPK. The parser then resumes _sniffing_. When the sniff result is 'CESR' then when at the top level looks for the CESR [version count code](https://weboftrust.github.io/WOT-terms/docs/glossary/version-code.md) or any other count codes.
Source Slack Cesride thread: Feb 2 2023
[Sniffable](https://weboftrust.github.io/WOT-terms/docs/glossary/sniffable.md)
---
title: unsolicited-issuance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/solicited-issuance
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/solicited-issuance.md
---
# unsolicited-issuance
Issuance of a Legal Entity vLEI Credential upon notice by a [QAR](https://weboftrust.github.io/WOT-terms/docs/glossary/QAR.md) to the [AVR](https://weboftrust.github.io/WOT-terms/docs/glossary/AVR.md)(s) of the Legal Entity that a Legal Entity vLEI Credential has been solicited on the [Legal Entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md)’s behalf.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
See [Solicited issuance](https://weboftrust.github.io/WOT-terms/docs/glossary/solicited-issuance.md)
---
title: source-of-truth
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/source-of-truth
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/source-of-truth.md
---
# source-of-truth
The source of truth is a trusted data source that gives a complete picture of the data object as a whole.
[Source](https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/): LinkedIN.
Source of a particular piece of information from one place, considered to present the truth. However both KERI and ACDC only commit to the secure attribution of _who_ said something and not whether _what_ has been said is true or not. Veracity is an individual (organisational) conclusion that needs governance and virtual credentials. KERI and ACDC support veracity (concluding it's the "the truth") but doesn't solve it.
Compound description by @henkvancann from sources: [1](https://en.wikipedia.org/wiki/Single_version_of_the_truth), [2](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC_Spec.md)
Truth is the property of being in accord with fact or reality. In everyday language, truth is typically ascribed to things that aim to represent reality
[Source](https://en.wikipedia.org/wiki/Truth): Wikipedia.
---
title: SPAC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SPAC
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SPAC.md
---
# SPAC
[Secure Private Authentic Confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/secure-private-authentic-confidentiality.md)
---
title: spanning-layer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/spanning-layer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/spanning-layer.md
---
# spanning-layer
An all encompassing layer horizontal layer in a software architecture. Each trust layer only spans platform specific applications. It bifurcates the internet trust map into domain silos (e.g. twitter.com), because there is no spanning trust layer.
---
title: spurn
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/spurn
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/spurn.md
---
# spurn
To _reject_. In KERI, "spurn" refers to a cryptographic or protocol-based act of rejecting an invalid or untrusted event. This rejection is deliberate and purposeful, ensuring the system's integrity by disregarding information that does not meet the necessary validation criteria. The verb 'spurn' is first used in the [IPEX](https://weboftrust.github.io/WOT-terms/docs/glossary/IPEX.md) specification.
| TBW prio 2 |
---
title: ssi-system
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ssi-system
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ssi-system.md
---
# ssi-system
The SSI Infrastructure consists of the technological components that are deployed all over the world for the purpose of providing, requesting and obtaining data for the purpose of negotiating and/or executing electronic [transactions](https://essif-lab.github.io/framework/docs/terms/transaction). Paraphrased by @henkvancann based on source [eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/ssi-infrastructure)
The SSI Infrastructure supports the sustainable functionality of [parties](https://essif-lab.github.io/framework/docs/terms/party) by providing IT services and facilities necessary for (electronic) [transactions](https://essif-lab.github.io/framework/docs/terms/transaction) to be negotiated and executed.
Source [eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/ssi-infrastructure)
The team has put stress on the principle 'security first, confidentiality second and privacy third'. All systems and infrastructure KERI and ACDC has presented therefore constitute a rather small subset of all [self-sovereign identity systems (SSI)](https://weboftrust.github.io/WOT-terms/docs/glossary/self-sovereign-identity.md) available nowadays.
---
title: SSI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SSI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/SSI.md
---
# SSI
[Self-sovereign identity](https://weboftrust.github.io/WOT-terms/docs/glossary/self-sovereign-identity.md)
---
title: stale-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/stale-event
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/stale-event.md
---
# stale-event
A stale key event is an outdated or irrelevant (key) event involving an [expired encryption key](https://weboftrust.github.io/WOT-terms/docs/glossary/stale-key.md) that may compromise security.
---
title: stale-key
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/stale-key
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/stale-key.md
---
# stale-key
A stale key is an outdated or expired encryption key that should no longer be used for securing data
[Stale (key) event](https://weboftrust.github.io/WOT-terms/docs/glossary/stale-event.md)
---
title: strip-parameter
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/strip-parameter
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/strip-parameter.md
---
# strip-parameter
tells us what part of the [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) stream will be parsed by which code.
[Parside](https://weboftrust.github.io/WOT-terms/docs/glossary/parside.md)
| TBW |
---
title: sub-shell
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/sub-shell
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/sub-shell.md
---
# sub-shell
A subshell is basically a new shell just to run a desired program. A subshell can access the global variables set by the 'parent shell' but not the local variables. Any changes made by a subshell to a global variable is not passed to the parent shell.
[Source](https://linuxhandbook.com/subshell/)
A child process in computing is a [process](https://en.wikipedia.org/wiki/Process_\(computing\)) created by another process (the [parent process](https://en.wikipedia.org/wiki/Parent_process)). This technique pertains to [multitasking operating systems](https://en.wikipedia.org/wiki/Computer_multitasking), and is sometimes called a subprocess or traditionally a subtask.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Child_process)
---
title: supermajority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/supermajority
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/supermajority.md
---
# supermajority
Sufficient majority that is labeled _immune_ from certain kinds of attacks or faults.
---
title: tcp-endpoint
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/tcp-endpoint
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/tcp-endpoint.md
---
# tcp-endpoint
This is a [service endpoint](https://weboftrust.github.io/WOT-terms/docs/glossary/service-endpoint.md) of the web [transmission control protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/transmission-control-protocol.md)
Because TCP packets do not include a session identifier, both endpoints identify the session using the client's address and port. Whenever a packet is received, the TCP implementation must perform a lookup on this table to find the destination process.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
---
title: TCP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TCP
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TCP.md
---
# TCP
[Transmission control protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/transmission-control-protocol.md)
---
title: TEE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TEE
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TEE.md
---
# TEE
[trusted execution environment](https://weboftrust.github.io/WOT-terms/docs/glossary/trusted-execution-environment.md)
---
title: management-TEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TEL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TEL.md
---
# management-TEL
[Management transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/management-transaction-event-log.md)
---
title: text-binary-concatenation-composability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/text-binary-concatenation-composability
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/text-binary-concatenation-composability.md
---
# text-binary-concatenation-composability
An encoding has _composability_ when any set of [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) concatenated primitives expressed in either the text domain or binary domain may be converted as a group to the other domain and back again without loss.
CESR is fully text binary concatenation composable.
Use Google Translate to translate a piece of text from English to Dutch. Subsequently, keep copy pasting the resulting “to:” text into the “from:” field. The message changes until it comes to a standstill where you can keep swapping the texts without them changing.
The conclusion is: Google Translate is not composable!
By contrast, CESR is composable. The _analogy_ lies in the fact that we consider two languages. Suppose the English in the Google Translate example is _readable, text based_ in CESR and Dutch is the _binary_ form in CESR. Within these two CESR “languages”, text-based and binary, you can concatenate and swap freely as many times as you like — the data won’t change in between in their binary or text form no matter what content you express with them.
More explanation in [source](https://medium.com/happy-blockchains/cesr-one-of-sam-smiths-inventions-is-as-controversial-as-genius-d757f36b88f8).
---
title: tholder
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/tholder
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/tholder.md
---
# tholder
t-holder object that supports fractionally-weighted [thresholds](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-threshold.md)
---
title: threshold-of-accountable-duplicity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/threshold-of-accountable-duplicity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/threshold-of-accountable-duplicity.md
---
# threshold-of-accountable-duplicity
The threshold of accountable duplicity (TOAD) is a threshold number `M` that the controller declares to accept accountability for an event when any subset `M` of the `N` witnesses confirm that event. The threshold `M` indicates the minimum number of confirming witnesses the controller deems sufficient given some number `F` of potentially faulty witnesses, given that `M >= N - F`. This enables a controller to provide itself with any degree of protection it deems necessary given this accountability.
Note that what may be sufficient for a controller may not be sufficient for a validator. To clarify, let `MC` denote the threshold size of a sufficient agreement from the perspective of a controller and let `MV` denote the threshold size of a sufficient agreement from the perspective of a validator. Typically, `MV >= MC`.
A controller declares TOAD in its [key event log (KEL)](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) during the [key inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md) and may edit it during subsequent [key rotation events](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md).
A highly available system needs some degree of fault tolerance. The purpose of the threshold of accountability is to enable fault tolerance of the key event service with respect to faulty behavior by either the controller or witnesses. The principal controller fault exhibits duplicitous behavior in the use of its keys. In this case, the threshold serves as the threshold of accountable duplicity. The threshold lets a validator know when it may hold the controller accountable for duplicitous behavior. Without a threshold, a validator may choose to hold a controller accountable upon any evidence of duplicity which may make the service fragile in the presence of any degree of such faulty behavior. The primary way that a validator may hold a controller accountable is to stop trusting any use of the associated identifier. This destroys any value in the identifier and does not allow the controller to recover from an exploit. Recall that the one purpose of rotation keys (pre-rotated unexposed) is to enable recovery from compromised interaction signing keys. A compromised interaction signing key may exhibit duplicitous behavior on the part of the controller. A threshold of accountable duplicity enables a validator to distinguish between potentially recoverable duplicity such as the use of a compromised signing key and non-recoverable duplicity such as the use of a compromised rotation key. This better protects both the validator and the controller and improves the robustness of the service.
---
title: threshold-signature-scheme
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/threshold-signature-scheme
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/threshold-signature-scheme.md
---
# threshold-signature-scheme
or TSS; is a type of digital signature protocol used by [Mutli-party Computation (MPC)](https://cryptoapis.io/products/wallet-as-a-service/mpc) wallets to authorize transactions or key state changes.
Source [Cryptoapis](https://cryptoapis.io/blog/78-what-is-the-threshold-signature-scheme)
---
title: threshold-structure-security
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/threshold-structure-security
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/threshold-structure-security.md
---
# threshold-structure-security
A threshold structure for security allows for weaker key management or execution environment infrastructure individually, but achieve greater overall security by multiplying the number of attack surfaces that an attacker must overcome to compromise a system.
With threshold structures, overall security may be greater than the security of any of the individual parts.
In [MFA](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-factor-authentication.md) the combination of two factors, something you have and something you know, may be much more secure than either of the factors by themselves.
Threshold structures may be employed in a complementary manner to trusted execution environments ([TEE](https://weboftrust.github.io/WOT-terms/docs/glossary/trusted-execution-environment.md)) for security. The two types of security are complementary.
This applies to KERI as well. The [witnesses](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) and [watchers](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) independently multiply the attack surfaces of the promulgation and the confirmation networks such that each witness or watcher respectively may be relatively insecure but the system as a whole may be highly secure.
Numerous papers discuss how secure a distributed consensus pool may be. But when comparing _apples_ (key management and trusted execution environment (TEE) approach to security) to _oranges_ (distributed consensus approach to security) its hard to say that the security of a distributed consensus algorithm is necessarily less secure than the key management infra-structure root-of-trust of any of its nodes. Although as a general rule, in an apples to apples comparison, _more complex is less secure_.
Source: Universal Identifier Theory by Samuel Smith
---
title: TOAD
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TOAD
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TOAD.md
---
# TOAD
[threshold of accountable duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/threshold-of-accountable-duplicity.md)
---
title: top-level-section
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/top-level-section
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/top-level-section.md
---
# top-level-section
The fields of an ACDC in [compact variant](https://weboftrust.github.io/WOT-terms/docs/glossary/compact-variant.md). The value of a top level section field is either the SAD or the SAID of the SAD of the associated section. An Issuer commitment via a signature to any variant of ACDC (compact, full, etc) makes a cryptographic commitment to the top-level section fields shared by all variants of that ACDC.
Paraphrased by @henkvancann based on [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#example-most-compact-variant).
---
title: TPM
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TPM
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TPM.md
---
# TPM
[Trusted platform module](https://weboftrust.github.io/WOT-terms/docs/glossary/trusted-platform-module.md)
---
title: trans-contextual-value
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trans-contextual-value
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trans-contextual-value.md
---
# trans-contextual-value
Value that is transferrable between contexts. **How do we recapture the value in our data?** 1- Leverage cooperative network effects 2- Retake control of our data.
[Source](https://github.com/SmithSamuelM/Papers/blob/master/presentations/NonconformistKeynoteWeb20200702.pdf) Samuel Smith
How to remove primary barriers to cooperation? Different value contexts implies 'not directly competitive'. So we need to find value that is transferrable between contexts. Therefore: Use trans-contextual value creation and capture to fuel cooperative network effects.
KERI assists in this.
---
title: virtual-credential-transaction-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transaction-event-log
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transaction-event-log.md
---
# virtual-credential-transaction-event-log
will track the issued or revoked state of each virtual credential (VC) and will contain a reference to its corresponding _management transaction event log (management TEL)_.
---
title: transfer-off-ledger
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transfer-off-ledger
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transfer-off-ledger.md
---
# transfer-off-ledger
The act of transferring control authority over an identifier from a ledger (or blockchain) to the native verifiable KERI data structure Key Event Log.
If you want to transition to using KERI, you could do that by anchoring your KERI identifiers in, for example, your Indy ledger. The neat thing is, you could then **transfer the identifier off the ledger** and then have non-ledger based portable identifiers.
Although it's portable, you can be anchored to any one ledger at a time, or you could move it to an identifier (witness, backer, watcher, etc) can only be represented different ledger, or you could move to using just witnesses, all with the same identifier by just doing rotation events and changing your anchor, your backers here.
So an identifier cannot be anchored, let's say to multiple Indies or Ethereum. You could be only anchored in one at a time.
You can move identifiers across networks with KERI, but it's not what it has been designed for.
---
title: transferable-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transferable-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transferable-identifier.md
---
# transferable-identifier
Control over the identifier [can be transferred](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable.md) by [rotating keys](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md).
A synonym is 'persistent identifier'.
The KERI design approach is to build composable primitives instead of custom functionality that is so typical of other DKMI approaches:
- transferable identifiers
- [non-transferable identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable-identifier.md)
- [delegated identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/delegated-identifier.md)
---
title: transferable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transferable
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transferable.md
---
# transferable
Capable of being transferred or conveyed from one place or person to another. Place can be its and bits. The adjective transferable also means 'Negotiable', as a note, bill of exchange, or other evidence of property, that may be conveyed from one person to another by indorsement or other writing; capable of being transferred with no loss of value. As opposed to [non-transferable](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable.md).
[Source](https://www.wordnik.com/words/transferable)
Focus is on the digital space and concerning the loss-less transfer of control over [identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable-identifier.md), private keys, etc.
---
title: transmission-control-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transmission-control-protocol
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/transmission-control-protocol.md
---
# transmission-control-protocol
One of the main [protocols](https://en.wikipedia.org/wiki/Communications_protocol) of the [Internet protocol suite](https://en.wikipedia.org/wiki/Internet_protocol_suite). It originated in the initial network implementation in which it complemented the [Internet Protocol](https://en.wikipedia.org/wiki/Internet_Protocol) (IP).
More on [source](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) Wikipedia.
---
title: trust-domain
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trust-domain
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trust-domain.md
---
# trust-domain
A trust domain is the ecosystem of interactions that rely on a trust basis. A trust basis binds controllers, identifiers, and key-pairs. _For example the Facebook ecosystem of social interactions is a trust domain that relies on Facebook’s identity system of usernames and passwords as its trust basis._
([Source whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf))
A trust domain is a domain that the system trusts to authenticate users. In other words, if a user or application is authenticated by a trusted domain, this authentication is accepted by all domains that trust the authenticating domain.
A more technical meaning of 'domain' is on the internet: [domain name](https://weboftrust.github.io/WOT-terms/docs/glossary/domain-name.md).
---
title: trust-spanning-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trust-spanning-protocol
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trust-spanning-protocol.md
---
# trust-spanning-protocol
Protocol using [VID](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-identifier.md)s that signs every single message on the internet and makes them verifiable.
---
title: trusted-execution-environment
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trusted-execution-environment
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trusted-execution-environment.md
---
# trusted-execution-environment
Protected hardware/software/firmware security system. The controller may protect its key generation, key storage, and event signing infrastructure by running it inside a trusted execution environment (TEE).
SGX, TrustZone, an HSM, a TPM, or other similarly protected hardware/software/firmware environment
---
title: trusted-platform-module
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trusted-platform-module
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/trusted-platform-module.md
---
# trusted-platform-module
A device that enhances the security and privacy (of identity systems) by providing hardware-based cryptographic functions.
A TPM can generate, store, and protect encryption keys and authentication credentials that are used to verify the identity of a user or a device.
A TPM can also measure and attest the integrity of the software and firmware that are running on a system, to ensure that they have not been tampered with or compromised.
A TPM can be implemented as a physical chip, a firmware module, or a virtual device.
Source: Bing chat sept 2023
---
title: ts-node
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ts-node
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/ts-node.md
---
# ts-node
npm package that lets you run typescript from a shell
---
title: TSP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TSP
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/TSP.md
---
# TSP
[Trust Spanning Protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/trust-spanning-protocol.md)
---
title: UI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/UI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/UI.md
---
# UI
[User interface](https://weboftrust.github.io/WOT-terms/docs/glossary/user-interface.md)
---
title: uniform-resource-locator
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/uniform-resource-locator
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/uniform-resource-locator.md
---
# uniform-resource-locator
A Uniform Resource Locator (URL), colloquially termed a web address, is a reference to a [web resource](https://en.wikipedia.org/wiki/Web_resource) that specifies its location on a [computer network](https://en.wikipedia.org/wiki/Computer_network) and a mechanism for retrieving it.
A URL is a specific type of [Uniform Resource Identifier](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) (URI),although many people use the two terms interchangeably. URLs occur most commonly to reference [web pages](https://en.wikipedia.org/wiki/Web_page) ([HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol)) but are also used for file transfer ([FTP](https://en.wikipedia.org/wiki/File_Transfer_Protocol)), email ([mailto](https://en.wikipedia.org/wiki/Mailto)), database access ([JDBC](https://en.wikipedia.org/wiki/Java_Database_Connectivity)), and many other applications.
More on source [Wikipedia](https://en.wikipedia.org/wiki/URL)
---
title: univalent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/univalent
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/univalent.md
---
# univalent
In identifier systems, univalent means having a unique and non-ambiguous identifier for each entity or resource. This means that there is a _one-to-one correspondence_ between the identifiers and the entities, and that no two different entities share the same identifier. Source: Bing chat, Sept 2023
(Paraphrased from source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith) In key management key pairs (public, private) are created in the key-pair generation and storage infrastructure and then may be moved to the key event generation and signing infrastructure in order to sign events. To protect both the key generation and storage and the event signing infrastructures. . Consequently, a given protection mechanism may co-locate both infrastructures. This means facilities are shared. This combined infrastructure is refered to as a _univalent_ key management infrastructure.
A more secure albeit less convenient or performant univalent key management infrastructure may use special computing devices or components to store private keys and/or create signatures.
[Multivalent](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-valent.md) [Bivalent](https://weboftrust.github.io/WOT-terms/docs/glossary/bivalent.md)
---
title: unsolicited-issuance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/unsolicited-issuance
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/unsolicited-issuance.md
---
# unsolicited-issuance
Issuance of a Legal Entity vLEI Credential upon notice by a [QAR](https://weboftrust.github.io/WOT-terms/docs/glossary/QAR.md) to the [AVR](https://weboftrust.github.io/WOT-terms/docs/glossary/AVR.md)(s) of the Legal Entity that a Legal Entity vLEI Credential has been solicited on the [Legal Entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md)’s behalf.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
See [Solicited issuance](https://weboftrust.github.io/WOT-terms/docs/glossary/solicited-issuance.md)
---
title: URL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/URL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/URL.md
---
# URL
[Uniform resource locator](https://weboftrust.github.io/WOT-terms/docs/glossary/uniform-resource-locator.md)
---
title: user-interface
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/user-interface
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/user-interface.md
---
# user-interface
A user interface (UI or U/I) is the space where interactions between humans and machines occur.
The [Reactable](https://en.wikipedia.org/wiki/Reactable), an example of a [tangible user interface](https://en.wikipedia.org/wiki/Tangible_user_interface) In the [industrial design](https://en.wikipedia.org/wiki/Industrial_design) field of [human–computer interaction](https://en.wikipedia.org/wiki/Human%E2%80%93computer_interaction), a user interface (UI) is the space where interactions between humans and machines occur. The goal of this interaction is to allow effective operation and control of the machine from the human end, while the machine simultaneously feeds back information that aids the operators' [decision-making](https://en.wikipedia.org/wiki/Decision-making) process.
Source [page](https://en.wikipedia.org/wiki/User_interface)
---
title: validate
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/validate
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/validate.md
---
# validate
ESSIF-lab definition of _[validate](https://essif-lab.github.io/framework/docs/essifLab-glossary#validate)_. Although this definition is very general, in the KERI/ACDC vocabulary, 'validate' currently has extra diverse meanings extending the one of eSSIF-lab, such as
- evaluate
- [verify](https://weboftrust.github.io/WOT-terms/docs/glossary/verify.md)
In contrast, [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) and [verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md) have been clearly outlined in the WebofTrust vocabulary.
---
title: validator
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/validator
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/validator.md
---
# validator
any entity or agent that evaluates whether or not a given signed statement as attributed to an identifier is valid at the time of its issuance.
Source: Dr. S. Smith
determines the current authoritative key set for an identifier from at least one key event (receipt) log.
Types:
- Validator of any verifiable data structure
- Validator as a node in distributed consensus or participant
Validator and [verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md) are close to synonyms for our purposes.
A `validator` in [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md) and [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) is anybody who wants to establish control authority over an identifier created by the controller of the identifier. Validators verify the log, apply duplicity detection, leverage somebody else's duplicity detection, or apply any other logic so they can say, "Yes, these are events I can trust."
During validation of virtual credentials for example, a [verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md) checks to see if a verifiable [credential](https://weboftrust.github.io/WOT-terms/docs/glossary/credential.md) ([VC](https://weboftrust.github.io/WOT-terms/docs/glossary/VC.md)) has been signed by the controller of this VC using the applicable verification method.
Any entity or agent that evaluates whether or not a given signed statement as attributed to an identifier is valid at the time of its issuance. A valid statement MUST be verifiable, that is, has a verifiable signature from the current controlling keypair(s) at the time of its issuance. Therefore a Validator must first act as a Verifier in order to establish the root authoritative set of keys. Once verified, the Validator may apply other criteria or constraints to the statement in order to determine its validity for a given use case. When that statement is part of a verifiable data structure then the cryptographic verification includes verifying digests and any other structural commitments or constraints. To elaborate, with respect to an AID, for example, a Validator first evaluates one or more KELs in order to determine if it can rely on (trust) the key state (control authority) provided by any given KEL. A necessary but insufficient condition for a valid KEL is it is verifiable i.e. is internally inconsistent with respect to compliance with the KERI protocol. An invalid KEL from the perspective of a Validator may be either unverifiable or may be verifiable but duplicitous with respect to some other verifiable version of that KEL. Detected duplicity by a given validator means that the validator has seen more than one verifiable version of a KEL for a given AID. Reconciliable duplicity means that one and only one version of a KEL as seen by a Validator is accepted as the authoritative version for that validator. Irreconcilable duplicity means that none of the versions of a KEL as seen by a validator are accepted as the authoritative one for that validator. The conditions for reconcilable duplicity are described later.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: VC TEL
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/VC-TEL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/VC-TEL.md
---
---
title: VC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/VC
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/VC.md
---
# VC
[Verifiable credential](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md)
---
title: vcp
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vcp
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vcp.md
---
# vcp
vcp = vdr incept, verifiable data registry inception
---
title: vdr
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vdr
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vdr.md
---
# vdr
[Verifiable data registry](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-data-registry.md)
---
title: VDS
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/VDS
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/VDS.md
---
# VDS
[Verifiable data structure](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-data-structure.md)
---
title: veracity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/veracity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/veracity.md
---
# veracity
The quality of being true; contrast [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md). When a newspaper publishes a story about an event, every faithful reproduction of that story may be _authentic_ — but that does not mean the story was true (has _veracity_).
---
title: verfer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verfer
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verfer.md
---
# verfer
A primitive that represents a public key. It has the ability to [verify](https://weboftrust.github.io/WOT-terms/docs/glossary/verify.md) signatures on data.
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: Verifiable Credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-credential
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-credential.md
---
# Verifiable Credential
Verifiable credentials (VCs) are an [open standard](https://en.wikipedia.org/wiki/Open_standard) for digital credentials. They can represent information found in physical credentials, such as a passport or license, as well as new things that have no physical equivalent, such as ownership of a bank account.
[VCs](https://en.wikipedia.org/wiki/Verifiable_credentials)
Importantly, there are VC specification that provide a mechanism to express these sorts of [credentials](https://www.w3.org/TR/vc-data-model/#dfn-credential) on the Web _in a way that is_ cryptographically secure, privacy respecting, and machine-verifiable. [More](https://www.w3.org/TR/vc-data-model/)
[Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md): The entity that creates and issues the credential. [Holder](https://weboftrust.github.io/WOT-terms/docs/glossary/holder.md): The entity that holds and can present the credential. [Verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md): The entity that checks the authenticity and validity of the credential. Tamper-proof: VCs use cryptographic techniques (like digital signatures) to ensure that the credential has not been altered since issuance. Privacy-preserving: VCs can allow the holder to disclose only the necessary information, often using selective disclosure or zero-knowledge proofs to protect privacy. Decentralized: VCs can be part of decentralized identity systems, where control over identity is more in the hands of the individual rather than centralized authorities.
A university degree issued digitally by a university that can be verified by a potential employer, a government-issued ID that can be verified by a third-party service provider, or a COVID-19 vaccination certificate that health authorities can verify.
[Virtual credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/virtual-credential.md), that share a subset.
---
title: verifiable-data-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-data-registry
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-data-registry.md
---
# verifiable-data-registry
A role a system might perform by mediating issuance and verification of ACDCs. See [verifiable data registry](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-data-registries).
Source: Dr. S. Smith
a [Verifiable Data Structure](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-data-structure.md) that has actual content.
It contains either a log of signed statements or a cryptographic commitment ([digest](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md)) to those statements (via a Merkle tree or hash chained data structure).
---
title: verifiable-data-structure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-data-structure
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-data-structure.md
---
# verifiable-data-structure
A verifiable data structure is a data structure that incorporates cryptographic techniques to ensure the integrity and authenticity of its contents. It allows users to verify the correctness of the data stored within the structure without relying on a trusted third party. [Source ChatGPT](#Sources-Definition-ChatGPT)
Provides proof of key state for its identifier. In KERI it is the Key Event Log (`KEL`). Key management is embedded in KELs, including recovery from key compromise.
* * *
1. Boneh, D., & Shacham, H. (2018). Verifiable data structures for outsourced data. Foundations and Trends® in Privacy and Security, 2(1-2), 1-116.
2. Bamert, T., Decker, C., Elsen, L., Wattenhofer, R., & Welten, S. (2017). Have a snack, pay with bitcoins. Distributed Computing, 30(1), 69-93.
3. Ateniese, G., Kamara, S., & Katz, J. (2014). Provable data possession at untrusted stores. ACM Transactions on Information and System Security (TISSEC), 7(2), 222-238.
4. Andrychowicz, M., Dziembowski, S., Malinowski, D., & Mazurek, Ł. (2014). Secure multiparty computations on Bitcoin. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (pp. 628-639).
5. Pomarole, M., Zhang, Y., Rosulek, M., & Katz, J. (2014). Secure cloud backup and inference control. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (pp. 812-823).
---
title: verifiable-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-identifier.md
---
# verifiable-identifier
Cryptographically verifiable authentic decentralized identifier (verfiable [DID](https://weboftrust.github.io/WOT-terms/docs/glossary/DID.md))
---
title: verifiable-legal-entity-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-legal-entity-identifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable-legal-entity-identifier.md
---
# verifiable-legal-entity-identifier
Verifiable credentials are issued by authorized validation agents ([QVIs](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md)) under the governance of [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md), who delegate tasks to these agents. They provide cryptographic proof that the information about a legal entity, as linked to its Legal Entity Identifier (LEI), is verifiably authentic, accurate, and up-to-date.
The v in vLEI stands for “verifiable”, but what does that mean? In this case, "verifiable" comes from “Verifiable Credential”. A verifiable credential is just a collection of information with a mechanism that allows a computer to verify that the information has not been modified and that the information was originally stated to be correct by some third party (maybe a bank or the driving license authority). Often (almost always really), the information will include a link to the entity the information is about.
[Here](https://rapidlei.com/what-is-vlei/) at Rapidlei.
---
title: verifiable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifiable.md
---
# verifiable
a condition of a KEL: being internally consistent with the integrity of its backward and forward chaining digest and authenticity of its non-repudiable signatures.
Source: Dr. S. Smith
**Explanation**
Able to cryptographically verify a certain data structure on its [consistency](https://weboftrust.github.io/WOT-terms/docs/glossary/inconsistency.md) and its [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md)
A KEL is verifiable means all content in a KEL including the digests and the signatures on that content is verifiably compliant with respect to the KERI protocol. In other words, the KEL is internally consistent and has integrity vis-a-vis its backward and forward chaining digests and authenticity vis-a-vis its non-repudiable signatures. As a verifiable data structure, the KEL satisfies the KERI protocol-defined rules for that verifiability. This includes the cryptographic verification of any digests or signatures on the contents so digested or signed.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: verification
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verification
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verification.md
---
# verification
An action an [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) (of a principal) performs to determine the [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) of a claim or other digital object using a cryptographic key.
Source: ToIP glossary, Jan 2024.
In more technical words, the capability to (cryptographically) verify data received from peers (check structure, signatures, dates)
[verify](https://weboftrust.github.io/WOT-terms/docs/glossary/verify.md)
---
title: verified-integrity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verified-integrity
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verified-integrity.md
---
# verified-integrity
A mechanism that can unambiguously assess whether the information is/continues to be whole, sound and unimpaired
- In KERI's secure attribution focus integrity is verified by [internal consistency](https://weboftrust.github.io/WOT-terms/docs/glossary/internal-inconsistency.md) of [KE(R)L](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md) and [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) plus [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection.
- In ACDC the [self addressing identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md) (SAID) takes of verified integrity at all times by design
- The streaming protocol CESR has verifiable integrity due to it's code tables and round-robin [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md).
[integrity](https://weboftrust.github.io/WOT-terms/docs/glossary/integrity.md)
[(complementary) integrity verification](https://weboftrust.github.io/WOT-terms/docs/glossary/complementary-integrity-verification.md)
---
title: verifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifier
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verifier.md
---
# verifier
any entity or agent that cryptographically verifies the signature(s) and digests on an event Message.
Source Dr. S. Smith
the entity that (cryptographically) verifies data received from peers (check structure, signatures, dates). More narrowly defined for the KERI suite: cryptographically verifies signature(s) on an event message.
Notice the subtile difference between [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) and verifier.
Any entity or agent that cryptographically verifies the signature(s) and/or digests on an event message. In order to verify a signature, a verifier must first determine which set of keys are or were the controlling set for an identifier when an event was issued. In other words, a verifier must first establish control authority for an identifier. For identifiers that are declared as non-transferable at inception, this control establishment merely requires a copy of the inception event for the identifier. For identifiers that are declared transferable at inception, this control establishment requires a complete copy of the sequence of establishment events (inception and all rotations) for the identifier up to the time at which the statement was issued.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: verify-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verify-signature
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verify-signature.md
---
# verify-signature
Applying an algorithm that, given the message, public key and signature, either accepts or rejects the message's claim to authenticity.
---
title: verify
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verify
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/verify.md
---
# verify
The act, by or on behalf of a [party](https://weboftrust.github.io/WOT-terms/docs/glossary/party.md), of determining whether that data is [authentic](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) (i.e. originates from the party that authored it), timely (i.e. has not expired), and conforms to other specifications that apply to its structure.
[Source eSSIF-lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#verify) in eSSIF-lab glossary
[Verification](https://weboftrust.github.io/WOT-terms/docs/glossary/verification.md)
---
title: version-code
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/version-code
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/version-code.md
---
# version-code
tells you which set of tables to load, it tells the table state. It's a unique code. what version of the table is going to load.
[Version string](https://weboftrust.github.io/WOT-terms/docs/glossary/version-string.md)
---
title: version-string
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/version-string
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/version-string.md
---
# version-string
the first field in any top-level KERI field map in which it appears.
The Version String in JSON, CBOR and MGPK is a workaround to make those self-framing.
[Version code](https://weboftrust.github.io/WOT-terms/docs/glossary/version-code.md)
---
title: version
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/version
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/version.md
---
# version
an instance of a KEL for an AID in which at least one event is unique between two instances of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/kel.md).
Source: Dr. S. Smith
In [software engineering](https://en.wikipedia.org/wiki/Software_engineering), version control (also known as revision control, source control, or source code management) is a class of systems responsible for managing changes to [computer programs](https://en.wikipedia.org/wiki/Computer_program), documents, large web sites, or other collections of information.
[Source](https://en.wikipedia.org/wiki/Version_control)
More than one version of a KEL for an AID exists when for any two instances of a KEL at least one event is unique between the two instances.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: VID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/VID
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/VID.md
---
# VID
[Verifiable Identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-identifier.md)
---
title: virtual-credential-transaction-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/virtual-credential-transaction-event-log
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/virtual-credential-transaction-event-log.md
---
# virtual-credential-transaction-event-log
will track the issued or revoked state of each virtual credential (VC) and will contain a reference to its corresponding _management transaction event log (management TEL)_.
---
title: vlei-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vlei-credential
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vlei-credential.md
---
# vlei-credential
Credential concerning a verifiable Legal Entity Identifier, residing in the [GLEIS](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIS.md) and compliant with one or more of the GLEIF [Governance Framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md)s
---
title: vlei-ecosystem-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vlei-ecosystem-governance-framework
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vlei-ecosystem-governance-framework.md
---
# vlei-ecosystem-governance-framework
The Verifiable LEI (vLEI) Ecosystem [Governance Framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md) Information Trust Policies. It's a **document** that defines the information security, privacy, availability, confidentiality and processing integrity policies that apply to all vLEI Ecosystem Members.
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: vlei-role-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vlei-role-credential
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vlei-role-credential.md
---
# vlei-role-credential
It is a [vLEI credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md) that attests to a role within a legal entity to an individual or an entity. It cryptographically proves that the individual or entity is authorized to act in that role on behalf of the legal entity.
---
title: vLEI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vLEI
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vLEI.md
---
# vLEI
[Verifiable legal entity identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-legal-entity-identifier.md)
---
title: vrt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vrt
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/vrt.md
---
# vrt
vrt = vdr rotate, verifiable data registry rotation
---
title: wallet
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/wallet
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/wallet.md
---
# wallet
A crypto wallet is a device, physical medium, program or a service which stores the [public and/or private keys](https://en.wikipedia.org/wiki/Public-key_cryptography) for [cryptocurrency](https://en.wikipedia.org/wiki/Cryptocurrency) transactions and digital identifiers.
Paraphrased by @henkvancann from source [Wikipedia](https://en.wikipedia.org/wiki/Cryptocurrency_wallet)
A wallet is a collection of data stores; made up of a [keystore](https://weboftrust.github.io/WOT-terms/docs/glossary/keystore.md), local and remote key event log database and credential database. So it is a superset of a keystore.
Source: Philip Feairheller.
In a broader context a wallet can be seen as software and sometimes hardware that serves as a [keystore](https://weboftrust.github.io/WOT-terms/docs/glossary/keystore.md) and functionality. Keys can be private keys and public keys, and the wallet could contain hashes and pointers. Functionality can be signing, invoices (receive), send, virtual credentials, delegation, etc. This functionality is the [`agency`](https://weboftrust.github.io/WOT-terms/docs/glossary/agency.md) part of a wallet.
[More about digital ID Wallets](https://www.thalesgroup.com/en/markets/digital-identity-and-security/government/identity/digital-identity-services/digital-id-wallet)
[More about cryto Wallets](https://cryptocurrencyfacts.com/what-is-a-cryptocurrency-wallet/).
In addition to this basic function of **storing the keys**, it's also used to storing [verifiable credentials (VCs)](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md). A cryptocurrency wallet more often also offers the functionality of **[encrypting](https://en.wikipedia.org/wiki/Encrypting)** and/or **[signing](https://en.wikipedia.org/wiki/Digital_signature)** information.\\
Signing can for example result in executing a [smart contract](https://en.wikipedia.org/wiki/Smart_contract), a cryptocurrency transaction, [identification](https://en.wikipedia.org/wiki/Digital_signature#Authentication) or [legally signing](https://en.wikipedia.org/wiki/Electronic_signature) a 'document'.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Cryptocurrency_wallet)
A 'wallet' in KERI would typically refer to the basic function of **storing the keys**, a wallet in ACDC is more focussed on storing [verifiable credentials (VCs)](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md).\\
KERI explicitly distinguishes [keystore](https://weboftrust.github.io/WOT-terms/docs/glossary/keystore.md) and [wallet](https://weboftrust.github.io/WOT-terms/docs/glossary/wallet.md); the latter being a superset of the former. [Keep](https://weboftrust.github.io/WOT-terms/docs/glossary/keep.md) is KERI's and ACDC's user interface with Keripy agent API as a back end.
---
title: watcher
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/watcher
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/watcher.md
---
# watcher
an _entity_ or _component_ that keeps a copy of a [KERL](https://weboftrust.github.io/WOT-terms/docs/glossary/kerl.md) for an identifier but that is not designated by the _controller_ of the identifier as one of its witnesses. See annex [watcher](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md).
Source: Dr. S.Smith
KERI alternative to total global ordering and consensus protocols is a mechanism called [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection. In the [verification](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md) and [validation](https://weboftrust.github.io/WOT-terms/docs/glossary/validate.md) **watchers are all that matter**; they guarantee that logs are immutable by one very simple rule: "[first seen](https://weboftrust.github.io/WOT-terms/docs/glossary/first-seen.md) wins".
This would be a set of watchers (that the validators trust) that record any and all copies of key event logs (KEL) that they see. Because these watchers can be anyone and anywhere, any controller of a public identifier is at peril should they choose to publish inconsistent copies of their KEL. This removes the incentive to be duplicitous.
---
title: web-of-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/web-of-trust
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/web-of-trust.md
---
# web-of-trust
In cryptography, a web of trust is a concept used in [PGP](https://weboftrust.github.io/WOT-terms/docs/glossary/PGP.md), [GnuPG](https://weboftrust.github.io/WOT-terms/docs/glossary/gnu-privacy-guard.md), and other `OpenPGP`\-compatible systems to establish the authenticity of the binding between a public key and its owner.
Its _decentralized_ trust model is an alternative to the centralized trust model of a public key infrastructure (`PKI`), which relies exclusively on a certificate authority (or a hierarchy of such). As with computer networks, there are many independent webs of trust, and any user (through their identity certificate) can be a part of, and a link between, multiple webs. The web of trust concept was first put forth by PGP creator Phil Zimmermann in 1992 in the manual for PGP.
More on [Wikipedia](https://en.wikipedia.org/wiki/Web_of_trust)
---
title: weight-of-weights
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/weight-of-weights
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/weight-of-weights.md
---
# weight-of-weights
There are 2 levels in the multi-sign weighted thresholds of [multi-signatures](https://weboftrust.github.io/WOT-terms/docs/glossary/multisig.md) in [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) because the solution only needs to focus on _tightly cooperating teams_.
- An individual using split keys over devices
- A team of teams
All other use cases can be solved by other means in KERI (e.g. [delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md)).
It also gives the advantage that the resulting [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) is more straightforward. It's hard to implement a recursive weight - of weights in CESR. And because of the alleged lack of use cases, KERI don't need to go beyond two levels.
---
title: well-known-witnesses
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/well-known-witnesses
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/well-known-witnesses.md
---
# well-known-witnesses
Witness identifier creation by using _salts_ to initialize their key stores so that you can predict what identifiers will be created. For testing purposes only!
Don't use the creation of well-known witnesses in a production environment, but for running tests it's suitable.
---
title: witness
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/witness
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/witness.md
---
# witness
a witness is an entity or component designated (trusted) by the controller of an identifier. The primary role of a witness is to verify, sign, and keep events associated with an identifier. A witness is the controller of its own self-referential identifier which may or may not be the same as the identifier to which it is a witness. See also [KERI’s Algorithm for Witness Agreement](https://weboftrust.github.io/WOT-terms/docs/glossary/keri’s-algorithm-for-witness-agreement.md).
Source: Dr. S. Smith
In KERI and ACDC context, a witness is an entity or component designated (trusted) by the controller of an identifier. The primary role of a witness is to verify, sign, and keep events associated with an identifier. A witness is the controller of its own self-referential identifier which may or may not be the same as the identifier to which it is a witness.
An identifier witness, therefore, is part of its [trust basis](https://weboftrust.github.io/WOT-terms/docs/glossary/trust-domain.md) and may be controlled (but not necessarily so) by its [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md). The purpose of a pool of witnesses is to protect the controller from external exploit of its identifier.
The term _[Backer](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md)_ and _Witness_ are closely related in KERI but not synonyms or interchangeable.
Be sure to understand the narrow KERI definition of Witness well. You could easily be confused, for there are dozens of papers that use the term Witness in a similar way to KERI; for example [https://ieeexplore.ieee.org/document/8644609](https://ieeexplore.ieee.org/document/8644609) or 'segregated witness' in bitcoin, but it's far from the same concept.
More in the [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
Entity that may receive, verify, and store key events for an identifier. Each witness controls its own identifier used to sign key event messages, a controller is a special case of a witness.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: XBRL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/XBRL
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/XBRL.md
---
# XBRL
[eXtensible Business Reporting Language](https://weboftrust.github.io/WOT-terms/docs/glossary/extensible-business-reporting-language.md)
---
title: xip
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/xip
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/xip.md
---
# xip
A XIP message allows a transaction set to be a mini peer to peer exchange to become a verifiable data structure. It makes the transaction become duplicity evident.
Source [KERI meeting 2024-03-12](https://wiki.trustoverip.org/pages/viewpage.action?pageId=80876836)
---
title: zero-trust-computing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/zero-trust-computing
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/zero-trust-computing.md
---
# zero-trust-computing
A security model centered on the principle of "never trust, always verify." It assumes that threats can exist inside and outside the network, and thus, no entity — a device, user, or system — is inherently trusted. This approach requires continuous verification of all users and devices attempting to access network resources.
Best practices for the implementation of an autonomic identifier system should follow zero-trust computing principles. These principles are described at more length elsewhere but may be summarized as follows:
1. Network Hostility. The network is always hostile, internally & externally; the Locality is untrustworthy. Solutions must provide means to mitigate network layer security vulnerabilities (man-in-the-middle, DNS hijacking, BGP attacks).
2. E2E Security. Inter-host communication must be end-to-end signed/encrypted and data must be stored signed/encrypted. Data is signed/encrypted in motion and at rest.
3. E2E Provenance. Data flow transformations must be end-to-end provenanced using verifiable data items (verifiable data chains or VCs). Every change shall be provenanced.
4. Verify every time for everything. Every network interaction or data flow must be authenticated and authorized using best-practice cryptography.
5. Authorization is behavioral. Policies for authentication and authorization must be dynamically modified based on behavior (reputation).
6. No single point of trust. Policies for authentication and authorization must be governed by end-verified diffuse-trust distributed consensus. The diffuse trust protects the policy.
7. Hosts locked down. Hosts or host components executing any of the abovementioned logic must be locked down. Any changes to the host execution logic or behavior must be thoroughly security tested and validated over the respective possible combinations of hardware and software platforms. This means locking down key management and cryptographic operations on the devices. This includes key generation and storage, as well as signature generation and signature verification. These may benefit from the use of some form of trusted execution environment (TEE), either generally or especially in a trusted platform module (TPM) or a hardware security module (HSM). In addition to key management and cryptographic operations, special security measures must be implemented regarding the secure execution of the application logic (e.g., code injection, insecure object references, cross-site/service request forgery, cross-service scripting, etc.).
Source: Universal Identity Theory by Samuel Smith
[zero trust](https://weboftrust.github.io/WOT-terms/docs/glossary/zero-trust.md)
---
title: zero-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/zero-trust
md: https://weboftrust.github.io/WOT-terms/_safe-can-go-in-2026/zero-trust.md
---
# zero-trust
a Zero Trust approach trusts no one.
Zero Trust is a shift of network defenses toward a more comprehensive IT security model that allows organizations to restrict access controls to networks, applications, and environment without sacrificing performance and user experience. As more organizations do more computing outside their perimeter in the cloud, security teams find it increasingly difficult to trust or identify who and what should be allowed or trusted with access to their networks. As a result, an increasing number of organizations are adopting Zero Trust as an element or a component of their trust network architecture and enterprise security strategy.
Zero Trust is a security concept that requires all users, even those inside the organization’s enterprise network, to be authenticated, authorized, and continuously validating security configuration and posture, before being granted or keeping access to applications and data. This approach leverages advanced technologies such as multi-factor authentication, identity and access management (IAM), and next-generation endpoint security technology to verify the user’s identity and maintain system security.
---
title: 2022 11 22 Legal Entity VLEI Credential GF Prep 1.0 Publication V0.12 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/2022-11-22_Legal-Entity-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work
md: https://weboftrust.github.io/WOT-terms/_test/2022-11-22_Legal-Entity-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work.md
---
---
title: Converted Test Document Bij ChatGPT
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/converted_test_document_bij_chatGPT
md: https://weboftrust.github.io/WOT-terms/_test/converted_test_document_bij_chatGPT.md
---
---
title: Howtos
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/howtos
md: https://weboftrust.github.io/WOT-terms/_test/howtos.md
---
---
title: Kerific Test
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/kerific-test
md: https://weboftrust.github.io/WOT-terms/_test/kerific-test.md
---
---
title: Result
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/result
md: https://weboftrust.github.io/WOT-terms/_test/result.md
---
---
title: Term Test
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/term_test
md: https://weboftrust.github.io/WOT-terms/_test/term_test.md
---
---
title: Term Test2
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/term_test2
md: https://weboftrust.github.io/WOT-terms/_test/term_test2.md
---
---
title: Term Test3
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/term_test3
md: https://weboftrust.github.io/WOT-terms/_test/term_test3.md
---
---
title: Term Test4
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/term_test4
md: https://weboftrust.github.io/WOT-terms/_test/term_test4.md
---
---
title: KERI Suite Glossary
description: This is the KERI Suite Glossary.
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/did-webs-iiw37-tutorial/intro
md: https://weboftrust.github.io/WOT-terms/_test/did-webs-iiw37-tutorial/intro.md
---
# KERI Suite Glossary
This is the KERI Suite Glossary.
Also take a look at:
- [KERIDoc – Documentation](https://weboftrust.github.io/keridoc/)
- [KERISSE – Search engine](https://weboftrust.github.io/kerisse/)
---
title: 2022 10 28 Qualified VLEI Issuer VLEI Identifer Credential GF Prep 1.0 Publication V0.9 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-10-28_Qualified-vLEI-Issuer-vLEI-Identifer-Credential-GF-Prep-1.0-Publication_v0.9_work
md: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-10-28_Qualified-vLEI-Issuer-vLEI-Identifer-Credential-GF-Prep-1.0-Publication_v0.9_work.md
---
---
title: 2022 11 01 GLEIF Identifier GF Prep 1.0 Publication V0.6 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-01_GLEIF-Identifier-GF-Prep-1.0-Publication_v0.6_work
md: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-01_GLEIF-Identifier-GF-Prep-1.0-Publication_v0.6_work.md
---
---
title: 2022 11 22 Legal Entity VLEI Credential GF Prep 1.0 Publication V0.12 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-22_Legal-Entity-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work
md: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-22_Legal-Entity-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work.md
---
---
title: 2022 11 23 Legal Entity Engagement Context Role VLEI Credential GF Prep 1.0 Publication V0.12 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-23_Legal-Entity-Engagement-Context-Role-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work
md: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-23_Legal-Entity-Engagement-Context-Role-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work.md
---
---
title: 2022 11 23 Legal Entity Official Organizational Role VLEI Credential GF Prep 1.0 Publication V0.12 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-23_Legal-Entity-Official-Organizational-Role-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work
md: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-23_Legal-Entity-Official-Organizational-Role-vLEI-Credential-GF-Prep-1.0-Publication_v0.12_work.md
---
---
title: 1
Introduction
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-30_Legal-Entity-QVI-AUTH-vLEI-Credential-GF-Prep-1.0-Publication_v0.6_work
md: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-11-30_Legal-Entity-QVI-AUTH-vLEI-Credential-GF-Prep-1.0-Publication_v0.6_work.md
---
# 1
Introduction
---
title: 1
Related Specifications
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-12-01_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part 3-vLEI-Credential-Schema-Registry-Prep-1.0-Publication_v0.1_work
md: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-12-01_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part 3-vLEI-Credential-Schema-Registry-Prep-1.0-Publication_v0.1_work.md
---
# 1
Related Specifications
---
title: 2022 12 06 Verifiable LEI (VLEI) Ecosystem Governance Framework Technical Requirements Part1 KERI Infrastructure Prep 1.0 Publication V0.6 Work
source_url:
html: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-12-06_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part1-KERI-Infrastructure-Prep-1.0-Publication_v0.6_work
md: https://weboftrust.github.io/WOT-terms/_test/gleif-legal/2022-12-06_verifiable-LEI-(vLEI)-Ecosystem-Governance-Framework-Technical-Requirements-Part1-KERI-Infrastructure-Prep-1.0-Publication_v0.6_work.md
---
---
title: 2024 03 24 KERI Dev Call
source_url:
html: https://weboftrust.github.io/WOT-terms/_video/2024-03-24-KERI-dev-call
md: https://weboftrust.github.io/WOT-terms/_video/2024-03-24-KERI-dev-call.md
---
---
title: Lets Keri On Together
source_url:
html: https://weboftrust.github.io/WOT-terms/_video/lets-keri-on-together
md: https://weboftrust.github.io/WOT-terms/_video/lets-keri-on-together.md
---
---
title: abandoned identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/abandoned-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/abandoned-identifier.md
---
# abandoned identifier
An [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) is abandoned when either the [Inception](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md) or a subsequent [Rotation event](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md) rotates to an empty next key digest list (which means the next threshold must also be 0).
When an AID is abandoned, `ndigers` is zero (empty next key digest list ), so any event after the event that made it nontransferable is not accepted.
So more on the [Keripy github discussion page](https://github.com/WebOfTrust/keripy/discussions/821)
---
title: access-controlled-interaction
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/access-controlled-interaction
md: https://weboftrust.github.io/WOT-terms/04_glossary/access-controlled-interaction.md
---
# access-controlled-interaction
Access controlled actions like submitting a report. If you already have that report then load balancer needs a mechanism to drop repeated requests.
Source: Samuel Smith / Daniel Hardman / Lance Byrd - Zoom meeting KERI Suite Jan 16 2024; discussion minute 30-60 min
Replay attacks are less of a concern, other than DDoS attack using resubmissions.
[Registration Interaction](https://weboftrust.github.io/WOT-terms/docs/glossary/registration-interaction.md)
---
title: ACDC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ACDC
md: https://weboftrust.github.io/WOT-terms/04_glossary/ACDC.md
---
# ACDC
[authentic chained data container](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md)
---
title: ADC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ADC
md: https://weboftrust.github.io/WOT-terms/04_glossary/ADC.md
---
# ADC
[Authentic data container](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-data-container.md)
---
title: ADR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ADR
md: https://weboftrust.github.io/WOT-terms/04_glossary/ADR.md
---
# ADR
[Architectural Decision Record](https://weboftrust.github.io/WOT-terms/docs/glossary/architectural-decision-record.md)
---
title: agency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/agency
md: https://weboftrust.github.io/WOT-terms/04_glossary/agency.md
---
# agency
Agents can be people, edge computers and the functionality within [wallets](https://github.com/trustoverip/acdc/wiki/_new#digital-identity-wallet). The service an agent offers is [agency](https://weboftrust.github.io/WOT-terms/docs/glossary/agency.md).
---
title: custodial-agent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/agent
md: https://weboftrust.github.io/WOT-terms/04_glossary/agent.md
---
# custodial-agent
An [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) owned by an individual who has granted [signing authority](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-authority.md) to a custodian who is usually also the host of the running agent software. Using [partial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md) to facilitate custodial key management the owner of the identifier retains [rotational authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md) and thus the ability to "fire" the custodian at any time without requiring the cooperation of the custodian.
Custodial Agents are important for individuals who may not be comfortable managing their own [signing keys](https://weboftrust.github.io/WOT-terms/docs/glossary/digital-signature.md) and agent software but still want to participate in a decentralized identity ecosystem and they enable a software as a service business model without centralizing control on the service provider.
(Source: Philip Feairheller)
Since ninety-nine percent of people in the world might not feel comfortable taking responsibility for their own practical [key management](https://weboftrust.github.io/WOT-terms/docs/glossary/key-management.md) but still want to be stay in control over their assets and be able to hire and fire service providers, this functionality is considered a key feature for KERI and ACDC.
---
title: SAID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/AID
md: https://weboftrust.github.io/WOT-terms/04_glossary/AID.md
---
# SAID
[Self-addressing identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md)
---
title: ambient-verifiability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ambient-verifiability
md: https://weboftrust.github.io/WOT-terms/04_glossary/ambient-verifiability.md
---
# ambient-verifiability
Verifiable by anyone, anywhere, at anytime. Although this seems a general term, it was first used in the context of KERI by Sam Smith.
_Ambient Duplicity Detection_ is an example of ambient verifiability that describes the possibility of detecting duplicity by anyone, anywhere, anytime.
As soon as you limit any of the parameters of location, time or who can verify, it's not 'ambient verifiability' anymore. For a signature to be ambiently verifiable, it needs to have no restrictions on these parameters.
---
title: ample
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ample
md: https://weboftrust.github.io/WOT-terms/04_glossary/ample.md
---
# ample
The minimum required number of participants in an event to have a [supermajority](https://weboftrust.github.io/WOT-terms/docs/glossary/supermajority.md) so that one and only one agreement or consensus on an event may be reached. This is a critical part of the [KAACE](https://weboftrust.github.io/WOT-terms/docs/glossary/KAACE.md) agreement algorithm (consensus) in KERI for establishing consensus between witnesses on the key state of a KERI identifier.
This consensus on key state forms the basis for accountability for a KERI controller, or what a person who controls a KERI identifier may be held legally responsible for.
This supermajority is also called a _sufficient majority_ that is labeled _immune_ from certain kinds of attacks or faults.
From section **11.4.2.4 Immune** of v2.60 of the KERI whitepaper,
> Satisfaction of this constraint guarantees that at most one sufficient agreement occurs or none at all despite a dishonest controller but where at most F of the witnesses are potentially faulty.
Ample Agreement Constraint:
Can apply to either
1) a group of KERI witnesses for a witnessed event or 2) a group of KERI identifier controllers participating in a multi-signature group.
Ample witnesses avoids problems of accidental lockout from a multisig group which would occur if the signing threshold for the multisig group was set lower than the "ample" number of participants.
N = Number of total participants
M = Number of participants needed to get the guarantees of "ample"
Python code implementation from [keri.core.eventing.py](https://github.com/WebOfTrust/keripy/blob/development/src/keri/core/eventing.py) of the `ample` algorithm used in [KAACE](https://weboftrust.github.io/WOT-terms/docs/glossary/KAACE.md):
```
def ample(n, f=None, weak=True):
"""
Returns int as sufficient immune (ample) majority of n when n >=1
otherwise returns 0
Parameters:
n is int total number of elements
f is int optional fault number
weak is Boolean
If f is not None and
weak is True then minimize m for f
weak is False then maximize m for f that satisfies n >= 3*f+1
Else
weak is True then find maximum f and minimize m
weak is False then find maximum f and maximize m
n,m,f are subject to
f >= 1 if n > 0
n >= 3*f+1
(n+f+1)/2 <= m <= n-f
"""
n = max(0, n) # no negatives
if f is None:
f1 = max(1, max(0, n - 1) // 3) # least floor f subject to n >= 3*f+1
f2 = max(1, ceil(max(0, n - 1) / 3)) # most ceil f subject to n >= 3*f+1
if weak: # try both fs to see which one has lowest m
return min(n, ceil((n + f1 + 1) / 2), ceil((n + f2 + 1) / 2))
else:
return min(n, max(0, n - f1, ceil((n + f1 + 1) / 2)))
else:
f = max(0, f)
m1 = ceil((n + f + 1) / 2)
m2 = max(0, n - f)
if m2 < m1 and n > 0:
raise ValueError("Invalid f={} is too big for n={}.".format(f, n))
if weak:
return min(n, m1, m2)
else:
return min(n, max(m1, m2))
```
---
title: APC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/APC
md: https://weboftrust.github.io/WOT-terms/04_glossary/APC.md
---
# APC
[Authentic provenance chain](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-provenance-chain.md)
---
title: KAPI
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/API
md: https://weboftrust.github.io/WOT-terms/04_glossary/API.md
---
# KAPI
Application programmer interfaces (APIs) for the various components in the KERI ecosystem such as Controllers, Agents, Witnesses, Watchers, Registrars etc need by which they can share information. The unique properties of the KERI protocol require APIs that preserve those properties. We call the set of APIs the KERI API.
[Source Kapi Repo](https://github.com/WebOfTrust/kapi/blob/main/kapi.md)
---
title: append-only-event-logs
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/append-only-event-logs
md: https://weboftrust.github.io/WOT-terms/04_glossary/append-only-event-logs.md
---
# append-only-event-logs
Append-only is a property of computer data storage such that new data can be appended to the storage, but where existing data is immutable.
A blockchain is an example of an append-only log. The events can be transactions. Bitcoin is a well-known Append only log where the events are _totally ordered_ and signed transfers of control over unspent transaction output.
More on [Wikipedia](https://en.wikipedia.org/wiki/Append-only)
---
title: application-programming-interface
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/application-programming-interface
md: https://weboftrust.github.io/WOT-terms/04_glossary/application-programming-interface.md
---
# application-programming-interface
An application programming interface (API) is a way for two or more [computer programs](https://en.wikipedia.org/wiki/Computer_program) to communicate with each other. It is a type of software [interface](https://en.wikipedia.org/wiki/Interface_\(computing\)), offering a service to other pieces of [software](https://en.wikipedia.org/wiki/Software).
A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term [API](https://weboftrust.github.io/WOT-terms/docs/glossary/API.md) may refer either to the specification or to the implementation.
More on [source](https://en.wikipedia.org/wiki/API) Wikipedia.
---
title: architectural-decision-record
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/architectural-decision-record
md: https://weboftrust.github.io/WOT-terms/04_glossary/architectural-decision-record.md
---
# architectural-decision-record
Is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant.
[Source adr.github.io](https://adr.github.io/)
---
title: attribute
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/attribute
md: https://weboftrust.github.io/WOT-terms/04_glossary/attribute.md
---
# attribute
a top-level [field map](https://weboftrust.github.io/WOT-terms/docs/glossary/field-map.md) within an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) that provides a property of an entity that is inherent or assigned to the entity.
Source: Dr. S. Smith
---
title: attributional-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/attributional-trust
md: https://weboftrust.github.io/WOT-terms/04_glossary/attributional-trust.md
---
# attributional-trust
KERI offers cryptographic root-of-trust to establish attributional trust. In the real world you'd also need [reputational trust](https://weboftrust.github.io/WOT-terms/docs/glossary/reputational-trust.md). You can't have reputation without attributional trust.
Read more in source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf)
[Out-of-band Introduction](https://weboftrust.github.io/WOT-terms/docs/glossary/out-of-band-introduction.md)s (OOBIs) to establish attributional trust, like its done with OOBIs in KERI, is not the same as the high friction costs of establishing reputational trust by going through the heavy lifting of [identity assurance](https://weboftrust.github.io/WOT-terms/docs/glossary/identity-assurance.md) by a to be trusted middle-men party, like [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md).
---
title: authentic-chained-data-container
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-chained-data-container
md: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-chained-data-container.md
---
# authentic-chained-data-container
a directed acyclic graph with properties to provide a verifiable chain of [proof-of-authorship](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authorship.md). See the full [specification](https://trustoverip.github.io/tswg-acdc-specification/)
Source: Dr. S.Smith, 2024
Explained briefly, an ACDC or [ADC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-data-container.md) proves digital data consistency and authenticity in one go. An ACDC cryptographically secures commitment to the data contained, and its identifiers are self-addressing, which means they point to themselves and are also contained in the data.
---
title: authentic-data-container
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-data-container
md: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-data-container.md
---
# authentic-data-container
A mechanism for conveying data that allows the [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) of its content to be proved.
**Instance**
A [Verifiable Credential](https://w3.org/TR/vc-data-model/) is an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md).
---
title: authentic-data
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-data
md: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-data.md
---
# authentic-data
[Integer](https://weboftrust.github.io/WOT-terms/docs/glossary/integrity.md) and [Provenanced](https://weboftrust.github.io/WOT-terms/docs/glossary/provenance.md) data.
Source: Timothy Ruff, #IIW37
---
title: authentic-provenance-chain
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-provenance-chain
md: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-provenance-chain.md
---
# authentic-provenance-chain
Interlinked [presentations](https://weboftrust.github.io/WOT-terms/docs/glossary/presentation-exchange.md) of evidence that allow data to be tracked back to its origin in an objectively [verifiable](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable.md) way.
---
title: authentic-web
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-web
md: https://weboftrust.github.io/WOT-terms/04_glossary/authentic-web.md
---
# authentic-web
The authentic web is the internet as a whole giant verifiable data structure. Also called _Web5_. The web will be one big graph. That's the mental model of the 'authentic web'.
- `Signed at rest` - the data never throws away any signature of data. Because otherwise we can't validate data in the future
- `Key state at rest` - you need to solve this hard problem too. This is the hard problem [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) solves.
- `Signed in motion` - signatures get thrown away. You use ephemeral identifiers. You have to do everything anew every time you want to reconstruct a verifiable data structure. Therefore we need 'Signed at rest'.
- You can append to any part of the (directed-acyclic) [graph](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md)
- You can hop into the graph to verify any fragment of the graph
- You don't have to sign the data,you just have to sign hashes of this data
- Every tree that gets integrated in this giant graph-forest has its own [Root of Trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md)
KERI solves all hard problems of the authentic web in a scalable manner.
See more in [Concepts](https://weboftrust.github.io/keridoc/docs/concepts/concepts?level=2) behind KERI
---
title: authenticity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authenticity
md: https://weboftrust.github.io/WOT-terms/04_glossary/authenticity.md
---
# authenticity
The quality of having an objectively verifiable origin ; contrast [veracity](https://weboftrust.github.io/WOT-terms/docs/glossary/veracity.md). When a newspaper publishes a story about an event, every faithful reproduction of that story may be _authentic_ — but that does not mean the story was _true_ (has _veracity_).
Authenticity is strongly related to digital [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md). Ideally it should be [verifiable](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable.md) (to a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md)). The future picture therein is the [Authentic Web](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-web.md).
The three properties, authenticity, confidentiality, and privacy inhabit a trade space. ... One can have any two of the three (privacy, authenticity, confidentiality) at the highest level but not all three.
The trilemma insists that one must make a trade-off by prioritizing one or two properties over a third.
The ToIP [design goals](https://github.com/trustoverip/TechArch/blob/main/spec.md#61-design-goals) reflect that trade-off and provide an order of importance. The design goals indicate that one should start with high authenticity, then high confidentiality, and then as high as possible privacy, given there is no trade-off with respect to the other two.
More on [Source](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md) Samuel Smith SPAC whitepaper.
- [confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/confidentiality.md)
- [privacy](https://weboftrust.github.io/WOT-terms/docs/glossary/privacy.md)
---
title: authoritative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authoritative
md: https://weboftrust.github.io/WOT-terms/04_glossary/authoritative.md
---
# authoritative
Established control [authority](https://weboftrust.github.io/WOT-terms/docs/glossary/authority.md) over an identifier, that has received attestations to it, e.g. control over the identifier has been verified to its root-of-trust. So the (control over the) identifier is 'authoritative' because it can be considered accurate, renowned, honourable and / or respected.
Also used to describe [PKI](https://weboftrust.github.io/WOT-terms/docs/glossary/PKI.md) key pairs that have this feature.
1. Author: creator, [source-of-truth](https://weboftrust.github.io/WOT-terms/docs/glossary/source-of-truth.md)
2. Authentic: provable origin, [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md)
3. Authorized: consent, [loci-of-control](https://weboftrust.github.io/WOT-terms/docs/glossary/loci-of-control.md)
4. **Authoritative: accurate, reputable**
"A4" data control securely is established via [self-certifying](https://weboftrust.github.io/WOT-terms/docs/glossary/self-certifying-identifier.md) pseudonymous identifiers
[Source](https://youtu.be/L82O9nqHjRE) Samuel M. Smith
---
title: signing-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authority
md: https://weboftrust.github.io/WOT-terms/04_glossary/authority.md
---
# signing-authority
The authority to sign on behalf of the controller of the authoritative key pair. Often in situation where delegation has taken place, e.g. a custodial agent. These are limited rights because [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md) is not included.
The original controller of an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md) can hold exclusive [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md). Because control authority is split between two key sets, the first for signing-authority and the second ([pre-rotated](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-rotation.md)) for [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md), the associated thresholds and key list can be structured in such a way that a designated [custodial agent](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-agent.md) can hold signing authority while the original controller can hold exclusive rotation authority.
---
title: broken-object-level-authorization
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authorization
md: https://weboftrust.github.io/WOT-terms/04_glossary/authorization.md
---
# broken-object-level-authorization
Refers to [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) flaws where users can access data they shouldn't, due to inadequate permission checks on individual (sub)objects.
---
title: authorized-vlei-representative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/authorized-vlei-representative
md: https://weboftrust.github.io/WOT-terms/04_glossary/authorized-vlei-representative.md
---
# authorized-vlei-representative
Also 'AVR'. This a representative of a Legal Entity that are authorized by the [DAR](https://weboftrust.github.io/WOT-terms/docs/glossary/DAR.md) of a Legal Entity to request issuance and revocation of:
- vLEI Legal Entity Credentials
- Legal Entity Official Organizational Role vLEI Credentials ([OOR](https://weboftrust.github.io/WOT-terms/docs/glossary/official-organizational-role.md) vLEI Credentials)
- Legal Entity Engagement Context Role vLEI Credentials ([ECR](https://weboftrust.github.io/WOT-terms/docs/glossary/engagement-context-role.md) vLEI Credentials).
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: autonomic-computing-systems
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-computing-systems
md: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-computing-systems.md
---
# autonomic-computing-systems
Self managing computing systems using algorithmic governance, from the 90's way way way before DAOs. KERI creator Sam Smith worked at funded Navy research in the 90's on autonomic survivable systems as in "self-healing" systems: "We called them autonomic way back then".
---
title: root-autonomic-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-identifier.md
---
# root-autonomic-identifier
An entity may provide the [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) for some ecosystem (with delegation )via its root [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md). Let’s call this the _RID_ for "root AID". The RID must be protected using the highest level of [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) in its [key management](https://weboftrust.github.io/WOT-terms/docs/glossary/key-management.md).
Although through the use of a [multi-valent](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-valent.md) key management infrastructure, the entity can employ extreme protection of the RID while still enabling more performant key management infrastructure for its operations.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: autonomic-identity-system
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-identity-system
md: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-identity-system.md
---
# autonomic-identity-system
an identity system that includes a primary root-of-trust in self-certifying identifiers that are strongly bound at issuance to a cryptographic signing (public, private) key pair. An AIS enables any entity to establish control over an AN in an independent, interoperable, and portable way.
Source: Dr. S.Smith, 2024
There's nobody that can intervene with the establishment of the authenticity of a control operation because you can verify all the way back to the root-of-trust.
---
title: autonomic-namespace
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-namespace
md: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-namespace.md
---
# autonomic-namespace
a namespace that is self-certifying and hence self-administrating. An AN has a self-certifying prefix that provides cryptographic verification of root control authority over its namespace. All derived AIDs in the same AN share the same root-of-trust, source-of-truth, and locus-of-control (RSL). The governance of the namespace is, therefore, unified into one entity, that is, the controller who is/holds the root authority over the namespace.
Source: Dr. S.Smith, 2024
Namespaces are, therefore, portable and truly self-sovereign.
---
title: autonomic-trust-basis
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-trust-basis
md: https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-trust-basis.md
---
# autonomic-trust-basis
When we use an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) as the [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) we form a so-called _autonomic trust basis_. This is diagrammed as follows:
Two other trust bases are in common use for identifier systems. One we call _algorithmic_, the other is .
An algorithmic trust basis relies on some network of nodes running some type of Byzantine fault tolerant totally ordering distributed consensus algorithm for its root-of-trust. These networks are more commonly known as a shared ledger or blockchain such as Bitcoin, Ethereum, or Sovrin
The other commonly used trust basis in identifier systems is an _administrative_ or organizational _trust basis_, i.e. a trusted entity. This is neither [secure](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) nor [decentralized](https://weboftrust.github.io/WOT-terms/docs/glossary/decentralized-identifier.md).
---
title: AVR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/AVR
md: https://weboftrust.github.io/WOT-terms/04_glossary/AVR.md
---
# AVR
[Authorized vLEI Representative](https://weboftrust.github.io/WOT-terms/docs/glossary/authorized-vlei-representative.md)
---
title: ledger-backer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/backer
md: https://weboftrust.github.io/WOT-terms/04_glossary/backer.md
---
# ledger-backer
A [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) in KERI that is ledger-registered. It's a type of [backer](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md) that proof its authenticity by a signing key anchored to the public key of a data item on a (public) blockchain.
---
title: BADA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/BADA
md: https://weboftrust.github.io/WOT-terms/04_glossary/BADA.md
---
# BADA
[Best available data acceptance mechanism](https://weboftrust.github.io/WOT-terms/docs/glossary/best-available-data-acceptance-mechanism.md)
---
title: base-media-type
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/base-media-type
md: https://weboftrust.github.io/WOT-terms/04_glossary/base-media-type.md
---
# base-media-type
`credential` plus `ld` plus `json`.
Other media types of credentials are allowed by must provide either unidirectional or bidirectional transformations. So, for example, we would create credential+acdc+json and provide a unidirectional transformation to credential+ld+json.
We are going for `credential` plus `acdc` plus `json` without `@context`. The main objection to use `@context` is that it can change the meaning of a credential. The other way around: ACDCs will include W3C credentials.
Media types will be used to differentiate between types of credentials and verifiable credentials.
---
title: base64
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/base64
md: https://weboftrust.github.io/WOT-terms/04_glossary/base64.md
---
# base64
In [computer programming](https://en.wikipedia.org/wiki/Computer_programming), Base64 is a group of [binary-to-text encoding](https://en.wikipedia.org/wiki/Binary-to-text_encoding) schemes that represent [binary data](https://en.wikipedia.org/wiki/Binary_data) (more specifically, a sequence of 8-bit bytes) in sequences of 24 bits that can be represented by four 6-bit Base64 digits.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Base64)
---
title: bespoke-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/bespoke-credential
md: https://weboftrust.github.io/WOT-terms/04_glossary/bespoke-credential.md
---
# bespoke-credential
It's an [issuance](https://weboftrust.github.io/WOT-terms/docs/glossary/issuance-event.md) of the disclosure or presentation of other ACDCs. _Bespoke_ means _Custom_ or _tailor made_. A bespoke credential serves as an on-the-fly contract with the issuee; it's a self-referencing and self-contained contract between the issuer and the verifier. Mind you, here the issuer and issuee are merely the discloser and disclosee of another (set of) ACDC(s).
If I want consent terms attached to a presentation of an (set of) ACDC(s).
Consider a disclosure-specific ACDC, aka tailor made, custom or bespoke. The Issuer is the Discloser, the Issuee is the Disclosee. The rule section includes a context-specific (anti) assimilation clause that limits the use of the information to a single one-time usage purpose, that is for example, admittance to a restaurant. The ACDC includes an edge that references some other ACDC that may for example be a coupon or gift card. The attribute section could include the date and place of admittance.
For the code of this example, see this [section 11.1 in Github](https://weboftrust.github.io/ietf-acdc/draft-ssmith-acdc.html#section-11.1)
We can use all the tools available for issuance and presentation we already have.
Similar to a presentation exchange, a verifier will first be asked for what they are looking for, secondly the discloser creates the dataset and publishes only the structure and the fields. To accomplish this, thirdly a compact ACDC will be issued (you publish the fields, not the content) and then issuer asks to sign it first. After signing, the disclosee can get the content associated with the on-the-fly contract.
More at [Github source](https://weboftrust.github.io/ietf-acdc/draft-ssmith-acdc.html#name-disclosure-specific-bespoke)
---
title: best-available-data-acceptance-mechanism
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/best-available-data-acceptance-mechanism
md: https://weboftrust.github.io/WOT-terms/04_glossary/best-available-data-acceptance-mechanism.md
---
# best-available-data-acceptance-mechanism
The BADA security model provides a degree of [replay attack](https://weboftrust.github.io/WOT-terms/docs/glossary/replay-attack.md) protection. The attributate originator (issuer, author, source) is provided by an attached signature couple or quadruple. A single reply could have multiple originators. When used as an [authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/authorization.md) the reply attributes may include the identifier of the authorizer and the logic for processing the associated route may require a matching attachment. BADA is part of [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md)'s [Zero Trust Computing Architecture for Data Management](https://hackmd.io/Qsrfj7Y-TIGl5ESvrxWGxw): How to support Secure Async Data Flow Routing in KERI enabled Applications.
- [Run off the crud](https://weboftrust.github.io/WOT-terms/docs/glossary/run-off-the-crud.md)
- [RUN](https://weboftrust.github.io/WOT-terms/docs/glossary/read-update-nullify.md)
---
title: bexter
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/bexter
md: https://weboftrust.github.io/WOT-terms/04_glossary/bexter.md
---
# bexter
The class variable length text that is used in CESR and preserves the round-trip transposability using Base64 URL safe-only encoding even though the text variable length.
From [readthedocs.io](https://keripy.readthedocs.io/en/latest/?badge=latest)
Bexter is subclass of Matter, cryptographic material, for variable length strings that only contain Base64 URL safe characters, i.e. Base64 text (bext).
When created using the 'bext' paramaeter, the encoded matter in qb64 format in the text domain is more compact than would be the case if the string were passed in as raw bytes. The text is used as is to form the value part of the qb64 version not including the leader.
Due to ambiguity that arises from pre-padding bext whose length is a multiple of three with one or more 'A' chars. Any bext that starts with an 'A' and whose length is either a multiple of 3 or 4 may not round trip. Bext with a leading 'A' whose length is a multiple of four may have the leading 'A' stripped when round tripping.
- Bexter(bext='ABBB').bext == 'BBB'
- Bexter(bext='BBB').bext == 'BBB'
- Bexter(bext='ABBB').qb64 == '4AABABBB' == Bexter(bext='BBB').qb64
To avoid this problem, only use for applications of base 64 strings that never start with 'A'
Examples: base64 text strings:
- bext = ""
- qb64 = '4AAA'
- bext = "-"
- qb64 = '6AABAAA-'
- bext = "-A"
- qb64 = '5AABAA-A'
- bext = "-A-"
- qb64 = '4AABA-A-'
- bext = "-A-B"
- qb64 = '4AAB-A-B'
- CESR encoded paths for nested SADs and SAIDs
- CESR encoded fractionally weighted threshold expressions
Inherited Properties: (See Matter) .pad is int number of pad chars given raw .code is str derivation code to indicate cypher suite .raw is bytes crypto material only without code .index is int count of attached crypto material by context (receipts) .qb64 is str in Base64 fully qualified with derivation code + crypto mat .qb64b is bytes in Base64 fully qualified with derivation code + crypto mat .qb2 is bytes in binary with derivation code + crypto material .transferable is Boolean, True when transferable derivation code False otherwise Properties: .text is the Base64 text value, .qb64 with text code and leader removed. Hidden: .\_pad is method to compute .pad property .\_code is str value for .code property .\_raw is bytes value for .raw property .\_index is int value for .index property .\_infil is method to compute fully qualified Base64 from .raw and .code .\_exfil is method to extract .code and .raw from fully qualified Base64 Methods: """
---
title: BFT
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/BFT
md: https://weboftrust.github.io/WOT-terms/04_glossary/BFT.md
---
# BFT
[Byzantine fault tolerance](https://weboftrust.github.io/WOT-terms/docs/glossary/byzantine-fault-tolerance.md)
---
title: binding
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/binding
md: https://weboftrust.github.io/WOT-terms/04_glossary/binding.md
---
# binding
The technique of connecting two data elements together. In the context of [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md) it's the association of data or an [identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md) with another identifier or a subject (a person, organization or machine), thereby lifting the privacy of the subject through that connection, i.e. **binding**.
---
title: bis
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/bis
md: https://weboftrust.github.io/WOT-terms/04_glossary/bis.md
---
# bis
bis = backed vc issue, registry-backed transaction event log credential issuance
---
title: bivalent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/bivalent
md: https://weboftrust.github.io/WOT-terms/04_glossary/bivalent.md
---
# bivalent
A nested set of layered delegations in a [delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md) tree, wraps each layer with compromise recovery protection of the next higher layer. This maintains the security of the root layer for compromise recovery all the way out to the leaves in spite of the leaves using less secure key management methods.
To elaborate, in a [cooperative delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/cooperative-delegation.md), the key generation and storage functions of the delegator and delegate, in terms of controlling private keys, may be completely isolated from each other. This means that each may use its own independent key management infrastructure with no movement of private keys between the two infrastructures. We call this a **bivalent** key management infrastructure.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
[Multivalent](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-valent.md) [Univalent](https://weboftrust.github.io/WOT-terms/docs/glossary/univalent.md)
---
title: blake3
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/blake3
md: https://weboftrust.github.io/WOT-terms/04_glossary/blake3.md
---
# blake3
BLAKE3 is a relatively young (2020) cryptographic hash function based on Bao and BLAKE2.
BLAKE3 is a single algorithm with many desirable features (parallelism, XOF, KDF, PRF and MAC), in contrast to BLAKE and BLAKE2, which are algorithm families with multiple variants. BLAKE3 has a [binary tree](https://en.wikipedia.org/wiki/Binary_tree) structure, so it supports a practically unlimited degree of parallelism (both SIMD and multithreading) given long enough input.
The official [Rust](https://en.wikipedia.org/wiki/Rust_\(programming_language\)) and [C](https://en.wikipedia.org/wiki/C_\(programming_language\)) implementations[\[24\]](https://en.wikipedia.org/wiki/BLAKE_\(hash_function\)?wprov=srpw1_0#cite_note-BLAKE3-repo-24) are [dual-licensed](https://en.wikipedia.org/wiki/Multi-licensing) as public domain ([CC0](https://en.wikipedia.org/wiki/CC0)) and the [Apache License](https://en.wikipedia.org/wiki/Apache_License).
BLAKE3 is designed to be as fast as possible. It is consistently a few times faster than BLAKE2. The BLAKE3 compression function is closely based on that of BLAKE2s, with the biggest difference being that the number of rounds is reduced from 10 to 7, a change based on the assumption that current cryptography is too conservative. In addition to providing parallelism, the Merkle tree format also allows for verified streaming (on-the-fly verifying) and incremental updates.
---
title: blind-oobi
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/blind-oobi
md: https://weboftrust.github.io/WOT-terms/04_glossary/blind-oobi.md
---
# blind-oobi
A blind [OOBI](https://weboftrust.github.io/WOT-terms/docs/glossary/OOBI.md) means that you have some mechanisms in place for verifying the [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) instead of via the OOBI itself. A blind OOBI is essentially a [URL](https://weboftrust.github.io/WOT-terms/docs/glossary/URL.md). It's called "blind" because the witness is not in the OOBI itself. You haves other ways of verifying the AID supplied.
A blind OOBI through an AID that is on some witness list and has been verified to root-of-trust already. So you know the human being behind this referred AID. Because it's an AID that has a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md) out there, which has been securely established, you can trust it. So a blind OOBI makes a via-via commitment.
A natural person that you trust is an owner of an AID. Then you cryptographically commit this AID to another AID through some mechanism (e.g. a witness list).
> "Here's my public key and here's my AID and because this in an another witness list I trust it."
A 'blind' AID becomes "unblind" when you establish a direct relationship with human being who controls the referenced AID. You shortcut the blind OOBI because you established a direct OOBI to the formerly reference AID.
type 2 authentication: minimise the friction | TBW prio 3 |
Authentication by reference, latent authenticity
---
title: blinded-revocation-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/blinded-revocation-registry
md: https://weboftrust.github.io/WOT-terms/04_glossary/blinded-revocation-registry.md
---
# blinded-revocation-registry
The current state of a [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) (TEL) **may be hidden or blinded** such that _the only way_ for a potential verifier of the state to observe that state is _when the controller of a designated AID discloses it_ at the time of presentation.
| TBW: BE CAREFUL WITH THE REST, JUST TEXT SNIPPETS TYPED IN FROM A CONVERSATION |
No information can be obtained via a [rainbow table attack](https://weboftrust.github.io/WOT-terms/docs/glossary/rainbow-table-attack.md) because the hash has enough [entropy](https://weboftrust.github.io/WOT-terms/docs/glossary/entropy.md) added to it.
| TBW | on the basis of the last half hour of the recording ACDC meetup Dec 6 }
The issuer creates and signs the bulk issuance set of credentials and shares a salt with the presenters. The shared salt correlates between the issuer and the issuee, but that is the worst problem we have to consider, which is acceptable.
See more in the section [blindable state tel](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#blindable-state-tel)
The presenter does the decomposition in a way that allows a verifier to conclude: "Yes that was an approved schema issued by the issuer!"
---
title: BOLA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/BOLA
md: https://weboftrust.github.io/WOT-terms/04_glossary/BOLA.md
---
# BOLA
[Broken Object Level Authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/broken-object-level-authorization.md)
---
title: bran
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/bran
md: https://weboftrust.github.io/WOT-terms/04_glossary/bran.md
---
# bran
A cryptographic string used as a primary input, a seed, for creating key material for and [autonomic-identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md).
This is used in Signify TS:
- `Controller` [constructor argument](https://github.com/WebOfTrust/signify-ts/blob/516539f8bb68c8504e10221bf144a54b8c507dc3/src/keri/app/controller.ts#L104C77-L104C89)
```
constructor(bran: string, tier: Tier, ridx: number = 0, state: any | null = null) {
this.bran = MtrDex.Salt_128 + 'A' + bran.substring(0, 21) // qb64 salt for seed
this.stem = "signify:controller"
this.tier = tier
this.ridx = ridx
this.salter = new Salter({ qb64: this.bran, tier: this.tier })
...
```
Quote, a Zoom chat message, from Dr. Sam Smith on 8/22/23 in the Tuesday morning KERI & ACDC ToIP specification discussion call:
> We already use seed and salt for something else so bran is related to seed so we used a term that was evocative of its use but not conflict with already used seed
---
title: branch
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/branch
md: https://weboftrust.github.io/WOT-terms/04_glossary/branch.md
---
# branch
In software development a 'branch' refers to the result of branching: the duplication of an object under version control for further separate modification.
Branching, in [version control](https://en.wikipedia.org/wiki/Version_control) and [software configuration management](https://en.wikipedia.org/wiki/Software_configuration_management), is the duplication of an object under version control (such as a [source code](https://en.wikipedia.org/wiki/Source_code) file or a [directory tree](https://en.wikipedia.org/wiki/Directory_tree)). Each object can thereafter be modified separately and in parallel so that the objects become different. In this context the objects are called branches. The users of the version control system can branch any branch.
---
title: broken-object-level-authorization
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/broken-object-level-authorization
md: https://weboftrust.github.io/WOT-terms/04_glossary/broken-object-level-authorization.md
---
# broken-object-level-authorization
Refers to [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) flaws where users can access data they shouldn't, due to inadequate permission checks on individual (sub)objects.
---
title: brv
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/brv
md: https://weboftrust.github.io/WOT-terms/04_glossary/brv.md
---
# brv
brv = backed vc revoke, registry-backed transaction event log credential revocation
---
title: byzantine-agreement
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/byzantine-agreement
md: https://weboftrust.github.io/WOT-terms/04_glossary/byzantine-agreement.md
---
# byzantine-agreement
(non PoW) Byzantine Agreement is [Byzantine fault tolerance](https://weboftrust.github.io/WOT-terms/docs/glossary/byzantine-fault-tolerance.md) of distributed computing systems that enable them to come to consensus despite arbitrary behavior from a fraction of the nodes in the network. BA consensus makes no assumptions about the behavior of nodes in the system. Practical Byzantine Fault Tolerance (pBFT) is the prototypical model for Byzantine agreement, and it can reach consensus fast and efficiently while concurrently decoupling consensus from resources (i.e., financial stake in PoS or electricity in PoW).
[More](https://blockonomi.com/stellar-consensus-protocol/) about the Stellar consensus protocol
```
"What if PBFT and Stellar had a baby?
that was missing liveness and total ordering
but had safety and was completely decentralized, portable, and permission-less?
It would be named KERI."
SamMSmith
```
---
title: byzantine-fault-tolerance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/byzantine-fault-tolerance
md: https://weboftrust.github.io/WOT-terms/04_glossary/byzantine-fault-tolerance.md
---
# byzantine-fault-tolerance
A Byzantine fault (also interactive consistency, source congruency, error avalanche, [Byzantine agreement](https://weboftrust.github.io/WOT-terms/docs/glossary/byzantine-agreement.md) problem, Byzantine generals problem, and Byzantine failure) is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed.
The term takes its name from an allegory, the "Byzantine Generals Problem", developed to describe a situation in which, in order to avoid catastrophic failure of the system, the system's actors must agree on a concerted strategy, but some of these actors are unreliable. In a Byzantine fault, a component such as a server can inconsistently appear as both failed and functioning to failure-detection systems, presenting different symptoms to different observers. It is difficult for the other components to declare it failed and shut it out of the network because they need first to reach a consensus regarding which component has failed in the first place. Byzantine fault tolerance (BFT) is the dependability of a fault-tolerant computer system to such conditions.
A system has Byzantine Fault Tolerance (BFT) when it can keep functioning correctly as long as two-thirds of the network agrees or reaches a consensus. BFT is a property or characteristic of a system that can resist up to one-third of the nodes failing or acting maliciously.
The pBFT model primarily focuses on providing a practical Byzantine state machine replication that tolerates Byzantine faults (malicious nodes) through an assumption that there are independent node failures and manipulated messages propagated by specific, independent nodes. The algorithm is designed to work in asynchronous systems and is optimized to be high-performance with an impressive overhead runtime and only a slight increase in latency. More on Wikipedia about
- [Byzantine Fault](https://en.wikipedia.org/wiki/Byzantine_fault)
- [pBFT](https://en.bitcoinwiki.org/wiki/PBFT) : An article that explains practical BFT.
- [Here](https://blockonomi.com/practical-byzantine-fault-tolerance/)'s a complete beginners guide.
---
title: Canonicalization
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/canonicalization
md: https://weboftrust.github.io/WOT-terms/04_glossary/canonicalization.md
---
# Canonicalization
In computer science, canonicalization (sometimes standardization or [normalization](https://en.wikipedia.org/wiki/Normalization_\(statistics\))) is a process for converting data that has more than one possible representation into a "standard," "normal," or [canonical form](https://en.wikipedia.org/wiki/Canonical_form).
This can be done to compare different representations for equivalence, to count the number of distinct data structures, to improve the efficiency of various algorithms by eliminating repeated calculations, or to make it possible to impose a meaningful sorting order.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Canonicalization)
---
title: CBOR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/CBOR
md: https://weboftrust.github.io/WOT-terms/04_glossary/CBOR.md
---
# CBOR
[Concise Binary Object Representation](https://weboftrust.github.io/WOT-terms/docs/glossary/concise-binary-object-representation.md)
---
title: certificate-transparency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/certificate-transparency
md: https://weboftrust.github.io/WOT-terms/04_glossary/certificate-transparency.md
---
# certificate-transparency
Certificate Transparency (CT) is an Internet security standard and open source framework for monitoring and auditing digital certificates. The standard creates a system of public logs that seek to eventually record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates. As of 2021, Certificate Transparency is mandatory for all SSL/TLS certificates.
Certificate Transparency was a response to the 2011 attack on DigiNotar and other Certificate Authorities. These attacks showed that the lack of transparency in the way CAs operated was a significant risk to the Web Public Key Infrastructure. It led to the creation of this ambitious project to improve security online by bringing accountability to the system that protects HTTPS.
More on [certificate.transparency.dev](https://certificate.transparency.dev/) and [Wikipedia](https://en.wikipedia.org/wiki/Certificate_Transparency).
---
title: cesr-proof-signatures
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cesr-proof-signatures
md: https://weboftrust.github.io/WOT-terms/04_glossary/cesr-proof-signatures.md
---
# cesr-proof-signatures
CESR Proof Signatures is an extension to the Composable Event Streaming Representation \[CESR\] that provides transposable cryptographic signature attachments on self-addressing data [(SAD)](https://weboftrust.github.io/WOT-terms/docs/glossary/SAD.md). Any SAD, such as an Authentic Chained Data Container (ACDC) Verifiable Credential \[ACDC\], for example, may be signed with a CESR Proof Signature and streamed along with any other CESR content. In addition, a signed SAD can be embedded inside another SAD, and the CESR proof signature attachment can be transposed across envelope boundaries and streamed without losing any cryptographic integrity.
(Philip Feairheller, IETF-cesr-proof)
---
title: CESR-version
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/CESR-version
md: https://weboftrust.github.io/WOT-terms/04_glossary/CESR-version.md
---
# CESR-version
the CESR Version is provided by a special Count Code that specifies the Version of all the CESR code tables in a given Stream or Stream section.
Source: Dr. S. Smith
---
title: CESR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/CESR
md: https://weboftrust.github.io/WOT-terms/04_glossary/CESR.md
---
# CESR
[composable event streaming representation](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md)
---
title: cesride
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cesride
md: https://weboftrust.github.io/WOT-terms/04_glossary/cesride.md
---
# cesride
is concerned with parsing CESR primitives.
Cesride is built from cryptographic primitives that are named clearly and concisely. There are:
- [Diger](https://weboftrust.github.io/WOT-terms/docs/glossary/diger.md)
- [Verfer](https://weboftrust.github.io/WOT-terms/docs/glossary/verfer.md)
- [Signer](https://weboftrust.github.io/WOT-terms/docs/glossary/signer.md)
- [Siger](https://weboftrust.github.io/WOT-terms/docs/glossary/siger.md)
- [Cigar](https://weboftrust.github.io/WOT-terms/docs/glossary/cigar.md)
- [Salter](https://weboftrust.github.io/WOT-terms/docs/glossary/salter.md)
Each primitive will have methods attached to it that permit one to generate and parse the qualified base2 or [base64](https://weboftrust.github.io/WOT-terms/docs/glossary/base64.md) representation.
Common methods you'll find:
- `.qb64()` - qualified base-64 representation of cryptographic material as a string
- `.qb64b()` - qualified base-64 representation of cryptographic material as octets (bytes)
- `.qb2()` - qualified base-2 representation of cryptographic material as octets (bytes)
- `.code()` - qualifying code (describes the type of cryptographic material)
- `.raw()` - raw cryptographic material (unqualified) as octets (bytes)
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
[Parside](https://weboftrust.github.io/WOT-terms/docs/glossary/parside.md)
---
title: chain-link-confidential-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/chain-link-confidential-disclosure
md: https://weboftrust.github.io/WOT-terms/04_glossary/chain-link-confidential-disclosure.md
---
# chain-link-confidential-disclosure
contractual restrictions and liability imposed on a recipient of a disclosed [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) that contractually link the obligations to protect the disclosure of the information contained within the ACDC to all subsequent recipients as the information moves downstream. The Chain-link Confidential Disclosure provides a mechanism for protecting against un-permissioned exploitation of the data disclosed via an ACDC.
Source: Dr. S.Smith
---
title: chain-link-confidentiality
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/chain-link-confidentiality
md: https://weboftrust.github.io/WOT-terms/04_glossary/chain-link-confidentiality.md
---
# chain-link-confidentiality
Chains together a sequence of [Disclosees](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md) which may also include a set of constraints on data usage by both second and third parties expressed in legal language such that the constraints apply to all recipients of the disclosed data thus the phrase "chain link" confidentiality. Each Disclosee in the sequence in turn is the [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) to the next Disclosee.
This is the primary mechanism of granting digital data rights through binding information exchange to confidentiality laws. Confidentiality is dynamically negotiated on a per-event, per-data exchange basis according to the data that is being shared in a given exchange.
Disclosures via [Presentations Exchanges](https://weboftrust.github.io/WOT-terms/docs/glossary/presentation-exchange.md) may be contractually protected by Chain-Link Confidentiality (i.e. a Chain-Link Confidential disclosure). The chaining in this case is different from the chaining described above between Issuances in a [DAG](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) of chained Issuances. Chain-link confidentiality, in contrast, chains together a sequence of Disclosees.
More info at [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#chain-link-confidentiality)
An important article on the topic can be found here:
[Woodrow Hartzog “Chain-Link Confidentiality”](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818)
---
title: chain-of-custody
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/chain-of-custody
md: https://weboftrust.github.io/WOT-terms/04_glossary/chain-of-custody.md
---
# chain-of-custody
From Wikipedia ([Source](https://en.wikipedia.org/wiki/Chain_of_custody)): Chain of custody (CoC), in legal contexts, is the chronological documentation or [paper trail](https://en.wiktionary.org/wiki/paper_trail) that records the sequence of custody, control, transfer, analysis, and disposition of materials, including physical or electronic [evidence](https://en.wikipedia.org/wiki/Evidence). Of particular importance in criminal cases, the concept is also applied in civil litigation and more broadly in drug testing of athletes and in [supply chain management](https://en.wikipedia.org/wiki/Supply_chain_management), e.g. to improve the [traceability](https://en.wikipedia.org/wiki/Traceability) of food products, or to provide assurances that wood products originate from [sustainably managed forests](https://en.wikipedia.org/wiki/Sustainable_forest_management).
It is often a tedious process that has been required for evidence to be shown legally in court. Now, however, with new portable technology that allows accurate laboratory quality results from the scene of the crime, the chain of custody is often much shorter which means evidence can be processed for court much faster.
([Source](https://en.wikipedia.org/wiki/Chain_of_custody))
---
title: cigar
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cigar
md: https://weboftrust.github.io/WOT-terms/04_glossary/cigar.md
---
# cigar
An **_un_**[indexed signature](https://weboftrust.github.io/WOT-terms/docs/glossary/indexed-signature.md).
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: claim
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/claim
md: https://weboftrust.github.io/WOT-terms/04_glossary/claim.md
---
# claim
An assertion of the truth of something, typically one which is disputed or in doubt. A set of claims might convey personally identifying information: name, address, date of birth and citizenship, for example. ([Source](https://www.identityblog.com/?p=352)).
---
title: CLC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/CLC
md: https://weboftrust.github.io/WOT-terms/04_glossary/CLC.md
---
# CLC
[Chain link confidential](https://weboftrust.github.io/WOT-terms/docs/glossary/chain-link-confidentiality.md)
---
title: clone
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/clone
md: https://weboftrust.github.io/WOT-terms/04_glossary/clone.md
---
# clone
A copy of a system that is - and works exactly as the original
In [computing](https://en.wikipedia.org/wiki/Computing), a clone is [hardware](https://en.wikipedia.org/wiki/Computer_hardware) or [software](https://en.wikipedia.org/wiki/Software) that is designed to function in exactly the same way as another system.
A specific subset of clones are remakes (or remades), which are revivals of old, obsolete, or discontinued products.
[Source Wikipedia](https://en.wikipedia.org/wiki/Clone_\(computing\))
---
title: cloud-agent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cloud-agent
md: https://weboftrust.github.io/WOT-terms/04_glossary/cloud-agent.md
---
# cloud-agent
Cloud agent is software that is installed on the cloud server instances in order to provide security, monitoring, and analysis solutions for the cloud. They actually provide information and helps to provide control over cloud entities.
_Paraphrased by @henkvancann based on [source](https://www.cloudopedia.com/cloud-agent/)_.
Also see [Agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md).
Cloud computing[\[1\]](https://en.wikipedia.org/wiki/Cloud_computing?wprov=srpw1_1#cite_note-urlAn_Introduction_to_Dew_Computing:_Definition''',_Concept_and_Implications_-_IEEE_Journals_&_Magazine-1) is the on-demand availability of [computer](https://en.wikipedia.org/wiki/Computer) [system resources](https://en.wikipedia.org/wiki/System_resource), especially data storage ([cloud storage](https://en.wikipedia.org/wiki/Cloud_storage)) and [computing power](https://en.wikipedia.org/wiki/Computing_power), without direct active management by the user.
[More](https://en.wikipedia.org/wiki/Cloud_computing) at source on Wikipedia
---
title: code-table-selector
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/code-table-selector
md: https://weboftrust.github.io/WOT-terms/04_glossary/code-table-selector.md
---
# code-table-selector
the first character in the text code of [CESR stream](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md) that determines which [code table](https://weboftrust.github.io/WOT-terms/docs/glossary/code-table.md) to use, either a default code table or a code table selector character when not the default code table. Thus the 1 character text code table must do double duty. It must provide selectors for the different text code tables and also provide type codes for the most popular primitives that have a pad size of 1 that appear is the default code table.
See row 1.
---
title: code-table
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/code-table
md: https://weboftrust.github.io/WOT-terms/04_glossary/code-table.md
---
# code-table
a code table is the Internet's most comprehensive yet simple resource for browsing and searching for [alt codes](https://www.codetable.net/altkeycodes), [ascii codes](https://www.codetable.net/asciikeycodes), [entities in html](https://www.codetable.net/entitiesinhtml), [unicode characters](https://www.codetable.net/unicodecharacters), and [unicode groups and categories](https://www.codetable.net/groups).
[Source](https://www.codetable.net)
Multiple text and binary code tables exist to pre-pend characters before the respective stream parts to characterize ([self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md)) them or group them.
---
title: cold-start-stream-parsing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cold-start-stream-parsing
md: https://weboftrust.github.io/WOT-terms/04_glossary/cold-start-stream-parsing.md
---
# cold-start-stream-parsing
After a reboot (or cold start), a stream processor looks for framing information to know how to parse groups of elements in the stream.
If that framing information is ambiguous then the parser may become confused and require yet another cold start. While processing a given stream a parser may become confused especially if a portion of the stream is malformed in some way. This usually requires flushing the stream and forcing a cold start to resynchronize the parser to subsequent stream elements.
Better than flushing the stream and forcing a cold start is a re-synchronization mechanism that does not require flushing the in-transit buffers but merely skipping to the next well-defined stream element boundary in order to execute a cold start.
_See an example_ in the [source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#cold-start-stream-parsing-problem)
Special CESR count codes support re-synchronization at each boundary between interleaved CESR and other serializations like JSON, CBOR, or MGPK.
---
title: collective-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/collective-signature
md: https://weboftrust.github.io/WOT-terms/04_glossary/collective-signature.md
---
# collective-signature
a group signature scheme, that (i) is shared by a set of signing groups and (ii) combined collective signature shared by several signing groups and several individual signers. The protocol of the first type is constructed and described in detail. It is possible to modify the described protocol which allows transforming the protocol of the first type into the protocol of the second type. The proposed collective signature protocols have significant merits, one of which is connected with possibility of their practical using on the base of the existing public key infrastructures.
[Source](https://link.springer.com/chapter/10.1007/978-981-10-7512-4_20)
Collective signature have a variable length as a function of the number of signers.
---
title: collision
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/collision
md: https://weboftrust.github.io/WOT-terms/04_glossary/collision.md
---
# collision
In cryptography and identity _collision_ generally refers to something going wrong because an identical result has been produced but it refers to - or points to - different sources or assets backing this result.
E.g. two hashes collide, meaning two different digital sources produce the same hash.
Another example is [name(space) collision](https://en.wikipedia.org/wiki/Naming_collision).
A circumstance where two or more identifiers in a given [namespace](https://weboftrust.github.io/WOT-terms/docs/glossary/namespace.md) or a given scope cannot be unambiguously resolved.
[Source Wikipedia](https://en.wikipedia.org/wiki/Naming_collision)
---
title: compact-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/compact-disclosure
md: https://weboftrust.github.io/WOT-terms/04_glossary/compact-disclosure.md
---
# compact-disclosure
a disclosure of an ACDC that discloses only the SAID(s) of some or all of its field maps. Both Partial and Selective Disclosure rely on Compact Disclosure.
Source: Dr. S. Smith
---
title: compact-variant
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/compact-variant
md: https://weboftrust.github.io/WOT-terms/04_glossary/compact-variant.md
---
# compact-variant
Either a [most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version of an ACDC or the [fully compact](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-compact.md) version of an ACDC. An [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) commitment via a signature to any variant of ACDC (compact, full, etc) makes a cryptographic commitment to the top-level section fields shared by all variants of that ACDC because the value of a [top level section field](https://weboftrust.github.io/WOT-terms/docs/glossary/top-level-section.md) is either the [SAD](https://weboftrust.github.io/WOT-terms/docs/glossary/SAD.md) or the [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md) of the SAD of the associated section.
All the variants of an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) are various degrees of expansion of the compact variant.
More at [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md)
[Fully (expanded)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-expanded.md) version of an ACDC
[Fully compact(ed)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-compact.md) version of an ACDC
[Most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version of an ACDC.
---
title: complementary-integrity-verification
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/complementary-integrity-verification
md: https://weboftrust.github.io/WOT-terms/04_glossary/complementary-integrity-verification.md
---
# complementary-integrity-verification
A mechanism that can verify integrity independent of needing access to a previous instance or reference version of the information for comparison.
Source: Neil Thomson
Independent Integrity Verification is what is achieved by use of a public key from the data "controller" such that it does not need to compare received data/messages against the sent data/message.
The already verified chain up to a certain point in time in the past (previous instance or reference version) no longer needs to be verified.
> Example: The tail of a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) that has been verified to its [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) on a certain date and time, can be cut off. You don't need to verify this any more from this date.
[integrity](https://weboftrust.github.io/WOT-terms/docs/glossary/integrity.md)
[verified integrity](https://weboftrust.github.io/WOT-terms/docs/glossary/verified-integrity.md)
---
title: text-binary-concatenation-composability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/composability
md: https://weboftrust.github.io/WOT-terms/04_glossary/composability.md
---
# text-binary-concatenation-composability
An encoding has _composability_ when any set of [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) concatenated primitives expressed in either the text domain or binary domain may be converted as a group to the other domain and back again without loss.
CESR is fully text binary concatenation composable.
Use Google Translate to translate a piece of text from English to Dutch. Subsequently, keep copy pasting the resulting “to:” text into the “from:” field. The message changes until it comes to a standstill where you can keep swapping the texts without them changing.
The conclusion is: Google Translate is not composable!
By contrast, CESR is composable. The _analogy_ lies in the fact that we consider two languages. Suppose the English in the Google Translate example is _readable, text based_ in CESR and Dutch is the _binary_ form in CESR. Within these two CESR “languages”, text-based and binary, you can concatenate and swap freely as many times as you like — the data won’t change in between in their binary or text form no matter what content you express with them.
More explanation in [source](https://medium.com/happy-blockchains/cesr-one-of-sam-smiths-inventions-is-as-controversial-as-genius-d757f36b88f8).
---
title: composable-event-streaming-representation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/composable-event-streaming-representation
md: https://weboftrust.github.io/WOT-terms/04_glossary/composable-event-streaming-representation.md
---
# composable-event-streaming-representation
Also called 'CESR'. This compact encoding scheme fully supports both textual and binary streaming applications of attached crypto material of all types. This approach includes [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) in both the textual and binary streaming domains. The [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md) may be the minimum possible but still composable size.
Making composability a guaranteed property allows future extensible support of new compositions of streaming formats based on pre-existing core primitives and compositions of core primitives. This enables optimized stream processing in both the binary and text domains.
---
title: composable
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/composable
md: https://weboftrust.github.io/WOT-terms/04_glossary/composable.md
---
# composable
[Composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md)
---
title: concatenation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/concatenation
md: https://weboftrust.github.io/WOT-terms/04_glossary/concatenation.md
---
# concatenation
In [formal language theory](https://en.wikipedia.org/wiki/Formal_language) and [computer programming](https://en.wikipedia.org/wiki/Computer_programming), string concatenation is the operation of joining [character strings](https://en.wikipedia.org/wiki/Character_string_\(computer_science\)) [end-to-end](https://en.wiktionary.org/wiki/end-to-end). For example, the concatenation of "snow" and "ball" is "snowball".
More on source [Wikipedia page](https://en.wikipedia.org/wiki/Concatenation)
In CESR Concatenation is an important property of CESR's [Composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md); it is associative and may be applied to any two [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md) or any two groups or sets of concatenated primitives.
The composability property of CESR allows us to create arbitrary compositions of primitives via concatenation in either the text or binary domain and then convert the composition en masse to the other domain and then de-concatenate the result without loss. The [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) property of the primitives enables de-concatenation.
---
title: concise-binary-object-representation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/concise-binary-object-representation
md: https://weboftrust.github.io/WOT-terms/04_glossary/concise-binary-object-representation.md
---
# concise-binary-object-representation
a binary serialization format, similar in concept to JSON but aiming for greater conciseness. Defined in \[[RFC7049](https://trustoverip.github.io/tswg-keri-specification/#ref:RFC7049)\].
Source: Dr. S.Smith, 2024
It is a binary data [serialization](https://en.wikipedia.org/wiki/Serialization) format loosely based on [JSON](https://en.wikipedia.org/wiki/JSON) authored by C. Bormann. Like JSON it allows the transmission of data objects that contain [name–value pairs](https://en.wikipedia.org/wiki/Attribute%E2%80%93value_pair), but in a more concise manner. This increases processing and transfer speeds at the cost of [human readability](https://en.wikipedia.org/wiki/Human-readable_medium).
It is defined in IETF [RFC](https://en.wikipedia.org/wiki/RFC_\(identifier\)) [8949](https://datatracker.ietf.org/doc/html/rfc8949).[\[1\]](https://en.wikipedia.org/wiki/CBOR#cite_note-:0-1)
CBOR was inspired by [MessagePack](https://en.wikipedia.org/wiki/MessagePack), which was developed and promoted by Sadayuki Furuhashi. CBOR extended MessagePack, particularly by allowing to distinguish text strings from byte strings, which was implemented in 2013 in MessagePack.[\[4\]](https://en.wikipedia.org/wiki/CBOR#cite_note-4)[\[5\]](https://en.wikipedia.org/wiki/CBOR#cite_note-rfc8949-5)
[CBOR](https://en.wikipedia.org/wiki/CBOR)
---
title: secure-private-authentic-confidentiality
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/confidentiality
md: https://weboftrust.github.io/WOT-terms/04_glossary/confidentiality.md
---
# secure-private-authentic-confidentiality
ToIP Trust Spanning Layer Group realized we do have a secure authentication layer (KERI) but we don't have a secure confidentiality and privacy mechanism. Sam Smith proposes SPAC paper to define this. Related: [https://www.usenix.org/system/files/sec22-cohen.pdf](https://www.usenix.org/system/files/sec22-cohen.pdf)
If someone has set up a public AID, with public Witnesses we don't have a mechanism to support private communication with this AID | TBW |
[SPAC paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md)
Tech meet KERI [recording](https://hackmd.io/-soUScAqQEaSw5MJ71899w#2023-06-27) from minute 35, date June 29 2023 and also discussed Tech meeting KERI Aug 3 2023 from minute 30 or so till end.
---
title: configuration-files
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/configuration-files
md: https://weboftrust.github.io/WOT-terms/04_glossary/configuration-files.md
---
# configuration-files
In [computing](https://en.wikipedia.org/wiki/Computing), configuration files (commonly known simply as config files) are [files](https://en.wikipedia.org/wiki/Computer_file) used to configure the [parameters](https://en.wikipedia.org/wiki/Parameter_\(computer_programming\)) and [initial settings](https://en.wikipedia.org/wiki/Initialization_\(programming\)) for some [computer programs](https://en.wikipedia.org/wiki/Computer_program). They are used for user [applications](https://en.wikipedia.org/wiki/Application_software), [server processes](https://en.wikipedia.org/wiki/Server_\(computing\)) and [operating system](https://en.wikipedia.org/wiki/Operating_system) settings.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Configuration_file)
---
title: Configuration traits
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/configuration-traits
md: https://weboftrust.github.io/WOT-terms/04_glossary/configuration-traits.md
---
# Configuration traits
a list of specially defined strings representing a configuration of a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md). See [Configuration traits field](#configuration-traits-field).
Source: Dr. S.Smith, 2024
---
title: consensus-mechanism
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/consensus-mechanism
md: https://weboftrust.github.io/WOT-terms/04_glossary/consensus-mechanism.md
---
# consensus-mechanism
How groups of entitities come to decisions. In general to learn about consensus mechanisms read any textbook on decision making, automated reasoning, multi-objective decision making, operations research etc.
A fundamental problem in distributed computing and multi-agent systems is to achieve overall system reliability in the presence of a number of faulty processes. This often requires coordinating processes to reach consensus, or agree on some data value that is needed during computation.
More on [wikipedia](https://en.wikipedia.org/wiki/Consensus_\(computer_science\)) or in this [2018 report](https://cryptoresearch.report/crypto-research/consensus-mechanisms/) from the cryptocurrency field.
---
title: content-addressable-hash
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/content-addressable-hash
md: https://weboftrust.github.io/WOT-terms/04_glossary/content-addressable-hash.md
---
# content-addressable-hash
Finding content by a hash of this content, generated by a one-way hash function applied to the content.
Content addressing is a way to find data in a network using its content rather than its location. The way we do is by taking the content of the content and hashing it. Try uploading an image to IPFS and get the hash using the below button.
Content Addressable Storage systems work by passing the content of the file through a [cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) to generate a unique key, the "content address". The [file system](https://en.wikipedia.org/wiki/File_system)'s [directory](https://en.wikipedia.org/wiki/Directory_\(computing\)) stores these addresses and a pointer to the physical storage of the content. Because an attempt to store the same file will generate the same key, CAS systems ensure that the files within them are unique, and because changing the file will result in a new key, CAS systems _provide assurance that the file is unchanged_.
In the IPFS ecosystem, this hash is called Content Identifier, or CID.
---
title: contextual-linkability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/contextual-linkability
md: https://weboftrust.github.io/WOT-terms/04_glossary/contextual-linkability.md
---
# contextual-linkability
Refers to the condition where vendors or other data capture points provide enough context at point of capture to be able to use statistical correlation with existing data sets to link any of a person's disclosed attributes to a set of already known data points about a given person.
This sort of linkability nullifies the perceived protection of [selective disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md) through [zero knowledge proofs](https://weboftrust.github.io/WOT-terms/docs/glossary/zero-knowledge-proofs.md) since the disclosed data can be combined with context to easily link the disclosed data to an existing profile of the person.
These threats mainly focus on a subject (the entity) who wants to hide as much of his identifiable information (or at least make it as unlikable as possible). This can occur when the subject wants to authenticate himself to a certain service (multiple authentication principles are shown in the tree), but also during regular communication (browsing, client-server requests, etc.) by means of the contextual information connected or linked to the the activity or communication.
More at [source](https://www.linddun.org/linkability)
[Contractually protected disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/contractually-protected-disclosure.md) is the primary defense against contextual linkability.
Cameras in stores are already able to identify you due to the extremely high prevalence of modern security systems who do facial recognition or mobile device ping recognition on each person entering the premises of a store. In the context of you buying stuff in their store they can capture data linked to you and then go and sell your data to third parties since there is an implicit grant of permission to use the data and also since there are no legal constraints on the distribution of that data.
Just have a look at what "they" are doing:
[https://linkgraph.io/blog/how-to-contextual-link-building/](https://linkgraph.io/blog/how-to-contextual-link-building/)
---
title: contingent-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/contingent-disclosure
md: https://weboftrust.github.io/WOT-terms/04_glossary/contingent-disclosure.md
---
# contingent-disclosure
Contingent disclosure is a privacy-preserving mechanism where only specific information or attributes are disclosed under defined conditions. It enables the selective sharing of data such that only the required information is revealed to a relying party, without exposing other unrelated or sensitive details. [Chain link confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/chain-link-confidentiality.md) is a form of contingent disclosure.
| TBW prio 1 |
---
title: contractually-protected-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/contractually-protected-disclosure
md: https://weboftrust.github.io/WOT-terms/04_glossary/contractually-protected-disclosure.md
---
# contractually-protected-disclosure
a discloser of an ACDC that leverages a Graduated Disclosure so that contractual protections can be put into place to minimize the leakage of information that can be correlated. A Contractually Protected Disclosure partially or selectively reveals the information contained within the ACDC in the initial interaction with the recipient and discloses further information only after the recipient agrees to the terms established by the discloser. More information may be progressively revealed as the recipient agrees to additional terms.
Source: Dr. S. Smith
Usage of schema-based and contract-based controls to limit the exchange of information to provide both mechanical and legal protection on the sharing of data.
Mechanical protection is composed of sharing the schema of the data to be shared prior to sharing the actual data contents. This mechanical protection is then combined through the IPEX protocol with disclosures of legal contracts to be agreed to prior to sharing the desired data contents.
Once the legal agreements have been met then the disclosure mechanism exchanges the desired data contents.
This is also the most elaborate form of disclosure by an [IPEX](https://weboftrust.github.io/WOT-terms/docs/glossary/IPEX.md). Contractually protected disclosure includes both [chain-link confidential](https://weboftrust.github.io/WOT-terms/docs/glossary/chain-link-confidentiality.md) and [contingent disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/contingent-disclosure.md).
Paraphrased by @henkvancann based on [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#discussion)
This [IPEX](https://weboftrust.github.io/WOT-terms/docs/glossary/IPEX.md) protocol leverages important features of [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md)s and ancillary protocols such as [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md), [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md)s, and [CESR-Proofs](https://weboftrust.github.io/WOT-terms/docs/glossary/cesr-proof-signatures.md) as well as [Ricardian contract](https://weboftrust.github.io/WOT-terms/docs/glossary/ricardian-contract.md)s and graduated disclosure (partial, selective, full) to enable contractually protected disclosure. Contractually protected disclosure includes both \[chain-link confidential\](https://weboftrust.github.io/WOT-terms/04_glossary/chain-link confidential.md) and \[contingent disclosure\](https://weboftrust.github.io/WOT-terms/04_glossary/contingent disclosure.md).
The disclosure performed by a presentation exchange MAY be [graduated](https://weboftrust.github.io/WOT-terms/docs/glossary/graduated-disclosure.md) and MAY be [contractually](https://weboftrust.github.io/WOT-terms/docs/glossary/contractually-protected-disclosure.md) protected.
---
title: control-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/control-authority
md: https://weboftrust.github.io/WOT-terms/04_glossary/control-authority.md
---
# control-authority
In identity systems Control Authority is who controls what and that is the primary factor in determining the basis for trust in them. The entity with _control authority_ takes action through operations that affect the
- creation (inception)
- updating
- rotation
- revocation
- deletion
- and delegation of the **authentication factors and their relation to the identifier**.
How these events are ordered and their dependence on previous operations is important. The record of these operations is the source of truth for the identity system.
In the 2022 implementation of [KeriPy](https://weboftrust.github.io/WOT-terms/docs/glossary/keripy.md) two [rotations](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md) were required to _change_ control authority. In new rotation rules, you can rotate to new keys that aren't in the prior next key [digests](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md). You just need to reach the appropriate thresholds of _prior-next-threshold_ and _current-signing-threshold_. So you now only need one rotation to change control authority.
**Note**: This change was the forcing function to require [dual indexed codes](https://weboftrust.github.io/WOT-terms/docs/glossary/dual-indexed-codes.md) in CESR.
---
title: controller
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/controller
md: https://weboftrust.github.io/WOT-terms/04_glossary/controller.md
---
# controller
an entity that can cryptographically prove the control authority over an AID and make changes on the associated KEL. A controller of a multi-sig AID may consist of multiple controlling entities.
Source: Dr. S.Smith, 2024
A controller is a controlling entity (person, organization, or autonomous software) of an identifier. For an [autonomic identifier (AID)](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md), a controlling entity has the capability to make changes to the [key event log (KEL)](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of the AID. This capability is typically asserted by the control of a set of cryptographic keys used by software acting on behalf of the controller, though it might also be asserted via other mechanisms.
At any point in time, an identifier has at least one but may have more than one controlling entity. This set of controlling entities constitutes the controller. Without loss of generality, when the context is unambiguous, the term controller may refer either to the whole set or a member of the set of controlling entities.
All [key events](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event.md) on the identifier must include a signature from the sole controlling entity when there is only one controlling entity or at least one signature from one of the controlling entities when there is more than one. Typically, when there is more than one controlling entity, control is established via signatures from all or a subset of controlling entities. This is called [multi-signature (multi-sig)](https://weboftrust.github.io/WOT-terms/docs/glossary/multisig.md). In a threshold multi-sig scheme, the control authority is split among the controlling entities, where each is assigned a weight. In this case, the control authority over the identifier is established via signatures from a subset of controlling entities whose combined weights exceed an agreed threshold. These thresholded multiple signatures may be expressed as a single collective threshold signature when a collective signing scheme is used.
The control authority over an identifier can also be divided into signing authority and rotation authority. The controller of the identifier may grant their authority to other entities. For example, in [custodial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-rotation.md), the controller grants a designated custodial agent the signing authority while retaining their rotation authority. In the case of a [delegated identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/delegated-identifier.md), the delegated identifier is granted some degree of control authority from its delegating identifier.
---
title: cooperative-delegation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cooperative-delegation
md: https://weboftrust.github.io/WOT-terms/04_glossary/cooperative-delegation.md
---
# cooperative-delegation
The way KERI addresses the [security-cost-performance architecture trade-off](https://weboftrust.github.io/WOT-terms/docs/glossary/security-cost-performance-architecture-trade-off.md) is via [delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md) of identifier prefixes. Delegation includes a delegator and a delegate. For this reason we may call this a cooperative delegation. This is a somewhat **novel form of delegation**.
A major advantage of cooperative delegation is the delegator’s key management protects the delegate’s via recovery by the delegator. With cooperative delegation, any exploiter that compromises only the delegate’s authoritative keys may not capture control authority of the delegate. Any exploit of the delegate only is recoverable by the delegator.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: coroutines
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/coroutines
md: https://weboftrust.github.io/WOT-terms/04_glossary/coroutines.md
---
# coroutines
Computer programs that can be suspended and resumed at will.
Coroutines are [computer program](https://en.wikipedia.org/wiki/Computer_program) components that generalize [subroutines](https://en.wikipedia.org/wiki/Subroutine) for [non-preemptive multitasking](https://en.wikipedia.org/wiki/Non-preemptive_multitasking), by allowing execution to be suspended and resumed. Coroutines are well-suited for implementing familiar program components such as [cooperative tasks](https://en.wikipedia.org/wiki/Cooperative_multitasking), [exceptions](https://en.wikipedia.org/wiki/Exception_handling), [event loops](https://en.wikipedia.org/wiki/Event_loop), [iterators](https://en.wikipedia.org/wiki/Iterator), [infinite lists](https://en.wikipedia.org/wiki/Lazy_evaluation) and [pipes](https://en.wikipedia.org/wiki/Pipeline_\(software\)).
More on source [Wikipedia](https://en.wikipedia.org/wiki/Coroutine)
---
title: unpermissioned-correlation
description: a correlation established between two or more disclosed ACDCs whereby the discloser of the ACDCs does not permit the disclosee to establish such a correlation.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/correlation
md: https://weboftrust.github.io/WOT-terms/04_glossary/correlation.md
---
# unpermissioned-correlation
a correlation established between two or more disclosed ACDCs whereby the discloser of the ACDCs does not permit the disclosee to establish such a correlation.
Source: Dr. S. Smith
---
title: count-code
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/count-code
md: https://weboftrust.github.io/WOT-terms/04_glossary/count-code.md
---
# count-code
[Group framing code](https://weboftrust.github.io/WOT-terms/docs/glossary/group-framing-code.md)
---
title: vlei-role-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/credential
md: https://weboftrust.github.io/WOT-terms/04_glossary/credential.md
---
# vlei-role-credential
It is a [vLEI credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md) that attests to a role within a legal entity to an individual or an entity. It cryptographically proves that the individual or entity is authorized to act in that role on behalf of the legal entity.
---
title: CRUD
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/CRUD
md: https://weboftrust.github.io/WOT-terms/04_glossary/CRUD.md
---
# CRUD
Is acronym for the traditional _client-server_ database update policy is CRUD (**Create, Read, Update, Delete**).
CRUD as opposed to [RUN](https://weboftrust.github.io/WOT-terms/docs/glossary/RUN.md) which is the acronym for the new peer-to-peer end-verifiable monotonic update policy.
We [RUN off the CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/run-off-the-crud.md), which means that because the source of truth for each data item is a decentralized controller Peer, a given database hosted by any Peer does not create records in the traditional sense of a server creating records for a client.
---
title: crypto-libraries
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/crypto-libraries
md: https://weboftrust.github.io/WOT-terms/04_glossary/crypto-libraries.md
---
# crypto-libraries
Cryptography libraries deal with cryptography algorithms and have API function calls to each of the supported features.
Criteria to chose one or the other:
- Open Source (most of them are)
- Compliant with standards
- Key operations include key generation algorithms, key exchange agreements and public key cryptography standards.
- Supported cryptographic hash functions
- Implementations of message authentication code (MAC) algorithms
- Implementations of block ciphers
- Hardware-assisted support
- Code size and code to comment ratio
- Composable derivation codes
See a [comparison here](https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries) at Wikipedia.
---
title: cryptocurrency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cryptocurrency
md: https://weboftrust.github.io/WOT-terms/04_glossary/cryptocurrency.md
---
# cryptocurrency
A digital asset designed to work as a medium of exchange wherein individual coin ownership records are stored in a digital ledger or computerized database using strong cryptography to secure transaction record entries, to control the creation of additional digital coin records.
See [more](https://en.wikipedia.org/wiki/Cryptocurrency) on source Wikipedia.
KERI doesn't need total global ordering, whereas cryptocurrencies do need this. As a consequence has been designed, without the need of a consensus-based distributed ledger (blockchain).
KERI doesn't provide for a currency system, however a KERI-based system can be easily extended with a money - or token system.
See also Non Fungible Tokens.
---
title: cryptographic-commitment-scheme
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cryptographic-commitment-scheme
md: https://weboftrust.github.io/WOT-terms/04_glossary/cryptographic-commitment-scheme.md
---
# cryptographic-commitment-scheme
is a cryptographic primitive that allows one to commit to a chosen value (or chosen statement) while keeping it hidden to others, with the ability to reveal the committed value later.
Commitment schemes are designed so that a party cannot change the value or statement after they have committed to it: that is, commitment schemes are _binding_.
More on [wikipedia](https://en.wikipedia.org/wiki/Commitment_scheme)
---
title: cryptographic-primitive
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cryptographic-primitive
md: https://weboftrust.github.io/WOT-terms/04_glossary/cryptographic-primitive.md
---
# cryptographic-primitive
the serialization of a value associated with a cryptographic operation including but not limited to a digest (hash), a salt, a seed, a private key, a public key, or a signature.
Source: Dr. S.Smith, 2024
Cryptographic primitives are well-established, low-level [cryptographic](https://en.wikipedia.org/wiki/Cryptography) algorithms that are frequently used to build [cryptographic protocols](https://en.wikipedia.org/wiki/Cryptographic_protocol) for [computer security](https://en.wikipedia.org/wiki/Computer_security) systems. These routines include, but are not limited to, [one-way hash functions](https://en.wikipedia.org/wiki/One-way_hash_function) and [encryption functions](https://en.wikipedia.org/wiki/Cipher).
More on source [Wikipedia-page](https://en.wikipedia.org/wiki/Cryptographic_primitive)
In KERI and ACDC it a serialization of a unitary value associated with a cryptographic operation including but not limited to a digest (hash), a salt, a seed, a private key, a public key, or a signature. All primitives in KERI MUST be expressed in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md).
The more general term [primitive](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md).
---
title: cryptographic-strength
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cryptographic-strength
md: https://weboftrust.github.io/WOT-terms/04_glossary/cryptographic-strength.md
---
# cryptographic-strength
The term "cryptographically strong" is often used to describe an encryption algorithm, and implies, in comparison to some other algorithm (which is thus cryptographically weak), greater resistance to attack. But it can also be used to describe hashing and unique identifier and filename creation algorithms.
More on [Wikipedia](https://en.wikipedia.org/wiki/Strong_cryptography)
---
title: cryptonym
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/cryptonym
md: https://weboftrust.github.io/WOT-terms/04_glossary/cryptonym.md
---
# cryptonym
a cryptographic pseudonymous identifier represented by a string of characters derived from a random or pseudo-random secret seed or salt via a one-way cryptographic function with a sufficiently high degree of cryptographic strength (e.g., 128 bits, see appendix on [cryptographic strength](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptographic-strength.md). A cryptonym is a type of [primitive](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md).
Due to the [entropy](https://weboftrust.github.io/WOT-terms/docs/glossary/entropy.md) in its derivation, a cryptonym is a universally unique identifier, and only the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) of the secret [salt](https://weboftrust.github.io/WOT-terms/docs/glossary/salt.md) or [seed](https://weboftrust.github.io/WOT-terms/docs/glossary/seed.md) from which the cryptonym is derived may prove control over the cryptonym. Therefore, the derivation function MUST be associated with the cryptonym and may be encoded as part of the cryptonym itself.
Source [Smith, ietf-keri draft](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md)
A code name, call sign, or cryptonym is a [code word](https://en.wikipedia.org/wiki/Code_word_\(figure_of_speech\)) or name used, sometimes clandestinely, to refer to another name, word, project, or person.
Source [Wikipedia](https://en.wikipedia.org/wiki/Code_name)
---
title: CSPRNG
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/CSPRNG
md: https://weboftrust.github.io/WOT-terms/04_glossary/CSPRNG.md
---
# CSPRNG
means "Cryptographically Secure Pseudorandom Number Generator," which means that a sequence of numbers (bits, bytes...) that is produced from an algorithm that is deterministic (the sequence is generated from some unknown internal state), hence pseudorandom is also cryptographically secure, or not.
(Source: [https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng](https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng))
It is cryptographically secure if nobody can _reliably distinguish_ the output from true randomness, even if the PRNG algorithm is perfectly known (but not its internal state). A non-cryptographically secure PRNG would fool basic statistical tests but can be distinguished from true randomness by an intelligent attacker.
(Source: [https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng](https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng))
[PRNG](https://weboftrust.github.io/WOT-terms/docs/glossary/PRNG.md)
---
title: CT
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/CT
md: https://weboftrust.github.io/WOT-terms/04_glossary/CT.md
---
# CT
[Certificate transparency](https://weboftrust.github.io/WOT-terms/docs/glossary/certificate-transparency.md)
---
title: current-threshold
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/current-threshold
md: https://weboftrust.github.io/WOT-terms/04_glossary/current-threshold.md
---
# current-threshold
represents the number or fractional weights of signatures from the given set of current keys required to be attached to a [Message](https://trustoverip.github.io/tswg-keri-specification/#term:message) for the [Message](https://trustoverip.github.io/tswg-keri-specification/#term:message) to be considered fully signed.
Source: Dr. S.Smith, 2024
---
title: custodial-agent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/custodial-agent
md: https://weboftrust.github.io/WOT-terms/04_glossary/custodial-agent.md
---
# custodial-agent
An [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) owned by an individual who has granted [signing authority](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-authority.md) to a custodian who is usually also the host of the running agent software. Using [partial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md) to facilitate custodial key management the owner of the identifier retains [rotational authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md) and thus the ability to "fire" the custodian at any time without requiring the cooperation of the custodian.
Custodial Agents are important for individuals who may not be comfortable managing their own [signing keys](https://weboftrust.github.io/WOT-terms/docs/glossary/digital-signature.md) and agent software but still want to participate in a decentralized identity ecosystem and they enable a software as a service business model without centralizing control on the service provider.
(Source: Philip Feairheller)
Since ninety-nine percent of people in the world might not feel comfortable taking responsibility for their own practical [key management](https://weboftrust.github.io/WOT-terms/docs/glossary/key-management.md) but still want to be stay in control over their assets and be able to hire and fire service providers, this functionality is considered a key feature for KERI and ACDC.
---
title: custodial-rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/custodial-rotation
md: https://weboftrust.github.io/WOT-terms/04_glossary/custodial-rotation.md
---
# custodial-rotation
Rotation is based on control authority that is split between two key sets. The first for signing authority and the second (pre-rotated) for rotation authority, the associated thresholds and key list can be structured so that a designated custodial agent can hold signing authority, while the original controller can hold exclusive rotation authority.
[Partial pre-rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md) supports the vital use case of custodial key rotation to authorize a [custodial agent](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-agent.md).
Paraphrased by @henkvancann based on the [IETF-KERI draft 2022](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md) by Samual Smith.
---
title: DAG
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/DAG
md: https://weboftrust.github.io/WOT-terms/04_glossary/DAG.md
---
# DAG
[Directed acyclic graph](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md)
---
title: DAR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/DAR
md: https://weboftrust.github.io/WOT-terms/04_glossary/DAR.md
---
# DAR
[Designated Authorized Representatives](https://weboftrust.github.io/WOT-terms/docs/glossary/designated-authorized-representative.md)
---
title: data-anchor
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/data-anchor
md: https://weboftrust.github.io/WOT-terms/04_glossary/data-anchor.md
---
# data-anchor
Data anchors are [digests](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md) of digital data, that uniquely identify this data. The digest is the anchor and can be used to identify - and point to the data at the same time.
The act of creating the digest of arbitrary data and then hook (or reference) the digest to (in) another data structure is called 'anchoring data'.
[SADs](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-data.md) are a type of data anchors.
[Link anchors](https://en.wikipedia.org/wiki/Hyperlink#Anchor_links) are a totally different concepts.
---
title: Dead attack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/dead-attack
md: https://weboftrust.github.io/WOT-terms/04_glossary/dead-attack.md
---
# Dead attack
an attack on an [establishment event](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md) that occurs after the Key-state for that event has become stale because a later establishment event has rotated the sets of signing and pre-rotated keys to new sets.
Security Properties of [Pre-rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/Pre-rotation.md).
Source: Dr. S.Smith, 2024
---
title: dead-drop
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/dead-drop
md: https://weboftrust.github.io/WOT-terms/04_glossary/dead-drop.md
---
# dead-drop
In cybersecurity or digital privacy scenarios, the term "dead drop" refers to encrypted or secure virtual spaces where information can be deposited or retrieved anonymously. In the credentials field, the presenter controls the disclosure, so you can't re-identify the data.
Discussed in tech meet KERI [recording](https://hackmd.io/-soUScAqQEaSw5MJ71899w#2023-06-27), date June 27 2023.
---
title: decentralized-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/decentralized-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/decentralized-identifier.md
---
# decentralized-identifier
Decentralized identifiers (DID) are a new type of identifier that enables verifiable, decentralized digital identity. A _DID_ refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID.
[Source](https://www.w3.org/TR/did-core/) W3C.org.
In contrast to typical, federated identifiers, _DIDs_ have been designed so that they may be **decoupled from centralized registries**, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party.
[Source](https://www.w3.org/TR/did-core/) W3C.org.
_DIDs_ are _URIs_ that associate a _DID subject_ with a _DID document_ allowing trustable interactions associated with that subject.
[Source](https://www.w3.org/TR/did-core/) W3C.org.
---
title: decentralized-identity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/decentralized-identity
md: https://weboftrust.github.io/WOT-terms/04_glossary/decentralized-identity.md
---
# decentralized-identity
is a technology that uses cryptography to allow individuals to create and control their own unique identifiers. They can use these identifiers to obtain `Verifiable Credentials` from trusted organizations and, subsequently, present elements of these credentials as proof of claims about themselves. In this model, the individual takes ownership of their own identity and does not need to cede control to centralized service providers or companies.
[ToIP main glossary](https://glossary.trustoverip.org/#term:decentralized-identity)
`KERI`s definition of decentralization (centralization) is about _control_ not _spatial distribution_. In our definition _decentralized_ is not necessarily the same as _distributed_. By distributed we mean that activity happens at more than one site. Thus decentralization is about _control_ and distribution is about _place_. To elaborate, when we refer to decentralized infrastructure we mean infrastructure under decentralized (centralized) control no matter its spatial distribution. Thus _decentralized infrastructure_ is infrastructure sourced or controlled by more than one `entity`.
---
title: decentralized-key-management-infrastructure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/decentralized-key-management-infrastructure
md: https://weboftrust.github.io/WOT-terms/04_glossary/decentralized-key-management-infrastructure.md
---
# decentralized-key-management-infrastructure
a key management infrastructure that does not rely on a single entity for the integrity and security of the system as a whole. Trust in a DKMI is decentralized through the use of technologies that make it possible for geographically and politically disparate entities to reach an agreement on the key state of an identifier [DPKI](https://trustoverip.github.io/tswg-keri-specification/#term:dpki).
Source: Dr. S.Smith, 2024
Decentralized Public Key Infrastructure ([DPKI](https://ldapwiki.com/wiki/DPKI) or [Decentralized Key Management System](https://ldapwiki.com/wiki/Decentralized%20Key%20Management%20System) ([DKMS](https://ldapwiki.com/wiki/DKMS)) goal is to ensure that no single [third-party](https://ldapwiki.com/wiki/Third-party) can compromise the [integrity](https://ldapwiki.com/wiki/Integrity) and [security](https://ldapwiki.com/wiki/Security) of the system as as whole.
[Source](https://ldapwiki.com/wiki/Decentralized%20Public%20Key%20Infrastructure)
---
title: DEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/DEL
md: https://weboftrust.github.io/WOT-terms/04_glossary/DEL.md
---
# DEL
[Duplicitous event log](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicitous-event-log.md)
---
title: delegated-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/delegated-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/delegated-identifier.md
---
# delegated-identifier
Matches the act of [delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md) with the appropriate digital twin. Consequently when applied recursively, delegation may be used to compose arbitrarily complex trees of hierarchical (delegative) key management event streams. This is a most powerful capability that may provide an essential building block for a generic universal decentralized key management infrastructure (DKMI) that is also compatible with the demand of generic event streaming applications.
More in the [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
The KERI design approach is to build composable primitives instead of custom functionality that is so typical of other DKMI approaches:
- [transferable identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable-identifier.md)
- [non-transferable identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable-identifier.md)
- delegated identifiers
---
title: delegation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/delegation
md: https://weboftrust.github.io/WOT-terms/04_glossary/delegation.md
---
# delegation
A person or group of persons officially elected or appointed to represent another or others.
Delegation can be defined as “the act of empowering to act for another”. With this bestowed power, a person, usually a subordinate, is able to carry out specific activities (normally given by a manager or supervisor). Delegation is a management tool designed to increase the efficiency of an organization. It allows for the goals of the organization to be broken down into tasks and assigned to the team member best suited for the duty.
---
title: derivation-code
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/derivation-code
md: https://weboftrust.github.io/WOT-terms/04_glossary/derivation-code.md
---
# derivation-code
To properly extract and use the [public key](https://weboftrust.github.io/WOT-terms/docs/glossary/public-key-infrastructure.md) embedded in a [self-certifying identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-certifying-identifier.md) we need to know the cryptographic _signing scheme_ used by the [key pair](https://weboftrust.github.io/WOT-terms/docs/glossary/key-pair.md). KERI includes this very compactly in the identifier, by replacing the pad character (a character used to fill a void to able to always end up with a fixed length public key) with a special character that encodes the derivation process. We call this the _derivation code_.
> For example suppose that the 44 character Base-64 with trailing pad character for the public key is as follows: `F5pxRJP6THrUtlDdhh07hJEDKrJxkcR9m5u1xs33bhp=` If B is the value of the derivation code then the resultant self-contained string is as follows: `BF5pxRJP6THrUtlDdhh07hJEDKrJxkcR9m5u1xs33bhp`
All crypto material appears in `KERI` in a fully [qualified](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified.md) representation. This includes a derivation code prepended to the crypto-material. 
[Key derivation functions](https://en.wikipedia.org/wiki/Key_derivation_function) are not related to the pre-pended derivation codes used in KERI.
---
title: designated-aliases
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/designated-aliases
md: https://weboftrust.github.io/WOT-terms/04_glossary/designated-aliases.md
---
# designated-aliases
An AID controller can designate aliases which are AID controlled identifiers such as a did:keri, did:webs, etc. The [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) controller issues a designated aliases attestation (no issuee) that lists the identifiers and manages the status through a registry anchored to their KEL. See the [designated aliases docs](https://weboftrust.github.io/schema/desig-aliases)
---
title: designated-authorized-representative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/designated-authorized-representative
md: https://weboftrust.github.io/WOT-terms/04_glossary/designated-authorized-representative.md
---
# designated-authorized-representative
Also 'DAR'. These are representatives of a Legal Entity that are authorized by the Legal Entity to act officially on behalf of the Legal Entity. DARs can authorize:
1. vLEI Issuer Qualification Program Checklists
2. execute the vLEI Issuer Qualification Agreement
3. provide designate/replace Authorized vLEI Representatives ([AVR](https://weboftrust.github.io/WOT-terms/docs/glossary/authorized-vlei-representative.md)s).
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: DHT
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/DHT
md: https://weboftrust.github.io/WOT-terms/04_glossary/DHT.md
---
# DHT
[Distributed hash table](https://weboftrust.github.io/WOT-terms/docs/glossary/distributed-hash-table.md)
---
title: DID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/DID
md: https://weboftrust.github.io/WOT-terms/04_glossary/DID.md
---
# DID
[Decentralized Identifier](https://github.com/trustoverip/acdc/wiki/decentralized-identifier)
---
title: diger
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/diger
md: https://weboftrust.github.io/WOT-terms/04_glossary/diger.md
---
# diger
A _primitive_ that represents a [digest](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md). It has the ability to [verify](https://weboftrust.github.io/WOT-terms/docs/glossary/verify.md) that an input hashes to its raw value.
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: signed-digest
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/digest
md: https://weboftrust.github.io/WOT-terms/04_glossary/digest.md
---
# signed-digest
commitment to content, by digitally signing a digest of this content.
---
title: digital-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/digital-signature
md: https://weboftrust.github.io/WOT-terms/04_glossary/digital-signature.md
---
# digital-signature
A _digital_ signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A valid digital signature, where the prerequisites are satisfied, gives a recipient very strong reason to believe that the message was created by a known sender (authentication), and that the message was not altered in transit (integrity).
There are `digital signatures` and [Electronic signatures](https://weboftrust.github.io/WOT-terms/docs/glossary/electronic-signature.md), the latter are quite different in purpose and practical use.
---
title: dip
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/dip
md: https://weboftrust.github.io/WOT-terms/04_glossary/dip.md
---
# dip
dip = delcept, delegated inception
---
title: indirect-mode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/direct-mode
md: https://weboftrust.github.io/WOT-terms/04_glossary/direct-mode.md
---
# indirect-mode
Two primary trust modalities motivated the KERI design, One of these is the _indirect_ (one-to-many) mode, which depends on witnessed key event receipt logs (KERL) as a secondary root-of-trust for validating events. This gives rise to the acronym KERI for key event receipt infrastructure.
The indirect mode extends that trust basis with witnessed key event receipt logs ([KERL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md)) for validating events. The security and accountability guarantees of indirect mode are provided by [KA2CE](https://weboftrust.github.io/WOT-terms/docs/glossary/KA2CE.md) or KERI’s Agreement Algorithm for Control Establishment among a set of witnesses.
[Source: Abstract KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
To protect a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) when engaging with some other controller’s identifier, be it [verification](https://weboftrust.github.io/WOT-terms/docs/glossary/verification.md), control authority establishment, or [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection, are based on an ability to _replay_ the sequence of key events (key event history or log) of that identifier. There are two main operational modes for providing replay capability that are distinguished by the degree of availability of the identifier’s controller when creating and promulgating the key events.
With _indirect mode_, the promulgation of events to a validator may happen even when the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) is not attached to the network and therefore not able to communicate directly with a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md). Indirect mode supports high (nearly continuous) availability of the key event history to any validator. This means that other components must be trusted to promulgate key events when the controller is not attached to the network. Indirect mode is compatible with identifiers for one-to-many exchanges or any-wise relationships (a controller with any others). A single indirect mode identifier may be used for a public service or business or otherwise when building brand and reputation in that identifier is important. An indirect mode identifier may also be used for private one-to-one or select groups but where intermittent availability is not tolerable.
More in [Source: chapter Protocol Operational Modes in KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
The protocol may operate in two basic modes, called direct and indirect. The availability and consistency attack surfaces are different for the two modes and hence the mitigation properties of the protocol are likewise mode specific. [Source: chapter Security concerns in KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
[Direct mode](https://weboftrust.github.io/WOT-terms/docs/glossary/direct-mode.md)
---
title: directed-acyclic-graph
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/directed-acyclic-graph
md: https://weboftrust.github.io/WOT-terms/04_glossary/directed-acyclic-graph.md
---
# directed-acyclic-graph
From Wikipedia ([source](https://en.wikipedia.org/wiki/Directed_acyclic_graph)):
In [mathematics](https://en.wikipedia.org/wiki/Mathematics), particularly [graph theory](https://en.wikipedia.org/wiki/Graph_theory), and [computer science](https://en.wikipedia.org/wiki/Computer_science), a directed acyclic graph (DAG [/ˈdæɡ/](https://en.wikipedia.org/wiki/Help:IPA/English) ([listen](https://upload.wikimedia.org/wikipedia/commons/5/5a/En-us-DAG.ogg))) is a [directed graph](https://en.wikipedia.org/wiki/Directed_graph) with no [directed cycles](https://en.wikipedia.org/wiki/Cycle_graph#Directed_cycle_graph). That is, it consists of [vertices](https://en.wikipedia.org/wiki/Vertex_\(graph_theory\)) and [edges](https://en.wikipedia.org/wiki/Edge_\(graph_theory\)) (also called arcs), with each edge directed from one vertex to another.
Following directions in a DAG will never form a closed loop. Steps through a DAG are finite. That's the main reason to choose for a DAG.
From Wikipedia ([source](https://en.wikipedia.org/wiki/Directed_acyclic_graph)):
A directed graph is a DAG if and only if it can be [topologically ordered](https://en.wikipedia.org/wiki/Topological_ordering), by arranging the vertices as a linear ordering that is consistent with all edge directions.
From Wikipedia ([source](https://en.wikipedia.org/wiki/Directed_acyclic_graph)):
DAGs have numerous scientific and computational applications, ranging from biology (evolution, family trees, epidemiology) to information science (citation networks) to computation (scheduling).
---
title: disclosee
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/disclosee
md: https://weboftrust.github.io/WOT-terms/04_glossary/disclosee.md
---
# disclosee
a role of an entity that is a recipient to which an ACDC is disclosed. A Disclosee may or may not be the Issuee of the disclosed ACDC.
Source: Dr. S. Smith
---
title: discloser
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/discloser
md: https://weboftrust.github.io/WOT-terms/04_glossary/discloser.md
---
# discloser
a role of an entity that discloses an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md). A Discloser may or may not be the Issuer of the disclosed ACDC.
Source: Dr. S. Smith
---
title: percolated-information-discovery
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/discovery
md: https://weboftrust.github.io/WOT-terms/04_glossary/discovery.md
---
# percolated-information-discovery
In the [OOBI](https://weboftrust.github.io/WOT-terms/docs/glossary/OOBI.md) protocol, a discovery mechanism for the [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) and the [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) protocols is provided by a bootstrap that enables Percolated Information Discovery (PID), which is based on Invasion Percolation Theory.
After related information for discovery and verification is bootstrapped from the OOBI, subsequent authorization is non-interactive, thus making it highly scalable. This provides what we call zero-trust percolated discovery or speedy percolated discovery.
Percolation means that each discoverer, in turn, may share what it discovers with any subsequent discoverers. Since the information so discovered is end-verifiable, the percolation mechanism and percolating intermediaries do not need to be trusted.
[Percolation theory](https://en.wikipedia.org/wiki/Percolation_theory) is a mathematical framework used to study the behavior of connected clusters in random systems. It was originally developed to understand the flow of fluids through porous media, but it has since found applications in various fields, including physics, mathematics, computer science, and social sciences.
Invasion percolation is a specific variant of percolation theory that models the infiltration of a fluid into a porous medium. It is used to study how a fluid, such as a gas or liquid, spreads through a random network of interconnected sites or pores.
The invasion process follows the principle of least resistance, where the fluid seeks the path of least resistance through the porous medium. As the invasion progresses, the fluid selectively infiltrates the sites with lower resistance, forming a connected cluster of invaded sites. The invaded cluster grows by adding new invaded sites through the neighboring dry sites with the lowest resistance.
[Percolated discovery](https://weboftrust.github.io/WOT-terms/docs/glossary/percolated-discovery.md)
---
title: distributed-hash-table
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/distributed-hash-table
md: https://weboftrust.github.io/WOT-terms/04_glossary/distributed-hash-table.md
---
# distributed-hash-table
It is a distributed system that provides a lookup service similar to a hash table: key-value pairs are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key. The main advantage of a DHT is that nodes can be added or removed with minimum work around re-distributing keys.
Keys are unique identifiers which map to particular values, which in turn can be anything from addresses, to documents, to arbitrary data.
(Source: [Wikipedia](https://en.wikipedia.org/wiki/Distributed_hash_table))
---
title: DKMI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/DKMI
md: https://weboftrust.github.io/WOT-terms/04_glossary/DKMI.md
---
# DKMI
[Decentralized key management infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/decentralized-key-management-infrastructure.md)
---
title: dnd
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/dnd
md: https://weboftrust.github.io/WOT-terms/04_glossary/dnd.md
---
# dnd
Do Not Delegate is a flag/attribute for an AID, and this is default set to "you can delegate."
---
title: domain-name
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/domain-name
md: https://weboftrust.github.io/WOT-terms/04_glossary/domain-name.md
---
# domain-name
A domain name is a [string](https://en.wikipedia.org/wiki/String_\(computer_science\)) that identifies a realm of administrative autonomy, authority or control within the [Internet](https://en.wikipedia.org/wiki/Internet). Domain names are used in various networking contexts and for application-specific naming and addressing purposes.
More on [Source Wikipedia](https://en.wikipedia.org/wiki/Domain_name).
---
title: trust-domain
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/domain
md: https://weboftrust.github.io/WOT-terms/04_glossary/domain.md
---
# trust-domain
A trust domain is the ecosystem of interactions that rely on a trust basis. A trust basis binds controllers, identifiers, and key-pairs. _For example the Facebook ecosystem of social interactions is a trust domain that relies on Facebook’s identity system of usernames and passwords as its trust basis._
([Source whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf))
A trust domain is a domain that the system trusts to authenticate users. In other words, if a user or application is authenticated by a trusted domain, this authentication is accepted by all domains that trust the authenticating domain.
A more technical meaning of 'domain' is on the internet: [domain name](https://weboftrust.github.io/WOT-terms/docs/glossary/domain-name.md).
---
title: double-spend-proof
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/double-spend-proof
md: https://weboftrust.github.io/WOT-terms/04_glossary/double-spend-proof.md
---
# double-spend-proof
Total global ordering of transactions so that value can’t be spent twice at the same time from the unit of value. Or in everyday language: you can't spend your money twice.
The most important feature of a [cryptocurrency](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptocurrency.md) is that it must be double spend proof. Because KERI's key event operations are idempotent they do not need to be double spend proofed, so we can greatly simplify the distributed consensus algorithm in KERI. Which makes KERI relatively more attractive for many applications including IoT applications by comparison.
As a result of the relaxation of double spend proofing, KERI is able to break the distributed consensus algorithm into two halves and simplify it in the process. The two halves are the _promulgation_ half (by witnesses) and the _confirmation_ half (by valdators).
---
title: DPKI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/DPKI
md: https://weboftrust.github.io/WOT-terms/04_glossary/DPKI.md
---
# DPKI
[Decentralized key management infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/decentralized-key-management-infrastructure.md)
---
title: drt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/drt
md: https://weboftrust.github.io/WOT-terms/04_glossary/drt.md
---
# drt
drt = deltate, delegated rotation
---
title: dual-indexed-codes
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/dual-indexed-codes
md: https://weboftrust.github.io/WOT-terms/04_glossary/dual-indexed-codes.md
---
# dual-indexed-codes
a context-specific coding scheme, for the common use case of thresholded multi-signature schemes in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md).
One way to compactly associated each signature with its public key is to include in the text code for that signature the index into the ordered set of public keys. A popular signature raw binary size is 64 bytes which has a pad size of 2. This gives two code characters for a compact text code. The first character is the selector and type code. The second character is the Base64 encoded integer index.
More at source [Github Repo Ietf-CESR](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md)
---
title: dual-text-binary-encoding-format
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/dual-text-binary-encoding-format
md: https://weboftrust.github.io/WOT-terms/04_glossary/dual-text-binary-encoding-format.md
---
# dual-text-binary-encoding-format
An encoding format that allows for both text and binary encoding format, which is fully interchangeable. The [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) property enables the round trip conversion en-masse of concatenated primitives between the text domain and binary domain while maintaining the separability of individual primitives.
Read more in [source](https://github.com/trustoverip/tswg-cesr-specification/blob/main/draft-ssmith-cesr.md) of Samuel Smith
- [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md)
- [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md)
---
title: duplicitous-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/duplicitous-event-log
md: https://weboftrust.github.io/WOT-terms/04_glossary/duplicitous-event-log.md
---
# duplicitous-event-log
This is a record of inconsistent event messages produced by a given controller or witness with respect to a given [KERL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md). The duplicitous events are indexed to the corresponding event in a KERL.
A duplicitous event is represented by a set of two or more provably mutually [inconsistent](https://weboftrust.github.io/WOT-terms/docs/glossary/inconsistency.md) event messages with respect to a KERL. Each [juror](https://weboftrust.github.io/WOT-terms/docs/glossary/juror.md) keeps a duplicitous event log (DEL) for each [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) and all designated witnesses with respect to a KERL. Any [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) may confirm [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) by examining a DEL.
---
title: duplicity-detection
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/duplicity-detection
md: https://weboftrust.github.io/WOT-terms/04_glossary/duplicity-detection.md
---
# duplicity-detection
A mechanism to detect [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) in cryptographically secured event logs.
Duplicity detection, which protects, _not against an external attacker_, but against a malicious [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) does require access to [watchers](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) that are also recording duplicitous events.
---
title: threshold-of-accountable-duplicity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/duplicity
md: https://weboftrust.github.io/WOT-terms/04_glossary/duplicity.md
---
# threshold-of-accountable-duplicity
The threshold of accountable duplicity (TOAD) is a threshold number `M` that the controller declares to accept accountability for an event when any subset `M` of the `N` witnesses confirm that event. The threshold `M` indicates the minimum number of confirming witnesses the controller deems sufficient given some number `F` of potentially faulty witnesses, given that `M >= N - F`. This enables a controller to provide itself with any degree of protection it deems necessary given this accountability.
Note that what may be sufficient for a controller may not be sufficient for a validator. To clarify, let `MC` denote the threshold size of a sufficient agreement from the perspective of a controller and let `MV` denote the threshold size of a sufficient agreement from the perspective of a validator. Typically, `MV >= MC`.
A controller declares TOAD in its [key event log (KEL)](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) during the [key inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md) and may edit it during subsequent [key rotation events](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md).
A highly available system needs some degree of fault tolerance. The purpose of the threshold of accountability is to enable fault tolerance of the key event service with respect to faulty behavior by either the controller or witnesses. The principal controller fault exhibits duplicitous behavior in the use of its keys. In this case, the threshold serves as the threshold of accountable duplicity. The threshold lets a validator know when it may hold the controller accountable for duplicitous behavior. Without a threshold, a validator may choose to hold a controller accountable upon any evidence of duplicity which may make the service fragile in the presence of any degree of such faulty behavior. The primary way that a validator may hold a controller accountable is to stop trusting any use of the associated identifier. This destroys any value in the identifier and does not allow the controller to recover from an exploit. Recall that the one purpose of rotation keys (pre-rotated unexposed) is to enable recovery from compromised interaction signing keys. A compromised interaction signing key may exhibit duplicitous behavior on the part of the controller. A threshold of accountable duplicity enables a validator to distinguish between potentially recoverable duplicity such as the use of a compromised signing key and non-recoverable duplicity such as the use of a compromised rotation key. This better protects both the validator and the controller and improves the robustness of the service.
---
title: E2E
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/E2E
md: https://weboftrust.github.io/WOT-terms/04_glossary/E2E.md
---
# E2E
[End-to-end](https://weboftrust.github.io/WOT-terms/docs/glossary/end-to-end.md)
---
title: eclipse-attack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/eclipse-attack
md: https://weboftrust.github.io/WOT-terms/04_glossary/eclipse-attack.md
---
# eclipse-attack
An eclipse attack is a [P2P](https://weboftrust.github.io/WOT-terms/docs/glossary/peer-to-peer.md) network-based attack. Eclipse attack can only be performed on nodes that accept incoming connections from other nodes, and not all nodes accept incoming connections.
In a bitcoin network, by default, there are a maximum of 117 incoming TCP connections and 8 outgoing TCP connections.
[Source](https://www.geeksforgeeks.org/what-is-an-eclipse-attack/)
The only attack on KERI possible is an eclipse attack, so the larger your watcher network reach is the better your protection from this type of attack. The only limitation is a resource constraint.
[Source Samuel Smith / Phil Feairheller](https://hackmd.io/-soUScAqQEaSw5MJ71899w?view#2022-09-06)
Eclipse attacks are possible because nodes within the network are unable to connect with all other nodes and can connect with a limited number of neighboring nodes. This limitation might make it seem convenient for attackers to isolate a node from the rest of the network, but it is not an easy task.
More at [Source GeeksforGeeks](https://www.geeksforgeeks.org/what-is-an-eclipse-attack/)
---
title: ECR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ECR
md: https://weboftrust.github.io/WOT-terms/04_glossary/ECR.md
---
# ECR
[Engagement context role](https://weboftrust.github.io/WOT-terms/docs/glossary/engagement-context-role.md)
---
title: edge
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/edge
md: https://weboftrust.github.io/WOT-terms/04_glossary/edge.md
---
# edge
a top-level field map within an ACDC that provides edges that connect to other ACDCs, forming a labeled property graph (LPG).
Source: Dr. S. Smith
---
title: electronic-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/electronic-signature
md: https://weboftrust.github.io/WOT-terms/04_glossary/electronic-signature.md
---
# electronic-signature
An electronic signature, or e-signature, refers to data in electronic form, which is logically associated with other data in electronic form and which is used by the signatory to sign. This type of signature has the same legal standing as a handwritten signature as long as it adheres to the requirements of the specific regulation under which it was created (e.g., eIDAS in the European Union, NIST-DSS in the USA or ZertES in Switzerland).
_Electronic_ signatures are a legal concept _distinct_ from **[digital signatures](https://weboftrust.github.io/WOT-terms/docs/glossary/digital-signature.md), a cryptographic mechanism** often used to implement electronic signatures. While an electronic signature can be as simple as a name entered in an electronic document, digital signatures are increasingly used in e-commerce and in regulatory filings to implement electronic signatures in a cryptographically protected way.
---
title: encrypt-sender-sign-receiver
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/encrypt-sender-sign-receiver
md: https://weboftrust.github.io/WOT-terms/04_glossary/encrypt-sender-sign-receiver.md
---
# encrypt-sender-sign-receiver
An authenticated encryption approach, using [PKI](https://weboftrust.github.io/WOT-terms/docs/glossary/PKI.md). It covers [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) and [confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/confidentiality.md).
---
title: end-role
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/end-role
md: https://weboftrust.github.io/WOT-terms/04_glossary/end-role.md
---
# end-role
An end role is an authorization for one [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) to serve in a role for another [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md).
For example, declaring that your [Agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) is serving in the role of [Agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) for your business AIDs.
Source: Phil Feairheller
---
title: end-to-end
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/end-to-end
md: https://weboftrust.github.io/WOT-terms/04_glossary/end-to-end.md
---
# end-to-end
Inter-host communication and data flow transformations, considered in motion and at rest.
1. E2E Security. Inter-host communication must be end-to-end signed/encrypted and data must be stored signed/encrypted. Data is signed/encrypted in motion and at rest.
2. E2E Provenance. Data flow transformations must be end-to-end provenanced using verifiable data items (verifiable data chains or VCs). Every change shall be provenanced.
Paraphrased from source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: end-verifiability
description: a data item or statement may be cryptographically securely attributable to its source (party at the source end) by any recipient verifier (party at the destination end) without reliance on any infrastructure not under the verifier’s ultimate control.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/end-verifiability
md: https://weboftrust.github.io/WOT-terms/04_glossary/end-verifiability.md
---
# end-verifiability
a data item or statement may be cryptographically securely attributable to its source (party at the source end) by any recipient verifier (party at the destination end) without reliance on any infrastructure not under the verifier’s ultimate control.
Source: Dr. S.Smith, 2024
[End-verifiable](https://weboftrust.github.io/WOT-terms/docs/glossary/end-verifiable.md)
---
title: end-verifiable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/end-verifiable
md: https://weboftrust.github.io/WOT-terms/04_glossary/end-verifiable.md
---
# end-verifiable
When a log is _end verifiable_, it means that the log may be verified by any end user that receives a copy. No trust in intervening infrastructure is needed to verify the log and validate the content.
[End‐verifiability](https://weboftrust.github.io/WOT-terms/docs/glossary/end‐verifiability.md)
---
title: engagement-context-role
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/engagement-context-role
md: https://weboftrust.github.io/WOT-terms/04_glossary/engagement-context-role.md
---
# engagement-context-role
A person that represents the [Legal Entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md) in a functional or in another context role and is issued an ECR [vLEI Credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md).
On the basis of [Legal entity engagement context role vLEI credential governance framework](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md) an ECR [vLEI Credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md) is **issued to** an engagement context role (ECR).
---
title: Self-sovereign identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/entity
md: https://weboftrust.github.io/WOT-terms/04_glossary/entity.md
---
# Self-sovereign identifier
Self-sovereign identity is a decentralized identity architecture that implements the Principles of SSI — principally that it puts the identity controller (e.g., a natural person or organization) directly in control of the identifiers and credentials they use to assert their digital identity.
Source: ToIP main glossary
The definition started in the blog "[The Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)" by Christopher Allen in 2016. has not resulted in a consensus today. While some see the ten principles of SSI that Allen proposed as the definition of SSI, he formulated them as "a departure point to provoke a discussion about what's truly important". And it is obvious that what is important differs per [party](https://essif-lab.github.io/framework/docs/terms/party).
[Source eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/self-sovereign-identity)
---
title: entropy
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/entropy
md: https://weboftrust.github.io/WOT-terms/04_glossary/entropy.md
---
# entropy
Unpredictable information. Often used as a _secret_ or as input to a _key_ generation algorithm.
[Entropy](https://en.wikipedia.org/wiki/Entropy_\(information_theory\))
The term entropy is also used to describe the degree of unpredictability of a message. Entropy is then measured in bits. The degree or strength of randomness determines how difficult it would be for someone else to reproduce the same large random number. This is called _collision resistance_.
---
title: ephemeral
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ephemeral
md: https://weboftrust.github.io/WOT-terms/04_glossary/ephemeral.md
---
# ephemeral
Lasting for a markedly brief time. Having a short lifespan.
In the context of identifiers is often referred to as identifiers for one time use; or throw-away identifiers.
---
title: escrow-state
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/escrow-state
md: https://weboftrust.github.io/WOT-terms/04_glossary/escrow-state.md
---
# escrow-state
The current state of all the temporary storage locations (what events are waiting for what other information) that KERI protocol needs to keep track of, due to its fully asynchronous nature.
Since the KERI protocol is fully asynchronous, there is no way to guarantee that events will arrive in order to be processed successfully. This includes things like anchoring events for transaction event logs for credentials (the TEL even could arrive before the anchoring event) and signatures arriving on a multisig event.
To account for this asynchronous nature, implementations need to "escrow" events (store them temporarily) while waiting for other events or additional signatures to show up. The current state of all the temporary storage locations (what events are waiting for what other information) is called the "escrow state".
Source: Philip Feairheller
An physical [Escrow State](https://www.answers.com/Q/What_is_an_escrow_state) that you might know from Real Estate transaction is not at all related to the one we define.
---
title: escrow
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/escrow
md: https://weboftrust.github.io/WOT-terms/04_glossary/escrow.md
---
# escrow
'Escrow' **as a noun** is a (legal) arrangement in which a third party temporarily holds money or property until a particular condition has been met.
'Escrow' **as a verb**: we use it in protocol design to handle out of order events. Store the event and wait for the other stuff to show up and then continue processing of the event. So _escrowing_ is the process of storing this event. We root back to the event later.
---
title: ESSR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ESSR
md: https://weboftrust.github.io/WOT-terms/04_glossary/ESSR.md
---
# ESSR
[Encrypt‐Sender‐Sign‐Receiver](https://github.com/WebOfTrust/WOT-terms/wiki/encrypt-sender-sign-receiver)
---
title: non-establishment-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/establishment-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/establishment-event.md
---
# non-establishment-event
a Key event that does not change the current Key state for an AID. Typically, the purpose of a Non-establishment event is to anchor external data to a given Key state as established by the most recent prior Establishment event for an AID.
Source: Dr. S. Smith
A key event tieing or anchoring a data payload to the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of an identifier. This data payload includes a set of one or more [seals](https://weboftrust.github.io/WOT-terms/docs/glossary/seal.md) each of which anchor data to the key event.
The data payload event may be used to make verifiable, authoritative statements on behalf of the identifier controller.
These might include authorizations of encryption keys, communication routes, service endpoints, and so forth.
Transactions or workflows composed of non-establishment events are secured by virtue of being included in the verifiable key event sequence with the verifiable authoritative establishment events.
A non-establishment event is a key event that does not change the current key-state for an AID.
Source [KERI Whitepaper Section 7.22 page 46](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
A non-establishment event is a key event that does not change the current key-state for an [identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md). The event (only) ties or anchors digital data to the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of the identifier.
_(@henkvancann)_
---
title: exn
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/exn
md: https://weboftrust.github.io/WOT-terms/04_glossary/exn.md
---
# exn
exn = exchange
---
title: exp
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/exp
md: https://weboftrust.github.io/WOT-terms/04_glossary/exp.md
---
# exp
exp = expose, sealed data exposition
---
title: extensible-business-reporting-language
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/extensible-business-reporting-language
md: https://weboftrust.github.io/WOT-terms/04_glossary/extensible-business-reporting-language.md
---
# extensible-business-reporting-language
XBRL is the open international standard for digital business reporting, managed by a global not for profit consortium, XBRL International.
XBRL provides a language in which reporting terms can be authoritatively defined. Those terms can then be used to uniquely represent the contents of financial statements or other kinds of compliance, performance and business reports. XBRL lets reporting information move between organisations rapidly, accurately and digitally.
[Source](https://www.xbrl.org/the-standard/what/an-introduction-to-xbrl/)
XBRL stands for **eXtensible Business Reporting Language**. It is one of a family of “XML” languages which is becoming a standard means of communicating information between businesses and on the internet.
[Source](https://in.xbrl.org/about-us/what-is-xbrl/)
---
title: FFI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/FFI
md: https://weboftrust.github.io/WOT-terms/04_glossary/FFI.md
---
# FFI
[Foreign Function Interface](https://weboftrust.github.io/WOT-terms/docs/glossary/foreign-function-interface.md)
---
title: field-map
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/field-map
md: https://weboftrust.github.io/WOT-terms/04_glossary/field-map.md
---
# field-map
A traditional `key:value` pair renamed to avoid confusing with the cryptographic use of the term 'key'.
To avoid confusion with the cryptographic use of the term key we instead use the term field to refer to a mapping pair and the terms _field label_ and _field value_ for each member of a pair. These pairs can be represented by two tuples e.g (`label, value`). We qualify this terminology when necessary by using the term _field map_ to reference such a mapping.
Field maps may be nested where a given field value is itself a reference to another field map. We call this nested set of fields a nested field map or simply a nested map for short.
---
title: first-seen
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/first-seen
md: https://weboftrust.github.io/WOT-terms/04_glossary/first-seen.md
---
# first-seen
refers to the first instance of a [Message](https://weboftrust.github.io/WOT-terms/docs/glossary/message.md) received by any [Witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) or [Watcher](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md). The first-seen event is always seen, and can never be unseen. It forms the basis for [Duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection in KERI-based systems.
Source: Dr. S.Smith
A "First seen" event in KERI refers to the first event received by a validator, such as a witness. The event is valid and fits the available tail sequence number in the validator's KEL and, therefore, is accepted into the validator's KEL. This rule has no effect on the timing of what has arrived in escrow. For example, in escrow, there can be garbage. Assuming a watched set of validators agree on the first-seen events and thus also agree on the KELs, the watchers of those validators will propagate only those first-seen events within microseconds.
From the perspective of a validator, the rule is "First seen, always seen, never unseen."
Different validators might have a different _first-seen_ number for the same originating transaction event. In the case of duplicitous (inconsistent) interaction events originating from the controller (of the current signing key(s)), which might not be discovered until after a key rotation, a recovery process involving judges and jury may be triggered. More [here](https://trustoverip.github.io/tswg-keri-specification/#superseding-rules-for-recovery-at-a-given-location-sn-sequence-number). Validators will not provide an outdated KEL or Event once an erroneous KEL has been corrected.
---
title: foreign-function-interface
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/foreign-function-interface
md: https://weboftrust.github.io/WOT-terms/04_glossary/foreign-function-interface.md
---
# foreign-function-interface
Is a mechanism by which a program written in one, usually an [interpreted](https://en.wikipedia.org/wiki/Interpreted_\(programming_languages\)) (scripted), [programming language](https://en.wikipedia.org/wiki/Programming_language) that can call routines or make use of services written or compiled in another one.
More on Source: [https://en.wikipedia.org/wiki/Foreign\_function\_interface](https://en.wikipedia.org/wiki/Foreign_function_interface)
To have the output from RUST-based developed (e.g. cesride) consumed by higher level languages.
---
title: frame-code
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/frame-code
md: https://weboftrust.github.io/WOT-terms/04_glossary/frame-code.md
---
# frame-code
[Framing code](https://weboftrust.github.io/WOT-terms/docs/glossary/framing-code.md)
---
title: group-framing-code
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/framing-code
md: https://weboftrust.github.io/WOT-terms/04_glossary/framing-code.md
---
# group-framing-code
special Framing Codes that can be specified to support groups of Primitives which make them pipelinable. Self-framing grouping using Count Codes is one of the primary advantages of composable encoding.
Source: Dr. S. Smith
special framing codes can be specified to support groups of [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md) in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md). Grouping enables [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md). Other suitable terms for these special framing codes are _group codes_ or _count codes_ for short. These are suitable terms because these framing codes can be used to count characters, primitives in a group, or groups of primitives in a larger group when parsing and off-loading a stream of CESR primitives.
[Source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#count-group-or-framing-codes)
One of the primary advantages of composable encoding is that we can use special framing code to support the above mentioned grouping.
---
title: full-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/full-disclosure
md: https://weboftrust.github.io/WOT-terms/04_glossary/full-disclosure.md
---
# full-disclosure
a disclosure of an ACDC that discloses the full details of some or all of its field maps. In the context of [Selective Disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md), Full Disclosure means detailed disclosure of the selectively disclosed attributes, not the detailed disclosure of all selectively disclosable attributes. In the context of [Partial Disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-disclosure.md), Full Disclosure means detailed disclosure of the field map that was so far only partially disclosed.
Source: Dr. S. Smith
A disclosure of data in all its details.
When used in the context of [selective disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md), full disclosure means _detailed disclosure of the selectively disclosed attributes_ not detailed disclosure of all selectively disclosable attributes. Whereas when used in the context of [partial disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-disclosure.md), full disclosure means _detailed disclosure of the [field map](https://weboftrust.github.io/WOT-terms/docs/glossary/field-map.md)_ that was so far only partially disclosed.
---
title: fully-compact
description: definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/fully-compact
md: https://weboftrust.github.io/WOT-terms/04_glossary/fully-compact.md
---
# fully-compact
The most compact form of an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md). This is the only signed variant of an ACDC and this signature is anchored in a [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) (TEL) for the ACDC. This is one valid choice for an ACDC schema.
This form is part of the [graduated disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/graduated-disclosure.md) mechanism in ACDCs.
The extra a fully compact version has to offer over a [most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version is the anchoring to the [Tranaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md). Here were various proofs ([hashes](https://weboftrust.github.io/WOT-terms/docs/glossary/distributed-hash-table.md)) can be "stored" which are optional in all kind of [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) variants.
[Fully (expanded)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-expanded.md) version of an ACDC
[Most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version of an ACDC.
A fully compact ACDC is like the core of an onion and the fully expanded ACDC is like rest of the outer layers of the onion. Turn this onion inside-out: you only need to sign the core (most compact), and then the whole onion (expanded version) would verify. The complete (expanded) onion is the most user friendly information bulb you can get, and you don't need to peel off all the rings of the onion to securely attribute _all_ the information to the controller of the [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md) that signed the core.
You can present any version of the onion you like: only the core, one partially stripped back, one layer at a time, or the whole thing (fully expanded). This illustrates part of the rational for why ACDCs matter. They offer a layered, graduated disclosure mechanism of verifiable credentials never seen before in the SSI field.
---
title: fully-expanded
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/fully-expanded
md: https://weboftrust.github.io/WOT-terms/04_glossary/fully-expanded.md
---
# fully-expanded
The most user-friendly version of an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) credential. It doesn't need to be signed and typically is not signed since the most compact version which is signed can be computed from this form and then the signature can be looked up in the [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/TEL.md) of the ACDC in question.
Regarding the graduated disclosure objective this form is the one with the highest amount of disclosure for a given node of an ACDC graph.
[Fully compact(ed)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-compact.md) version of an ACDC
[Most compact](https://weboftrust.github.io/WOT-terms/docs/glossary/most-compact.md) version of an ACDC.
---
title: GAR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/GAR
md: https://weboftrust.github.io/WOT-terms/04_glossary/GAR.md
---
# GAR
[GLEIF authorized representative](https://weboftrust.github.io/WOT-terms/docs/glossary/gleif-authorized-representative.md)
---
title: ghost-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ghost-credential
md: https://weboftrust.github.io/WOT-terms/04_glossary/ghost-credential.md
---
# ghost-credential
Is a valid credential within in a 90 days grace period (the revocation transaction time frame before it's booked to revocation registry).
When a relationship needs to be terminated with a [QVI](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md) and the QVI has not revoked their credentials (yet) then those credentials become ghost credentials.
| TBW prio 3 |
---
title: gleif-authorized-representative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/gleif-authorized-representative
md: https://weboftrust.github.io/WOT-terms/04_glossary/gleif-authorized-representative.md
---
# gleif-authorized-representative
A representative of GLEIF authorized to perform the identity verifications requirements needed to issue the [QVI](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md) [vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) Credential.
Source: [GLEIF Ecosystem Governance Framework v1.0 Glossary](https://www.gleif.org/media/pages/vlei/introducing-the-vlei-ecosystem-governance-framework/0349aa74c5-1678443743/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-glossary_v1.0_final.pdf)
---
title: GLEIF
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/GLEIF
md: https://weboftrust.github.io/WOT-terms/04_glossary/GLEIF.md
---
# GLEIF
Global Legal Entity Identifier Foundation
[https://www.gleif.org/en](https://www.gleif.org/en)
---
title: GLEIS
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/GLEIS
md: https://weboftrust.github.io/WOT-terms/04_glossary/GLEIS.md
---
# GLEIS
Global Legal Entity Identifier System
---
title: gnu-privacy-guard
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/gnu-privacy-guard
md: https://weboftrust.github.io/WOT-terms/04_glossary/gnu-privacy-guard.md
---
# gnu-privacy-guard
also GnuPG; is a free-software replacement for Symantec's PGP cryptographic software suite. It is compliant with RFC 4880, the IETF standards-track specification of OpenPGP. Modern versions of PGP are interoperable with GnuPG and other OpenPGP-compliant systems.
More on [wikipedia](https://en.wikipedia.org/wiki/GNU_Privacy_Guard)
See more about the closely related and often-confusing term [PGP](https://weboftrust.github.io/WOT-terms/docs/glossary/PGP.md).
---
title: vlei-ecosystem-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/governance-framework
md: https://weboftrust.github.io/WOT-terms/04_glossary/governance-framework.md
---
# vlei-ecosystem-governance-framework
The Verifiable LEI (vLEI) Ecosystem [Governance Framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md) Information Trust Policies. It's a **document** that defines the information security, privacy, availability, confidentiality and processing integrity policies that apply to all vLEI Ecosystem Members.
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: GPG
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/GPG
md: https://weboftrust.github.io/WOT-terms/04_glossary/GPG.md
---
# GPG
[Gnu privacy guard](https://weboftrust.github.io/WOT-terms/docs/glossary/gnu-privacy-guard.md)
---
title: graduated-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/graduated-disclosure
md: https://weboftrust.github.io/WOT-terms/04_glossary/graduated-disclosure.md
---
# graduated-disclosure
a disclosure of an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) that does not reveal its entire content in the initial interaction with the recipient and, instead, partially or selectively reveals only the information contained within the ACDC necessary to further a transaction with the recipient. A Graduated disclosure may involve multiple steps where more information is progressively revealed as the recipient satisfies the conditions set by the [discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md). [Compact disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/compact-disclosure.md), [Partial disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-disclosure.md), [Selective disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md), and [Full disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/full-disclosure.md) are all Graduated disclosure mechanisms.
Source: Dr. S. Smith
Lifting confidentiality step by step: Selectively disclosing more data as time and/or necessity progresses, offering backward verifiability of earlier issued cryptographic proofs.
You proof your insurance policy without disclosing details before enjoying extreme sports. Only when something goes wrong, e.g., 1 in 100, do you disclose the data. This way confidentiality is kept in 99% of the cases.
Disclosure performed by a presentation exchange that has cross-variant (see [compact variant](https://weboftrust.github.io/WOT-terms/docs/glossary/compact-variant.md)) Issuer commitment verifiability as an essential property. It supports graduated disclosure by the [Disclosee](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md) of any or all variants wether it be full, compact, metadata, partial, selective, bulk issued, or contractually protected.
Paraphrased by @henkvancann based on [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#discussion)
The [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md) of a given variant is useful even when it is not the SAID of the variant the [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) signed because during graduated disclosure the [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) MAY choose to sign that given variant to fulfil a given step in an IPEX graduated disclosure transaction.
The disclosure performed by a presentation exchange MAY be [graduated](https://weboftrust.github.io/WOT-terms/docs/glossary/graduated-disclosure.md) and MAY be [contractually](https://weboftrust.github.io/WOT-terms/docs/glossary/contractually-protected-disclosure.md) protected.
- [Partial Disclosure](https://github.com/trustoverip/acdc/wiki/partial-disclosure)
- [Selective Disclosure](https://github.com/trustoverip/acdc/wiki/selective-disclosure)
- [Full Disclosure](https://github.com/trustoverip/acdc/wiki/full-disclosure)
| TBW | check prio 1
---
title: graph-fragment
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/graph-fragment
md: https://weboftrust.github.io/WOT-terms/04_glossary/graph-fragment.md
---
# graph-fragment
An ACDC is a verifiable data structure and _part of a graph_, consisting of a node property and one or two edge proporties.
---
title: group-code
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/group-code
md: https://weboftrust.github.io/WOT-terms/04_glossary/group-code.md
---
# group-code
[Group framing code](https://weboftrust.github.io/WOT-terms/docs/glossary/group-framing-code.md)
---
title: group-framing-code
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/group-framing-code
md: https://weboftrust.github.io/WOT-terms/04_glossary/group-framing-code.md
---
# group-framing-code
special Framing Codes that can be specified to support groups of Primitives which make them pipelinable. Self-framing grouping using Count Codes is one of the primary advantages of composable encoding.
Source: Dr. S. Smith
special framing codes can be specified to support groups of [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md) in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md). Grouping enables [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md). Other suitable terms for these special framing codes are _group codes_ or _count codes_ for short. These are suitable terms because these framing codes can be used to count characters, primitives in a group, or groups of primitives in a larger group when parsing and off-loading a stream of CESR primitives.
[Source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#count-group-or-framing-codes)
One of the primary advantages of composable encoding is that we can use special framing code to support the above mentioned grouping.
---
title: hab
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/hab
md: https://weboftrust.github.io/WOT-terms/04_glossary/hab.md
---
# hab
A Hab is a keystore for one identifier. The Python implementation in [KERIpy](https://weboftrust.github.io/WOT-terms/docs/glossary/keripy.md), also used by [KERIA](https://weboftrust.github.io/WOT-terms/docs/glossary/keria.md) uses [LMDB](http://www.lmdb.tech/doc/) to store key material and all other data.
Many Habs are included within and managed by a [Habery](https://weboftrust.github.io/WOT-terms/docs/glossary/habery.md).
---
title: habery
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/habery
md: https://weboftrust.github.io/WOT-terms/04_glossary/habery.md
---
# habery
'Hab' comes from ‘Habitat’. It’s a place where multi-sigs and AIDs are linked. Habery manages a collection of [Habs](https://weboftrust.github.io/WOT-terms/docs/glossary/hab.md). A Hab is a data structure (a Python object).
The only hit (2022) in a Google search pointing to a github site 'habery DOT github DOT io' is NOT related.
| TBW |-prio2
---
title: hardware-security-module
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/hardware-security-module
md: https://weboftrust.github.io/WOT-terms/04_glossary/hardware-security-module.md
---
# hardware-security-module
A HSM is a physical computing device that safeguards and manages secrets (most importantly [digital keys](https://en.wikipedia.org/wiki/Digital_keys)), performs [encryption](https://en.wikipedia.org/wiki/Encryption) and decryption functions for [digital signatures](https://en.wikipedia.org/wiki/Digital_signature), strong [authentication](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) and other cryptographic functions.
More in source [Wikipedia](https://en.wikipedia.org/wiki/Hardware_security_module)
---
title: hierarchical-asynchronous-coroutines-and-input-output
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/hierarchical-asynchronous-coroutines-and-input-output
md: https://weboftrust.github.io/WOT-terms/04_glossary/hierarchical-asynchronous-coroutines-and-input-output.md
---
# hierarchical-asynchronous-coroutines-and-input-output
HIO is an acronym which stands for 'Weightless hierarchical asynchronous coroutines and I/O in Python'.
It's Rich Flow Based Programming Hierarchical Structured Concurrency with Asynchronous IO. That mouthful of terms has been explained further on [Github](https://github.com/ioflo/hio).
HIO builds on very early work on hierarchical structured concurrency with lifecycle contexts from [ioflo](https://ioflo.com/), [ioflo github](https://github.com/ioflo/ioflo), and [ioflo manuals](https://github.com/ioflo/ioflo_manuals).
[Repo ioflo hio](https://github.com/ioflo/hio)
---
title: hierarchical-composition
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/hierarchical-composition
md: https://weboftrust.github.io/WOT-terms/04_glossary/hierarchical-composition.md
---
# hierarchical-composition
Encoding protocol that is composable in a hierarchy and enables [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md) (multiplexing and de-multiplexing) of complex streams in either text or compact binary. This allows management at scale for high-bandwidth applications.
| TBW prio2 |
Because of [count codes](https://weboftrust.github.io/WOT-terms/docs/glossary/count-code.md) and the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) - and [concatenation](https://weboftrust.github.io/WOT-terms/docs/glossary/concatenation.md) property in CESR, [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md) is possible, which then uses [multiplexing](https://weboftrust.github.io/WOT-terms/docs/glossary/multiplexing.md) (combining [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) primitives) and _de-multiplexing_ (unravelling self-framing [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md)).
---
title: hierchical-deterministic-keys
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/hierchical-deterministic-keys
md: https://weboftrust.github.io/WOT-terms/04_glossary/hierchical-deterministic-keys.md
---
# hierchical-deterministic-keys
An HDK type is a deterministic Bitcoin wallet derived from a known [seed](https://weboftrust.github.io/WOT-terms/docs/glossary/seed.md) that allows child keys to be created from the parent key. Because the child key is generated from a known seed, a relationship between the child and parent keys is invisible to anyone without that seed.
The HD protocol (BIP 32) can generate a near-infinite number of child keys from a deterministically generated seed (chain code) from its parent, allowing you to recreate those exact same child keys as long as you have the seed.
More at [W3 source](https://www.w3.org/2016/04/blockchain-workshop/interest/robles.html)
---
title: hio
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/hio
md: https://weboftrust.github.io/WOT-terms/04_glossary/hio.md
---
# hio
Weightless hierarchical asynchronous coroutines and I/O in Python.
Rich Flow Based Programming Hierarchical Structured Concurrency with Asynchronous IO.
This very technical topic can best be studied further at the Github [Repository](https://github.com/ioflo/hio)
Choosing HIO complies with the asynchronous nature of KERI, the minimal sufficient means design principle of KERI and the leading KERIpy implementation.
---
title: Home
description: Welcome to the WebofTrust terms wiki!
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/Home
md: https://weboftrust.github.io/WOT-terms/04_glossary/Home.md
---
# Home
The wiki also serves the glossary terms for the underlying and related techniques to ACDC, like KERI, CESR and OOBI.
There are a few [practical rules](https://wiki.trustoverip.org/display/HOME/Terms+Wikis) from the originator ToIP to get these wiki terms through their equivalent [github actions script](https://github.com/WebOfTrust/WOT-terms/actions/workflows/content-fetch-and-deploy-update-glossary.yml), please:
1. beware all new wiki items you **create**, lead to new .md files. We'd like to know
2. introduce lowercase names with spaces (they will convert into lower case names with dashes between the words)
3. start with **\## Definition** header; [example](https://github.com/WebOfTrust/WOT-terms/wiki/composable-event-streaming-representation)
4. start with uppercase abbreviations with only the "**\## See**" header; [example](https://github.com/WebOfTrust/WOT-terms/wiki/CESR)
5. don't **delete** items (i.e. .md files) but make clear they are depreciated and / or link to the new concept / term
6. don't change or **update** the name of an item single handed, for it might change the concept / meaning for other people and create dead links for those who **read** - or link to the term. Please open an issue or a PR to discuss first.
7. any other immediate updates and amendments welcome, the revisions are available for us to be able to (partially) revert if something unwanted or unexpected happens.
The _weboftrust_ wiki glossary is currently our input tool for our KERI Suite glossary. However, we regularly scrape the wiki into [KERISSE](http://kerisse.org), we add features and metadata, we connect relevant matching terms from related glossaries and finally we index it for the KERI Suite Search Engine (KERISSE).
_Have fun CRU-ing!_
'\* CRU=Create Read Update
---
title: HSM
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/HSM
md: https://weboftrust.github.io/WOT-terms/04_glossary/HSM.md
---
# HSM
[Hardware security model](https://weboftrust.github.io/WOT-terms/docs/glossary/hardware-security-module.md)
---
title: I-O
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/I-O
md: https://weboftrust.github.io/WOT-terms/04_glossary/I-O.md
---
# I-O
[Input output](https://weboftrust.github.io/WOT-terms/docs/glossary/input-output.md)
---
title: IANA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/IANA
md: https://weboftrust.github.io/WOT-terms/04_glossary/IANA.md
---
# IANA
[Internet assigned numbers authority](https://weboftrust.github.io/WOT-terms/docs/glossary/internet-assigned-numbers-authority.md)
---
title: icp
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/icp
md: https://weboftrust.github.io/WOT-terms/04_glossary/icp.md
---
# icp
icp = incept, inception
---
title: identifier-system
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/identifier-system
md: https://weboftrust.github.io/WOT-terms/04_glossary/identifier-system.md
---
# identifier-system
a system for uniquely identifying (public) identities
The International Standard Name Identifier (ISNI) is an identifier system for uniquely identifying the public identities of contributors to media content such as books, television programmes, and newspaper articles. Such an identifier consists of 16 digits. It can optionally be displayed as divided into four blocks. More info on [Wikipedia page](https://en.wikipedia.org/wiki/International_Standard_Name_Identifier)
1. Completeness. Every unique object must be assigned an identifier.
2. Uniqueness. Each identifier is a unique sequence.
3. Exclusivity. Each identifier is assigned to a unique object, and to no other object.
4. Authenticity. The objects that receive identification must be verified as the objects that they are intended to be.
5. Aggregation. There must be a mechanism to aggregate all of the data, and only that data, that is properly associated with the identifier (i.e., to bundle all of the data that belong to the uniquely identified object).
6. Permanence. The identifiers and the associated data must be permanent.
7. Reconciliation. There should be a mechanism whereby the data associated with a unique, identified object in one resource can be merged with the data held in another resource, for the same unique object. This process, which requires comparison, authentication, and merging, is known as reconciliation.
8. Immutability. In addition to being permanent (i.e., never destroyed or lost), the identifier must never change (
9. Security. The identifier system should be as little vulnerable to malicious attack as possible.
10. Documentation and quality assurance. Protocols must be written for establishing the identifier system, for assigning identifiers, for protecting the system, and for monitoring the system.
11. Centrality. The subject's identifier is the central "key" to which every event for the subject is attached.
12. Autonomy. An identifier system has a life of its own.
By (_@henkvancann_) based on this [source](https://www.sciencedirect.com/topics/computer-science/identifier-system)
KERI is an thin-layered identifier system generator, offering globally portable identifiers, secure attribution to their root-of-trust, and chained verifiable credential containers (ACDC) to them.
Verifiable Credentials (VCs) and the emerging role of the LEI: Verifiable Credentials are digitally signed credentials that are not only tamper-resistant but capable of being verified in decentralized manner. vLEIs are based on the Trust over IP Authentic Chained Data Container (ACDC) specification (based on the Key Event Receipt Infrastructure (KERI) protocol ([github.com/WebOfTrust/keri](http://github.com/WebOfTrust/keri)), both Internet Engineering Task Force (IETF) draft specifications). Verifiable Credentials are digitally signed credentials that are not only tamper-resistant but capable of being verified in decentralized manner. vLEIs are based on the Trust over IP Authentic Chained Data Container (ACDC) specification (based on the Key Event Receipt Infrastructure (KERI) protocol ([github.com/WebOfTrust/keri](http://github.com/WebOfTrust/keri)), both Internet Engineering Task Force (IETF) draft specifications). More info on [GLEIF site](https://www.gleif.org/en/vlei/introducing-the-verifiable-lei-vlei)
---
title: verifiable-legal-entity-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/identifier.md
---
# verifiable-legal-entity-identifier
Verifiable credentials are issued by authorized validation agents ([QVIs](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md)) under the governance of [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md), who delegate tasks to these agents. They provide cryptographic proof that the information about a legal entity, as linked to its Legal Entity Identifier (LEI), is verifiably authentic, accurate, and up-to-date.
The v in vLEI stands for “verifiable”, but what does that mean? In this case, "verifiable" comes from “Verifiable Credential”. A verifiable credential is just a collection of information with a mechanism that allows a computer to verify that the information has not been modified and that the information was originally stated to be correct by some third party (maybe a bank or the driving license authority). Often (almost always really), the information will include a link to the entity the information is about.
[Here](https://rapidlei.com/what-is-vlei/) at Rapidlei.
---
title: identity-assurance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/identity-assurance
md: https://weboftrust.github.io/WOT-terms/04_glossary/identity-assurance.md
---
# identity-assurance
The heavy-lifting to be done by a trusted (middle-man) party to establish - and then offer reputational trust. An example of such a party is [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md). Instead, KERI is for [attributional trust](https://weboftrust.github.io/WOT-terms/docs/glossary/attributional-trust.md). In the real world you need both.
Read more in source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf)
A trusted party might use out-of-band procedures to assure the identity of people (representing parties) but it's not the same as [Out-of-band Introduction](https://weboftrust.github.io/WOT-terms/docs/glossary/out-of-band-introduction.md)s (OOBIs) to establish attributional trust, which is done with KERI.
---
title: Self-sovereign identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/identity
md: https://weboftrust.github.io/WOT-terms/04_glossary/identity.md
---
# Self-sovereign identifier
Self-sovereign identity is a decentralized identity architecture that implements the Principles of SSI — principally that it puts the identity controller (e.g., a natural person or organization) directly in control of the identifiers and credentials they use to assert their digital identity.
Source: ToIP main glossary
The definition started in the blog "[The Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)" by Christopher Allen in 2016. has not resulted in a consensus today. While some see the ten principles of SSI that Allen proposed as the definition of SSI, he formulated them as "a departure point to provoke a discussion about what's truly important". And it is obvious that what is important differs per [party](https://essif-lab.github.io/framework/docs/terms/party).
[Source eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/self-sovereign-identity)
---
title: inception-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/inception-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/inception-event.md
---
# inception-event
an [Establishment Event](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md) that provides the incepting information needed to derive an AID and establish its initial Key state.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
An inception event is an establishment key event that represents the creation operation of an identifier, including its derivation and its initial set of controlling keys as well as other inception or configuration data for supporting infrastructure.
This is the information needed to derive an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) and establish its initial key-state.
There may be one and only one inception event operation performed on an identifier.
Source [KERI Whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
**In brief: It's the signed version of a statement containing the inception event with some extra data.**
(_@henkvancann_)
The inception data must include the public key, the identifier derivation from that public key, and may include other configuration data. The identifier derivation may be simply represented by the `derivation code`. A statement that includes the inception data with attached signature made with the private key comprises a cryptographic commitment to the derivation and configuration of the identifier that may be cryptographically verified by any entity that receives it.
A KERI inception statement is completely self-contained. No additional infrastructure is needed or more importantly must be trusted in order to verify the derivation and initial configuration (inception) of the identifier. The initial trust basis for the identifier is simply the signed inception statement.
(_SamMSmith_)
---
title: inception
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/inception
md: https://weboftrust.github.io/WOT-terms/04_glossary/inception.md
---
# inception
The operation of creating an AID by binding it to the initial set of authoritative keypairs and any other associated information. This operation is made verifiable and duplicity evident upon acceptance as the inception event that begins the AID's KEL.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: internal-inconsistency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/inconsistency
md: https://weboftrust.github.io/WOT-terms/04_glossary/inconsistency.md
---
# internal-inconsistency
Internal is used to describe things that exist or happen inside an [entity](https://weboftrust.github.io/WOT-terms/docs/glossary/entity.md). In our scope of digital [identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md) its (in)consistency is considered within the defining data structures and related data stores.
In [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md), you are protected against internal inconsistency by the hash chain data structure of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) because the only [authority](https://weboftrust.github.io/WOT-terms/docs/glossary/authority.md) that can sign the log is the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) itself.
---
title: indexed-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/indexed-signature
md: https://weboftrust.github.io/WOT-terms/04_glossary/indexed-signature.md
---
# indexed-signature
Also called _siger_. An indexed signature attachment is used when signing anything with a multi-key autonomic identifier. The index is included as part of the attachment, so a verifier knows which of the multiple public keys was used to generate a specific signature.
Source:Philip Feairheller
An indexed signature attachment would look something like:
```
03.
```
All encoded as [qualified](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified.md) [base64](https://weboftrust.github.io/WOT-terms/docs/glossary/base64.md). A verifier would then know to use the AID’s public key located at index 3 in the list of public keys to verify the signature.
Source:Philip Feairheller
In addition, [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) signatures can also be attached as indexed signatures. So a verifier can determine which witness signed a particular [receipt](https://weboftrust.github.io/WOT-terms/docs/glossary/receipt.md). This is useful when witnesses are receipting an event and only attaching their own signature. The [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) knows which witness signed the receipt by looking up the index in their list of witnesses for that event.
Source:Philip Feairheller
---
title: indirect-mode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/indirect-mode
md: https://weboftrust.github.io/WOT-terms/04_glossary/indirect-mode.md
---
# indirect-mode
Two primary trust modalities motivated the KERI design, One of these is the _indirect_ (one-to-many) mode, which depends on witnessed key event receipt logs (KERL) as a secondary root-of-trust for validating events. This gives rise to the acronym KERI for key event receipt infrastructure.
The indirect mode extends that trust basis with witnessed key event receipt logs ([KERL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md)) for validating events. The security and accountability guarantees of indirect mode are provided by [KA2CE](https://weboftrust.github.io/WOT-terms/docs/glossary/KA2CE.md) or KERI’s Agreement Algorithm for Control Establishment among a set of witnesses.
[Source: Abstract KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
To protect a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) when engaging with some other controller’s identifier, be it [verification](https://weboftrust.github.io/WOT-terms/docs/glossary/verification.md), control authority establishment, or [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection, are based on an ability to _replay_ the sequence of key events (key event history or log) of that identifier. There are two main operational modes for providing replay capability that are distinguished by the degree of availability of the identifier’s controller when creating and promulgating the key events.
With _indirect mode_, the promulgation of events to a validator may happen even when the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) is not attached to the network and therefore not able to communicate directly with a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md). Indirect mode supports high (nearly continuous) availability of the key event history to any validator. This means that other components must be trusted to promulgate key events when the controller is not attached to the network. Indirect mode is compatible with identifiers for one-to-many exchanges or any-wise relationships (a controller with any others). A single indirect mode identifier may be used for a public service or business or otherwise when building brand and reputation in that identifier is important. An indirect mode identifier may also be used for private one-to-one or select groups but where intermittent availability is not tolerable.
More in [Source: chapter Protocol Operational Modes in KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
The protocol may operate in two basic modes, called direct and indirect. The availability and consistency attack surfaces are different for the two modes and hence the mitigation properties of the protocol are likewise mode specific. [Source: chapter Security concerns in KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
[Direct mode](https://weboftrust.github.io/WOT-terms/docs/glossary/direct-mode.md)
---
title: information-theoretic-security
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/information-theoretic-security
md: https://weboftrust.github.io/WOT-terms/04_glossary/information-theoretic-security.md
---
# information-theoretic-security
the highest level of cryptographic security concerning a cryptographic secret (seed, salt, or private key).
Source: Dr. S. Smith
---
title: input-output
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/input-output
md: https://weboftrust.github.io/WOT-terms/04_glossary/input-output.md
---
# input-output
In [computing](https://en.wikipedia.org/wiki/Computing), input/output (I/O, or informally io or IO) is the communication between an information processing system, such as a [computer](https://en.wikipedia.org/wiki/Computer), and the outside world, possibly a human or another information processing system. [Inputs](https://en.wikipedia.org/wiki/Information) are the signals or [data](https://en.wikipedia.org/wiki/Data_\(computing\)) received by the system and outputs are the signals or data sent from it. The term can also be used as part of an action; to "perform I/O" is to perform an [input or output operation](https://en.wikipedia.org/wiki/I/O_scheduling).
[Input/Output](https://en.wikipedia.org/wiki/Input/output)
---
title: inquisitor
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/inquisitor
md: https://weboftrust.github.io/WOT-terms/04_glossary/inquisitor.md
---
# inquisitor
In the ACDC context it's a general term for someone (in a validating role) that launches an inquiry at some KERI [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md).
An inquisitor was an [official](https://en.wikipedia.org/wiki/Official) (usually with [judicial](https://en.wikipedia.org/wiki/Judicial) or investigative functions) in an [inquisition](https://en.wikipedia.org/wiki/Inquisition) – an organization or program intended to eliminate [heresy](https://en.wikipedia.org/wiki/Heresy) and other things contrary to the [doctrine](https://en.wikipedia.org/wiki/Doctrine) or teachings.
Source: [Wikipedia](https://en.wikipedia.org/wiki/Inquisitor)
---
title: verified-integrity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/integrity
md: https://weboftrust.github.io/WOT-terms/04_glossary/integrity.md
---
# verified-integrity
A mechanism that can unambiguously assess whether the information is/continues to be whole, sound and unimpaired
- In KERI's secure attribution focus integrity is verified by [internal consistency](https://weboftrust.github.io/WOT-terms/docs/glossary/internal-inconsistency.md) of [KE(R)L](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md) and [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) plus [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection.
- In ACDC the [self addressing identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md) (SAID) takes of verified integrity at all times by design
- The streaming protocol CESR has verifiable integrity due to it's code tables and round-robin [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md).
[integrity](https://weboftrust.github.io/WOT-terms/docs/glossary/integrity.md)
[(complementary) integrity verification](https://weboftrust.github.io/WOT-terms/docs/glossary/complementary-integrity-verification.md)
---
title: interaction-event
description: Non-establishment Event that anchors external data to the key-state as established by the most recent prior establishment event.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/interaction-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/interaction-event.md
---
# interaction-event
Non-establishment Event that anchors external data to the key-state as established by the most recent prior establishment event.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: non-interactive-authentication-design
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/interactive-authentication-design
md: https://weboftrust.github.io/WOT-terms/04_glossary/interactive-authentication-design.md
---
# non-interactive-authentication-design
A group of approaches having non-interactive mechanisms that pose unique problems because they do not allow a challenge response reply handshake. A request is submitted that is self-authenticating without additional interaction.
The main benefits of non-interactive authentication are scalability and path independent end-to-end verifiability. These benefits become more important in decentralized applications that employ [zero-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/zero-trust.md) architectures.
More in [source](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw) Keri Request Authentication Mechanism (KRAM) by Samuel Smith
[Interactive authentication design](https://weboftrust.github.io/WOT-terms/docs/glossary/interactive-authentication-design.md)
---
title: interceptor
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/interceptor
md: https://weboftrust.github.io/WOT-terms/04_glossary/interceptor.md
---
# interceptor
a [keria](https://weboftrust.github.io/WOT-terms/docs/glossary/keria.md) class that allows to push events that are happening inside the cloud agent to other backend processes. It is similar to the notifier class but it is used to "notify" other web services.
[https://github.com/WebOfTrust/keria/pull/67](https://github.com/WebOfTrust/keria/pull/67)
---
title: interleaved-serialization
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/interleaved-serialization
md: https://weboftrust.github.io/WOT-terms/04_glossary/interleaved-serialization.md
---
# interleaved-serialization
Serializations of different types interleaved in an overarching format
One extremely useful property of CESR is that special **count codes** enable CESR to be interleaved with other serializations. For example, Many applications use [JSON](https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html#JSON) [RFC4627](https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html#RFC4627), [CBOR](https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html#CBOR) [RFC8949](https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html#RFC8949), or MsgPack ([MGPK](https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html#MGPK)) to serialize flexible self-describing data structures based on field maps, also known as _dictionaries_ or [hash tables](https://weboftrust.github.io/WOT-terms/docs/glossary/distributed-hash-table.md).
[Source IETF-CESR](https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html#section-3.5)
---
title: internal-inconsistency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/internal-inconsistency
md: https://weboftrust.github.io/WOT-terms/04_glossary/internal-inconsistency.md
---
# internal-inconsistency
Internal is used to describe things that exist or happen inside an [entity](https://weboftrust.github.io/WOT-terms/docs/glossary/entity.md). In our scope of digital [identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md) its (in)consistency is considered within the defining data structures and related data stores.
In [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md), you are protected against internal inconsistency by the hash chain data structure of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) because the only [authority](https://weboftrust.github.io/WOT-terms/docs/glossary/authority.md) that can sign the log is the [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) itself.
---
title: internet-assigned-numbers-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/internet-assigned-numbers-authority
md: https://weboftrust.github.io/WOT-terms/04_glossary/internet-assigned-numbers-authority.md
---
# internet-assigned-numbers-authority
is the organization that oversees the allocation of [IP](https://www.techtarget.com/searchunifiedcommunications/definition/Internet-Protocol) addresses to internet service providers ([ISPs](https://www.techtarget.com/whatis/definition/ISP)).
[Source](https://www.techtarget.com/whatis/definition/IANA-Internet-Assigned-Numbers-Authority)
In addition to global [IP addressing](https://www.techtarget.com/whatis/definition/IP-address-Internet-Protocol-Address), IANA is also responsible for domain name system ([DNS](https://www.techtarget.com/searchnetworking/definition/domain-name-system)) root zone management, autonomous system numbers and any "unique parameters and protocol values" for the internet community.
[Source](https://www.techtarget.com/whatis/definition/IANA-Internet-Assigned-Numbers-Authority)
[Wikipedia](https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority)
---
title: interoperability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/interoperability
md: https://weboftrust.github.io/WOT-terms/04_glossary/interoperability.md
---
# interoperability
Interoperability is a characteristic of a product or system to work with other products or systems. While the term was initially defined for [information technology](https://en.wikipedia.org/wiki/Information_technology) or [systems engineering](https://en.wikipedia.org/wiki/Systems_engineering) services to allow for information exchange.
[More on source Wikipedia](https://en.wikipedia.org/wiki/Interoperability)
[Identifier interoperability](https://www.doi.org/factsheets/Identifier_Interoper.html) enables users to re-use these identifiers (and their associated data) across different applications. Such interoperability of identifiers encompasses not only technical aspects of interoperability but consideration of the purpose and community of use of the identifiers.
[Source](https://www.doi.org/factsheets/Identifier_Interoper.html)
If two or more systems use common [data formats](https://en.wikipedia.org/wiki/File_format) and [communication protocols](https://en.wikipedia.org/wiki/Communication_protocol) and are capable of communicating with each other, they exhibit syntactic interoperability. [XML](https://en.wikipedia.org/wiki/XML) and [SQL](https://en.wikipedia.org/wiki/SQL) are examples of common data formats and protocols. Lower-level data formats also contribute to syntactic interoperability, ensuring that alphabetical characters are stored in the same [ASCII](https://en.wikipedia.org/wiki/ASCII) or a [Unicode](https://en.wikipedia.org/wiki/Unicode) format in all the communicating systems.
[More on source Wikipedia](https://en.wikipedia.org/wiki/Interoperability)
Beyond the ability of two or more computer systems to exchange information, [semantic interoperability](https://en.wikipedia.org/wiki/Semantic_interoperability) is the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end users of both systems.
[Cross-domain interoperability](https://en.wikipedia.org/wiki/Cross-domain_interoperability) involves multiple social, organizational, political, legal entities working together for a common interest or information exchange.
[More on source Wikipedia](https://en.wikipedia.org/wiki/Interoperability)
---
title: interoperable
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/interoperable
md: https://weboftrust.github.io/WOT-terms/04_glossary/interoperable.md
---
# interoperable
[Interoperability](https://weboftrust.github.io/WOT-terms/docs/glossary/interoperability.md)
---
title: ip-address
description: An Internet Protocol address (IP address) is a numerical label such as '192.0.2.1' that is connected to a computer network that uses the Internet Protocol for communication. An IP address serves two main functions: network interface identification) and location addressing.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ip-address
md: https://weboftrust.github.io/WOT-terms/04_glossary/ip-address.md
---
# ip-address
An Internet Protocol address (IP address) is a numerical label such as '192.0.2.1' that is connected to a [computer network](https://en.wikipedia.org/wiki/Computer_network) that uses the [Internet Protocol](https://en.wikipedia.org/wiki/Internet_Protocol) for communication. An IP address serves two main functions: network interface [identification](https://en.wikipedia.org/wiki/Identification_\(information\)) and location [addressing](https://en.wikipedia.org/wiki/Network_address).
Much more on source [Wikipedia](https://en.wikipedia.org/wiki/IP_address)
---
title: IPEX
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/IPEX
md: https://weboftrust.github.io/WOT-terms/04_glossary/IPEX.md
---
# IPEX
[Issuance and presentation exchange protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/issuance-and-presentation-exchange-protocol.md)
---
title: iss
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/iss
md: https://weboftrust.github.io/WOT-terms/04_glossary/iss.md
---
# iss
iss = vc issue, verifiable credential issuance
---
title: issuance-and-presentation-exchange-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/issuance-and-presentation-exchange-protocol
md: https://weboftrust.github.io/WOT-terms/04_glossary/issuance-and-presentation-exchange-protocol.md
---
# issuance-and-presentation-exchange-protocol
provides a uniform mechanism for the issuance and presentation of ACDCs in a securely attributable manner.
A single protocol is able to work for both types of exchanges ([issuance](https://weboftrust.github.io/WOT-terms/docs/glossary/issuance-exchange.md) and [presentation](https://weboftrust.github.io/WOT-terms/docs/glossary/presentation-exchange.md)) by recognizing that all exchanges (both issuance and presentation) may be modeled as the disclosure of information by a [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) to a [Disclosee](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md).
The _difference_ between exchange types is _the information disclosed not the mechanism for disclosure_.
([Source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md))
---
title: issuance-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/issuance-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/issuance-event.md
---
# issuance-event
The initial transaction event log event anchored to the issuing AID’s key event log that represents the issuance of an ACDC credential.
Source: Philip Feairheller.
It's a sort of "[inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md)" of a verifiable credential.
---
title: issuance-exchange
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/issuance-exchange
md: https://weboftrust.github.io/WOT-terms/04_glossary/issuance-exchange.md
---
# issuance-exchange
A special case of a [presentation exchange](https://weboftrust.github.io/WOT-terms/docs/glossary/presentation-exchange.md) where the [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) is the [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) of the origin (Primary) ACDC of the [DAG](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) formed by the set of chained [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md)s so disclosed.
In an issuance exchange, when the origin ACDC has an [Issuee](https://weboftrust.github.io/WOT-terms/docs/glossary/issuee.md), the [Disclosee](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md) MAY also be the origin ACDC's Issuee.
---
title: issuee
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/issuee
md: https://weboftrust.github.io/WOT-terms/04_glossary/issuee.md
---
# issuee
a role of an entity to which the claims of an ACDC are asserted.
Source: Dr. S. Smith
An [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) is optionally issued to the Issuee. When present, the Issuee identifier ([AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md)) appears at the top level of the attribute section or in the attribute list at the top level of the attribute aggregate section of the ACDC.
Each ACDC MUST have an [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) and MAY have an [Issuee](https://weboftrust.github.io/WOT-terms/docs/glossary/issuee.md). The set of [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md)s so disclosed in a presentation exchange MUST be chained. This set of chained ACDCs define a [directed acyclic graph](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
---
title: qualified-vlei-issuer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/issuer
md: https://weboftrust.github.io/WOT-terms/04_glossary/issuer.md
---
# qualified-vlei-issuer
The contracting party to the vLEI Issuer Qualification Agreement that has been qualified by GLEIF as a Qualified vLEI Issuer.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
Is an authoritative role at the GLEIF organization that is mandated to issue [vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) credentials to others.
---
title: ITPS
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ITPS
md: https://weboftrust.github.io/WOT-terms/04_glossary/ITPS.md
---
# ITPS
[Information theoretic security](https://weboftrust.github.io/WOT-terms/docs/glossary/information-theoretic-security.md)
---
title: ixn
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ixn
md: https://weboftrust.github.io/WOT-terms/04_glossary/ixn.md
---
# ixn
[JSON](https://weboftrust.github.io/WOT-terms/docs/glossary/JSON.md) field name (attribute) for Interaction Event; its content (value) contains a hash pointer. All [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) events are anchored in a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) in either ixn ([interaction](https://weboftrust.github.io/WOT-terms/docs/glossary/interaction-event.md)) or [rot](https://weboftrust.github.io/WOT-terms/docs/glossary/rot.md) ([rotation event](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md)s). This is the foundation enabling a verifiable credential protocol to be built on top of KERI.
[Source](https://kentbull.com/2023/03/09/keri-tutorial-series-treasure-hunting-in-abydos-issuing-and-verifying-a-credential-acdc/) Kent Bull 2023
[rot](https://weboftrust.github.io/WOT-terms/docs/glossary/rot.md)
---
title: javascript-object-notation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/javascript-object-notation
md: https://weboftrust.github.io/WOT-terms/04_glossary/javascript-object-notation.md
---
# javascript-object-notation
JSON (JavaScript Object Notation, pronounced [/ˈdʒeɪsən/](https://en.wikipedia.org/wiki/Help:IPA/English); also [/ˈdʒeɪˌsɒn/](https://en.wikipedia.org/wiki/Help:IPA/English)) is an [open standard](https://en.wikipedia.org/wiki/Open_standard) [file format](https://en.wikipedia.org/wiki/File_format) and [data interchange](https://en.wikipedia.org/wiki/Electronic_data_interchange) format that uses [human-readable](https://en.wikipedia.org/wiki/Human-readable_medium) text to store and transmit data objects consisting of [attribute–value pairs](https://en.wikipedia.org/wiki/Attribute%E2%80%93value_pair) and [arrays](https://en.wikipedia.org/wiki/Array_data_type) (or other [serializable](https://en.wikipedia.org/wiki/Serialization) values). It is a common data format with diverse uses in [electronic data interchange](https://en.wikipedia.org/wiki/Electronic_data_interchange), including that of [web applications](https://en.wikipedia.org/wiki/Web_application) with [servers](https://en.wikipedia.org/wiki/Server_\(computing\)).
JSON is a [language-independent](https://en.wikipedia.org/wiki/Language-independent_specification) data format. It was derived from [JavaScript](https://en.wikipedia.org/wiki/JavaScript), but many modern [programming languages](https://en.wikipedia.org/wiki/Programming_language) include code to generate and [parse](https://en.wikipedia.org/wiki/Parsing) JSON-format data. JSON filenames use the extension .json.
JavaScript Object Notation. JSON is a [language-independent](https://en.wikipedia.org/wiki/Language-independent_specification) data format. It was derived from [JavaScript](https://en.wikipedia.org/wiki/JavaScript). It's an [open standard](https://en.wikipedia.org/wiki/Open_standard) [file format](https://en.wikipedia.org/wiki/File_format) and [data interchange](https://en.wikipedia.org/wiki/Electronic_data_interchange) format that uses [human-readable](https://en.wikipedia.org/wiki/Human-readable_medium) text to store and transmit data objects consisting of [attribute–value pairs](https://en.wikipedia.org/wiki/Attribute%E2%80%93value_pair) and [arrays](https://en.wikipedia.org/wiki/Array_data_type) (or other [serializable](https://en.wikipedia.org/wiki/Serialization) values).
More on [source](https://en.wikipedia.org/wiki/JSON) Wikipedia
---
title: javascript-object-signing-and-encryption
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/javascript-object-signing-and-encryption
md: https://weboftrust.github.io/WOT-terms/04_glossary/javascript-object-signing-and-encryption.md
---
# javascript-object-signing-and-encryption
is a framework intended to provide a method to securely transfer claims (such as authorization information) between parties. The JOSE framework provides a collection of specifications to serve this purpose.
Related: `JWK`, `JWT`. [More info](https://jose.readthedocs.io/en/latest/)
---
title: JOSE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/JOSE
md: https://weboftrust.github.io/WOT-terms/04_glossary/JOSE.md
---
# JOSE
[Javascript object signing and encryption](https://weboftrust.github.io/WOT-terms/docs/glossary/javascript-object-signing-and-encryption.md)
---
title: JSON
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/JSON
md: https://weboftrust.github.io/WOT-terms/04_glossary/JSON.md
---
# JSON
[JavaScript Object Notation](https://weboftrust.github.io/WOT-terms/docs/glossary/javascript-object-notation.md)
---
title: judge
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/judge
md: https://weboftrust.github.io/WOT-terms/04_glossary/judge.md
---
# judge
A judge is an entity or component that examines the entries of one or more [KERLs](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md) and DELs of a given identifier to validate that the event history is from a non-[duplicitous](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) controller and has been witnessed by a sufficient number of non-duplicitous [witnesses](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) such that it may be trusted or conversely not-trusted by a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md).
A judge determines current \[authoritative\] key set for identifier from the [key event receipt logs](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md) from a set of witnesses. Judges transmit the 'judgement' of watchers concerning duplicity.
Example AT&T vs T-Mobile. The only "fault" that is apparent, is an attack on the KEL. And that can only occur via key compromise. So a successful multi-threshold attack causing [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) is the only thing [watchers](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) are looking for.
So even competitors will want to share across the entire ecosystem. Similar to certificate transparency, all competitors in the internet hosting space share the information with each other because it is in their best interest to eliminate fraud / duplicity.
Paraphrased by @henkvancann based on [source Samuel Smith / Phil Feairheller](https://hackmd.io/-soUScAqQEaSw5MJ71899w?view#2022-09-06)
---
title: juror
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/juror
md: https://weboftrust.github.io/WOT-terms/04_glossary/juror.md
---
# juror
A juror has the basic task of performing [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection on events and event receipts.
---
title: jury
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/jury
md: https://weboftrust.github.io/WOT-terms/04_glossary/jury.md
---
# jury
The jury is the set of entities or components acting as [jurors](https://weboftrust.github.io/WOT-terms/docs/glossary/juror.md).
---
title: KA2CE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KA2CE
md: https://weboftrust.github.io/WOT-terms/04_glossary/KA2CE.md
---
# KA2CE
[KERI agreement algorithm for control establishment](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-agreement-algorithm-for-control-establishment.md)
---
title: KAACE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KAACE
md: https://weboftrust.github.io/WOT-terms/04_glossary/KAACE.md
---
# KAACE
[KERI agreement algorithm for control establishment](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-agreement-algorithm-for-control-establishment.md)
---
title: KAPI
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KAPI
md: https://weboftrust.github.io/WOT-terms/04_glossary/KAPI.md
---
# KAPI
Application programmer interfaces (APIs) for the various components in the KERI ecosystem such as Controllers, Agents, Witnesses, Watchers, Registrars etc need by which they can share information. The unique properties of the KERI protocol require APIs that preserve those properties. We call the set of APIs the KERI API.
[Source Kapi Repo](https://github.com/WebOfTrust/kapi/blob/main/kapi.md)
---
title: KAWA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KAWA
md: https://weboftrust.github.io/WOT-terms/04_glossary/KAWA.md
---
# KAWA
[KERI’s Algorithm for Witness Agreement](https://weboftrust.github.io/WOT-terms/docs/glossary/keri’s-algorithm-for-witness-agreement.md)
---
title: keep
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keep
md: https://weboftrust.github.io/WOT-terms/04_glossary/keep.md
---
# keep
Is KERI's and ACDC's user interface that uses the keripy agent for its backend. It uses the REST API exposed from the keripy agent.
Source: Philip Feairheller
Keep is a task orientated application for managing [AIDs](https://github.com/WebOfTrust/ietf-keri) in ecosystems, e.g. the [vLEI Ecosystem](https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei).
Keep can be used to:
- establish and manage local AIDs
- create, join and manage distributed Multi-Sig AIDs (with or without delegation)
- issue and revoke credentials specified within the vLEI Ecosystem
More info on [Github repo](https://github.com/WebOfTrust/keep) of Keep.
---
title: KEL
description: A Key Event Log.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KEL
md: https://weboftrust.github.io/WOT-terms/04_glossary/KEL.md
---
# KEL
A Key Event Log.
[Key Event Log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md)
---
title: keri-agreement-algorithm-for-control-establishment
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri-agreement-algorithm-for-control-establishment
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri-agreement-algorithm-for-control-establishment.md
---
# keri-agreement-algorithm-for-control-establishment
Agreement on an event in a key event log [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md) means each [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) has observed the exact version of the event and each witness’ [receipt](https://weboftrust.github.io/WOT-terms/docs/glossary/receipt.md) has been received by every other witness.
Control establishment means that the set of agreeing witnesses, along with the controller of the identifier and associated keypairs, create a verifiable way to establish control authority for an identifier by reading all of the events in the KEL that have been agreed upon by the witnesses and the controller.
'KA2CE' '[KA2CE](https://weboftrust.github.io/WOT-terms/docs/glossary/KA2CE.md)' and 'KAACE'.
The agreement with KA2CE is as follows: "... the controller first creates its own receipt of the event and then promulgates the receipted event to witnesses in order to gather their promulgated receipts.
In this algorithm, an agreement consists of a specific version of an event with verifiable receipts. (signatures) from the controller and a set of witnesses.
A state of agreement about a version of an event with respect to a set of witnesses means that each witness in that set has witnessed the same version of that event, and each witness’ receipt in that set has been promulgated to every other witness in that set."
Source [KERI Whitepaper Section 11.4.2 Agreement](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
A newly invented algorithm that is a simplification of PBFT class algorithms, separation of control of distributed consensus using distinct promulgation (witness) and confirmation (watcher) networks (new invention), but many non-BFT consensus algorithms do something similar, and one BFT algorithm, Stellar, does something similar but not the same.
What if PBFT and Stellar had a baby missing liveness and total ordering but had safety and were completely decentralized, portable, and permissionless? It would be named KERI.
(SamMSmith)
---
title: keri-command-line-interface
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri-command-line-interface
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri-command-line-interface.md
---
# keri-command-line-interface
Command line tool used to create identifiers, manage keys, query for KELs and participate in delegated identifiers or multi-signature group identifiers. It also includes operations for running witnesses, watchers and cloud agents to establish a cloud presence for any identifier.
Most commands require a “name” parameter which references a named Habitat (think wallet) for performing the operation.
[IIW34 presentation slides](https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68_0_5)
---
title: keri-event-stream
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri-event-stream
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri-event-stream.md
---
# keri-event-stream
A stream of verifiable KERI data, consisting of the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) and other data such as a [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md). This data is a CESR event stream (TODO: link to IANA application/cesr media type) and may be serialized in a file using [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md) encoding. We refer to these _CESR stream resources_ as KERI event streams to simplify the vocabulary.
Source `did:webs` [ToIP specification](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
---
title: keri-improvement-doc
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri-improvement-doc
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri-improvement-doc.md
---
# keri-improvement-doc
These docs are modular so teams of contributors can independently work and create PRs of individual KIDs; KIDs answer the question "how we do it". We add commentary to the indivudual KIDs that elaborate on the why. It has been split from the how to not bother implementors with the why.
---
title: keri-ox
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri-ox
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri-ox.md
---
# keri-ox
The RUST programming-language implementation of the [KERI](https://github.com/trustoverip/acdc/wiki/KERI) protocol.
---
title: keri-request-authentication-method
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri-request-authentication-method
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri-request-authentication-method.md
---
# keri-request-authentication-method
All requests from a web client must use KRAM (KERI Request Authentication Method) for replay attack protection. The method is essentially based on each request body needing to include a date time string field in ISO-8601 format that must be within an acceptable time window relative to the server's date time. See the [KRAM Github repo](https://github.com/WebOfTrust/kram/blob/main/README.md)
Source [SKWA GitHub repo](https://github.com/WebOfTrust/skwa), more info in [HackMD.io write-up](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw)
[SKWA](https://weboftrust.github.io/WOT-terms/docs/glossary/SKWA.md)
---
title: keri-suite-search-engine
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri-suite-search-engine
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri-suite-search-engine.md
---
# keri-suite-search-engine
KERISSE is the Docusaurus [self-education site](https://weboftrust.github.io/WOT-terms/) of Web-of-Trust GitHub repo with Typesense search facilities. Because of its focus on well-versed developers in the field of [SSI](https://weboftrust.github.io/WOT-terms/docs/glossary/SSI.md) and the support of their journey to understand the structure of the code and how things work in the [KERI suite](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-suite.md) it's more a search engine that drills down on documentation.
[kerific](https://weboftrust.github.io/WOT-terms/docs/glossary/kerific.md) is a front-end tool that show all available glossary-definition in [KERISSE](https://weboftrust.github.io/WOT-terms/docs/glossary/KERISSE.md) for matching words in any web text; combined in the [Dictionary SSI](https://weboftrust.github.io/keridoc/docs/dictionary?level=2). This is based on a large JSON file
---
title: keri-suite
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri-suite
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri-suite.md
---
# keri-suite
The _KERI suite_ is the set of inter-related developments (KERI, ACDC, OOBI, CESR, IPEX, etc) under the Web-of -Trust user on Github
---
title: KERI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KERI
md: https://weboftrust.github.io/WOT-terms/04_glossary/KERI.md
---
# KERI
[Key event receipt infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md)
---
title: keri’s-algorithm-for-witness-agreement
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keri’s-algorithm-for-witness-agreement
md: https://weboftrust.github.io/WOT-terms/04_glossary/keri’s-algorithm-for-witness-agreement.md
---
# keri’s-algorithm-for-witness-agreement
a type of Byzantine Fault Tolerant ([BFT](https://weboftrust.github.io/WOT-terms/docs/glossary/byzantine-fault-tolerance.md)) algorithm.
Source: Dr. S.Smith
---
title: KERIA-agent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KERIA-agent
md: https://weboftrust.github.io/WOT-terms/04_glossary/KERIA-agent.md
---
# KERIA-agent
An [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) in [KERIA](https://weboftrust.github.io/WOT-terms/docs/glossary/keria.md) terms, is an instance of a keystore ([Hab](https://weboftrust.github.io/WOT-terms/docs/glossary/hab.md)) that runs in a given instance of the KERIA agent server.
---
title: keria
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keria
md: https://weboftrust.github.io/WOT-terms/04_glossary/keria.md
---
# keria
KERI Agent in the cloud. The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces.
1. Boot Interface - Exposes one endpoint for Agent Worker initialization.
2. Admin Interface - The REST API for command and control operations from the Signify Client.
3. KERI Protocol Interface - CESR over HTTP endpoint for KERI protocol interactions with the rest of the world.
More at [Source Github repo](https://github.com/WebOfTrust/keria/blob/main/docs/protocol.md)
---
title: keride
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keride
md: https://weboftrust.github.io/WOT-terms/04_glossary/keride.md
---
# keride
is a _Rust_ programming language library for [Key Event Receipt Infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md). Among its features is [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md), signing, prefixing, pathing, and parsing.
More on [Github repo](https://github.com/WebOfTrust/keride)
---
title: keridemlia
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keridemlia
md: https://weboftrust.github.io/WOT-terms/04_glossary/keridemlia.md
---
# keridemlia
It is a contraction of [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md) and [Kademlia](https://en.wikipedia.org/wiki/Kademlia). It's the distributed database of Witness IP-addresses based on a [Distributed Hash Table](https://weboftrust.github.io/WOT-terms/docs/glossary/distributed-hash-table.md). It also does the CNAME - stuff that [Domain Name](https://weboftrust.github.io/WOT-terms/docs/glossary/domain-name.md) Services (DNS) offers for KERI: the mapping between an identifier and it's controller AID stored in the KEL to its current wittness AID and the wittness AID to the IP address.
(@henkvancann)
---
title: kerific
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/kerific
md: https://weboftrust.github.io/WOT-terms/04_glossary/kerific.md
---
# kerific
_kerific_ is a front plugin or extension that currently only works for Chrome and Brave. It matches words in any text on the web that is parseable for kerific and offers buttons to various glossaries and definitions in the [SSI](https://weboftrust.github.io/WOT-terms/docs/glossary/self-sovereign-identity.md) field.
All glossaries that [KERISSE](https://weboftrust.github.io/WOT-terms/docs/glossary/KERISSE.md) is allowed to scrape are combined in the [Dictionary SSI](https://weboftrust.github.io/keridoc/docs/dictionary?level=2). This is based on a large JSON file, which kerific uses to match words in any text and serve the combined glossaries.
It is in the [Chrome Webstore](https://chromewebstore.google.com/detail/kerific/ckbmkbbmnfbeecfmoiohobcdmopekgmp?hl=nl)
---
title: KERIMask
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KERIMask
md: https://weboftrust.github.io/WOT-terms/04_glossary/KERIMask.md
---
# KERIMask
A wallet similar to _MetaMask_, the manifestation will be a browser extension and it will connect to KERIA servers in order for a person to control AIDs from their browser.
As of October 2023 KERIMask is only planned.
[Signify keria request authentication protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/signify-keria-request-authentication-protocol.md)
---
title: Slack Archive
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keripy
md: https://weboftrust.github.io/WOT-terms/04_glossary/keripy.md
---
# Slack Archive
---
title: KERISSE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KERISSE
md: https://weboftrust.github.io/WOT-terms/04_glossary/KERISSE.md
---
# KERISSE
[KERI suite search engine](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-suite-search-engine.md)
---
title: KERL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KERL
md: https://weboftrust.github.io/WOT-terms/04_glossary/KERL.md
---
# KERL
[Key event receipt log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md)
---
title: kever
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/kever
md: https://weboftrust.github.io/WOT-terms/04_glossary/kever.md
---
# kever
Kever is a key event verifier.
---
title: key-compromise
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-compromise
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-compromise.md
---
# key-compromise
Basically there are three infrastructures that are included in “key management” systems that must be protected:
- Key pair creation and storage
- Event signing
- Event signature verification So when we say “key compromise” we really mean compromise of one of those three things.
More in the security sections of [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf)
---
title: key-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-log
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-log.md
---
# key-event-log
a Verifiable data structure that is a backward and forward chained, signed, append-only log of key events for an AID. The first entry in a KEL must be the one and only Inception event of that AID.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
KELs are hash-chained Key Events. These are blockchains in a narrow definition, but not in the sense of ordering (not ordered) or global consensus mechanisms (which is not needed). (SamMSmith)
A KEL is KERI's VDS: the proof of key state of its identifier.
---
title: key-event-message
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-message
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-message.md
---
# key-event-message
Message whose body is a key event and whose attachments may include signatures on its body.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: key-event-receipt-infrastructure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-receipt-infrastructure
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-receipt-infrastructure.md
---
# key-event-receipt-infrastructure
or the KERI protocol, is an identity system-based secure overlay for the Internet.
Source: Dr. S.Smtih
It's a new approach to decentralized identifiers and decentralized key management that promises significant benefits for `SSI` (self-sovereign identity) and `ToIP` (Trust over IP) infrastructure.
(_@drummondreed_)
KERI is an identifier system that fixes the internet. It's a fully decentralized permission-less key management architecture. It solves the `secure attribution problem` to its identifiers and allows portability.
(_@henkvancann_)
While attribution has always been a non-exact science, we could come as close to attribution as “beyond a reasonable doubt”, those days are over with KERI.
KERI provides a trust spanning layer for the internet, because **the protocol solves the secure attribution problem** in a general, portable, fully decentralized way. There are more types of trust IN KERI but they all depend on the most important _attributive_ trust. From KERI we've learned that _secure attribution_ is the essential problem for _any_ `identifier system` to solve.
---
title: key-event-receipt-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-receipt-log
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-receipt-log.md
---
# key-event-receipt-log
a key event receipt log is a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/kel.md) that also includes all the consistent key event receipt [Message](https://weboftrust.github.io/WOT-terms/docs/glossary/message.md)s created by the associated set of witnesses. See annex [Key event receipt log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md).
Source: Dr. S.Smith
Signed Key Events, keeping track of establishment events. To begin with the inception event and any number of rotation events. We call that the establishment subsequence. The Key Event Receipt Logs are built from receipts of events signed by the witnesses of those events (these are called commitments); these are also append-only but not hash-chained. (@henkvancann)
---
title: key-event-receipt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-receipt
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-event-receipt.md
---
# key-event-receipt
message whose body references a Key event and whose attachments must include one or more signatures on that Key event.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: key-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-event.md
---
# key-event
Concretely, it is the serialized data structure of an entry in the Key event log (KEL) for an AID. Abstractly, the data structure itself. Key events come in different types and are used primarily to establish or change the authoritative set of keypairs and/or anchor other data to the authoritative set of keypairs at the point in the KEL actualized by a particular entry.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
Events happening to controlling keys of an identifier recorded in a Key Event Log (KEL).
A _key event_ is data structure that consist of a header (Key Event header), a configuration section (Key Event Data spans Header and configuration) and signatures (Key event Message spans Data and signatures)
(_@henkvancann_)
---
title: key-management
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-management
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-management.md
---
# key-management
management of cryptographic keys in a crypto-system. This includes dealing with the generation, exchange, storage, use, crypto-shredding (destruction) and replacement of keys (also [rotation](#key-rotation)). It includes cryptographic protocol design, key servers, user procedures, and other relevant protocols.
Successful key management is critical to the _security_ of a crypto-system. It is the more challenging side of cryptography in a sense that it involves aspects of social engineering such as system policy, user training, organizational and departmental interactions, and coordination between all of these elements, in contrast to pure mathematical practices that can be automated.
More on [wikipedia](https://en.wikipedia.org/wiki/Key_management)
---
title: key-pair
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-pair
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-pair.md
---
# key-pair
is a private key and its corresponding public key resulting from a one-way crypto-graphical function; a key pair is used with an asymmetric-key (public-key) algorithm in a so called [Public Key Infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/public-key-infrastructure.md) (PKI).
---
title: key-state
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-state
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-state.md
---
# key-state
a set of currently authoritative keypairs for an AID and any other information necessary to secure or establish control authority over an AID. This includes current keys, prior next key digests, current thresholds, prior next thresholds, witnesses, witness thresholds, and configurations.
A key state of an AID is first established through an inception event and may be altered by subsequent rotation events.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
A set of authoritative keys for an AID and other essential information necessary to establish, evolve, verify, and validate control-signing authority for that AID. This information includes the current public keys and their thresholds (for a multi-signature scheme); pre-rotated key digests and their thresholds; [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md)es and their thresholds; and configurations. An AID’s key state is first established through its [inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md) and may evolve via subsequent [rotation event](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md)s. Thus, an AID’s key state is time-dependent.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: key-stretching
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-stretching
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-stretching.md
---
# key-stretching
In [cryptography](https://en.wikipedia.org/wiki/Cryptography), key stretching techniques are used to make a possibly weak [key](https://en.wikipedia.org/wiki/Key_\(cryptography\)), typically a [password](https://en.wikipedia.org/wiki/Password) or [passphrase](https://en.wikipedia.org/wiki/Passphrase), more secure against a [brute-force attack](https://en.wikipedia.org/wiki/Brute-force_attack) by increasing the resources (time and possibly space) it takes to test each possible key.
Passwords or passphrases created by humans are often short or predictable enough to allow [password cracking](https://en.wikipedia.org/wiki/Password_cracking), and key stretching is intended to make such attacks more difficult by complicating a basic step of trying a single password candidate. Key stretching also improves security in some real-world applications where the key length has been constrained, by mimicking a longer key length from the perspective of a brute-force attacker.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Key_stretching)
---
title: key-transparency
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key-transparency
md: https://weboftrust.github.io/WOT-terms/04_glossary/key-transparency.md
---
# key-transparency
provides a lookup service for generic records and a public, tamper-proof audit log of all record changes. While being publicly auditable, individual records are only revealed in response to queries for specific IDs.
- Key Transparency can be used as a _public key discovery service_ to authenticate users and provides a mechanism to keep the service accountable.
- Key Transparency empowers account owners to reliably see what public keys have been associated with their account, and it can be used by senders to see how long an account has been active and stable before trusting it. [Source](https://github.com/google/keytransparency/)
Key Transparency does this by using piece of blockchain technology called a Merkle Tree.
More on [Stackexchange](https://security.stackexchange.com/questions/149125/how-does-key-transparency-work) how key transparency works.
(_@henkvancann_)
---
title: stale-key
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/key
md: https://weboftrust.github.io/WOT-terms/04_glossary/key.md
---
# stale-key
A stale key is an outdated or expired encryption key that should no longer be used for securing data
[Stale (key) event](https://weboftrust.github.io/WOT-terms/docs/glossary/stale-event.md)
---
title: keystore
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/keystore
md: https://weboftrust.github.io/WOT-terms/04_glossary/keystore.md
---
# keystore
A keystore in KERI is the encrypted data store that hold the private keys for a collection of AIDs.
Source: Philip Feairheller.
KERI explicitly distinguishes [keystore](https://weboftrust.github.io/WOT-terms/docs/glossary/keystore.md) and [wallet](https://weboftrust.github.io/WOT-terms/docs/glossary/wallet.md); the latter being a superset of the former. [Keep](https://weboftrust.github.io/WOT-terms/docs/glossary/keep.md) is KERI's and ACDC's user interface with Keripy agent API as a back end.
A [Java Keystore](https://en.wikipedia.org/wiki/Java_KeyStore) is a non-related concept!
---
title: KID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KID
md: https://weboftrust.github.io/WOT-terms/04_glossary/KID.md
---
# KID
[KERI improvement doc](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-improvement-doc.md)
---
title: kli
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/kli
md: https://weboftrust.github.io/WOT-terms/04_glossary/kli.md
---
# kli
[KERI command line interface](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-command-line-interface.md)
---
title: KRAM
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/KRAM
md: https://weboftrust.github.io/WOT-terms/04_glossary/KRAM.md
---
# KRAM
[KERI Request Authentication Method](https://weboftrust.github.io/WOT-terms/docs/glossary/keri-request-authentication-method.md)
---
title: ksn
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ksn
md: https://weboftrust.github.io/WOT-terms/04_glossary/ksn.md
---
# ksn
ksn = state, key state notice
---
title: large-language-model
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/large-language-model
md: https://weboftrust.github.io/WOT-terms/04_glossary/large-language-model.md
---
# large-language-model
A large language model (LLM) is a [language model](https://en.wikipedia.org/wiki/Language_model) consisting of a [neural network](https://en.wikipedia.org/wiki/Artificial_neural_network) with many parameters (typically billions of weights or more), trained on large quantities of unlabeled text using [self-supervised learning](https://en.wikipedia.org/wiki/Self-supervised_learning) or [semi-supervised learning](https://en.wikipedia.org/wiki/Semi-supervised_learning).
More on [Source Wikipedia](https://en.wikipedia.org/wiki/Large_language_model)
---
title: lead-bytes
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/lead-bytes
md: https://weboftrust.github.io/WOT-terms/04_glossary/lead-bytes.md
---
# lead-bytes
In order to avoid confusion with the use of the term [pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pad.md) character, when [pre-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-pad.md)ding with bytes that are not replaced later, we use the term **lead bytes**. So lead-bytes are added "pre-conversion".
The term [pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pad.md) may be confusing not merely because both ways use a type of padding but it is also true that the number of pad characters when padding _post-conversion_ equals the number of lead bytes when padding _pre-conversion_.
---
title: ledger-backer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ledger-backer
md: https://weboftrust.github.io/WOT-terms/04_glossary/ledger-backer.md
---
# ledger-backer
A [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) in KERI that is ledger-registered. It's a type of [backer](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md) that proof its authenticity by a signing key anchored to the public key of a data item on a (public) blockchain.
---
title: legal-entity-engagement-context-role-vlei-credential-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework
md: https://weboftrust.github.io/WOT-terms/04_glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md
---
# legal-entity-engagement-context-role-vlei-credential-governance-framework
A document that details the requirements for [vLEI Role Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-role-credential.md) **issued to** representatives of a Legal Entity _in other than official roles_ but in functional or other context of engagement.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
- [Legal entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md)
- [Engagement context role (ECR)](https://weboftrust.github.io/WOT-terms/docs/glossary/engagement-context-role.md)
- [vLEI credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md)
- [Governance framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md)
---
title: legal-entity-official-organizational-role-vlei-credential-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/legal-entity-official-organizational-role-vlei-credential-governance-framework
md: https://weboftrust.github.io/WOT-terms/04_glossary/legal-entity-official-organizational-role-vlei-credential-governance-framework.md
---
# legal-entity-official-organizational-role-vlei-credential-governance-framework
A document that details the requirements for [vLEI Role Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-role-credential.md) **issued to** official representatives of a Legal Entity.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
- [Legal entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md)
- [Official organizational role (OOR)](https://weboftrust.github.io/WOT-terms/docs/glossary/official-organizational-role.md)
- [vLEI credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md)
- [Governance framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md)
---
title: legal-entity-vlei-credential-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/legal-entity-vlei-credential-governance-framework
md: https://weboftrust.github.io/WOT-terms/04_glossary/legal-entity-vlei-credential-governance-framework.md
---
# legal-entity-vlei-credential-governance-framework
A _document_ that details the requirements for vLEI Credential **issued by** a [Qualified vLEI Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified-vlei-issuer.md) to a [Legal Entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md).
---
title: legal-entity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/legal-entity
md: https://weboftrust.github.io/WOT-terms/04_glossary/legal-entity.md
---
# legal-entity
Unique parties that are legally or financially responsible for the performance of financial transactions or have the legal right in their jurisdiction to enter independently into legal contracts.
As defined in ISO 17442:2020, includes, but is not limited to, the unique parties above, regardless of whether they are incorporated or constituted in some other way (e.g., trust, partnership, contractual). It includes governmental organizations and supranationals and individuals when acting in a business capacity but excludes natural persons. It also includes international branches.
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: legitimized-human-meaningful-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/legitimized-human-meaningful-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/legitimized-human-meaningful-identifier.md
---
# legitimized-human-meaningful-identifier
An [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md) and its associated self-certifying trust basis gives rise to a trust domain for associated cryptographically verifiable non-repudiable statements. Every other type of identifier including human meaningful identifiers may then be secured in this resultant trust domain via an [end-verifiable](https://weboftrust.github.io/WOT-terms/docs/glossary/end-verifiable.md) [authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/authorization.md). This authorization legitimizes that human meaningful identifier as an LID through its association with an AID. The result is a secured trust domain specific identifier couplet of aid|lid.
Human meaningfulness has two limiting characteristics: _scarcity_ and _security_. Scarcity exhibits itself in various undesirable ways such as name squatting, or race conditions to register or otherwise assert control. More importantly, there is no inherent security property of a human meaningful identifier. This makes them insecure by default. Happily an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md) comes to rescue.
The trust domain of an AID provides a context in which to interpret the appearance of any LID. The AID is implied by the context. This means that the AID may not need to be prepended or appear with the LID. This allows the human meaningfulness of the LID to exhibit itself without being encumbered by the AID.
This model of an _aid|lid couplet_ unifies all desirable identifier properties into one identifier system model. The AID part provides the security infrastructure while the LID part provides the application specific human meaningfulness. The connection between the two is provided by a legitimizing authorization represented by the |.
---
title: vLEI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/LEI
md: https://weboftrust.github.io/WOT-terms/04_glossary/LEI.md
---
# vLEI
[Verifiable legal entity identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-legal-entity-identifier.md)
---
title: levels-of-assurance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/levels-of-assurance
md: https://weboftrust.github.io/WOT-terms/04_glossary/levels-of-assurance.md
---
# levels-of-assurance
Identity and other trust decisions are often not binary. They are judgement calls. Any time that judgement is not a simple “Yes/No” answer, you have the option for levels of assurance. Also 'LoA'.
KERI has the same LOAs for entropy and trust in human behavior preserving the security of key pairs and preserving their own privacy. It has high LOAs for the cryptographic bindings of controllers and identifiers. Also the validation of witnesses and watchtowers has high a LOA.
---
title: LID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/LID
md: https://weboftrust.github.io/WOT-terms/04_glossary/LID.md
---
# LID
[Legitimized human meaningful identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/legitimized-human-meaningful-identifier.md)
---
title: listed-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/listed-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/listed-identifier.md
---
# listed-identifier
Is a list in an [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) of authorised did:webs identifier + method; the list appears in the metadata of the did:webs DID-doc.
Source: paraphrased Samuel Smith, Zoom meeting _KERI dev_ Thursday Nov 9 2023
---
title: live-attack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/live-attack
md: https://weboftrust.github.io/WOT-terms/04_glossary/live-attack.md
---
# live-attack
an attack that compromises either the current signing keys used to sign non-establishment events or the current pre-rotated keys needed to sign a subsequent establishment event. See (Security Properties of Prerotation)\[#live-attacks\].
Source: Dr. S.Smith
---
title: liveness
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/liveness
md: https://weboftrust.github.io/WOT-terms/04_glossary/liveness.md
---
# liveness
Liveness refers to a set of properties of concurrent systems, that require a system to make progress despite the fact that its concurrently executing components ("processes") may have to "take turns" in critical sections, parts of the program that cannot be simultaneously run by multiple processes.
A _liveness_ property in concurrent systems states that "something good will eventually occur".
Liveness guarantees are important properties in operating systems and distributed systems.
Unlike liveness properties, [safety properties](#safety-properties) can be violated by a finite execution of a distributed system. All properties can be expressed as the intersection of safety and liveness properties.
| TBW | prio 2 how is liveness important in distributed systems? how does KERI guarantee liveness}
On [wikipedia](https://en.wikipedia.org/wiki/Liveness)
---
title: LLM
description: See Large Language Model
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/LLM
md: https://weboftrust.github.io/WOT-terms/04_glossary/LLM.md
---
# LLM
---
title: LoA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/LoA
md: https://weboftrust.github.io/WOT-terms/04_glossary/LoA.md
---
# LoA
[Levels of assurance](https://weboftrust.github.io/WOT-terms/docs/glossary/levels-of-assurance.md)
---
title: LoC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/LoC
md: https://weboftrust.github.io/WOT-terms/04_glossary/LoC.md
---
# LoC
[Loci of control](https://weboftrust.github.io/WOT-terms/docs/glossary/loci-of-control.md)
---
title: loci-of-control
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/loci-of-control
md: https://weboftrust.github.io/WOT-terms/04_glossary/loci-of-control.md
---
# loci-of-control
Locus of control is the degree to which people believe that they, as opposed to external forces (beyond their influence), have control over the outcome of events in their lives. Also 'LoC'.
More on [wikipedia](https://en.wikipedia.org/wiki/Locus_of_control)
In SSI loci-of-control was decribed by Tim Bouma in 2019: 
In KERI this is further developed:
- Key Event Promulgation Service = from the `controller`'s point.
- key event confirmation service = from the `validator`'s point.
The separation of promulgation and confirmation into two separate _loci-of-control_, one the controller’s, and the other the validator’s simplifies the interaction space between these two parties.
The design principle of separating the loci-of-control between controllers and validators removes one of the major drawbacks of total ordered distributed consensus algorithms, that is, shared governance over the pool of nodes that provide the consensus algorithm.
The primary purpose of the [KA2CE](#keri-agreement-algorithm-for-control-establishment) algorithm is to protect the controller’s ability to promulgate the authoritative copy of its key event history despite external attack. This includes maintaining a sufficient degree of availability such that any validator may obtain an authoritative copy on demand.
---
title: locked-state
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/locked-state
md: https://weboftrust.github.io/WOT-terms/04_glossary/locked-state.md
---
# locked-state
The default status a KERI data store is in once it has been created using a [passcode](https://weboftrust.github.io/WOT-terms/docs/glossary/passcode.md); it is by default encrypted.
---
title: management-TEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/management-TEL
md: https://weboftrust.github.io/WOT-terms/04_glossary/management-TEL.md
---
# management-TEL
[Management transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/management-transaction-event-log.md)
---
title: management-transaction-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/management-transaction-event-log
md: https://weboftrust.github.io/WOT-terms/04_glossary/management-transaction-event-log.md
---
# management-transaction-event-log
A 'management [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md)' will signal the creation of the _Virtual Credential Registry [(VCR)](https://weboftrust.github.io/WOT-terms/docs/glossary/VCR.md)_ and track the list of _Registrars_ that will act as _[Backers](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md)_ for the individual _transaction event logs (TELs)_ for each [virtual credential](https://weboftrust.github.io/WOT-terms/docs/glossary/virtual-credential.md) (VC).
---
title: media-type
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/media-type
md: https://weboftrust.github.io/WOT-terms/04_glossary/media-type.md
---
# media-type
A Media type (formerly known as _MIME type_) is a standard way to indicate the nature and format of a file, in the same way as 'image/jpeg' for JPEG images, used on the internet.
It is a two-part identifier for file formats and format contents transmitted on the internet. Their purpose is somewhat similar to file extensions in that they identify the intended data format.
The [Internet Assigned Numbers Authority (IANA)](https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority) is the official authority for the standardization and publication of these classifications.
Source: [Wikipedia](https://en.wikipedia.org/wiki/Media_type)
The [Internet Assigned Numbers Authority (IANA)](https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority) is the official authority for the standardization and publication of these classifications.
Source: [Wikipedia](https://en.wikipedia.org/wiki/Media_type)
The more important criteria are:
- Standard Format: MIME types must adhere to the format type/subtype
- Registered with IANA: Although, ideally, MIME types should be registered with the Internet Assigned Numbers Authority ([IANA](https://weboftrust.github.io/WOT-terms/docs/glossary/IANA.md)), ensuring they are part of a recognized standard, we consider Experimental or Proposed MIME types as being a valid MIME type as well.
---
title: message
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/message
md: https://weboftrust.github.io/WOT-terms/04_glossary/message.md
---
# message
a serialized data structure that comprises its body and a set of serialized data structures that are its attachments. Attachments may include but are not limited to signatures on the body.
Source: Dr. S.Smith
Consists of a serialized data structure that comprises its body and a set of serialized data structures that are its attachments. Attachments may include but are not limited to signatures on the body.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: messagepack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/messagepack
md: https://weboftrust.github.io/WOT-terms/04_glossary/messagepack.md
---
# messagepack
MessagePack is a [computer](https://en.wikipedia.org/wiki/Computer) data interchange format. It is a binary form for representing simple [data structures](https://en.wikipedia.org/wiki/Data_structure) like [arrays](https://en.wikipedia.org/wiki/Array_data_structure) and [associative arrays](https://en.wikipedia.org/wiki/Associative_array). MessagePack aims to be as compact and simple as possible. The official implementation is available in a variety of languages
[MessagePack](https://en.wikipedia.org/wiki/MessagePack)
---
title: MFA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/MFA
md: https://weboftrust.github.io/WOT-terms/04_glossary/MFA.md
---
# MFA
[Multi-factor Authentication](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-factor-authentication.md)
---
title: MIME-type
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/MIME-type
md: https://weboftrust.github.io/WOT-terms/04_glossary/MIME-type.md
---
# MIME-type
[Media type](https://weboftrust.github.io/WOT-terms/docs/glossary/media-type.md)
---
title: moobi
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/moobi
md: https://weboftrust.github.io/WOT-terms/04_glossary/moobi.md
---
# moobi
Multi [OOBI](https://weboftrust.github.io/WOT-terms/docs/glossary/OOBI.md) would allow to share a bunch of different end-points (oobis) all at once. A way for a single store to share multiple endpoints for that store.
Those oobis would still need a way to authorize the endpoint provider, the endpoint role, for each of the different things. A multi-sig becomes a messy collaboration effort, especially when you take into account signing at the edge. You would need an authorization record for each end-point. And then pass this to all the members and ask them to collaborate.
Source: Philip Feairheller [KERI-dev meeting](https://github.com/WebOfTrust/keri/discussions/39) July 27 2023
---
title: most-compact
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/most-compact
md: https://weboftrust.github.io/WOT-terms/04_glossary/most-compact.md
---
# most-compact
An [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) that, for a given level of disclosure, is as compact as it can be, which means
- it has the [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/SAID.md)s for each section that are not disclosed
- it has expanded sections that are disclosed
Multiple forms of a single ACDC can be called the "most compact" version, given that each level of [graduated disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/graduated-disclosure.md) will have a "most compacted" version. If all the blocks are expanded to a most compact version, then it becomes fully expanded. If all the blocks are replaced with SAIDs then it becomes fully compacted.
This form is a part of the graduated disclosure objective.
[Fully (expanded)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-expanded.md) version of an ACDC
[Fully compact(ed)](https://weboftrust.github.io/WOT-terms/docs/glossary/fully-compact.md) version of an ACDC
---
title: multi-factor-authentication
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/multi-factor-authentication
md: https://weboftrust.github.io/WOT-terms/04_glossary/multi-factor-authentication.md
---
# multi-factor-authentication
Authentication by combining multiple security factors. Well-known factors are _what you know_, _what you have_ and _what you are_.
Multi-factor authentication (MFA; two-factor authentication, or 2FA, along with similar terms) is an [electronic authentication](https://en.wikipedia.org/wiki/Electronic_authentication) method in which a user is granted access to a website or application only after successfully presenting two or more pieces of evidence (or factors) to an [authentication](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) mechanism.
[Source Wikipedia](https://en.wikipedia.org/wiki/Multi-factor_authentication)
---
title: multi-valent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/multi-valent
md: https://weboftrust.github.io/WOT-terms/04_glossary/multi-valent.md
---
# multi-valent
A [delegator](https://weboftrust.github.io/WOT-terms/docs/glossary/delegator.md) may have multiple [delegates](https://weboftrust.github.io/WOT-terms/docs/glossary/delegate.md), thereby enabling elastic horizontal scalability. Multiple delegates from a single delegator. Furthermore, each delegate may act as a delegator for its own delegates to form a _nested delegation tree_.
This allows mapping key management infrastructures to any hierarchically structured organization's computing infrastructure. With this construction, both security and performance trade-offs may be made as appropriate. Such an extended delegation setup we call a multivalent key management infrastructure.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
[Univalent](https://weboftrust.github.io/WOT-terms/docs/glossary/univalent.md) [Bivalent](https://weboftrust.github.io/WOT-terms/docs/glossary/bivalent.md)
---
title: multicodec
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/multicodec
md: https://weboftrust.github.io/WOT-terms/04_glossary/multicodec.md
---
# multicodec
Is a self-describing multi-format, it wraps other formats with a tiny bit of self-description. A multi-codec identifier is both a variant (variable length integer) and the code identifying data.
See more at [GitHub Multi-codec](https://github.com/multiformats/multicodec)
Multi-codec is an agreed-upon codec table. It is designed for use in binary representations, such as keys or identifiers (i.e CID). It is then used as a prefix to identify the data that follows.
---
title: multiplexing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/multiplexing
md: https://weboftrust.github.io/WOT-terms/04_glossary/multiplexing.md
---
# multiplexing
In [telecommunications](https://en.wikipedia.org/wiki/Telecommunications) and [computer networking](https://en.wikipedia.org/wiki/Computer_network), multiplexing (sometimes contracted to _muxing_) is a method by which multiple analog or digital signals are combined into one signal over a [shared medium](https://en.wikipedia.org/wiki/Shared_medium). The aim is to share a scarce resource - a physical [transmission medium](https://en.wikipedia.org/wiki/Transmission_medium).
More on source [Wikipedia-page](https://en.wikipedia.org/wiki/Multiplexing)
Because of [count codes](https://weboftrust.github.io/WOT-terms/docs/glossary/count-code.md) and the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) - and [concatenation](https://weboftrust.github.io/WOT-terms/docs/glossary/concatenation.md) property in CESR, [pipelining](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md) is possible, which then uses _multiplexing_ (combining [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) primitives) and _de-multiplexing_ (unravelling self-framing [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md)). The addition of group framing codes as independently composable primitives enables [hierarchical compositions](https://weboftrust.github.io/WOT-terms/docs/glossary/hierarchical-composition.md).
---
title: multisig
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/multisig
md: https://weboftrust.github.io/WOT-terms/04_glossary/multisig.md
---
# multisig
also multi-signature or multisignature; is a [digital signature](https://en.wikipedia.org/wiki/Digital_signature) scheme which allows a group of users to sign a single piece of digital data.
Paraphrased by @henkvancann from Wikipedia [source](https://en.wikipedia.org/wiki/Multisignature)
The KERI team has conceptually chosen for minimal sufficient means and so-called _dumb crypto_: "'Dumb technology' is freely available, understandable to everyone and easy to implement. In our case: just hashes and digital signatures."
KERI has thresholded set of [non-repudiable](https://weboftrust.github.io/WOT-terms/docs/glossary/non-repudiable.md) signatures.
KERI's CESR, and therefore KERI and ACDC is extensible with the latest more sophisticated multi-signature schemes like Schnorr signatures.
---
title: naive-conversion
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/naive-conversion
md: https://weboftrust.github.io/WOT-terms/04_glossary/naive-conversion.md
---
# naive-conversion
Non-CESR Base64 conversion. How people are used to using the Base64 encode and decode. Without [pre-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-pad.md)ding etc all the stuff CESR does to ensure aligns on 24 bit boundaries so [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) never uses the '=' pad character. But naive [Base64](https://weboftrust.github.io/WOT-terms/docs/glossary/base64.md) will pad if the length is not 24 bit aligned.
Source: Samuel Smith in [issue 34](https://github.com/WebOfTrust/ietf-cesr/issues/34)
Naive conversion is a text to binary conversion or vice versa that doesn't anticipate on either [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) and / or on the [concatenation](https://weboftrust.github.io/WOT-terms/docs/glossary/concatenation.md) capability of the result of such an operation.
In the [IETF draft CESR](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#conversions) there's much attention for naive [Base64](https://weboftrust.github.io/WOT-terms/docs/glossary/base64.md) conversions, because it helps explaining the necessity of stable code characters and padding in CESR to achieve:
- [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md)
- round-robin [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md)
- [concatenation](https://weboftrust.github.io/WOT-terms/docs/glossary/concatenation.md) options
- [pipelined](https://weboftrust.github.io/WOT-terms/docs/glossary/pipelining.md) streaming
---
title: namespace
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/namespace
md: https://weboftrust.github.io/WOT-terms/04_glossary/namespace.md
---
# namespace
In an identity system, an identifier can be generalized to a _namespace_ to provide a systematic way of organizing identifiers for related resources and their attributes. A namespace is a grouping of symbols or identifiers for a set of related objects.
A namespace employs some scheme for assigning identifiers to the elements of the namespace. A simple name-spacing scheme uses a prefix or prefixes in a hierarchical fashion to compose identifiers. The following is an example of a namespace scheme for addresses within the USA that uses a hierarchy of prefixes:
```
state.county.city.zip.street.number.
```
An example element in this namespace may be identified with the following:
```
utah.wasatch.heber.84032.main.150S.
```
---
title: ndigs
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ndigs
md: https://weboftrust.github.io/WOT-terms/04_glossary/ndigs.md
---
# ndigs
Digests of public keys, not keys themselves. The reason to use ndigs is to prove control over public keys or to hide keys. It's used in Keripy and consists of a list of qualified base64 digests of public rotation key derivations.
---
title: nested-cooperative-delegated-identifiers
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/nested-cooperative-delegated-identifiers
md: https://weboftrust.github.io/WOT-terms/04_glossary/nested-cooperative-delegated-identifiers.md
---
# nested-cooperative-delegated-identifiers
In KERI delegations are cooperative, this means that both the delegator and delegate must contribute to a delegation. The delegator creates a cryptographic commitment in either a rotation or interaction event via a seal in a delegated establishment event. The delegate creates a cryptographic commitment in its establishment event via a seal to the delegating event.
Each commitment is signed respectively by the committer. This cooperative delegation together with special superseding recovery rules for events enables cooperative recovery.
This superseding rule may be recursively applied to multiple levels of delegation, thereby enabling recovery of any set of keys signing or pre-rotated in any lower levels by a superseding rotation delegation at the next higher level. This cascades the security of the key management infrastructure of higher levels to lower levels. This is a distinctive security feature of the cooperative delegation of identifiers in KERI.
More in chapter Nested Delegation Recovery of the [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
---
title: next-threshold
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/next-threshold
md: https://weboftrust.github.io/WOT-terms/04_glossary/next-threshold.md
---
# next-threshold
represents the number or fractional weights of signatures from the given set of next keys required to be attached to a [Message](https://trustoverip.github.io/tswg-keri-specification/#term:message) for the [Message](https://trustoverip.github.io/tswg-keri-specification/#term:message) to be considered fully signed.
---
title: NFT
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/NFT
md: https://weboftrust.github.io/WOT-terms/04_glossary/NFT.md
---
# NFT
[Non-fungible token](https://weboftrust.github.io/WOT-terms/docs/glossary/non-fungible-token.md)
---
title: non-establishment-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/non-establishment-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/non-establishment-event.md
---
# non-establishment-event
a Key event that does not change the current Key state for an AID. Typically, the purpose of a Non-establishment event is to anchor external data to a given Key state as established by the most recent prior Establishment event for an AID.
Source: Dr. S. Smith
A key event tieing or anchoring a data payload to the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of an identifier. This data payload includes a set of one or more [seals](https://weboftrust.github.io/WOT-terms/docs/glossary/seal.md) each of which anchor data to the key event.
The data payload event may be used to make verifiable, authoritative statements on behalf of the identifier controller.
These might include authorizations of encryption keys, communication routes, service endpoints, and so forth.
Transactions or workflows composed of non-establishment events are secured by virtue of being included in the verifiable key event sequence with the verifiable authoritative establishment events.
A non-establishment event is a key event that does not change the current key-state for an AID.
Source [KERI Whitepaper Section 7.22 page 46](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
A non-establishment event is a key event that does not change the current key-state for an [identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md). The event (only) ties or anchors digital data to the [key event log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) of the identifier.
_(@henkvancann)_
---
title: non-fungible-token
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/non-fungible-token
md: https://weboftrust.github.io/WOT-terms/04_glossary/non-fungible-token.md
---
# non-fungible-token
A non-fungible token (NFT) is a [financial security](https://en.wikipedia.org/wiki/Security_\(finance\)) consisting of digital data stored in a [blockchain](https://en.wikipedia.org/wiki/Blockchain), a form of [distributed ledger](https://en.wikipedia.org/wiki/Distributed_ledger).
The ownership of an NFT is recorded in a blockchain, and can be transferred by the owner, allowing NFTs to be sold and traded. NFTs can be created by anybody, and require few or no coding skills to create. NFTs typically contain references to [digital files](https://en.wikipedia.org/wiki/Digital_file) such as photos, videos, and audio.
Because NFTs are uniquely identifiable assets, they differ from [cryptocurrencies](https://en.wikipedia.org/wiki/Cryptocurrencies), which are [fungible](https://en.wikipedia.org/wiki/Fungibility).
There's nothing "non fungible" about a non-fungible token in our perspective. It's just another unique identifier controlled by a public private key pair. The fact that NFTs uniquely identify a digital entity isn't very impressive, because of their
- security flaw : the security is dependent on the host ledger the NFT is anchored to
- transferability flaw : you need a transaction to transfer ownership on the host blockchain, controlling keys can't be rotated
- monetization flaw : there's no good reason whatsoever to mingle the value aspect and the uniqueness property of a digital asset; unfortunately, that's what NFTs are doing.
Uniqueness tokenization done correctly is to be praised. Moreover, **it's recommended to look into KERI identifiers and ACDC veracity claims to support the value of the identifiers**, whose monetary value can be recorded elsewhere and separately from the identifier system. Key (pre-)rotation can transfer ownership of a unique digital asset without the need for a transaction on a blockchain.
Sometimes an NFT doesn't only uniquely represent a digital asset: it can be the digital twin of - and is also (hopefully) backed by - a real-life asset. Even in this perspective, KERI and ACDC are more inclusive, because in the KERI/ACDC case we are dealing with globally portable unique digital twins, not anchored to, i.e. locked in, a blockchain.
---
title: non-interactive-authentication-design
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/non-interactive-authentication-design
md: https://weboftrust.github.io/WOT-terms/04_glossary/non-interactive-authentication-design.md
---
# non-interactive-authentication-design
A group of approaches having non-interactive mechanisms that pose unique problems because they do not allow a challenge response reply handshake. A request is submitted that is self-authenticating without additional interaction.
The main benefits of non-interactive authentication are scalability and path independent end-to-end verifiability. These benefits become more important in decentralized applications that employ [zero-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/zero-trust.md) architectures.
More in [source](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw) Keri Request Authentication Mechanism (KRAM) by Samuel Smith
[Interactive authentication design](https://weboftrust.github.io/WOT-terms/docs/glossary/interactive-authentication-design.md)
---
title: non-normative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/non-normative
md: https://weboftrust.github.io/WOT-terms/04_glossary/non-normative.md
---
# non-normative
A theory is called non-normative if it does not do what has described under '[Normative](https://weboftrust.github.io/WOT-terms/docs/glossary/normative.md)'. In general, the purpose of non-normative theories is not to give answers, but rather to describe possibilities or predict what might happen as a result of certain actions.
[Source](https://www.quora.com/What-is-the-difference-between-normative-and-non-normative?share=1).
---
title: non-repudiable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/non-repudiable
md: https://weboftrust.github.io/WOT-terms/04_glossary/non-repudiable.md
---
# non-repudiable
Non-repudiation refers to a situation where a statement's author **cannot successfully dispute** its authorship or the validity of an associated contract, signature or commitment.
The term is often seen in a legal setting when the authenticity of a signature is being challenged. In such an instance, the authenticity is being "repudiated".
Any non-repudiable signature made with the private key may be verified by extracting the public key from either the identifier itself or incepting information uniquely associated with the cryptographic derivation process for the identifier. In a basic SCID, the mapping between an identifier and its controlling public key is self-contained in the identifier itself.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#self-certifying-identifier-scid)
The function of KERI's identifier-system security overlay is to establish the authenticity (or authorship) of the message payload in an IP Packet by verifiably attributing it to a cryptonymous self-certifying identifier (AID) via an attached set of one or more asymmetric keypair-based non-repudiable digital signatures. The current valid set of associated asymmetric keypair(s) is proven via a verifiable data structure called a key event log (KEL).
An authenticatable (verifiable) internet message (packet) or data item includes the identifier and data in its payload. Attached to the payload is a digital signature(s) made with the private key(s) from the controlling keypair(s). Given the identifier in a message, any verifier of a message (data item) can use the identifier system mapping to look up the public key(s) belonging to the controlling keypair(s). The verifier can then verify the attached signature(s) using that public key(s). **Because the payload includes the identifier, the signature makes a non-repudiable cryptographic commitment to both the source identifier and the data in the payload.**
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#identifier-system-security-overlay)
---
title: non-transferable-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/non-transferable-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/non-transferable-identifier.md
---
# non-transferable-identifier
Controlling keys over this identifier cannot be rotated and therefore this identifier is [non-transferable](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable.md) to other control.
An identifier of this type has specific positive features like short-lived, peer to peer, one-time use, discardable, etc. that are very practical in certain use cases. Moreover non-transferable identifiers are much easier to govern than persistent identifiers that are [transferable](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable.md).
The KERI design approach is to build composable primitives instead of custom functionality that is so typical of other DKMI approaches:
- [transferable identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable-identifier.md)
- non-transferable identifiers
- [delegated identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/delegated-identifier.md)
---
title: non-transferable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/non-transferable
md: https://weboftrust.github.io/WOT-terms/04_glossary/non-transferable.md
---
# non-transferable
No [capacity to transfer](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable.md) (the control over) a certain digital asset in an unobstructed or loss-less manner. As opposed to [transferable](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable.md).
For example not legally transferable to the ownership of another entity.
A specific type of identifier we distinguish is a [non-transferable identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable-identifier.md); it is has specific positive features like short-lived, peer to peer, one-time use, discardable, etc. that are very practical in certain use cases.
---
title: normative
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/normative
md: https://weboftrust.github.io/WOT-terms/04_glossary/normative.md
---
# normative
a theory is “normative” if it, in some sense, tells you what you should do - what action you should take. If it includes a usable procedure for determining the optimal action in a given scenario.
[Source](https://www.quora.com/What-is-the-difference-between-normative-and-non-normative?share=1).
---
title: official-organizational-role
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/official-organizational-role
md: https://weboftrust.github.io/WOT-terms/04_glossary/official-organizational-role.md
---
# official-organizational-role
Also 'OOR'. A person that represents the Legal Entity in an official organizational role and is issued an OOR vLEI Credential.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: one-way-function
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/one-way-function
md: https://weboftrust.github.io/WOT-terms/04_glossary/one-way-function.md
---
# one-way-function
In computer science, a one-way function is a function that is easy to compute on every input, but hard to invert given the image of a random input. Here, "easy" and "hard" are to be understood in the sense of computational complexity theory, specifically the theory of polynomial time problems.
More on [Wikipedia](https://en.wikipedia.org/wiki/One-way_function)
---
title: OOBI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/OOBI
md: https://weboftrust.github.io/WOT-terms/04_glossary/OOBI.md
---
# OOBI
[Out-of-band introduction](https://weboftrust.github.io/WOT-terms/docs/glossary/out-of-band-introduction.md)
---
title: OOR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/OOR
md: https://weboftrust.github.io/WOT-terms/04_glossary/OOR.md
---
# OOR
[Official Organizational Role](https://weboftrust.github.io/WOT-terms/docs/glossary/official-organizational-role.md)
---
title: opcode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/opcode
md: https://weboftrust.github.io/WOT-terms/04_glossary/opcode.md
---
# opcode
Opcodes are meant to provide stream processing instructions that are more general and flexible than simply concatenated primitives or groups of primitives.
A yet to be determined stack based virtual machine could be executed using a set of opcodes that provides primitive, primitive group, or stream processing instructions. This would enable highly customizable uses for [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md).
The ‘\_’ selector is reserved for the yet to be defined [opcode](https://weboftrust.github.io/WOT-terms/docs/glossary/opcode.md) table or tables.
---
title: operator
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/operator
md: https://weboftrust.github.io/WOT-terms/04_glossary/operator.md
---
# operator
an optional field map in the Edge section that enables expression of the edge logic on edge subgraph as either a unary operator on the edge itself or an m-ary operator on the edge group.
Source: Dr. S.Smith
---
title: out-of-band-introduction
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/out-of-band-introduction
md: https://weboftrust.github.io/WOT-terms/04_glossary/out-of-band-introduction.md
---
# out-of-band-introduction
Out-of-band Introductions (OOBIs) are discovery and validation of IP resources for [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md) autonomic identifiers. **Discovery via URI, trust via KERI.**
The simplest form of a KERI OOBI is a namespaced string, a tuple, a mapping, a structured message, or structured attachment that contains both a KERI AID and a URL. The OOBI associates the URL with the AID.
In tuple form, this abstractly
```
(url, aid)
```
and concretely
```
("http://8.8.5.6:8080/oobi", "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM")
```
Validation is done based on [BADA](https://weboftrust.github.io/WOT-terms/docs/glossary/best-available-data-acceptance-mechanism.md) More in [KERI OOBI draft spec](https://hackmd.io/MxTAIBQTRkWU4-w140tNuA?view) and [KERI OOBI explained - draft](https://medium.com/p/510467856035).
From the [IETF draft specification](https://datatracker.ietf.org/doc/html/draft-ssmith-oobi):
An Out-Of-Band Introduction (OOBI) provides a discovery mechanism that associates a given URI or URL with a given AID (\[autonomic identifier\](https://weboftrust.github.io/WOT-terms/04_glossary/autonomic-identifier-(AID.md) or [self-addressing identifier (SAID)](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md)). The URI provided by an OOBI acts as a service endpoint for the discovery of verifiable information about the AID or SAID. As such an OOBI itself is not trusted but must be verified.
To clarify, any information obtained from the service endpoint provided in the OOBI must be verified by some other mechanism. An OOBI, however, enables any internet and web search infrastructure to act as an out-of-band infrastructure to discover information that is verified using an in-band mechanism or protocol. The primary in-band verification protocol is [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md).
---
title: owner
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/owner
md: https://weboftrust.github.io/WOT-terms/04_glossary/owner.md
---
# owner
[Owner](https://github.com/trustoverip/toip/wiki/owner) in ToIP glossary
---
title: ownership
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ownership
md: https://weboftrust.github.io/WOT-terms/04_glossary/ownership.md
---
# ownership
[Ownership](https://github.com/trustoverip/toip/wiki/ownership) in ToIP glossary
---
title: P2P
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/P2P
md: https://weboftrust.github.io/WOT-terms/04_glossary/P2P.md
---
# P2P
[Peer to peer](https://weboftrust.github.io/WOT-terms/docs/glossary/peer-to-peer.md)
---
title: pre-pad
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/pad
md: https://weboftrust.github.io/WOT-terms/04_glossary/pad.md
---
# pre-pad
the action and / or result of prepending a string with _leading_ pad characters to align to a certain length in bits or bytes.
There are two ways to provide the required alignment on 24-bit boundaries to satisfy the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) property. One is [post-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/post-pad.md), with trailing pad characters `=`, the text domain encoding to ensure that the text domain primitive has a total size (length) that is an integer multiple of 4. This is what [naive Base64 encoding](https://weboftrust.github.io/WOT-terms/docs/glossary/naive-conversion.md) does.
The other way is to _pre-pad_ leading bytes of zeros to the raw binary value before conversion to Base64 to ensure the total size of the raw binary value with pre-pad bytes is an integer multiple of 3 bytes. This ensures that the size in characters of the Base64 conversion of the pre-padded raw binary is an integer multiple of 4 characters.
[Source IEFT CESR draft](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#code-characters-and-lead-bytes)
---
title: parside
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/parside
md: https://weboftrust.github.io/WOT-terms/04_glossary/parside.md
---
# parside
is a bunch of generators. Responsible for pulling out a stream of bits from a CESR stream and parse it. Sam Smith suggested for Parside to not iterate stuff, only parse chunks delimited by the [count code](https://weboftrust.github.io/WOT-terms/docs/glossary/count-code.md). (Source Cesride: meeting Feb 2 2023)
CESR primitives are self-framing (which is relatively new). That means that you can construct your parser modually. We can dispatch the parsing of the stream to an entity. The [strip parameter](https://weboftrust.github.io/WOT-terms/docs/glossary/strip-parameter.md) tells us what part will be parsed be which code.
1. Parside should be concerned with parsing group codes, [cesride](https://weboftrust.github.io/WOT-terms/docs/glossary/cesride.md) concerned with parsing primitives.
2. Parside will contain a [count code](https://weboftrust.github.io/WOT-terms/docs/glossary/count-code.md) at the beginning of the stream, each cesr primitive is self framing, JSON is not; hence the [Version string](https://weboftrust.github.io/WOT-terms/docs/glossary/version-string.md).
3. Parside could "load" the tables it supports for dynamically loaded code tables
4. Parside could look at how/if we can return an interator/generator
Source Cesride: meeting Feb 2 2023 notes
> Cesride parses the CESR primitives
> Parside parses the [group codes](https://weboftrust.github.io/WOT-terms/docs/glossary/group-code.md)
| TBW |
- [Version code](https://weboftrust.github.io/WOT-terms/docs/glossary/version-code.md)
- [Version string](https://weboftrust.github.io/WOT-terms/docs/glossary/version-string.md)
- [Strip parameter](https://weboftrust.github.io/WOT-terms/docs/glossary/strip-parameter.md)
- [Cesride](https://weboftrust.github.io/WOT-terms/docs/glossary/cesride.md)
- [Sniffer](https://weboftrust.github.io/WOT-terms/docs/glossary/sniffer.md)
Source Cesride: meeting Feb 2 2023
Parside should start with a default version for CESR. Anytime it gets a version count code it changes the version and also elevates to the top level (the version count code must appear at the top level). The version count code determines which CESR table to load when parsing the stream. The [sniffer](https://weboftrust.github.io/WOT-terms/docs/glossary/sniffer.md) detects if CESR binary, CESR Text, JSON, CBOR, MGPK. If any of the last three then the parser regexes to find the version string inside the JSON, CBOR, and MGPK and from the version string extracts the number of characters/bytes that is the length of the JSON, CBOR, or MGPK. The parser then resumes sniffing. When the sniff is CESR then when at the top level looks for the CESR version count code or any other count codes. The interpretation of the count codes is dependent on the version count code that is why the Parser has to start with a default version count code because the stream may not begin with a version code or may have resumed after a cold restart. When a count code is parsed then the parser may descend into parsing whats inside group for a group count code which may recursively nest down a ways.
Source Slack Cesride thread: Feb 2 2023
---
title: partial-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/partial-disclosure
md: https://weboftrust.github.io/WOT-terms/04_glossary/partial-disclosure.md
---
# partial-disclosure
a disclosure of an ACDC that partially discloses its field maps using Compact Disclosure. The Compact Disclosure provides a cryptographically equivalent commitment to the yet-to-be-disclosed content, and the later exchange of the uncompacted content is verifiable to an earlier Partial Disclosure. Unlike Selective disclosure, a partially disclosable field becomes correlatable to its encompassing block after its Full Disclosure.
Source: Dr. S. Smith
An ACDC attribute section can be a nested branch in a tree. Partial disclosure is the weaker version because you can either decide to disclose or not. Selective disclosure is more fine-grained.
[Selective disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/selective-disclosure.md) is a from partial disclosure that has a different cryptographic fundament: a sort of cryptographic aggregator (not an accumulator).
Source: distilled from ACDC Zoom meeting, date March 28, 2023
---
title: partial-pre-rotation
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/partial-pre-rotation
md: https://weboftrust.github.io/WOT-terms/04_glossary/partial-pre-rotation.md
---
# partial-pre-rotation
[Partial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md)
---
title: partial-rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/partial-rotation
md: https://weboftrust.github.io/WOT-terms/04_glossary/partial-rotation.md
---
# partial-rotation
The pre-rotation mechanism supports partial pre-rotation or **more exactly partial rotation of pre-rotated keypairs**. It's a rotation operation on a set of pre-rotated keys that may keep some keys in reserve (i.e unexposed) while exposing others as needed.
Partial rotation serves two important purposes:
- [Reserve rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/reserve-rotation.md)
- [Custodial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-rotation.md)
Paraphrased by @henkvancann on the bases of the [IETF-KERI draft 2022](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md) by Samual Smith.
A valid rotation operation requires the satisfaction of two different thresholds. These are the current [threshold](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-threshold.md) of the given [rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md) ([establishment](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md)) event with respect to its associated current public key list and the next threshold from the given rotation event's most recent prior establishment event with respect to its associated blinded next key [digest](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md) list. For short, we denote the next threshold from the most recent prior establishment event as the prior next threshold, and the list of unblinded public keys taken from the blinded key digest list from the most recent prior establishment event as the prior next key list. Explication of the elements of the prior next key list requires exposing or unblinding the underlying public keys committed to by their corresponding digests that appear in the next key digest list of the most recent prior establishment event. The unexposed (blinded) public keys MAY be held in reserve.
More in [Source](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#partial-pre-rotation-detail)
---
title: party
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/party
md: https://weboftrust.github.io/WOT-terms/04_glossary/party.md
---
# party
An entity who participates or is concerned in an action, proceeding, plan, etc.
Source: ToIP
---
title: passcode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/passcode
md: https://weboftrust.github.io/WOT-terms/04_glossary/passcode.md
---
# passcode
A password, sometimes called a passcode (for example in [Apple](https://en.wikipedia.org/wiki/Apple_Inc.) devices), is secret data, typically a string of characters, usually used to confirm a user's identity.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Password)
---
title: pathing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/pathing
md: https://weboftrust.github.io/WOT-terms/04_glossary/pathing.md
---
# pathing
It was designed to sign portions of a credential aimed at complex cases like
- a credential embedded in another credential
- multiple signers, only signing portions of a credential (partial signing)
In these cases, we provide a path (using SAD path language) to what is signed. _We have never used it for credentials_, however we do need it for **forwarding in KERI embedded messages** - see [video discussion](https://us06web.zoom.us/rec/play/qEL79NTkwi4KHrC7ytfy4pYJySOvjpL_gqMSiTxEBl9uXPaeUSaQdka_65xLKP1yozaakqIlYpIX4Yxc.xN0-4LkaqWOZqDjg?canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fus06web.zoom.us%2Frec%2Fshare%2F9RtKAuTNe1417D-4tgdLzmdsrRz63EuaBOysMQU4EZ0ysw4aaZXsIXo1tIRNdzyC.FJhPr84fMxOsGoQN).
We don't sign our credentials, you shouldn't either!
Source: Philip Feairheller, July 20 2023, KERI-dev meeting
---
title: payload
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/payload
md: https://weboftrust.github.io/WOT-terms/04_glossary/payload.md
---
# payload
The term 'payload' is used to distinguish between the 'interesting' information in a chunk of data or similar and the overhead to support it. The payload refers to the interesting part.
It is borrowed from transportation, where it refers to the part of the load that 'pays': for example, a tanker truck may carry 20 tons of oil, but the fully loaded vehicle weighs much more than that - there's the vehicle itself, the driver, fuel, the tank, etc. It costs money to move all these, but the customer only cares about (and pays for) the oil, hence, 'pay-load'. [Source](https://softwareengineering.stackexchange.com/questions/158603/what-does-the-term-payload-mean-in-programming).
Now payload in `KERI`. The payload of an item in an `Event Log` is one the following cryptographic building blocks in KERI:
- a content digest hash
- a root hash of a Merkle-tree
- a public key Note tha KERI never puts raw data or privacy-sensitive data in a `KEL` or `KERL`.
---
title: peer-to-peer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/peer-to-peer
md: https://weboftrust.github.io/WOT-terms/04_glossary/peer-to-peer.md
---
# peer-to-peer
Peer-to-peer (P2P) computing or networking is a [distributed application](https://en.wikipedia.org/wiki/Distributed_application) architecture that partitions tasks or workloads between peers. Peers are **equally privileged**, [equipotent](https://en.wikipedia.org/wiki/Equipotent) participants in the network. They are said to form a peer-to-peer network of [nodes](https://en.wikipedia.org/wiki/Node_\(networking\))
More on source [Wikipedia](https://en.wikipedia.org/wiki/Peer-to-peer)
---
title: percolated-discovery
description: a discovery mechanism for information associated with an AID or a SAID, which is based on Invasion Percolation Theory. Once an entity has discovered such information, it may in turn share what it discovers with other entities. Since the information so discovered is end-verifiable, the percolation mechanism and percolating intermediaries do not need to be trusted.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/percolated-discovery
md: https://weboftrust.github.io/WOT-terms/04_glossary/percolated-discovery.md
---
# percolated-discovery
a discovery mechanism for information associated with an AID or a SAID, which is based on Invasion Percolation Theory. Once an entity has discovered such information, it may in turn share what it discovers with other entities. Since the information so discovered is end-verifiable, the percolation mechanism and percolating intermediaries do not need to be trusted.
Source: Dr. S. Smith
[Percolated information discovery](https://weboftrust.github.io/WOT-terms/docs/glossary/percolated-information-discovery.md)
---
title: percolated-information-discovery
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/percolated-information-discovery
md: https://weboftrust.github.io/WOT-terms/04_glossary/percolated-information-discovery.md
---
# percolated-information-discovery
In the [OOBI](https://weboftrust.github.io/WOT-terms/docs/glossary/OOBI.md) protocol, a discovery mechanism for the [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) and the [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md) protocols is provided by a bootstrap that enables Percolated Information Discovery (PID), which is based on Invasion Percolation Theory.
After related information for discovery and verification is bootstrapped from the OOBI, subsequent authorization is non-interactive, thus making it highly scalable. This provides what we call zero-trust percolated discovery or speedy percolated discovery.
Percolation means that each discoverer, in turn, may share what it discovers with any subsequent discoverers. Since the information so discovered is end-verifiable, the percolation mechanism and percolating intermediaries do not need to be trusted.
[Percolation theory](https://en.wikipedia.org/wiki/Percolation_theory) is a mathematical framework used to study the behavior of connected clusters in random systems. It was originally developed to understand the flow of fluids through porous media, but it has since found applications in various fields, including physics, mathematics, computer science, and social sciences.
Invasion percolation is a specific variant of percolation theory that models the infiltration of a fluid into a porous medium. It is used to study how a fluid, such as a gas or liquid, spreads through a random network of interconnected sites or pores.
The invasion process follows the principle of least resistance, where the fluid seeks the path of least resistance through the porous medium. As the invasion progresses, the fluid selectively infiltrates the sites with lower resistance, forming a connected cluster of invaded sites. The invaded cluster grows by adding new invaded sites through the neighboring dry sites with the lowest resistance.
[Percolated discovery](https://weboftrust.github.io/WOT-terms/docs/glossary/percolated-discovery.md)
---
title: perfect-security
description: a special case of Information theoretic security ITPS.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/perfect-security
md: https://weboftrust.github.io/WOT-terms/04_glossary/perfect-security.md
---
# perfect-security
a special case of Information theoretic security [ITPS](https://weboftrust.github.io/WOT-terms/docs/glossary/itps.md).
Source: Dr. S. Smith
---
title: persistent-data-structure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/persistent-data-structure
md: https://weboftrust.github.io/WOT-terms/04_glossary/persistent-data-structure.md
---
# persistent-data-structure
An append only verifiable data structure. What we sign may not change.
The approach that ACDCs take to data structures -- making them immutable and thus distributable and concurrency-friendly -- is very similar to the one [advocated and implemented by Clojure](https://github.com/candera/clojure-data-structures#collections-are-immutable).
The persistent data structure is a graph
---
title: persistent-identifier
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/persistent-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/persistent-identifier.md
---
# persistent-identifier
[Transferable Identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable-identifier.md)
---
title: PGP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/PGP
md: https://weboftrust.github.io/WOT-terms/04_glossary/PGP.md
---
# PGP
[Pretty good privacy](https://weboftrust.github.io/WOT-terms/docs/glossary/pretty-good-privacy.md)
---
title: PID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/PID
md: https://weboftrust.github.io/WOT-terms/04_glossary/PID.md
---
# PID
[percolated information discovery](https://weboftrust.github.io/WOT-terms/docs/glossary/percolated-information-discovery.md)
---
title: pii
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/pii
md: https://weboftrust.github.io/WOT-terms/04_glossary/pii.md
---
# pii
personally identifiable information
---
title: pipelining
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/pipelining
md: https://weboftrust.github.io/WOT-terms/04_glossary/pipelining.md
---
# pipelining
In [computing](https://en.wikipedia.org/wiki/Computing), a pipeline, also known as a data pipeline, is a set of [data](https://en.wikipedia.org/wiki/Data) processing elements connected in series, where the output of one element is the input of the next one. The elements of a pipeline are often executed in parallel or in time-sliced fashion. Some amount of [buffer storage](https://en.wikipedia.org/wiki/Buffer_\(computer_science\)) is often inserted between elements.
More on source [Wikipedia-page](https://en.wikipedia.org/wiki/Pipeline_\(computing\))
If you have a stream coming in, you have to look ahead how big a chunk of data can be. We call this a logical atomic data chunk.
With JSON I don’t know where the end is, so I have to parse the initial stream to find out. That's slow.
That once you have a block of data, that you can pull off chunks and de-multiplex from the stream into cores and multiplex them back into the streams. Cores in big datacenters are now max 5 GHz, a pipeline is 40 GHz. So you have to be able to do pipelining (split off over many cores). [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) is the only streaming protocol that has this anticipation on board.
Source: Samuel Smith, KERI Zoom meeting Dec 5 2023.
[Multiplexing](https://weboftrust.github.io/WOT-terms/docs/glossary/multiplexing.md)
---
title: PKI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/PKI
md: https://weboftrust.github.io/WOT-terms/04_glossary/PKI.md
---
# PKI
[Public key infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/public-key-infrastructure.md)
---
title: post-pad
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/post-pad
md: https://weboftrust.github.io/WOT-terms/04_glossary/post-pad.md
---
# post-pad
the action and / or result of extending a string with _trailing_ pad characters to align to a certain length in bits or bytes.
There are two ways to provide the required alignment on 24-bit boundaries to satisfy the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) property. One is _post-pad_, with trailing pad characters `=`, the text domain encoding to ensure that the text domain primitive has a total size (length) that is an integer multiple of 4. This is what [naive Base64 encoding](https://weboftrust.github.io/WOT-terms/docs/glossary/naive-conversion.md) does.
The other way is to [pre-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-pad.md) leading bytes of zeros to the raw binary value before conversion to Base64 to ensure the total size of the raw binary value with pre-pad bytes is an integer multiple of 3 bytes. This ensures that the size in characters of the Base64 conversion of the pre-padded raw binary is an integer multiple of 4 characters.
[Source IEFT CESR draft](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#code-characters-and-lead-bytes)
---
title: post-quantum
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/post-quantum
md: https://weboftrust.github.io/WOT-terms/04_glossary/post-quantum.md
---
# post-quantum
In cryptography, post-quantum cryptography (PQC) (sometimes referred to as quantum-proof, quantum-safe or quantum-resistant) refers to cryptographic algorithms (usually public-key algorithms) that are thought to be secure against a cryptanalytic attack by a quantum computer.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Post-quantum_cryptography)
Although individual public-private key pairs are most probably not post-quantum proof, by design the pre-rotation mechanism in KERI is post-quantum proof; which means that in the projected future presence of quantum computers KERI will still be safe. Basically, this safety is established by rotating keys before a brute force quantum attack can be effective. As quantum computers might get faster or more effective over time, the rotation intervals simply become shorter and/or increased [entropy](https://weboftrust.github.io/WOT-terms/docs/glossary/entropy.md) might be used for key generation.
---
title: pre-pad
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/pre-pad
md: https://weboftrust.github.io/WOT-terms/04_glossary/pre-pad.md
---
# pre-pad
the action and / or result of prepending a string with _leading_ pad characters to align to a certain length in bits or bytes.
There are two ways to provide the required alignment on 24-bit boundaries to satisfy the [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md) property. One is [post-pad](https://weboftrust.github.io/WOT-terms/docs/glossary/post-pad.md), with trailing pad characters `=`, the text domain encoding to ensure that the text domain primitive has a total size (length) that is an integer multiple of 4. This is what [naive Base64 encoding](https://weboftrust.github.io/WOT-terms/docs/glossary/naive-conversion.md) does.
The other way is to _pre-pad_ leading bytes of zeros to the raw binary value before conversion to Base64 to ensure the total size of the raw binary value with pre-pad bytes is an integer multiple of 3 bytes. This ensures that the size in characters of the Base64 conversion of the pre-padded raw binary is an integer multiple of 4 characters.
[Source IEFT CESR draft](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#code-characters-and-lead-bytes)
---
title: pre-rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/pre-rotation
md: https://weboftrust.github.io/WOT-terms/04_glossary/pre-rotation.md
---
# pre-rotation
Cryptographic commitment to next rotated key set in previous rotation or [inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md).
The main purpose of [key rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md) it to either prevent or recover from a successful compromise of one or more private keys by an exploiter. Given a potentially compromised private key, an exploiter could sign statements and even capture full control over the identifier by rotating the current key pair.
Pre-rotation mitigates successful exploit of a given set of signing private keys. There are several assumptions listed in [chapter Pre-rotation of the KERI white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf) about the circumstances under which pre-rotation is able to sustain this mitigation, e.g. it assumes that the private keys remains private until after issuance of the associated identifier.
Pre-rotation is a new invention in KERI. Pre-rotation is a cryptographic commitment (a hash) to the next private/public key in the rotation-scheme.
[Source: chapter Pre-rotation in whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
---
title: prefix
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/prefix
md: https://weboftrust.github.io/WOT-terms/04_glossary/prefix.md
---
# prefix
A prefix that is composed of a basic Base-64 (URL safe) derivation code pre-pended to Base-64 encoding of a basic public digital signing key.
Including the derivation code in the prefix binds the derivation process along with the public key to the resultant identifier.
> An example of the prefix with a one character derivation code and a 32 byte public key encoded into a 44 character Based-64 string follows: `BDKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0`
---
title: presentation-exchange
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/presentation-exchange
md: https://weboftrust.github.io/WOT-terms/04_glossary/presentation-exchange.md
---
# presentation-exchange
An exchange that provides disclosure of one or more [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md)s between a Discloser and a Disclosee.
A presentation exchange is the process by which [authenticatable](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) information may be exchanged between two parties, namely, the [Discloser](https://weboftrust.github.io/WOT-terms/docs/glossary/discloser.md) and [Disclosee](https://weboftrust.github.io/WOT-terms/docs/glossary/disclosee.md).
Each ACDC MUST have an [Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md) and MAY have an [Issuee](https://weboftrust.github.io/WOT-terms/docs/glossary/issuee.md). The set of [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md)s so disclosed in a presentation exchange MUST be chained. This set of chained ACDCs define a [directed acyclic graph](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
---
title: pretty-good-privacy
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/pretty-good-privacy
md: https://weboftrust.github.io/WOT-terms/04_glossary/pretty-good-privacy.md
---
# pretty-good-privacy
Is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. Phil Zimmermann developed PGP in 1991.
More on [wikipedia](https://en.wikipedia.org/wiki/Pretty_Good_Privacy)
So also the often confusing [GPG](https://weboftrust.github.io/WOT-terms/docs/glossary/GPG.md) term.
---
title: primary-root-of-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/primary-root-of-trust
md: https://weboftrust.github.io/WOT-terms/04_glossary/primary-root-of-trust.md
---
# primary-root-of-trust
In KERI a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) that is cryptographically verifiable all the way to its current controlling key pair in a PKI.
The characteristic _primary_ is one-on-one related to the **entropy** used for the creation of (the seed of) the private keys.
---
title: primitive
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/primitive
md: https://weboftrust.github.io/WOT-terms/04_glossary/primitive.md
---
# primitive
a serialization of a unitary value. All Primitives in KERI must be expressed in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md).
Source: Dr. S.Smith
In general in computing a 'primitive' is the simplest type of programming language item. It may also refer to the smallest processing unit accessible by a programmer.
[Source](https://www.techopedia.com/definition/3860/primitive)
See [Cryptographic primitive](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptographic-primitive.md)
In KERI and ACDC it a serialization of a unitary value. A [cryptographic primitive](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptographic-primitive.md) is the KERI-suite sense is the serialization of a value associated with a cryptographic operation including but not limited to a digest (hash), a salt, a seed, a private key, a public key, or a signature. All primitives in KERI MUST be expressed in [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md).
---
title: privacy-washing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/privacy-washing
md: https://weboftrust.github.io/WOT-terms/04_glossary/privacy-washing.md
---
# privacy-washing
De-identification so that it provides a personal data safe harbour and could be legally acceptable forwarded.
We might need legally enforced pressure for it to be no longer acceptable that you've _un-seen_ the (re-identifiable) personal data.
"Once you see, you can't un-see".
---
title: privacy
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/privacy
md: https://weboftrust.github.io/WOT-terms/04_glossary/privacy.md
---
# privacy
Privacy is the ability of an individual or group to seclude themselves or information about themselves, and thereby express themselves selectively.
The domain of privacy partially overlaps with [security](https://en.wikipedia.org/wiki/Security), which can include the concepts of appropriate use and protection of information. Privacy may also take the form of [bodily integrity](https://en.wikipedia.org/wiki/Bodily_integrity).
More on source [Wikipedia](https://en.wikipedia.org/wiki/Privacy)
The three properties, authenticity, confidentiality, and privacy inhabit a trade space. ... One can have any two of the three (privacy, authenticity, confidentiality) at the highest level but not all three.
The trilemma insists that one must make a trade-off by prioritizing one or two properties over a third.
The ToIP [design goals](https://github.com/trustoverip/TechArch/blob/main/spec.md#61-design-goals) reflect that trade-off and provide an order of importance. The design goals indicate that one should start with high authenticity, then high confidentiality, and then as high as possible privacy, given there is no trade-off with respect to the other two.
More on [Source](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md) Samuel Smith SPAC whitepaper.
- [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md)
- [confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/confidentiality.md)
---
title: PRNG
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/PRNG
md: https://weboftrust.github.io/WOT-terms/04_glossary/PRNG.md
---
# PRNG
means "Pseudorandom Number Generator" which means that a sequence of numbers (bits, bytes...) is produced from an algorithm which looks random, but is in fact deterministic (the sequence is generated from some unknown internal state), hence pseudorandom.
Such pseudorandomness can be cryptographically secure, or not. It is cryptographically secure if nobody can reliably distinguish the output from true randomness, even if the PRNG algorithm is perfectly known (but not its internal state). A non-cryptographically secure PRNG would fool basic statistical tests but can be distinguished from true randomness by an intelligent attacker.
(Source: [https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng](https://crypto.stackexchange.com/questions/12436/what-is-the-difference-between-csprng-and-prng))
[CSPRNG](https://weboftrust.github.io/WOT-terms/docs/glossary/CSPRNG.md)
---
title: proem
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/proem
md: https://weboftrust.github.io/WOT-terms/04_glossary/proem.md
---
# proem
A "proem" is an introductory statement, preamble, or preface. It sets the stage for the content that follows, often providing context, framing the discussion, or outlining the purpose and scope of the material.
Proems are commonly found in legal, philosophical, or literary works and serve to guide the reader's understanding before delving into the main content.
---
title: promiscuous-mode
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/promiscuous-mode
md: https://weboftrust.github.io/WOT-terms/04_glossary/promiscuous-mode.md
---
# promiscuous-mode
It is the mode a [watcher](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) runs in. A watcher uses the same code as a [witness](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md). However a watcher does so "lacking standards of selection; acting without careful judgment; indiscriminate". Or "Showing little forethought or critical judgment; casual."
[Source](https://www.wordnik.com/words/promiscuous)
The function of watcher is different from a witness, however they can both use the same protocol and code, just in a distinct mode.
---
title: proof-of-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/proof-of-authority
md: https://weboftrust.github.io/WOT-terms/04_glossary/proof-of-authority.md
---
# proof-of-authority
Proof that somebody or something has certain rights or permissions. It's about _data_. Whereas [proof of authorship](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authorship.md) is about _data_ and its original creator.
A proof-of-authority provides verifiable authorizations or permissions or rights or credentials.
_Proof of authorship_ and [proof of authority](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authority.md) are integrated in [Authentic Chained Data Containers (ACDCs)](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md):
- ACDCs provide a verifiable chain of proof-of-`authorship` of the contained data
- A proof-of-`authority` may be used to provide verifiable authorizations or permissions or rights or credentials. A chained (treed) proof-of-authority enables delegation of authority and delegated authorizations. These proofs of authorship and/or authority provide provenance of an ACDC itself and by association any data that is so conveyed.
([source](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#introduction))
The data contained in an ACDC is a book written by Terlalu Bonito; the ACDC also contains anchoring digest, signed by the author at publishing date. Terlalu has sold all rights to publish the book to Liz Smiley The ownership of the book matches the current [control](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) over the book and its digital twin: the proof of authority by the chain of ACDCs.
Proof of authority (PoA) is also an [algorithm](https://en.wikipedia.org/wiki/Algorithm) used with [blockchains](https://en.wikipedia.org/wiki/Blockchain) that delivers comparatively fast transactions through a consensus mechanism based on identity as a stake.
([Source](https://en.wikipedia.org/wiki/Proof_of_authority))
This is NOT what we mean in SSI, KERI and ACDC.
---
title: proof-of-authorship
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/proof-of-authorship
md: https://weboftrust.github.io/WOT-terms/04_glossary/proof-of-authorship.md
---
# proof-of-authorship
Proof that somebody or something has originally created certain content. It's about _data_'s inception. Whereas [proof-of-authority](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authority.md) is about _rights_ attached to this data.
For example, a [signature](https://en.wikipedia.org/wiki/Signature) constitutes direct proof of [authorship](https://en.wikipedia.org/wiki/Authorship); less directly, [handwriting analysis](https://en.wikipedia.org/wiki/Handwriting_analysis) may be submitted as proof of authorship of a document.[\[21\]](https://en.wikipedia.org/wiki/Proof_\(truth\)?wprov=srpw1_0#cite_note-21) [Privileged information](https://en.wikipedia.org/wiki/Secret) in a document can serve as proof that the document's author had access to that information; such access might in turn establish the location of the author at certain time, which might then provide the author with an [alibi](https://en.wikipedia.org/wiki/Alibi).
[Source](https://en.wikipedia.org/wiki/Proof_\(truth\))
_Proof of authorship_ and [proof of authority](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authority.md) are integrated in [Authentic Chained Data Containers (ACDCs)](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) constituting an [Authentic Provenance Chain (APC)](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-provenance-chain.md):
- ACDCs provide a verifiable chain of proof-of-`authorship` of the contained data
- A proof-of-`authority` may be used to provide verifiable authorizations or permissions or rights or credentials. A chained (treed) proof-of-authority enables delegation of authority and delegated authorizations. These proofs of authorship and/or authority provide provenance of an ACDC itself and by association any data that is so conveyed.
([source](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#introduction))
The data contained in an ACDC is a book written by Terlalu Bonito; the ACDC also contains anchoring digest, signed by the author at publishing date. Terlalu has sold all rights to publish the book to Liz Smiley The ownership of the book matches the current [control](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) over the book and its digital twin: the proof of authority by the chain of ACDCs.
---
title: WebOfTrust-keria-main-docs-protocol
description: signify-keria-request-authentication-protocol--skrap-, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/protocol
md: https://weboftrust.github.io/WOT-terms/04_glossary/protocol.md
---
# WebOfTrust-keria-main-docs-protocol
The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces.
1. Boot Interface - Exposes one endpoint for Agent Worker initialization.
2. Admin Interface - The REST API for command and control operations from the Signify Client.
3. KERI Protocol Interface - CESR over HTTP endpoint for KERI protocol interactions with the rest of the world.
This separation allows for the Boot interface to be expose to internal infrastructure only (or disabled all together) while exposing the other two interfaces externally. If a KERIA instance is launched in static worker mode, meaning all agent workers are configured at start up only the Boot interface can be disabled completely.
To initiate a connection between a Signify Client and a KERIA agent, the two sides will exchange KERI AIDs with the Signify Client AID (called the "Client AID") being the delegator for the KERIA agent worker AID (called the "Agent AID"). To establish the connection the following steps are performed:
The Signify Client generates the client AID as a transferable AID with a single signing key and single rotation key and provides the signed inception event out-of-bands to the KERIA service through the Boot interface. The HTTP request must be signed by the client AID using Signify Request Authentication described below. The algorithm for generating the signing and rotation key pairs for Client AID is as follows:
1. Prepend the 128 bit random salt derivation code ('0A') plus the blank qualified base 64 character ('A') to the provided 21 character passcode
2. Stretch the passcode derivation using Argon2 to generate an Ed25519 private key from the provided "tier" and paths of `signify:controller00` and `signify:controller01` for the signing key and rotation key respectively.
3. Use the qualified base64 of the signing public key and the qualified base64 of the Blake3 digest of the rotation public key in the inception event.
The follow is an example of a Client AID generated by the SignifyPy (Python implementation) Signify Client with a passcode of `0123456789abcdefghijk`
```
{
"v": "KERI10JSON00012b_",
"t": "icp",
"d": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose", // Client AID
"s": "0",
"kt": "1",
"k": [
"DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc" // Derived from passcode as salt, kidx = 0
],
"nt": "1",
"n": [
"EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL" // Derived from passcode as salt, kidx = 1, Blake3 Hashed
],
"bt": "0",
"b": [],
"c": [],
"a": []
}
```
The KERIA service will create an Agent Worker on behalf of the new client and create the delegated, transferable Agent AID with a single signing key and single rotation key specifying the Client AID as its delegator in its inception event.
The KERIA service will return the Agent AID inception event in a signed HTTP response, signed by the Agent AID. Agent AID keys can be generated using a salt or truly random depending on the requirements of the service hosting the KERIA service.
```
{
"v": "KERI10JSON00015f_",
"t": "dip", // Delegated AID
"d": "EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei",
"i": "EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei", // Agent AID
"s": "0",
"kt": "1",
"k": [
"DMZh_y-H5C3cSbZZST-fqnsmdNTReZxIh0t2xSTOJQ8a"
],
"nt": "1",
"n": [
"EM9M2EQNCBK0MyAhVYBvR98Q0tefpvHgE-lHLs82XgqC"
],
"bt": "0",
"b": [],
"c": [],
"a": [],
"di": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose" // Delegated signing authority from Client AID
}
```
_Note that all HTTP requests against the Admin Interface must be signed by the Client AID and expect all responses to be signed by the Agent AID._
The Signify Client will approve the delegation of the client AID with an interaction event that it sends back to the KERIA service over the Admin interface.
Once these steps are complete the Signify Client can begin using the rest of the Admin interface to create AIDs, issue credentials, etc.
Document the steps for retrieving state from the Admin interface and updating.
The KERIA service supports the following key generation methods where the Signify Client generates the keys and only ever sends encrypted key material (if any) to the server.
1. Salty Keys - HDK key chain generated from a salt per aid that is encrypted and stored server.
2. Randy Keys - Randomly generated keys (signing and rotation) that are encrypted and store on the server.
3. Sandy Keys - Keys generated from a different salt for inception and each rotation.
4. Group Keys - Signify Client/KERIA Service AIDs participating in a distributed group multisig AID.
5. HSM Keys - Signify Client uses a Signify HSM Integration Module (SHIM) to manage keys and signatures.
For all key generation methods, the Signify Client creates and signs all KERI events, credentials, etc. ensuring that unencrypted private key material never leaves the client. The key generate methods are descrive in more detail in the following sections.
The Salty Key algorithm is used to create a hierarchical deterministic key chain for each AID by generating a unique random salt for each AID and stretching the salt using Argon2 with a `path` that is calculated from the AIDs index relative to all other AIDs and the key index calculated by the total number of signing and rotation keys over the lifetime of the AID.
The salt for each AID is encrypted with the X25519 encryption key generated from the passcode and stored on the server with other AID metadata, including the AID index and current key index.
The Signify Client API must accept the AID salt as an optional parameter to creating Salty Key AIDs allowing users to manage AID salts externally or to share Salts across AIDs if required.
The following Python data class represents the metadata storage for Salty Key AIDs:
```
class SaltyPrm:
"""
Salty prefix's parameters for creating new key pairs
"""
sxlt: str = '' # qualified b64 encoded AID salt
pidx: int = 0 # prefix index for this keypair sequence
kidx: int = 0 # key index for this keypair sequence
stem: str = '' # default unique path stem for salty algo
tier: str = '' # security tier for stretch index salty algo
dcode: str = '' # next digest hasing code
icodes: list = field(default_factory=list) # current signing key seed codes
ncodes: list = field(default_factory=list) # next key seed codes
transferable: bool = False
```
Document the procedure for rotating a new Salt in for a Salty Key AID.
The Randy Key algorithm allows for all signing and rotation private keys to be generated solely from entropy and encrypted with the X25519 encryption key generated from the passcode and stored on the server alongside other AID metadata.
The server stores the encrypted private key material for signing and rotation keys in separate LMBD sub-databases as indexed qualified base 64 CESR encoded Cipher representations.
The Group Key algorithm is a special key generation algorith for distributed group multisig AIDs that does not manage and keys at all. Instead this algoritm allows for the specification of an AID of one of the other three types to be the "local" participant in a distributed group multisig AID.
All signing operations must be performed on the Signify Client on behalf of the "local" AID for this Signify Client indexed based on the local AID's location in both the signing key list and the rotation key list.
The SignifyPy Signify Client defines an experimental interface for declaring external modules that can be used as Signify HSM Integration Modules to allow all key generation and event signing to occur in an external Hardware Security Module (HSM).
Two sample implementations have been defined to date, one using the Google KSM and one using a Trezure One external HSM.
The following psuedo Python class represents the current, experimental interface a SHIM has to implememnt to work with SignifyPy. It is anticipated that each Signify Client implementation defines a similar interface.
```
class Shim:
def incept(self, transferable=True):
""" Create an AID using the Google KSM for key generation and event signing.
Parameters:
transferable (bool): True means create a transferable AID which allows for key rotation
Returns:
keys (list): list of qualified base64 public signing key deriviations based on the codes passed into init
ndigs (list): list of qualified base64 digests of public rotation key derivations based on the codes
passed into init
"""
def rotate(self, ncount, transferable):
""" Rotate an AID using the Google KSM for key generation and event signing.
Parameters:
ncount (int): number of new rotation keys to generate
transferable (bool): True means create a transferable AID which allows for key rotation
Returns:
keys (list): list of qualified base64 public signing key deriviations based on the codes passed into init
ndigs (list): list of qualified base64 digests of public rotation key derivations based on the codes
passed into init
"""
def sign(self, ser, indexed=True, indices=None, ondices=None, **_):
"""
Parameters:
ser (bytes): content to be signed
indexed (bool): True means generated indexed signatures
indices (list): Optional list of indices to use when generating indexed signatures
ondices (list): Optional list of rotation indices to use when generating dual indexed signatures
**_: Placeholder
Returns:
sigs (list): list of qualified base64 signatures over the based in ser
"""
```
To perform a passcode rotation, the Signify Client requires both old and new passcodes and must perform the following steps:
1. Encrypted the old passcode with X25519 key generated from the new passcode.
2. Perform a partial rotation of the Client AID as described below.
3. Decrypt all salts with X25519 key from old passcode for Salty Keys, validate them against current public keys, encrypt with X25519 key from new passcode
4. Decrypt all keys with X25519 key from old passcode for Randy Keys, validate them against current public keys, encrypt with X25519 key from new passcode
5. Send all rotation event and all recrypted material in a POST request to the agent on `/agent/`
To provide post-quantum secure passcode recovery, a passcode recovery must be accompanied by partial rotation of the Client AID. This partial rotation is possible because the user will have to provide both old and new passcodes to initiate the process.
The partial rotation of the Client AID is accomplished by using the old passcode to regenerate the the prior rotation key pair called `R0` from the latest establishment event. In addition, two new key pairs are generated from the new passocde, one used for signing authority (S0) and one used for rotation authority (R1) in the new rotation event.
The public key for `S0` is used as the first signing key in the new rotation event; it is giving a fractionally weighted threshold of "1". The public key for `R0` is used as the second signing key in the new rotation event; it is giving a fractionally weighted threshold of "0". A Blake3 has is created of the public key for `R1` and is used as the next rotation key commitment.
The rotation event is signed with the private keys of both `S0` and `R0`. An example of a partial rotation event of the Client AID from above follows with its signatures:
```
{
"v": "KERI10JSON000195_",
"t": "rot",
"d": "EGTAY6x1tTbOO27LCy3poh5iW0Oa2Cq1s7wsVnj152Zi",
"i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"s": "1",
"p": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"kt": [
"1", // Threshold for key derived from NEW passcode, has full signing authority
"0" // Threshold for key derived from OLD passcode, no signing authority
],
"k": [
"DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc", // Derived from NEW passcode as salt, kidx = 0
"DHMAZEksiqGxlNKnm0pSAyMRPK1ZKyBfGV8q_B9r6pLs" // Derived from OLD passcode as salt, kidx = 1 (matches previous rotation key)
],
"nt": "1",
"n": [
"EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL" // Derived from NEW passcode as salt, kidx = 1, Blake3 Hashed
],
"bt": "0",
"br": [],
"ba": [],
"a": []
}
```
With the following attached signatures:
```
[
"AADuzJ4zU8MkLBPP8Os9UPbTvNqoQ4YDImNkTjfknWgJW25V6EmwZ59PXas0zKhxtp_dOhvkPqtqIhgarOFwt7sC",
"2AABAACRZGDB7s4hmYnt7vTYGWCawhnqHndWUy_rtR_L8mfNmrJ4N5S05wAZ6w5RoL68h1HjIzO7ZuiF30XBz1cC6eUA"
]
```
The first signature satisfies the current signing threshold and has only one index, 0 for signing key index. The second signature satifies the prior rotation threshold and thus uses dual index code to specify a current signing index of 1 and a prior signing index of 0.
The following steps are followed to accept the passcode rotation:
1. Verify and accept the Client AID rotation
2. Verify the signature on the request against the NEW signing key of the Client AID
3. Save encrypted old passcode
4. Update all Salty Key encrypted salts
5. Update all Randy Key encrypted keys
6. Delete encrypted old passcode
When each Agent Worker is loaded it will check for a saved old passcode to detect an aborted passcode rotation. If a saved encrypted old passcode is found the Agent Worker will notify the client in the response to the state call that a passcode rotation recovery is needed and lock out all other operations until it is completed successfully.
To perform a passcode rotation recovery, the Signify Client requires only the new passcode and must perform the following steps:
1. Retrieve the encrypted old passcode and decrypt it with X25519 key generated from the new passcode.
2. Perform a revised partial rotation of the Client AID where you rotate out to a new next key not new signing key.
3. Attempt to decrypt all salts with the X25519 keys from both the old and new passcode for Salty Keys
4. For any salt still encrypted with the old passcode, encrypt with X25519 key from new passcode
5. Attempt to decrypt all keys with the X25519 keys from both the old and new passcode for Randy Keys
6. Validate them against current public keys and for any key still encrypted with the old passcode, encrypt with X25519 key from new passcode
7. Send all rotation event and all recrypted material in a POST request to the agent on `/agent/`
Signify clients must sign all requests to the KERIA Admin Interface using the latest signing key of the Client AID and must expect all responses from the KERIA service be signed by the latest signing key of the Agent AID. Both request and response signing rely on the same set of HTTP headers to accomplish request/response signing.
Document `Signify-Resource` and `Signify-Timestamp` headers here.
Document the `Signature-Input` header here with link to [https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html](https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html)
Document the signing method and `Signature` header.
---
title: provenance
description: Defintion
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/provenance
md: https://weboftrust.github.io/WOT-terms/04_glossary/provenance.md
---
# provenance
From Wikipedia ([Source](https://en.wikipedia.org/wiki/Provenance)):
Provenance (from the [French](https://en.wikipedia.org/wiki/French_language) provenir, 'to come from/forth') is the chronology of the ownership, custody or location of a historical object. The term was originally mostly used in relation to [works of art](https://en.wikipedia.org/wiki/Works_of_art) but is now used in similar senses in a wide range of fields, including [archaeology](https://en.wikipedia.org/wiki/Archaeology), [paleontology](https://en.wikipedia.org/wiki/Paleontology), [archives](https://en.wikipedia.org/wiki/Archive), [manuscripts](https://en.wikipedia.org/wiki/Manuscript), printed books, the [circular economy](https://en.wikipedia.org/wiki/Circular_economy), and science and computing.
The primary purpose of tracing the provenance of an object or entity is normally to provide contextual and circumstantial evidence for its original production or discovery, by establishing, as far as practicable, its later history, especially the sequences of its formal ownership, custody and places of storage. The practice has a particular value in helping [authenticate](https://en.wikipedia.org/wiki/Authentication) objects. Comparative techniques, expert opinions and the results of scientific tests may also be used to these ends, but establishing provenance is essentially a matter of [documentation](https://en.wikipedia.org/wiki/Document). The term dates to the 1780s in English. Provenance is conceptually comparable to the legal term [chain of custody](https://en.wikipedia.org/wiki/Chain_of_custody).
([Source](https://en.wikipedia.org/wiki/Provenance))
[Authentic chained data containers (ACDC)](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) establish provenance in two coherent ways:
- historic documentation of cryptographic verifiable key states and data consistency (result: secure attribution)
- historic documentation of [credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/credential.md) (result: attested [veracity](https://weboftrust.github.io/WOT-terms/docs/glossary/veracity.md))
(_@henkvancann_)
---
title: provenanced
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/provenanced
md: https://weboftrust.github.io/WOT-terms/04_glossary/provenanced.md
---
# provenanced
The act of verifying [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) or quality of documented history or origin of something.
Focus on authenticity. See [provenance](https://weboftrust.github.io/WOT-terms/docs/glossary/provenance.md).
---
title: pseudo-random-number
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/pseudo-random-number
md: https://weboftrust.github.io/WOT-terms/04_glossary/pseudo-random-number.md
---
# pseudo-random-number
A (set of) value(s) or element(s) that is statistically random, but it is derived from a known starting point and is typically repeated over and over.
Pseudo-random numbers provide necessary values for processes that require randomness, such as creating test signals or for synchronizing sending and receiving devices in a spread spectrum transmission.
It is called "pseudo" random, **because the algorithm can repeat the sequence**, and the numbers are thus not entirely random.
[Source](https://www.pcmag.com/encyclopedia/term/pseudo-random-numbers)
---
title: PTEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/PTEL
md: https://weboftrust.github.io/WOT-terms/04_glossary/PTEL.md
---
# PTEL
[Public transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/public-transaction-event-log.md)
---
title: public-key-infrastructure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/public-key-infrastructure
md: https://weboftrust.github.io/WOT-terms/04_glossary/public-key-infrastructure.md
---
# public-key-infrastructure
Is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.
More on [Wikipedia](https://en.wikipedia.org/wiki/Public_key_infrastructure)
---
title: public-transaction-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/public-transaction-event-log
md: https://weboftrust.github.io/WOT-terms/04_glossary/public-transaction-event-log.md
---
# public-transaction-event-log
is a public hash-linked data structure of transactions that can be used to track state anchored to a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md).
A Public Verifiable Credential Registry can be represented in several [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/TEL.md)s to establish issuance or revocation state of a [Verifiable Credential](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md) (VC).
The [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md) is used to establish control authority over the keys used to commit to the events of the TEL and sign the VC. The events of the TEL are used to establish the issuance or revocation state of the VCs issued by the controller of the identifier represented by the KEL.
[Source: pfeairheller](https://github.com/WebOfTrust/ietf-ptel/blob/main/draft-pfeairheller-ptel.md)
---
title: public-verifiable-credential-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/public-verifiable-credential-registry
md: https://weboftrust.github.io/WOT-terms/04_glossary/public-verifiable-credential-registry.md
---
# public-verifiable-credential-registry
is a form of a [Verifiable Data Registry](https://github.com/trustoverip/toip/wiki/credential-registry) that tracks the issuance/revocation state of credentials issued by the controller of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md). Two types of TELs will be used for this purpose: [management TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/management-transaction-event-log.md) and [VC TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/virtual-credential-transaction-event-log.md).
The first type of [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) is the _management TEL_ and will signal the creation of the Registry and track the list of Registrars that will act as [Backers](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md) for the individual TELs for each [VC](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md). The second type of TEL is the _VC TEL_, which will track the issued or revoked state of each VC and will contain a reference to its corresponding management TEL.
| TBW | prio2
---
title: QAR
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/QAR
md: https://weboftrust.github.io/WOT-terms/04_glossary/QAR.md
---
# QAR
[QVI Authorized Representative](https://weboftrust.github.io/WOT-terms/docs/glossary/qvi-authorized-representative.md)
---
title: qry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/qry
md: https://weboftrust.github.io/WOT-terms/04_glossary/qry.md
---
# qry
qry = query
---
title: quadlet
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/quadlet
md: https://weboftrust.github.io/WOT-terms/04_glossary/quadlet.md
---
# quadlet
a group of 4 characters in the T domain and equivalently in triplets of 3 bytes each in the B domain used to define variable size.
Source: Dr. S. Smith
---
title: qualified-vlei-issuer-vlei-credential-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/qualified-vlei-issuer-vlei-credential-governance-framework
md: https://weboftrust.github.io/WOT-terms/04_glossary/qualified-vlei-issuer-vlei-credential-governance-framework.md
---
# qualified-vlei-issuer-vlei-credential-governance-framework
A _document_ that details the requirements to enable this Credential to be **issued by** [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md) **to** [Qualified vLEI Issuers](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified-vlei-issuer.md) which allows the Qualified vLEI Issuers to issue, verify and revoke [Legal Entity vLEI Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity-vlei-credential-governance-framework.md), [Legal Entity Official Organizational Role vLEI Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity-official-organizational-role-vlei-credential-governance-framework.md), and [Legal Entity Engagement Context Role vLEI Credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md).
---
title: qualified-vlei-issuer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/qualified-vlei-issuer
md: https://weboftrust.github.io/WOT-terms/04_glossary/qualified-vlei-issuer.md
---
# qualified-vlei-issuer
The contracting party to the vLEI Issuer Qualification Agreement that has been qualified by GLEIF as a Qualified vLEI Issuer.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
Is an authoritative role at the GLEIF organization that is mandated to issue [vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) credentials to others.
---
title: qualified
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/qualified
md: https://weboftrust.github.io/WOT-terms/04_glossary/qualified.md
---
# qualified
When qualified, a cryptographic primitive includes a prepended derivation code (as a [proem](https://weboftrust.github.io/WOT-terms/docs/glossary/proem.md)), that indicates the cryptographic algorithm or suite used for that derivation.
This simplifies and compactifies the essential information needed to use that cryptographic primitive. All cryptographic primitives expressed in either text or binary CESR are qualified by definition [CESR-ID](https://weboftrust.github.io/ietf-keri/draft-ssmith-keri.html#CESR-ID). Qualification is an essential property of CESR [\[CESR-ID\](https://weboftrust.github.io/ietf-keri/draft-ssmith-keri.html#CESR-ID)](https://weboftrust.github.io/ietf-keri/draft-ssmith-keri.html#section-2-2.4.1)
[Sam Smith, IETF-keri](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: qvi-authorized-representative
description: A designated representative of a QVI authorized, to conduct QVI operations with GLEIF and Legal Entities. Also referring to a person in the role of a QAR.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/qvi-authorized-representative
md: https://weboftrust.github.io/WOT-terms/04_glossary/qvi-authorized-representative.md
---
# qvi-authorized-representative
A designated representative of a [QVI](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md) authorized, to conduct QVI operations with GLEIF and [Legal Entities](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md). Also referring to a person in the role of a QAR.
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: QVI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/QVI
md: https://weboftrust.github.io/WOT-terms/04_glossary/QVI.md
---
# QVI
[Qualified vLEI issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/qualified-vlei-issuer.md)
---
title: race-condition
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/race-condition
md: https://weboftrust.github.io/WOT-terms/04_glossary/race-condition.md
---
# race-condition
A race condition or race hazard is the condition of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.
[Source](https://en.wikipedia.org/wiki/Race_condition).
| TBW prio 2 |
---
title: rainbow-table-attack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rainbow-table-attack
md: https://weboftrust.github.io/WOT-terms/04_glossary/rainbow-table-attack.md
---
# rainbow-table-attack
A rainbow table attack is a password-cracking method that uses a special table (a “rainbow table”) to crack the password hashes in a database.
Applications don’t store passwords in plaintext, but instead encrypt passwords using [hashes](https://weboftrust.github.io/WOT-terms/docs/glossary/content-addressable-hash.md). After the user enters their password to login, it is converted to hashes, and the result is compared with the stored hashes on the server to look for a match. If they match, the user is [authenticated](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) and able to log in.
More on [source](https://www.beyondidentity.com/glossary/rainbow-table-attack)
---
title: rct
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rct
md: https://weboftrust.github.io/WOT-terms/04_glossary/rct.md
---
# rct
rct = receipt
---
title: read-update-nullify
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/read-update-nullify
md: https://weboftrust.github.io/WOT-terms/04_glossary/read-update-nullify.md
---
# read-update-nullify
Read, update, nullify are a set of actions you (or a server) can take on data. "Read" means to view it, "update" means to change it, and "nullify" means to invalidate it, but not "Delete" it. Mind you, there's also no "Create".
- [Run off the CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/run-off-the-crud.md)
- [BADA](https://weboftrust.github.io/WOT-terms/docs/glossary/BADA.md)
---
title: receipt-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/receipt-log
md: https://weboftrust.github.io/WOT-terms/04_glossary/receipt-log.md
---
# receipt-log
ordered record of all key event receipts for a given set of witnesses.
---
title: receipt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/receipt
md: https://weboftrust.github.io/WOT-terms/04_glossary/receipt.md
---
# receipt
event message or reference with one or more witness signatures.
See Also:
[key event receipt](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt.md)
---
title: reconciliation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/reconciliation
md: https://weboftrust.github.io/WOT-terms/04_glossary/reconciliation.md
---
# reconciliation
Reconciliation is the process in which you decide to accept a fork of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) or not.
Source: Samuel Smith, Zoom meeting Jan 2 2024.
- You might not have to abandon your identifier after key compromise
- Only few people will see your reconciliation or clean up
---
title: redundant-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/redundant-credential
md: https://weboftrust.github.io/WOT-terms/04_glossary/redundant-credential.md
---
# redundant-credential
Multiple credentials issued by the same issuer (e.g. a [QVI](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md)). They do not have anything to do with each other. They are independently valid.
If a QVI issues two instances of the same credential, and is able to only revoke one. This is a governance issue and this behaviour of a QVI is not recommended. But it can be done this way (issue two revoke one) and it leaves the outside world with one other valid credential.
---
title: registrar
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/registrar
md: https://weboftrust.github.io/WOT-terms/04_glossary/registrar.md
---
# registrar
identifiers that serve as backers for each [transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) (TEL) under its provenance. This list of Registrars can be rotated with events specific to a certain type of TEL. In this way, a Registrar is analogous to a Backer in KERI KELs and Registrar lists are analogous to Backer lists in KERI KELs.
---
title: registration-interaction
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/registration-interaction
md: https://weboftrust.github.io/WOT-terms/04_glossary/registration-interaction.md
---
# registration-interaction
Setup/Registration interaction, new AID and authorization to establish access control. You present a ([vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md)) credential. You don't want that captured and misused. Narrowing the scope to a certain role (e.g. Document Submitter) is a pre-registration via [delegatable](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md) authority.
The [Credential](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md) is like a bearer token. Does it matter if the credential was delivered by the [issuee](https://weboftrust.github.io/WOT-terms/docs/glossary/issuee.md)? The token is [proof of the authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/proof-of-authority.md), but does the delivery require the issuee signature? Depends on the context. If it is an idempotent process resubmission has no effect.
Source: Samuel Smith / Daniel Hardman / Lance Byrd - Zoom meeting KERI Suite Jan 16 2024; discussion minute 30-60 min
is important, depending on the context or governance model the issuance itself needs / should / could be signed.
[Access-controlled interaction](https://weboftrust.github.io/WOT-terms/docs/glossary/access-controlled-interaction.md)
---
title: verifiable-data-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/registry
md: https://weboftrust.github.io/WOT-terms/04_glossary/registry.md
---
# verifiable-data-registry
A role a system might perform by mediating issuance and verification of ACDCs. See [verifiable data registry](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-data-registries).
Source: Dr. S. Smith
a [Verifiable Data Structure](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-data-structure.md) that has actual content.
It contains either a log of signed statements or a cryptographic commitment ([digest](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md)) to those statements (via a Merkle tree or hash chained data structure).
---
title: replay-attack
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/replay-attack
md: https://weboftrust.github.io/WOT-terms/04_glossary/replay-attack.md
---
# replay-attack
A _replay attack_ occurs when a cybercriminal eavesdrops on a secure network communication, intercepts it, and then fraudulently delays or resends it to misdirect the receiver into doing what the hacker wants.
The added danger of replay attacks is that a hacker doesn't even need advanced skills to decrypt a message after capturing it from the network. The attack could be successful simply by resending the whole thing.
More on **how it works** and **stopping** replay attacks at [source](https://www.kaspersky.com/resource-center/definitions/replay-attack)
---
title: repo
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/repo
md: https://weboftrust.github.io/WOT-terms/04_glossary/repo.md
---
# repo
Software is our line of work. In this, 'repo' is the short hand for 'Repository', mostly referring to a software repo(sitory) on [Github.com](https://github.com), Gitlab ([https://gitlab.com](https://gitlab.com)) or other software repository hosting services.
A software repository, is a storage location for [software packages](https://en.wikipedia.org/wiki/Package_format). Often a table of contents is also stored, along with metadata. A software repository is typically managed by [source control](https://en.wikipedia.org/wiki/Version_control) or repository managers. [Package managers](https://en.wikipedia.org/wiki/Package_manager) allow automatically installing and updating repositories (sometimes called "packages").
[software repository](https://en.wikipedia.org/wiki/Software_repository)
---
title: reputation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/reputation
md: https://weboftrust.github.io/WOT-terms/04_glossary/reputation.md
---
# reputation
Consistent behaviour over time on the basis of which anyone else makes near-future decisions.
Source: Samuel Smith at IIW37.
---
title: reputational-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/reputational-trust
md: https://weboftrust.github.io/WOT-terms/04_glossary/reputational-trust.md
---
# reputational-trust
Established by a trusted party offering [Identity Assurance](https://weboftrust.github.io/WOT-terms/docs/glossary/identity-assurance.md).
---
title: reserve-rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/reserve-rotation
md: https://weboftrust.github.io/WOT-terms/04_glossary/reserve-rotation.md
---
# reserve-rotation
One important use case for [partial rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-rotation.md) is to enable pre-rotated key pairs designated in one [establishment event](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md) **to be held in reserve and not exposed** at the next (immediately subsequent) establishment event.
Source [IETF-KERI draft 2022](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md) by Samual Smith.
---
title: rev
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rev
md: https://weboftrust.github.io/WOT-terms/04_glossary/rev.md
---
# rev
rev = vc revoke, verifiable credential revocation
---
title: revocation-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/revocation-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/revocation-event.md
---
# revocation-event
An event that revokes [control authority](https://weboftrust.github.io/WOT-terms/docs/glossary/control-authority.md) over an [identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/identifier.md). From that point in time the authoritative key-pairs at hand are not valid anymore.
The time stamp of a revocation is useful but not for security purposes, it can be gamed by an attacker. KERI should be fitted in a way so that it's _not possible_ to rewrite history. The tool we have is the ordering of the events in a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md).
[Revocation](https://weboftrust.github.io/WOT-terms/docs/glossary/revocation.md)
A temporary revocation of a grant or privilege is called a suspension. We don't have this type of state or event in KERI.
---
title: revocation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/revocation
md: https://weboftrust.github.io/WOT-terms/04_glossary/revocation.md
---
# revocation
Revocation is the act of [recall](https://en.wiktionary.org/wiki/recall) or [annulment](https://en.wikipedia.org/wiki/Annulment). It is the cancelling of an act, the recalling of a grant or privilege, or the making [void](https://en.wikipedia.org/wiki/Void_\(law\)) of some [deed](https://en.wikipedia.org/wiki/Deed) previously existing.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Revocation)
The term revocation has two completely different meanings in the identity space. In key management one may speak of revoking keys. With statement issuance, authorization issuance, or credential issuance, one may speak of revoking an authorization statement, a token, or a credential.
This becomes confusing when the act of revoking keys also implicitly revokes the [authorization](https://weboftrust.github.io/WOT-terms/docs/glossary/authorization.md) of statements signed with those keys. Any statement may be effectively authorized by virtue of the attached signature(s) made with a set of [authoritative](https://weboftrust.github.io/WOT-terms/docs/glossary/authoritative.md) keys. The statement itself may be authorizing some other function in the system. So, the verification of the signature on an authorizing statement is essential to determining the authoritativeness of the associated authorized function. To clarify when an authorization is conveyed via a signed statement, the signature acts to authorize the statement.
KERI terminology usually avoids confusion between [rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md) and revocation because a key rotation operation is the equivalent of a key revocation operation **followed by a key replacement operation**. So one operation, rotate, is implemented instead of two operations (revoke and replace).
**A bare key revocation is indicated by replacement with a null key.** So only one operation is needed, that is, rotate where a special case of rotation is to rotate to a null key.
[Revocation event](https://weboftrust.github.io/WOT-terms/docs/glossary/revocation-event.md)
---
title: ricardian-contract
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ricardian-contract
md: https://weboftrust.github.io/WOT-terms/04_glossary/ricardian-contract.md
---
# ricardian-contract
The Ricardian contract, as invented by Ian Grigg in 1996, is a method of recording a document as a [contract](https://en.wikipedia.org/wiki/Contract) at law, and linking it securely to other systems, such as accounting, for the contract as an issuance of value.
It is robust through use of identification by [cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function), transparent through use of readable text for legal prose and efficient through [markup language](https://en.wikipedia.org/wiki/Markup_language) to extract essential information.
More at [source Wikipedia](https://en.wikipedia.org/wiki/Ricardian_contract)
Ricardian contracts provide a human readable twin to the seals and and signatures (commitments) in binary format in [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md).
---
title: RID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/RID
md: https://weboftrust.github.io/WOT-terms/04_glossary/RID.md
---
# RID
[Root autonomic identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/root-autonomic-identifier.md)
---
title: root-autonomic-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/root-autonomic-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/root-autonomic-identifier.md
---
# root-autonomic-identifier
An entity may provide the [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) for some ecosystem (with delegation )via its root [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md). Let’s call this the _RID_ for "root AID". The RID must be protected using the highest level of [security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md) in its [key management](https://weboftrust.github.io/WOT-terms/docs/glossary/key-management.md).
Although through the use of a [multi-valent](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-valent.md) key management infrastructure, the entity can employ extreme protection of the RID while still enabling more performant key management infrastructure for its operations.
Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: secondary-root-of-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/root-of-trust
md: https://weboftrust.github.io/WOT-terms/04_glossary/root-of-trust.md
---
# secondary-root-of-trust
In KERI its a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) that, for its secure attribution, depends on another verifiable data structure (VDS) which MUST be a [primary root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/primary-root-of-trust.md).
By its nature and cryptographic anchoring via [seals](https://weboftrust.github.io/WOT-terms/docs/glossary/seal.md) to a primary root-of-trust, a secondary root-of-trust still has a high level of trustability and can be automatically verified.
---
title: rot
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rot
md: https://weboftrust.github.io/WOT-terms/04_glossary/rot.md
---
# rot
[JSON](https://weboftrust.github.io/WOT-terms/docs/glossary/JSON.md) field name (attribute) for Rotation Event; its content (value) contains a hash pointer. All [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) events are anchored in a [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) in either ixn ([interaction](https://weboftrust.github.io/WOT-terms/docs/glossary/interaction-event.md)) or [rot](https://weboftrust.github.io/WOT-terms/docs/glossary/rot.md) ([rotation event](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md)s). This is the foundation enabling a verifiable credential protocol to be built on top of KERI.
[Source](https://kentbull.com/2023/03/09/keri-tutorial-series-treasure-hunting-in-abydos-issuing-and-verifying-a-credential-acdc/) Kent Bull 2023
[ixn](https://weboftrust.github.io/WOT-terms/docs/glossary/ixn.md)
---
title: rotation-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rotation-authority
md: https://weboftrust.github.io/WOT-terms/04_glossary/rotation-authority.md
---
# rotation-authority
The (exclusive) right to rotate the authoritative key pair and establish changed control authority.
The original controller of an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md) can hold exclusive rotation authority. Because control authority is split between two key sets, the first for [signing authority](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-authority.md) and the second ([pre-rotated](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-rotation.md)) for rotation authority, the associated thresholds and key list can be structured in such a way that a designated [custodial agent](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-agent.md) can hold signing authority while the original controller can hold exclusive rotation authority.
---
title: rotation-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rotation-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/rotation-event.md
---
# rotation-event
an Establishment Event that provides the information needed to change the Key state, which includes a change to the set of [authoritative](https://weboftrust.github.io/WOT-terms/docs/glossary/authoritative.md) keypairs for an AID.
Source: Dr. S.Smith
An [establishment event](https://weboftrust.github.io/WOT-terms/docs/glossary/establishment-event.md) representing a transfer of root control authority of an identifier from the current set of controlling keys to new set committed to in the prior establishment event (inception or rotation) as the pre-rotated key pair set.
Source [KERI Whitepaper Section 7.21 page 46](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
This event provides the information needed to change the key-state including a change to the set of [authoritative](https://weboftrust.github.io/WOT-terms/docs/glossary/authoritative.md) keypairs for an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md).
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
We start with a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) in public/private key-pair that is bound to an identifier derived from the key-pair. From this key-pair and then we can rotate controlling authority to other key-pairs with signed rotation messages (events). These rotation messages are witnessed by witnesses designated in the inception event and any subsequent rotation events. Upon completion of successful witnessing a receipt message is sent back to the identity controller performing the rotation and the controller keeps track of these receipts in a [key event receipt log](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md).
The infrastructure needed to keep track of these key events including inception events, rotation events, and non-establishment events is key event receipt infrastructure, thus the acronym "KERI": [Key Event Receipt Infrastructure](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md).\\
_(SamASmith)_
---
title: rotation
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rotation
md: https://weboftrust.github.io/WOT-terms/04_glossary/rotation.md
---
# rotation
The operation of revoking and replacing the set of [authoritative](https://weboftrust.github.io/WOT-terms/docs/glossary/authoritative.md) [key pairs](https://weboftrust.github.io/WOT-terms/docs/glossary/key-pair.md) for an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md). This operation is made verifiable and [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) evident upon acceptance as a rotation event that is appended to the AID's [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/KEL.md).
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: rpy
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rpy
md: https://weboftrust.github.io/WOT-terms/04_glossary/rpy.md
---
# rpy
rpy = reply
---
title: rules
description: a top-level field map within an ACDC that provides a legal language as a Ricardian Contract, which is both human and machine-readable and referenceable by a cryptographic digest.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/rules
md: https://weboftrust.github.io/WOT-terms/04_glossary/rules.md
---
# rules
a top-level field map within an ACDC that provides a legal language as a [Ricardian Contract](https://en.wikipedia.org/wiki/Ricardian_contract), which is both human and machine-readable and referenceable by a cryptographic digest.
Source: Dr. S. Smith
---
title: run-off-the-crud
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/run-off-the-crud
md: https://weboftrust.github.io/WOT-terms/04_glossary/run-off-the-crud.md
---
# run-off-the-crud
_RUN off the [CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/CRUD.md)_ is an alternative to the traditional [CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/CRUD.md) approach to defining basic operations on resources in data management systems (e.g., databases, APIs). RUN stands for Read, Update, Nullify and bears a nuanced approach to deletion.
Why is it preferred ('run off') over the CRUD (Create, Update, Delete)?
Consider the need to protect '_authentic data_' in a decentralized environment.
In a decentralized control model, the data always originates from a controller (aka client). The data created (sourced) by the controller follows the principle of '_Non-Interactive Replay Monotonicity_' to be able to protect the data from a replay (events are changed) or a deletion (some events are deleted) attacks. That is to say, the data (or events comprising it) is never deleted, it's rather always added to via updates. Each update, therefore, forms a verifiable, continuous log ( e.g. by providing growing sequence number, date timestamp, etc for each update). To enable invalidation of data, a special update, called Nullify, is used.
The client, therefore, updates the server (it's peer or peers), which just maintains the log following certain rules (see [BADA](https://weboftrust.github.io/WOT-terms/docs/glossary/best-available-data-acceptance-mechanism.md) - Best Available Data Acceptance).
To summarise, the server can only Read the log, add Updates to it, including Nullifying ones. So _no_ Create or Delete.
---
title: RUN
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/RUN
md: https://weboftrust.github.io/WOT-terms/04_glossary/RUN.md
---
# RUN
The acronym for the new peer-to-peer end-verifiable monotonic update policy is RUN (**Read, Update, Nullify**).
RUN as opposed to [CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/CRUD.md) which is the traditional client-server database update policy.
We [RUN off the CRUD](https://weboftrust.github.io/WOT-terms/docs/glossary/run-off-the-crud.md), which means that because the source of truth for each data item is a decentralized controller Peer, a given database hosted by any Peer does not create records in the traditional sense of a server creating records for a client.
---
title: SAD
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/SAD
md: https://weboftrust.github.io/WOT-terms/04_glossary/SAD.md
---
# SAD
[Self addressing data](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-data.md)
---
title: SAID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/SAID
md: https://weboftrust.github.io/WOT-terms/04_glossary/SAID.md
---
# SAID
[Self-addressing identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md)
---
title: sally
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/sally
md: https://weboftrust.github.io/WOT-terms/04_glossary/sally.md
---
# sally
is an implementation of a verification service and acting as a reporting server. It is purpose-built software for the vLEI ecosystem to allow participants in the vLEI ecosystem present credentials, so the [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md) Reporting API can show what [vLEIs](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) are; issued to [Legal Entities](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md).
The Sally [vLEI](https://weboftrust.github.io/WOT-terms/docs/glossary/vLEI.md) Audit Reporting Agent _receives presentations of credentials_ and notices of [revocation](https://weboftrust.github.io/WOT-terms/docs/glossary/revocation-event.md), verifies the structure and cryptographic integrity of the credential or revocation event and performs a POST to the configured webhook [URL](https://weboftrust.github.io/WOT-terms/docs/glossary/URL.md)
[Source](https://github.com/GLEIF-IT/sally)
---
title: salt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/salt
md: https://weboftrust.github.io/WOT-terms/04_glossary/salt.md
---
# salt
random data fed as an additional input to a one-way function that hashes data.
Source: Dr. S. Smith
In [cryptography](https://en.wikipedia.org/wiki/Cryptography), a salt is [random](https://en.wikipedia.org/wiki/Random_Number_Generator) data that is used as an additional input to a [one-way function](https://en.wikipedia.org/wiki/One-way_function) that [hashes](https://en.wikipedia.org/wiki/Cryptographic_hash_function) [data](https://en.wikipedia.org/wiki/Data_\(computing\)), a [password](https://en.wikipedia.org/wiki/Password) or [passphrase](https://en.wikipedia.org/wiki/Passphrase).
Salts are used to safeguard passwords in storage. Historically, only a cryptographic hash function of the password was stored on a system, but over time, additional safeguards were developed to protect against duplicate or common passwords being identifiable (as their hashes are identical).[\[2\]](https://en.wikipedia.org/wiki/Salt_\(cryptography\)#cite_note-2) Salting is one such protection.
[Wikipedia](https://en.wikipedia.org/wiki/Salt_\(cryptography\))
---
title: salter
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/salter
md: https://weboftrust.github.io/WOT-terms/04_glossary/salter.md
---
# salter
A primitive that represents a [seed](https://weboftrust.github.io/WOT-terms/docs/glossary/seed.md). It has the ability to generate new [Signer](https://weboftrust.github.io/WOT-terms/docs/glossary/signer.md)s.
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: salty-nonce-blinding-factor
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/salty-nonce-blinding-factor
md: https://weboftrust.github.io/WOT-terms/04_glossary/salty-nonce-blinding-factor.md
---
# salty-nonce-blinding-factor
For ease of sharing a secret and hiding information with this secret of Blindable State TELs we use a Salty Nonce Blinding Factor. You’d like to hide the state of certain credentials to some verifiers in the future, while keeping the state verifiable for others.
A way to share the key to blind/unblind the state of a TEL is
- [HTOP, HMAC-Based One-Time Password](https://datatracker.ietf.org/doc/html/rfc6238)
- [Time-Based One-Time Password](https://datatracker.ietf.org/doc/html/rfc6238)
- HDKM, Hierarchical Deterministic Key Management, based on a shared master key you could split off subkeys in a predictable manner.
The blinding is performed by the issuer, the issuee could request the blinding.
I don’t want my employment states shared in the future with former possible employers.
[Blindable State TEL](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#blindable-state-tel)
---
title: SATP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/SATP
md: https://weboftrust.github.io/WOT-terms/04_glossary/SATP.md
---
# SATP
[Secure asset transfer protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/secure-asset-transfer-protocol.md)
---
title: schema-namespace-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/schema-namespace-registry
md: https://weboftrust.github.io/WOT-terms/04_glossary/schema-namespace-registry.md
---
# schema-namespace-registry
a centrally managed [schema registry](https://weboftrust.github.io/WOT-terms/docs/glossary/schema-registry.md) where corporations or individuals reserve schemas within a specific [namespace](https://weboftrust.github.io/WOT-terms/docs/glossary/namespace.md) in order to have an interoperable schema that is labeled with a corporation-specific or individual-specific namespace.
[Graphs](https://weboftrust.github.io/WOT-terms/docs/glossary/directed-acyclic-graph.md) in ACDC have decentralised the old-school schema registry, so it's [interoperable](https://weboftrust.github.io/WOT-terms/docs/glossary/interoperability.md) by design.
---
title: schema-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/schema-registry
md: https://weboftrust.github.io/WOT-terms/04_glossary/schema-registry.md
---
# schema-registry
Central [registry](https://weboftrust.github.io/WOT-terms/docs/glossary/registry.md) for credential schemas based on namespaces.
ACDCs and SAIDS **eliminated the need** for a centrally controlled namespace registry for credential schemas.
From our vocabulary that contains the term "[Public verifiable credential registry](https://weboftrust.github.io/WOT-terms/docs/glossary/public-verifiable-credential-registry.md)" there's follow-up on ToIP definitions like | TBW |
[Syntio](https://www.syntio.net/en/labs-musings/schema-registry-comparison/) comparison of (old-school?) centralized schema registries.
This source has conceptual explanations in diagrams like the one below and code examples. However, **be aware that ACDC solves this in a different way** with [KERI-based verifiable data structures](https://weboftrust.github.io/WOT-terms/docs/glossary/VDS.md) and [graph fragments](https://weboftrust.github.io/WOT-terms/docs/glossary/graph-fragment.md).
---
title: schema
description: the SAID of a JSON schema that is used to issue and verify an ACDC.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/schema
md: https://weboftrust.github.io/WOT-terms/04_glossary/schema.md
---
# schema
the [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/said.md) of a JSON schema that is used to issue and verify an ACDC.
Source: Dr. S.Smith
---
title: SCID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/SCID
md: https://weboftrust.github.io/WOT-terms/04_glossary/SCID.md
---
# SCID
[Self-certifying identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-certifying-identifier.md)
---
title: seal
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/seal
md: https://weboftrust.github.io/WOT-terms/04_glossary/seal.md
---
# seal
a seal is a cryptographic commitment in the form of a cryptographic digest or hash tree root (Merkle root) that anchors arbitrary data or a tree of hashes of arbitrary data to a particular event in the key event sequence.
Source: Dr. S. Smith
A cryptographic commitment in the form of a cryptographic digest or hash tree root (Merkle root) that anchors arbitrary data or a tree of hashes of arbitrary data to a particular event in the key event sequence.
Source [KERI Whitepaper section 7.23 page 47](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
A seal is a cryptographic proof in a secondary root-of-trust (e.g. TEL) that is anchored in a primary-root-of-trust (e.g.KEL).
Source Same Smith
The payload of the seal becomes immutable and the controller commits a signature to the seal.
| TBW prio 2 |
---
title: secondary-root-of-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/secondary-root-of-trust
md: https://weboftrust.github.io/WOT-terms/04_glossary/secondary-root-of-trust.md
---
# secondary-root-of-trust
In KERI its a [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md) that, for its secure attribution, depends on another verifiable data structure (VDS) which MUST be a [primary root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/primary-root-of-trust.md).
By its nature and cryptographic anchoring via [seals](https://weboftrust.github.io/WOT-terms/docs/glossary/seal.md) to a primary root-of-trust, a secondary root-of-trust still has a high level of trustability and can be automatically verified.
---
title: secure-asset-transfer-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/secure-asset-transfer-protocol
md: https://weboftrust.github.io/WOT-terms/04_glossary/secure-asset-transfer-protocol.md
---
# secure-asset-transfer-protocol
An IETF protocol (and working group) in the making (as of mid 2022) for moving assets between blockchains.
[About SATP working group](https://datatracker.ietf.org/wg/satp/about/)
KERI has portable identifiers per definition. KERI identifier are not locked into silos like distributed ledgers. KERI IDs have their own native hash-chained data structures (KEL, KERL and TEL).
---
title: secure-attribution
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/secure-attribution
md: https://weboftrust.github.io/WOT-terms/04_glossary/secure-attribution.md
---
# secure-attribution
Secure attribution is strongly related to _making and proving statements_. A [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) makes statements to the a [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) or [verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md), who in turn validates the statements issued. A [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) "_owns_" the statement: content and attribution via digital signatures. Secure attribution is "whodunit?!" in cyberspace.
_Secure attribution of a statement_ is a way of proving that **the statement is an authentic statement of the `controller`**.
In the context of KERI and ACDC _secure_ means a **`Validator` may cryptographically verify** the statement.
---
title: secure-private-authentic-confidentiality
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/secure-private-authentic-confidentiality
md: https://weboftrust.github.io/WOT-terms/04_glossary/secure-private-authentic-confidentiality.md
---
# secure-private-authentic-confidentiality
ToIP Trust Spanning Layer Group realized we do have a secure authentication layer (KERI) but we don't have a secure confidentiality and privacy mechanism. Sam Smith proposes SPAC paper to define this. Related: [https://www.usenix.org/system/files/sec22-cohen.pdf](https://www.usenix.org/system/files/sec22-cohen.pdf)
If someone has set up a public AID, with public Witnesses we don't have a mechanism to support private communication with this AID | TBW |
[SPAC paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md)
Tech meet KERI [recording](https://hackmd.io/-soUScAqQEaSw5MJ71899w#2023-06-27) from minute 35, date June 29 2023 and also discussed Tech meeting KERI Aug 3 2023 from minute 30 or so till end.
---
title: secure
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/secure
md: https://weboftrust.github.io/WOT-terms/04_glossary/secure.md
---
# secure
[Security](https://weboftrust.github.io/WOT-terms/docs/glossary/security.md)
---
title: security-cost-performance-architecture-trade-off
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/security-cost-performance-architecture-trade-off
md: https://weboftrust.github.io/WOT-terms/04_glossary/security-cost-performance-architecture-trade-off.md
---
# security-cost-performance-architecture-trade-off
The degree of protection offered by a key management infrastructure usually forces a trade-off between security, cost, and performance.
Typically, key generation happens relatively infrequently compared to event signing. But highly secure key generation may not support highly performant signing. This creates an architecture trade-off problem.
Paraphrased from source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
---
title: security-overlay-properties-trillema
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/security-overlay-properties-trillema
md: https://weboftrust.github.io/WOT-terms/04_glossary/security-overlay-properties-trillema.md
---
# security-overlay-properties-trillema
An identifier system has some degree of any combination of the three properties [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md), [privacy](https://weboftrust.github.io/WOT-terms/docs/glossary/privacy.md) and [confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/confidentiality.md), but not all three completely.
The reason a system may not provide all three completely is that no single cryptographic operation provides all three properties.
As a result any cryptographic system must layer the operations. But layering exposes weaknesses due to the separation between the layers. Because no single layer can exhibit all three properties, one must pick one or two properties for the bottom layer and then layer on top the remaining property or properties on one or more layers.
Source: Universal Identifier Theory by Samuel Smith
---
title: threshold-structure-security
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/security
md: https://weboftrust.github.io/WOT-terms/04_glossary/security.md
---
# threshold-structure-security
A threshold structure for security allows for weaker key management or execution environment infrastructure individually, but achieve greater overall security by multiplying the number of attack surfaces that an attacker must overcome to compromise a system.
With threshold structures, overall security may be greater than the security of any of the individual parts.
In [MFA](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-factor-authentication.md) the combination of two factors, something you have and something you know, may be much more secure than either of the factors by themselves.
Threshold structures may be employed in a complementary manner to trusted execution environments ([TEE](https://weboftrust.github.io/WOT-terms/docs/glossary/trusted-execution-environment.md)) for security. The two types of security are complementary.
This applies to KERI as well. The [witnesses](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) and [watchers](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) independently multiply the attack surfaces of the promulgation and the confirmation networks such that each witness or watcher respectively may be relatively insecure but the system as a whole may be highly secure.
Numerous papers discuss how secure a distributed consensus pool may be. But when comparing _apples_ (key management and trusted execution environment (TEE) approach to security) to _oranges_ (distributed consensus approach to security) its hard to say that the security of a distributed consensus algorithm is necessarily less secure than the key management infra-structure root-of-trust of any of its nodes. Although as a general rule, in an apples to apples comparison, _more complex is less secure_.
Source: Universal Identifier Theory by Samuel Smith
---
title: seed
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/seed
md: https://weboftrust.github.io/WOT-terms/04_glossary/seed.md
---
# seed
In cryptography a 'seed' is a _pseudorandomly_ generated number, often expressed in representation of a series of words.
Paraphrased from [wikipedia](https://en.wikipedia.org/wiki/Random_seed)
```
broken toddler farm argue elder behind sea ramp cake rabbit renew option combine guilt inflict sentence what desert manage angry manual grit copy hundred
```
Test [here](https://iancoleman.io/bip39/) yourself.
Although sequences that are closer to truly random can be generated using [hardware random number generators](https://en.wikipedia.org/wiki/Hardware_random_number_generator), pseudorandom number generators are important in practice for their speed in number generation and their reproducibility.
Source [wikipedia](https://en.wikipedia.org/wiki/Pseudorandom_number_generator)
---
title: selective-disclosure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/selective-disclosure
md: https://weboftrust.github.io/WOT-terms/04_glossary/selective-disclosure.md
---
# selective-disclosure
a disclosure of an ACDC that selectively discloses its attributes using Compact Disclosure. The set of selectively disclosable attributes is provided as an array of blinded blocks where each attribute in the set has its own dedicated blinded block. Unlike Partial Disclosure, the selectively disclosed fields are not correlatable to the so far undisclosed but selectively disclosable fields in the same encompassing block. Source: Dr. S. Smith
Selective disclosure is a from partial disclosure that has a different cryptographic fundament: a sort of cryptographic aggregator (not an accumulator).
Selective disclosure is a list of field maps. You can choose to blind and publish every single field map, but you have to disclosure all the field maps, either blinded or published.
It is an aggregator because you have to disclosure all the blinded fields when you do the selective disclosure.
[Partial Disclosure](https://weboftrust.github.io/WOT-terms/docs/glossary/partial-disclosure.md)
Source: distilled from ACDC Zoom meeting, date March 28, 2023
---
title: self-addressed-data
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/self-addressed-data
md: https://weboftrust.github.io/WOT-terms/04_glossary/self-addressed-data.md
---
# self-addressed-data
a representation of data content from which a SAID is derived. The SAID is both cryptographically bound to (content-addressable) and encapsulated by (self-referential) its SAD [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/said.md).
Source: Dr. S.Smith
---
title: self-addressing-data
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/self-addressing-data
md: https://weboftrust.github.io/WOT-terms/04_glossary/self-addressing-data.md
---
# self-addressing-data
an identifier that is content-addressable and self-referential. A SAID is uniquely and cryptographically bound to a serialization of data that includes the SAID as a component in that serialization [SAID](https://weboftrust.github.io/WOT-terms/docs/glossary/said.md).
Source: Dr. S. Smith
While all KERI event messages are self-addressing data (SAD), there is a broad class of SADs that are not KERI events but that require signature attachments. ACDC Verifiable credentials fit into this class of SADs. With more complex data structures represented as SADs, such as verifiable credentials, there is a need to provide signature attachments on nested subsets of SADs.
(Philip Feairheller, ietf-cesr-proof)
---
title: self-addressing-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/self-addressing-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/self-addressing-identifier.md
---
# self-addressing-identifier
any identifier that is deterministically generated out of the content, or a digest of the content.
Source: Dr. S. Smtih
An identifier that is deterministically generated from and embedded in the content it identifies, making it and its data mutually tamper-evident.
1. Fully populate the data that the SAID will identify, leaving a placeholder for the value of the SAID itself.
2. Canonicalize the data, if needed. The result is called the SAID's **identifiable basis**.
3. Hash the _identifiable basis_. The result is the value of the SAID.
4. Replace the placeholder in _identifiable basis_ the with the newly generated identifier, so the SAID is embedded in the data it identifies. The result is called the **saidified data.**
1. Canonicalize the data, if needed. The result is **claimed saidified data**.
2. In the _claimed saidified data_, replace the SAID value with a placeholder. The result is the **identifiable basis** for the SAID.
3. Hash the _identifiable basis_.
4. Compare the hash value to the SAID. If they are equal, then the SAID identifies the _claimed saidified data_.
- how data is canonicalized
- which hash algorithm is used
- which placeholder is used
- how the bytes produced by the hash algorithm are encoded
- how the SAID value is formatted
A terse way to describe a SAID and its data is to write an expression that consists of the token `SAID` followed by a token with field names in canonical order, where the field containing the SAID itsef is marked by the suffix `=said`. For example, the saidification of a simple `ContactInfo` data structure might be given as `SAID(name, address, phone, email, id=said)`.
---
title: self authenticating
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/self-authenticating
md: https://weboftrust.github.io/WOT-terms/04_glossary/self-authenticating.md
---
# self authenticating
[self-certifying](https://weboftrust.github.io/WOT-terms/docs/glossary/self-certifying-identifier.md)
---
title: Self-certifying identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/self-certifying-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/self-certifying-identifier.md
---
# Self-certifying identifier
a type of Cryptonym that is uniquely cryptographically derived from the public key of an asymmetric signing keypair (public, private).
Source: Dr. S. Smith
A Self-Certifying Identifier (SCID) cryptographically binds an identifier to one or more public/private key pairs. It is an identifier that can be proven to be the one and only identifier tied to a public key using cryptography alone.
A [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md) issues an own Identifier by binding a generated public private key pair to an identifier. After this a controller is able to sign the identifier and create a certificate. Also called a _cryptonym_. The simplest form of a self-certifying identifier includes either the public key or a unique fingerprint of the public key as a [prefix](https://weboftrust.github.io/WOT-terms/docs/glossary/prefix.md) in the identifier.
- Self-contained secure cryptographic [root-of-trust](https://weboftrust.github.io/WOT-terms/docs/glossary/root-of-trust.md)
- Decentralized control via [private key management](https://weboftrust.github.io/WOT-terms/docs/glossary/PKI.md)
- Universally unique identifiers
A self-certifying identifier (SCID) is a type of [cryptonym](https://weboftrust.github.io/WOT-terms/docs/glossary/cryptonym.md) that is uniquely cryptographically derived from the public key of an asymmetric non-repudiable signing keypair, (public, private).
It is self-certifying or more precisely **self-authenticating** because it does not rely on a trusted entity. The [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) of a non-repudiable signature made with the private key may be verified by extracting the public key from either the identifier itself or incepting information uniquely associated with the cryptographic derivation process for the identifier. In a _basic SCID_, the mapping between an identifier and its controlling public key is self-contained in the identifier itself. A basic SCID is [ephemeral](https://weboftrust.github.io/WOT-terms/docs/glossary/ephemeral.md) i.e. it does not support [rotation](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md) of its keypairs in the event of key weakness or compromise and therefore must be abandoned once the controlling private key becomes weakened or compromised from exposure.
---
title: self-framing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/self-framing
md: https://weboftrust.github.io/WOT-terms/04_glossary/self-framing.md
---
# self-framing
a textual or binary encoding that begins with type, size, and value so that a parser knows how many characters (when textual) or bytes (when binary) to extract from the stream for a given element without parsing the rest of the characters or bytes in the element is Self-Framing.
A self-framing Primitive may be extracted without needing any additional delimiting characters. Thus, a stream of concatenated Primitives may be extracted without the need to encapsulate each Primitive inside a set of delimiters or an envelope.
Source [Samual M Smith](https://www.ietf.org/archive/id/draft-ssmith-cesr-02.txt)
A self-framing text primitive may be parsed without needing any additional delimiting characters. Thus a stream of concatenated primitives may be individually parsed without the need to encapsulate the primitives inside textual delimiters or envelopes. Thus a textual self-framing encoding provides the core capability for a streaming text protocol like [STOMP](https://en.wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocol) or [RAET](https://github.com/RaetProtocol/raet).
Although a first class textual encoding of cryptographic primitives is the primary motivation for the [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/composable-event-streaming-representation.md) protocol defined herein, CESR is sufficiently flexible and extensible to support other useful data types, such as, integers of various sizes, floating point numbers, date-times as well as generic text. Thus this protocol is generally useful to encode in text data data structures of all types not merely those that contain cryptographic primitives.
---
title: Self-sovereign identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/self-sovereign-identity
md: https://weboftrust.github.io/WOT-terms/04_glossary/self-sovereign-identity.md
---
# Self-sovereign identifier
Self-sovereign identity is a decentralized identity architecture that implements the Principles of SSI — principally that it puts the identity controller (e.g., a natural person or organization) directly in control of the identifiers and credentials they use to assert their digital identity.
Source: ToIP main glossary
The definition started in the blog "[The Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html)" by Christopher Allen in 2016. has not resulted in a consensus today. While some see the ten principles of SSI that Allen proposed as the definition of SSI, he formulated them as "a departure point to provoke a discussion about what's truly important". And it is obvious that what is important differs per [party](https://essif-lab.github.io/framework/docs/terms/party).
[Source eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/self-sovereign-identity)
---
title: self-sovereignty
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/self-sovereignty
md: https://weboftrust.github.io/WOT-terms/04_glossary/self-sovereignty.md
---
# self-sovereignty
[Self sovereignty](https://github.com/trustoverip/toip/wiki/self-sovereignty) in Trust over IP wiki.
---
title: semver
description: Semantic Versioning Specification 2.0. See also (https//semver.org/].
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/semver
md: https://weboftrust.github.io/WOT-terms/04_glossary/semver.md
---
# semver
Semantic Versioning Specification 2.0. See also ([https://semver.org/)\[https://semver.org/\]](https://semver.org/\)%5Bhttps://semver.org/%5D).
Source: Dr. S.Smith
---
title: server-sent-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/server-sent-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/server-sent-event.md
---
# server-sent-event
Mailbox notifications; a streaming service for the agent U/I, to get notifications from the KERI system itself.
---
title: service-endpoint
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/service-endpoint
md: https://weboftrust.github.io/WOT-terms/04_glossary/service-endpoint.md
---
# service-endpoint
In our context we consider a **web service endpoint** which is a [URL](https://weboftrust.github.io/WOT-terms/docs/glossary/uniform-resource-locator.md) at which clients of specific service can get access to the service.
By referencing that URL, clients can get to operations provided by that service.
Paraphrased from [source](https://study.com/academy/lesson/what-is-web-service-endpoint-definition-concept.html)
---
title: siger
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/siger
md: https://weboftrust.github.io/WOT-terms/04_glossary/siger.md
---
# siger
[Indexed signature](https://weboftrust.github.io/WOT-terms/docs/glossary/indexed-signature.md)
---
title: signed-digest
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/signed-digest
md: https://weboftrust.github.io/WOT-terms/04_glossary/signed-digest.md
---
# signed-digest
commitment to content, by digitally signing a digest of this content.
---
title: signer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/signer
md: https://weboftrust.github.io/WOT-terms/04_glossary/signer.md
---
# signer
A primitive that represents a private key. It has the ability to create Sigers and Cigars (signatures).
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: signify-keria-request-authentication-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/signify-keria-request-authentication-protocol
md: https://weboftrust.github.io/WOT-terms/04_glossary/signify-keria-request-authentication-protocol.md
---
# signify-keria-request-authentication-protocol
SKRAP is a client to the KERIA server. Mobile clients will be using SKRAP to connect to KERI [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/AID.md)s via [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md)s in the new, multi-tenant Mark II Agent server, [KERIA](https://weboftrust.github.io/WOT-terms/docs/glossary/keria.md).
Also, browser extensions will use SKRAP in order to use a wallet similar to _MetaMask_, except it will be KERIMask, and it will be a browser extension. [KERIMask](https://weboftrust.github.io/WOT-terms/docs/glossary/KERIMask.md) will connect to KERIA servers in order for a person to control AIDs from their browser extension.
SKRAP is also usable from HSMs and hardware wallets because the keys from the hardware wallet, along with some app code, connect through SKRAP to agents running in a KERIA server.
[Signify](https://weboftrust.github.io/WOT-terms/docs/glossary/signify.md) signs things at the edge. This includes [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/ACDC.md)s. KERIA will be used to send communications between agents. The things KERIA sends are signed by Signify.
Source: Kent Bull in KERI Slack May 2023
The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces.
1. Boot Interface - Exposes one endpoint for Agent Worker initialization.
2. Admin Interface - The REST API for command and control operations from the Signify Client.
3. KERI Protocol Interface - CESR over HTTP endpoint for KERI protocol interactions with the rest of the world.
This separation allows for the Boot interface to be expose to internal infrastructure only (or disabled all together) while exposing the other two interfaces externally. If a KERIA instance is launched in static worker mode, meaning all agent workers are configured at start up only the Boot interface can be disabled completely.
More at source [Github Signify](https://github.com/WebOfTrust/signify/blob/main/protocol.md)
---
title: Slack Archive
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/signify
md: https://weboftrust.github.io/WOT-terms/04_glossary/signify.md
---
# Slack Archive
---
title: signing-authority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/signing-authority
md: https://weboftrust.github.io/WOT-terms/04_glossary/signing-authority.md
---
# signing-authority
The authority to sign on behalf of the controller of the authoritative key pair. Often in situation where delegation has taken place, e.g. a custodial agent. These are limited rights because [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md) is not included.
The original controller of an [AID](https://weboftrust.github.io/WOT-terms/docs/glossary/autonomic-identifier.md) can hold exclusive [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md). Because control authority is split between two key sets, the first for signing-authority and the second ([pre-rotated](https://weboftrust.github.io/WOT-terms/docs/glossary/pre-rotation.md)) for [rotation authority](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-authority.md), the associated thresholds and key list can be structured in such a way that a designated [custodial agent](https://weboftrust.github.io/WOT-terms/docs/glossary/custodial-agent.md) can hold signing authority while the original controller can hold exclusive rotation authority.
---
title: signing-threshold
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/signing-threshold
md: https://weboftrust.github.io/WOT-terms/04_glossary/signing-threshold.md
---
# signing-threshold
Is the minimum number of valid signatures to satisfy the requirement for successful verification in a [Threshold Signature Scheme](https://weboftrust.github.io/WOT-terms/docs/glossary/threshold-signature-scheme.md).
In a 2-of-3 signature scheme the threshold is 2. This means that 2 valid signatures are enough to fulfil the required signature.
---
title: simple-keri-for-web-auth
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/simple-keri-for-web-auth
md: https://weboftrust.github.io/WOT-terms/04_glossary/simple-keri-for-web-auth.md
---
# simple-keri-for-web-auth
A [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) implementation that sacrifices performance or other non-security feature for usability. In general a narrow application of KERI may not require all the features of KERI but those features that it does support must still be secure.
More on source [Github Repo SKWA](https://github.com/WebOfTrust/skwa).
Designed for private clouds, just like [Keep](https://weboftrust.github.io/WOT-terms/docs/glossary/keep.md). [Signify](https://weboftrust.github.io/WOT-terms/docs/glossary/signify.md) is designed for public clouds.
---
title: single-signature-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/single-signature-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/single-signature-identifier.md
---
# single-signature-identifier
or single sig identifier; is an identifier controlled by a one-of-one signing [keypair](https://weboftrust.github.io/WOT-terms/docs/glossary/key-pair.md)
---
title: SKRAP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/SKRAP
md: https://weboftrust.github.io/WOT-terms/04_glossary/SKRAP.md
---
# SKRAP
[Signify/KERIA Request Authentication Protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/signify-keria-request-authentication-protocol.md)
---
title: SKWA
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/SKWA
md: https://weboftrust.github.io/WOT-terms/04_glossary/SKWA.md
---
# SKWA
[Simple KERI for web auth](https://weboftrust.github.io/WOT-terms/docs/glossary/simple-keri-for-web-auth.md)
---
title: sniffable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/sniffable
md: https://weboftrust.github.io/WOT-terms/04_glossary/sniffable.md
---
# sniffable
A stream is _sniffable_ as soon as it starts with a group code or field map; in fact this is how our parser ([Parside](https://weboftrust.github.io/WOT-terms/docs/glossary/parside.md)) works. and detects if the CESR stream contains a certain datablock. The datablock of CESR binary, CESR Text, JSON, CBOR, MGPK have an Object code or the Group code (binary or text) and it's always a recognizable and unique _three bit combination_.
We have the Cold start problem of a stream: you don't where to start recognizing structured data.
So a stream is either sniffable or not, when it has or has not the fore-mentioned group- or object-codes.
Source: Sam Smith, Zoom Meeting KERI, Dec 5 2023
[Sniffer](https://weboftrust.github.io/WOT-terms/docs/glossary/sniffer.md)
---
title: sniffer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/sniffer
md: https://weboftrust.github.io/WOT-terms/04_glossary/sniffer.md
---
# sniffer
The _sniffer_ is part of [Parside](https://weboftrust.github.io/WOT-terms/docs/glossary/parside.md) and detects if the CESR stream contains CESR binary, CESR Text, JSON, CBOR, MGPK.
If any of JSON, CBOR, MGPK then the parser regexes to find the [version string](https://weboftrust.github.io/WOT-terms/docs/glossary/version-string.md) inside the JSON, CBOR, and MGPK and from the version string extracts the number of characters/bytes that is the length of the JSON, CBOR, or MGPK. The parser then resumes _sniffing_. When the sniff result is 'CESR' then when at the top level looks for the CESR [version count code](https://weboftrust.github.io/WOT-terms/docs/glossary/version-code.md) or any other count codes.
Source Slack Cesride thread: Feb 2 2023
[Sniffable](https://weboftrust.github.io/WOT-terms/docs/glossary/sniffable.md)
---
title: unsolicited-issuance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/solicited-issuance
md: https://weboftrust.github.io/WOT-terms/04_glossary/solicited-issuance.md
---
# unsolicited-issuance
Issuance of a Legal Entity vLEI Credential upon notice by a [QAR](https://weboftrust.github.io/WOT-terms/docs/glossary/QAR.md) to the [AVR](https://weboftrust.github.io/WOT-terms/docs/glossary/AVR.md)(s) of the Legal Entity that a Legal Entity vLEI Credential has been solicited on the [Legal Entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md)’s behalf.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
See [Solicited issuance](https://weboftrust.github.io/WOT-terms/docs/glossary/solicited-issuance.md)
---
title: source-of-truth
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/source-of-truth
md: https://weboftrust.github.io/WOT-terms/04_glossary/source-of-truth.md
---
# source-of-truth
The source of truth is a trusted data source that gives a complete picture of the data object as a whole.
[Source](https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/): LinkedIN.
Source of a particular piece of information from one place, considered to present the truth. However both KERI and ACDC only commit to the secure attribution of _who_ said something and not whether _what_ has been said is true or not. Veracity is an individual (organisational) conclusion that needs governance and virtual credentials. KERI and ACDC support veracity (concluding it's the "the truth") but doesn't solve it.
Compound description by @henkvancann from sources: [1](https://en.wikipedia.org/wiki/Single_version_of_the_truth), [2](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC_Spec.md)
Truth is the property of being in accord with fact or reality. In everyday language, truth is typically ascribed to things that aim to represent reality
[Source](https://en.wikipedia.org/wiki/Truth): Wikipedia.
---
title: SPAC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/SPAC
md: https://weboftrust.github.io/WOT-terms/04_glossary/SPAC.md
---
# SPAC
[Secure Private Authentic Confidentiality](https://weboftrust.github.io/WOT-terms/docs/glossary/secure-private-authentic-confidentiality.md)
---
title: spanning-layer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/spanning-layer
md: https://weboftrust.github.io/WOT-terms/04_glossary/spanning-layer.md
---
# spanning-layer
An all encompassing layer horizontal layer in a software architecture. Each trust layer only spans platform specific applications. It bifurcates the internet trust map into domain silos (e.g. twitter.com), because there is no spanning trust layer.
---
title: spurn
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/spurn
md: https://weboftrust.github.io/WOT-terms/04_glossary/spurn.md
---
# spurn
To _reject_. In KERI, "spurn" refers to a cryptographic or protocol-based act of rejecting an invalid or untrusted event. This rejection is deliberate and purposeful, ensuring the system's integrity by disregarding information that does not meet the necessary validation criteria. The verb 'spurn' is first used in the [IPEX](https://weboftrust.github.io/WOT-terms/docs/glossary/IPEX.md) specification.
| TBW prio 2 |
---
title: ssi-system
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ssi-system
md: https://weboftrust.github.io/WOT-terms/04_glossary/ssi-system.md
---
# ssi-system
The SSI Infrastructure consists of the technological components that are deployed all over the world for the purpose of providing, requesting and obtaining data for the purpose of negotiating and/or executing electronic [transactions](https://essif-lab.github.io/framework/docs/terms/transaction). Paraphrased by @henkvancann based on source [eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/ssi-infrastructure)
The SSI Infrastructure supports the sustainable functionality of [parties](https://essif-lab.github.io/framework/docs/terms/party) by providing IT services and facilities necessary for (electronic) [transactions](https://essif-lab.github.io/framework/docs/terms/transaction) to be negotiated and executed.
Source [eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/ssi-infrastructure)
The team has put stress on the principle 'security first, confidentiality second and privacy third'. All systems and infrastructure KERI and ACDC has presented therefore constitute a rather small subset of all [self-sovereign identity systems (SSI)](https://weboftrust.github.io/WOT-terms/docs/glossary/self-sovereign-identity.md) available nowadays.
---
title: SSI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/SSI
md: https://weboftrust.github.io/WOT-terms/04_glossary/SSI.md
---
# SSI
[Self-sovereign identity](https://weboftrust.github.io/WOT-terms/docs/glossary/self-sovereign-identity.md)
---
title: stable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/stable
md: https://weboftrust.github.io/WOT-terms/04_glossary/stable.md
---
# stable
Refers to the state of cryptographic verifiability across a network or system. It generally implies that a particular identifier, event, or data set is consistent, fully verified, and cannot be contested within KERI.
An identifier is considered stable when its associated event sequence (establishment, rotations, etc.) has been published by sufficient witnesses so that it can be verified and acknowledged by a quorum of watchers.
After a key rotation event, the new keys are considered stable only when enough receipts from witnesses confirm the event.
---
title: stale-event
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/stale-event
md: https://weboftrust.github.io/WOT-terms/04_glossary/stale-event.md
---
# stale-event
A stale key event is an outdated or irrelevant (key) event involving an [expired encryption key](https://weboftrust.github.io/WOT-terms/docs/glossary/stale-key.md) that may compromise security.
---
title: stale-key
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/stale-key
md: https://weboftrust.github.io/WOT-terms/04_glossary/stale-key.md
---
# stale-key
A stale key is an outdated or expired encryption key that should no longer be used for securing data
[Stale (key) event](https://weboftrust.github.io/WOT-terms/docs/glossary/stale-event.md)
---
title: stream
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/stream
md: https://weboftrust.github.io/WOT-terms/04_glossary/stream.md
---
# stream
a [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) Stream is any set of concatenated Primitives, concatenated groups of Primitives, or hierarchically composed groups of [Primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitives.md).
Source: Dr. S. Smith
---
title: streamer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/streamer
md: https://weboftrust.github.io/WOT-terms/04_glossary/streamer.md
---
# streamer
A convenience class for supporting stream parsing, including nested (tunneled, encrypted) [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) streams. Streams can be a mixture/combination of different [primitives](https://weboftrust.github.io/WOT-terms/docs/glossary/primitive.md), including other streams. A stream is a concatenation of primitives. Source: Kent Bull in chat Zoom meeting KERI Aug 6, 2024.
It is akin to a cryptographic primitive yet is not a cryptographic primitive itself.
It supports [ESSR](https://weboftrust.github.io/WOT-terms/docs/glossary/ESSR.md) by making it easier to handle tunneled streams. Source: Kent Bull in chat Zoom meeting KERI Aug 6, 2024.
---
title: strip-parameter
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/strip-parameter
md: https://weboftrust.github.io/WOT-terms/04_glossary/strip-parameter.md
---
# strip-parameter
tells us what part of the [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) stream will be parsed by which code.
[Parside](https://weboftrust.github.io/WOT-terms/docs/glossary/parside.md)
| TBW |
---
title: sub-shell
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/sub-shell
md: https://weboftrust.github.io/WOT-terms/04_glossary/sub-shell.md
---
# sub-shell
A subshell is basically a new shell just to run a desired program. A subshell can access the global variables set by the 'parent shell' but not the local variables. Any changes made by a subshell to a global variable is not passed to the parent shell.
[Source](https://linuxhandbook.com/subshell/)
A child process in computing is a [process](https://en.wikipedia.org/wiki/Process_\(computing\)) created by another process (the [parent process](https://en.wikipedia.org/wiki/Parent_process)). This technique pertains to [multitasking operating systems](https://en.wikipedia.org/wiki/Computer_multitasking), and is sometimes called a subprocess or traditionally a subtask.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Child_process)
---
title: supermajority
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/supermajority
md: https://weboftrust.github.io/WOT-terms/04_glossary/supermajority.md
---
# supermajority
Sufficient majority that is labeled _immune_ from certain kinds of attacks or faults.
---
title: untargeted-acdc
description: an ACDC without the presence of the Issuee field in the attribute or attribute aggregate sections.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/targeted-acdc
md: https://weboftrust.github.io/WOT-terms/04_glossary/targeted-acdc.md
---
# untargeted-acdc
an ACDC without the presence of the Issuee field in the attribute or attribute aggregate sections.
Source: Dr. S. Smith
[Targeted ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/targeted-acdc.md)
---
title: tcp-endpoint
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/tcp-endpoint
md: https://weboftrust.github.io/WOT-terms/04_glossary/tcp-endpoint.md
---
# tcp-endpoint
This is a [service endpoint](https://weboftrust.github.io/WOT-terms/docs/glossary/service-endpoint.md) of the web [transmission control protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/transmission-control-protocol.md)
Because TCP packets do not include a session identifier, both endpoints identify the session using the client's address and port. Whenever a packet is received, the TCP implementation must perform a lookup on this table to find the destination process.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
---
title: TCP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/TCP
md: https://weboftrust.github.io/WOT-terms/04_glossary/TCP.md
---
# TCP
[Transmission control protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/transmission-control-protocol.md)
---
title: TEE
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/TEE
md: https://weboftrust.github.io/WOT-terms/04_glossary/TEE.md
---
# TEE
[trusted execution environment](https://weboftrust.github.io/WOT-terms/docs/glossary/trusted-execution-environment.md)
---
title: management-TEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/TEL
md: https://weboftrust.github.io/WOT-terms/04_glossary/TEL.md
---
# management-TEL
[Management transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/management-transaction-event-log.md)
---
title: text-binary-concatenation-composability
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/text-binary-concatenation-composability
md: https://weboftrust.github.io/WOT-terms/04_glossary/text-binary-concatenation-composability.md
---
# text-binary-concatenation-composability
An encoding has _composability_ when any set of [self-framing](https://weboftrust.github.io/WOT-terms/docs/glossary/self-framing.md) concatenated primitives expressed in either the text domain or binary domain may be converted as a group to the other domain and back again without loss.
CESR is fully text binary concatenation composable.
Use Google Translate to translate a piece of text from English to Dutch. Subsequently, keep copy pasting the resulting “to:” text into the “from:” field. The message changes until it comes to a standstill where you can keep swapping the texts without them changing.
The conclusion is: Google Translate is not composable!
By contrast, CESR is composable. The _analogy_ lies in the fact that we consider two languages. Suppose the English in the Google Translate example is _readable, text based_ in CESR and Dutch is the _binary_ form in CESR. Within these two CESR “languages”, text-based and binary, you can concatenate and swap freely as many times as you like — the data won’t change in between in their binary or text form no matter what content you express with them.
More explanation in [source](https://medium.com/happy-blockchains/cesr-one-of-sam-smiths-inventions-is-as-controversial-as-genius-d757f36b88f8).
---
title: tholder
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/tholder
md: https://weboftrust.github.io/WOT-terms/04_glossary/tholder.md
---
# tholder
t-holder object that supports fractionally-weighted [thresholds](https://weboftrust.github.io/WOT-terms/docs/glossary/signing-threshold.md)
---
title: threshold-of-accountable-duplicity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/threshold-of-accountable-duplicity
md: https://weboftrust.github.io/WOT-terms/04_glossary/threshold-of-accountable-duplicity.md
---
# threshold-of-accountable-duplicity
The threshold of accountable duplicity (TOAD) is a threshold number `M` that the controller declares to accept accountability for an event when any subset `M` of the `N` witnesses confirm that event. The threshold `M` indicates the minimum number of confirming witnesses the controller deems sufficient given some number `F` of potentially faulty witnesses, given that `M >= N - F`. This enables a controller to provide itself with any degree of protection it deems necessary given this accountability.
Note that what may be sufficient for a controller may not be sufficient for a validator. To clarify, let `MC` denote the threshold size of a sufficient agreement from the perspective of a controller and let `MV` denote the threshold size of a sufficient agreement from the perspective of a validator. Typically, `MV >= MC`.
A controller declares TOAD in its [key event log (KEL)](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-log.md) during the [key inception event](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event.md) and may edit it during subsequent [key rotation events](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation-event.md).
A highly available system needs some degree of fault tolerance. The purpose of the threshold of accountability is to enable fault tolerance of the key event service with respect to faulty behavior by either the controller or witnesses. The principal controller fault exhibits duplicitous behavior in the use of its keys. In this case, the threshold serves as the threshold of accountable duplicity. The threshold lets a validator know when it may hold the controller accountable for duplicitous behavior. Without a threshold, a validator may choose to hold a controller accountable upon any evidence of duplicity which may make the service fragile in the presence of any degree of such faulty behavior. The primary way that a validator may hold a controller accountable is to stop trusting any use of the associated identifier. This destroys any value in the identifier and does not allow the controller to recover from an exploit. Recall that the one purpose of rotation keys (pre-rotated unexposed) is to enable recovery from compromised interaction signing keys. A compromised interaction signing key may exhibit duplicitous behavior on the part of the controller. A threshold of accountable duplicity enables a validator to distinguish between potentially recoverable duplicity such as the use of a compromised signing key and non-recoverable duplicity such as the use of a compromised rotation key. This better protects both the validator and the controller and improves the robustness of the service.
---
title: threshold-signature-scheme
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/threshold-signature-scheme
md: https://weboftrust.github.io/WOT-terms/04_glossary/threshold-signature-scheme.md
---
# threshold-signature-scheme
or TSS; is a type of digital signature protocol used by [Mutli-party Computation (MPC)](https://cryptoapis.io/products/wallet-as-a-service/mpc) wallets to authorize transactions or key state changes.
Source [Cryptoapis](https://cryptoapis.io/blog/78-what-is-the-threshold-signature-scheme)
---
title: threshold-structure-security
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/threshold-structure-security
md: https://weboftrust.github.io/WOT-terms/04_glossary/threshold-structure-security.md
---
# threshold-structure-security
A threshold structure for security allows for weaker key management or execution environment infrastructure individually, but achieve greater overall security by multiplying the number of attack surfaces that an attacker must overcome to compromise a system.
With threshold structures, overall security may be greater than the security of any of the individual parts.
In [MFA](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-factor-authentication.md) the combination of two factors, something you have and something you know, may be much more secure than either of the factors by themselves.
Threshold structures may be employed in a complementary manner to trusted execution environments ([TEE](https://weboftrust.github.io/WOT-terms/docs/glossary/trusted-execution-environment.md)) for security. The two types of security are complementary.
This applies to KERI as well. The [witnesses](https://weboftrust.github.io/WOT-terms/docs/glossary/witness.md) and [watchers](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md) independently multiply the attack surfaces of the promulgation and the confirmation networks such that each witness or watcher respectively may be relatively insecure but the system as a whole may be highly secure.
Numerous papers discuss how secure a distributed consensus pool may be. But when comparing _apples_ (key management and trusted execution environment (TEE) approach to security) to _oranges_ (distributed consensus approach to security) its hard to say that the security of a distributed consensus algorithm is necessarily less secure than the key management infra-structure root-of-trust of any of its nodes. Although as a general rule, in an apples to apples comparison, _more complex is less secure_.
Source: Universal Identifier Theory by Samuel Smith
---
title: TOAD
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/TOAD
md: https://weboftrust.github.io/WOT-terms/04_glossary/TOAD.md
---
# TOAD
[threshold of accountable duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/threshold-of-accountable-duplicity.md)
---
title: top-level-section
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/top-level-section
md: https://weboftrust.github.io/WOT-terms/04_glossary/top-level-section.md
---
# top-level-section
The fields of an ACDC in [compact variant](https://weboftrust.github.io/WOT-terms/docs/glossary/compact-variant.md). The value of a top level section field is either the SAD or the SAID of the SAD of the associated section. An Issuer commitment via a signature to any variant of ACDC (compact, full, etc) makes a cryptographic commitment to the top-level section fields shared by all variants of that ACDC.
Paraphrased by @henkvancann based on [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#example-most-compact-variant).
---
title: TPM
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/TPM
md: https://weboftrust.github.io/WOT-terms/04_glossary/TPM.md
---
# TPM
[Trusted platform module](https://weboftrust.github.io/WOT-terms/docs/glossary/trusted-platform-module.md)
---
title: trans-contextual-value
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/trans-contextual-value
md: https://weboftrust.github.io/WOT-terms/04_glossary/trans-contextual-value.md
---
# trans-contextual-value
Value that is transferrable between contexts. **How do we recapture the value in our data?** 1- Leverage cooperative network effects 2- Retake control of our data.
[Source](https://github.com/SmithSamuelM/Papers/blob/master/presentations/NonconformistKeynoteWeb20200702.pdf) Samuel Smith
How to remove primary barriers to cooperation? Different value contexts implies 'not directly competitive'. So we need to find value that is transferrable between contexts. Therefore: Use trans-contextual value creation and capture to fuel cooperative network effects.
KERI assists in this.
---
title: virtual-credential-transaction-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/transaction-event-log
md: https://weboftrust.github.io/WOT-terms/04_glossary/transaction-event-log.md
---
# virtual-credential-transaction-event-log
will track the issued or revoked state of each virtual credential (VC) and will contain a reference to its corresponding _management transaction event log (management TEL)_.
---
title: transfer-off-ledger
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/transfer-off-ledger
md: https://weboftrust.github.io/WOT-terms/04_glossary/transfer-off-ledger.md
---
# transfer-off-ledger
The act of transferring control authority over an identifier from a ledger (or blockchain) to the native verifiable KERI data structure Key Event Log.
If you want to transition to using KERI, you could do that by anchoring your KERI identifiers in, for example, your Indy ledger. The neat thing is, you could then **transfer the identifier off the ledger** and then have non-ledger based portable identifiers.
Although it's portable, you can be anchored to any one ledger at a time, or you could move it to an identifier (witness, backer, watcher, etc) can only be represented different ledger, or you could move to using just witnesses, all with the same identifier by just doing rotation events and changing your anchor, your backers here.
So an identifier cannot be anchored, let's say to multiple Indies or Ethereum. You could be only anchored in one at a time.
You can move identifiers across networks with KERI, but it's not what it has been designed for.
---
title: transferable-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/transferable-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/transferable-identifier.md
---
# transferable-identifier
Control over the identifier [can be transferred](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable.md) by [rotating keys](https://weboftrust.github.io/WOT-terms/docs/glossary/rotation.md).
A synonym is 'persistent identifier'.
The KERI design approach is to build composable primitives instead of custom functionality that is so typical of other DKMI approaches:
- transferable identifiers
- [non-transferable identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable-identifier.md)
- [delegated identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/delegated-identifier.md)
---
title: transferable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/transferable
md: https://weboftrust.github.io/WOT-terms/04_glossary/transferable.md
---
# transferable
Capable of being transferred or conveyed from one place or person to another. Place can be its and bits. The adjective transferable also means 'Negotiable', as a note, bill of exchange, or other evidence of property, that may be conveyed from one person to another by indorsement or other writing; capable of being transferred with no loss of value. As opposed to [non-transferable](https://weboftrust.github.io/WOT-terms/docs/glossary/non-transferable.md).
[Source](https://www.wordnik.com/words/transferable)
Focus is on the digital space and concerning the loss-less transfer of control over [identifiers](https://weboftrust.github.io/WOT-terms/docs/glossary/transferable-identifier.md), private keys, etc.
---
title: transmission-control-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/transmission-control-protocol
md: https://weboftrust.github.io/WOT-terms/04_glossary/transmission-control-protocol.md
---
# transmission-control-protocol
One of the main [protocols](https://en.wikipedia.org/wiki/Communications_protocol) of the [Internet protocol suite](https://en.wikipedia.org/wiki/Internet_protocol_suite). It originated in the initial network implementation in which it complemented the [Internet Protocol](https://en.wikipedia.org/wiki/Internet_Protocol) (IP).
More on [source](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) Wikipedia.
---
title: tritet
description: 3 bits. See Performant resynchronization with unique start bits.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/tritet
md: https://weboftrust.github.io/WOT-terms/04_glossary/tritet.md
---
# tritet
3 bits. See [Performant resynchronization with unique start bits](https://trustoverip.github.io/tswg-cesr-specification/#performant-resynchronization-with-unique-start-bits).
Source: Dr. S. Smith
---
title: trust-domain
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/trust-domain
md: https://weboftrust.github.io/WOT-terms/04_glossary/trust-domain.md
---
# trust-domain
A trust domain is the ecosystem of interactions that rely on a trust basis. A trust basis binds controllers, identifiers, and key-pairs. _For example the Facebook ecosystem of social interactions is a trust domain that relies on Facebook’s identity system of usernames and passwords as its trust basis._
([Source whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf))
A trust domain is a domain that the system trusts to authenticate users. In other words, if a user or application is authenticated by a trusted domain, this authentication is accepted by all domains that trust the authenticating domain.
A more technical meaning of 'domain' is on the internet: [domain name](https://weboftrust.github.io/WOT-terms/docs/glossary/domain-name.md).
---
title: trust-spanning-protocol
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/trust-spanning-protocol
md: https://weboftrust.github.io/WOT-terms/04_glossary/trust-spanning-protocol.md
---
# trust-spanning-protocol
Protocol using [VID](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-identifier.md)s that signs every single message on the internet and makes them verifiable.
---
title: trusted-execution-environment
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/trusted-execution-environment
md: https://weboftrust.github.io/WOT-terms/04_glossary/trusted-execution-environment.md
---
# trusted-execution-environment
Protected hardware/software/firmware security system. The controller may protect its key generation, key storage, and event signing infrastructure by running it inside a trusted execution environment (TEE).
SGX, TrustZone, an HSM, a TPM, or other similarly protected hardware/software/firmware environment
---
title: trusted-platform-module
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/trusted-platform-module
md: https://weboftrust.github.io/WOT-terms/04_glossary/trusted-platform-module.md
---
# trusted-platform-module
A device that enhances the security and privacy (of identity systems) by providing hardware-based cryptographic functions.
A TPM can generate, store, and protect encryption keys and authentication credentials that are used to verify the identity of a user or a device.
A TPM can also measure and attest the integrity of the software and firmware that are running on a system, to ensure that they have not been tampered with or compromised.
A TPM can be implemented as a physical chip, a firmware module, or a virtual device.
Source: Bing chat sept 2023
---
title: ts-node
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/ts-node
md: https://weboftrust.github.io/WOT-terms/04_glossary/ts-node.md
---
# ts-node
npm package that lets you run typescript from a shell
---
title: TSP
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/TSP
md: https://weboftrust.github.io/WOT-terms/04_glossary/TSP.md
---
# TSP
[Trust Spanning Protocol](https://weboftrust.github.io/WOT-terms/docs/glossary/trust-spanning-protocol.md)
---
title: UI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/UI
md: https://weboftrust.github.io/WOT-terms/04_glossary/UI.md
---
# UI
[User interface](https://weboftrust.github.io/WOT-terms/docs/glossary/user-interface.md)
---
title: uniform-resource-locator
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/uniform-resource-locator
md: https://weboftrust.github.io/WOT-terms/04_glossary/uniform-resource-locator.md
---
# uniform-resource-locator
A Uniform Resource Locator (URL), colloquially termed a web address, is a reference to a [web resource](https://en.wikipedia.org/wiki/Web_resource) that specifies its location on a [computer network](https://en.wikipedia.org/wiki/Computer_network) and a mechanism for retrieving it.
A URL is a specific type of [Uniform Resource Identifier](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) (URI),although many people use the two terms interchangeably. URLs occur most commonly to reference [web pages](https://en.wikipedia.org/wiki/Web_page) ([HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol)) but are also used for file transfer ([FTP](https://en.wikipedia.org/wiki/File_Transfer_Protocol)), email ([mailto](https://en.wikipedia.org/wiki/Mailto)), database access ([JDBC](https://en.wikipedia.org/wiki/Java_Database_Connectivity)), and many other applications.
More on source [Wikipedia](https://en.wikipedia.org/wiki/URL)
---
title: univalent
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/univalent
md: https://weboftrust.github.io/WOT-terms/04_glossary/univalent.md
---
# univalent
In identifier systems, univalent means having a unique and non-ambiguous identifier for each entity or resource. This means that there is a _one-to-one correspondence_ between the identifiers and the entities, and that no two different entities share the same identifier. Source: Bing chat, Sept 2023
(Paraphrased from source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith) In key management key pairs (public, private) are created in the key-pair generation and storage infrastructure and then may be moved to the key event generation and signing infrastructure in order to sign events. To protect both the key generation and storage and the event signing infrastructures. . Consequently, a given protection mechanism may co-locate both infrastructures. This means facilities are shared. This combined infrastructure is refered to as a _univalent_ key management infrastructure.
A more secure albeit less convenient or performant univalent key management infrastructure may use special computing devices or components to store private keys and/or create signatures.
[Multivalent](https://weboftrust.github.io/WOT-terms/docs/glossary/multi-valent.md) [Bivalent](https://weboftrust.github.io/WOT-terms/docs/glossary/bivalent.md)
---
title: unpermissioned-correlation
description: a correlation established between two or more disclosed ACDCs whereby the discloser of the ACDCs does not permit the disclosee to establish such a correlation.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/unpermissioned-correlation
md: https://weboftrust.github.io/WOT-terms/04_glossary/unpermissioned-correlation.md
---
# unpermissioned-correlation
a correlation established between two or more disclosed ACDCs whereby the discloser of the ACDCs does not permit the disclosee to establish such a correlation.
Source: Dr. S. Smith
---
title: unsolicited-issuance
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/unsolicited-issuance
md: https://weboftrust.github.io/WOT-terms/04_glossary/unsolicited-issuance.md
---
# unsolicited-issuance
Issuance of a Legal Entity vLEI Credential upon notice by a [QAR](https://weboftrust.github.io/WOT-terms/docs/glossary/QAR.md) to the [AVR](https://weboftrust.github.io/WOT-terms/docs/glossary/AVR.md)(s) of the Legal Entity that a Legal Entity vLEI Credential has been solicited on the [Legal Entity](https://weboftrust.github.io/WOT-terms/docs/glossary/legal-entity.md)’s behalf.
[Source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf): Draft vLEI Ecosystem Governance Framework Glossary.
See [Solicited issuance](https://weboftrust.github.io/WOT-terms/docs/glossary/solicited-issuance.md)
---
title: untargeted-acdc
description: an ACDC without the presence of the Issuee field in the attribute or attribute aggregate sections.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/untargeted-acdc
md: https://weboftrust.github.io/WOT-terms/04_glossary/untargeted-acdc.md
---
# untargeted-acdc
an ACDC without the presence of the Issuee field in the attribute or attribute aggregate sections.
Source: Dr. S. Smith
[Targeted ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/targeted-acdc.md)
---
title: URL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/URL
md: https://weboftrust.github.io/WOT-terms/04_glossary/URL.md
---
# URL
[Uniform resource locator](https://weboftrust.github.io/WOT-terms/docs/glossary/uniform-resource-locator.md)
---
title: user-interface
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/user-interface
md: https://weboftrust.github.io/WOT-terms/04_glossary/user-interface.md
---
# user-interface
A user interface (UI or U/I) is the space where interactions between humans and machines occur.
The [Reactable](https://en.wikipedia.org/wiki/Reactable), an example of a [tangible user interface](https://en.wikipedia.org/wiki/Tangible_user_interface) In the [industrial design](https://en.wikipedia.org/wiki/Industrial_design) field of [human–computer interaction](https://en.wikipedia.org/wiki/Human%E2%80%93computer_interaction), a user interface (UI) is the space where interactions between humans and machines occur. The goal of this interaction is to allow effective operation and control of the machine from the human end, while the machine simultaneously feeds back information that aids the operators' [decision-making](https://en.wikipedia.org/wiki/Decision-making) process.
Source [page](https://en.wikipedia.org/wiki/User_interface)
---
title: validate
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/validate
md: https://weboftrust.github.io/WOT-terms/04_glossary/validate.md
---
# validate
ESSIF-lab definition of _[validate](https://essif-lab.github.io/framework/docs/essifLab-glossary#validate)_. Although this definition is very general, in the KERI/ACDC vocabulary, 'validate' currently has extra diverse meanings extending the one of eSSIF-lab, such as
- evaluate
- [verify](https://weboftrust.github.io/WOT-terms/docs/glossary/verify.md)
In contrast, [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) and [verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md) have been clearly outlined in the WebofTrust vocabulary.
---
title: validator
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/validator
md: https://weboftrust.github.io/WOT-terms/04_glossary/validator.md
---
# validator
any entity or agent that evaluates whether or not a given signed statement as attributed to an identifier is valid at the time of its issuance.
Source: Dr. S. Smith
determines the current authoritative key set for an identifier from at least one key event (receipt) log.
Types:
- Validator of any verifiable data structure
- Validator as a node in distributed consensus or participant
Validator and [verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md) are close to synonyms for our purposes.
A `validator` in [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-infrastructure.md) and [ACDC](https://weboftrust.github.io/WOT-terms/docs/glossary/authentic-chained-data-container.md) is anybody who wants to establish control authority over an identifier created by the controller of the identifier. Validators verify the log, apply duplicity detection, leverage somebody else's duplicity detection, or apply any other logic so they can say, "Yes, these are events I can trust."
During validation of virtual credentials for example, a [verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md) checks to see if a verifiable [credential](https://weboftrust.github.io/WOT-terms/docs/glossary/credential.md) ([VC](https://weboftrust.github.io/WOT-terms/docs/glossary/VC.md)) has been signed by the controller of this VC using the applicable verification method.
Any entity or agent that evaluates whether or not a given signed statement as attributed to an identifier is valid at the time of its issuance. A valid statement MUST be verifiable, that is, has a verifiable signature from the current controlling keypair(s) at the time of its issuance. Therefore a Validator must first act as a Verifier in order to establish the root authoritative set of keys. Once verified, the Validator may apply other criteria or constraints to the statement in order to determine its validity for a given use case. When that statement is part of a verifiable data structure then the cryptographic verification includes verifying digests and any other structural commitments or constraints. To elaborate, with respect to an AID, for example, a Validator first evaluates one or more KELs in order to determine if it can rely on (trust) the key state (control authority) provided by any given KEL. A necessary but insufficient condition for a valid KEL is it is verifiable i.e. is internally inconsistent with respect to compliance with the KERI protocol. An invalid KEL from the perspective of a Validator may be either unverifiable or may be verifiable but duplicitous with respect to some other verifiable version of that KEL. Detected duplicity by a given validator means that the validator has seen more than one verifiable version of a KEL for a given AID. Reconciliable duplicity means that one and only one version of a KEL as seen by a Validator is accepted as the authoritative version for that validator. Irreconcilable duplicity means that none of the versions of a KEL as seen by a validator are accepted as the authoritative one for that validator. The conditions for reconcilable duplicity are described later.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: variable-length
description: a type of count code allowing for vaiable size signatures or attachments which can be parsed to get the full size.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/variable-length
md: https://weboftrust.github.io/WOT-terms/04_glossary/variable-length.md
---
# variable-length
a type of count code allowing for vaiable size signatures or attachments which can be parsed to get the full size.
Source: Dr. S. Smith
---
title: VC
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/VC
md: https://weboftrust.github.io/WOT-terms/04_glossary/VC.md
---
# VC
[Verifiable credential](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md)
---
title: vcp
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/vcp
md: https://weboftrust.github.io/WOT-terms/04_glossary/vcp.md
---
# vcp
vcp = vdr incept, verifiable data registry inception
---
title: VCTEL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/VCTEL
md: https://weboftrust.github.io/WOT-terms/04_glossary/VCTEL.md
---
# VCTEL
[Virtual credential transaction event log](https://weboftrust.github.io/WOT-terms/docs/glossary/virtual-credential-transaction-event-log.md)
---
title: vdr
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/vdr
md: https://weboftrust.github.io/WOT-terms/04_glossary/vdr.md
---
# vdr
[Verifiable data registry](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-data-registry.md)
---
title: VDS
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/VDS
md: https://weboftrust.github.io/WOT-terms/04_glossary/VDS.md
---
# VDS
[Verifiable data structure](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-data-structure.md)
---
title: veracity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/veracity
md: https://weboftrust.github.io/WOT-terms/04_glossary/veracity.md
---
# veracity
The quality of being true; contrast [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md). When a newspaper publishes a story about an event, every faithful reproduction of that story may be _authentic_ — but that does not mean the story was true (has _veracity_).
---
title: verfer
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verfer
md: https://weboftrust.github.io/WOT-terms/04_glossary/verfer.md
---
# verfer
A primitive that represents a public key. It has the ability to [verify](https://weboftrust.github.io/WOT-terms/docs/glossary/verify.md) signatures on data.
[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
---
title: Verifiable Credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-credential
md: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-credential.md
---
# Verifiable Credential
Verifiable credentials (VCs) are an [open standard](https://en.wikipedia.org/wiki/Open_standard) for digital credentials. They can represent information found in physical credentials, such as a passport or license, as well as new things that have no physical equivalent, such as ownership of a bank account.
[VCs](https://en.wikipedia.org/wiki/Verifiable_credentials)
Importantly, there are VC specification that provide a mechanism to express these sorts of [credentials](https://www.w3.org/TR/vc-data-model/#dfn-credential) on the Web _in a way that is_ cryptographically secure, privacy respecting, and machine-verifiable. [More](https://www.w3.org/TR/vc-data-model/)
[Issuer](https://weboftrust.github.io/WOT-terms/docs/glossary/issuer.md): The entity that creates and issues the credential. [Holder](https://weboftrust.github.io/WOT-terms/docs/glossary/holder.md): The entity that holds and can present the credential. [Verifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md): The entity that checks the authenticity and validity of the credential. Tamper-proof: VCs use cryptographic techniques (like digital signatures) to ensure that the credential has not been altered since issuance. Privacy-preserving: VCs can allow the holder to disclose only the necessary information, often using selective disclosure or zero-knowledge proofs to protect privacy. Decentralized: VCs can be part of decentralized identity systems, where control over identity is more in the hands of the individual rather than centralized authorities.
A university degree issued digitally by a university that can be verified by a potential employer, a government-issued ID that can be verified by a third-party service provider, or a COVID-19 vaccination certificate that health authorities can verify.
[Virtual credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/virtual-credential.md), that share a subset.
---
title: verifiable-data-registry
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-data-registry
md: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-data-registry.md
---
# verifiable-data-registry
A role a system might perform by mediating issuance and verification of ACDCs. See [verifiable data registry](https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-data-registries).
Source: Dr. S. Smith
a [Verifiable Data Structure](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-data-structure.md) that has actual content.
It contains either a log of signed statements or a cryptographic commitment ([digest](https://weboftrust.github.io/WOT-terms/docs/glossary/digest.md)) to those statements (via a Merkle tree or hash chained data structure).
---
title: verifiable-data-structure
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-data-structure
md: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-data-structure.md
---
# verifiable-data-structure
A verifiable data structure is a data structure that incorporates cryptographic techniques to ensure the integrity and authenticity of its contents. It allows users to verify the correctness of the data stored within the structure without relying on a trusted third party. [Source ChatGPT](#Sources-Definition-ChatGPT)
Provides proof of key state for its identifier. In KERI it is the Key Event Log (`KEL`). Key management is embedded in KELs, including recovery from key compromise.
* * *
1. Boneh, D., & Shacham, H. (2018). Verifiable data structures for outsourced data. Foundations and Trends® in Privacy and Security, 2(1-2), 1-116.
2. Bamert, T., Decker, C., Elsen, L., Wattenhofer, R., & Welten, S. (2017). Have a snack, pay with bitcoins. Distributed Computing, 30(1), 69-93.
3. Ateniese, G., Kamara, S., & Katz, J. (2014). Provable data possession at untrusted stores. ACM Transactions on Information and System Security (TISSEC), 7(2), 222-238.
4. Andrychowicz, M., Dziembowski, S., Malinowski, D., & Mazurek, Ł. (2014). Secure multiparty computations on Bitcoin. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (pp. 628-639).
5. Pomarole, M., Zhang, Y., Rosulek, M., & Katz, J. (2014). Secure cloud backup and inference control. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security (pp. 812-823).
---
title: verifiable-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-identifier.md
---
# verifiable-identifier
Cryptographically verifiable authentic decentralized identifier (verfiable [DID](https://weboftrust.github.io/WOT-terms/docs/glossary/DID.md))
---
title: verifiable-legal-entity-identifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-legal-entity-identifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable-legal-entity-identifier.md
---
# verifiable-legal-entity-identifier
Verifiable credentials are issued by authorized validation agents ([QVIs](https://weboftrust.github.io/WOT-terms/docs/glossary/QVI.md)) under the governance of [GLEIF](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIF.md), who delegate tasks to these agents. They provide cryptographic proof that the information about a legal entity, as linked to its Legal Entity Identifier (LEI), is verifiably authentic, accurate, and up-to-date.
The v in vLEI stands for “verifiable”, but what does that mean? In this case, "verifiable" comes from “Verifiable Credential”. A verifiable credential is just a collection of information with a mechanism that allows a computer to verify that the information has not been modified and that the information was originally stated to be correct by some third party (maybe a bank or the driving license authority). Often (almost always really), the information will include a link to the entity the information is about.
[Here](https://rapidlei.com/what-is-vlei/) at Rapidlei.
---
title: verifiable
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable
md: https://weboftrust.github.io/WOT-terms/04_glossary/verifiable.md
---
# verifiable
a condition of a KEL: being internally consistent with the integrity of its backward and forward chaining digest and authenticity of its non-repudiable signatures.
Source: Dr. S. Smith
**Explanation**
Able to cryptographically verify a certain data structure on its [consistency](https://weboftrust.github.io/WOT-terms/docs/glossary/inconsistency.md) and its [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md)
A KEL is verifiable means all content in a KEL including the digests and the signatures on that content is verifiably compliant with respect to the KERI protocol. In other words, the KEL is internally consistent and has integrity vis-a-vis its backward and forward chaining digests and authenticity vis-a-vis its non-repudiable signatures. As a verifiable data structure, the KEL satisfies the KERI protocol-defined rules for that verifiability. This includes the cryptographic verification of any digests or signatures on the contents so digested or signed.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: verification
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verification
md: https://weboftrust.github.io/WOT-terms/04_glossary/verification.md
---
# verification
An action an [agent](https://weboftrust.github.io/WOT-terms/docs/glossary/agent.md) (of a principal) performs to determine the [authenticity](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) of a claim or other digital object using a cryptographic key.
Source: ToIP glossary, Jan 2024.
In more technical words, the capability to (cryptographically) verify data received from peers (check structure, signatures, dates)
[verify](https://weboftrust.github.io/WOT-terms/docs/glossary/verify.md)
---
title: verified-integrity
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verified-integrity
md: https://weboftrust.github.io/WOT-terms/04_glossary/verified-integrity.md
---
# verified-integrity
A mechanism that can unambiguously assess whether the information is/continues to be whole, sound and unimpaired
- In KERI's secure attribution focus integrity is verified by [internal consistency](https://weboftrust.github.io/WOT-terms/docs/glossary/internal-inconsistency.md) of [KE(R)L](https://weboftrust.github.io/WOT-terms/docs/glossary/key-event-receipt-log.md) and [TEL](https://weboftrust.github.io/WOT-terms/docs/glossary/transaction-event-log.md) plus [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection.
- In ACDC the [self addressing identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/self-addressing-identifier.md) (SAID) takes of verified integrity at all times by design
- The streaming protocol CESR has verifiable integrity due to it's code tables and round-robin [composability](https://weboftrust.github.io/WOT-terms/docs/glossary/composability.md).
[integrity](https://weboftrust.github.io/WOT-terms/docs/glossary/integrity.md)
[(complementary) integrity verification](https://weboftrust.github.io/WOT-terms/docs/glossary/complementary-integrity-verification.md)
---
title: verifier
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verifier
md: https://weboftrust.github.io/WOT-terms/04_glossary/verifier.md
---
# verifier
any entity or agent that cryptographically verifies the signature(s) and digests on an event Message.
Source Dr. S. Smith
the entity that (cryptographically) verifies data received from peers (check structure, signatures, dates). More narrowly defined for the KERI suite: cryptographically verifies signature(s) on an event message.
Notice the subtile difference between [validator](https://weboftrust.github.io/WOT-terms/docs/glossary/validator.md) and verifier.
Any entity or agent that cryptographically verifies the signature(s) and/or digests on an event message. In order to verify a signature, a verifier must first determine which set of keys are or were the controlling set for an identifier when an event was issued. In other words, a verifier must first establish control authority for an identifier. For identifiers that are declared as non-transferable at inception, this control establishment merely requires a copy of the inception event for the identifier. For identifiers that are declared transferable at inception, this control establishment requires a complete copy of the sequence of establishment events (inception and all rotations) for the identifier up to the time at which the statement was issued.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: verify-signature
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verify-signature
md: https://weboftrust.github.io/WOT-terms/04_glossary/verify-signature.md
---
# verify-signature
Applying an algorithm that, given the message, public key and signature, either accepts or rejects the message's claim to authenticity.
---
title: verify
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/verify
md: https://weboftrust.github.io/WOT-terms/04_glossary/verify.md
---
# verify
The act, by or on behalf of a [party](https://weboftrust.github.io/WOT-terms/docs/glossary/party.md), of determining whether that data is [authentic](https://weboftrust.github.io/WOT-terms/docs/glossary/authenticity.md) (i.e. originates from the party that authored it), timely (i.e. has not expired), and conforms to other specifications that apply to its structure.
[Source eSSIF-lab](https://essif-lab.github.io/framework/docs/essifLab-glossary#verify) in eSSIF-lab glossary
[Verification](https://weboftrust.github.io/WOT-terms/docs/glossary/verification.md)
---
title: version-code
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/version-code
md: https://weboftrust.github.io/WOT-terms/04_glossary/version-code.md
---
# version-code
tells you which set of tables to load, it tells the table state. It's a unique code. what version of the table is going to load.
[Version string](https://weboftrust.github.io/WOT-terms/docs/glossary/version-string.md)
---
title: version-string
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/version-string
md: https://weboftrust.github.io/WOT-terms/04_glossary/version-string.md
---
# version-string
the first field in any top-level KERI field map in which it appears.
The Version String in JSON, CBOR and MGPK is a workaround to make those self-framing.
[Version code](https://weboftrust.github.io/WOT-terms/docs/glossary/version-code.md)
---
title: version
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/version
md: https://weboftrust.github.io/WOT-terms/04_glossary/version.md
---
# version
an instance of a KEL for an AID in which at least one event is unique between two instances of the [KEL](https://weboftrust.github.io/WOT-terms/docs/glossary/kel.md).
Source: Dr. S. Smith
In [software engineering](https://en.wikipedia.org/wiki/Software_engineering), version control (also known as revision control, source control, or source code management) is a class of systems responsible for managing changes to [computer programs](https://en.wikipedia.org/wiki/Computer_program), documents, large web sites, or other collections of information.
[Source](https://en.wikipedia.org/wiki/Version_control)
More than one version of a KEL for an AID exists when for any two instances of a KEL at least one event is unique between the two instances.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: VID
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/VID
md: https://weboftrust.github.io/WOT-terms/04_glossary/VID.md
---
# VID
[Verifiable Identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-identifier.md)
---
title: virtual-credential-transaction-event-log
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/virtual-credential-transaction-event-log
md: https://weboftrust.github.io/WOT-terms/04_glossary/virtual-credential-transaction-event-log.md
---
# virtual-credential-transaction-event-log
will track the issued or revoked state of each virtual credential (VC) and will contain a reference to its corresponding _management transaction event log (management TEL)_.
---
title: virtual-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/virtual-credential
md: https://weboftrust.github.io/WOT-terms/04_glossary/virtual-credential.md
---
# virtual-credential
Digital representations of claims or identity attributes, often used in online environments.
A virtual credential typically refers to a type of credential that exists in a digital or online form, often without a physical counterpart. It can be a digital representation of a claim or an identity attribute (such as name, age, professional certification, etc.) that is issued, stored, and shared electronically. The term "virtual" here emphasizes that the credential exists only in digital form and may not be physically printed or tangible.
A digital badge awarded for completing an online course, an electronic version of a driver’s license, or a digital ID card stored in a mobile app.
[Verifiable credentials](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md), that share a subset.
---
title: vlei-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/vlei-credential
md: https://weboftrust.github.io/WOT-terms/04_glossary/vlei-credential.md
---
# vlei-credential
Credential concerning a verifiable Legal Entity Identifier, residing in the [GLEIS](https://weboftrust.github.io/WOT-terms/docs/glossary/GLEIS.md) and compliant with one or more of the GLEIF [Governance Framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md)s
---
title: vlei-ecosystem-governance-framework
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/vlei-ecosystem-governance-framework
md: https://weboftrust.github.io/WOT-terms/04_glossary/vlei-ecosystem-governance-framework.md
---
# vlei-ecosystem-governance-framework
The Verifiable LEI (vLEI) Ecosystem [Governance Framework](https://weboftrust.github.io/WOT-terms/docs/glossary/governance-framework.md) Information Trust Policies. It's a **document** that defines the information security, privacy, availability, confidentiality and processing integrity policies that apply to all vLEI Ecosystem Members.
Paraphrased by @henkvancann from [source](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-02-07_verifiable-lei-vlei-ecosystem-governance-framework-glossary-draft-publication_v0.9-draft.pdf) Draft vLEI Ecosystem Governance Framework Glossary.
---
title: vlei-role-credential
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/vlei-role-credential
md: https://weboftrust.github.io/WOT-terms/04_glossary/vlei-role-credential.md
---
# vlei-role-credential
It is a [vLEI credential](https://weboftrust.github.io/WOT-terms/docs/glossary/vlei-credential.md) that attests to a role within a legal entity to an individual or an entity. It cryptographically proves that the individual or entity is authorized to act in that role on behalf of the legal entity.
---
title: vLEI
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/vLEI
md: https://weboftrust.github.io/WOT-terms/04_glossary/vLEI.md
---
# vLEI
[Verifiable legal entity identifier](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-legal-entity-identifier.md)
---
title: vrt
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/vrt
md: https://weboftrust.github.io/WOT-terms/04_glossary/vrt.md
---
# vrt
vrt = vdr rotate, verifiable data registry rotation
---
title: wallet
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/wallet
md: https://weboftrust.github.io/WOT-terms/04_glossary/wallet.md
---
# wallet
A crypto wallet is a device, physical medium, program or a service which stores the [public and/or private keys](https://en.wikipedia.org/wiki/Public-key_cryptography) for [cryptocurrency](https://en.wikipedia.org/wiki/Cryptocurrency) transactions and digital identifiers.
Paraphrased by @henkvancann from source [Wikipedia](https://en.wikipedia.org/wiki/Cryptocurrency_wallet)
A wallet is a collection of data stores; made up of a [keystore](https://weboftrust.github.io/WOT-terms/docs/glossary/keystore.md), local and remote key event log database and credential database. So it is a superset of a keystore.
Source: Philip Feairheller.
In a broader context a wallet can be seen as software and sometimes hardware that serves as a [keystore](https://weboftrust.github.io/WOT-terms/docs/glossary/keystore.md) and functionality. Keys can be private keys and public keys, and the wallet could contain hashes and pointers. Functionality can be signing, invoices (receive), send, virtual credentials, delegation, etc. This functionality is the [`agency`](https://weboftrust.github.io/WOT-terms/docs/glossary/agency.md) part of a wallet.
[More about digital ID Wallets](https://www.thalesgroup.com/en/markets/digital-identity-and-security/government/identity/digital-identity-services/digital-id-wallet)
[More about cryto Wallets](https://cryptocurrencyfacts.com/what-is-a-cryptocurrency-wallet/).
In addition to this basic function of **storing the keys**, it's also used to storing [verifiable credentials (VCs)](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md). A cryptocurrency wallet more often also offers the functionality of **[encrypting](https://en.wikipedia.org/wiki/Encrypting)** and/or **[signing](https://en.wikipedia.org/wiki/Digital_signature)** information.\\
Signing can for example result in executing a [smart contract](https://en.wikipedia.org/wiki/Smart_contract), a cryptocurrency transaction, [identification](https://en.wikipedia.org/wiki/Digital_signature#Authentication) or [legally signing](https://en.wikipedia.org/wiki/Electronic_signature) a 'document'.
More on source [Wikipedia](https://en.wikipedia.org/wiki/Cryptocurrency_wallet)
A 'wallet' in KERI would typically refer to the basic function of **storing the keys**, a wallet in ACDC is more focussed on storing [verifiable credentials (VCs)](https://weboftrust.github.io/WOT-terms/docs/glossary/verifiable-credential.md).\\
KERI explicitly distinguishes [keystore](https://weboftrust.github.io/WOT-terms/docs/glossary/keystore.md) and [wallet](https://weboftrust.github.io/WOT-terms/docs/glossary/wallet.md); the latter being a superset of the former. [Keep](https://weboftrust.github.io/WOT-terms/docs/glossary/keep.md) is KERI's and ACDC's user interface with Keripy agent API as a back end.
---
title: watcher
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/watcher
md: https://weboftrust.github.io/WOT-terms/04_glossary/watcher.md
---
# watcher
an _entity_ or _component_ that keeps a copy of a [KERL](https://weboftrust.github.io/WOT-terms/docs/glossary/kerl.md) for an identifier but that is not designated by the _controller_ of the identifier as one of its witnesses. See annex [watcher](https://weboftrust.github.io/WOT-terms/docs/glossary/watcher.md).
Source: Dr. S.Smith
KERI alternative to total global ordering and consensus protocols is a mechanism called [duplicity](https://weboftrust.github.io/WOT-terms/docs/glossary/duplicity.md) detection. In the [verification](https://weboftrust.github.io/WOT-terms/docs/glossary/verifier.md) and [validation](https://weboftrust.github.io/WOT-terms/docs/glossary/validate.md) **watchers are all that matter**; they guarantee that logs are immutable by one very simple rule: "[first seen](https://weboftrust.github.io/WOT-terms/docs/glossary/first-seen.md) wins".
This would be a set of watchers (that the validators trust) that record any and all copies of key event logs (KEL) that they see. Because these watchers can be anyone and anywhere, any controller of a public identifier is at peril should they choose to publish inconsistent copies of their KEL. This removes the incentive to be duplicitous.
---
title: web-of-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/web-of-trust
md: https://weboftrust.github.io/WOT-terms/04_glossary/web-of-trust.md
---
# web-of-trust
In cryptography, a web of trust is a concept used in [PGP](https://weboftrust.github.io/WOT-terms/docs/glossary/PGP.md), [GnuPG](https://weboftrust.github.io/WOT-terms/docs/glossary/gnu-privacy-guard.md), and other `OpenPGP`\-compatible systems to establish the authenticity of the binding between a public key and its owner.
Its _decentralized_ trust model is an alternative to the centralized trust model of a public key infrastructure (`PKI`), which relies exclusively on a certificate authority (or a hierarchy of such). As with computer networks, there are many independent webs of trust, and any user (through their identity certificate) can be a part of, and a link between, multiple webs. The web of trust concept was first put forth by PGP creator Phil Zimmermann in 1992 in the manual for PGP.
More on [Wikipedia](https://en.wikipedia.org/wiki/Web_of_trust)
---
title: weight-of-weights
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/weight-of-weights
md: https://weboftrust.github.io/WOT-terms/04_glossary/weight-of-weights.md
---
# weight-of-weights
There are 2 levels in the multi-sign weighted thresholds of [multi-signatures](https://weboftrust.github.io/WOT-terms/docs/glossary/multisig.md) in [KERI](https://weboftrust.github.io/WOT-terms/docs/glossary/KERI.md) because the solution only needs to focus on _tightly cooperating teams_.
- An individual using split keys over devices
- A team of teams
All other use cases can be solved by other means in KERI (e.g. [delegation](https://weboftrust.github.io/WOT-terms/docs/glossary/delegation.md)).
It also gives the advantage that the resulting [CESR](https://weboftrust.github.io/WOT-terms/docs/glossary/CESR.md) is more straightforward. It's hard to implement a recursive weight - of weights in CESR. And because of the alleged lack of use cases, KERI don't need to go beyond two levels.
---
title: weight
description: an optional field map in the Edge section that provides edge weight property that enables directed weighted edges and operators that use weights.
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/weight
md: https://weboftrust.github.io/WOT-terms/04_glossary/weight.md
---
# weight
an optional field map in the Edge section that provides edge weight property that enables directed weighted edges and operators that use weights.
Source: Dr. S.Smith
---
title: well-known-witnesses
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/well-known-witnesses
md: https://weboftrust.github.io/WOT-terms/04_glossary/well-known-witnesses.md
---
# well-known-witnesses
Witness identifier creation by using _salts_ to initialize their key stores so that you can predict what identifiers will be created. For testing purposes only!
Don't use the creation of well-known witnesses in a production environment, but for running tests it's suitable.
---
title: witness
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/witness
md: https://weboftrust.github.io/WOT-terms/04_glossary/witness.md
---
# witness
a witness is an entity or component designated (trusted) by the controller of an identifier. The primary role of a witness is to verify, sign, and keep events associated with an identifier. A witness is the controller of its own self-referential identifier which may or may not be the same as the identifier to which it is a witness. See also [KERI’s Algorithm for Witness Agreement](https://weboftrust.github.io/WOT-terms/docs/glossary/keri’s-algorithm-for-witness-agreement.md).
Source: Dr. S. Smith
In KERI and ACDC context, a witness is an entity or component designated (trusted) by the controller of an identifier. The primary role of a witness is to verify, sign, and keep events associated with an identifier. A witness is the controller of its own self-referential identifier which may or may not be the same as the identifier to which it is a witness.
An identifier witness, therefore, is part of its [trust basis](https://weboftrust.github.io/WOT-terms/docs/glossary/trust-domain.md) and may be controlled (but not necessarily so) by its [controller](https://weboftrust.github.io/WOT-terms/docs/glossary/controller.md). The purpose of a pool of witnesses is to protect the controller from external exploit of its identifier.
The term _[Backer](https://weboftrust.github.io/WOT-terms/docs/glossary/backer.md)_ and _Witness_ are closely related in KERI but not synonyms or interchangeable.
Be sure to understand the narrow KERI definition of Witness well. You could easily be confused, for there are dozens of papers that use the term Witness in a similar way to KERI; for example [https://ieeexplore.ieee.org/document/8644609](https://ieeexplore.ieee.org/document/8644609) or 'segregated witness' in bitcoin, but it's far from the same concept.
More in the [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
Entity that may receive, verify, and store key events for an identifier. Each witness controls its own identifier used to sign key event messages, a controller is a special case of a witness.
Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
---
title: XBRL
description: See
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/XBRL
md: https://weboftrust.github.io/WOT-terms/04_glossary/XBRL.md
---
# XBRL
[eXtensible Business Reporting Language](https://weboftrust.github.io/WOT-terms/docs/glossary/extensible-business-reporting-language.md)
---
title: xip
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/xip
md: https://weboftrust.github.io/WOT-terms/04_glossary/xip.md
---
# xip
A XIP message allows a transaction set to be a mini peer to peer exchange to become a verifiable data structure. It makes the transaction become duplicity evident.
Source [KERI meeting 2024-03-12](https://wiki.trustoverip.org/pages/viewpage.action?pageId=80876836)
---
title: zero-trust-computing
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/zero-trust-computing
md: https://weboftrust.github.io/WOT-terms/04_glossary/zero-trust-computing.md
---
# zero-trust-computing
A security model centered on the principle of "never trust, always verify." It assumes that threats can exist inside and outside the network, and thus, no entity — a device, user, or system — is inherently trusted. This approach requires continuous verification of all users and devices attempting to access network resources.
Best practices for the implementation of an autonomic identifier system should follow zero-trust computing principles. These principles are described at more length elsewhere but may be summarized as follows:
1. Network Hostility. The network is always hostile, internally & externally; the Locality is untrustworthy. Solutions must provide means to mitigate network layer security vulnerabilities (man-in-the-middle, DNS hijacking, BGP attacks).
2. E2E Security. Inter-host communication must be end-to-end signed/encrypted and data must be stored signed/encrypted. Data is signed/encrypted in motion and at rest.
3. E2E Provenance. Data flow transformations must be end-to-end provenanced using verifiable data items (verifiable data chains or VCs). Every change shall be provenanced.
4. Verify every time for everything. Every network interaction or data flow must be authenticated and authorized using best-practice cryptography.
5. Authorization is behavioral. Policies for authentication and authorization must be dynamically modified based on behavior (reputation).
6. No single point of trust. Policies for authentication and authorization must be governed by end-verified diffuse-trust distributed consensus. The diffuse trust protects the policy.
7. Hosts locked down. Hosts or host components executing any of the abovementioned logic must be locked down. Any changes to the host execution logic or behavior must be thoroughly security tested and validated over the respective possible combinations of hardware and software platforms. This means locking down key management and cryptographic operations on the devices. This includes key generation and storage, as well as signature generation and signature verification. These may benefit from the use of some form of trusted execution environment (TEE), either generally or especially in a trusted platform module (TPM) or a hardware security module (HSM). In addition to key management and cryptographic operations, special security measures must be implemented regarding the secure execution of the application logic (e.g., code injection, insecure object references, cross-site/service request forgery, cross-service scripting, etc.).
Source: Universal Identity Theory by Samuel Smith
[zero trust](https://weboftrust.github.io/WOT-terms/docs/glossary/zero-trust.md)
---
title: zero-trust
description: Definition
source_url:
html: https://weboftrust.github.io/WOT-terms/04_glossary/zero-trust
md: https://weboftrust.github.io/WOT-terms/04_glossary/zero-trust.md
---
# zero-trust
a Zero Trust approach trusts no one.
Zero Trust is a shift of network defenses toward a more comprehensive IT security model that allows organizations to restrict access controls to networks, applications, and environment without sacrificing performance and user experience. As more organizations do more computing outside their perimeter in the cloud, security teams find it increasingly difficult to trust or identify who and what should be allowed or trusted with access to their networks. As a result, an increasing number of organizations are adopting Zero Trust as an element or a component of their trust network architecture and enterprise security strategy.
Zero Trust is a security concept that requires all users, even those inside the organization’s enterprise network, to be authenticated, authorized, and continuously validating security configuration and posture, before being granted or keeping access to applications and data. This approach leverages advanced technologies such as multi-factor authentication, identity and access management (IAM), and next-generation endpoint security technology to verify the user’s identity and maintain system security.
---
title: WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
description: 4171595971390, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/08_annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
md: https://weboftrust.github.io/WOT-terms/08_annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc.md
---
# WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
title: "Authentic Chained Data Containers (ACDC)" abbrev: "ACDC" category: info
docname: draft-ssmith-acdc-latest
ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
author:
- name: S. Smith organization: ProSapien LLC email: [sam@prosapien.com](mailto:sam@prosapien.com)
normative:
ACDC\_ID: target: [https://github.com/trustoverip/tswg-acdc-specification](https://github.com/trustoverip/tswg-acdc-specification) title: IETF ACDC (Authentic Chained Data Containers) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
KERI\_ID: target: [https://github.com/WebOfTrust/ietf-keri](https://github.com/WebOfTrust/ietf-keri) title: IETF KERI (Key Event Receipt Infrastructure) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
CESR\_ID: target: [https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr) title: IETF CESR (Composable Event Streaming Representation) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
SAID\_ID: target: [https://github.com/WebOfTrust/ietf-said](https://github.com/WebOfTrust/ietf-said) title: IETF SAID (Self-Addressing IDentifier) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
OOBI\_ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF OOBI (Out-Of-Band-Introduction) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
PTEL\_ID: target: [https://github.com/WebOfTrust/ietf-ptel](https://github.com/WebOfTrust/ietf-ptel) title: IETF PTEL (Public Transaction Event Log) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
Proof\_ID: target: [https://github.com/WebOfTrust/ietf-cesr-proof](https://github.com/WebOfTrust/ietf-cesr-proof) title: IETF CESR-Proof Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
IPEX\_ID: target: [https://github.com/WebOfTrust/ietf-ipex](https://github.com/WebOfTrust/ietf-ipex) title: IPEX (Issuance and Presentation EXchange) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
DIDK\_ID: target: [https://github.com/WebOfTrust/ietf-did-keri](https://github.com/WebOfTrust/ietf-did-keri) title: IETF DID-KERI Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
RFC6901: target: [https://datatracker.ietf.org/doc/html/rfc6901](https://datatracker.ietf.org/doc/html/rfc6901) title: JavaScript Object Notation (JSON) Pointer author:
```
-
name: Paul C. Bryan
-
name: Kris Zyp
-
name: Mark Nottingham
date: 2003
```
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
RFC8259: target: [https://datatracker.ietf.org/doc/html/rfc8259](https://datatracker.ietf.org/doc/html/rfc8259) title: JSON (JavaScript Object Notation)
RFC4627: target: [https://datatracker.ietf.org/doc/rfc4627/](https://datatracker.ietf.org/doc/rfc4627/) title: The application/json Media Type for JavaScript Object Notation (JSON)
JSch: target: [https://json-schema.org](https://json-schema.org) title: JSON Schema
JSch\_202012: target: [https://json-schema.org/draft/2020-12/release-notes.html](https://json-schema.org/draft/2020-12/release-notes.html) title: "JSON Schema 2020-12"
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
RFC3986: target: [https://datatracker.ietf.org/doc/html/rfc3986](https://datatracker.ietf.org/doc/html/rfc3986) title: "Uniform Resource Identifier (URI): Generic Syntax"
RFC8820: target: [https://datatracker.ietf.org/doc/html/rfc8820](https://datatracker.ietf.org/doc/html/rfc8820) title: URI Design and Ownership
informative:
ACDC\_WP: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/ACDC.web.pdf) title: Authentic Chained Data Containers (ACDC) White Paper
VCEnh: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC\_Enhancement\_Strategy.md](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC_Enhancement_Strategy.md) title: VC Spec Enhancement Strategy Proposal
ACDC\_TF: target: [https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force](https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force) title: ACDC (Authentic Chained Data Container) Task Force
TOIP: target: [https://trustoverip.org](https://trustoverip.org) title: Trust Over IP (ToIP) Foundation
IETF: target: [https://www.ietf.org](https://www.ietf.org) title: IETF (Internet Engineering Task Force
KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
ITPS: target: [https://en.wikipedia.org/wiki/Information-theoretic\_security](https://en.wikipedia.org/wiki/Information-theoretic_security) title: Information-Theoretic and Perfect Security
OTP: target: [https://en.wikipedia.org/wiki/One-time\_pad](https://en.wikipedia.org/wiki/One-time_pad) title: One-Time-Pad
VCphr: target: [https://www.ciphermachinesandcryptology.com/en/onetimepad.htm](https://www.ciphermachinesandcryptology.com/en/onetimepad.htm) title: Vernom Cipher (OTP)
SSplt: target: [https://www.ciphermachinesandcryptology.com/en/secretsplitting.htm](https://www.ciphermachinesandcryptology.com/en/secretsplitting.htm) title: Secret Splitting
SShr: target: [https://en.wikipedia.org/wiki/Secret\_sharing](https://en.wikipedia.org/wiki/Secret_sharing) title: Secret Sharing
CSPRNG: target: [https://en.wikipedia.org/wiki/Cryptographically-secure\_pseudorandom\_number\_generator](https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator) title: Cryptographically-secure pseudorandom number generator (CSPRNG)
IThry: target: [https://en.wikipedia.org/wiki/Information\_theory](https://en.wikipedia.org/wiki/Information_theory) title: Information Theory
CAcc: target: [https://en.wikipedia.org/wiki/Accumulator\_(cryptography)](https://en.wikipedia.org/wiki/Accumulator_\(cryptography\)) title: Cryptographic Accumulator
XORA: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/XORA.md](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/XORA.md) title: XORA (XORed Accumulator)
GLEIF: target: [https://www.gleif.org/en/](https://www.gleif.org/en/) title: GLEIF (Global Legal Entity Identifier Foundation)
vLEI: target: [https://github.com/WebOfTrust/vLEI](https://github.com/WebOfTrust/vLEI) title: vLEI (verifiable Legal Entity Identifier) Definition
GLEIF\_vLEI: target: [https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei](https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei/introducing-the-verifiable-lei-vlei) title: GLEIF vLEI (verifiable Legal Entity Identifier)
GLEIF\_KERI: target: [https://github.com/WebOfTrust/vLEI](https://github.com/WebOfTrust/vLEI) title: GLEIF with KERI Architecture
W3C\_VC: target: [https://www.w3.org/TR/vc-data-model/](https://www.w3.org/TR/vc-data-model/) title: W3C Verifiable Credentials Data Model v1.1
W3C\_DID: target: [https://w3c-ccg.github.io/did-spec/](https://w3c-ccg.github.io/did-spec/) title: W3C Decentralized Identifiers (DIDs) v1.0
Salt: target: [https://medium.com/@fridakahsas/salt-nonces-and-ivs-whats-the-difference-d7a44724a447](https://medium.com/@fridakahsas/salt-nonces-and-ivs-whats-the-difference-d7a44724a447) title: Salts, Nonces, and Initial Values
RB: target: [https://en.wikipedia.org/wiki/Rainbow\_table](https://en.wikipedia.org/wiki/Rainbow_table) title: Rainbow Table
DRB: target: [https://www.commonlounge.com/discussion/2ee3f431a19e4deabe4aa30b43710aa7](https://www.commonlounge.com/discussion/2ee3f431a19e4deabe4aa30b43710aa7) title: Dictionary Attacks, Rainbow Table Attacks and how Password Salting defends against them
BDay: target: [https://en.wikipedia.org/wiki/Birthday\_attack](https://en.wikipedia.org/wiki/Birthday_attack) title: Birthday Attack
BDC: target: [https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/](https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/) title: Birthday Attacks, Collisions, And Password Strength
HCR: target: [https://en.wikipedia.org/wiki/Collision\_resistance](https://en.wikipedia.org/wiki/Collision_resistance) title: Hash Collision Resistance
QCHC: target: [https://cr.yp.to/hash/collisioncost-20090823.pdf](https://cr.yp.to/hash/collisioncost-20090823.pdf) title: "Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete?"
EdSC: target: [https://eprint.iacr.org/2020/823](https://eprint.iacr.org/2020/823) title: "The Provable Security of Ed25519: Theory and Practice Report"
PSEd: target: [https://ieeexplore.ieee.org/document/9519456?denied=](https://ieeexplore.ieee.org/document/9519456?denied=) title: "The Provable Security of Ed25519: Theory and Practice" seriesinfo: 2021 IEEE Symposium on Security and Privacy (SP) author:
```
-
ins: J. Brendel
name: Jacqueline Brendel
-
ins: C. Cremers
name: Cas Cremers
-
ins: D. Jackson
name: Dennis Jackson
-
ins: M. Zhao
name: Mang Zhao
date: 2021-05-24
```
TMEd: target: [https://eprint.iacr.org/2020/1244.pdf](https://eprint.iacr.org/2020/1244.pdf) title: Taming the many EdDSAs
JSchCp: target: "[https://json-schema.org/understanding-json-schema/reference/combining.html"](https://json-schema.org/understanding-json-schema/reference/combining.html%22) title: "Schema Composition in JSON Schema"
JSchRE: target: "[https://json-schema.org/understanding-json-schema/reference/regular\_expressions.html"](https://json-schema.org/understanding-json-schema/reference/regular_expressions.html%22) title: "Regular Expressions in JSON Schema"
JSchId: target: "[https://json-schema.org/understanding-json-schema/structuring.html#schema-identification"](https://json-schema.org/understanding-json-schema/structuring.html#schema-identification%22) title: "JSON Schema Identification"
JSchCx: target: "[https://json-schema.org/understanding-json-schema/structuring.html#base-uri"](https://json-schema.org/understanding-json-schema/structuring.html#base-uri%22) title: "Complex JSON Schema Structuring"
RC: target: [https://en.wikipedia.org/wiki/Ricardian\_contract](https://en.wikipedia.org/wiki/Ricardian_contract) title: Ricardian Contract
CLC: target: [https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=2045818](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818) title: "Chain-Link Confidentiality"
DHKE: target: [https://www.infoworld.com/article/3647751/understand-diffie-hellman-key-exchange.html](https://www.infoworld.com/article/3647751/understand-diffie-hellman-key-exchange.html) title: "Diffie-Hellman Key Exchange"
KeyEx: target: [https://libsodium.gitbook.io/doc/key\_exchange](https://libsodium.gitbook.io/doc/key_exchange) title: Key Exchange
IDSys: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf) title: Identity System Essentials
Hash: target: [https://en.wikipedia.org/wiki/Cryptographic\_hash\_function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) title: Cryptographic Hash Function
Mrkl: target: [https://en.wikipedia.org/wiki/Merkle\_tree](https://en.wikipedia.org/wiki/Merkle_tree) title: Merkle Tree
TwoPI: target: [https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/](https://flawed.net.nz/2018/02/21/attacking-merkle-trees-with-a-second-preimage-attack/) title: Second Pre-image Attack on Merkle Trees
MTSec: target: [https://blog.enuma.io/update/2019/06/10/merkle-trees-not-that-simple.html](https://blog.enuma.io/update/2019/06/10/merkle-trees-not-that-simple.html) title: Merkle Tree Security
DSig: target: [https://en.wikipedia.org/wiki/Digital\_signature](https://en.wikipedia.org/wiki/Digital_signature) title: Digital Signature
Level: target: [https://en.wikipedia.org/wiki/Security\_level](https://en.wikipedia.org/wiki/Security_level) title: Security Level
Twin: target: [https://en.wikipedia.org/wiki/Digital\_twin](https://en.wikipedia.org/wiki/Digital_twin) title: Digital Twin
TMal: target: [https://en.wikipedia.org/wiki/Transaction\_malleability\_problem](https://en.wikipedia.org/wiki/Transaction_malleability_problem) title: Transaction Malleability
PGM: target: [http://ceur-ws.org/Vol-2100/paper26.pdf](http://ceur-ws.org/Vol-2100/paper26.pdf) title: The Property Graph Database Model author: ins: R. Angles name: Renzo Angles date: 2018
Dots: target: [https://arxiv.org/pdf/1006.2361.pdf](https://arxiv.org/pdf/1006.2361.pdf) title: Constructions from Dots and Lines author:
```
-
ins: M. Rodriguez
name: Marko A. Rodriguez
-
ins: P. Neubauer
name: Peter Neubauer
date: 2010
```
KG: target: [https://arxiv.org/pdf/2003.02320.pdf](https://arxiv.org/pdf/2003.02320.pdf) title: Knowledge Graphs
Abuse: target: [https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md](https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.md) title: Alice Attempts to Abuse a Verifiable Credential
SKEM: target: [https://eprint.iacr.org/2021/509](https://eprint.iacr.org/2021/509) title: On using the same key pair for Ed25519 and an X25519 based KEM
tags: "IETF, ACDC, CESR, SAID, KERI"
\--- abstract
An authentic chained data container (ACDC) {{ACDC\_ID}}{{ACDC\_WP}}{{VCEnh}} is an IETF {{IETF}} internet draft focused specification being incubated at the ToIP (Trust over IP) foundation {{TOIP}}{{ACDC\_TF}}. An ACDC is a variant of the W3C Verifiable Credential (VC) specification {{W3C\_VC}}. The W3C VC specification depends on the W3C DID (Decentralized IDentifier) specification {{W3C\_DID}}. A major use case for the ACDC specification is to provide GLEIF vLEIs (verifiable Legal Entity Identifiers) {{vLEI}}{{GLEIF\_vLEI}}{{GLEIF\_KERI}}. GLEIF is the Global Legal Entity Identifier Foundation {{GLEIF}}. ACDCs are dependent on a suite of related IETF focused standards associated with the KERI (Key Event Receipt Infrastructure) {{KERI\_ID}}{{KERI}} specification. These include CESR {{CESR\_ID}}, SAID {{SAID\_ID}}, PTEL {{PTEL\_ID}}, CESR-Proof {{Proof\_ID}}, IPEX {{IPEX\_ID}}, did:keri {{DIDK\_ID}}, and OOBI {{OOBI\_ID}}. Some of the major distinguishing features of ACDCs include normative support for chaining, use of composable JSON Schema {{JSch}}{{JSchCp}}, multiple serialization formats, namely, JSON {{JSON}}{{RFC4627}}, CBOR {{CBOR}}{{RFC8949}}, MGPK {{MGPK}}, and CESR {{CESR\_ID}}, support for Ricardian contracts {{RC}}, support for chain-link confidentiality {{CLC}}, a well defined security model derived from KERI {{KERI}}{{KERI\_ID}}, _compact_ formats for resource constrained applications, simple _partial disclosure_ mechanisms and simple _selective disclosure_ mechanisms. ACDCs provision data using a synergy of provenance, protection, and performance.
\--- middle
One primary purpose of the ACDC protocol is to provide granular provenanced proof-of-authorship (authenticity) of their contained data via a tree or chain of linked ACDCs (technically a directed acyclic graph or DAG). Similar to the concept of a chain-of-custody, ACDCs provide a verifiable chain of proof-of-authorship of the contained data. With a little additional syntactic sugar, this primary facility of chained (treed) proof-of-authorship (authenticity) is extensible to a chained (treed) verifiable authentic proof-of-authority (proof-of-authorship-of-authority). A proof-of-authority may be used to provide verifiable authorizations or permissions or rights or credentials. A chained (treed) proof-of-authority enables delegation of authority and delegated authorizations. These proofs of authorship and/or authority provide provenance of an ACDC itself and by association any data that is so conveyed.
The dictionary definition of **_credential_** is _evidence of authority, status, rights, entitlement to privileges, or the like_. Appropriately structured ACDCs may be used as credentials when their semantics provide verifiable evidence of authority. Chained ACDCs may provide delegated credentials.
Chains of ACDCs that merely provide proof-of-authorship (authenticity) of data may be appended to chains of ACDCs that provide proof-of-authority (delegation) to enable verifiable delegated authorized authorship of data. This is a vital facility for authentic data supply chains. Furthermore, any physical supply chain may be measured, monitored, regulated, audited, and/or archived by a data supply chain acting as a digital twin {{Twin}}. Therefore ACDCs provide the critical enabling facility for an authentic data economy and by association an authentic real (twinned) economy.
ACDCs act as securely attributed (authentic) fragments of a distributed _property graph_ (PG) {{PGM}}{{Dots}}. Thus they may be used to construct knowledge graphs expressed as property graphs {{KG}}. ACDCs enable securely-attributed and privacy-protecting knowledge graphs.
The ACDC specification (including its partial and selective disclosure mechanisms) leverages two primary cryptographic operations namely digests and digital signatures {{Hash}}{{DSig}}. These operations when used in an ACDC MUST have a security level, cryptographic strength, or entropy of approximately 128 bits {{Level}}. (See the appendix for a discussion of cryptographic strength and security)
An important property of high-strength cryptographic digests is that a verifiable cryptographic commitment (such as a digital signature) to the digest of some data is equivalent to a commitment to the data itself. ACDCs leverage this property to enable compact chains of ACDCs that anchor data via digests. The data _contained_ in an ACDC may therefore be merely its equivalent anchoring digest. The anchored data is thereby equivalently authenticated or authorized by the chain of ACDCs.
An ACDC may be abstractly modeled as a nested `key: value` mapping. To avoid confusion with the cryptographic use of the term _key_ we instead use the term _field_ to refer to a mapping pair and the terms _field label_ and _field value_ for each member of a pair. These pairs can be represented by two tuples e.g `(label, value)`. We qualify this terminology when necessary by using the term _field map_ to reference such a mapping. _Field maps_ may be nested where a given _field value_ is itself a reference to another _field map_. We call this nested set of fields a _nested field map_ or simply a _nested map_ for short. A _field_ may be represented by a framing code or block delimited serialization. In a block delimited serialization, such as JSON, each _field map_ is represented by an object block with block delimiters such as `{}` {{RFC8259}}{{JSON}}{{RFC4627}}. Given this equivalence, we may also use the term _block_ or _nested block_ as synonymous with _field map_ or _nested field map_. In many programming languages, a field map is implemented as a dictionary or hash table in order to enable performant asynchronous lookup of a _field value_ from its _field label_. Reproducible serialization of _field maps_ requires a canonical ordering of those fields. One such canonical ordering is called insertion or field creation order. A list of `(field, value)` pairs provides an ordered representation of any field map. Most programming languages now support ordered dictionaries or hash tables that provide reproducible iteration over a list of ordered field `(label, value)` pairs where the ordering is the insertion or field creation order. This enables reproducible round trip serialization/deserialization of _field maps_. ACDCs depend on insertion ordered field maps for canonical serialization/deserialization. ACDCs support multiple serialization types, namely JSON, CBOR, MGPK, and CESR but for the sake of simplicity, we will only use JSON herein for examples {{RFC8259}}{{JSON}}. The basic set of normative field labels in ACDC field maps is defined in the following table.
These are reserved field labels at the top level of an ACDC.
| Label | Title | Description |
| --- | --- | --- |
| `v` | Version String | Regexable format: ACDCvvSSSShhhhhh\_ that provides protocol type, version, serialization type, size, and terminator. |
| `d` | Digest (SAID) | Self-referential fully qualified cryptographic digest of enclosing map. |
| `u` | UUID | Random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `i` | Issuer Identifier (AID) | Autonomic IDentifier whose Control authority is established via KERI verifiable key state. |
| `ri` | Registry Identifier | Issuance and/or revocation, transfer, or retraction registry for ACDC derived from Issuer Identifier. |
| `s` | Schema | Either the SAID of a JSON Schema block or the block itself. |
| `a` | Attribute | Either the SAID of a block of attributes or the block itself. |
| `A` | Attribute Aggregate | Either the Aggregate of a selectively disclosable block of attributes or the block itself. |
| `e` | Edge | Either the SAID of a block of edges or the block itself. |
| `r` | Rule | Either the SAID a block of rules or the block itself. |
| `n` | Node | SAID of another ACDC as the terminating point of a directed edge that connects the encapsulating ACDC node to the specified ACDC node as a fragment of a distributed property graph (PG). |
| `o` | Operator | Either unary operator on edge or m-ary operator on edge-group in edge section. Enables expressing of edge logic on edge subgraph. |
| `w` | Weight | Edge weight property that enables default property for directed weighted edges and operators on directed weighted edges. |
| `l` | Legal Language | Text of Ricardian contract clause. |
These may appear at other levels besides the top-level of an ACDC but are nonetheless reserved.
| Label | Title | Description |
| --- | --- | --- |
| `d` | Digest (SAID) | Self-referential fully qualified cryptographic digest of enclosing map. |
| `u` | UUID | Random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `i` | Identifier (AID) | Context dependent AID as determined by its enclosing map such as Issuee Identifier. |
| `n` | Node | SAID of another ACDC as the terminating point (vertex) of a directed edge that connects the encapsulating ACDC node to the specified ACDC node as a fragment of a distributed property graph (PG). |
| `o` | Operator | Either unary operator on edge or m-ary operator on edge-group in edge section. Enables expressing of edge logic on edge subgraph. |
| `w` | Weight | Edge weight property that enables default property for directed weighted edges and operators on directed weighted edges. |
| `l` | Legal Language | Text of Ricardian contract clause. |
The primary field labels are compact in that they use only one or two characters. ACDCs are meant to support resource-constrained applications such as supply chain or IoT (Internet of Things) applications. Compact labels better support resource-constrained applications in general. With compact labels, the over-the-wire verifiable signed serialization consumes a minimum amount of bandwidth. Nevertheless, without loss of generality, a one-to-one normative semantic overlay using more verbose expressive field labels may be applied to the normative compact labels after verification of the over-the-wire serialization. This approach better supports bandwidth and storage constraints on transmission while not precluding any later semantic post-processing. This is a well-known design pattern for resource-constrained applications.
The version string, `v`, field MUST be the first field in any top-level ACDC field map. It provides a regular expression target for determining the serialization format and size (character count) of a serialized ACDC. A stream-parser may use the version string to extract and deserialize (deterministically) any serialized ACDC in a stream of serialized ACDCs. Each ACDC in a stream may use a different serialization type.
The format of the version string is `ACDCvvSSSShhhhhh_`. The first four characters `ACDC` indicate the enclosing field map serialization. The next two characters, `vv` provide the lowercase hexadecimal notation for the major and minor version numbers of the version of the ACDC specification used for the serialization. The first `v` provides the major version number and the second `v` provides the minor version number. For example, `01` indicates major version 0 and minor version 1 or in dotted-decimal notation `0.1`. Likewise `1c` indicates major version 1 and minor version decimal 12 or in dotted-decimal notation `1.12`. The next four characters `SSSS` indicate the serialization type in uppercase. The four supported serialization types are `JSON`, `CBOR`, `MGPK`, and `CESR` for the JSON, CBOR, MessagePack, and CESR serialization standards respectively {{JSON}}{{RFC4627}}{{CBOR}}{{RFC8949}}{{MGPK}}{{CESR\_ID}}. The next six characters provide in lowercase hexadecimal notation the total number of characters in the serialization of the ACDC. The maximum length of a given ACDC is thereby constrained to be _224 = 16,777,216_ characters in length. The final character `-` is the version string terminator. This enables later versions of ACDC to change the total version string size and thereby enable versioned changes to the composition of the fields in the version string while preserving deterministic regular expression extractability of the version string. Although a given ACDC serialization type may have a field map delimiter or framing code characters that appear before (i.e. prefix) the version string field in a serialization, the set of possible prefixes is sufficiently constrained by the allowed serialization protocols to guarantee that a regular expression can determine unambiguously the start of any ordered field map serialization that includes the version string as the first field value. Given the version string, a parser may then determine the end of the serialization so that it can extract the full ACDC from the stream without first deserializing it. This enables performant stream parsing and off-loading of ACDC streams that include any or all of the supported serialization types.
Some fields in ACDCs may have for their value either a _field map_ or a SAID. A SAID follows the SAID protocol {{SAID\_ID}}. Essentially a SAID is a Self-Addressing IDentifier (self-referential content addressable). A SAID is a special type of cryptographic digest of its encapsulating _field map_ (block). The encapsulating block of a SAID is called a SAD (Self-Addressed Data). Using a SAID as a _field value_ enables a more compact but secure representation of the associated block (SAD) from which the SAID is derived. Any nested field map that includes a SAID field (i.e. is, therefore, a SAD) may be compacted into its SAID. The uncompacted blocks for each associated SAID may be attached or cached to optimize bandwidth and availability without decreasing security.
Several top-level ACDC fields may have for their value either a serialized _field map_ or the SAID of that _field map_. Each SAID provides a stable universal cryptographically verifiable and agile reference to its encapsulating block (serialized _field map_). Specifically, the value of top-level `s`, `a`, `e`, and `r` fields may be replaced by the SAID of their associated _field map_. When replaced by their SAID, these top-level sections are in _compact_ form.
Recall that a cryptographic commitment (such as a digital signature or cryptographic digest) on a given digest with sufficient cryptographic strength including collision resistance {{HCR}}{{QCHC}} is equivalent to a commitment to the block from which the given digest was derived. Specifically, a digital signature on a SAID makes a verifiable cryptographic non-repudiable commitment that is equivalent to a commitment on the full serialization of the associated block from which the SAID was derived. This enables reasoning about ACDCs in whole or in part via their SAIDS in a fully interoperable, verifiable, compact, and secure manner. This also supports the well-known bow-tie model of Ricardian Contracts {{RC}}. This includes reasoning about the whole ACDC given by its top-level SAID, `d`, field as well as reasoning about any nested sections using their SAIDS.
The purpose of the UUID, `u`, field in any block is to provide sufficient entropy to the SAID, `d`, field of the associated block to make computationally infeasible any brute force attacks on that block that attempt to discover the block contents from the schema and the SAID. The UUID, `u`, field may be considered a salty nonce {{Salt}}. Without the entropy provided the UUID, `u`, field, an adversary may be able to reconstruct the block contents merely from the SAID of the block and the schema of the block using a rainbow or dictionary attack on the set of field values allowed by the schema {{RB}}{{DRB}}. The effective security level, entropy, or cryptographic strength of the schema-compliant field values may be much less than the cryptographic strength of the SAID digest. Another way of saying this is that the cardinality of the power set of all combinations of allowed field values may be much less than the cryptographic strength of the SAID. Thus an adversary could successfully discover via brute force the exact block by creating digests of all the elements of the power set which may be small enough to be computationally feasible instead of inverting the SAID itself. Sufficient entropy in the `u` field ensures that the cardinality of the power set allowed by the schema is at least as great as the entropy of the SAID digest algorithm itself.
A UUID, `u` field may optionally appear in any block (field map) at any level of an ACDC. Whenever a block in an ACDC includes a UUID, `u`, field then its associated SAID, `d`, field makes a blinded commitment to the contents of that block. The UUID, `u`, field is the blinding factor. This makes that block securely partially disclosable or even selectively disclosable notwithstanding disclosure of the associated schema of the block. The block contents can only be discovered given disclosure of the included UUID field. Likewise when a UUID, `u`, field appears at the top level of an ACDC then that top-level SAID, `d`, field makes a blinded commitment to the contents of the whole ACDC itself. Thus the whole ACDC, not merely some block within the ACDC, may be disclosed in a privacy-preserving (correlation minimizing) manner.
Some fields, such as the `i`, Issuer identifier field MUST each have an AID (Autonomic IDentifier) as its value. An AID is a fully qualified Self-Certifying IDentifier (SCID) that follows the KERI protocol {{KERI}}{{KERI\_ID}}. A related type of identifier field is the `ri`, registry identifier field. The `ri` field is cryptographically derived from the Issuer identifier field value so has securely attributable control authority via the AID from which it is derived. A SCID is derived from one or more `(public, private)` key pairs using asymmetric or public-key cryptography to create verifiable digital signatures {{DSig}}. Each AID has a set of one or more controllers who each control a private key. By virtue of their private key(s), the set of controllers may make statements on behalf of the associated AID that is backed by uniquely verifiable commitments via digital signatures on those statements. Any entity may then verify those signatures using the associated set of public keys. No shared or trusted relationship between the controllers and verifiers is required. The verifiable key state for AIDs is established with the KERI protocol {{KERI}}{{KERI\_ID}}. The use of AIDS enables ACDCs to be used in a portable but securely attributable, fully decentralized manner in an ecosystem that spans trust domains.
Because KERI is agnostic about the namespace for any particular AID, different namespace standards may be used to express KERI AIDs or identifiers derived from AIDs as the value of thes AID related fields in an ACDC. The examples below use the W3C DID namespace specification with the `did:keri` method {{DIDK\_ID}}. But the examples would have the same validity from a KERI perspective if some other supported namespace was used or no namespace was used at all. The latter case consists of a bare KERI AID (identifier prefix) expressed in CESR format {{CESR\_ID}}.
The top-level selectively-disclosable attribute aggregate section, `A`, field value is an aggregate of cryptographic commitments used to make a commitment to a set (bundle) of selectively-disclosable attributes. The value of the attribute aggregate, `A`, field depends on the type of selective disclosure mechanism employed. For example, the aggregate value could be the cryptographic digest of the concatenation of an ordered set of cryptographic digests, a Merkle tree root digest of an ordered set of cryptographic digests, or a cryptographic accumulator.
ACDC leverages several closely related mechanisms for what can be called **_graduated disclosure_**. _Graduated disclosure_ enables adherence to the principle of least disclosure which is expressed as follows:
> The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. {{IDSys}}
To clarify, _graduated disclosure_ enables a potential Discloser to follow the principle of _least disclosure_ by providing the least amount of information i.e. partial, incomplete, or uncorrelatable information needed to further a transaction.
The important insight is that one type of transaction enabled by least disclosure is a transaction that specifically enables further disclosure. In other words, disclose enough to enable more disclosure which in turn may enable even more disclosure. This is the essence of _graduated disclosure_. This progression of successive least graduated disclosures to enable a transaction that itself enables a farther least graduated disclosure forms a recursive loop of least disclosure enabled transactions. In other words, the principle of least disclosure may be applied recursively.
A type of transaction that leverages _graduated disclosure_ to enable further disclosure we call a **_contractually protected disclosure_** transaction. In a contractually protected disclosure, the potential Discloser first makes an offer using the least (partial) disclosure of some information about other information to be disclosed (full disclosure) contingent on the potential Disclosee first agreeing to the contractual terms provided in the offer. The contractual terms could, for example, limit the disclosure to third parties of the yet to be disclosed information. But those contractual terms may also include provisions that protect against liability or other concerns not merely disclosure to third parties.
One special case of a _contractually protected disclosure_ is a **_chain-link confidential disclosure_** {{CLC}}.
Another special case of _contractually protected disclosure_ is a **_contingent-disclosure_**. In a _contingent disclosure_ some contingency is specified in the rule section that places an obligation by some party to make a disclosure when the contingency is satisfied. This might be recourse given the breach of some other term of the contract. When that contingency is met then the contingent disclosure MUST be made by the party whose responsibility it is to satisfy that disclosure obligation. The responsible party may be the Discloser of the ACDC or it may be some other party such as an escrow agent. The contingent disclosure clause may reference a cryptographic commitment to a private ACDC or private attribute ACDC (partial disclosure) that satisfies via its full disclosure the contingent disclosure requirement. Contingent disclosure may be used to limit the actual disclosure of personally identifying information (PII) to a just-in-time, need-to-know basis (i.e upon the contingency) and not a priori. As long as the Discloser and Disclosee trust the escrow agent and the verifiability of the committment, there is no need to disclose PII about the discloser in order to enable a transaction, but merely an agreement to the terms of the contingency. This enables something called **_latent accountability_**. Recourse via PII is latent in the contingent disclosure but is not ever realized (actualized) until recourse is truly needed. The minimizes inadvertent leakage while protecting the Disclosee.
ACDCs employ three specific closely related types of _graduated disclosure_. These are **_compact disclosure_**, **_partial disclosure_**, and **_selective disclosure_**. The mechanism for _compact disclosure_ is a cryptographic digest of the content expressed in the form of a SAID of that content. Both partial and selective disclosure rely on the compact disclosure of content that is also cryptographically blinded or hidden. Content in terms of an ACDC means a block (field map or field map array).
The difference between **_partial disclosure_** and **_selective disclosure_** of a given block is determined by the correlatability of the disclosed field(s) after **_full disclosure_** of the detailed field value with respect to its enclosing block (field map or field map array). A _partially disclosable_ field becomes correlatable after _full disclosure_. Whereas a _selectively disclosable_ field may be excluded from the _full disclosure_ of any other _selectively disclosable_ fields in the _selectively disclosable_ block (usually a field map array). After such _selective disclosure_, the selectively disclosed fields are not correlatable to the so-far undisclosed but selectively disclosable fields in that block (field map array).
When used in the context of _selective disclosure_, _full disclosure_ means detailed disclosure of the selectively disclosed attributes not detailed disclosure of all selectively disclosable attributes. Whereas when used in the context of _partial disclosure_, _full disclosure_ means detailed disclosure of the field map that was so far only partially disclosed.
_Partial disclosure_ is an essential mechanism needed to support both performant exchange of information and contractually protected disclosure such as chain-link confidentiality on exchanged information {{CLC}}. The exchange of only the SAID of a given field map is a type of _partial disclosure_. Another type of _partial disclosure_ is the disclosure of validatable metadata about a detailed field map e.g. the schema of a field map.
The SAID of a field map provides a _compact_ cryptographically equivalent commitment to the yet to be undisclosed field map details. A later exchange of the uncompacted field map detail provides _full disclosure_. Any later _full disclosure_ is verifiable to an earlier _partial disclosure_. Partial disclosure via compact SAIDs enables the scalable repeated verifiable exchange of SAID references to cached full disclosures. Multiple SAID references to cached fully disclosed field maps may be transmitted compactly without redundant retransmission of the full details each time a new reference is transmitted. Likewise, _partial disclosure_ via SAIDs also supports the bow-tie model of Ricardian contracts {{RC}}. Similarly, the schema of a field map is metadata about the structure of the field map this is validatable given the full disclosure of the field map. The details of_compact_ and/or confidential exchange mechanisms that leverage partial disclosure are explained later. When the field map includes sufficient cryptographic entropy such as through a UUID field (salty nonce), then the SAID of that field map effectively blinds the contents of the field map. This enables the field map contents identified by its SAID and characterized by its schema (i.e. partial disclosure) to remain private until later full disclosure.
_Selective disclosure_, on the other hand, is an essential mechanism needed to unbundle in a correlation minimizing way a single commitment by an Issuer to a bundle of fields (i.e. a nested array or list or tuple of fields) as a whole. This allows separating a "stew" (bundle) of "ingredients" (attributes) into its constituent "ingredients" (attributes) without correlating the constituents via the Issuer's commitment to the "stew" (bundle) as a whole.
Notable is the fact that there are no top-level type fields in an ACDC. This is because the schema, `s`, field itself is the type field for the ACDC and its parts. ACDCs follow the design principle of separation of concerns between a data container's actual payload information and the type information of that container's payload. In this sense, type information is metadata, not data. The schema dialect used by ACDCs is JSON Schema 2020-12 {{JSch}}{{JSch\_202012}}. JSON Schema supports composable schema (sub-schema), conditional schema (sub-schema), and regular expressions in the schema. Composability enables a validator to ask and answer complex questions about the type of even optional payload elements while maintaining isolation between payload information and type (structure) information about the payload {{JSchCp}}{{JSchRE}}{{JSchId}}{{JSchCx}}. A static but composed schema allows a verifiably immutable set of variants. Although the set is immutable, the variants enable graduated but secure disclosure. ACDC's use of JSON Schema MUST be in accordance with the ACDC defined profile as defined herein. The exceptions are defined below.
The usual field label for SAID fields in ACDCs is `d`. In the case of the schema section, however, the field label for the SAID of the schema section is `$id`. This repurposes the schema id field label, `$id` as defined by JSON Schema {{JSchId}}{{JSchCx}}. The top-level id, `$id`, field value in a JSON Schema provides a unique identifier of the schema instance. In a usual (non-ACDC) schema the value of the id, `$id`, field is expressed as a URI. This is called the _Base URI_ of the schema. In an ACDC schema, however, the top-level id, `$id`, field value is repurposed. Its value MUST include the SAID of the schema. This ensures that the ACDC schema is static and verifiable to their SAIDS. A verifiably static schema satisfies one of the essential security properties of ACDCs as discussed below. There are several ACDC supported formats for the value of the top-level id, `$id`, field but all of the formats MUST include the SAID of the schema (see below). Correspondingly, the value of the top-level schema, `s`, field MUST be the SAID included in the schema's top-level `$id` field. The detailed schema is either attached or cached and maybe discovered via its SAIDified, id, `$id`, field value.
When an id, '$id', field appears in a sub-schema it indicates a bundled sub-schema called a schema resource {{JSchId}}{{JSchCx}}. The value of the id, '$id', field in any ACDC bundled sub-schema resource MUST include the SAID of that sub-schema using one of the formats described below. The sub-schema so bundled MUST be verifiable against its referenced and embedded SAID value. This ensures secure bundling.
For security reasons, the full schema of an ACDC must be completely self-contained and statically fixed (immutable) for that ACDC. By this, we mean that no dynamic schema references or dynamic schema generation mechanisms are allowed.
Should an adversary successfully attack the source that provides the dynamic schema resource and change the result provided by that reference, then the schema validation on any ACDC that uses that dynamic schema reference may fail. Such an attack effectively revokes all the ACDCs that use that dynamic schema reference. We call this a **_schema revocation_** attack.
More insidiously, an attacker could shift the semantics of the dynamic schema in such a way that although the ACDC still passes its schema validation, the behavior of the downstream processing of that ACDC is changed by the semantic shift. This we call a **_semantic malleability_** attack. It may be considered a new type of _transaction malleability_ attack {{TMal}}.
To prevent both forms of attack, all schema must be static, i.e. schema MUST be SADs and therefore verifiable against their SAIDs.
To elaborate, the serialization of a static schema may be self-contained. A compact commitment to the detailed static schema may be provided by its SAID. In other words, the SAID of a static schema is a verifiable cryptographic identifier for its SAD. Therefore all ACDC compliant schema must be SADs. In other words, they MUST therefore be _SAIDified_. The associated detailed static schema (uncompacted SAD) is cryptographically bound and verifiable to its SAID.
The JSON Schema specification allows complex schema references that may include non-local URI references {{JSchId}}{{JSchCx}}{{RFC3986}}{{RFC8820}}. These references may use the `$id` or `$ref` keywords. A relative URI reference provided by a `$ref` keyword is resolved against the _Base URI_ provided by the top-level `$id` field. When this top-level _Base URI_ is non-local then all relative `$ref` references are therefore also non-local. A non-local URI reference provided by a `$ref` keyword may be resolved without reference to the _Base URI_.
In general, schema indicated by non-local URI references (`$id` or `$ref`) MUST NOT be used because they are not cryptographically end-verifiable. The value of the underlying schema resource so referenced may change (mutate). To restate, a non-local URI schema resource is not end-verifiable to its URI reference because there is no cryptographic binding between URI and resource {{RFC3986}}{{RFC8820}}.
This does not preclude the use of remotely cached SAIDified schema resources because those resources are end-verifiable to their embedded SAID references. Said another way, a SAIDified schema resource is itself a SAD (Self-Address Data) referenced by its SAID. A URI that includes a SAID may be used to securely reference a remote or distributed SAIDified schema resource because that resource is fixed (immutable, nonmalleable) and verifiable to both the SAID in the reference and the embedded SAID in the resource so referenced. To elaborate, a non-local URI reference that includes an embedded cryptographic commitment such as a SAID is verifiable to the underlying resource when that resource is a SAD. This applies to JSON Schema as a whole as well as bundled sub-schema resources.
There ACDC supported formats for the value of the top-level id, `$id`, field are as follows:
- Bare SAIDs may be used to refer to a SAIDified schema as long as the JSON schema validator supports bare SAID references. By default, many if not all JSON schema validators support bare strings (non-URIs) for the _Base URI_ provided by the top-level `$id` field value.
- The `sad:` URI scheme may be used to directly indicate a URI resource that safely returns a verifiable SAD. For example `sad:SAID` where _SAID_ is replaced with the actual SAID of a SAD that provides a verifiable non-local reference to JSON Schema as indicated by the mime-type of `schema+json`.
- The IETF KERI OOBI internet draft specification provides a URL syntax that references a SAD resource by its SAID at the service endpoint indicated by that URL {{OOBI\_ID}}. Such remote OOBI URLs are also safe because the provided SAD resource is verifiable against the SAID in the OOBI URL. Therefore OOBI URLs are also acceptable non-local URI references for JSON Schema {{OOBI\_ID}}{{RFC3986}}{{RFC8820}}.
- The `did:` URI scheme may be used safely to prefix non-local URI references that act to namespace SAIDs expressed as DID URIs or DID URLs. DID resolvers resolve DID URLs for a given DID method such as `did:keri` {{DIDK\_ID}} and may return DID docs or DID doc metadata with SAIDified schema or service endpoints that return SAIDified schema or OOBIs that return SAIDified schema {{RFC3986}}{{RFC8820}}{{OOBI\_ID}}. A verifiable non-local reference in the form of DID URL that includes the schema SAID is resolved safely when it dereferences to the SAD of that SAID. For example, the resolution result returns an ACDC JSON Schema whose id, `$id`, field includes the SAID and returns a resource with JSON Schema mime-type of `schema+json`.
To clarify, ACDCs MUST NOT use complex JSON Schema references which allow _dynamically generated_ schema resources to be obtained from online JSON Schema Libraries {{JSchId}}{{JSchCx}}. The latter approach may be difficult or impossible to secure because a cryptographic commitment to the base schema that includes complex schema (non-relative URI-based) references only commits to the non-relative URI reference and not to the actual schema resource which may change (is dynamic, mutable, malleable). To restate, this approach is insecure because a cryptographic commitment to a complex (non-relative URI-based) reference is NOT equivalent to a commitment to the detailed associated schema resource so referenced if it may change.
ACDCs MUST use static JSON Schema (i.e. _SAIDifiable_ schema). These may include internal relative references to other parts of a fully self-contained static (_SAIDified_) schema or references to static (_SAIDified_) external schema parts. As indicated above, these references may be bare SAIDs, DID URIs or URLs (`did:` scheme), SAD URIs (`sad:` scheme), or OOBI URLs {{OOBI\_ID}}. Recall that a commitment to a SAID with sufficient collision resistance makes an equivalent secure commitment to its encapsulating block SAD. Thus static schema may be either fully self-contained or distributed in parts but the value of any reference to a part must be verifiably static (immutable, nonmalleable) by virtue of either being relative to the self-contained whole or being referenced by its SAID. The static schema in whole or in parts may be attached to the ACDC itself or provided via a highly available cache or data store. To restate, this approach is securely end-verifiable (zero-trust) because a cryptographic commitment to the SAID of a SAIDified schema is equivalent to a commitment to the detailed associated schema itself (SAD).
The schema dialect for ACDC 1.0 is JSON Schema 2020-12 and is indicated by the identifier `"https://json-schema.org/draft/2020-12/schema"` {{JSch}}{{JSch\_202012}}. This is indicated in a JSON Schema via the value of the top-level `$schema` field. Although the value of `$schema` is expressed as a URI, de-referencing does not provide dynamically downloadable schema dialect validation code. This would be an attack vector. The validator MUST control the tooling code dialect used for schema validation and hence the tooling dialect version actually used. A mismatch between the supported tooling code dialect version and the `$schema` string value should cause the validation to fail. The string is simply an identifier that communicates the intended dialect to be processed by the schema validation tool. When provided, the top-level `$schema` field value for ACDC version 1.0 must be "[https://json-schema.org/draft/2020-12/schema"](https://json-schema.org/draft/2020-12/schema%22).
The composed detailed (uncompacted) (bundled) static schema for an ACDC may be cached or attached. But cached, and/or attached static schema is not to be confused with dynamic schema. Nonetheless, while securely verifiable, a remotely cached, _SAIDified_, schema resource may be unavailable. Availability is a separate concern. Unavailable does not mean insecure or unverifiable. ACDCs MUST be verifiable when available. Availability is typically solvable through redundancy. Although a given ACDC application domain or eco-system governance framework may impose schema availability constraints, the ACDC specification itself does not impose any specific availability requirements on Issuers other than schema caches SHOULD be sufficiently available for the intended application of their associated ACDCs. It's up to the Issuer of an ACDC to satisfy any availability constraints on its schema that may be imposed by the application domain or eco-system.
A composable JSON Schema enables the use of any combination of compacted/uncompacted attribute, edge, and rule sections in a provided ACDC. When compact, any one of these sections may be represented merely by its SAID {{JSch}}{{JSchCp}}. When used for the top-level attribute, `a`, edge, `e`, or rule, `r`, section field values, the `oneOf` sub-schema composition operator provides both compact and uncompacted variants. The provided ACDC MUST validate against an allowed combination of the composed variants, either the compact SAID of a block or the full detailed (uncompacted) block for each section. The validator determines what decomposed variants the provided ACDC MUST also validate against. Decomposed variants may be dependent on the type of graduated disclosure, partial, full, or selective. Essentially a composable schema is a verifiable bundle of metadata (composed) about content that then can be verifiably unbundled (decomposed) later. The Issuer makes a single verifiable commitment to the bundle (composed schema) and a recipient may then safely unbundle (decompose) the schema to validate any of the graduated disclosures variants allowed by the composition.
Unlike the other compactifiable sections, it is impossible to define recursively the exact detailed schema as a variant of a `oneOf` composition operator contained in itself. Nonetheless, the provided schema, whether self-contained, attached, or cached MUST validate as a SAD against its provided SAID. It MUST also validate against one of its specified `oneOf` variants.
The compliance of the provided non-schema attribute, `a`, edge, `e`, and rule, `r`, sections MUST be enforced by validating against the composed schema. In contrast, the compliance of the provided composed schema for an expected ACDC type MUST be enforced by the validator. This is because it is not possible to enforce strict compliance of the schema by validating it against itself.
ACDC specific schema compliance requirements are usually specified in the eco-system governance framework for a given ACDC type. Because the SAID of a schema is a unique content-addressable identifier of the schema itself, compliance can be enforced by comparison to the allowed schema SAID in a well-known publication or registry of ACDC types for a given ecosystem governance framework (EGF). The EGF may be solely specified by the Issuer for the ACDCs it generates or be specified by some mutually agreed upon eco-system governance mechanism. Typically the business logic for making a decision about a presentation of an ACDC starts by specifying the SAID of the composed schema for the ACDC type that the business logic is expecting from the presentation. The verified SAID of the actually presented schema is then compared against the expected SAID. If they match then the actually presented ACDC may be validated against any desired decomposition of the expected (composed) schema.
To elaborate, a validator can confirm compliance of any non-schema section of the ACDC against its schema both before and after uncompacted disclosure of that section by using a composed base schema with `oneOf` pre-disclosure and a decomposed schema post-disclosure with the compact `oneOf` option removed. This capability provides a mechanism for secure schema validation of both compact and uncompacted variants that require the Issuer to only commit to the composed schema and not to all the different schema variants for each combination of a given compact/uncompacted section in an ACDC.
One of the most important features of ACDCs is support for Chain-Link Confidentiality {{CLC}}. This provides a powerful mechanism for protecting against un-permissioned exploitation of the data disclosed via an ACDC. Essentially an exchange of information compatible with chain-link confidentiality starts with an offer by the discloser to disclose confidential information to a potential disclosee. This offer includes sufficient metadata about the information to be disclosed such that the disclosee can agree to those terms. Specifically, the metadata includes both the schema of the information to be disclosed and the terms of use of that data once disclosed. Once the disclosee has accepted the terms then full disclosure is made. A full disclosure that happens after contractual acceptance of the terms of use we call _permissioned_ disclosure. The pre-acceptance disclosure of metadata is a form of partial disclosure.
As is the case for compact (uncompacted) ACDC disclosure, Composable JSON Schema, enables the use of the same base schema for both the validation of the partial disclosure of the offer metadata prior to contract acceptance and validation of full or detailed disclosure after contract acceptance {{JSch}}{{JSchCp}}. A cryptographic commitment to the base schema securely specifies the allowable semantics for both partial and full disclosure. Decomposition of the base schema enables a validator to impose more specific semantics at later stages of the exchange process. Specifically, the `oneOf` sub-schema composition operator validates against either the compact SAID of a block or the full block. Decomposing the schema to remove the optional compact variant enables a validator to ensure complaint full disclosure. To clarify, a validator can confirm schema compliance both before and after detailed disclosure by using a composed base schema pre-disclosure and a decomposed schema post-disclosure with the undisclosed options removed. These features provide a mechanism for secure schema-validated contractually-bound partial (and/or selective) disclosure of confidential data via ACDCs.
There are several variants of ACDCs determined by the presence/absence of certain fields and/or the value of those fields. At the top level, the presence (absence), of the UUID, `u`, field produces two variants. These are private (public) respectively. In addition, a present but empty UUID, `u`, field produces a private metadata variant.
Given that there is no top-level UUID, `u`, field in an ACDC, then knowledge of both the schema of the ACDC and the top-level SAID, `d`, field may enable the discovery of the remaining contents of the ACDC via a rainbow table attack {{RB}}{{DRB}}. Therefore, although the top-level, `d`, field is a cryptographic digest, it may not securely blind the contents of the ACDC when knowledge of the schema is available. The field values may be discoverable. Consequently, any cryptographic commitment to the top-level SAID, `d`, field may provide a fixed point of correlation potentially to the ACDC field values themselves in spite of non-disclosure of those field values. Thus an ACDC without a top-level UUID, `u`, field must be considered a **_public_** (non-confidential) ACDC.
Given a top-level UUID, `u`, field, whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of an ACDC may provide a secure cryptographic digest that blinds the contents of the ACDC {{Hash}}. An adversary when given both the schema of the ACDC and the top-level SAID, `d`, field, is not able to discover the remaining contents of the ACDC in a computationally feasible manner such as through a rainbow table attack {{RB}}{{DRB}}. Therefore the top-level, UUID, `u`, field may be used to securely blind the contents of the ACDC notwithstanding knowledge of the schema and top-level, SAID, `d`, field. Moreover, a cryptographic commitment to that that top-level SAID, `d`, field does not provide a fixed point of correlation to the other ACDC field values themselves unless and until there has been a disclosure of those field values. Thus an ACDC with a sufficiently high entropy top-level UUID, `u`, field may be considered a **_private_** (confidential) ACDC. enables a verifiable commitment to the top-level SAID of a private ACDC to be made prior to the disclosure of the details of the ACDC itself without leaking those contents. This is called _partial_ disclosure. Furthermore, the inclusion of a UUID, `u`, field in a block also enables _selective_ disclosure mechanisms described later in the section on selective disclosure.
An empty, top-level UUID, `u`, field appearing in an ACDC indicates that the ACDC is a **_metadata_** ACDC. The purpose of a _metadata_ ACDC is to provide a mechanism for a _Discloser_ to make cryptographic commitments to the metadata of a yet to be disclosed private ACDC without providing any point of correlation to the actual top-level SAID, `d`, field of that yet to be disclosed ACDC. The top-level SAID, `d`, field, of the metadata ACDC, is cryptographically derived from an ACDC with an empty top-level UUID, `u`, field so its value will necessarily be different from that of an ACDC with a high entropy top-level UUID, `u`, field value. Nonetheless, the _Discloser_ may make a non-repudiable cryptographic commitment to the metadata SAID in order to initiate a chain-link confidentiality exchange without leaking correlation to the actual ACDC to be disclosed {{CLC}}. A _Disclosee_ (verifier) may validate the other metadata information in the metadata ACDC before agreeing to any restrictions imposed by the future disclosure. The metadata includes the _Issuer_, the _schema_, the provenancing _edges_, and the _rules_ (terms-of-use). The top-level attribute section, `a`, field value of a _metadata_ ACDC may be empty so that its value is not correlatable across disclosures (presentations). Should the potential _Disclosee_ refuse to agree to the rules then the _Discloser_ has not leaked the SAID of the actual ACDC or the SAID of the attribute block that would have been disclosed.
Given the _metadata_ ACDC, the potential _Disclosee_ is able to verify the _Issuer_, the schema, the provenanced edges, and rules prior to agreeing to the rules. Similarly, an _Issuer_ may use a _metadata_ ACDC to get agreement to a contractual waiver expressed in the rule section with a potential _Issuee_ prior to issuance. Should the _Issuee_ refuse to accept the terms of the waiver then the _Issuer_ has not leaked the SAID of the actual ACDC that would have been issued nor the SAID of its attributes block nor the attribute values themselves.
When a _metadata_ ACDC is disclosed (presented) only the _Discloser's_ signature(s) is attached not the _Issuer's_ signature(s). This precludes the _Issuer's_ signature(s) from being used as a point of correlation until after the _Disclosee_ has agreed to the terms in the rule section. When chain-link confidentiality is used, the _Issuer's_ signatures are not disclosed to the _Disclosee_ until after the _Disclosee_ has agreed to keep them confidential. The _Disclosee_ is protected from forged _Discloser_ because ultimately verification of the disclosed ACDC will fail if the _Discloser_ does not eventually provide verifiable _Issuer's_ signatures. Nonetheless, should the potential _Disclosee_ not agree to the terms of the disclosure expressed in the rule section then the _Issuer's_ signature(s) is not leaked.
An important design goal of ACDCs is they support the sharing of provably authentic data while also protecting against the un-permissioned exploitation of that data. Often the term _privacy protection_ is used to describe similar properties. But a narrow focus on "privacy protection" may lead to problematic design trade-offs. With ACDCs, the primary design goal is not _data privacy protection_ per se but the more general goal of protection from the **_un-permissioned exploitation of data_**. In this light, a _given privacy protection_ mechanism may be employed to help protect against _unpermissioned exploitation of data_ but only when it serves that more general-purpose and not as an end in and of itself.
As described previously, ACDCs employ _graduated disclosure_ mechanisms that satisfy the principle of least disclosure. Requoted here the principle of least disclosure is as follows:
> The system should disclose only the minimum amount of information about a given party needed to facilitate a transaction and no more. {{IDSys}}
For example, compact disclosure, partial disclosure, and selective disclosure are all graduated disclosure mechanisms. Contractually protected disclosure leverages graduated disclosure so that contractual protections can be put into place using the least disclosure necessary to that end. This minimizes the leakage of information that can be correlated. One type of contractually protected disclosure is chain-link confidentiality {{CLC}}.
An ACDC may employ several mechanisms to protect against _unpermissioned exploitation of data_. These are:
- Contractually Protected Disclosure
- Chain-link Confidentiality {{CLC}}
- Contingent Disclosure
- Partial Disclosure
- Selective Disclosure
For example, the _partial disclosure_ of portions of an ACDC to enable chain-link confidentiality of the subsequent full disclosure is an application of the principle of least disclosure. Likewise, unbundling only the necessary attributes from a bundled commitment using _selective disclosure_ to enable a correlation minimizing disclosure from that bundle is an application of the principle of least disclosure.
Unpermission exploitation is characterized using a three-party model. The three parties are as follows:
- First-Party = _Discloser_ of data.
- Second-Party = _Disclosee_ of data received from First Party (_Discloser_).
- Third-Party = _Observer_ of data disclosed by First Party (_Discloser_) to Second Party (_Disclosee_).
- implicit permissioned correlation.
- no contractual restrictions on the use of disclosed data.
- explicit permissioned correlation.
- use as permitted by contract
- explicit unpermissioned correlation with other second parties or third parties.
- malicious use in violation of contract
- implicit permissioned correlation.
- no contractual restrictions on the use of observed data.
- explicit unpermissioned correlation via collusion with second parties.
- malicious use in violation of second-party contract
Chain-link confidentiality imposes contractual restrictions and liability on any Disclosee (Second-Party) {{CLC}}. The exchange provides a fair contract consummation mechanism. The essential steps in a chain-link confidentiality exchange are shown below. Other steps may be included in a more comprehensive exchange protocol.
- _Discloser_ provides a non-repudiable _Offer_ with verifiable metadata (sufficient partial disclosure), which includes any terms or restrictions on use.
- _Disclosee_ verifies _Offer_ against composed schema and metadata adherence to desired data.
- _Disclosee_ provides non-repudiable _Accept_ of terms that are contingent on compliant disclosure.
- _Discloser_ provides non-repudiable _Disclosure_ with sufficient compliant detail.
- _Disclosee_ verifies _Disclosure_ using decomposed schema and adherence of disclosed data to _Offer_.
_Disclosee_ may now engage in permissioned use and carries liability as a deterrent against unpermissioned use.
The ordering of the top-level fields when present in an ACDC MUST be as follows, `v`, `d`, `u`, `i`, `ri`, `s`, `a`, `e`, `r`.
The top-level section field values of a compact ACDC are the SAIDs of each uncompacted top-level section. The section field labels are `s`, `a`, `e`, and `r`.
A fully compact public ACDC is shown below.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
A fully compact private ACDC is shown below.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"u": "0ANghkDaG7OY1wjaDAE0qHcg",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
The schema for the compact private ACDC example above is provided below.
```
{
"$id": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Compact Private ACDC",
"description": "Example JSON Schema for a Compact Private ACDC.",
"credentialType": "CompactPrivateACDCExample",
"type": "object",
"required":
[
"v",
"d",
"u",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"u":
{
"description": "ACDC UUID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry ID",
"type": "string"
},
"s": {
"description": "schema SAID",
"type": "string"
},
"a": {
"description": "attribute SAID",
"type": "string"
},
"e": {
"description": "edge SAID",
"type": "string"
},
"r": {
"description": "rule SAID",
"type": "string"
}
},
"additionalProperties": false
}
```
The attribute section in the examples above has been compacted into its SAID. The schema of the compacted attribute section is as follows,
```
{
"a":
{
"description": "attribute section SAID",
"type": "string"
}
}
```
Two variants of an ACDC, namely, namely, **_private (public) attribute_** are defined respectively by the presence (absence) of a UUID, `u`, field in the uncompacted attribute section block.
Two other variants of an ACDC, namely, **_targeted (untargeted)_** are defined respectively by the presence (absence) of an issuee, `i`, field in the uncompacted attribute section block.
Suppose that the un-compacted value of the attribute section as denoted by the attribute section, `a`, field is as follows,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
}
}
```
The SAID, `d`, field at the top level of the uncompacted attribute block is the same SAID used as the compacted value of the attribute section, `a`, field.
Given the absence of a `u` field at the top level of the attributes block, then knowledge of both SAID, `d`, field at the top level of an attributes block and the schema of the attributes block may enable the discovery of the remaining contents of the attributes block via a rainbow table attack {{RB}}{{DRB}}. Therefore the SAID, `d`, field of the attributes block, although, a cryptographic digest, does not securely blind the contents of the attributes block given knowledge of the schema. It only provides compactness, not privacy. Moreover, any cryptographic commitment to that SAID, `d`, field provides a fixed point of correlation potentially to the attribute block field values themselves in spite of non-disclosure of those field values via a compact ACDC. Thus an ACDC without a UUID, `u`, field in its attributes block must be considered a **_public-attribute_** ACDC even when expressed in compact form.
The subschema for the public uncompacted attribute section is shown below,
```
{
"a":
{
"description": "attribute section",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
}
```
Through the use of the JSON Schema `oneOf` composition operator the following composed schema will validate against both the compact and un-compacted value of the attribute section field.
```
{
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute SAID",
"type": "string"
},
{
"description": "uncompacted attribute section",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
```
Consider the following form of an uncompacted private-attribute block,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"u": "0AwjaDAE0qHcgNghkDaG7OY1",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
}
}
```
Given the presence of a top-level UUID, `u`, field of the attribute block whose value has sufficient cryptographic entropy, then the top-level SAID, `d`, field of the attribute block provides a secure cryptographic digest of the contents of the attribute block {{Hash}}. An adversary when given both the schema of the attribute block and its SAID, `d`, field, is not able to discover the remaining contents of the attribute block in a computationally feasible manner such as a rainbow table attack {{RB}}{{DRB}}. Therefore the attribute block's UUID, `u`, field in a compact ACDC enables its attribute block's SAID, `d`, field to securely blind the contents of the attribute block notwithstanding knowledge of the attribute block's schema and SAID, `d` field. Moreover, a cryptographic commitment to that attribute block's, SAID, `d`, field does not provide a fixed point of correlation to the attribute field values themselves unless and until there has been a disclosure of those field values.
To elaborate, when an ACDC includes a sufficiently high entropy UUID, `u`, field at the top level of its attributes block then the ACDC may be considered a **_private-attributes_** ACDC when expressed in compact form, that is, the attribute block is represented by its SAID, `d`, field and the value of its top-level attribute section, `a`, field is the value of the nested SAID, `d`, field from the uncompacted version of the attribute block. A verifiable commitment may be made to the compact form of the ACDC without leaking details of the attributes. Later disclosure of the uncompacted attribute block may be verified against its SAID, `d`, field that was provided in the compact form as the value of the top-level attribute section, `a`, field.
Because the _Issuee_ AID is nested in the attribute block as that block's top-level, issuee, `i`, field, a presentation exchange (disclosure) could be initiated on behalf of a different AID that has not yet been correlated to the _Issuee_ AID and then only correlated to the Issuee AID after the _Disclosee_ has agreed to the chain-link confidentiality provisions in the rules section of the private-attributes ACDC {{CLC}}.
Through the use of the JSON Schema `oneOf` composition operator, the following composed schema will validate against both the compact and un-compacted value of the private attribute section, `a`, field.
```
{
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute SAID",
"type": "string"
},
{
"description": "uncompacted attribute section",
"type": "object",
"required":
[
"d",
"u",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
```
As described above in the Schema section of this specification, the `oneOf` sub-schema composition operator validates against either the compact SAID of a block or the full block. A validator can use a composed schema that has been committed to by the Issuer to securely confirm schema compliance both before and after detailed disclosure by using the fully composed base schema pre-disclosure and a specific decomposed variant post-disclosure. Decomposing the schema to remove the optional compact variant (i.e. removing the `oneOf` compact option) enables a validator to ensure complaint full disclosure.
Consider the case where the issuee, `i`, field is absent at the top level of the attribute block as shown below,
```
{
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"temp": 45,
"lat": "N40.3433",
"lon": "W111.7208"
}
}
```
This ACDC has an _Issuer_ but no _Issuee_. Therefore, there is no provably controllable _Target_ AID. This may be thought of as an undirected verifiable attestation or observation of the data in the attributes block by the _Issuer_. One could say that the attestation is addressed to "whom it may concern". It is therefore an **_untargeted_** ACDC, or equivalently an _unissueed_ ACDC. An _untargeted_ ACDC enables verifiable authorship by the Issuer of the data in the attributes block but there is no specified counter-party and no verifiable mechanism for delegation of authority. Consequently, the rule section may only provide contractual obligations of implied counter-parties.
This form of an ACDC provides a container for authentic data only (not authentic data as authorization). But authentic data is still a very important use case. To clarify, an untargeted ACDC enables verifiable authorship of data. An observer such as a sensor that controls an AID may make verifiable non-repudiable measurements and publish them as ACDCs. These may be chained together to provide provenance for or a chain-of-custody of any data. These ACDCs could be used to provide a verifiable data supply chain for any compliance-regulated application. This provides a way to protect participants in a supply chain from imposters. Such data supply chains are also useful as a verifiable digital twin of a physical supply chain {{Twin}}.
A hybrid chain of one or more targeted ACDCs ending in a chain of one or more untargeted ACDCs enables delegated authorized attestations at the tail of that chain. This may be very useful in many regulated supply chain applications such as verifiable authorized authentic datasheets for a given pharmaceutical.
When present at the top level of the attribute section, the issuee, `i`, field value provides the AID of the _Issuee_ of the ACDC. This _Issuee_ AID is a provably controllable identifier that serves as the _Target_ AID. This makes the ACDC a **_targeted_** ACDC or equivalently an _issueed_ ACDC. Targeted ACDCs may be used for many different purposes such as an authorization or a delegation directed at the _Issuee_ AID, i.e. the _Target_. In other words, a _targeted ACDC_ provides a container for authentic data that may also be used as some form of authorization such as a credential that is verifiably bound to the _Issuee_ as targeted by the _Issuer_. Furthermore, by virtue of the targeted _Issuee's_ provable control over its AID, the _targeted ACDC_ may be verifiably presented (disclosed) by the controller of the _Issuee_ AID.
For example, the definition of the term **_credential_** is _evidence of authority, status, rights, entitlement to privileges, or the like_. To elaborate, the presence of an attribute section top-level issuee, `i`, field enables the ACDC to be used as a verifiable credential given by the _Issuer_ to the _Issuee_.
One reason the issuee, `i`, field is nested into the attribute section, `a`, block is to enable the _Issuee_ AID to be private or partially or selectively disclosable. The _Issuee_ may also be called the _Holder_ or _Subject_ of the ACDC. But here we use the more semantically precise albeit less common terms of _Issuer_ and _Issuee_. The ACDC is issued from or by an _Issuer_ and is issued to or for an _Issuee_. This precise terminology does not bias or color the role (function) that an _Issuee_ plays in the use of an ACDC. What the presence of _Issuee_ AID does provide is a mechanism for control of the subsequent use of the ACDC once it has been issued. To elaborate, because the issuee, `i`, field value is an AID, by definition, there is a provable controller of that AID. Therefore that _Issuee_ controller may make non-repudiable commitments via digital signatures on behalf of its AID. Therefore subsequent use of the ACDC by the _Issuee_ may be securely attributed to the _Issuee_.
Importantly the presence of an issuee, `i`, field enables the associated _Issuee_ to make authoritative verifiable presentations or disclosures of the ACDC. A designated _Issuee_also better enables the initiation of presentation exchanges of the ACDC between that _Issuee_ as _Discloser_ and a _Disclosee_ (verifier).
In addition, because the _Issuee_ is a specified counter-party the _Issuer_ may engage in a contract with the _Issuee_ that the _Issuee_ agrees to by virtue of its non-repudiable signature on an offer of the ACDC prior to its issuance. This agreement may be a pre-condition to the issuance and thereby impose liability waivers or other terms of use on that _Issuee_.
Likewise, the presence of an issuee, `i`, field, enables the _Issuer_ to use the ACDC as a contractual vehicle for conveying an authorization to the _Issuee_. This enables verifiable delegation chains of authority because the _Issuee_ in one ACDC may become the _Issuer_ in some other ACDC. Thereby an _Issuer_ may delegate authority to an _Issuee_ who may then become a verifiably authorized _Issuer_ that then delegates that authority (or an attenuation of that authority) to some other verifiably authorized _Issuee_ and so forth.
In the compact ACDC examples above, the edge section has been compacted into merely the SAID of that section. Suppose that the un-compacted value of the edge section denoted by the top-level edge, `e`, field is as follows,
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
}
}
```
The edge section's top-level SAID, `d`, field is the SAID of the edge block and is the same SAID used as the compacted value of the ACDC's top-level edge, `e`, field. Each edge in the edge section gets its own field with its own local label. The value of the field may be a sub-block or in the simplest case a string. In the example above, the edge label is `"boss"`. Note that each edge does NOT include a type field. The type of each edge is provided by the schema vis-a-vis the label of that edge. This is in accordance with the design principle of ACDCs that may be succinctly expressed as "type-is-schema". This approach varies somewhat from many property graphs which often do not have a schema {{PGM}}{{Dots}}{{KG}}. Because ACDCs have a schema for other reasons, however, they leverage that schema to provide edge types with a cleaner separation of concerns. Notwithstanding, this separation, an edge sub-block may include a constraint on the type of the ACDC to which that edge points by including the SAID of the schema of the pointed-to ACDC as a property of that edge.
A main distinguishing feature of a _property graph_ (PG) is that both nodes and edges may have a set of properties {{PGM}}{{Dots}}{{KG}}. These might include modifiers that influence how the connected node is to be combined or place a constraint on the allowed type(s) of connected nodes.
There several reserved field labels for edge sub-blocks. These are detailed in the table below. Each edge sub-block may have other non-reserved field labels as needed for a particular edge type.
| Label | Title | Description |
| --- | --- | --- |
| `d` | Digest (SAID) | Optional, self-referential fully qualified cryptographic digest of enclosing edge map. |
| `u` | UUID | Optional random Universally Unique IDentifier as fully qualified high entropy pseudo-random string, a salty nonce. |
| `s` | Schema | Optional SAID of the JSON Schema block of the far node ACDC. |
| `n` | Node | Required SAID of the far ACDC as the terminating point of a directed edge that connects the edge's encapsulating near ACDC to the specified far ACDC as a fragment of a distributed property graph (PG). |
| `o` | Operator | Optional as either a unary operator on edge or an m-ary operator on edge-group in edge section. Enables expression of the edge logic on edge subgraph. |
| `w` | Weight | Optional edge weight property that enables default property for directed weighted edges and operators that use weights. |
The node, `n`, field is required. The SAID, `d`, UUID, `u`, schema, `s`, operator, `o`, and weight, `w`, fields are optional. To clarify, each edge sub-block MUST have a node, `n`, field and MAY have any combination of SAID, `d`, UUID, `u`, schema, `s`, operator, `o`, or weight, `w`, fields.
When present, the SAID, `d`, field MUST appear as the first field in the edge sub-block. When present,the value of the SAID, `d` field MUST be the SAID of its enclosing edge sub-block.
A UUID, `u`, field MUST not appear unless there is also a SAID, `d` field. When present, the UUID, `u`, field must appear immediately after as the SAID, `d`, field in the edge sub-block. When present, the value of the UUID, `u` is a pseudorandom string with approximately 128 bits of cryptographic entropy. The UUID, `u`, field acts as a salty nonce to hide the values of the edge sub-block in spite of knowledge of the edge sub-blocks SAID, `d`, field and its, the edge's, actual near schema (not its far node schema field).
When the edge sub-block does NOT include a SAID, `d`, field then the node, `n`, field MUST appear as the first field in the edge sub-block, i.e. it follows the SAID, `d`, field which is first. When the edge sub-block does include a SAID, `d`, field then the node, `n`, field MUST appear as the second field in the edge sub-block.
The value of the required node, `n`, field is the SAID of the ACDC to which the edge connects i.e. the node, `n`, field indicated, designates, references, or "points to" another ACDC. The edge is directed _from_ the _near_ node that is the ACDC in which the edge sub-block resides and is directed _to_ the _far_ node that is the ACDC indicated by the node, `n`, field of that edge sub-block. In order for the edge (chain) to be valid, the ACDC validator MUST confirm that the SAID of the provided _far_ ACDC matches the node, `n`, field value given in the edge sub-block in _near_ ACDC and MUST confirm that the provided _far_ ACDC satisfies its own schema.
When present, the schema, `s` field must appear immediately following the node `n`, field in the edge sub-block. When present, the value of the schema, `s` field MUST be the SAID of the top-level schema, `s`, field of the ACDC indicated by the edge's far node, `n`, field. When the schema, `s`, field is present in an edge sub-block, in order for the edge (chain) to be valid, the ACDC validator, after validating that the provided _far_ ACDC indicated by the node, `n`, field satisfies its (the far ACDC's) own schema, MUST also confirm that the value of the edge's schema, `s`, field matches the SAID of the far ACDC's schema as indicated by its top-level schema, `s`, field.
The following example adds both SAID, `d`, and schema, `s`, fields (edge properties) to the edge sub-block.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn9y",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"s": "ELIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdYerzw"
}
}
}
```
When present, the operator, `o` field must appear immediately following all of the SAID, `d`, node, `n`, or schema, `s`, fields in the edge sub-block. The function of the operator field is explained in a later section.
When present, the weight, `w` field must appear immediately following all of the SAID, `d`, node, `n`, schema, `s`, or operator, `o`, fields in the edge sub-block. The function of the weight field is explained in a later section.
Abstractly, an ACDC with one or more edges may be a fragment of a distributed property graph. However, the local label does not enable the direct unique global resolution of a given edge including its properties other than a trivial edge with only one property, its node, `n` field. To enable an edge with additional properties to be globally uniquely resolvable, that edge's block MUST have a SAID, `d`, field. Because a SAID is a cryptographic digest it will universally and uniquely identify an edge with a given set of properties {{Hash}}. This allows ACDCs to be used as secure fragments of a globally distributed property graph (PG). This enables a property graph to serve as a global knowledge graph in a secure manner that crosses trust domains {{PGM}}{{Dots}}{{KG}}. This is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
Given that an individual edge's property block includes a SAID, `d`, field then a compact representation of the edge's property block is provided by replacing it with its SAID. This may be useful for complex edges with many properties. This is called a **_compact edge_**. This is shown as follows,
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn"
}
}
```
Each edge's properties may be blinded by its SAID, `d`, field (i.e. be private) if its properties block includes a UUID, `u` field. As with UUID, `u`, fields used elsewhere in ACDC, if the UUID, `u`, field value has sufficient entropy then the values of the properties of its enclosing block are not discoverable in a computationally feasible manner merely given the schema for the edge block and its SAID, `d` field. This is called a **_private edge_**. When a private edge is provided in compact form then the edge detail is hidden and is partially disclosable. An uncompacted private edge is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
When an edge points to a _private_ ACDC, a _Discloser_ may choose to use a metadata version of that private ACDC when presenting the node, `n`, field of that edge prior to acceptance of the terms of disclosure. The _Disclosee_ can verify the metadata of the private node without the _Discloser_ exposing the actual node contents via the actual node SAID or other attributes.
Private ACDCs (nodes) and private edges may be used in combination to prevent an un-permissioned correlation of the distributed property graph.
When an edge sub-block has only one field that is its node, `n`, field then the edge block may use an alternate simplified compact form where the labeled edge field value is the value of its node, `n`, field. The schema for that particular edge label, in this case, `"boss"`, will indicate that the edge value is a node SAID and not the edge sub-block SAID as would be the case for the normal compact form shown above. This alternate compact form is shown below.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
}
```
When the top-level edge section, `e`, field includes more than one edge there is a need or opportunity to define the logic for evaluating those edges with respect to validating the ACDC itself with respect to the validity of the other ACDCs it is connected two. More than one edge creates a provenance tree not simply a provenance chain. The obvious default for a chain is that all links in the chain must be valid in order for the chain itself to be valid, or more precisely for the tail of the chain to be valid. If any links between the head and the tail are broken (invalid) then the tail is not valid. This default logic may not be so useful in all cases when a given ACDC is the tail of multiple parallel chains (i.e. a branching node in a tree of chains). Therefore provided herein is the syntax for exactly specifying the operations to perform on each edge and groups of edges in its edge section.
There are three types of labels in edge sub-blocks:
- Reserved Field Labels (Metadata). `d` for SAID of block `u` for UUID (salty nonce) `n` for node SAID (far ACDC) `s` for schema SAID ( far ACDC) `o` for operator `w` for weight
- Edge Field Map Labels (Single Edges) any value except reserved values above
- Edge-Group Field Map Labels (Aggregates of Edges) any value except reserved values above
There are two types of field-maps or blocks that may appear as values of fields within an edge section, `e`, field either at the top level or nested:
- Edge-Group. An _**edge-group**_ MUST NOT have a node, `n`, metadata field. Its non-metadata field values may include other (sub) edge-group blocks, edge blocks or other properties.
- Edge. An _**edge**_ MUST have a node, `n`, metadata field. Its non-metadata field values MUST NOT include edge-group blocks or other edge blocks but may include other types of properties. From a graph perspective, _edge_ blocks terminate at their node, `n`, field and are not themselves nestable. An _edge_ block is a leaf with respect to any nested _edge-group_ blocks in which the edge appears. It is therefore also a leaf with respect to its enclosing top-level edge section, `e`, field. The ACDC node that an edge points to may have its own edge-groups or edges in that node's own top-level edge section.
The top-level edge section, `e`, field value is always an _edge-group_ block.
With respect to the granularity of a property graph consisting of ACDCs as nodes, nested edge-groups within a given top-level edge field, `e`, field of a given ACDC constitute a sub-graph whose nodes are edge-groups not ACDCs. One of the attractive features of property graphs (PGs) is their support for different edge and node types which enables nested sub-graphs such as is being employed here to support the expression of complex logical or aggregative operations on groups of edges (as subnodes) within the top-level edge section, `e`, field of an ACDC (as supernode).
The meaning of the operator, `o`, metadata field label depends on which type of block it appears in.
- When appearing in an edge-group block then the operator, `o`, field value is an aggregating (m-ary) operator, such as, `OR`, `AND`, `AVG`, `NAND`, `NOR` etc. Its operator applies to all the edges or edge-groups that appear in that edge-group block.
- When appearing in an edge block then the operator, `o`, field value is a unary operator like `NOT`. When more than one unary operator applies to a given edge then the value of the operator, `o`, field is a list of those unary operators.
Weighted directed edges represent degrees of confidence or likelihood. PGs with weighted directed edges are commonly used for machine learning or reasoning under uncertainty. The weight, `w` field provides a reserved label for the primary weight. To elaborate, many aggregating operators used for automated reasoning such as the weighted average, `WAVG`, operator or ranking aggregation operators, depend on each edge having a weight. To simplify the semantics for such operators, the weight, `w`, field is the reserved field label for weighting. Other fields with other labels could provide other types of weights but having a default label, namely `w`, simplifies the default definitions of weighted operators.
The following example adds a weight property to the edge sub-block as indicated by the weight, `w`, field.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"w": "high"
}
}
}
```
There are two basic m-ary operators defined for ACDCs. These are,
| M-ary Operator | Description | Type | Default |
| --- | --- | --- | --- |
| `AND` | All edges or edge-groups in the edge group MUST be valid for the edge-group to be valid | Combination | Yes |
| `OR` | Only one of the edges or edge-groups in the edge group MUST be valid for the edge-group to be valid | Combination | No |
There are three special unary operators defined for ACDCs. These are,
| Unary Operator | Description | Type | Default |
| --- | --- | --- | --- |
| `I2I` | Issuee-To-Issuer, Issuer AID of this ACDC must Issuee AID of node the edge points to | Constraint | Yes |
| `NI2I` | Not-Issuee-To-Issuer, Issuer AID if any of this ACDC MAY or MAY NOT be Issuee AID of node that the edge points to | Constraint | No |
| `DI2I` | Delegated-Issuee-To-Issuer, Issuer AID of this ACDC MUST be either the Issuee AID or delegated AID of the Issuee AID of the node the edge points to | Constraint | No |
Many ACDC chains use targeted ACDCs (i.e. have Issuees). A chain of Issuer-To-Issuee-To-Issuer targeted ACDCs in which each Issuee becomes the Issuer of the next ACDC in the chain can be used to provide a chain-of-authority. A common use case of a chain-of-authority is a delegation chain for authorization.
The `I2I` unary operator when present means that the Issuer AID of the current ACDC in which the edge resides MUST be the Issuee AID of the node that the edge points to. This also means therefore that the ACDC node pointed to by the edge must also be a targeted ACDC. This is the default value when none of `I2I`, `NI2I`, or `DI2I` is present.
The `NI2I` unary operator when present removes or nullifies any requirement expressed by the dual `I2I` operator described above. In other words, any requirement that the Issuer AID of the current ACDC in which the edge resides MUST be the Issuee AID, if any, of the node the edge points to is relaxed (not applicable). To clarify, when operative (present), the `NI2I` operator means that both an untargeted ACDC or targeted ACDC as the node pointed to by the edge may still be valid even when untargeted or if targeted even when the Issuer of the ACDC in which the edge appears is not the Issuee AID, of that node the edge points to.
The `DI2I` unary operator when present expands the class of allowed Issuer AIDs of the node the edge resides in to include not only the Issuee AID but also any delegated AIDS of the Issuee of the node the edge points to. This also means therefore that the ACDC node pointed to by the edge must also be a targeted ACDC.
If more than one of the `I2I`, `NI2I`, or `DI2I` operators appear in an operator, `o`, field list then the last one appearing in the list is the operative one.
When the operator, `o`, field is missing in an edge-group block. The default value for the operator, `o`, field is `AND`.
When the operator, `o`, field is missing or empty in an edge block, or is present but does not include any of the `I2I`, `NI2I` or `DI2I` operators then,
If the node pointed to by the edge is a targeted ACDC, i.e. has an Issuee, by default it is assumed that the `I2I` operator is appended to the operator, `o`, field's effective list value.
If the node pointed to by the edge block is a non-targeted ACDC i.e., does not have an Issuee, by default, it is assumed that the `NI2I` operator is appended to the operator, `o`, field's effective list value.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "NOT",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "OR",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"o": "NI2I",
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
}
}
}
```
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"o": "AND",
"boss":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"o": ["NI2I", "NOT"],
"power": "high"
},
"baby":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "I2I",
"power": "low"
},
"food":
{
"o": "OR",
"power": "med",
"plum":
{
"n": "EQIYPvAu6DZAIl3AORH3dCdoFOLe71iheqcywJcnjtJt",
"o": "NI2I"
},
"pear":
{
"n": "EJtQIYPvAu6DZAIl3AORH3dCdoFOLe71iheqcywJcnjt",
"o": "NI2I"
}
}
}
}
```
When an ECR vLEI is issued by the QVI it is not chained, Issuer-to-Issuee, via the LE credential. A more accurate way of expressing the chaining would be to use the `AND` operator to include both the LE and QVI credentials as edges in the ECR and also to apply the unary `NI2I` to the LE credential instead of only chaining the ECR to the LE and not chaining to ECR to the QVI at all.
In the following example: The top-level edge-block uses the default of `AND` and the `qvi` edge uses the default of `I2I` because it points to a targeted ACDC. The `le` edge, on the other hand, points to a targeted ACDC. It uses the unary operator, `NI2I` in its operator, `o`, field so that it will be accepted it even though its targeted Issuee is not the Issuer of the current credential.
```
{
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLx,UdY",
"qvi":
{
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
},
"le":
{
"n": "EORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZAIl3A",
"o": "NI2I"
}
}
}
```
This provides a simple but highly expressive syntax for applying (m-ary) aggregating operators to nestable groups of edges and unary operators to edges individually within those groups. This is a general approach with high expressive power. It satisfies many business logic requirements similar to that of SGL.
Certainly, an even more expressive syntax could be developed. The proposed syntax, however, is relatively simple and compact. It has intelligent defaults and is sufficiently general in scope to satisfy all the currently contemplated use cases.
The intelligent defaults for the operator, `o`, field, including the default application of the `I2I` or `NI2I` unary operator, means that in most current use cases, the operator, `o`, field, does not even need to be present.
In general, the discovery of the details of an ACDC referenced as a node, `n` field value, in an edge sub-block begins with the node SAID or the SAID of the associated edge sub-block. Because a SAID is a cryptographic digest with high collision resistance it provides a universally unique identifier to the referenced ACDC as a node. The Discovery of a service endpoint URL that provides database access to a copy of the ACDC may be bootstrapped via an OOBI (Out-Of-Band-Introduction) that links the service endpoint URL to the SAID of the ACDC {{OOBI\_ID}}. Alternatively, the _Issuer_ may provide as an attachment at the time of issuance a copy of the referenced ACDC. In either case, after a successful exchange, the _Issuee_ or recipient of any ACDC will have either a copy or a means of obtaining a copy of any referenced ACDCs as nodes in the edge sections of all ACDCs so chained. That Issuee or recipient will then have everything it needs to make a successful disclosure to some other _Disclosee_. This is the essence of _percolated_ discovery.
In the compact ACDC examples above, the rule section has been compacted into merely the SAID of that section. Suppose that the un-compacted value of the rule section denoted by the top-level rule, `r`, field is as follows,
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
The purpose of the rule section is to provide a Ricardian Contract {{RC}}. The important features of a Ricardian contract are that it be both human and machine-readable and referenceable by a cryptographic digest. A JSON encoded document or block such as the rule section block is a practical example of both a human and machine-readable document. The rule section's top-level SAID, `d`, field provides the digest. This provision supports the bow-tie model of Ricardian Contracts {{RC}}. Ricardian legal contracts may be hierarchically structured into sections and subsections with named or numbered clauses in each section. The labels on the clauses may follow such a hierarchical structure using nested maps or blocks. These provisions enable the rule section to satisfy the features of a Ricardian contract.
To elaborate, the rule section's top-level SAID, `d`, field is the SAID of that block and is the same SAID used as the compacted value of the rule section, `r`, field that appears at the top level of the ACDC. Each clause in the rule section gets its own field. Each clause also has its own local label.
The legal, `l`, field in each block provides the associated legal language.
Note there are no type fields in the rule section. The type of a contract and the type of each clause is provided by the schema vis-a-vis the label of that clause. This follows the ACDC design principle that may be succinctly expressed as "type-is-schema".
Each rule section clause may also have its own clause SAID, `d`, field. Clause SAIDs enable reference to individual clauses, not merely the whole contract as given by the rule section's top-level SAID, `d`, field.
An example rule section with clause SAIDs is provided below.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
The use of clause SAIDS enables a compact form of a set of clauses where each clause value is the SAID of the corresponding clause. For example,
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"liabilityDisclaimer": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw"
}
}
```
The disclosure of some clauses may be pre-conditioned on acceptance of chain-link confidentiality. In this case, some clauses may benefit from partial disclosure. Thus clauses may be blinded by their SAID, `d`, field when the clause block includes a sufficiently high entropy UUID, `u`, field. The use of a clause UUID enables the compact form of a clause to NOT be discoverable merely from the schema for the clause and its SAID via rainbow table attack {{RB}}{{DRB}}. Therefore such a clause may be partially disclosable. These are called **_private clauses_**. A private clause example is shown below.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"u": "0AHcgNghkDaG7OY1wjaDAE0q",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
An alternate simplified compact form uses the value of the legal, `l`, field as the value of the clause field label. The schema for a specific clause label will indicate that the field value, for a given clause label is the legal language itself and not the clause block's SAID, `d`, field as is the normal compact form shown above. This alternate simple compact form is shown below. In this form individual clauses are not compactifiable and are fully self-contained.
```
{
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE",
"liabilityDisclaimer": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
```
In compact form, the discovery of either the rule section as a whole or a given clause begins with the provided SAID. Because the SAID, `d`, field of any block is a cryptographic digest with high collision resistance it provides a universally unique identifier to the referenced block details (whole rule section or individual clause). The discovery of a service endpoint URL that provides database access to a copy of the rule section or to any of its clauses may be bootstrapped via an OOBI (Out-Of-Band-Introduction) that links the service endpoint URL to the SAID of the respective block {{OOBI\_ID}}. Alternatively, the issuer may provide as an attachment at issuance a copy of the referenced contract associated with the whole rule section or any clause. In either case, after a successful issuance exchange, the Issuee or holder of any ACDC will have either a copy or a means of obtaining a copy of any referenced contracts in whole or in part of all ACDCs so issued. That Issuee or recipient will then have everything it needs to subsequently make a successful presentation or disclosure to a Disclosee. This is the essence of percolated discovery.
The ACDC chaining enables disclosure-specific issuance of bespoke ACDCs. A given Discloser of an ACDC issued by some Issuer may want to augment the disclosure with additional contractual obligations or additional information sourced by the Discloser where those augmentations are specific to a given context such as a specific Disclosee. Instead of complicating the presentation exchange to accommodate such disclosure-specific augmentations, a given Disloser issues its own bespoke ACDC that includes the other ACDC of the other Issuer by reference via an edge in the bespoke ACDC. This means that the normal validation logic and tooling for a chained ACDC can be applied without complicating the presentation exchange logic. Furthermore, attributes in other ACDCs pointed to by edges in the bespoke ACDC may be addressed by attributes in the bespoke ACDC using JSON Pointer or CESR-Proof SAD Path references that are relative to the node SAID in the edge {{RFC6901}}{{Proof\_ID}}.
For example, this approach enables the bespoke ACDC to identify (name) the Disclosee directly as the Issuee of the bespoke ACDC. This enables contractual legal language in the rule section of the bespoke ACDC that reference the Issuee of that ACDC as a named party. Signing the agreement to the offer of that bespoke ACDC consummates a contract between named Issuer and named Issuee. This approach means that custom or bespoke presentations do not need additional complexity or extensions. Extensibility comes from reusing the tooling for issuing ACDCs to issue a bespoke or disclosure-specific ACDC. When the only purpose of the bespoke ACDC is to augment the contractual obligations associated with the disclosure then the attribute section, `a`, field value of the bespoke ACD may be empty or it may include properties whose only purpose is to support the bespoke contractual language.
Similarly, this approach effectively enables a type of _rich presentation_ or combined disclosure where multiple ACDCs may be referenced by edges in the bespoke ACDC that each contributes some attribute(s) to the effective set of attributes referenced in the bespoke ACDC. The bespoke ACDC enables the equivalent of a _rich presentation_ without requiring any new tooling {{Abuse}}.
Consider the following disclosure-specific ACDC. The Issuer is the Discloser, the Issuee is the Disclosee. The rule section includes a context-specific (anti) assimilation clause that limits the use of the information to a single one-time usage purpose, that is in this case, admittance to a restaurant. The ACDC includes an edge that references some other ACDC that may for example be a coupon or gift card. The attribute section includes the date and place of admittance.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "EGGeIZ8a8FWS7a646jrVPTzlSkUPqs4reAXRZOkogZ2A",
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"date": "2022-08-22T17:50:09.988921+00:00",
"place": "GoodFood Restaurant, 953 East Sheridan Ave, Cody WY 82414 USA"
},
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"other":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA"
}
},
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"Assimilation":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuee hereby explicitly and unambiguously agrees to NOT assimilate, aggregate, correlate, or otherwise use in combination with other information available to the Issuee, the information, in whole or in part, referenced by this container or any containers recursively referenced by the edge section, for any purpose other than that expressly permitted by the Purpose clause."
},
"Purpose":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "One-time admittance of Issuer by Issuee to eat at place on date as specified in attribute section."
}
}
}
```
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a":
{
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA",
"score": 96,
"name": "Jane Doe"
},
"e":
{
"d": "EerzwLIr9Bf7V_NHwY1lkFrn9y2PgveY4-9XgOcLxUdY",
"boss":
{
"d": "E9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NHwY1lkFrn",
"n": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"s": "EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71",
"w": "high"
}
},
"r":
{
"d": "EwY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NA",
"warrantyDisclaimer":
{
"d": "EXgOcLxUdYerzwLIr9Bf7V_NAwY1lkFrn9y2PgveY4-9",
"l": "Issuer provides this credential on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE"
},
"liabilityDisclaimer":
{
"d": "EY1lkFrn9y2PgveY4-9XgOcLxUdYerzwLIr9Bf7V_NAw",
"l": "In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the Issuer be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this credential. "
}
}
}
```
```
{
"$id": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Public ACDC",
"description": "Example JSON Schema Public ACDC.",
"credentialType": "PublicACDCExample",
"type": "object",
"required":
[
"v",
"d",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry ID",
"type": "string"
},
"s":
{
"description": "schema section",
"oneOf":
[
{
"description": "schema section SAID",
"type": "string"
},
{
"description": "schema detail",
"type": "object"
}
]
},
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute section SAID",
"type": "string"
},
{
"description": "attribute detail",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute section SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false
}
]
},
"e":
{
"description": "edge section",
"oneOf":
[
{
"description": "edge section SAID",
"type": "string"
},
{
"description": "edge detail",
"type": "object",
"required":
[
"d",
"boss"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"boss":
{
"description": "boss edge",
"type": "object",
"required":
[
"d",
"n",
"s",
"w"
],
"properties":
{
"d":
{
"description": "edge SAID",
"type": "string"
},
"n":
{
"description": "far node SAID",
"type": "string"
},
"s":
{
"description": "far node schema SAID",
"type": "string",
"const": "EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71"
},
"w":
{
"description": "edge weight",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
},
"r":
{
"description": "rule section",
"oneOf":
[
{
"description": "rule section SAID",
"type": "string"
},
{
"description": "rule detail",
"type": "object",
"required":
[
"d",
"warrantyDisclaimer",
"liabilityDisclaimer"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"warrantyDisclaimer":
{
"description": "warranty disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
},
"liabilityDisclaimer":
{
"description": "liability disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
}
},
"additionalProperties": false
}
```
As explained previously, the primary difference between _partial disclosure_ and _selective disclosure_ is determined by the correlatability with respect to its encompassing block after _full disclosure_ of the detailed field value. A _partially disclosable_ field becomes correlatable to its encompassing block after its _full disclosure_. Whereas a _selectively disclosable_ field may be excluded from the _full disclosure_ of any other selectively disclosable fields in its encompassing block. After selective disclosure, the selectively disclosed fields are not correlatable to the so-far undisclosed but selectively disclosable fields in the same encompassing block. In this sense, _full disclosure_ means detailed disclosure of the selectively disclosed attributes not detailed disclosure of all selectively disclosable attributes.
Recall that _partial_ disclosure is an essential mechanism needed to support chain-link confidentiality {{CLC}}. The chain-link confidentiality exchange _offer_ requires _partial disclosure_, and _full disclosure_ only happens after _acceptance_ of the _offer_. _Selective_ disclosure, on the other hand, is an essential mechanism needed to unbundle in a correlation minimizing way a single commitment by an Issuer to a bundle of fields (i.e. a nested block or array of fields). This allows separating a "stew" of "ingredients" (attributes) into its constituent "ingredients" (attributes) without correlating the constituents via the stew.
ACDCs, as a standard, benefit from a minimally sufficient approach to selective disclosure that is simple enough to be universally implementable and adoptable. This does not preclude support for other more sophisticated but optional approaches. But the minimally sufficient approach should be universal so that at least one selective disclosure mechanism be made available in all ACDC implementations. To clarify, not all instances of an ACDC must employ the minimal selective disclosure mechanisms as described herein but all ACDC implementations must support any instance of an ACDC that employs the minimal selective disclosure mechanisms as described above.
The ACDC chaining mechanism reduces the need for selective disclosure in some applications. Many non-ACDC verifiable credentials provide bundled precisely because there is no other way to associate the attributes in the bundle. These bundled credentials could be refactored into a graph of ACDCs. Each of which is separately disclosable and verifiable thereby obviating the need for selective disclosure.
Nonetheless, some applications require bundled attributes and therefore may benefit from the independent selective disclosure of bundled attributes. This is provided by **_selectively disclosable attribute_** ACDCs.
The use of a revocation registry is an example of a type of bundling, not of attributes in a credential, but uses of a credential in different contexts. Unbundling the usage contexts may be beneficial. This is provided by **_bulk-issued_** ACDCs.
Finally, in the case where the correlation of activity of an Issuee across contexts even when the ACDC used in those contexts is not correlatable may be addressed of a variant of bulk-issued ACDCs that have **_unique issuee AIDs_** with an independent TEL registry per issuee instance. This provides non-repudiable (recourse supporting) disclosure while protecting from the malicious correlation between second parties and other second and/or third-parties as to who (Issuee) is involved in a presentation.
In any case, the set of selective disclosure mechanisms we call tiered selective disclosure which allows a user or implementer to better trade-off protection vs. complexity and performance. A tiered selective disclosure me
The basic selective disclosure mechanism shared by all is comprised of a single aggregated blinded commitment to a list of blinded commitments to undisclosed values. Membership of any blinded commitment to a value in the list of aggregated blinded commitments may be proven without leaking (disclosing) the unblinded value belonging to any other blinded commitment in the list. This enables provable selective disclosure of the unblinded values. When a non-repudiable digital signature is created on the aggregated blinded commitment then any disclosure of a given value belonging to a given blinded commitment in the list is also non-repudiable. This approach does not require any more complex cryptography than digests and digital signatures. This satisfies the design ethos of minimally sufficient means. The primary drawback of this approach is verbosity. It trades ease and simplicity and _adoptability_ of implementation for size. Its verbosity may be mitigated by replacing the list of blinded commitments with a Merkle tree of those commitments where the Merkle tree root becomes the aggregated blinded commitment.
Given sufficient cryptographic entropy of the blinding factors, collision resistance of the digests, and unforgeability of the digital signatures, either inclusion proof format (list or Merkle tree digest) prevents a potential disclosee or adversary from discovering in a computationally feasible way the values of any undisclosed blinded value details from the combination of the schema of those value details and either the aggregated blinded commitment and/or the list of aggregated blinded commitments {{Hash}}{{HCR}}{{QCHC}}{{Mrkl}}{{TwoPI}}{{MTSec}}. A potential disclosee or adversary would also need both the blinding factor and the actual value details.
Selective disclosure in combination with partial disclosure for chain-link confidentiality provides comprehensive correlation minimization because a discloser may use a non-disclosing metadata ACDC prior to acceptance by the disclosee of the terms of the chain-link confidentiality expressed in the rule section {{CLC}}. Thus only malicious disclosees who violate chain-link confidentiality may correlate between independent disclosures of the value details of distinct members in the list of aggregated blinded commitments. Nonetheless, they are not able to discover any as-of-yet undisclosed (unblinded) value details.
In a **_selectively disclosable attribute_** ACDC, the set of attributes is provided as an array of blinded blocks. Each attribute in the set has its own dedicated blinded block. Each block has its own SAID, `d`, field and UUID, `u`, field in addition to its attribute field or fields. When an attribute block has more than one attribute field then the set of fields in that block are not independently selectively disclosable but MUST be disclosed together as a set. Notable is that the field labels of the selectively disclosable attributes are also blinded because they only appear within the blinded block. This prevents un-permissioned correlation via contextualized variants of a field label that appear in a selectively disclosable block. For example, localized or internationalized variants where each variant's field label(s) each use a different language or some other context correlatable information in the field labels themselves.
A selectively-disclosable attribute section appears at the top level using the field label `A`. This is distinct from the field label `a` for a non-selectively-disclosable attribute section. This makes clear (unambiguous) the semantics of the attribute section's associated schema. This also clearly reflects the fact that the value of a compact variant of selectively-disclosable attribute section is an "aggregate" not a SAID. As described previously, the top-level selectively-disclosable attribute aggregate section, `A`, field value is an aggregate of cryptographic commitments used to make a commitment to a set (bundle) of selectively-disclosable attributes. The derivation of its value depends on the type of selective disclosure mechanism employed. For example, the aggregate value could be the cryptographic digest of the concatenation of an ordered set of cryptographic digests, a Merkle tree root digest of an ordered set of cryptographic digests, or a cryptographic accumulator.
The _Issuee_ attribute block is absent from an uncompacted untargeted selectively disclosable ACDC as follows:
```
{
"A":
[
{
"d": "ELIr9Bf7V_NHwY1lkgveY4-Frn9y2PY9XgOcLxUderzw",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"score": 96
},
{
"d": "E9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-",
"u": "0AghkDaG7OY1wjaDAE0qHcgN",
"name": "Jane Doe"
}
]
}
```
The _Issuee_ attribute block is present in an uncompacted untargeted selectively disclosable ACDC as follows:
```
{
"A":
[
{
"d": "ErzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-9XgOcLxUde",
"u": "0AqHcgNghkDaG7OY1wjaDAE0",
"i": "did:keri:EpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPmkPreYA"
},
{
"d": "ELIr9Bf7V_NHwY1lkgveY4-Frn9y2PY9XgOcLxUderzw",
"u": "0AG7OY1wjaDAE0qHcgNghkDa",
"score": 96
},
{
"d": "E9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PYgveY4-",
"u": "0AghkDaG7OY1wjaDAE0qHcgN",
"name": "Jane Doe"
}
]
}
```
Given that each attribute block's UUID, `u`, field has sufficient cryptographic entropy, then each attribute block's SAID, `d`, field provides a secure cryptographic digest of its contents that effectively blinds the attribute value from discovery given only its Schema and SAID. To clarify, the adversary despite being given both the schema of the attribute block and its SAID, `d`, field, is not able to discover the remaining contents of the attribute block in a computationally feasible manner such as a rainbow table attack {{RB}}{{DRB}}. Therefore the UUID, `u`, field of each attribute block enables the associated SAID, `d`, field to securely blind the block's contents notwithstanding knowledge of the block's schema and that SAID, `d`, field. Moreover, a cryptographic commitment to that SAID, `d`, field does not provide a fixed point of correlation to the associated attribute (SAD) field values themselves unless and until there has been specific disclosure of those field values themselves.
Given a total of _N_ elements in the attributes array, let _ai_ represent the SAID, `d`, field of the attribute at zero-based index _i_. More precisely the set of attributes is expressed as the ordered set,
_{ai for all i in {0, ..., N-1}}_.
The ordered set of _ai_ may be also expressed as a list, that is,
_\[a0, a1, ...., aN-1\]_.
Because the selectively-disclosable attributes are provided by an array (list), the uncompacted variant in the schema uses an array of items and the `anyOf` composition operator to allow one or more of the items to be disclosed without requiring all to be disclosed. Thus both the `oneOf` and `anyOf` composition operators are used. The `oneOf` is used to provide compact partial disclosure of the aggregate, _A_, as the value of the top-level selectively-disclosable attribute section, `A`, field in its compact variant and the nested `anyOf` operator is used to enable selective disclosure in the uncompacted selectively-disclosable variant.
```
{
"A":
{
"description": "selectively disclosable attribute aggregate section",
"oneOf":
[
{
"description": "attribute aggregate",
"type": "string"
},
{
"description": "selectively disclosable attribute details",
"type": "array",
"uniqueItems": true,
"items":
{
"anyOf":
[
{
"description": "issuer attribute",
"type": "object",
"required":
[
"d",
"u",
"i"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"i":
{
"description": "issuer SAID",
"type": "string"
}
},
"additionalProperties": false
},
{
"description": "score attribute",
"type": "object",
"required":
[
"d",
"u",
"score"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"score":
{
"description": "score value",
"type": "integer"
}
},
"additionalProperties": false
},
{
"description": "name attribute",
"type": "object",
"required":
[
"d",
"u",
"name"
],
"properties":
{
"d":
{
"description": "attribute SAID",
"type": "string"
},
"u":
{
"description": "attribute UUID",
"type": "string"
},
"name":
{
"description": "name value",
"type": "string"
}
},
"additionalProperties": false
}
]
}
}
],
"additionalProperties": false
}
}
```
All the _ai_ in the list are aggregated into a single aggregate digest denoted _A_ by computing the digest of their ordered concatenation. This is expressed as follows:
_A = H(C(ai for all i in {0, ..., N-1}))_ where _H_ is the digest (hash) operator and _C_ is the concatentation operator.
To be explicit, using the targeted example above, let _a0_ denote the SAID of the _Issuee_ attribute, _a1_ denote the SAID of the _score_ attribute, and _a2_ denote the SAID of the _name_ attribute then the aggregated digest _A_ is computed as follows:
_A = H(C(a0, a1, a2))_.
Equivalently using _+_ as the infix concatenation operator, we have,
_A = H(a0 + a1 + a2)_
Given sufficient collision resistance of the digest operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements {{BDC}}{{BDay}}{{QCHC}}{{HCR}}{{Hash}}.
In compact form, the value of the selectively-disclosable top-level attribute section, `A`, field is set to the aggregated value _A_. This aggregate _A_ makes a blinded cryptographic commitment to the all the ordered elements in the list,
_\[a0, a1, ...., aN-1\]_.
Moreover because each _ai_ element also makes a blinded commitment to its block's (SAD) attribute value(s), disclosure of any given _ai_ element does not expose or disclose any discoverable information detail about either its own or another block's attribute value(s). Therefore one may safely disclose the full list of _ai_ elements without exposing the blinded block attribute values.
Proof of inclusion in the list consists of checking the list for a matching value. A computationally efficient way to do this is to create a hash table or B-tree of the list and then check for inclusion via lookup in the hash table or B-tree.
To protect against later forgery given a later compromise of the signing keys of the Issuer, the issuer MUST anchor an issuance proof digest seal to the ACDC in its KEL. This seal binds the signing key state to the issuance. There are two cases. In the first case, an issuance/revocation registry is used. In the second case, an issuance/revocation registry is not used.
When the ACDC is registered using an issuance/revocation TEL (Transaction Event Log) then the issuance proof seal digest is the SAID of the issuance (inception) event in the ACDC's TEL entry. The issuance event in the TEL includes the SAID of the ACDC. This binds the ACDC to the issuance proof seal in the Issuer's KEL through the TEL entry.
When the ACDC is not registered using an issuance/revocation TEL then the issuance proof seal digest is the SAID of the ACDC itself.
In either case, this issuance proof seal makes a verifiable binding between the issuance of the ACDC and the key state of the Issuer at the time of issuance. Because aggregated value _A_ provided as the attribute section, `A`, field, value is bound to the SAID of the ACDC which is also bound to the key state via the issuance proof seal, the attribute details of each attribute block are also bound to the key state.
The requirement of an anchored issuance proof seal means that the forger Must first successfully publish in the KEL of the issuer an inclusion proof digest seal bound to a forged ACDC. This makes any forgery attempt detectable. To elaborate, the only way to successfully publish such a seal is in a subsequent interaction event in a KEL that has not yet changed its key state via a rotation event. Whereas any KEL that has changed its key state via a rotation must be forked before the rotation. This makes the forgery attempt either both detectable and recoverable via rotation in any KEL that has not yet changed its key state or detectable as duplicity in any KEL that has changed its key state. In any event, the issuance proof seal ensures detectability of any later attempt at forgery using compromised keys.
Given that aggregate value _A_ appears as the compact value of the top-level attribute section, `A`, field, the selective disclosure of the attribute at index _j_ may be proven to the disclosee with four items of information. These are:
- The actual detailed disclosed attribute block itself (at index _j_) with all its fields.
- The list of all attribute block digests, _\[a0, a1, ...., aN-1\]_ that includes _aj_.
- The ACDC in compact form with selectively-disclosable attribute section, `A`, field value set to aggregate _A_.
- The signature(s), _s_, of the Issuee on the ACDC's top-level SAID, `d`, field.
The actual detailed disclosed attribute block is only disclosed after the disclosee has agreed to the terms of the rules section. Therefore, in the event the potential disclosee declines to accept the terms of disclosure, then a presentation of the compact version of the ACDC and/or the list of attribute digests, _\[a0, a1, ...., aN-1\]_. does not provide any point of correlation to any of the attribute values themselves. The attributes of block _j_ are hidden by _aj_ and the list of attribute digests _\[a0, a1, ...., aN-1\]_ is hidden by the aggregate _A_. The partial disclosure needed to enable chain-link confidentiality does not leak any of the selectively disclosable details.
The disclosee may then verify the disclosure by:
- computing _aj_ on the selectively disclosed attribute block details.
- confirming that the computed _aj_ appears in the provided list _\[a0, a1, ...., aN-1\]_.
- computing _A_ from the provided list _\[a0, a1, ...., aN-1\]_.
- confirming that the computed _A_ matches the value, _A_, of the selectively-disclosable attribute section, `A`, field value in the provided ACDC.
- computing the top-level SAID, `d`, field of the provided ACDC.
- confirming the presence of the issuance seal digest in the Issuer's KEL
- confirming that the issuance seal digest in the Issuer's KEL is bound to the ACDC top-level SAID, `d`, field either directly or indirectly through a TEL registry entry.
- verifying the provided signature(s) of the Issuee on the provided top-level SAID, `d` field value.
The last 3 steps that culminate with verifying the signature(s) require determining the key state of the Issuer at the time of issuance, this may require additional verification steps as per the KERI, PTEL, and CESR-Proof protocols.
A private selectively disclosable ACDC provides significant correlation minimization because a presenter may use a metadata ACDC prior to acceptance by the disclosee of the terms of the chain-link confidentiality expressed in the rule section {{CLC}}. Thus only malicious disclosees who violate chain-link confidentiality may correlate between presentations of a given private selectively disclosable ACDC. Nonetheless, they are not able to discover any undisclosed attributes.
The inclusion proof via aggregated list may be somewhat verbose when there are a large number of attribute blocks in the selectively disclosable attribute section. A more efficient approach is to create a Merkle tree of the attribute block digests and let the aggregate, _A_, be the Merkle tree root digest {{Mrkl}}. Specifically, set the value of the top-level selectively-disclosable attribute section, `A`, field to the aggregate, _A_ whose value is the Merkle tree root digest {{Mrkl}}.
The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes {{TwoPI}}{{MTSec}}. The discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, _aj_ contributed to the Merkle tree root digest, _A_. For ACDCs with a small number of attributes the added complexity of the Merkle tree approach may not be worth the savings in verbosity.
The amount of data transferred between the Issuer and Issuee (or recipient in the case of an untargeted ACDC) at issuance of a selectively disclosable attribute ACDC may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUDI, `u`, fields from a shared secret salt {{Salt}}.
There are several ways that the Issuer may securely share that secret salt. Given that an Ed25519 key pair(s) controls each of the Issuer and Issuee AIDs, (or recipient AID in the case of an untargeted ACDC) a corresponding X15519 asymmetric encryption key pair(s) may be derived from each controlling Ed25519 key pair(s) {{EdSC}}{{PSEd}}{{TMEd}}{{SKEM}}. An X25519 public key may be securely derived from an Ed25519 public key {{KeyEx}}{{SKEM}}. Likewise, an X25519 private key may be securely derived from an Ed25519 private key {{KeyEx}}{{SKEM}}.
In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key {{KeyEx}}{{DHKE}}. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived.
In a non-interactive approach, the Issuer derives an X25519 asymmetric public encryption key from the Issuee's (recipient's) public Ed25519 public key. The Issuer then encrypts the secret salt with that public asymmetric encryption key and signs the encryption with the Issuer's private Ed25519 signing key. This is transmitted to the Issuee, who verifies the signature and decrypts the secret salt using the private X25519 decryption key derived from the Issuee's private Ed25519 key. This non-interactive approach is more scalable for AIDs that are controlled with a multi-sig group of signing keys. The Issuer can broadcast to all members of the Issuee's (or recipient's) multi-sig signing group individually asymmetrically encrypted and signed copies of the secret salt.
In addition to the secret salt, the Issuer provides to the Issuee (recipient) a template of the ACDC but with empty UUID, `u`, and SAID, `d`, fields in each block with such fields. Each UUID, `u`, field value is then derived from the shared salt with a path prefix that indexes a specific block. Given the UUID, `u`, field value, the SAID, `d`, field value may then be derived. Likewise, both compact and uncompacted versions of the ACDC may then be generated. The derivation path for the top-level UUID, `u`, field (for private ACDCS), is the string "0" and derivation path the the the zeroth indexed attribute in the attributes array is the string "0/0". Likewise, the next attribute's derivation path is the string "0/1" and so forth.
In addition to the shared salt and ACDC template, the Issuer also provides its signature(s) on its own generated compact version ACDC. The Issuer may also provide references to the anchoring issuance proof seals. Everything else an Issuee (recipient) needs to make a verifiable presentation/disclosure can be computed at the time of presentation/disclosure by the Issuee.
The purpose of bulk issuance is to enable the Issuee to more efficiently use ACDCs with unique SAIDs to isolate and minimize correlation across different usage contexts. Each member of a set of bulk-issued ACDCs is essentially the same ACDC but with a unique SAID. This enables public commitments to each of the unqiue ACDC SAIDs without correlating between them. A private ACDC may be effectively issued in bulk as a set. In its basic form, the only difference between each ACDC is the top-level SAID, _d_, and UUID, _u_ field values. To elaborate, bulk issuance enables the use of un-correlatable copies while minimizing the associated data transfer and storage requirements involved in the issuance. Essentially each copy (member) of a bulk issued ACDC set shares a template that both the Issuer and Issuee use to generate on-the-fly a given ACDC in that set without requiring that the Issuer and Issuee exchange and store a unique copy of each member of the set independently. This minimizes the data transfer and storage requirements for both the Issuer and the Issuee. The Issuer is only required to provide a single signature for the bulk issued aggregate value _B_ defined below. The same signature may be used to provide proof of issuance of any member of the bulk issued set. The signature on _B_ and _B_ itself are points of correlation but these need only be disclosed after contractually protected disclosure is in place, i.e no permissioned correlation. Thus correlation requires a colluding second party who enagages in unpermissioned correlation.
An ACDC provenance chain is connected via references to the SAIDs given by the top-level SAID, `d`, fields of the ACDCs in that chain. A given ACDC thereby makes commitments to other ACDCs. Expressed another way, an ACDC may be a node in a directed graph of ACDCs. Each directed edge in that graph emanating from one ACDC includes a reference to the SAID of some other connected ACDC. These edges provide points of correlation to an ACDC via their SAID reference. Private bulk issued ACDCs enable the Issuee to better control the correlatability of presentations using different presentation strategies.
For example, the Issuee could use one copy of a bulk-issued private ACDC per presentation even to the same verifier. This strategy would consume the most copies. It is essentially a one-time-use ACDC strategy. Alternatively, the Issuee could use the same copy for all presentations to the same verifier and thereby only permit the verifier to correlate between presentations it received directly but not between other verifiers. This limits the consumption to one copy per verifier. In yet another alternative, the Issuee could use one copy for all presentations in a given context with a group of verifiers, thereby only permitting correlation among that group.
In this context, we are talking about permissioned correlation. Any verifier that has received a complete presentation of a private ACDC has access to all the fields disclosed by the presentation but the terms of the chain-link confidentiality agreement may forbid sharing those field values outside a given context. Thus an Issuee may use a combination of bulk issued ACDCs with chain-link confidentiality to control permissioned correlation of the contents of an ACDC while allowing the SAID of the ACDC to be more public. The SAID of a private ACDC does not expose the ACDC contents to an un-permissioned third party. Unique SAIDs belonging to bulk issued ACDCs prevent third parties from making a provable correlation between ACDCs via their SAIDs in spite of those SAIDs being public. This does not stop malicious verifiers (as second parties) from colluding and correlating against the disclosed fields but it does limit provable correlation to the information disclosed to a given group of malicious colluding verifiers. To restate unique SAIDs per copy of a set of private bulk issued ACDC prevent un-permissioned third parties from making provable correlations, in spite of those SAIDs being public, unless they collude with malicious verifiers (second parties).
In some applications, chain-link-confidentiality is insufficient to deter un-permissioned correlation. Some verifiers may be malicious with sufficient malicious incentives to overcome whatever counter incentives the terms of the contractual chain-link confidentiality may impose. In these cases, more aggressive technological anti-correlation mechanisms such as bulk issued ACDCs may be useful. To elaborate, in spite of the fact that chain-link confidentiality terms of use may forbid such malicious correlation, making such correlation more difficult technically may provide better protection than chain-link confidentiality alone {{CLC}}.
It is important to note that any group of colluding malicious verifiers may always make a statistical correlation between presentations despite technical barriers to cryptographically provable correlation. We call this contextual linkability. In general, there is no cryptographic mechanism that precludes statistical correlation among a set of colluding verifiers because they may make cryptographically unverifiable or unprovable assertions about information presented to them that may be proven as likely true using merely statistical correlation techniques. Linkability due the context of the disclosure itself may defeat any unlinkability guarantees of a cryptographic technique. Thus without contractually protected disclosure, contextual linkability in spite of cryptographic unlinkability may make the complexity of using advanced cryptographic mechanisms to provide unlinkability an exercise in diminishing returns.
The amount of data transferred between the Issuer and Issuee (or recipient of an untargeted ACDC) at issuance of a set of bulk issued ACDCs may be minimized by using a hierarchical deterministic derivation function to derive the value of the UUID, `u`, fields from a shared secret salt {{Salt}}.
As described above, there are several ways that the Issuer may securely share a secret salt. Given that the Issuer and Issuee (or recipient when untargeted) AIDs are each controlled by an Ed25519 key pair(s), a corresponding X15519 asymmetric encryption key pair(s) may be derived from the controlling Ed25519 key pair(s) {{EdSC}}{{PSEd}}{{TMEd}}. An X25519 public key may be securely derived from an Ed25519 public key {{KeyEx}}{{SKEM}}. Likewise, an X25519 private key may be securely derived from an Ed25519 private key {{KeyEx}}{{SKEM}}.
In an interactive approach, the Issuer derives a public asymmetric X25519 encryption key from the Issuee's published Ed25519 public key and the Issuee derives a public asymmetric X25519 encryption key from the Issuer's published Ed25519 public key. The two then interact via a Diffie-Hellman (DH) key exchange to create a shared symmetric encryption key {{KeyEx}}{{DHKE}}. The shared symmetric encryption key may be used to encrypt the secret salt or the shared symmetric encryption key itself may be used has high entropy cryptographic material from which the secret salt may be derived.
In a non-interactive approach, the Issuer derives an X25519 asymmetric public encryption key from the Issuee's (or recipient's) public Ed25519 public key. The Issuer then encrypts the secret salt with that public asymmetric encryption key and signs the encryption with the Issuer's private Ed25519 signing key. This is transmitted to the Issuee, who verifies the signature and decrypts the secret salt using the private X25519 decryption key derived from the Issuee's private Ed25519 key. This non-interactive approach is more scalable for AIDs that are controlled with a multi-sig group of signing keys. The Issuer can broadcast to all members of the Issuee's (or recipient's) multi-sig signing group individually asymmetrically encrypted and signed copies of the secret salt.
In addition to the secret salt, the Issuer also provides a template of the private ACDC but with empty UUID, `u`, and SAID, `d`, fields at the top-level of each nested block with such fields. Each UUID, `u`, field value is then derived from the shared salt with a deterministic path prefix that indexes both its membership in the bulk issued set and its location in the ACDC. Given the UUID, `u`, field value, the associated SAID, `d`, field value may then be derived. Likewise, both full and compact versions of the ACDC may then be generated. This generation is analogous to that described in the section for selective disclosure ACDCs but extended to a set of private ACDCs.
The initial element in each deterministic derivation path is the string value of the bulk-issued member's copy index _k_, such as "0", "1", "2" etc. Specifically, if _k_ denotes the index of an ordered set of bulk issued private ACDCs of size _M_, the derivation path starts with the string _"k"_ where _k_ is replaced with the decimal or hexadecimal textual representation of the numeric index _k_. Furthermore, a bulk-issued private ACDC with a private attribute section uses _"k"_ to derive its top-level UUID and _"k/0"_ to derive its attribute section UUID. This hierarchical path is extended to any nested private attribute blocks. This approach is further extended to enable bulk issued selective disclosure ACDCs by using a similar hierarchical derivation path for the UUID field value in each of the selectively disclosable blocks in the array of attributes. For example, the path _"k/j"_ is used to generate the UUID of attribute index _j_ at bulk-issued ACDC index _k_.
In addition to the shared salt and ACDC template, the Issuer also provides a list of signatures of SAIDs, one for each SAID of each copy of the associated compact bulk-issued ACDC. The Issuee (or recipient) can generate on-demand each compact or uncompacted ACDC from the template, the salt, and its index _k_. The Issuee does not need to store a copy of each bulk issued ACDC, merely the template, the salt, and the list of signatures.
The Issuer MUST also anchor in its KEL an issuance proof digest seal of the set of bulk issued ACDCs. The issuance proof digest seal makes a cryptographic commitment to the set of top-level SAIDS belonging to the bulk issued ACDCs. This protects against later forgery of ACDCs in the event the Issuer's signing keys become compromised. A later attempt at forgery requires a new event or new version of an event that includes a new anchoring issuance proof digest seal that makes a cryptographic commitment to the set of newly forged ACDC SAIDS. This new anchoring event of the forgery is therefore detectable.
Similarly, to the process of generating a selective disclosure attribute ACDC, the issuance proof digest is an aggregate that is aggregated from all members in the bulk-issued set of ACDCs. The complication of this approach is that it must be done in such a way as to not enable provable correlation by a third party of the actual SAIDS of the bulk-issued set of ACDCs. Therefore the actual SAIDs must not be aggregated but blinded commitments to those SAIDs instead. With blinded commitments, knowledge of any or all members of such a set does not disclose the membership of any SAID unless and until it is unblinded. Recall that the purpose of bulk issuance is to allow the SAID of an ACDC in a bulk issued set to be used publicly without correlating it in an un-permissioned provable way to the SAIDs of the other members.
The basic approach is to compute the aggregate denoted, _B_, as the digest of the concatenation of a set of blinded digests of bulk issued ACDC SAIDS. Each ACDC SAID is first blinded via concatenation to a UUID (salty nonce) and then the digest of that concatenation is concatenated with the other blinded SAID digests. Finally, a digest of that concatenation provides the aggregate.
Suppose there are _M_ ACDCs in a bulk issued set. Using zero-based indexing for each member of the bulk issued set of ACDCs, such that index _k_ satisfies _k in {0, ..., M-1}, let_ dk _denote the top-level SAID of an ACDC in an ordered set of bulk-issued ACDCs. Let_ vk _denote the UUID (salty nonce) or blinding factor that is used to blind that said. The blinding factor,_ vk_, is NOT the top-level UUID, `u`, field of the ACDC itself but an entirely different UUID used to blind the ACDC's SAID for the purpose of aggregation. The derivation path for_ vk _from the shared secret salt is_ "k." _where_ k\* is the index of the bulk-issued ACDC.
Let _ck = vk + dk_, denote the blinding concatenation where _+_ is the infix concatenation operator. Then the blinded digest, _bk_, is given by, _bk = H(ck) = H(vk + dk)_, where _H_ is the digest operator. Blinding is performed by a digest of the concatenation of the binding factor, _vk_, with the SAID, _dk_ instead of XORing the two. An XOR of two elements whose bit count is much greater than 2 is not vulnerable to a birthday table attack {{BDay}}{{DRB}}{{BDC}}. In order to XOR, however, the two must be of the same length. Different SAIDs MAY be of different lengths, however, and MAY therefore require different length blinding factors. Because concatenation is length independent it is simpler to implement.
The aggregation of blinded digests, _B_, is given by, _B = H(C(bk for all k in {0, ..., M-1}))_, where _C_ is the concatenation operator and _H_ is the digest operator. This aggregate, _B_, provides the issuance proof digest.
The aggregate, _B_, makes a blinded cryptographic commitment to the ordered elements in the list _\[b0, b1, ...., bM-1\]_. A commitment to _B_ is a commitment to all the _bk_ and hence all the dk.
Given sufficient collision resistance of the digest operator, the digest of an ordered concatenation is not subject to a birthday attack on its concatenated elements {{BDC}}{{BDay}}{{QCHC}}{{HCR}}{{Hash}}.
Disclosure of any given _bk_ element does not expose or disclose any discoverable information detail about either the SAID of its associated ACDC or any other ACDC's SAID. Therefore one may safely disclose the full list of _bk_ elements without exposing the blinded bulk issued SAID values, dk.
Proof of inclusion in the list of blinded digests consists of checking the list for a matching value. A computationally efficient way to do this is to create a hash table or B-tree of the list and then check for inclusion via lookup in the hash table or B-tree.
A proof of inclusion of an ACDC in a bulk-issued set requires disclosure of _vk_ which is only disclosed after the disclosee has accepted (agreed to) the terms of the rule section. Therefore, in the event the _Disclosee_ declines to accept the terms of disclosure, then a presentation/disclosure of the compact version of the ACDC does not provide any point of correlation to any other SAID of any other ACDC from the bulk set that contributes to the aggregate _B_. In addition, because the other SAIDs are hidden by each _bk_ inside the aggregate, _B_, even a presentation/disclosure of, _\[b0, b1, ...., bM-1\]_ does not provide any point of correlation to the actual bulk-issued ACDC without disclosure of its _vk_. Indeed if the _Discloser_ uses a metadata version of the ACDC in its _offer_ then even its SAID is not disclosed until after acceptance of terms in the rule section.
To protect against later forgery given a later compromise of the signing keys of the Issuer, the issuer MUST anchor an issuance proof seal to the ACDC in its KEL. This seal binds the signing key state to the issuance. There are two cases. In the first case, an issuance/revocation registry is used. In the second case, an issuance/revocation registry is not used.
When the ACDC is registered using an issuance/revocation TEL (Transaction Event Log) then the issuance proof seal digest is the SAID of the issuance (inception) event in the ACDC's TEL entry. The issuance event in the TEL uses the aggregate value, _B_, as its identifier value. This binds the aggregate, _B_, to the issuance proof seal in the Issuer's KEL through the TEL.
Recall that the usual purpose of a TEL is to provide a verifiable data registry that enables dynamic revocation of an ACDC via a state of the TEL. A verifier checks the state at the time of use to check if the associated ACDC has been revoked. The Issuer controls the state of the TEL. The registry identifier, `ri`, field is used to identify the public registry which usually provides a unique TEL entry for each ACDC. Typically the identifier of each TEL entry is the SAID of the TEL's inception event which is a digest of the event's contents which include the SAID of the ACDC. In the bulk issuance case, however, the TEL's inception event contents include the aggregate, _B_, instead of the SAID of a given ACDC. Recall that the goal is to generate an aggregate value that enables an Issuee to selectively disclose one ACDC in a bulk-issued set without leaking the other members of the set to un-permissioned parties (second or third). Using the aggregate, _B_ of blinded ACDC saids as the TEL registry entry identifier allows all members of the bulk-issued set to share the same TEL without any third party being able to discover which TEL any ACDC is using in an un-permissioned provable way. Moreover, a second party may not discover in an un-permissioned way any other ACDCs from the bulk-issued set not specifically disclosed to that second party. In order to prove to which TEL a specific bulk issued ACDC belongs, the full inclusion proof must be disclosed.
When the ACDC is not registered using an issuance/revocation TEL then the issuance proof seal digest is the aggregate, _B_, itself.
In either case, this issuance proof seal makes a verifiable binding between the issuance of all the ACDCs in the bulk issued set and the key state of the Issuer at the time of issuance.
A _Discloser_ may make a basic provable non-repudiable selective disclosure of a given bulk issued ACDC, at index _k_ by providing to the _Disclosee_ four items of information (proof of inclusion). These are as follows:
- The ACDC in compact form (at index _k_) where _dk_ as the value of its top-level SAID, `d`, field.
- The blinding factor, _vk_ from which _bk = H(vk + dk)_ may be computed.
- The list of all blinded SAIDs, _\[b0, b1, ...., bM-1\]_ that includes _bk_.
- A reference to the anchoring seal in the Issuer's KEL or TEL that references the aggregate _B_. The event that references the seal or the TEL event that references _B_ must be signed by the issuer so the signature on either event itself is sufficient to prove authorized issuance.
The aggregate _B_ is a point of unpermissioned correlation but not permissioned correlation. To remove _B_ as a point of unpermissioned correlation requires using _independent TEL bulk-issued ACDCs_ described in the section so named below.
A _Disclosee_ may then verify the disclosure by:
- computing _dj_ on the disclosed compact ACDC.
- computing _bk = H(vk + dk)_
- confirming that the computed _bk_ appears in the provided list _\[b0, b1, ...., bM-1\]_.
- computing the aggregate _B_ from the provided list _\[b0, b1, ...., bM-1\]_..
- confirming the presence of an issuance seal digest in the Issuer's KEL that makes a commitment to the aggregate, _B_, either directly or indirectly through a TEL registry entry. This provides proof of authorized issuance.
The last 3 steps that culminate with verifying the anchoring seal also require verifying the key state of the Issuer at the time of issuance, this may require additional verification steps as per the KERI, PTEL, and CESR-Proof protocols.
The requirement of an anchored issuance proof seal of the aggregate _B_ means that the forger MUST first successfully publish in the KEL of the issuer an inclusion proof digest seal bound to a set of forged bulk issued ACDCs. This makes any forgery attempt detectable. To elaborate, the only way to successfully publish such a seal is in a subsequent interaction event in a KEL that has not yet changed its key state via a rotation event. Whereas any KEL that has changed its key state via a rotation must be forked before the rotation. This makes the forgery attempt either both detectable and recoverable via rotation in any KEL that has not yet changed its key state or detectable as duplicity in any KEL that has changed its key state. In any event, the issuance proof seal makes any later attempt at forgery using compromised keys detectable.
The inclusion proof via aggregated list may be somewhat verbose when there are a very large number of bulk issued ACDCs in a given set. A more efficient approach is to create a Merkle tree of the blinded SAID digests, _bk_ and set the aggregate _B_ value as the Merkle tree root digest {{Mrkl}}.
The Merkle tree needs to have appropriate second-pre-image attack protection of interior branch nodes {{TwoPI}}{{MTSec}}. The discloser then only needs to provide a subset of digests from the Merkle tree to prove that a given digest, _bk_ contributed to the Merkle tree root digest. For a small numbered bulk-issued set of ACDCs, the added complexity of the Merkle tree approach may not be worth the savings in verbosity.
One potential point of provable but un-permissioned correlation among any group of colluding malicious _Disclosees_ (Second-Party verifiers) may arise when the same Issuee AID is used for presentation/disclosure to all _Disclosees_ in that group. Recall that the contents of private ACDCs are not disclosed except to permissioned _Disclosees_ (Second-Parties). Thus a common _Issuee_ AID would only be a point of correlation for a group of colluding malicious verifiers. But in some cases removing this un-permissioned point of correlation may be desirable.
One solution to this problem is for the _Issuee_ to use a unique AID for the copy of a bulk-issued ACDC presented to each _Disclosee_ in a given context. This requires that each ACDC copy in the bulk-issued set use a unique _Issuee_ AID. This would enable the _Issuee_ in a given context to minimize provable correlation by malicious _Disclosees_ against any given _Issuee_ AID. In this case, the bulk issuance process may be augmented to include the derivation of a unique Issuee AID in each copy of the bulk-issued ACDC by including in the inception event that defines a given Issuee's self-addressing AID, a digest seal derived from the shared salt and copy index _k_. The derivation path for the digest seal is _"k/0."_ where _k_ is the index of the ACDC. To clarify _"k/0."_ specifies the path to generate the UUID to be included in the inception event that generates the Issuee AID for the ACDC at index _k_. This can be generated on-demand by the _Issuee_. Each unique _Issuee_ AID would also need its own KEL. But generation and publication of the associated KEL can be delayed until the bulk-issued ACDC is actually used. This approach completely isolates a given _Issuee_ AID to a given context with respect to the use of a bulk-issued private ACDC. This protects against even the un-permissioned correlation among a group of malicious Disclosees (Second Parties) via the Issuee AID.
In some applications, it is desirable that the current state of a transaction event log (TEL) be hidden or blinded such that the only way for a potential verifier of the state to observe that state is when the controller of a designated AID discloses it at the time of presentation. This designated AID we call the Discloser. Typically for ACDCs that have an Issuee, the Discloser is the Issuee, but the Issuer could designate any AID as the Discloser. Only the Discloser will be able to unblind the state to a potential Disclosee.
In a blindable state TEL, the state disclosure is interactive. A Disclosee may only observe the state when unblinded via an interactive exchange with the Discloser. After disclosure, the Discloser may then request that the Issuer update the state with a new blinding factor (_the blind_). The Disclosee cannot then observe the current state of the TEL without yet another disclosure interaction with the Discloser.
The blind is derived from a secret salt shared between the Issuer and the designated Discloser. The current blind is derived from this salt, and the sequence number of the TEL event is so blinded. To elaborate, the derivation path for the blind is the sequence number of the TEL event, which in combination with the salt, produces a universally unique salty nonce for the blind. Only the Issuer and Discloser have a copy of the secret salt, so only they can derive the current blind. The Issuer provides a service endpoint to which the Discloser can make a signed request to update the blind. Each new event in the TEL MUST change the blinding factor but MAY or MAY NOT change the actual blinded state. Only the Issuer can change the actual blinded state. Because each updated event in the TEL has a new blinding factor regardless of an actual change of state or not, an observer can not correlate state changes to event updates as long as the Issuer regularly updates the blinding factor by issuing a new TEL event.
Blindable State TEL events use a unique event type, `upd`. The event state is hidden in the `a` field, whose value is the blinded SAID of a field map that holds the TEL state. The field map's SAID is its `d` field. The blinding factor is provided in the field map's `u` field. The SAID of the associated ACDC is in the field map's `i` field or else the aggregate value for bulk issued ACDCs. The actual state of the TEL for that ACDC is provided by other fields in the `a`, field map. A simple state could use the `s` field for state or status.
When the `u` field is missing or empty, then the event is not blindable. When the `u` field has sufficient entropy, then the SAID of the enclosing field map effectively blinds the state provided by that map. The discloser must disclose the field map to the Disclosee, who can verify that its SAID matches the SAID in the TEL. A subsequent update event entered into that TEL will then re-blind the state of the TEL so that any prior Disclosees may no longer verify the current state of the TEL.
| Label | Description | Notes |
| --- | --- | --- |
| v | version string | |
| d | event digest | SAID |
| s | sequence number of event | |
| t | message type of event | `upd` |
| dt | issuer system data/time in iso format | |
| p | prior event digest | SAID |
| ri | registry identifier from management TEL | |
| ra | registry anchor to management TEL | |
| a | state attributed digest | SAID |
| Label | Description | Notes |
| --- | --- | --- |
| d | attribute digest | SAID |
| u | salty nonce blinding factor | UUID |
| i | namespaced identifier of VC or aggregate when bulk issued | SAID or Aggregate |
| s | state value | `issued` or `revoked` |
Recall that the purpose of using the aggregate _B_ for a bulk-issued set from which the TEL identifier is derived is to enable a set of bulk-issued ACDCs to share a single public TEL and/or a single anchoring seal in the Issuer's KEL without enabling un-permissioned correlation to any other members of the bulk set by virtue of the shared aggregate _B_ used for either the TEL or anchoring seal in the KEL. When using a TEL this enables the issuance/revocation/transfer state of all copies of a set of bulk-issued ACDCs to be provided by a single TEL which minimizes the storage and compute requirements on the TEL registry while providing selective disclosure to prevent un-permissioned correlation via the public TEL. When using an anchoring seal, this enables one signature to provide proof of inclusion in the bulk-issued aggregate _B_.
However, in some applications where chain-link confidentiality does not sufficiently deter malicious provable correlation by Disclosees (Second-Party verifiers), an Issuee may benefit from using ACDC with independent TELs or independent aggregates _B_ but that are still bulk-issued.
In this case, the bulk issuance process must be augmented so that each uniquely identified copy of the ACDC gets its own TEL entry (or equivalently its own aggregate _B_) in the registry. Each Disclosee (verifier) of a full presentation/disclosure of a given copy of the ACDC only receives proof of one uniquely identified TEL and can NOT provably correlate the TEL state of one presentation to any other presentation because the ACDC SAID, the TEL identifier, and the signature of the issuer on each aggregate _B_ will be different for each copy. There is, therefore no point of provable correlation, permissioned or otherwise. One could for example, modulate this apprach by having a set of smaller bulk issued sets that are more contextualized than one large bulk issued set.
The obvious drawbacks of this approach (independent unique TELs for each private ACDC) are that the size of the registry database increases as a multiple of the number of copies of each bulk-issued ACDC and every time an Issuer must change the TEL state of a given set of copies it must change the state of multiple TELs in the registry. This imposes both a storage and computation burden on the registry. The primary advantage of this approach, however, is that each copy of a private ACDC has a uniquely identified TEL. This minimizes un-permissioned Third-Party exploitation via provable correlation of TEL identifiers even with colluding Second-Party verifiers. They are limited to statistical correlation techniques.
In this case, the set of private ACDCs may or may not share the same Issuee AID because for all intents and purposes each copy appears to be a different ACDC even when issued to the same Issuee. Nonetheless, using unique Issuee AIDs may further reduce correlation by malicious Disclosees (Second-Party verifiers) beyond using independent TELs.
To summarize the main benefit of this approach, in spite of its storage and compute burden, is that in some applications chain-link confidentiality does not sufficiently deter un-permissioned malicious collusion. Therefore completely independent bulk-issued ACDCs may be used.
ToDo
Append-only verifiable data structures have strong security properties that simplify end-verifiability & foster decentralization.
Append-only provides permission-less extensibility by downstream issuers, presenters, and/or verifiers
Each ACDC has a universally-unique content-based identifier with a universally-unique content-based schema identifier.
Fully decentralized name-spacing.
Custom fields are appended via chaining via one or more custom ACDCs defined by custom schema (type-is-schema).
No need for centralized permissioned name-space registries to resolve name-space collisions.
The purposes of a registry now become merely schema discovery or schema blessing for a given context or ecosystem.
The reach of the registry is tuned to the reach of desired interoperability by the ecosystem participants.
Human meaningful labels on SAIDs are local context only.
Versioning is simplified because edges still verify if new schema are backwards compatible. (persistent data structure model).
The compact disclosure and distribute property graph fragment mechanisms in ACDC can be leveraged to enable high performance at scale. Simply using SAIDs and signed SAIDs of ACDCs in whole or in part enables compact but securely attributed and verifiable references to ACDCs to be employed anywhere performance is an issue. Only the SAID and its signature need be transmitted to verify secure attribution of the data represented by the SAID. Later receipt of the data may be verified against the SAID. The signature does not need to be re-verified because a signature on a SAID is making a unique (to within the cryptographic strength of the SAID) commitment to the data represented by the SAID. The actual detailed ACDC in whole or in part may then be cached or provided on-demand or just-in-time.
Hierarchical decomposition of data into a distributed verifiable property graph, where each ACDC is a distributed graph fragment, enables performant reuse of data or more compactly performant reuse of SAIDs and their signatures. The metadata and attribute sections of each ACDC provide a node in the graph and the edge section of each ACDC provides the edges to that node. Higher-up nodes in the graph with many lower-level nodes need only be transmitted, verified, and cached once per every node or leaf in the branch not redundantly re-transmitted and re-verified for each node or leaf as is the case for document-based verifiable credentials where the whole equivalent of the branched (graph) structure must be contained in one document. This truly enables the bow-tie model popularized by Ricardian contracts, not merely for contracts, but for all data authenticated, authorized, referenced, or conveyed by ACDCs.
For crypto-systems with _perfect-security_, the critical design parameter is the number of bits of entropy needed to resist any practical brute force attack. In other words, when a large random or pseudo-random number from a cryptographic strength pseudo-random number generator (CSPRNG) {{CSPRNG}} expressed as a string of characters is used as a seed or private key to a cryptosystem with _perfect-security_, the critical design parameter is determined by the amount of random entropy in that string needed to withstand a brute force attack. Any subsequent cryptographic operations must preserve that minimum level of cryptographic strength. In information theory {{IThry}}{{ITPS}} the entropy of a message or string of characters is measured in bits. Another way of saying this is that the degree of randomness of a string of characters can be measured by the number of bits of entropy in that string. Assuming conventional non-quantum computers, the convention wisdom is that, for systems with information-theoretic or perfect security, the seed/key needs to have on the order of 128 bits (16 bytes, 32 hex characters) of entropy to practically withstand any brute force attack. A cryptographic quality random or pseudo-random number expressed as a string of characters will have essentially as many bits of entropy as the number of bits in the number. For other crypto-systems such as digital signatures that do not have perfect security, the size of the seed/key may need to be much larger than 128 bits in order to maintain 128 bits of cryptographic strength.
An N-bit long base-2 random number has 2N different possible values. Given that no other information is available to an attacker with perfect security, the attacker may need to try every possible value before finding the correct one. Thus the number of attempts that the attacker would have to try maybe as much as 2N-1. Given available computing power, one can easily show that 128 is a large enough N to make brute force attack computationally infeasible.
Let's suppose that the adversary has access to supercomputers. Current supercomputers can perform on the order of one quadrillion operations per second. Individual CPU cores can only perform about 4 billion operations per second, but a supercomputer will parallelly employ many cores. A quadrillion is approximately 250 = 1,125,899,906,842,624. Suppose somehow an adversary had control over one million (220 = 1,048,576) supercomputers which could be employed in parallel when mounting a brute force attack. The adversary could then try 250 _220 = 270 values per second (assuming very conservatively that each try only took one operation). There are about 3600_ 24 \* 365 = 313,536,000 = 2log2313536000\=224.91 ~= 225 seconds in a year. Thus this set of a million super computers could try 250+20+25 = 295 values per year. For a 128-bit random number this means that the adversary would need on the order of 2128-95 = 233 = 8,589,934,592 years to find the right value. This assumes that the value of breaking the cryptosystem is worth the expense of that much computing power. Consequently, a cryptosystem with perfect security and 128 bits of cryptographic strength is computationally infeasible to break via brute force attack.
The highest level of cryptographic security with respect to a cryptographic secret (seed, salt, or private key) is called _information-theoretic security_ {{ITPS}}. A cryptosystem that has this level of security cannot be broken algorithmically even if the adversary has nearly unlimited computing power including quantum computing. It must be broken by brute force if at all. Brute force means that in order to guarantee success the adversary must search for every combination of key or seed. A special case of _information-theoretic security_ is called _perfect-security_ {{ITPS}}. _Perfect-security_ means that the ciphertext provides no information about the key. There are two well-known cryptosystems that exhibit _perfect security_. The first is a _one-time-pad_ (OTP) or Vernum Cipher {{OTP}}{{VCphr}}, the other is _secret splitting_ {{SSplt}}, a type of secret sharing {{SShr}} that uses the same technique as a _one-time-pad_.
{::boilerplate bcp14-tagged}
- `SAID` - Self-Addressing Identifier - any identifier which is deterministically generated out of the content, digest of the content
Refer to the body of the specification. Security considerations are included in the context of each section. The ACDC specification is security driven so the specification itself is riddled with discussions of the security considerations in the context in which those discussions are most understandable and relevant.
This document has no IANA actions.
\--- back
{:numbered="false"}
ACDC community.
---
title: WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
description: 9286652585568, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/08_annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
md: https://weboftrust.github.io/WOT-terms/08_annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof.md
---
# WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
title: "CESR Proof Signatures" abbrev: "CESR-PROOF" docname: draft-pfeairheller-cesr-proof-latest category: info
ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
author:
- name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](mailto:Philip.Feairheller@gleif.org)
normative: ACDC: target: [https://datatracker.ietf.org/doc/draft-ssmith-acdc/](https://datatracker.ietf.org/doc/draft-ssmith-acdc/) title: Authentic Data Chained Containers author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021 CESR: target: [https://datatracker.ietf.org/doc/draft-ssmith-cesr/](https://datatracker.ietf.org/doc/draft-ssmith-cesr/) title: Composable Event Streaming Representation (CESR) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
SAID: target: [https://datatracker.ietf.org/doc/draft-ssmith-said/](https://datatracker.ietf.org/doc/draft-ssmith-said/) title: Self-Addressing IDentifier (SAID) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
informative: KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
RFC6901: target: [https://datatracker.ietf.org/doc/html/rfc6901](https://datatracker.ietf.org/doc/html/rfc6901) title: JavaScript Object Notation (JSON) Pointer author:
```
-
name: Paul C. Bryan
-
name: Kris Zyp
-
name: Mark Nottingham
date: 2003
```
JSONPath: target: [https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/](https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/) title: JSONPath - Query expressions for JSON author:
```
-
name: Stefan Gössner
-
name: Glyn Normington
-
name: Carsten Bormann
date: 2021-10-25
```
tags: IETF, CESR, SAID, KERI, ACDC
\--- abstract
CESR Proof Signatures are an extension to the Composable Event Streaming Representation \[CESR\] that provide transposable cryptographic signature attachments on self-addressing data (SAD) \[SAID\]. Any SAD, such as an Authentic Chained Data Container (ACDC) Verifiable Credential \[ACDC\] for example, may be signed with a CESR Proof Signature and streamed along with any other CESR content. In addition, a signed SAD can be embedded inside another SAD and the CESR proof signature attachment can be transposed across envelope boundaries and streamed without losing any cryptographic integrity.
\--- middle
Composable Event Streaming Representation (CESR) is a dual text-binary encoding format that has the unique property of text-binary concatenation composability. The CESR specification not only provides the definition of the streaming format but also the attachment codes needed for differentiating the types of cryptographic material (such as signatures) used as attachments on all event types for the Key Event Receipt Infrastructure (KERI) \[KERI\]. While all KERI event messages are self-addressing data (SAD), there is a broad class of SADs that are not KERI events but that require signature attachments. ACDC Verifiable credentials fit into this class of SADs. With more complex data structures represented as SADs, such as verifiable credentials, there is a need to provide signature attachments on nested subsets of SADs. Similar to indices in indexed controller signatures in KERI that specify the location of the public key they represent, nested SAD signatures need a path mechanism to specify the exact location of the nested content that they are signing. CESR Proof Signatures provide this mechanism with the CESR SAD Path Language and new CESR attachment codes, detailed in this specification.
A primary goal of CESR Proof Signatures is to allow any signed self-addressing data (SAD) to be streamed inline with any other CESR content. In support of that goal, CESR Proof Signatures leverage CESR attachments to define a signature scheme that can be attached to any SAD content serialized as JSON \[JSON\], MessagePack \[MGPK\] or CBOR \[CBOR\]. Using this capability, SADs signed with CESR Proof Signatures can be streamed inline in either the text (T) or binary (B) domain alongside any other KERI event message over, for example TCP or UDP. In addition, signed SADs can be transported via HTTP as a CESR HTTP Request (todo: reference needed).
CESR Proof Signatures can be used to sign as many portions of a SAD as needed, including the entire SAD. The signed subsets are either SADs themselves or the self-addressing identifer (SAID) of a SAD that will be provided out of band. A new CESR count code is included with this specification to allow for multiple signatures on nested portions of a SAD to be grouped together under one attachment. By including a SAD Path in the new CESR attachment for grouping signatures, the entire group of signatures can be transposed across envelope boundaries by changing only the root path of the group attachment code.
There are several events in KERI that can contain context specific embedded self-addressing data (SADs). Exchange events (`exn`) for peer-to-peer communication and Replay events (`rpy`) for responding to data requests as well as Expose events (`exp`) for providing anchored data are all examples of KERI events that contain embedded SADs as part of their payload. If the SAD payload for one of these event types is signed with a CESR attachment, the resulting structure is not embeddable in one of the serializations of map or dictionary like data models. (JSON, CBOR, MessagePack) supported by CESR. To solve this problem, CESR Proof Signatures are transposable across envelope boundaries in that a single SAD signature or an entire signature group on any given SAD can be transposed to attach to the end of an enveloping SAD without losing its meaning. This unique feature is provided by the SAD Path language used in either a SAD signature or the root path designation in the outermost attachment code of any SAD signature group. These paths can be updated to point to the embedded location of the signed SAD inside the envelope. Protocols for verifiable credential issuance and proof presentation can be defined using this capability to embed the same verifiable credential SAD at and location in an enveloping `exn` message as appropriate for the protocol without having to define a unique signature scheme for each protocol.
CESR Proof Signatures defines a SAD Path Language to be used in signature attachments for specifying the location of the SAD content within the signed SAD that a signature attachment is verifying. This path language has a more limited scope than alternatives like JSONPtr \[RFC6901\] or JSONPath \[JSONPath\] and is therefore simpler and more compact when encoding in CESR signature attachments. SADs in CESR and therefore CESR Proof Signatures require static field ordering of all maps. The SAD path language takes advantage of this feature to allow for a Base64 compatible syntax into SADs even when a SAD uses non-Base64 compatible characters for field labels.
The SAD path language contains a single reserved character, the `-` (dash) character. Similar to the `/` (forward slack) character in URLs, the `-` in the SAD Path Language is the path separator between components of the path. The `-` was selected because it is a one of the valid Base64 characters.
The simplest path in the SAD Path Language is a single `-` character representing the root path which specifies the top level of the SAD content.
Root Path
```
-
```
After the root path, path components follow, delimited by the `-` character. Path components may be integer indices into field labels or arrays or may be full field labels. No wildcards are supported by the SAD Path Language.
An example SAD Path using only labels that resolve to map contexts follows:
```
-a-personal
```
In addition, integers can be specified and their meaning is dependent on the context of the SAD.
```
-1-12-personal-0
```
The rules for a SAD Path Language processor are simple. If a path consists of only a single `-`, it represents the root of the SAD and therefore the entire SAD content. Following any `-` character is a path component that points to a field if the current context is a map in the SAD or is an index of an element if the current context is an array. It is an error for any sub-path to resolve to a value this is not a map or an array. Any trailing `-` character in a SAD Path can be ignored.
The root context (after the initial `-`) is always a map. Therefore, the first path component represents a field of that map. The SAD is traversed following the path components as field labels or indexes in arrays until the end of the path is reached. The value at the end of the path is then returned as the resolution of the SAD Path. If the current context is a map and the path component is an integer, the path component represents an index into fields of the map. This feature takes advantage of the static field ordering of SADs and is used against any SAD that contains field labels that use non-Base64 compatible characters or the `-` character. Any combination of integer and field label path components can be used when the current context is a map. All path components MUST be an integer when the current context is an array.
SAD Paths are variable raw size primitives that require CESR variable size codes. We will use the `A` small variable size code for SAD Paths which has 3 code entries being added to the Master Code Table, `4A##`, `5A##` and `6A##` for SAD Paths with 0 lead bytes, 1 lead byte and 2 lead bytes respecively. This small variable size code is reserved for text values that only contain valid Base64 characters. These codes are detailed in Table 2 below. The selector not only encodes the table but also implicitly encodes the number of lead bytes. The variable size is measured in quadlets of 4 characters each in the T domain and equivalently in triplets of 3 bytes each in the B domain. Thus computing the number of characters when parsing or off-loading in the T domain means multiplying the variable size by 4. Computing the number of bytes when parsing or off-loading in the B domain means multiplying the variable size by 3. The two Base64 size characters provide value lengths in quadlets/triplets from 0 to 4095 (64\*_2 -1). This corresponds to path lengths of up to 16,380 characters (4095_ 4) or 12,285 bytes (4095 \* 3).
This section provides some more examples for SAD Path expressions. The examples are based on Authentic Chained Data Containers (ACDCs) representing verifiable credentials.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"home-city": "Durham"
}
},
"p": [
{
"qualifiedIssuerCredential": {
"d": "EIl3MORH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZA",
"i": "Et2DOOu4ivLsjpv89vgv6auPntSLx4CvOhGUxMhxPS24"
}
},
{
"certifiedLender": {
"d": "EglG9JLG6UhkLrrv012NPuLEc1F3ne5vPH_sHGP_QPN0",
"i": "E8YrUcVIqrMtDJHMHDde7LHsrBOpvN38PLKe_JCDzVrA"
}
}
]
}
```
Figure 1. Example ACDC Credential SAD
The examples in Table 1 represent all the features of the SAD Path language when referring to the SAD in Figure 1. along with the CESR text encoding.
| SAD Path | Result | CESR T Domain Encoding |
| --- | --- | --- |
| \- | The root of the SAD | 6AABAAA- |
| \-a-personal | The personal map of the a field | 4AADA-a-personal |
| \-4-5 | The personal map of the a field | 4AAB-4-5 |
| \-4-5-legalName | "John Doe" | 5AAEAA-4-5-legalName |
| \-a-personal-1 | "Durham" | 6AAEAAA-a-personal-1 |
| \-p-1 | The second element in the p array | 4AAB-p-1 |
| \-a-LEI | "254900OPPU84GM83MG36" | 5AACAA-a-LEI |
| \-p-0-0-d | "EIl3MORH...6DZA" | 4AAC-p-0-0-d |
| \-p-0-certifiedLender-i | "E8YrUcVI...zVrA" | 5AAGAA-p-0-certifiedLender-i |
The SAD Path language was chosen over alternatives such as JSONPtr and JSONPath in order to create a more compact representation of a pathing language in the text domain. Many of the features of the alternatives are not needed for CESR Proof Signatures. The only token in the language (`-`) is Base64 compatible. The use of field indices in SADs (which require staticly ordered fields) allows for Base64 compatible pathing even when the field labels of the target SAD are not Base64 compatible. The language accomplishes the goal of uniquely locating any path in a SAD using minimally sufficient means in a manner that allows it to be embedded in a CESR attachment as Base64. Alternative syntaxes would need to be Base64 encoded to be used in a CESR attachment in the text domain thus incurring the additional bandwidth cost of such an encoding.
This specification adds 2 _Counter Four Character Codes_ to the Master Code Table and uses 1 _Small Variable Raw Size Code Type_ and 1 _Large Variable Raw Size Code Type_ from the Master Code Table (each of which have 3 code entries).
The SAD Path Signature counter code is represented by the four character code `-J##`. The first two characters reserve this code for attaching the couplet (SAD Path, Signature Group). The second two characters represent the count in hexidecimal of SAD path signatures are in this attachment. The path is attached in the T domain using the codes described in the next section. The signature group is from either a transferable identifier or a non-transferable identifier and therefore attached using the CESR codes `-F##` or `-C##` respectively as described in the CESR Specification \[CESR\].
The code `A` is reserved as a Small Variable Raw Size Code and `AAA` as a Large Variable Raw Size Code for Base64 URL safe strings. SAD Paths are Base64 URL safe strings and so leverage these codes when encoded in the CESR T domain. To account for the variable nature of path strings, the variable size types reserve 3 codes each with prefix indicators of lead byte size used for adjusting the T domain encoding to multiples of 4 characters and the B domain to multiples of 3 bytes. For the _Small_ codes the prefix indicators are `4`, `5` and `6` representing 0, 1 and 2 lead bytes respectively and for _Large_ codes the prefix indicators are `7`, `8`, and `9` representing 0, 1 and 2 lead bytes respectively. The resulting 6 code entries are displayed in the table that follows.
The additions to the Master Code Table of CESR is shown below:
| Code | Description | Code Length | Count or Index Length | Total Length |
| --- | --- | --- | --- | --- |
| | **Counter Four Character Codes** | | | |
| \-J## | Count of attached qualified Base64 SAD path sig groups path+sig group (trans or non-trans) | 2 | 2 | 4 |
| \-K## | Count of attached qualified Base64 SAD Path groups | 2 | 2 | 4 |
| | **Small Variable Raw Size Code** | | | |
| 4A## | String Base64 Only with 0 Lead Bytes | 2 | 2 | 4 |
| 5A## | String Base64 Only with 1 Lead Byte | 2 | 2 | 4 |
| 6A## | String Base64 Only with 2 Lead Bytes | 2 | 2 | 4 |
| | **Large Variable Raw Size Code** | | | |
| 7AAA#### | String Base64 Only with 0 Lead Bytes | 4 | 4 | 8 |
| 8AAA#### | String Base64 Only with 1 Lead Byte | 4 | 4 | 8 |
| 9AAA#### | String Base64 Only with 2 Lead Bytes | 4 | 4 | 8 |
CESR defines several counter codes for attaching signatures to serialized CESR event messages. For KERI event messages, the signatures in the attachments apply to the entire serialized content of the KERI event message. As all KERI event messages are SADs, the same rules for signing a KERI event message applies to signing SADs for CESR Proof Signatures. A brief review of CESR signatures for transferable and non-transferable identifiers follows. In addition, signatures on nested content must be specified.
Signatures on SAD content require signing the serialized encoding format of the data ensuring that the signature applies to the data over the wire. The serialization for any SAD is identified in the version string which can be found in the `v` field of any KERI event message or ACDC credential. An example version string follows:
```
{
"v": "KERI10JSON00011c_"
}
```
where KERI is the identifier of KERI events followed by the hexidecimal major and minor version code and then the serialized encoding format of the event, JSON in this case. KERI and ACDC support JSON, MessagePack and CBOR currently. Field ordering is important when apply cryptographic signatures and all serialized encoding formats must support static field ordering. Serializing a SAD starts with reading the version string from the SAD field (`v` for KERI and ACDC events message) to determine the serialized encoding format of the message. The serialized encoding format is used to generate the SAID at creation and can not be changed. The event map is serialized using a library that ensures the static field order perserved across serialization and deserialization and the private keys are used to generate the qualified cryptographic material that represents the signatures over the SAD content.
The same serialized encoding format must be used when nesting a SAD in another SAD. For example, an ACDC credential that was issued using JSON can only be embedded and presented in a KERI `exn` presentation event message that uses JSON as its serialized encoding format. That same credential can not be transmitted using CBOR or MessagePack. Controllers can rely on this restriction when verifying signatures of embedded SADs. When processing the signature attachments and resolving the data at a given SAD path, the serialization of the outter most SAD can be used at any depth of the traversal. New verison string processing does not need to occur at nested paths. However, if credential signature verification is pipelined and processed in parallel to the event message such that the event message is not avaiable, the version string of the nested SAD will still be valid and can be used if needed.
Each attached signature is accompanied by a SAD Path that indicates the content that is signed. The path must resolve within the enveloping SAD to either a nested SAD (map) or a SAID (string) of an externally provided SAD. This of course, includes a root path that resolves to the enveloping SAD itself.
Non-transferable identifiers only ever have one public key. In addition, the identifier prefix is identical to the qualified cryptographic material of the public key and therefore no KEL is required to validate the signature of a non-transferable identifier \[KERI\]. The attachment code for witness receipt couplets, used for CESR Proof Signatures, takes this into account. The four character couner code `-C##` is used for non-transferable identifiers and contains the signing identfier prefix and the signature \[CESR\]. Since the verification key can be extracted from the identifier prefix and the identifier can not be rotated, all that is required to validate the signature is the identifier prefix, the data signed and the signature.
Transferable identifiers require full KEL resolution and verfication to determine the correct public key used to sign some content \[KERI\]. In addition, the attachment code used for transferable identifiers, `-F##` must specify the location in the KEL at which point the signature was generated \[CESR\]. To accomplish this, this counter code includes the identifier prefix, the sequence number of the event in the KEL, the digest of the event in the KEL and the indexed signatures (transferable identifiers support multiple public/private keys and require index signatures). Using all the values, one can verify the signature(s) by retrieving the KEL of the identifier prefix and determine the key state at the sequence number along with validating the digest of the event against the actual event. Then using the key(s) at the determined key state, validate the signature(s).
This specification adds two Counter Four Character Codes to the CESR Master Code Table for attaching and grouping transposable signatures on SAD and nested SAD content. The first code (`-J##`) is reserved for attaching a SAD path and the associated signatures on the content at the resolution of the SAD Path (either a SAD or its associated SAID). The second reserved code (`-K##`) is for grouping all SAD Path signature groups under a root path for a given SAD. The root path in the second grouping code provides signature attachment transposability for embedding SAD content in other messages.
The SAD Path Signature Group provides a four character counter code, `-J##`, for attaching an encoded variable length SAD Path along with either a transferable index signature group or non-transferable identifer receipt couplets. The SAD Path identifies the content that this attachment is signing. The path must resolve to either a nested SAD (map) or a SAID (string) of an externally provided SAD within the context of the SAD and root path against which this attachment is applied. Using the following ACDC SAD embedded in a KERI `exn` message:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00",
"r": "/credential/offer",
"a": {
"credential": { // SIGNATURE TARGET OF TRANSPOSED SAD PATH GROUP
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"home": "Durham"
}
}
}
}
}
```
the following signature applies to the nested `credential` SAD signed by a transferable identifier using the transferable index signature group. The example is annotated with spaces and line feeds for clarity and an accompanied table is provided with comments.
```
-JAB
6AAEAAA-a-credential
-FAB
E_T2_p83_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y
-EAB0AAAAAAAAAAAAAAAAAAAAAAB
EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM
-AAD
AA5267UlFg1jHee4Dauht77SzGl8WUC_0oimYG5If3SdIOSzWM8Qs9SFajAilQcozXJVnbkY5stG_K4NbKdNB4AQ
ABBgeqntZW3Gu4HL0h3odYz6LaZ_SMfmITL-Btoq_7OZFe3L16jmOe49Ur108wH7mnBaq2E_0U0N0c5vgrJtDpAQ
ACTD7NDX93ZGTkZBBuSeSGsAQ7u0hngpNTZTK_Um7rUZGnLRNJvo5oOnnC1J2iBQHuxoq8PyjdT3BHS2LiPrs2Cg
```
| code | description |
| --- | --- |
| \-JAB | SAD path signature group counter code 1 following the group |
| 6AAEAAA-a-credential | encoded SAD path designation |
| \-FAB | Trans Indexed Sig Groups counter code 1 following group |
| E\_T2\_p83\_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y | trans prefix of signer for sigs |
| \-EAB0AAAAAAAAAAAAAAAAAAAAAAB | sequence number of est event of signer's public keys for sigs |
| EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM | digest of est event of signer's public keys for sigs |
| \-AAD | Controller Indexed Sigs counter code 3 following sigs |
| AA5267...4AQ | sig 0 |
| ABBgeq...pAQ | sig 1 |
| ACTD7N...2Cg | sig 2 |
The next example demostrates the use of a non-transferable identifier to sign SAD content. In this example, the entire nested SAD located at the `a` field is signed by the non-transferable identfier:
```
-JAB
5AABAA-a
-CAB
BmMfUwIOywRkyc5GyQXfgDA4UOAMvjvnXcaK9G939ArM
0BT7b5PzUBmts-lblgOBzdThIQjKCbq8gMinhymgr4_dD0JyfN6CjZhsOqqUYFmRhABQ-vPywggLATxBDnqQ3aBg
```
| code | description |
| --- | --- |
| \-JAB | SAD path signature group counter code 1 following the group |
| 5AABAA-a | encoded SAD path designation |
| \-CAB | NonTrans witness receipt couplet |
| BmMfUwIOywRkyc5GyQXfgDA4UOAMvjvnXcaK9G939ArM | non-trans prefix of signer of sig |
| 0BT7b5... aBg | sig |
The SAD Path Group provides a four character counter code, `-K##`, for attaching encoded variable length **root** SAD Path along with 1 or more SAD Path Signature Groups. The root SAD Path identifies the root context against which the paths in all included SAD Path Signature Groups are resolved. When parsing a SAD Path Group, if the root path is the single `-` character, all SAD paths are treated as absolute paths. Otherwise, the root path is prepended to the SAD paths in each of the SAD Path Signature Groups. Given the following snippet of a SAD Path Group:
```
-KAB6AABAAA--JAB5AABAA-a...
```
The root path is the single `-` character meaning that all subsequent SAD Paths are absolute and therefore the first path is resolved as the `a` field of the root map of the SAD as seen in the following example:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"city": "Durham"
}
}
}
```
To support nesting of signed SAD content in other SAD content the root path of SAD Path Groups or the path of a SAD Path Signature Group provides transposability of CESR SAD signatures such that a single SAD Path Signature Group or an entire SAD Path Group attachment can be transposed across envelope boundaries by updating the single path or root path to indicate the new location. Extending the example above, the SAD content is now embedded in a KERI `exn` event message as follows:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00"
"r": "/credential/offer"
"a": {
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF TRANSPOSED SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"legalName": "John Doe",
"city": "Durham"
}
}
}
}
```
The same signature gets transposed to the outer `exn` SAD by updating the root path of the `-K##` attachment:
```
-KAB5AABAA-a-JAB5AABAA-a...
```
Now the SAD Path of the first signed SAD content resolves to the `a` field of the `a` field of the streamed `exn` message
The small variable raw side code reserved for SAD Path encoding is `A` which results in the addition of 3 entries (`4A##`, `5A##` and `6A##`) in the Master Code Table for each lead byte configuration. These codes and their use are discussed in detail in CESR Encoding for SAD Path Language.
Additional signatures on nested content can be included in a SAD Path Group and are applied to the serialized data at the resolution of a SAD path in a SAD. Signatures can be applied to the SAID or an entire nested SAD. When verifying a CESR Proof Signature, the content at the resolution of the SAD path is the data that was signed. The choice to sign a SAID or the full SAD effects how the data may be used in presentations and the rules for verifying the signature.
When signing nested SAD content, the serialization used at the time of signing is the only serialization that can be used when presenting the signed data. When transposing the signatures and nesting the signed data, the enveloping SAD must use the same serialization that was used to create the signatures. This is to ensure that all signatures apply to the data over the wire and not a transformation of that data. The serialization can be determined from the version field (`v`) of the nested SAD or any parent of the nested SAD as they are guaranteed to be identical. Consider the following ACDC Credential SAD:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // SIGNATURE TARGET OF SAD PATH GROUP
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"personal": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"first": "John",
"last": "Doe"
}
}
}
```
To sign the SAD located at the path `-a`, JSON serialization would be used because the SAD at that path does not have a version field so the version field of its parent is used. The serialization rules (spacing, field ordering, etc) for a SAD would be used for the SAD and the serialization encoding format and the signature would be applied to the bytes of the JSON for that map. Any presentation of the signed data must always include the fully nested SAD. The only valid nesting of this credential would be as follows:
```
{
"v": "KERI10JSON00011c_",
"t": "exn",
"dt": "2020-08-22T17:50:12.988921+00:00"
"r": "/credential/apply"
"a": {
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": { // FULL SAD MUST BE PRESENT
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"first": "John",
"last": "Doe"
}
}
}
}
```
Applying signatures to a SAD with SAIDs in place of fully expanded nested SAD content enables compact credentials for domains with bandwidth restrictions such as IoT. Consider the following fully expanded credential:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": {
"d": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"n": "sKHtYSiCdlibuLDS2PTJg1AZXtPhaySZ9O3DoKrRXWY",
"first": "John
"middle": "William"
"last": "Doe"
},
"address": {
"d": "E-0luqYSg6cPcMFmhiAz8VBQObZLmTQPrgsr7Z1j6CA4",
"n": "XiSoVDNvqV8ldofPyTVqQ-EtVPlkIIQTln9Ai0yI05M",
"street": "123 Main St",
"city": "Salt Lake City",
"state": "Utah",
"zipcode": "84157"
},
"phone": {
"d": "E6lty8H2sA_1acq8zg89_kqF194DbF1cDpwA7UPtwjPQ",
"n": "_XKNVntbcIjp12DmsAGhv-R7JRwuzjD6KCHC7Fw3zvU"
"mobile": "555-121-3434",
"home": "555-121-3435",
"work": "555-121-3436",
"fax": "555-121-3437"
}
}
}
}
```
The three nested blocks of the `a` block `legalName`, `address` and `phone` are SADs with a SAID in the `d` field and are candidates for SAID replacement in an issued credential. A compact credential can be created and signed by replacing those three nested blocks with the SAID of each nested SAD. The schema for this verifiable credential would need to specify conditional subschema for the field labels at each nesting location that requires the full schema of the nested SAD or a string for the SAID. The commitment to a SAID in place of a SAD contains nearly the same cryptographic integrity as a commitment to the SAD itself since the SAID is the qualified cryptographic material of a digest of the SAD. The same credential could be converted to a compact credential containing the SAIDs of each nested block and signed as follows:
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": {
"d": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"i": "EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA",
"dt": "2021-06-09T17:35:54.169967+00:00",
"ri": "EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"LEI": "254900OPPU84GM83MG36",
"legalName": "E2X8OLaLnM0XRQEYgM5UV3bZmWg3UUn7CP4SoKkvsl-s",
"address": "E-0luqYSg6cPcMFmhiAz8VBQObZLmTQPrgsr7Z1j6CA4",
"phone": "E6lty8H2sA_1acq8zg89_kqF194DbF1cDpwA7UPtwjPQ"
}
}
```
It is important to note that if this version of the credential is the one issued to the holder and the signature over the entire credential is on the serialized data of this version of the credential it is the only version that can be presented. The full SAD data of the three nested blocks would be delivered out of band from the signed credential. The top level schema would describe the blocks with conditional subschema for each section. The credential signature becomes a cryptographic commitment to the contents of the overall credential as well as the content of each of the blocks and will still validate the presented credential with significantly less bandwidth.
With this approach, credential presentation request and exchange protocols can be created that modify the schema with the conditional subschema, removing the conditions that allow for SAIDs in place of the required (or presented) nested blocks. The modified schema can be used in such a protocol to indicate the required sections to be delivered out of bounds or as a commitment to provide the nested blocks after the crendential presentation has occurred.
{::boilerplate bcp14-tagged}
TODO Security
The Internet Assigned Numbers Authority (IANA) is a standards organization that oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Internet Protocol-related symbols and Internet numbers.
This document has no IANA actions.
\--- back
{:numbered="false"}
Dr Sam Smith, Kevin Griffin and the Global Legal Entity Identifier Foundation (GLEIF)
---
title: WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
description: 8203357166114, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/08_annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
md: https://weboftrust.github.io/WOT-terms/08_annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex.md
---
# WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
title: "Issuance and Presentation Exchange Protocol" abbrev: "IPEX" category: info
docname: draft-ssmith-ipex-latest v: 3 area: AREA workgroup: WG Working Group keyword: Internet-Draft venue: group: WG type: Working Group mail: [WG@example.com](mailto:WG@example.com) arch: [https://example.com/WG](https://example.com/WG) github: USER/REPO latest: [https://example.com/LATEST](https://example.com/LATEST)
author:
- fullname: Samuel M. Smith organization: ProSapien LLC email: "[sam@prosapien.com](mailto:sam@prosapien.com)"
- name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](mailto:Philip.Feairheller@gleif.org)
normative:
IPEX-ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF IPEX (Issuance and Presentation EXchange) Prototocol Internet Draft author:
```
-
ins: S. Smith
name: Samuel M. Smith
org: ProSapien LLC
-
name: Phil Feairheller
organization: GLEIF
email: Philip.Feairheller@gleif.org
date: 2022
```
ACDC-ID: target: [https://github.com/trustoverip/tswg-acdc-specification](https://github.com/trustoverip/tswg-acdc-specification) title: IETF ACDC (Authentic Chained Data Containers) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
OOBI-ID: target: [https://github.com/WebOfTrust/ietf-oobi](https://github.com/WebOfTrust/ietf-oobi) title: IETF OOBI (Out-Of-Band-Introduction) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
KERI-ID: target: [https://github.com/WebOfTrust/ietf-keri](https://github.com/WebOfTrust/ietf-keri) title: IETF KERI (Key Event Receipt Infrastructure) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
SAID-ID: target: [https://github.com/WebOfTrust/ietf-said](https://github.com/WebOfTrust/ietf-said) title: IETF SAID (Self-Addressing IDentifier) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
CESR-ID: target: [https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr) title: IETF CESR (Composable Event Streaming Representation) Internet Draft author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2022
PTEL-ID: target: [https://github.com/WebOfTrust/ietf-ptel](https://github.com/WebOfTrust/ietf-ptel) title: IETF PTEL (Public Transaction Event Log) Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
Proof-ID: target: [https://github.com/WebOfTrust/ietf-cesr-proof](https://github.com/WebOfTrust/ietf-cesr-proof) title: IETF CESR-Proof Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
DIDK-ID: target: [https://github.com/WebOfTrust/ietf-did-keri](https://github.com/WebOfTrust/ietf-did-keri) title: IETF DID-KERI Internet Draft author: ins: P. Feairheller name: Phil Feairheller org: GLEIF date: 2022
JSON: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimeters
RFC8259: target: [https://datatracker.ietf.org/doc/html/rfc8259](https://datatracker.ietf.org/doc/html/rfc8259) title: JSON (JavaScript Object Notation)
RFC4627: target: [https://datatracker.ietf.org/doc/rfc4627/](https://datatracker.ietf.org/doc/rfc4627/) title: The application/json Media Type for JavaScript Object Notation (JSON)
CBOR: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
RFC8949: target: [https://datatracker.ietf.org/doc/rfc8949/](https://datatracker.ietf.org/doc/rfc8949/) title: Concise Binary Object Representation (CBOR) author:
```
-
ins: C. Bormann
name: Carsten Bormann
-
ins: P. Hoffman
name: Paul Hoffman
date: 2020-12-04
```
MGPK: target: [https://github.com/msgpack/msgpack/blob/master/spec.md](https://github.com/msgpack/msgpack/blob/master/spec.md) title: Msgpack Mapping Object Codes
JSch: target: [https://json-schema.org](https://json-schema.org) title: JSON Schema
JSch\_202012: target: [https://json-schema.org/draft/2020-12/release-notes.html](https://json-schema.org/draft/2020-12/release-notes.html) title: "JSON Schema 2020-12"
informative:
KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC date: 2021
IDSys: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf) title: Identity System Essentials
RC: target: [https://en.wikipedia.org/wiki/Ricardian\_contract](https://en.wikipedia.org/wiki/Ricardian_contract) title: Ricardian Contract
CLC: target: [https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=2045818](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818) title: "Chain-Link Confidentiality"
\--- abstract
The Issuance and Presentation Exchange (IPEX) Protocol provides a uniform mechanism for the issuance and presentation of ACDCs {{ACDC-ID}} in a securely attributable manner. A single protocol is able to work for both types of exchanges by recognizing that all exchanges (both issuance and presentation) may be modeled as the disclosure of information by a Discloser to a Disclosee. The difference between exchange types is the information disclosed not the mechanism for disclosure. Furthermore, the chaining mechanism of ACDCs and support for both targeted and untargeted ACDCs provide sufficient variability to accommodate the differences in applications or use cases without requiring a difference in the exchange protocol itself. This greatly simplifies the exchange protocol. This simplification has two primary advantages. The first is enhanced security. A well-delimited protocol can be designed and analyzed to minimize and mitigate attack mechanisms. The second is convenience. A standard simple protocol is easier to implement, support, update, understand, and adopt. The tooling is more consistent.
This IPEX {{IPEX-ID}} protocol leverages important features of ACDCs and ancillary protocols such as CESR {{CESR-ID}}, SAIDs {{SAID-ID}}, and CESR-Proofs {{Proof-ID}} as well as Ricardian contracts {{RC}} and graduated disclosure (partial, selective, full) to enable contractually protected disclosure. Contractually protected disclosure includes both chain-link confidential {{CLC}} and contingent disclosure {{ACDC-ID}}.
\--- middle
TODO Introduction
Presentation Exchange : An exchange that provides disclosure of one or more ACDCs between a _Discloser_ and a _Disclosee_.
A presentation exchange is the process by which authenticatable information may be exchanged between two parties, namely, the _Discloser_ and _Disclosee_.
ACDC : Type of data as issuance concretely defined by the ACDC specification {{ACDC-ID}}.
Discloser : An ACDC in a disclosure is _disclosed by_ the _Discloser_.
Disclosee : An ACDC in a disclosure is _disclosed to_ the _Disclosee_.
Issuer : An _ACDC_ is _issued by_ the _Issuer_. The _Issuer_ identifier (AID) appears in the top level of the ACDC.
Issuee : An _ACDC_ is optionally _issued to_ the _Issuee_. When present, the _Issuee_ identifier (AID) appears at the top level of the attribute section or in the attribute list at the top level of the attribute aggregate section of the ACDC.
Each _ACDC_ MUST have an _Issuer_ and MAY have an _Issuee_.
The set of _ACDCs_ so disclosed in a _presentation exchange_ MUST be chained. This set of chained _ACDCs_ define a directed acyclic graph (DAG) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
Each _ACDC_ itself defines a graph fragment consisting of one vertex and zero or more directed edges. Each directed edge contained in an _ACDC_ points to a vertex contained in another _ACDC_. The ACDC that contains the origin vertex of the DAG is called the _origin_ or _primary_ ACDC of the _presentation exchange_.
The disclosure performed by a presentation exchange MAY be _graduated_ and MAY be _contractually protected_.
Issuance Exchange : A special case of a _presentation exchange_ where the _Discloser_ is the _Issuer_ of the _origin_ (Primary) _ACDC_ of the DAG formed by the set of chained ACDCs so disclosed.
In an _issuance exchange_, when the _origin_ ACDC has an _Issuee_, the _Disclosee_ MAY also be the _origin_ ACDC's _Issuee_.
Disclosures via Presentations Exchanges may be contractually protected by Chain-Link Confidentiality (i.e a Chain-Link Confidential disclosure). The chaining in this case is different from the chaining described above between Issuances in a DAG of chained Issuances. Chain-link confidentiality, in contrast, chains together a sequence of Disclosees. Each Disclosee in the sequence in turn is the Discloser to the next Disclosee. The terms-of-use of the original disclosure as applied to the original Disclosee MUST be applied by each subsequent Discloser to each subsequent Disclosee via each of the subsequent disclosures (presentation exchanges). These terms-of-use typically constrain disclosure to only approved parties, i.e. imbue the chain of disclosures with some degree of confidentiality. These terms-of-use are meant to contractually protect the data rights of the original Issuer or Issuee of the data being disclosed.
| Discloser | Disclosee | Initiate | Contents | Description |
| --- | --- | --- | --- | --- |
| | `apply` | Y | schema or its SAID, attribute field label list, signature on `apply` or its SAID | schema SAID is type of ACDC, optional label list for selective disclosure, CESR-Proof signature |
| `spurn` | | N | | rejects `apply` |
| `offer` | | Y | metadata ACDC or its SAID, signature on `offer` or its SAID | includes schema or its SAID, other partial disclosures, selective disclosure label list, CESR-Proof signature |
| | `spurn` | N | | rejects `offer` |
| | `agree` | N | signature on `offer` or its SAID | CESR-Proof signature |
| `spurn` | | N | | rejects `agree` |
| `grant` | | Y | full or selective disclosure ACDC, signature on `grant` or its SAID | includes attribute values, CESR-Proof signature |
| | `admit` | N | signature on `grant` or its SAID | CESR-Proof signature |
All the variants of an ACDC are various degrees of expansion of the compact variant. Therefore, an Issuer commitment via a signature to any variant of ACDC (compact, full, etc) makes a cryptographic commitment to the top-level section fields shared by all variants of that ACDC because the value of a top level section field is either the SAD or the SAID of the SAD of the associated section. Both a SAD and its SAID, when signed, each provide a verifiable commitment to the SAD. In the former the signature verification is directly agains the SAD itself. In the latter, the SAID as digest must first be verified against its SAD and then the signature on the SAID may be verified. This indirect verifiablity assumes that the cryptographic strength of the SAID digest is equivalent to the cryptographic strength of the signature used to sign it. To clarify, because all variants share the same top level structure as the compact variant, then a signature on any variant may be used to verify the Issuer's committment to any other variant either directly or indirectly, in whole or in part on a top-level section by top-level section basis. This cross-variant Issuer commitment verifiability is an essential property that supports graduated disclosure by the Disclosee of any or all variants wether it be full, compact, metadata, partial, selective, bulk issued, or contractually protected.
To elaborate, the SAID of a given variant is useful even when it is not the SAID of the variant the Issuer signed because during graduated disclosure the Discloser MAY choose to sign that given variant to fullfill a given step in an IPEX graduated disclosure transaction. The Discloser thereby can make a verifiable disclosure in a given step of the SAD of a given variant that fulfills a commitment made in a prior step via its signature on merely the SAID of the SAD of the variant so disclosed.
For example, the Metadata variant of an ACDC will have a different SAID than the Compact variant because some of the top-level field values may be empty in the Metadata variant. One can think of the The metadata variant as a partial manifest that only includes those top level sections that the Discloser is committing to disclose in order to induce the Disclosee to agree to the contractual terms of use when disclosed. The IPEX transaction is between the Discloser and Disclosee, who both may make non-repudiable commitments via signing to each other. Typically this means that the Discloser will eventually need to fulfull its commitment with a proof of disclosure to the Disclosee. This proof may be satisfied with either directly against the Discloser's signature on the the actual disclosed SAD or indirectly agaisnt the Discloser's signature on the SAID of the actual disclosed SAD. In addition, the Disclosee will typically require a proof of issuance via a non-repudiable signature by the Issuer on a variant of the disclosed SAD that is verifiable (directly or indirectly) against the variant that is the disclosed SAD.
To summarize, when the Issuer commits to the composed schema of an ACDC it is committing to all the variants so composed. As described above, the top level field values in the compact variant enable verification against a disclosure of any of the other Issuer committed variants because they all share the same top level structure. This applies even to the metadata variant in spite of it only providing values for some top level sections and not others. The verifiablity of a top level section is separable.
Consequently, the IPEX protocol must specify how a validator does validation of any variant in a graduated disclosure. To restate there are two proofs that a Discloser must provide. The first is proof of issuance and the second is proof of disclosure. In the former, the Discloser provide the variant via its SAD that was actually signed (as SAD or SAID of SAD) by the Issuer in order for the Disclosee to verify authentic issuance via the signature on that variant. In the latter, the Discloser must disclose any other Issuer enabled (via schema composition) variants that the Discloser offered to disclose as part of the graduated disclosure process.
The goal is to define a validation process (set of rules) that works for all variants of an ACDC and for all types of graduated disclosure of that ACDC.
For example, in the bulk issuance of an ACDC, the Issuer only signs the blinded SAID of the SAD that is the Compact variant of the ACDC not the SAD itself. This enable a Discloser to make a proof of inclusion of the ACDC in a bulk issuance set by unblinding the signature on the blinded SAID without leaking correlation to anything but the blinded SAID itself. To clarify, the Disclosee can verify the signature on the SAID without to prove set inclusion with needing the disclosure of any other information about the ACDC. Issuer signing of the SAID not the SAD also has the side benefit of minimizing the computation of large numbers of bulk issued signatures.
The Issuer MUST provide a signature on the SAID of the most compact variant defined by the schema of the ACDC. When more than one variant is defined by the schema via the oneOf composition operator for any top-level field, the most compact variant MUST appear as the first entry in the oneOf list. When only one variant of each top-level field is defined by the schema, that variant is therefore by defintion the most compact variant.
The different variants of an ACDC form a hash tree (using SAIDs) that is analogous to a Merkle Tree. Signing the top-level SAID of the compact version of the ACDC is equivalent to signing the Merkle Root of a Merkle Tree. Different variants of an ACDC (SADs with SAIDs) correspond to different paths through a Merkle tree. The process of verifying that a SAD via its SAID of a section is included in a schema authorized variant down from the top-level SAID is equivalent to a Merkle Tree proof of inclusion along a path in the Merkel Tree down from its Root. This allows a single signature to provide proof of Issuance of the presentation of any schema authorized variants of the ACDC.
An Issuer MAY provide signatures of the SAIDS of other variants, as well as signatures of the SADs of other variants.
Proof of issuance is provided by disclosing the SAID of the most compact variant and the signature by the Issuer on that SAID.
Proof of disclosure is provided by disclosing the SAD of the most compact variant and then recursively disclosing the nested SADs of each of the top level sections of the most compact variant as needed for the promised disclosure.
Thus for any disclosed variant of an ACDC, the Disclosee need only verify only one proof of issuance as defined above and may need to verify a different proof of disclosure for each disclosed variant as defined above.
The following schema supports a compact variant
```
{
"$id": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Public ACDC",
"description": "Example JSON Schema Public ACDC.",
"credentialType": "PublicACDCExample",
"type": "object",
"required":
[
"v",
"d",
"i",
"ri",
"s",
"a",
"e",
"r"
],
"properties":
{
"v":
{
"description": "ACDC version string",
"type": "string"
},
"d":
{
"description": "ACDC SAID",
"type": "string"
},
"i":
{
"description": "Issuer AID",
"type": "string"
},
"ri":
{
"description": "credential status registry AID",
"type": "string"
},
"s":
{
"description": "schema section",
"oneOf":
[
{
"description": "schema section SAID",
"type": "string"
},
{
"description": "schema detail",
"type": "object"
},
]
},
"a":
{
"description": "attribute section",
"oneOf":
[
{
"description": "attribute section SAID",
"type": "string"
},
{
"description": "attribute detail",
"type": "object",
"required":
[
"d",
"i",
"score",
"name"
],
"properties":
{
"d":
{
"description": "attribute section SAID",
"type": "string"
},
"i":
{
"description": "Issuee AID",
"type": "string"
},
"score":
{
"description": "test score",
"type": "integer"
},
"name":
{
"description": "test taker full name",
"type": "string"
}
},
"additionalProperties": false,
}
]
},
"e":
{
"description": "edge section",
"oneOf":
[
{
"description": "edge section SAID",
"type": "string"
},
{
"description": "edge detail",
"type": "object",
"required":
[
"d",
"boss"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"boss":
{
"description": "boss edge",
"type": "object",
"required":
[
"d",
"n",
's',
"w"
],
"properties":
{
"d":
{
"description": "edge SAID",
"type": "string"
},
"n":
{
"description": "far node SAID",
"type": "string"
},
"s":
{
"description": "far node schema SAID",
"type": "string",
"const": ""EiheqcywJcnjtJtQIYPvAu6DZAIl3MORH3dCdoFOLe71"
},
"w":
{
"description": "edge weight",
"type": "string"
},
"additionalProperties": false
},
},
"additionalProperties": false
}
]
},
"r":
{
"description": "rule section",
"oneOf":
[
{
"description": "rule section SAID",
"type": "string"
},
{
"description": "rule detail",
"type": "object",
"required":
[
"d",
"warrantyDisclaimer",
"liabilityDisclaimer"
],
"properties":
{
"d":
{
"description": "edge section SAID",
"type": "string"
},
"warrantyDisclaimer":
{
"description": "warranty disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
},
"liabilityDisclaimer":
{
"description": "liability disclaimer clause",
"type": "object",
"required":
[
"d",
"l"
],
"properties":
{
"d":
{
"description": "clause SAID",
"type": "string"
},
"l":
{
"description": "legal language",
"type": "string"
}
},
"additionalProperties": false
}
},
"additionalProperties": false
}
]
}
},
"additionalProperties": false
}
```
The following JSON field map serialization satisfies the rules for most compact variant of the schema above.
```
{
"v": "ACDC10JSON00011c_",
"d": "EBdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
"i": "did:keri:EmkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
"ri": "did:keri:EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt",
"s": "E46jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
"a": "EgveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
"e": "ERH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"r": "Ee71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}
```
The Issuer signs the SAID, `d` field value of the field map above.
{::boilerplate bcp14-tagged}
TODO Security
This document has no IANA actions.
\--- back
{:numbered="false"}
TODO acknowledge.
---
title: WebOfTrust-keria-main-docs-protocol
description: signify-keria-request-authentication-protocol--skrap-, level 1
source_url:
html: https://weboftrust.github.io/WOT-terms/08_annotated-copies/WebOfTrust-keria-main-docs-protocol
md: https://weboftrust.github.io/WOT-terms/08_annotated-copies/WebOfTrust-keria-main-docs-protocol.md
---
# WebOfTrust-keria-main-docs-protocol
The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces.
1. Boot Interface - Exposes one endpoint for Agent Worker initialization.
2. Admin Interface - The REST API for command and control operations from the Signify Client.
3. KERI Protocol Interface - CESR over HTTP endpoint for KERI protocol interactions with the rest of the world.
This separation allows for the Boot interface to be expose to internal infrastructure only (or disabled all together) while exposing the other two interfaces externally. If a KERIA instance is launched in static worker mode, meaning all agent workers are configured at start up only the Boot interface can be disabled completely.
To initiate a connection between a Signify Client and a KERIA agent, the two sides will exchange KERI AIDs with the Signify Client AID (called the "Client AID") being the delegator for the KERIA agent worker AID (called the "Agent AID"). To establish the connection the following steps are performed:
The Signify Client generates the client AID as a transferable AID with a single signing key and single rotation key and provides the signed inception event out-of-bands to the KERIA service through the Boot interface. The HTTP request must be signed by the client AID using Signify Request Authentication described below. The algorithm for generating the signing and rotation key pairs for Client AID is as follows:
1. Prepend the 128 bit random salt derivation code ('0A') plus the blank qualified base 64 character ('A') to the provided 21 character passcode
2. Stretch the passcode derivation using Argon2 to generate an Ed25519 private key from the provided "tier" and paths of `signify:controller00` and `signify:controller01` for the signing key and rotation key respectively.
3. Use the qualified base64 of the signing public key and the qualified base64 of the Blake3 digest of the rotation public key in the inception event.
The follow is an example of a Client AID generated by the SignifyPy (Python implementation) Signify Client with a passcode of `0123456789abcdefghijk`
```
{
"v": "KERI10JSON00012b_",
"t": "icp",
"d": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose", // Client AID
"s": "0",
"kt": "1",
"k": [
"DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc" // Derived from passcode as salt, kidx = 0
],
"nt": "1",
"n": [
"EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL" // Derived from passcode as salt, kidx = 1, Blake3 Hashed
],
"bt": "0",
"b": [],
"c": [],
"a": []
}
```
The KERIA service will create an Agent Worker on behalf of the new client and create the delegated, transferable Agent AID with a single signing key and single rotation key specifying the Client AID as its delegator in its inception event.
The KERIA service will return the Agent AID inception event in a signed HTTP response, signed by the Agent AID. Agent AID keys can be generated using a salt or truly random depending on the requirements of the service hosting the KERIA service.
```
{
"v": "KERI10JSON00015f_",
"t": "dip", // Delegated AID
"d": "EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei",
"i": "EEXekkGu9IAzav6pZVJhkLnjtjM5v3AcyA-pdKUcaGei", // Agent AID
"s": "0",
"kt": "1",
"k": [
"DMZh_y-H5C3cSbZZST-fqnsmdNTReZxIh0t2xSTOJQ8a"
],
"nt": "1",
"n": [
"EM9M2EQNCBK0MyAhVYBvR98Q0tefpvHgE-lHLs82XgqC"
],
"bt": "0",
"b": [],
"c": [],
"a": [],
"di": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose" // Delegated signing authority from Client AID
}
```
_Note that all HTTP requests against the Admin Interface must be signed by the Client AID and expect all responses to be signed by the Agent AID._
The Signify Client will approve the delegation of the client AID with an interaction event that it sends back to the KERIA service over the Admin interface.
Once these steps are complete the Signify Client can begin using the rest of the Admin interface to create AIDs, issue credentials, etc.
Document the steps for retrieving state from the Admin interface and updating.
The KERIA service supports the following key generation methods where the Signify Client generates the keys and only ever sends encrypted key material (if any) to the server.
1. Salty Keys - HDK key chain generated from a salt per aid that is encrypted and stored server.
2. Randy Keys - Randomly generated keys (signing and rotation) that are encrypted and store on the server.
3. Sandy Keys - Keys generated from a different salt for inception and each rotation.
4. Group Keys - Signify Client/KERIA Service AIDs participating in a distributed group multisig AID.
5. HSM Keys - Signify Client uses a Signify HSM Integration Module (SHIM) to manage keys and signatures.
For all key generation methods, the Signify Client creates and signs all KERI events, credentials, etc. ensuring that unencrypted private key material never leaves the client. The key generate methods are descrive in more detail in the following sections.
The Salty Key algorithm is used to create a hierarchical deterministic key chain for each AID by generating a unique random salt for each AID and stretching the salt using Argon2 with a `path` that is calculated from the AIDs index relative to all other AIDs and the key index calculated by the total number of signing and rotation keys over the lifetime of the AID.
The salt for each AID is encrypted with the X25519 encryption key generated from the passcode and stored on the server with other AID metadata, including the AID index and current key index.
The Signify Client API must accept the AID salt as an optional parameter to creating Salty Key AIDs allowing users to manage AID salts externally or to share Salts across AIDs if required.
The following Python data class represents the metadata storage for Salty Key AIDs:
```
class SaltyPrm:
"""
Salty prefix's parameters for creating new key pairs
"""
sxlt: str = '' # qualified b64 encoded AID salt
pidx: int = 0 # prefix index for this keypair sequence
kidx: int = 0 # key index for this keypair sequence
stem: str = '' # default unique path stem for salty algo
tier: str = '' # security tier for stretch index salty algo
dcode: str = '' # next digest hasing code
icodes: list = field(default_factory=list) # current signing key seed codes
ncodes: list = field(default_factory=list) # next key seed codes
transferable: bool = False
```
Document the procedure for rotating a new Salt in for a Salty Key AID.
The Randy Key algorithm allows for all signing and rotation private keys to be generated solely from entropy and encrypted with the X25519 encryption key generated from the passcode and stored on the server alongside other AID metadata.
The server stores the encrypted private key material for signing and rotation keys in separate LMBD sub-databases as indexed qualified base 64 CESR encoded Cipher representations.
The Group Key algorithm is a special key generation algorith for distributed group multisig AIDs that does not manage and keys at all. Instead this algoritm allows for the specification of an AID of one of the other three types to be the "local" participant in a distributed group multisig AID.
All signing operations must be performed on the Signify Client on behalf of the "local" AID for this Signify Client indexed based on the local AID's location in both the signing key list and the rotation key list.
The SignifyPy Signify Client defines an experimental interface for declaring external modules that can be used as Signify HSM Integration Modules to allow all key generation and event signing to occur in an external Hardware Security Module (HSM).
Two sample implementations have been defined to date, one using the Google KSM and one using a Trezure One external HSM.
The following psuedo Python class represents the current, experimental interface a SHIM has to implememnt to work with SignifyPy. It is anticipated that each Signify Client implementation defines a similar interface.
```
class Shim:
def incept(self, transferable=True):
""" Create an AID using the Google KSM for key generation and event signing.
Parameters:
transferable (bool): True means create a transferable AID which allows for key rotation
Returns:
keys (list): list of qualified base64 public signing key deriviations based on the codes passed into init
ndigs (list): list of qualified base64 digests of public rotation key derivations based on the codes
passed into init
"""
def rotate(self, ncount, transferable):
""" Rotate an AID using the Google KSM for key generation and event signing.
Parameters:
ncount (int): number of new rotation keys to generate
transferable (bool): True means create a transferable AID which allows for key rotation
Returns:
keys (list): list of qualified base64 public signing key deriviations based on the codes passed into init
ndigs (list): list of qualified base64 digests of public rotation key derivations based on the codes
passed into init
"""
def sign(self, ser, indexed=True, indices=None, ondices=None, **_):
"""
Parameters:
ser (bytes): content to be signed
indexed (bool): True means generated indexed signatures
indices (list): Optional list of indices to use when generating indexed signatures
ondices (list): Optional list of rotation indices to use when generating dual indexed signatures
**_: Placeholder
Returns:
sigs (list): list of qualified base64 signatures over the based in ser
"""
```
To perform a passcode rotation, the Signify Client requires both old and new passcodes and must perform the following steps:
1. Encrypted the old passcode with X25519 key generated from the new passcode.
2. Perform a partial rotation of the Client AID as described below.
3. Decrypt all salts with X25519 key from old passcode for Salty Keys, validate them against current public keys, encrypt with X25519 key from new passcode
4. Decrypt all keys with X25519 key from old passcode for Randy Keys, validate them against current public keys, encrypt with X25519 key from new passcode
5. Send all rotation event and all recrypted material in a POST request to the agent on `/agent/`
To provide post-quantum secure passcode recovery, a passcode recovery must be accompanied by partial rotation of the Client AID. This partial rotation is possible because the user will have to provide both old and new passcodes to initiate the process.
The partial rotation of the Client AID is accomplished by using the old passcode to regenerate the the prior rotation key pair called `R0` from the latest establishment event. In addition, two new key pairs are generated from the new passocde, one used for signing authority (S0) and one used for rotation authority (R1) in the new rotation event.
The public key for `S0` is used as the first signing key in the new rotation event; it is giving a fractionally weighted threshold of "1". The public key for `R0` is used as the second signing key in the new rotation event; it is giving a fractionally weighted threshold of "0". A Blake3 has is created of the public key for `R1` and is used as the next rotation key commitment.
The rotation event is signed with the private keys of both `S0` and `R0`. An example of a partial rotation event of the Client AID from above follows with its signatures:
```
{
"v": "KERI10JSON000195_",
"t": "rot",
"d": "EGTAY6x1tTbOO27LCy3poh5iW0Oa2Cq1s7wsVnj152Zi",
"i": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"s": "1",
"p": "ELI7pg979AdhmvrjDeam2eAO2SR5niCgnjAJXJHtJose",
"kt": [
"1", // Threshold for key derived from NEW passcode, has full signing authority
"0" // Threshold for key derived from OLD passcode, no signing authority
],
"k": [
"DAbWjobbaLqRB94KiAutAHb_qzPpOHm3LURA_ksxetVc", // Derived from NEW passcode as salt, kidx = 0
"DHMAZEksiqGxlNKnm0pSAyMRPK1ZKyBfGV8q_B9r6pLs" // Derived from OLD passcode as salt, kidx = 1 (matches previous rotation key)
],
"nt": "1",
"n": [
"EIFG_uqfr1yN560LoHYHfvPAhxQ5sN6xZZT_E3h7d2tL" // Derived from NEW passcode as salt, kidx = 1, Blake3 Hashed
],
"bt": "0",
"br": [],
"ba": [],
"a": []
}
```
With the following attached signatures:
```
[
"AADuzJ4zU8MkLBPP8Os9UPbTvNqoQ4YDImNkTjfknWgJW25V6EmwZ59PXas0zKhxtp_dOhvkPqtqIhgarOFwt7sC",
"2AABAACRZGDB7s4hmYnt7vTYGWCawhnqHndWUy_rtR_L8mfNmrJ4N5S05wAZ6w5RoL68h1HjIzO7ZuiF30XBz1cC6eUA"
]
```
The first signature satisfies the current signing threshold and has only one index, 0 for signing key index. The second signature satifies the prior rotation threshold and thus uses dual index code to specify a current signing index of 1 and a prior signing index of 0.
The following steps are followed to accept the passcode rotation:
1. Verify and accept the Client AID rotation
2. Verify the signature on the request against the NEW signing key of the Client AID
3. Save encrypted old passcode
4. Update all Salty Key encrypted salts
5. Update all Randy Key encrypted keys
6. Delete encrypted old passcode
When each Agent Worker is loaded it will check for a saved old passcode to detect an aborted passcode rotation. If a saved encrypted old passcode is found the Agent Worker will notify the client in the response to the state call that a passcode rotation recovery is needed and lock out all other operations until it is completed successfully.
To perform a passcode rotation recovery, the Signify Client requires only the new passcode and must perform the following steps:
1. Retrieve the encrypted old passcode and decrypt it with X25519 key generated from the new passcode.
2. Perform a revised partial rotation of the Client AID where you rotate out to a new next key not new signing key.
3. Attempt to decrypt all salts with the X25519 keys from both the old and new passcode for Salty Keys
4. For any salt still encrypted with the old passcode, encrypt with X25519 key from new passcode
5. Attempt to decrypt all keys with the X25519 keys from both the old and new passcode for Randy Keys
6. Validate them against current public keys and for any key still encrypted with the old passcode, encrypt with X25519 key from new passcode
7. Send all rotation event and all recrypted material in a POST request to the agent on `/agent/`
Signify clients must sign all requests to the KERIA Admin Interface using the latest signing key of the Client AID and must expect all responses from the KERIA service be signed by the latest signing key of the Agent AID. Both request and response signing rely on the same set of HTTP headers to accomplish request/response signing.
Document `Signify-Resource` and `Signify-Timestamp` headers here.
Document the `Signature-Input` header here with link to [https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html](https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html)
Document the signing method and `Signature` header.
---
title: KERI DEV Meeting March 28 2024
description: Zoom recording
source_url:
html: https://weboftrust.github.io/WOT-terms/video/keri-dev-meeting-March-28-2024
md: https://weboftrust.github.io/WOT-terms/video/keri-dev-meeting-March-28-2024.md
---
# KERI DEV Meeting March 28 2024
Your browser does not support the video tag.
```
00:19:37 Henk van Cann: https://chat.openai.com/g/g-mTlHjxQCp-keri-wizzard
00:27:42 Henk van Cann: Interested in what people suggest to feed the chatGPT engine for new developers to learn from and be able to question it
00:30:54 nkongsuwan: https://github.com/WebOfTrust/keripy/discussions/726
00:32:03 Philip Feairheller: https://github.com/WebOfTrust/cesr-test-vectors
```