diff --git a/.github/workflows/D-deploy-to-gh-pages.yml b/.github/workflows/D-deploy-to-gh-pages.yml index f9b564e0..269fc89b 100644 --- a/.github/workflows/D-deploy-to-gh-pages.yml +++ b/.github/workflows/D-deploy-to-gh-pages.yml @@ -48,6 +48,42 @@ jobs: + ############################## + # Generate LLM-optimized docs (llmstxt.org standard) + # Uses build directory discovery since keridoc uses autogenerated sidebars + - name: Generate LLM documentation + uses: osodevops/docusaurus-llm-docs@v1 + id: llm-docs + with: + build-dir: './build' + output-dir: './build/llm-docs' + base-url: 'https://weboftrust.github.io/keridoc' + product-name: 'KERIDoc' + tagline: 'KERI Suite Documentation' + inject-sidebar: 'false' + sidebar-path: './sidebars-nonexistent.js' + + - name: Copy LLM docs to build root and repo + run: | + cp ${{ steps.llm-docs.outputs.llms-txt-path }} ./build/llms.txt + cp ${{ steps.llm-docs.outputs.llms-full-txt-path }} ./build/llms-full.txt + cp ${{ steps.llm-docs.outputs.markdown-zip-path }} ./build/markdown.zip + mkdir -p ./llm-docs + cp ${{ steps.llm-docs.outputs.llms-txt-path }} ./llm-docs/llms.txt + cp ${{ steps.llm-docs.outputs.llms-full-txt-path }} ./llm-docs/llms-full.txt + cp ${{ steps.llm-docs.outputs.markdown-zip-path }} ./llm-docs/markdown.zip + + - name: Commit LLM docs to repo + run: | + git config user.name "github-actions[bot]" + git config user.email "41898282+github-actions[bot]@users.noreply.github.com" + git add llm-docs/ + git diff --staged --quiet && echo "No changes to commit" || git commit -m "Update LLM-optimized documentation [automated]" + git push + ############################## + + + ############################## # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus - name: Deploy to GitHub Pages diff --git a/.github/workflows/generate-llm-docs.yml b/.github/workflows/generate-llm-docs.yml new file mode 100644 index 00000000..9b4248d4 --- /dev/null +++ b/.github/workflows/generate-llm-docs.yml @@ -0,0 +1,60 @@ +name: Generate LLM Documentation + +on: + push: + branches: [main] + paths: + - 'docs/**' + - 'docusaurus.config.js' + - 'sidebars.js' + workflow_dispatch: + +permissions: + contents: write + +jobs: + generate-llm-docs: + name: Build site and generate LLM-optimized docs + runs-on: ubuntu-latest + + steps: + - uses: actions/checkout@v4 + + - uses: actions/setup-node@v4 + with: + node-version: '20' + cache: 'npm' + + - name: Install dependencies + run: npm ci + + - name: Build website + run: npm run build + + - name: Generate LLM documentation + uses: osodevops/docusaurus-llm-docs@v1 + id: llm-docs + with: + build-dir: './build' + output-dir: './build/llm-docs' + base-url: 'https://weboftrust.github.io/keridoc' + product-name: 'KERIDoc' + tagline: 'KERI Suite Documentation' + inject-sidebar: 'false' + sidebar-path: './sidebars-nonexistent.js' + + - name: Copy LLM docs to build output + run: | + cp ${{ steps.llm-docs.outputs.llms-txt-path }} ./build/llms.txt + cp ${{ steps.llm-docs.outputs.llms-full-txt-path }} ./build/llms-full.txt + cp ${{ steps.llm-docs.outputs.markdown-zip-path }} ./build/markdown.zip + + - name: Upload LLM docs as artifact + uses: actions/upload-artifact@v4 + with: + name: llm-docs + path: | + ./build/llms.txt + ./build/llms-full.txt + ./build/markdown.zip + retention-days: 30 diff --git a/llm-docs/llms-full.txt b/llm-docs/llms-full.txt new file mode 100644 index 00000000..3dfa81e4 --- /dev/null +++ b/llm-docs/llms-full.txt @@ -0,0 +1,42952 @@ +# KERIDoc Documentation + +KERI Suite Documentation + +> This file contains the complete documentation in a single file for LLM consumption. +> For a lightweight index, see https://weboftrust.github.io/keridoc/llms.txt +> For individual markdown files, download https://weboftrust.github.io/keridoc/markdown.zip + + +--- +title: KERIDoc +description: KERI Suite Documentation +source_url: + html: https://weboftrust.github.io/keridoc/index + md: https://weboftrust.github.io/keridoc/index.md +--- + +# KERIDoc + +## Personal learning environment and consensus building tool + +[ + +### ⚡ KERI Suite Documentation + +doc.kerisse.org + +](https://weboftrust.github.io/keridoc/) + +[ + +### ⚡ KERI Suite Glossary + +glossary.kerisse.org + +](https://weboftrust.github.io/WOT-terms/) + +[ + +### ⚡ KERI Suite Search Engine + +search.kerisse.org + +](https://weboftrust.github.io/kerisse/) + + + + +--- +title: Visualisations +source_url: + html: https://weboftrust.github.io/keridoc/visualisations/index + md: https://weboftrust.github.io/keridoc/visualisations/index.md +--- + +# Visualisations + + + + +--- +title: Markdown page example +description: You don't need React to write simple standalone pages. +source_url: + html: https://weboftrust.github.io/keridoc/markdown-page/index + md: https://weboftrust.github.io/keridoc/markdown-page/index.md +--- + +# Markdown page example + +You don't need React to write simple standalone pages. + + + + +--- +title: Menu +description: How-to pages. +source_url: + html: https://weboftrust.github.io/keridoc/howtos-menu/index + md: https://weboftrust.github.io/keridoc/howtos-menu/index.md +--- + +# Menu + +How-to pages. + + + + +--- +title: Feedback +description: We appreciate your feedback. +source_url: + html: https://weboftrust.github.io/keridoc/feedback/index + md: https://weboftrust.github.io/keridoc/feedback/index.md +--- + +# Feedback + +We appreciate your feedback. + +Give us your feedback on Slack: [keriworld.slack.com](https://keriworld.slack.com), #edu channel, channel ID: C03RB6ASVUM. + + + + +--- +title: Document Information +source_url: + html: https://weboftrust.github.io/keridoc/ToIP-IR/ToIPIssuerRequirements.docx + md: https://weboftrust.github.io/keridoc/ToIP-IR/ToIPIssuerRequirements.docx.md +--- + +# Document Information + + + + +--- +title: Source: modules-js-universal/toLowerCaseAndRemoveSpecialChars.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_toLowerCaseAndRemoveSpecialChars.js + md: https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_toLowerCaseAndRemoveSpecialChars.js.md +--- + +# Source: modules-js-universal/toLowerCaseAndRemoveSpecialChars.js + +``` +/** + * @file This file converts string to lower case and removes special characters + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-12-01 + */ + +/** + * @module toLowerCaseAndRemoveSpecialChars + * @description Description: Converts string to lower case and removes special characters + * @param {*} str + * @returns {string} - The string in lower case without special characters + */ +export function toLowerCaseAndRemoveSpecialChars(str) { + return str.toLowerCase().replace(/[\s-_—]/g, ''); +} +``` + + + + +--- +title: Source: modules-js-universal/positionInArray.mjs +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_positionInArray.mjs + md: https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_positionInArray.mjs.md +--- + +# Source: modules-js-universal/positionInArray.mjs + +``` +/** + * @file This file returns the position of a value in the entriesIndex array. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-11-05 + */ + +/** + * @module positionInArray + * @description Returns the position of a value in the entriesIndex array. + * @param {Array} content - The content to search in. + * @param {string} value - The value to search for in the entriesIndex array. + * @returns {number} - The position of the value in the entriesIndex array, or -1 if not found. + */ +function positionInArray(content, value) { + const entriesIndex = content[0]; + for (let i = 0; i < entriesIndex.length; i++) { + if (entriesIndex[i] === value) return i; + } + return -1; +} + +export default positionInArray; +``` + + + + +--- +title: Source: modules-js-node/unzipFile.mjs +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_unzipFile.mjs + md: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_unzipFile.mjs.md +--- + +# Source: modules-js-node/unzipFile.mjs + +``` +/** + * @file This file unzips a zip file to a specified destination directory. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-11-12 + */ + +import AdmZip from 'adm-zip'; + +/** + * @module unzipFile + * @description Unzips a zip file to a specified destination directory + * @param {*} zipFilePath + * @param {*} extractToDir + */ +function unzipFile(zipFilePath, extractToDir) { + try { + let zip = new AdmZip(zipFilePath); + zip.extractAllTo(extractToDir, true); + console.log(`Extraction complete. Files extracted to ${extractToDir}`); + } catch (error) { + console.error('Error extracting the file:', error); + throw error; + } +} + +export default unzipFile; +``` + + + + +--- +title: Source: modules-js-node/glossaryJsonToMarkdown.mjs +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_glossaryJsonToMarkdown.mjs + md: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_glossaryJsonToMarkdown.mjs.md +--- + +# Source: modules-js-node/glossaryJsonToMarkdown.mjs + +``` +// TODO: This is not a module, so it should be moved to somewhere else. (A module should have an export statement in our definition.) + +/** + * @file This file converts JSON files to markdown files. + * It is used to convert the glossary JSON files to markdown files. + * The JSON files are located in the static/json/external-glosseries/glossaries directory. + * The markdown files are saved in the static/json/external-glosseries/glossaries-to-markdown-from-json directory. + * Run this script from the root of the project: + * $ node modules-js-node/glossaryJsonToMarkdown.mjs + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2024-02-09 + */ + +import fs from 'fs'; +import path from 'path'; + +// Function to ensure the target directory is emptied +const emptyTargetDirectory = (targetDir) => { + if (fs.existsSync(targetDir)) { + fs.readdirSync(targetDir).forEach(file => { + const filePath = path.join(targetDir, file); + fs.unlinkSync(filePath); + }); + } else { + fs.mkdirSync(targetDir, { recursive: true }); + } +}; + +// Resolve the parent directory +const currentDir = path.dirname(new URL(import.meta.url).pathname); +const sourceDir = path.join(currentDir, '../static/json/external-glosseries/glossaries'); +const targetParentDir = path.join(currentDir, '../static/json/external-glosseries/glossaries-to-markdown-from-json'); + +// Get a list of JSON files in the source directory +const jsonFiles = fs.readdirSync(sourceDir) + .filter(filename => filename.endsWith('.json')); + +// Process each JSON file +jsonFiles.forEach(filename => { + try { + // Load the JSON file + fs.promises.readFile(path.join(sourceDir, filename), 'utf-8') + .then(jsonData => { + const parsedData = JSON.parse(jsonData); + + // Determine the output directory + const outputDirName = path.parse(filename).name; + const outputDir = path.join(targetParentDir, outputDirName); + + // Ensure the output directory exists and is empty + emptyTargetDirectory(outputDir); + + // Process each object in the JSON array + parsedData.forEach((item, index) => { + // Create markdown content + const markdownContent = `## ${item.term}\n\n${item.definition}\n\n`; + + // Write markdown content to file + const markdownFilename = `${item.term.replace(/[^a-zA-Z0-9]/g, '_').toLowerCase()}.md`; + const markdownFilePath = path.join(outputDir, markdownFilename); + + fs.writeFileSync(markdownFilePath, markdownContent, 'utf-8'); + + console.log(`Markdown file generated: ${markdownFilename} in ${outputDir}`); + }); + + console.log(`All markdown files have been generated for ${filename}`); + }) + .catch(error => { + console.error(`Error loading or processing file "${filename}":`, error); + }); + } catch (error) { + console.error(`Error processing file "${filename}":`, error); + } +}); +``` + + + + +--- +title: Source: modules-js-node/downloadFile.mjs +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_downloadFile.mjs + md: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_downloadFile.mjs.md +--- + +# Source: modules-js-node/downloadFile.mjs + +``` +/** + * @file This file downloads a file from a given URL and save it to a specified path on the local file system. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-11-12 + */ + +import axios from 'axios'; +import fs from 'fs'; + +/** + * @module downloadFile + * @description This module downloads a file from a given URL and saves it to a specified path on the local file system. + * @param {string} downloadUrl - The URL of the file to download. + * @param {string} fullPath - The full path of the file to write to. + * @returns {Promise} A Promise that resolves when the file is downloaded and written successfully. + * @throws {Error} An error if the file cannot be downloaded. + */ +async function downloadFile(downloadUrl, fullPath) { + try { + const response = await axios({ + method: 'GET', + url: downloadUrl, + responseType: 'stream', + }); + + const writer = fs.createWriteStream(fullPath); + + response.data.pipe(writer); + + return new Promise((resolve, reject) => { + writer.on('finish', resolve); + writer.on('error', reject); + }); + } catch (error) { + console.error('Error downloading the file:', error); + throw error; + } +} + +export default downloadFile; +``` + + + + +--- +title: Source: modules-js-node/createSpecUpJsonFile.mjs +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_createSpecUpJsonFile.mjs + md: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_createSpecUpJsonFile.mjs.md +--- + +# Source: modules-js-node/createSpecUpJsonFile.mjs + +``` +// TODO: This is not a module, so it should be moved to somewhere else. (A module should have an export statement in our definition.) + +/** + * @file This file creates JSON files that serve as the source for the Spec-Up document generator. It takes markdown files as input. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2024-02-12 + */ + +import fs from 'fs'; +import path from 'path'; + +// Function to remove all files and subdirectories in a directory +const emptyDirectory = (dirPath) => { + if (fs.existsSync(dirPath)) { + fs.readdirSync(dirPath).forEach(item => { + const itemPath = path.join(dirPath, item); + if (fs.lstatSync(itemPath).isDirectory()) { + emptyDirectory(itemPath); // Recursively empty subdirectories + fs.rmdirSync(itemPath); // Remove the subdirectory + } else { + fs.unlinkSync(itemPath); // Remove the file + } + }); + } +}; + +// Function to ensure the target directory exists and is emptied +const ensureTargetDirectory = (targetDir) => { + if (!fs.existsSync(targetDir)) { + fs.mkdirSync(targetDir, { recursive: true }); // Create the target directory if it does not exist + } else { + emptyDirectory(targetDir); // Empty the target directory if it exists + } +}; + +const currentDir = path.dirname(new URL(import.meta.url).pathname); +const sourceDir = path.join(currentDir, '../static/json/external-glosseries/glossaries-to-markdown-from-json'); +// Resolve the parent directory +const targetParentDir = path.join(currentDir, '../static/json/external-glosseries/specUpJsonFiles'); + +const prependToJson = `{ + "specs": [ + { + "title": "ToIP Template Specification", + "spec_directory": "./spec", + "output_path": "./docs", + "markdown_paths": `; + +const appendToJson = `, + "logo": "https://raw.githubusercontent.com/trustoverip/logo-assets/master/logos/ToIP-Logo-Color-SolidDimensional-Horizontal-LightOnDark.svg", + "logo_link": "https://github.com/trustoverip/specification-template", + "katex": true, + "source": { + "host": "github", + "account": "trustoverip", + "repo": "specification-template" + } + } + ] +}`; + +// Ensure the target parent directory exists and is emptied +ensureTargetDirectory(targetParentDir); + +// Get a list of directories in the source directory +const directories = fs.readdirSync(sourceDir) + .filter(filename => fs.lstatSync(path.join(sourceDir, filename)).isDirectory()); + +console.log('directories: ', directories); + +// for every directory in directories create an array with the file names of the markdown files, withouth the .md extension +// and then create a json file in the target directory. The json file will have the same name as the directory and will contain the array of file names +directories.forEach(directory => { + const files = fs.readdirSync(path.join(sourceDir, directory)) + .filter(filename => filename.endsWith('.md')) + .map(filename => path.parse(filename).name + ".md"); + // console.log('files: ', files); + + // // if path.join(targetParentDir, `${directory}`) does not exist, create it + // if (!fs.existsSync(path.join(targetParentDir, `${directory}`))) { + // fs.mkdirSync(path.join(targetParentDir, `${directory}`), { recursive: true }); + // } else { + // // if it exists, empty it + // emptyTargetDirectory(path.join(targetParentDir, `${directory}`)); + // } + + fs.writeFileSync(path.join(targetParentDir, `${directory}.json`), prependToJson + JSON.stringify(files, null, 2) + appendToJson); + // fs.writeFileSync(`${directory}.json`, JSON.stringify(files, null, 2)); + +}); +``` + + + + +--- +title: Source: modules-js-node/cleanJson.mjs +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_cleanJson.mjs + md: https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_cleanJson.mjs.md +--- + +# Source: modules-js-node/cleanJson.mjs + +``` +/** + * @file This file cleans a JSON file by removing non-printable characters from string values. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-12-07 + */ + +import fs from 'fs/promises'; + +/** + * @module cleanJsonFile + * @description Cleans a JSON file by removing non-printable characters from string values. + * @async + * @param {string} inputFilePath - The path to the input JSON file. + * @param {string} outputFilePath - The path to write the cleaned JSON data. + * @returns {Promise} A Promise that resolves when the JSON file is cleaned and written successfully. + */ +async function cleanJsonFile(inputFilePath, outputFilePath) { + try { + // Read the JSON file + const rawData = await fs.readFile(inputFilePath, 'utf8'); + + // Parse the JSON data + let jsonData = JSON.parse(rawData); + + // Function to recursively clean strings in the JSON object + function cleanStrings(obj) { + for (const key in obj) { + if (typeof obj[key] === 'string') { + // Replace non-printable characters with an empty string + obj[key] = obj[key].replace(/[^\x20-\x7E]/g, ''); + } else if (typeof obj[key] === 'object') { + cleanStrings(obj[key]); + } + } + } + + // Clean the JSON data + cleanStrings(jsonData); + + // Convert the cleaned JSON data back to a string + const cleanedData = JSON.stringify(jsonData, null, 2); + + // Write the cleaned JSON data to a new file + await fs.writeFile(outputFilePath, cleanedData, 'utf8'); + + console.log(`Cleaned JSON written to ${outputFilePath}`); + } catch (error) { + console.error('Error processing JSON file:', error); + } +} + +export default cleanJsonFile; +``` + + + + +--- +title: Module: unzipFile +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/module-unzipFile + md: https://weboftrust.github.io/keridoc/JSDoc/module-unzipFile.md +--- + +# Module: unzipFile + +Unzips a zip file to a specified destination directory + +##### Parameters: + +| Name | Type | Description | +| --- | --- | --- | + +| `zipFilePath` | \* | | +| `extractToDir` | \* | | + +Source: + +- [modules-js-node/unzipFile.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_unzipFile.md), [line 10](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_unzipFile.md#line10) + + + + +--- +title: Module: toLowerCaseAndRemoveSpecialChars +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/module-toLowerCaseAndRemoveSpecialChars + md: https://weboftrust.github.io/keridoc/JSDoc/module-toLowerCaseAndRemoveSpecialChars.md +--- + +# Module: toLowerCaseAndRemoveSpecialChars + +Description: Converts string to lower case and removes special characters + +##### Parameters: + +| Name | Type | Description | +| --- | --- | --- | + +| `str` | \* | | + +Source: + +- [modules-js-universal/toLowerCaseAndRemoveSpecialChars.js](https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_toLowerCaseAndRemoveSpecialChars.md), [line 8](https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_toLowerCaseAndRemoveSpecialChars.md#line8) + +##### Returns: + +\- The string in lower case without special characters + +Type + +string + + + + +--- +title: Module: positionInArray +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/module-positionInArray + md: https://weboftrust.github.io/keridoc/JSDoc/module-positionInArray.md +--- + +# Module: positionInArray + +Returns the position of a value in the entriesIndex array. + +##### Parameters: + +| Name | Type | Description | +| --- | --- | --- | + +| `content` | Array. | The content to search in. | +| `value` | string | The value to search for in the entriesIndex array. | + +Source: + +- [modules-js-universal/positionInArray.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_positionInArray.md), [line 8](https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_positionInArray.md#line8) + +##### Returns: + +\- The position of the value in the entriesIndex array, or -1 if not found. + +Type + +number + + + + +--- +title: Module: downloadFile +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/module-downloadFile + md: https://weboftrust.github.io/keridoc/JSDoc/module-downloadFile.md +--- + +# Module: downloadFile + +This module downloads a file from a given URL and saves it to a specified path on the local file system. + +##### Parameters: + +| Name | Type | Description | +| --- | --- | --- | + +| `downloadUrl` | string | The URL of the file to download. | +| `fullPath` | string | The full path of the file to write to. | + +Source: + +- [modules-js-node/downloadFile.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_downloadFile.md), [line 11](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_downloadFile.md#line11) + +##### Throws: + +An error if the file cannot be downloaded. + +Type + +Error + +##### Returns: + +A Promise that resolves when the file is downloaded and written successfully. + +Type + +Promise. + + + + +--- +title: Module: cleanJsonFile +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/module-cleanJsonFile + md: https://weboftrust.github.io/keridoc/JSDoc/module-cleanJsonFile.md +--- + +# Module: cleanJsonFile + +Cleans a JSON file by removing non-printable characters from string values. + +##### Parameters: + +| Name | Type | Description | +| --- | --- | --- | + +| `inputFilePath` | string | The path to the input JSON file. | +| `outputFilePath` | string | The path to write the cleaned JSON data. | + +Source: + +- [modules-js-node/cleanJson.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_cleanJson.md), [line 10](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_cleanJson.md#line10) + +##### Returns: + +A Promise that resolves when the JSON file is cleaned and written successfully. + +Type + +Promise. + + + + +--- +title: Source: maintenance/fix_INDEX_OVERVIEW_FILE.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/maintenance_fix_INDEX_OVERVIEW_FILE.js + md: https://weboftrust.github.io/keridoc/JSDoc/maintenance_fix_INDEX_OVERVIEW_FILE.js.md +--- + +# Source: maintenance/fix_INDEX_OVERVIEW_FILE.js + +``` +/** + * @file This file cleans the content of the index_overview file. + * Environment: NodeJS + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-12-04 + */ + +require('dotenv').config(); +const fs = require('fs'); + +// load INDEX_OVERVIEW_FILE from .env +const indexOverviewFile = process.env.INDEX_OVERVIEW_FILE; +const indexOverviewFileContent = fs.readFileSync(indexOverviewFile, 'utf8'); + +// Clean up the file content + +// Via regex replace %E2%80%90 with - +const regex = /%E2%80%90/gm; +const fixedIndexOverviewFileContent = indexOverviewFileContent.replace(regex, '-'); + +// Write the fixed content back to the file +fs.writeFileSync(indexOverviewFile, fixedIndexOverviewFileContent, 'utf8'); +``` + + + + +--- +title: Source: maintenance/fixOmnigraffleSvgOutput.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/maintenance_fixOmnigraffleSvgOutput.js + md: https://weboftrust.github.io/keridoc/JSDoc/maintenance_fixOmnigraffleSvgOutput.js.md +--- + +# Source: maintenance/fixOmnigraffleSvgOutput.js + +``` +/** + * @file This file fixes Omnigraffle svg output. Without these fixes the Docusaurus page does not render. + * Environment: NodeJS + * Usage: + * $ node maintenance/fixOmnigraffleSvgOutput.js + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-07-16 + */ + +/* + Description: + The script will scan the '/static/img' directory for SVG files, and for each file it: + + -defines replacements to rectify common OmniGraffle SVG output issues, including the removal of SVG DOCTYPE declaration and XML version tag, and correction of the 'xl:' namespace and 'xl:href' attributes to 'xmlns:xlink' and 'xlink:href' respectively. + + -reads all files in the specified directory (../static/img), and for each '.svg' file, it performs the following: + + -applies the predefined replacement rules + + -checks for 'viewBox' attribute on the SVG element using the 'cheerio' library, and if found, removes the 'width' and 'height' attributes for responsive scaling + + -for each anchor ('a') element, it corrects relative URLs and rearranges rectangle ('rect') elements within the anchor for optimal rendering + + Modified SVG data is then saved back to the file. Error handling is implemented at several stages to address potential issues during directory scanning, file reading, and writing. +*/ + +console.log(""); +console.log(""); +console.log("Fixing SVG files..."); + +const fs = require('fs'); +const path = require('path'); +const config = require('../docusaurus.config.js'); +const cheerio = require('cheerio'); + +const directoryPath = path.join(__dirname, "../static/img"); + +const replacements = [ + { + regex: new RegExp('<\\?xml version="1.0" encoding="UTF-8" standalone="no"\\?>\\n', 'g'), + replaceWith: '' + }, + { + regex: new RegExp('xmlns:xl=', 'g'), + replaceWith: 'xmlns:xlink=' + }, + { + regex: new RegExp('xl:href=', 'g'), + replaceWith: 'xlink:href=' + }, +]; + +fs.readdir(directoryPath, (err, files) => { + if (err) { + return console.log('Unable to scan directory: ' + err); + } + + files.forEach((file) => { + if (path.extname(file) === '.svg') { + const filePath = path.join(directoryPath, file); + fs.readFile(filePath, 'utf8', (err, data) => { + if (err) { + return console.log('Error reading file: ' + err); + } + + let result = data; + + for (const rule of replacements) { + if (rule.regex.toString() !== '/width="\\d+(\\.\\d+)?" height="\\d+(\\.\\d+)?"/') { + result = result.replace(rule.regex, rule.replaceWith); + } + } + + const $ = cheerio.load(result, { xmlMode: true }); + + if ($('svg').attr('viewBox')) { + $('svg').removeAttr('width'); + $('svg').removeAttr('height'); + } + + $('a').each(function () { + const href = $(this).attr('xlink:href'); + if (href && !href.startsWith('http') && !href.includes(config.baseUrl)) { + $(this).attr('xlink:href', config.baseUrl + href); + } + + const a = $(this); + const rects = a.find('rect'); + if (rects.length > 0) { + rects.each(function () { + a.before($(this).clone()); // clone the rect before moving it + }); + rects.remove(); // remove the original rect elements + } + }); + + result = $.html(); + + fs.writeFile(filePath, result, 'utf8', (err) => { + if (err) { + return console.log('Error writing file: ' + err); + } + }); + }); + } + }); +}); + +console.log(""); +console.log("SVG files have been fixed."); +``` + + + + +--- +title: Source: maintenance/fixDashInWikiCopyFilenames.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/maintenance_fixDashInWikiCopyFilenames.js + md: https://weboftrust.github.io/keridoc/JSDoc/maintenance_fixDashInWikiCopyFilenames.js.md +--- + +# Source: maintenance/fixDashInWikiCopyFilenames.js + +``` +/** + * @file This file replaces the hyphen character in file names with the minus sign character. + * When copying files from the wiki, the hyphen character causes issues with the file names. + * Environment: NodeJS + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-12-04 + */ + +require('dotenv').config(); +const fs = require('fs'); +const path = require('path'); + +// const directoryPath = path.join(__dirname, `../docs/${process.env.GLOSSARY_DIR}`); +const directoryPath = `docs/${process.env.GLOSSARY_DIR}`; + +// Function to replace the hyphen character in file names +function replaceHyphenInFileNames(directory) { + fs.readdir(directory, (err, files) => { + if (err) { + console.error('Error reading directory:', err); + return; + } + + files.forEach(file => { + + // Stop if file name is ”_category_.json” + if (file === '_category_.json') { + return; + } + /* + Add an

in markdown at the top of the file. Use the file name without extension as the heading text. Do two replacements: + 1. Replace the hyphen character with a space + 2. Replace the minus sign character with a hyphen + */ + const filePath = `${directory}/${file}`; + + // Read the file's content + const fileContent = fs.readFileSync(filePath, 'utf8'); + + // Extract the filename without extension + const fileNameWithoutExtension = path.parse(file).name; + + // Modify the file's content + const modifiedContent = `# ${fileNameWithoutExtension.replace(/\u2010/g, '-').replace(/-/g, ' ')}\n${fileContent}`; + + // Write the modified content back to the file + fs.writeFileSync(filePath, modifiedContent, 'utf8'); + + // End of addition + + if (file.includes('\u2010')) { + const newFileName = file.replace(/\u2010/g, '-'); + fs.renameSync(`${directory}/${file}`, `${directory}/${newFileName}`, err => { + if (err) { + console.error('Error renaming file:', err); + } else { + console.log(`Renamed ${file} to ${newFileName}`); + } + }); + } + }); + }); +} + +// Replace hyphens in the specified directory +replaceHyphenInFileNames(directoryPath); +``` + + + + +--- +title: Source: maintenance/findBrokenLinks.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/maintenance_findBrokenLinks.js + md: https://weboftrust.github.io/keridoc/JSDoc/maintenance_findBrokenLinks.js.md +--- + +# Source: maintenance/findBrokenLinks.js + +``` +/** + * @file This file checks all links on the WOT-terms site and reports broken links. It also creates a GitHub issue with the broken links. + * The script should be run from the root of the WOT-terms repository. + * Environment: NodeJS + * Usage: + * $ node findBrokenLinks.js + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-09-04 + * @see https://www.npmjs.com/package/broken-link-checker + * @see https://github.com/stevenvachon/broken-link-checker + */ + +require('dotenv').config(); +const { Octokit } = require('@octokit/core'); +const fs = require('fs'); +const { SiteChecker } = require('broken-link-checker'); +const { URL } = require('url'); +const path = require('path'); + +/**********/ +/* CONFIG */ + +const siteUrl = 'https://weboftrust.github.io/WOT-terms'; +const baseUrl = 'https://weboftrust.github.io'; + +const outputDirectory = path.join(__dirname, '../logs'); +const outputFileName = 'brokenLinks.md'; +// const excludedSubdirectories = ['/WOT-terms/slack/']; +const githubToken = process.env.GITHUB_ISSUE_AUTH_TOKEN; + +/* END CONFIG */ +/**************/ + +const outputFilePath = path.join(outputDirectory, outputFileName); +let brokenLinks = {}; +let fileContent = ''; + +console.log('Start Link checking...'); + +const siteChecker = new SiteChecker({ + excludeExternalLinks: true, + maxSocketsPerHost: 10 +}, { + link: (result) => { + // Log every URL that is checked + console.log(`Checking link: ${result.url.resolved}`); + + // Additionally, log if a link is broken + if (result.broken) { + + // brokenLinks.push({ + // url: result.url.resolved, + // brokenReason: result.brokenReason + // }); + + const urlObj = new URL(result.url.original, baseUrl); + const baseObj = new URL(result.base.original, baseUrl); + + const href = urlObj.href; + if (!brokenLinks[href]) { + brokenLinks[href] = []; + } + if (!brokenLinks[href].includes(baseObj.href)) { + brokenLinks[href].push(baseObj.href); + } + console.log(`Broken link found: ${result.url.resolved} (${result.brokenReason}). Found on page: ${baseObj.href}`); + } + + }, + end: () => { + console.log("Finished checking site."); + console.log('Checking done! Writing to file...'); + + // Get ISO8601 timestamp + const getISO8601Timestamp = () => { + const now = new Date(); + return now.toISOString(); + }; + + const timestamp = getISO8601Timestamp(); + const numberOfBrokenLinks = Object.keys(brokenLinks).length; + console.log('numberOfBrokenLinks: ', numberOfBrokenLinks); + + // Format the output for the Markdown file + fileContent = `# Broken Links Report\n\nCreated: ${timestamp}\n\n`; + fileContent += `Total Broken Links Found: ${numberOfBrokenLinks}\n\n`; + + let counter = 1; // Initialize counter variable outside the loop + + for (const [brokenLink, foundOnPages] of Object.entries(brokenLinks)) { + let markdownBrokenLink = `[${brokenLink}](https://weboftrust.github.io/keridoc/JSDoc/${brokenLink}.md)`; + let pagesMarkdown = foundOnPages.map(page => `- [${page}](https://weboftrust.github.io/keridoc/JSDoc/${page}.md)`).join('\n'); + pagesMarkdown += '\n\n'; + fileContent += `## Broken Link #${counter}:\n${markdownBrokenLink}\n\nFound on Pages:\n\n${pagesMarkdown}\n`; + counter++; // Increment counter for the next broken link + } + + // Check if directory exists, if not then create it + if (!fs.existsSync(outputDirectory)) { + fs.mkdirSync(outputDirectory, { recursive: true }); + } + + fs.writeFile(outputFilePath, fileContent, async (err) => { + if (err) { + console.error('Error writing to file:', err); + } else { + console.log(`Broken links and count written to ${outputFilePath}`); + } + }); + + console.log('Creating GitHub issue...'); + + // TODO: Create GitHub should not be inside the file write callback + // Create GitHub issue using Octokit + const issueData = { + title: 'Broken Links Report', + body: "Created: " + timestamp + "\n\n" + "Number of broken internal links: " + numberOfBrokenLinks + "\n\n" + "See full list of broken internal links.", + }; + + const octokit = new Octokit({ + auth: githubToken + }); + + octokit.request('POST /repos/WebOfTrust/WOT-terms/issues', { + owner: 'WebOfTrust', + repo: 'WOT-terms', + title: issueData.title, + body: issueData.body, + // labels: [ + // 'bug' + // ], + headers: { + 'X-GitHub-Api-Version': '2022-11-28' + } + }); + + console.log('GitHub issue created.'); + + } +}); + +siteChecker.enqueue(siteUrl); +``` + + + + +--- +title: Source: maintenance/XMLsitemapEditor.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/maintenance_XMLsitemapEditor.js + md: https://weboftrust.github.io/keridoc/JSDoc/maintenance_XMLsitemapEditor.js.md +--- + +# Source: maintenance/XMLsitemapEditor.js + +``` +/** + * @file This file can be used to edit an XML sitemap file. It can be used to remove all URLs that do not end with .pdf, or to remove all URLs that contain a specific string. The script will create a backup of the original file before editing it. + * Environment: NodeJS + * Usage: + * $ node XMLsitemapEditor.js + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2022-01-01 + */ + +/* + Author: Kor Dwarshuis + Created: 2023-08-11 + Updated: - + Description: This script can be used to edit an XML sitemap file. It can be used to remove all URLs that do not end with .pdf, or to remove all URLs that contain a specific string. The script will create a backup of the original file before editing it. The script is written for Node.js and can be run from the command line using the following command: node XMLsitemapEditor.js + + ==> Make sure to update the configuration below first. +*/ + +const fs = require('fs'); +const path = require('path'); +const xml2js = require('xml2js'); + +// Configuration +const mode = 2; // 1 for .pdf check, 2 for specific string removal +const specificString = "/regulatory-use-of-the-lei/"; // Replace 'example' with the string you want to check for and remove +const inputFilePath = '../search-index-typesense/sitemaps-manual/sitemap-www.gleif.org-pdf.xml'; + +// Backup original file +const backupFilePath = `${inputFilePath}.backup`; + +fs.copyFile(path.resolve(__dirname, inputFilePath), path.resolve(__dirname, backupFilePath), (copyErr) => { + if (copyErr) throw copyErr; + + console.log(`Backup created at: ${backupFilePath}`); + + // Read the sitemap file + fs.readFile(path.resolve(__dirname, inputFilePath), (err, data) => { + if (err) throw err; + + xml2js.parseString(data, (parseErr, result) => { + if (parseErr) throw parseErr; + + if (result.urlset && result.urlset.url) { + if (mode === 1) { + // Retain only URLs ending with .pdf + result.urlset.url = result.urlset.url.filter(urlEntry => { + return urlEntry.loc && urlEntry.loc[0].endsWith('.pdf'); + }); + } else if (mode === 2) { + // Remove URLs containing the specific string + result.urlset.url = result.urlset.url.filter(urlEntry => { + return !(urlEntry.loc && urlEntry.loc[0].includes(specificString)); + }); + } + } + + // Convert back to XML + const builder = new xml2js.Builder(); + const updatedXml = builder.buildObject(result); + + // Save the updated XML back under the original name + fs.writeFile(path.resolve(__dirname, inputFilePath), updatedXml, writeErr => { + if (writeErr) throw writeErr; + console.log(`Updated sitemap saved back to original file: ${inputFilePath}`); + }); + }); + }); +}); +``` + + + + +--- +title: Home +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/index + md: https://weboftrust.github.io/keridoc/JSDoc/index.md +--- + +# Home + +This file adds html attributes with information to the article html-element. The info is fetched from a json file. + +Version: + +- 1.0.0 + +Since: + +- 2023-04-01 + +Author: + +- Kor Dwarshuis + +Source: + +- [clientModules/addDataTypes.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_addDataTypes.md), [line 1](https://weboftrust.github.io/keridoc/JSDoc/clientModules_addDataTypes.md#line1) + +### Example +``` +An article element could look like this: +
…
+``` + + + + +--- +title: Global +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/global + md: https://weboftrust.github.io/keridoc/JSDoc/global.md +--- + +# Global + +### Methods + +#### (async) cleanJsonFile(inputFilePath, outputFilePath) → {Promise.} + +Cleans a JSON file by removing non-printable characters from string values. + +##### Parameters: + +| Name | Type | Description | +| --- | --- | --- | + +| `inputFilePath` | string | The path to the input JSON file. | +| `outputFilePath` | string | The path to write the cleaned JSON data. | + +Source: + +- [modules-js-node/cleanJson.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_cleanJson.md), [line 17](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_cleanJson.md#line17) + +##### Returns: + +A Promise that resolves when the JSON file is cleaned and written successfully. + +Type + +Promise. + +#### unzipFile(zipFilePath, extractToDir) + +Unzips a zip file to a specified destination directory + +##### Parameters: + +| Name | Type | Description | +| --- | --- | --- | + +| `zipFilePath` | \* | | +| `extractToDir` | \* | | + +Source: + +- [modules-js-node/unzipFile.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_unzipFile.md), [line 15](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_unzipFile.md#line15) + + + + +--- +title: Source: clientModules/writeChanges.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_writeChanges.js + md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_writeChanges.js.md +--- + +# Source: clientModules/writeChanges.js + +``` +/** + * @file This file makes table cells editable and send the edited content to a server and create a GitHub issue for each edit. It uses the Octokit library to interact with the GitHub API and the awesome-notifications library to display notifications to the user. + +It also uses a MutationObserver to observe changes in the element. When a change is detected, it collects the data of the edited cell (like row, column, row number, column number, column name, proposed text, term) and stores it in the mutation object. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-03-15 + */ + +import { Octokit, App } from 'octokit'; + +// https://f3oall.github.io/awesome-notifications/docs/why-such-awesome +// https://www.npmjs.com/package/awesome-notifications +// https://github.com/f3oall/awesome-notifications#readme +// import AWN from 'awesome-notifications'; +import AWN from './libs/awesome-notifications.js'; + +// Initialize instance of AWN +let notifier = new AWN({ + maxNotifications: 6, + durations: { + alert: 0, + success: 4000, + }, + icons: { + enabled: false, + }, +}); + +const writeChanges = (element) => { + const el = document.querySelector(element); + const buttonTextEdit = 'Edit'; + const buttonTextSave = 'Send'; + const buttonTextCancel = 'Cancel'; + let explanationAboutGithubIssueShown = false; + + const domainReceivingChanges = + 'https://dwarshuis.com/test/wot-terms/php_scripts/saveEdits.php'; + + if (el !== null) { + write(); + } + + function write() { + const makeEditable = el; + let mutation = {}; + + // // Create an edit/save button and insert before the element we want to edit + // const editSaveButton = document.createElement('button'); + // editSaveButton.classList.add('button'); + // editSaveButton.classList.add('button--secondary'); + // editSaveButton.classList.add('margin--md'); + // editSaveButton.classList.add('edit-save'); + // editSaveButton.innerText = buttonTextEdit; + // el.parentNode.insertBefore(editSaveButton, el); + // editSaveButton.addEventListener('click', makeContentEditable); + + // Create an edit/save button in every table cell + const tableCells = document.querySelectorAll('.googlesheet td'); + tableCells.forEach((cell) => { + if (cell.dataset.columnnr !== '0') { + // Surround the cell content with a div + cell.innerHTML = + '
' + cell.innerHTML + '
'; + + const div = document.createElement('div'); + div.classList.add('buttons'); + cell.appendChild(div); + + const editSaveButton = document.createElement('button'); + editSaveButton.classList.add('button'); + editSaveButton.classList.add('button--secondary'); + editSaveButton.classList.add('margin--md'); + editSaveButton.classList.add('edit-save'); + editSaveButton.innerText = buttonTextEdit; + div.appendChild(editSaveButton); + editSaveButton.addEventListener('click', makeTableCellEditable); + + const cancelButton = document.createElement('button'); + cancelButton.classList.add('button'); + cancelButton.classList.add('button--secondary'); + cancelButton.classList.add('margin--md'); + cancelButton.classList.add('cancel'); + cancelButton.innerText = buttonTextCancel; + div.appendChild(cancelButton); + cancelButton.addEventListener('click', cancelTableCellEditable); + } + }); + + function makeTableCellEditable() { + if (this.parentElement.parentElement.contentEditable !== 'true') { + this.parentElement.parentElement.contentEditable = 'true'; + this.parentElement.parentElement.classList.add('editable'); + this.parentElement.parentElement.focus(); + this.innerText = buttonTextSave; + + if (explanationAboutGithubIssueShown === false) { + notifier.info( + `After editing, click the “${buttonTextSave}” button, and a Github issue will be generated.` + ); + explanationAboutGithubIssueShown = true; + } + } else { + this.parentElement.parentElement.contentEditable = 'false'; + this.innerText = buttonTextEdit; + sendContent(); + } + } + function cancelTableCellEditable() { + this.parentElement.parentElement.contentEditable = 'false'; + this.parentElement.parentElement.classList.remove('editable'); + this.parentElement.querySelector('button.edit-save').innerText = + buttonTextEdit; + } + + async function sendContent() { + var formData = new FormData(); + + formData.append('content', JSON.stringify(mutation)); + + /** + * Write to a textfile on a domain + */ + + // TODO: improve fetch + fetch(domainReceivingChanges, { method: 'POST', body: formData }); + // .then( + // function (response) { + // return response.text(); + // } + // ); + // .then(function (body) { + // }); + + // // Octokit.js + // // https://github.com/octokit/core.js#readme + // const octokit = new Octokit({ + // auth: 'xxx', + // }); + + // octokit.request('POST /repos/kordwarshuis/WOT-terms-edits/dispatches', { + // owner: 'kordwarshuis', + // repo: 'WOT-terms-edits', + // event_type: 'edit', + // client_payload: { + // unit: false, + // integration: true, + // }, + // headers: { + // 'X-GitHub-Api-Version': '2022-11-28', + // }, + // }); + + /** + * Create an issue on Github + */ + let auth = prompt('Enter token'); + + // Initialize the Octokit client + const octokit = new Octokit({ + auth: auth, + }); + + // Create the issue payload + const payload = { + owner: 'kordwarshuis', + repo: 'WOT-terms-edits', + title: `New edit for “${mutation.columnname}” for the term: “${mutation.term}”.`, + body: `An edit has been made in column “${mutation.columnname}” for the term: “${mutation.term}”.\n\nThe new text is: “${mutation.proposedText}”\n\n(Column: ${mutation.columnnr}, Row: ${mutation.rownr})`, + }; + + // Send the request to create the issue + const response = await octokit.rest.issues.create(payload); + + let onOk = () => { + // notifier.info('You pressed OK'); + }; + notifier.confirm( + `A new issue has been created on Github at: ${response.data.html_url}`, + onOk, + false, + { + labels: { + confirm: 'Info', + }, + } + ); + } + + // https://hacks.mozilla.org/2012/05/dom-mutationobserver-reacting-to-dom-changes-without-killing-browser-performance/ + // TODO: implement observer.disconnect(); + const observer = new MutationObserver((mutationRecords) => { + // Collect the data like row, column, rownr, columnnr, columnname, proposedText, term of the edited cell + mutation.row = + mutationRecords[0].target.parentElement.parentElement.dataset.row; + mutation.rownr = + mutationRecords[0].target.parentElement.parentElement.dataset.rownr; + mutation.column = + mutationRecords[0].target.parentElement.parentElement.dataset.column; + mutation.columnnr = + mutationRecords[0].target.parentElement.parentElement.dataset.columnnr; + mutation.columnname = document.querySelectorAll( + `.googlesheet th[data-columnnr]` + )[ + mutationRecords[0].target.parentElement.parentElement.dataset.columnnr + ].innerText; + + // The text that is being edited + mutation.proposedText = + mutationRecords[0].target.parentElement.parentElement.innerText; + + // Remove the edit button text from the text that is being edited + mutation.proposedText = mutation.proposedText.substring( + 0, + mutation.proposedText.length - + buttonTextSave.length - + buttonTextCancel.length - + 1 + ); + + // The term that is being edited + mutation.term = document.querySelectorAll( + `.googlesheet tr[data-rownr="${mutation.rownr}"] td[data-columnnr="4"]` + )[0].innerText; + + // Remove the edit button text from the term + mutation.term = mutation.term.substring( + 0, + mutation.term.length - + document.querySelectorAll( + `.googlesheet tr[data-rownr="${mutation.rownr}"] td[data-columnnr="4"] button.cancel` + )[0].innerText.length - + document.querySelectorAll( + `.googlesheet tr[data-rownr="${mutation.rownr}"] td[data-columnnr="4"] button.edit-save` + )[0].innerText.length - + 1 + ); + }); + observer.observe(el, { + characterData: true, + subtree: true, + }); + } +}; + +export function onRouteDidUpdate({ location, previousLocation }) { + // Don't execute if we are still on the same page; the lifecycle may be fired + // because the hash changes (e.g. when navigating between headings) + // if (location.pathname === previousLocation?.pathname) return; + writeChanges('.googlesheet'); +} +``` + + + + +--- +title: Source: clientModules/upvoteSearchResult.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_upvoteSearchResult.js + md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_upvoteSearchResult.js.md +--- + +# Source: clientModules/upvoteSearchResult.js + +``` +/** + * @file This file adds upvote functionality to KERISSE search results. + * It listens for clicks on elements with the class "upvote" and captures + * relevant search result data. + * + * The script also prompts users for a simple anti spam check. + * Once the user's answer is verified by a remote PHP script, an upvote is sent to another + * remote PHP script. A token is stored in a cookie for future upvotes without requiring + * the user to answer the prompt again. + * + * Dependencies: + * - Octokit, App from 'octokit' + * - Awesome-Notifications (AWN) for user notifications + * + * Configuration variables are specified under the CONFIG section. + * They include the URLs for the remote PHP scripts for upvoting and answer-checking, + * as well as messages displayed to the user. + * + * https://f3oall.github.io/awesome-notifications/docs/why-such-awesome + * https://www.npmjs.com/package/awesome-notifications + * https://github.com/f3oall/awesome-notifications#readme + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-09-18 + */ +import { Octokit, App } from 'octokit'; +// import AWN from 'awesome-notifications'; +import AWN from './libs/awesome-notifications.js'; + +// Initialize instance of AWN, awesome notifications +let notifier = new AWN({ + maxNotifications: 6, + durations: { + alert: 0, + success: 4000, + }, + icons: { + enabled: false, + }, +}); + +const upvoteSearchResult = () => { + // CONFIG + const remoteUpvoteScript = 'https://dwarshuis.com/various/kerisse/php_scripts/upvotes.php'; + const remoteCheckAnswerScript = 'https://dwarshuis.com/various/kerisse/php_scripts/checkAnswer.php'; + const promptText = '- - - - - - - - -\nCheck: What is the four letter word (in lowercase) for the identity system based secure overlay for the Internet?\n\nSet the cookie. Go!!!'; + const upvoteSentText = 'Your upvote has been sent. This is a test and currently we are manually checking and processing the results.'; + const upvoteNotSentText = `Not the answer we expected. Your upvote has NOT been sent.`; + const continueText = 'You are upvoting a search result.'; + // END CONFIG + + let activeButton = null; + let upvoteData = {}; + + // Add event listener to the upvote buttons. + document.addEventListener('click', (event) => { + if (event.target.classList.contains('upvote')) { + // Take the url from the href in the previous element + let searchHitUrl = event.target.previousElementSibling.getAttribute('href'); + + // Take the search term from the search box + let searchTerm = document.querySelector(".ais-SearchBox-input").value; + + // Create the upvote data object + upvoteData.name = searchTerm.replace(/ /g, '-') + "-" + Math.floor(Date.now() / 1000); // Replace spaces with dashes, unix timestamp to make unique + upvoteData.url = searchHitUrl; + upvoteData.query = searchTerm; + upvoteData.position = "1"; + upvoteData.match = "exact"; + activeButton = event.target; + submitAnswer(); + } + }); + + function submitAnswer() { + // First, check if there is any cookie set at all. + if (document.cookie.indexOf("upvoteAnswer=") !== -1) { + // Read the stored token from the cookie + let cookieValue = document.cookie + .split('; ') + .find(row => row.startsWith('upvoteAnswer=')) + .split('=')[1]; + + // Here we could validate the token against the server, but this is a basic check, we will leave it for now. + // For now, we skip the question. + // sendContent(upvoteData, cookieValue); + const userResponse = confirm(continueText); + if (userResponse) { + // Code to execute if the user clicks "OK" + console.log("You chose to continue!"); + sendContent(upvoteData, cookieValue); + console.log("sendContent"); + // Disable the upvote button + activeButton.disabled = true; + } else { + // Code to execute if the user clicks "Cancel" + console.log("You chose to cancel."); + return + } + } else { + // User has not yet answered the question + const userAnswer = prompt(promptText, ""); + fetch(remoteCheckAnswerScript, { + method: 'POST', + headers: { + 'Content-Type': 'application/x-www-form-urlencoded', + }, + body: `user_answer=${userAnswer}` + }) + .then(response => response.json()) + .then(data => { + if (data.success) { + console.log("Correct answer!"); + document.cookie = `upvoteAnswer=${data.token}; max-age=31536000`; // Expires after 1 year + + const userResponse = confirm(continueText); + if (userResponse) { + // Code to execute if the user clicks "OK" + console.log("You chose to continue!"); + sendContent(upvoteData, data.token); + console.log("sendContent"); + // Disable the upvote button + activeButton.disabled = true; + } else { + // Code to execute if the user clicks "Cancel" + console.log("You chose to cancel."); + return + } + } else { + console.log("Incorrect answer!"); + notifier.confirm( + upvoteNotSentText, + onOk, + false, + { + labels: { + confirm: 'Info', + }, + } + ); + } + }); + } + } + + let onOk = () => { + // notifier.info('You pressed OK'); + }; + + function sendContent(data, token) { + var formData = new FormData(); + + formData.append('content', JSON.stringify(data)); + formData.append('token', token); // Add the token + + // Send the data to the remote script + fetch(remoteUpvoteScript, { method: 'POST', body: formData }); + + notifier.confirm( + upvoteSentText, + onOk, + false, + { + labels: { + confirm: 'Info', + }, + } + ); + } +}; + +export function onRouteDidUpdate({ location, previousLocation }) { + // Don't execute if we are still on the same page; the lifecycle may be fired + // because the hash changes (e.g. when navigating between headings) + // if (location.pathname === previousLocation?.pathname) return; + upvoteSearchResult(); +} +``` + + + + +--- +title: Source: clientModules/typesenseInstantSearchInit.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseInstantSearchInit.js + md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseInstantSearchInit.js.md +--- + +# Source: clientModules/typesenseInstantSearchInit.js + +``` +/** + * @file This file creates the DOM elements for the Typesense search box and search results. The DOM elements for the search hits are in the main Typesense InstantSearch plugin code. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-05-19 + */ + +import paths from "../docusaurus.paths"; + +const typesenseInstantSearchCreateDomElements = () => { + const domStringSearchStart = ``; + const domStringSearchResult = ` + + + `; + + // Add search to dom + if (document.querySelector('#search') === null) { + document + .querySelector('body') + .insertAdjacentHTML('afterbegin', domStringSearchResult); + } + + // TODO: find out why check for null does not work + // if (document.querySelector('#search-start') === null) { + if (document.querySelector('#search-start')) { + document.querySelector('#search-start').remove(); + } + document + .querySelector('.navbar__items--right') + .insertAdjacentHTML('beforeend', domStringSearchStart); + // } + + /* + TIMESTAMP + + The code below Fetches HTML content from indexed-in-KERISSE on this same domain using the `fetch` API. + + It then parses the fetched HTML using `DOMParser` and queries the DOM to find a paragraph element with the id "index-created-timestamp-source". + + If the element is found, its text content is added to the search result page; otherwise, an appropriate message indicating the absence of such an element is logged. + */ + + // Fetching the HTML content + fetch(paths.indexedInKERISSE, { + headers: { + 'Cache-Control': 'no-cache', + 'Pragma': 'no-cache', + 'Expires': '0' + } + }) + .then(response => response.text()) + .then(html => { + // Parsing the fetched HTML string into a DOM object + const parser = new DOMParser(); + const doc = parser.parseFromString(html, 'text/html'); + + // Finding the paragraph elements by their id's + const timestampElement = doc.querySelector('#index-created-timestamp-source'); + const pageCountElement = doc.querySelector('#index-created-page-count-source'); + + if (timestampElement) { + // Extracting and logging the content of the paragraph + const timestampContent = timestampElement.textContent; + document.querySelector('#index-created-timestamp-target-search-modal').textContent = timestampContent; + } else { + console.log('Element with id "index-created-timestamp-source" not found.'); + } + + if (pageCountElement) { + // Extracting and logging the content of the paragraph + const pageCountContent = pageCountElement.textContent; + document.querySelector('#index-created-page-count-target-search-modal').textContent = pageCountContent; + } else { + console.log('Element with id "index-created-page-count-source" not found.'); + } + }) + .catch(error => { + console.error(`Error fetching the content: ${error}`); + }); + // END TIMESTAMP + +}; + +export function onRouteDidUpdate({ location, previousLocation }) { + // Don't execute if we are still on the same page; the lifecycle may be fired + // because the hash changes (e.g. when navigating between headings) + if (location.pathname === previousLocation?.pathname) return; + typesenseInstantSearchCreateDomElements(); +} +``` + + + + +--- +title: Source: clientModules/typesenseInstantSearch.js +source_url: + html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseInstantSearch.js + md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseInstantSearch.js.md +--- + +# Source: clientModules/typesenseInstantSearch.js + +``` +/** + * @file This file instantiates the Typesense InstantSearch.js adapter and the InstantSearch.js search client. + * @author Kor Dwarshuis + * @version 1.0.0 + * @since 2023-05-19 + */ + +import instantsearch from 'instantsearch.js/es'; + +// to be used in the future +// import { queriesWithSortAdjustment } from '/search-index-typesense/overrides/sortAdjustment.js'; + +import { + searchBox, + hits, + pagination, + // infiniteHits, + configure, + // stats, + // analytics, + refinementList, + clearRefinements, + // menu, + sortBy, + currentRefinements, +} from 'instantsearch.js/es/widgets'; + +import TypesenseInstantSearchAdapter from 'typesense-instantsearch-adapter'; +// import { SearchClient as TypesenseSearchClient } from 'typesense'; // To get the total number of docs + +// import { connectSearchBox } from 'instantsearch.js/es/connectors' +import { connectRefinementList } from 'instantsearch.js/es/connectors'; + +// This is a custom widget that displays the refinement list for the "tag" attribute, but only for items that have the label "img". This is a replacement for the standard refinementList widget. The standard refinementList widget does not allow you to show a message when there are no items available. This custom widget does. +const refinementListImageToggle = connectRefinementList((renderOptions, isFirstRender) => { + const { items, widgetParams } = renderOptions; + + const container = document.querySelector("#tag-refinement-list"); + + if (items.length === 0) { + // Display "No results" if there are no items + container.innerHTML = '
No images available
'; + } else { + // Otherwise, build and display the refinement list + const list = items.map(item => { + return ``; + }).join(''); + + container.innerHTML = `
${list}
`; + } +}); + +const typeSenseInstantSearch = () => { + // "Try searching for:" + function handleSearchTermClick(event) { + const searchBox = document.querySelector('.ais-SearchBox-input'); + search.helper.clearRefinements(); + searchBox.value = event.currentTarget.textContent; + search.helper.setQuery(searchBox.value).search(); + } + + document.querySelectorAll('.clickable-search-term').forEach((el) => { + el.addEventListener('click', handleSearchTermClick); + }); + + // to be used in the future + // function applyCustomSorting(items) { + // console.log('items: ', items); + // const currentQuery = search.helper.state.query; + + // const matchingQueryObj = queriesWithSortAdjustment.find( + // (obj) => obj.queryString === currentQuery + // ); + + // if (matchingQueryObj) { + // const sortAdjustment = matchingQueryObj.sortAdjustment; + // const urlSubstring = matchingQueryObj.urlSubstring; + + // return items.map((item) => { + // item.sort_order = item.url && item.url.includes(urlSubstring) ? sortAdjustment : 0; + // return item; + // }).sort((a, b) => b.sort_order - a.sort_order); + // } + + // return items; + // } + + const typesenseInstantsearchAdapter = new TypesenseInstantSearchAdapter({ + server: { + apiKey: 'qy6mC9ZakKZ3C8GUD5T3iDrelDgpp5Zc', // Be sure to use an API key that only allows searches, in production + nodes: [ + { + host: '9ktso7i1b8034azqp-1.a1.typesense.net', + port: '443', + protocol: 'https', + }, + ], + }, + // The following parameters are directly passed to Typesense's search API endpoint. + // So you can pass any parameters supported by the search endpoint below. + // queryBy is required. + // filterBy is managed and overridden by InstantSearch.js. To set it, you want to use one of the filter widgets like refinementList or use the `configure` widget. + additionalSearchParameters: { + // query_by: 'title,authors', + // query_by: 'imgMeta, content, firstHeadingBeforeElement, pageTitle, siteName, source, url', + query_by: 'content, firstHeadingBeforeElement, pageTitle, siteName, source, url', + // weights: '10000,1,1,1,1,1,1', + // filter_by: 'tag:=[p]', + // filter_by: 'tag:[a]', + // filter_by: 'contentLength:>50', + // sort_by: 'contentLength:asc',//asc or desc + + // sort_by: 'imgMetaLength:asc, contentLength:asc',//asc or desc + sort_by: 'imgWidth:desc,contentLength:desc,imgUrl(missing_values: last):desc',//asc or desc + // sort_by: 'imgWidth:desc,imgUrl(missing_values: last):desc',//asc or desc + group_by: 'url', + group_limit: 1 + }, + }); + const searchClient = typesenseInstantsearchAdapter.searchClient; + + const search = instantsearch({ + searchClient, + indexName: 'Wot-terms',// production + // indexName: 'Wot-terms-test',// testing + routing: true, + // searchFunction(helper) { + // if (helper.state.query === '') { + // document + // .querySelector('.search-modal-backdrop') + // .classList.add('hidden'); + // document.querySelector('#search').classList.add('hidden'); + // } else { + // document + // .querySelector('.search-modal-backdrop') + // .classList.remove('hidden'); + // document.querySelector('#search').classList.remove('hidden'); + // } + // helper.search(); + // }, + }); + + search.addWidgets([ + searchBox({ + container: '#search-box', + showSubmit: false, + showReset: false, + showLoadingIndicator: true, + placeholder: 'Enter Search…', + autofocus: true, + cssClasses: { + input: 'form-control', + }, + // queryHook(query, search) { + // const modifiedQuery = queryWithoutStopWords(query); + // if (modifiedQuery.trim() !== '') { + // search(modifiedQuery); + // } + // }, + }), + + configure({ + hitsPerPage: 10, + }), + hits({ + container: '#hits', + + // to be used in the future + // transformItems(items) { + // let sortedItems = applyCustomSorting(items); + // return sortedItems; + // }, + templates: { + item(item) { + function makeCodeStringShorter(string) { + /* + Sometimes code blocks are very long and they take up a lot of space in the search results. + + This function takes a string as input and returns a modified version of the string. + It finds the first occurrence of the tag and the tag in the input string. + Then, it extracts a substring that includes 100 characters before the first and 100 characters after the first . + The extracted substring is wrapped in an HTML element with the class "highlighted". + If either the tag or the tag is not found, the function returns the original string unchanged. + */ + + // Find the index of the first occurrence of and in the string + let firstMarkerTagIndex = string.indexOf(''); + let lastMarkerTagIndex = string.indexOf(''); + + // Check if either < marker > or is not found in the string + if (firstMarkerTagIndex === -1 || lastMarkerTagIndex === -1) { + return string; // Return the original string if the tags are not found + } + + // Calculate the start and end indices for the substring + let start = Math.max(0, firstMarkerTagIndex - 300); // Start xxx characters before the first or at the beginning of the string + let end = Math.min(string.length, lastMarkerTagIndex + 300); // End xxx characters after the first or at the end of the string + + // Extract the substring containing 100 characters before the first and 100 characters after the first + let firstMarkerTagWith100CharactersBeforeAndAfterIt = string.substring(start, end); + + // Add a span with the "highlighted" class around the extracted substring + firstMarkerTagWith100CharactersBeforeAndAfterIt = `${firstMarkerTagWith100CharactersBeforeAndAfterIt}`; + + return firstMarkerTagWith100CharactersBeforeAndAfterIt; // Return the modified string + } + + // External links should open in a new tab + let openInNewTab = ''; + if (item.url.indexOf('weboftrust.github.io/WOT-terms') === -1) { + openInNewTab = 'target="_blank" rel="noopener"'; + } + + // "Postprocess" the content. Especially code samples can be very long and take up a lot of space in the search results. This function makes the code samples shorter. TODO: check if other content types need to be shortened as well. + let postProcessedCode = ''; + + // If the tag is pre or textarea, wrap the content in a 
 tag, first let's do the opening tag
+          let postProcessedOpeningTag = '';
+          if (item.tag === 'pre' || item.tag === 'textarea') {
+            postProcessedOpeningTag = '
';
+            postProcessedCode = makeCodeStringShorter(item._highlightResult.content.value);
+          } else { // Otherwise, wrap the content in a 
 tag
+            postProcessedOpeningTag = '
'
+            postProcessedCode = item._highlightResult.content.value;
+          }
+
+          // If the tag is pre or textarea, wrap the content in a 
 tag, now let's do the closing tag
+          let postProcessedClosingTag = '';
+          if (item.tag === 'pre' || item.tag === 'textarea') {
+            postProcessedClosingTag = '
';
+          } else { // Otherwise, wrap the content in a 
 tag
+            postProcessedClosingTag = '
'
+          }
+          // END "Postprocess" the content
+
+          // Only if curated is true, show a sticky label
+          let itemCurated = item.curated === true ? `` : '';
+
+          // Only if siteName is not empty, show it
+          let itemSiteNameTemplateString = item.siteName !== '' ? `${item._highlightResult.siteName.value}` : '';
+
+          // Only if title is not empty, show it
+          // mb-4
+          let itemTitleTemplateString = item.pageTitle !== '' ? `
${item._highlightResult.pageTitle.value}
` : '';
+
+          // Only if author is not empty, show it
+          let itemAuthorTemplateString = item.author !== '' ? `• ${item._highlightResult.author.value}` : '';
+
+          // Add class to img based on imgWidth (img that are under 301 are assumed to be logos etc, above 301 are assumed to be explanations, flowcharts, etc)
+          let imgClass = '';
+          item.imgWidth < 301 ? imgClass = "inline-thumb-start" : imgClass = "";
+
+          // Only if imgUrl is not empty, show it
+          let itemImgUrlTemplateString = item.imgUrl !== '' ? `` : '';
+
+          // Only if imgMeta is not empty, show it
+          let itemImgMetaTemplateString = item.imgMeta !== '' ? `
${item._highlightResult.imgMeta.value}
` : '';
+
+          // Only if creationDate is not empty, show it
+          let itemCreationDateTemplateString = item.creationDate !== '' ? `• ${item.creationDate}` : '';
+
+          // Only if knowledgeLevel is not empty, show it
+          let itemKnowledgeLevelTemplateString = item.knowledgeLevel !== '' ? `• Level: ${item.knowledgeLevel}` : '';
+
+          // Only if type is not empty, show it
+          let itemTypeTemplateString = item.type !== '' ? `• ${item.type}` : '';
+
+          // Only if hierarchy.lvl1 is not empty, show it
+          let itemHierarchyLvl1TemplateString = item['hierarchy.lvl1'] !== '' ? `• ${item['hierarchy.lvl1']}` : '';
+
+          // Only if firstHeadingBeforeElement is not empty, show it
+          let itemFirstHeadingBeforeElementTemplateString = item.firstHeadingBeforeElement !== '' ? `
${item.firstHeadingBeforeElement}
` : '';
+
+          let siteBrandingClass = '';
+          if (item.siteName === "Gleif website") {
+            siteBrandingClass = "gleif";
+          }
+          if (item.siteName === "eSSIF-Lab") {
+            siteBrandingClass = "essif-lab";
+          }
+          if (item.siteName === "KERISSE (this site)") {
+            siteBrandingClass = "kerisse";
+          }
+          return `
+            

+              

+                ${itemCurated}
 Found on: ${itemSiteNameTemplateString}

+              

+              

+                

+                  ${item._highlightResult.url.value}
+                  ${itemAuthorTemplateString}
+                  ${itemCreationDateTemplateString}
+                  ${itemKnowledgeLevelTemplateString}
+                  ${itemTypeTemplateString}
+                  ${itemHierarchyLvl1TemplateString}
+                

+                

+                ${itemTitleTemplateString}
+                ${itemFirstHeadingBeforeElementTemplateString}
+
+                ${postProcessedOpeningTag}
+                  ${postProcessedCode}
+                ${postProcessedClosingTag}
+
+                ${itemImgUrlTemplateString}
+                ${itemImgMetaTemplateString}
+              

+              

+                back to top
+                to URL
+                
+              

+            

+      `;
+        },
+      },
+    }),
+
+    pagination({
+      container: '#pagination',
+    }),
+    clearRefinements({
+      container: '#clear-refinements',
+      templates: {
+        resetLabel: 'Clear filters'
+      },
+      cssClasses: {
+        button: 'btn btn-secondary btn-sm align-content-center mb-5 mt-3'
+      }
+    }),
+    currentRefinements({
+      container: '#current-refinements-list',
+      cssClasses: {
+        list: 'list-unstyled',
+        item: '',
+        delete: 'btn btn-sm btn-link text-decoration-none p-0 px-2',
+      },
+      transformItems: (items) => {
+        // hide the heading if there are no current refinements
+        document.querySelector("#current-refinements-list-container").classList.add("d-none");
+        const labelLookup = {
+          content: 'Content',
+          author: 'Author',
+          category: 'Category',
+          source: 'Source',
+          mediaType: 'File type',
+        };
+        const modifiedItems = items.map((item) => {
+          // show the heading if there are current refinements
+          document.querySelector("#current-refinements-list-container").classList.remove("d-none");
+          return {
+            ...item,
+            label: labelLookup[item.attribute] || '',
+          };
+        });
+        return modifiedItems;
+      },
+    }),
+    // Currently not useful
+    // sortBy({
+    //   container: '#sort-by',
+    //   items: [
+    //     { label: 'Default Sort', value: 'Wot-terms' },
+    //     { label: 'Content Length: Low to High', value: 'Wot-terms/sort/contentLength:asc' },
+    //     { label: 'Content Length: High to Low', value: 'Wot-terms/sort/contentLength:desc' },
+    //   ],
+    //   cssClasses: {
+    //     select: 'form-select form-select-sm mb-2 border-light-2',
+    //   },
+    // }),
+
+    // // KNOWLEDGELEVEL
+    // refinementList({
+    //   container: '#knowledgelevel-refinement-list',
+    //   attribute: 'knowledgeLevel',
+    //   searchable: false,
+    //   searchablePlaceholder: 'Search knowledge level',
+    //   showMore: false,
+    //   cssClasses: {
+    //     searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+    //     searchableSubmit: 'hidden',
+    //     searchableReset: 'hidden',
+    //     showMore: 'btn btn-secondary btn-sm align-content-center',
+    //     list: 'list-unstyled',
+    //     count: '',
+    //     label: '',
+    //     checkbox: 'me-2',
+    //   },
+
+    //   sortBy: ['name:asc', 'count:desc'],
+    // }),
+    // // TYPE
+    // refinementList({
+    //   container: '#type-refinement-list',
+    //   attribute: 'type',
+    //   searchable: false,
+    //   searchablePlaceholder: 'Search type',
+    //   showMore: false,
+    //   cssClasses: {
+    //     searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+    //     searchableSubmit: 'hidden',
+    //     searchableReset: 'hidden',
+    //     showMore: 'btn btn-secondary btn-sm align-content-center',
+    //     list: 'list-unstyled',
+    //     count: '',
+    //     label: '',
+    //     checkbox: 'me-2',
+    //   },
+
+    //   sortBy: ['name:asc', 'count:desc'],
+    // }),
+    // // SUBJECT
+    // refinementList({
+    //   container: '#subject-refinement-list',
+    //   attribute: 'hierarchy.lvl1',
+    //   searchable: false,
+    //   searchablePlaceholder: 'Subject',
+    //   showMore: false,
+    //   cssClasses: {
+    //     searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+    //     searchableSubmit: 'hidden',
+    //     searchableReset: 'hidden',
+    //     showMore: 'btn btn-secondary btn-sm align-content-center',
+    //     list: 'list-unstyled',
+    //     count: '',
+    //     label: '',
+    //     checkbox: 'me-2',
+    //   },
+    //   sortBy: ['name:asc', 'count:desc'],
+    // }),
+    // TAG
+
+    refinementListImageToggle({
+      container: '#tag-refinement-list',
+      attribute: 'tag',
+      // Include other necessary widget options here
+      transformItems: items => items.filter(item => ['img'].includes(item.label)),
+      limit: 1000
+    }),
+
+    // CATEGORY
+    refinementList({
+      container: '#category-refinement-list',
+      attribute: 'category',
+      searchable: true,
+      searchablePlaceholder: 'Category',
+      showMore: false,
+      // max_facet_values: 100, TODO: does this work?
+      cssClasses: {
+        searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+        searchableSubmit: 'hidden',
+        searchableReset: 'hidden',
+        showMore: 'btn btn-secondary btn-sm align-content-center',
+        list: 'list-unstyled',
+        count: '',
+        label: '',
+        checkbox: 'me-2',
+      },
+      sortBy: ['name:asc', 'count:desc'],
+    }),
+    // SOURCE
+    refinementList({
+      container: '#source-refinement-list',
+      attribute: 'source',
+      searchable: true,
+      searchablePlaceholder: 'Source',
+      showMore: true,
+      // max_facet_values: 100, TODO: does this work?
+      cssClasses: {
+        searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+        searchableSubmit: 'hidden',
+        searchableReset: 'hidden',
+        showMore: 'btn btn-secondary btn-sm align-content-center',
+        list: 'list-unstyled',
+        count: '',
+        label: '',
+        checkbox: 'me-2',
+      },
+      sortBy: ['name:asc', 'count:desc'],
+    }),
+
+    refinementList({
+      container: '#author-refinement-list',
+      attribute: 'author',
+      searchable: true,
+      searchablePlaceholder: 'Author',
+      showMore: true,
+      // max_facet_values: 100,TODO: does this work?
+      cssClasses: {
+        searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+        searchableSubmit: 'hidden',
+        searchableReset: 'hidden',
+        showMore: 'btn btn-secondary btn-sm align-content-center',
+        list: 'list-unstyled',
+        count: '',
+        label: '',
+        checkbox: 'me-2',
+      },
+      sortBy: ['name:asc', 'count:desc'],
+    }),
+    // MEDIATYPE
+    refinementList({
+      container: '#media-type-refinement-list',
+      attribute: 'mediaType',
+      searchable: true,
+      searchablePlaceholder: 'File type',
+      showMore: true,
+      // max_facet_values: 100,TODO: does this work?
+      cssClasses: {
+        searchableInput: 'form-control form-control-sm mb-2 border-light-2',
+        searchableSubmit: 'hidden',
+        searchableReset: 'hidden',
+        showMore: 'btn btn-secondary btn-sm align-content-center',
+        list: 'list-unstyled',
+        count: '',
+        label: '',
+        checkbox: 'me-2',
+      },
+      sortBy: ['name:asc', 'count:desc'],
+    }),
+  ]);
+
+  // function handleSearchTermClick(event) {
+  //   const searchBox = document.querySelector('#search-box input[type=search]');
+  //   search.helper.clearRefinements();
+  //   searchBox.val(event.currentTarget.textContent);
+  //   search.helper.setQuery(searchBox.val()).search();
+  // }
+
+  // search.on('render', function () {
+  //   // Make artist names clickable
+  //   // $('#hits .clickable-search-term').on('click', handleSearchTermClick);
+  //   document.querySelectorAll('.hit-url a').forEach((el) => {
+  //     el.addEventListener('click', handleSearchTermClick);
+  //   });
+  // });
+
+  search.start();
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+  typeSenseInstantSearch();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/typesenseHandleSearchModal.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseHandleSearchModal.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseHandleSearchModal.js.md
+---
+
+# Source: clientModules/typesenseHandleSearchModal.js
+
+```
+/**
+ * @file This file makes the state of the search modal (open or closed) persistent in the url.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-06-21
+ */
+
+import paths from "../docusaurus.paths";
+
+// The search Modal is a modal that opens when the user clicks on the search icon in the top right corner of the screen.
+let searchModalStatus = '';
+
+// Some things need to be done only once, when the app is initialized
+let appInitialized = false;
+
+function router() {
+  function getParam(key) {
+    const searchParams = new URLSearchParams(window.location.search);
+    return searchParams.get(key);
+  }
+
+  // Function to set the value of a search parameter
+  function setParam(key, value) {
+    const searchParams = new URLSearchParams(window.location.search);
+    searchParams.set(key, value);
+
+    // Update the URL with the modified search parameters
+    const newUrl = window.location.pathname + '?' + searchParams.toString();
+    window.history.replaceState(null, '', newUrl);
+  }
+
+  return {
+    getParam,
+    setParam
+  };
+}
+
+// Create an instance of the router
+const myRouter = router();
+
+function hideModal() {
+  document.querySelector('.search-modal-backdrop').classList.add('hidden');
+  document.querySelector('#search').classList.add('hidden');
+  searchModalStatus = 'closed';
+}
+
+function showModal() {
+  document.querySelector('.search-modal-backdrop').classList.remove('hidden');
+  document.querySelector('#search').classList.remove('hidden');
+  document.querySelector('.ais-SearchBox-input').focus();
+}
+
+// Runs on onRouteDidUpdate
+const typesenseHandleSearchModal = () => {
+  // Only first time when app loads
+  if (appInitialized === false) {
+    document.addEventListener('eventSearchModalCloses', function () {
+      hideModal();
+
+      // Add to url that the modal is closed
+      myRouter.setParam('searchModalStatus', 'closed');
+    }, false);
+
+    document.addEventListener('eventSearchModalOpens', function () {
+      showModal();
+
+      searchModalStatus = 'open';
+
+      // Add to url that the modal is open
+      myRouter.setParam('searchModalStatus', 'open');
+
+      // Hide the search results on the home page if the search box is empty
+      if (window.location.pathname === paths.baseUrl && document.querySelector('.ais-SearchBox-input').value === '') {
+        document.querySelector('.search-results-container').classList.add('d-none');
+        document.querySelector('.to-search-results').classList.add('d-none');
+      } else {
+        document.querySelector('.search-results-container').classList.remove('d-none');
+        document.querySelector('.to-search-results').classList.remove('d-none');
+      }
+    }, false);
+
+  }
+
+  // on new page load, check if the search modal should be open or closed
+  if (myRouter.getParam('searchModalStatus') === 'open') {
+    showModal();
+    searchModalStatus = 'open';
+  } else {
+    hideModal();
+    searchModalStatus = 'closed';
+  }
+
+  // // on new page load, if search box is empty, hide results. There seems to be no out of the box solution for this
+  // if (document.querySelector('.ais-SearchBox-input').value === '') {
+  //   document.querySelector('#hits').classList.add('hidden');
+  //   document.querySelector('#pagination').classList.add('hidden');
+  //   document.querySelector('.ais-SearchBox-input').addEventListener('input', function () {
+  //     document.querySelector('#hits').classList.remove('hidden');
+  //     document.querySelector('#pagination').classList.remove('hidden');
+  //   })
+  // }
+
+  function setSearchModalStatusInUrl() {
+    setTimeout(() => {
+      myRouter.setParam('searchModalStatus', searchModalStatus);
+    }, 1000);//TODO: typesense removes all query params so we need to wait for that to happen and the re-add the searchModalStatus param. Find out how typesense can be configured to not remove all query params
+  }
+
+  function toggleSearchResultsVisibility() {
+    if (window.location.pathname === paths.baseUrl && document.querySelector('.ais-SearchBox-input').value === '') {
+      document.querySelector('.search-results-container').classList.add('d-none');
+      document.querySelector('.to-search-results').classList.add('d-none');
+    } else {
+      document.querySelector('.search-results-container').classList.remove('d-none');
+      document.querySelector('.to-search-results').classList.remove('d-none');
+    }
+  }
+
+  document.querySelector('.ais-SearchBox-input').addEventListener('input', function (e) {// Should be “input”, not “change”
+    setSearchModalStatusInUrl();
+    toggleSearchResultsVisibility();
+  }, false);
+
+  // event delegation, for the filters
+  const on = (selector, eventType, childSelector, eventHandler) => {
+    const elements = document.querySelectorAll(selector);
+    for (let element of elements) {
+      element.addEventListener(eventType, eventOnElement => {
+        if (eventOnElement.target.matches(childSelector)) {
+          eventHandler(eventOnElement);
+        }
+      }, true);
+    }
+  };
+
+  // When a filter is clicked
+  on('#filters-section', 'click', '.ais-RefinementList-checkbox', event => {
+    setSearchModalStatusInUrl();
+  });
+
+  // create event for opening and closing the search modal
+  var eventSearchModalOpens = new Event('eventSearchModalOpens');
+  var eventSearchModalCloses = new Event('eventSearchModalCloses');
+
+  function handleSearchModalCloseClick(e) {
+    document.dispatchEvent(eventSearchModalCloses);
+
+  }
+  function handleSearchModalOpenClick(e) {
+    document.dispatchEvent(eventSearchModalOpens);
+
+  }
+
+  // Dispatch the event.
+  // Only first time when app loads, since the Modal DOM structure is apparently preserved between pages
+  if (appInitialized === false) {
+    document.querySelector('#search-close').addEventListener('click', handleSearchModalCloseClick);
+  }
+
+  // Dispatch the event.
+  // This DOM element is not preserved between pages, so we need to add the event listener every time the page loads
+  document.querySelector('#search-start').addEventListener('click', handleSearchModalOpenClick);
+
+  if (window.location.pathname === paths.baseUrl) {
+    handleSearchModalOpenClick();
+  }
+  // Close the search modal when the backdrop is clicked
+  document.querySelector('.search-modal-backdrop').addEventListener('click', handleSearchModalCloseClick);
+
+  // Close the search modal when the escape key is pressed
+  document.addEventListener('keyup', (event) => {
+    switch (event.key) {
+      // escape
+      case 'Escape':
+        document.dispatchEvent(eventSearchModalCloses);
+        break;
+    }
+  });
+
+  appInitialized = true;
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+
+  typesenseHandleSearchModal();
+}
+
+// export function onRouteUpdate({ location, previousLocation }) {
+//   // Only first time when app loads
+//   if (previousLocation === null) {
+//     console.log("Only first time when app loads");
+//   }
+// }
+```
+
+
+
+
+---
+title: Source: clientModules/showLevels.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_showLevels.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_showLevels.js.md
+---
+
+# Source: clientModules/showLevels.js
+
+```
+/**
+ * @file This file controls the visibility of content on a webpage based on a "level" parameter. This parameter can be set either through the URL or via localStorage. The script also creates buttons that allow users to manually set the level.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-02-04
+ */
+
+const levelButtonsAndInfoClassNames = 'show-level-buttons-info-container';
+
+// define the message to be shown for each level
+const infoMessage = {
+  level1: `Level 1`,
+  level2: `Level 2`,
+  level3: `Level 3`,
+};
+
+// define the css class names for the show level button and the active button
+const showLevelButtonClass = 'show-level';
+const showLevelButtonActiveClass = 'button--active';
+
+// main function to show different levels
+const showLevels = (targetElements) => {
+  // Code should only run in the documentation section
+  //TODO: should this not be: only in the glossary section?
+  const inDocSection =
+    window.location.href.indexOf('/docs/') > -1 ? true : false;
+
+  // get the query parameters from the current URL
+  let strAllQueryParameters = window.location.search;
+  let allQueryParameters = new URLSearchParams(strAllQueryParameters);
+
+  // get the 'level' parameter from the URL
+  let urlLevel = allQueryParameters.get('level');
+
+  // check if the 'level' parameter from the URL is valid (1, 2, or 3)
+  let urlContainsValidLevel = false;
+  if (urlLevel === '1' || urlLevel === '2' || urlLevel === '3') {
+    urlContainsValidLevel = true;
+  }
+
+  // check if the 'level' parameter from the localStorage is valid (1, 2, or 3)
+  let localStorageContainsValidLevel = false;
+  if (
+    localStorage.getItem('level') === '1' ||
+    localStorage.getItem('level') === '2' ||
+    localStorage.getItem('level') === '3'
+  ) {
+    localStorageContainsValidLevel = true;
+  }
+
+  // function to remove the active class from all show level buttons
+  const resetShowLevelButton = () => {
+    const showLevelButtons = document.querySelectorAll(
+      '.' + showLevelButtonClass
+    );
+    showLevelButtons.forEach((button) => {
+      button.classList.remove(showLevelButtonActiveClass);
+    });
+  };
+
+  // function to update the URL with the current parameters
+  const setURL = () => {
+    window.history.replaceState(
+      '',
+      '',
+      window.location.protocol +
+      '//' +
+      window.location.host +
+      window.location.pathname +
+      '?' +
+      allQueryParameters.toString()
+    );
+  };
+
+  // function to show or hide paragraphs depending on the given level
+  const setParagraphs = (level) => {
+    const textBlocks = document.querySelectorAll(targetElements);
+    textBlocks.forEach((p) => {
+      if (p.dataset.level !== undefined) {
+        // hide all items
+        p.querySelector('.accordion-collapse').classList.remove('show');
+        if (p.dataset.level <= level) {
+          // show items with level equal or lower than level
+          //TODO: it works, but there must be a better way to do this
+          p.querySelector('button').click();
+        }
+      }
+    });
+  };
+
+  // function to create buttons for showing different levels
+  const createShowLevelButtons = () => {
+    if (
+      inDocSection &&
+      document.querySelector('.show-level-buttons-info') === null
+    ) {
+      // insert level selection buttons into the HTML
+      let htmlString =
+        `

+         
Choose knowledge level:
+          
+          
+          
+         

+         

+        `;
+
+      let mainArticle = document.querySelector('main article');
+      if (mainArticle) {
+        mainArticle.insertAdjacentHTML('afterbegin', htmlString);
+      }
+
+      // add event listener to each button
+      document.querySelectorAll('.show-level').forEach((button) => {
+        button.addEventListener('click', handleShowLevelButton.bind(button));
+      });
+    }
+
+    // Buttons should only be visible if there are elements with data-level
+    function checkDataLevelAttribute(targetElements, levelButtonsAndInfoClassNames) {
+
+      if (document.querySelector('main article') === null) return;
+
+      // Query all elements matching the target selector
+      const elements = document.querySelector('main article').querySelectorAll(targetElements);
+
+      // Flag to track if any element has the "data-level" attribute
+      let hasDataLevelAttribute = false;
+
+      // Loop through each element
+      elements.forEach((element) => {
+        // Check if the element has the "data-level" attribute
+        if (element.hasAttribute('data-level')) {
+          // Set the flag to true if an element has the attribute
+          hasDataLevelAttribute = true;
+          return; // Exit the loop early if attribute is found
+        }
+      });
+
+      // If no element has the "data-level" attribute
+      if (!hasDataLevelAttribute) {
+        // Get all elements with the specified class name(s)
+        const elementsWithClass = document.querySelectorAll("." + levelButtonsAndInfoClassNames);
+
+        // Loop through the elements with the class
+        for (let i = 0; i < elementsWithClass.length; i++) {
+          // Add the "hidden" class to each element
+          elementsWithClass[i].classList.add('hidden');
+        }
+      }
+    }
+
+    checkDataLevelAttribute(targetElements, levelButtonsAndInfoClassNames);
+
+  };
+
+  // function to handle the click event on a show level button
+  const handleShowLevelButton = (button) => {
+    // show or hide paragraphs based on the clicked button
+    setParagraphs(button.target.dataset.level);
+
+    // update the URL with the new level
+    allQueryParameters.set('level', button.target.dataset.level);
+    setURL();
+
+    // save the new level to the localStorage
+    localStorage.setItem('level', button.target.dataset.level);
+
+    // make the clicked button active
+    resetShowLevelButton();
+    button.target.classList.add(showLevelButtonActiveClass);
+  };
+
+  // create the buttons when the page loads
+  createShowLevelButtons();
+
+  // handle the case when the URL doesn't contain a valid level but the localStorage does
+  if (
+    urlContainsValidLevel === false &&
+    localStorageContainsValidLevel === true
+  ) {
+    // update the URL with the level from the localStorage
+    allQueryParameters.set('level', localStorage.getItem('level'));
+    setURL();
+    setParagraphs(localStorage.getItem('level'));
+
+    // make the corresponding button active
+    if (
+      document.querySelector(
+        '.show-level[data-level="' + localStorage.getItem('level') + '"]'
+      )
+    ) {
+      document
+        .querySelector(
+          '.show-level[data-level="' + localStorage.getItem('level') + '"]'
+        )
+        .classList.add(showLevelButtonActiveClass);
+    }
+  }
+
+  // handle the case when the URL contains a valid level
+  if (urlContainsValidLevel) {
+    // show or hide paragraphs based on the level from the URL
+    setParagraphs(urlLevel);
+
+    // save the level from the URL to the localStorage
+    localStorage.setItem('level', urlLevel);
+
+    // make the corresponding button active
+    if (
+      document.querySelector(
+        '.show-level[data-level="' + localStorage.getItem('level') + '"]'
+      )
+    ) {
+      document
+        .querySelector(
+          '.show-level[data-level="' + localStorage.getItem('level') + '"]'
+        )
+        .classList.add(showLevelButtonActiveClass);
+    }
+  }
+};
+
+// function to call when the route changes
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  // if (location.pathname === previousLocation?.pathname) return;
+  showLevels('div, tr');
+}
+// export function onRouteUpdate({ location, previousLocation }) {
+//   // Don't execute if we are still on the same page; the lifecycle may be fired
+//   // because the hash changes (e.g. when navigating between headings)
+//   // if (location.pathname === previousLocation?.pathname) return;
+//   showLevels('div, tr');
+// }
+```
+
+
+
+
+---
+title: Source: clientModules/showGPTsummary.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_showGPTsummary.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_showGPTsummary.js.md
+---
+
+# Source: clientModules/showGPTsummary.js
+
+```
+/**
+ * @file This file adds a GTP generated summary to the top of the page.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-05-17
+ */
+
+import overview from '@site/static/json/overview.json';
+
+const showGPTsummary = () => {
+  // TODO: fix bug where the summary is added multiple times when navigating between pages
+  // TODO: endless loop when navigating between pages too fast
+  function typeWriter(selector, strText, interval) {
+    let text = document.querySelector(selector),
+      i = 0,
+      clear,
+      pauseBeforeStart = 60,
+      finalString = '';
+    text.innerHTML = '';
+    clearInterval(clear);
+
+    function createTextString() {
+      for (let i = 0; i < strText.length; i++) {
+        finalString +=
+          "';
+      }
+    }
+
+    function typeText() {
+      let counterId = '#n' + i;
+
+      document.querySelector(counterId).style.visibility = 'visible';
+      i++;
+
+      if (i === strText.length) {
+        clearInterval(clear);
+      }
+    }
+    createTextString();
+
+    document.querySelector(selector).innerHTML = finalString;
+
+    setTimeout(function () {
+      clear = setInterval(typeText, interval);
+    }, pauseBeforeStart);
+  } // end typeWriter
+
+  const heading = document.querySelector('.markdown h1:first-child');
+
+  if (heading) {
+    // Find the column number of the column with the name 'Shortened version static copy'
+    const summaryColumnName = 'Shortened version static copy';
+    // loop through the first entry of the overview.json and find the column number of the column with the name 'Shortened version static copy'
+    let summaryColumnNumber;
+    for (let i = 0; i < overview.values[0].length; i++) {
+      if (overview.values[0][i].trim() === summaryColumnName) {
+        summaryColumnNumber = i;
+      }
+    }
+
+    // Find the column number of the column with the name 'Term'
+    const textColumnName = 'Term';
+    // loop through the first entry of the overview.json and find the column number of the column with the name 'Term'
+    let textColumnNumber = -1;
+    for (let i = 0; i < overview.values[0].length; i++) {
+      if (overview.values[0][i].trim() === textColumnName) {
+        textColumnNumber = i;
+      }
+    }
+
+    overview.values.forEach((row, index) => {
+      if (index < 1) return;
+
+      // Add a paragraph with the summary directly below the heading
+      if (
+        row[summaryColumnNumber] !== 'NO INPUT' &&
+        typeof row[summaryColumnNumber] !== undefined
+      ) {
+        if (heading.innerText === row[textColumnNumber]) {
+          const summaryContainer = document.createElement('div');
+          summaryContainer.classList.add(
+            'summary-container',
+            // 'alert',
+            // 'alert--info',
+            'margin-bottom--lg'
+          );
+          summaryContainer.setAttribute('role', 'alert');
+          heading.after(summaryContainer);
+
+          const domSummaryContainer =
+            document.querySelector('.summary-container');
+
+          const summaryHeading = document.createElement('h2');
+          summaryHeading.classList.add('summary-heading');
+          summaryHeading.innerHTML = 'AI–generated Summary';
+          domSummaryContainer.appendChild(summaryHeading);
+
+          const summary = document.createElement('p');
+          summary.classList.add('summary');
+          summary.innerHTML = row[summaryColumnNumber];
+          domSummaryContainer.appendChild(summary);
+
+          // typeWriter('.summary', row[summaryColumnNumber], 30);
+        }
+      }
+    });
+  }
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+  showGPTsummary();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/showDefinitionsPopUpOnClick.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_showDefinitionsPopUpOnClick.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_showDefinitionsPopUpOnClick.js.md
+---
+
+# Source: clientModules/showDefinitionsPopUpOnClick.js
+
+```
+/**
+ * @file This file shows popups with definitions when hovering over links.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-03-05
+ */
+
+import tippy from 'tippy.js';
+// import 'tippy.js/themes/light.css';
+import 'tippy.js/themes/light-border.css';
+// import 'tippy.js/themes/material.css';
+// import 'tippy.js/themes/translucent.css';
+import overview from '../static/json/overview.json';
+
+var findTerm = (function () {
+  let termsWOTmanage = overview.values;
+
+  // Find the position of the column "Term" in the array, by looping through the first row
+  let termArrayPosition = 0;
+  let textArrayPosition = 0;
+
+  // Loop through the first row and find the position of the column "Term"
+  for (let i = 0; i < termsWOTmanage[0].length; i++) {
+    if (termsWOTmanage[i][termArrayPosition] !== undefined) {
+      if (termsWOTmanage[0][i].trim() === "Term") {
+        termArrayPosition = i;
+      }
+      if (termsWOTmanage[0][i].trim() === "text") {
+        textArrayPosition = i;
+      }
+    }
+  }
+
+  function find(term) {
+    for (let i = 0; i < termsWOTmanage.length; i++) {
+      // console.log('termsWOTmanage[i][termArrayPosition]: ', termsWOTmanage[i][termArrayPosition]);
+      if (termsWOTmanage[i][termArrayPosition] !== undefined) {
+        if (termsWOTmanage[i][termArrayPosition].trim() === term.trim()) {
+          return termsWOTmanage[i][textArrayPosition];
+        }
+      }
+    }
+    return "No definition found.";
+  }
+
+  return {
+    find: find
+  };
+}());
+
+const showDefinitionsPopUpOnClick = () => {
+  if (window.location.href.includes("/docs/glossary") === false) {
+    console.log("Stopping");
+    return
+  }
+
+  // All links in the main text of the article that are not anchors
+  let links = document.querySelectorAll(
+    'article .markdown a[href]:not([href^="#"])'
+  );
+
+  /**
+   * JS function that takes a string (a url, but it can be relative or full, we don't know) and:
+   * if there is no “/” at the end:
+   * finds everything after the last “/”
+   * if there is a “/” at the end:
+   * removes this “/” and then finds everything after the then last “/”
+   */
+  function extractLastPathComponent(url) {
+    // Remove trailing slash if it exists
+    if (url.endsWith('/')) {
+      url = url.slice(0, -1);
+    }
+
+    // Find everything after the last "/"
+    const lastSlashIndex = url.lastIndexOf('/');
+    const result = url.slice(lastSlashIndex + 1);
+
+    return result;
+  }
+
+  const definitionButtonClassName = 'definition-button';
+
+  links.forEach((item) => {
+    // Get the host of the link
+    let linkHref = new URL(item.href, location).host;
+
+    // If the link is internal
+    if (linkHref === window.location.host) {
+      let term = extractLastPathComponent(item.href)
+      let text = findTerm.find(term);
+
+      // add an inline button after the link
+      let button = document.createElement('button');
+      button.innerHTML = '+';
+      button.classList.add(definitionButtonClassName);
+      item.after(button);
+
+      tippy(item, {
+        triggerTarget: item.nextElementSibling, // button
+        trigger: 'click',
+        arrow: true,
+        // arrowType: 'round',
+        theme: 'light-border',
+        allowHTML: true,
+        content:
+          '
' +
+          text +
+          '
Visit link to see more.
',
+      });
+    }
+  });
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+  showDefinitionsPopUpOnClick();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/scrollHorizontallyToKeyWordInSearchResults.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_scrollHorizontallyToKeyWordInSearchResults.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_scrollHorizontallyToKeyWordInSearchResults.js.md
+---
+
+# Source: clientModules/scrollHorizontallyToKeyWordInSearchResults.js
+
+```
+/**
+ * @file This file scrolls every search results that shows code in a < pre > element horizontally to the first < mark > element in the < pre > element.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-08-09
+ */
+
+function scrollToMarkElementInPre() {
+  // Find all 
 elements on the page
+  const preElements = document.querySelectorAll('pre');
+
+  // For each 
 element
+  preElements.forEach(pre => {
+    // Find the first  element
+    const mark = pre.querySelector('mark');
+
+    if (mark) {
+      // Get the position of the  relative to its parent 
+      const startPosition = mark.getBoundingClientRect().left;
+      const parentStart = pre.getBoundingClientRect().left;
+
+      // Calculate the offset
+      const scrollOffset = startPosition - parentStart;
+
+      // Scroll the parent 
 horizontally
+      pre.scrollLeft = scrollOffset;
+    }
+
+  });
+}
+
+function addRandomArrowClassToMarkElement() {
+  const markElements = document.querySelectorAll('mark');
+
+  markElements.forEach(item => {
+    // Add a random arrow to the  element. A little bit of fun. Check the css file for the arrow variants.
+    const variant = Math.floor(Math.random() * 19) + 1;
+    item.className = '';
+    item.classList.add('variation' + variant);
+  });
+}
+
+const makeKeywordsStandOut = () => {
+  // Select the node that you want to observe
+  const targetNode = document.getElementById('hits'); // Works, presumable because it's harcoded in the html
+  // const targetNode = document.querySelector('.ais-Hits-list');// Does not work
+
+  // Create an observer instance with a callback function
+  var observer = new MutationObserver(function (mutationsList) {
+    for (var mutation of mutationsList) {
+      if (mutation.type == 'childList') {
+        // console.log('Content of the target node has changed.');
+        scrollToMarkElementInPre();
+        addRandomArrowClassToMarkElement();
+      }
+    }
+  });
+
+  // Configuration of the observer:
+  var config = {
+    childList: true,  // observe direct children addition/removal
+    attributes: false,  // don't observe attribute changes
+    characterData: true,  // don't observe text changes
+    subtree: true  // observe any descendant changes
+  };
+
+  // Start observing the target node with the configured parameters
+  observer.observe(targetNode, config);
+
+  // Later, you can stop observing
+  // observer.disconnect();
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  // if (location.pathname === previousLocation?.pathname) return;
+  makeKeywordsStandOut();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/insertVideo.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_insertVideo.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_insertVideo.js.md
+---
+
+# Source: clientModules/insertVideo.js
+
+```
+/**
+ * @file This file selects elements with a data-youtubeid attribute and inserts a YouTube iframe into each. The iframe's src is set to the video URL using the youtubeid and starttime data attributes of the element.
+ * @example < div className="youtube-video" data-youtubeid="RE2QClKir1E" data-starttime="23"> transforms into an iframe.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-02-07
+ */
+
+const insertVideo = () => {
+  const refs = [...document.querySelectorAll(`[data-youtubeid`)];
+
+  refs.forEach((item) => {
+    let youtubeEmbed = ``;
+
+    item.insertAdjacentHTML('afterbegin', youtubeEmbed);
+  });
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+  insertVideo();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/insertSubtitles.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_insertSubtitles.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_insertSubtitles.js.md
+---
+
+# Source: clientModules/insertSubtitles.js
+
+```
+/**
+ * @file This file handles the display of subtitles for a video player. It takes no direct input, but it relies on the presence of specific HTML elements on the page, such as a container for the subtitles and a video element.
+
+The purpose of this code is to extract the start and end times of each subtitle from the text content of HTML paragraph elements (< p >), and then display the corresponding subtitle text in the subtitle container when the video playback time falls within the start and end times of that subtitle.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-02-12
+ */
+
+const handleSubtitles = () => {
+  let counter = document.querySelector('.counter');
+  let subtitlecontainer = document.querySelector('.subtitlecontainer');
+
+  const convert = (timestamp) => {
+    //https://stackoverflow.com/a/9640384 modified. Minutes are worth 60 seconds. Hours are worth 60 minutes:
+    return +timestamp[0] * 60 * 60 + +timestamp[1] * 60 + +timestamp[2][0];
+  };
+
+  if (subtitlecontainer !== null) {
+    const paragraphs = document.querySelectorAll('p');
+    let paragraphIndex = [];
+
+    paragraphs.forEach((p) => {
+
+      const matchStartTime = p.innerText.match(/[0-9]:[0-9][0-9]:[0-9][0-9].[0-9][0-9][0-9]/);
+      const matchEndTime = p.innerText.match(/,[0-9]:[0-9][0-9]:[0-9][0-9].[0-9][0-9][0-9]/);
+
+      if (matchStartTime && matchEndTime) {
+        const strStartTime = matchStartTime[0];
+        const strEndTime = matchEndTime[0].slice(1); // slice the separator, a comma
+
+        // start time
+        let arrStartTime = strStartTime.split(':'); // split it at the colons
+        arrStartTime[2] = arrStartTime[2].split('.'); // split at the dot
+
+        // leave the miliseconds after the dot
+        let secondsStartTime = convert(arrStartTime);
+
+        // and place them back after the seconds are dealt with
+        secondsStartTime = secondsStartTime + '.' + arrStartTime[2][1];
+
+        // end time
+        let arrEndTime = strEndTime.split(':'); // split it at the colons
+        arrEndTime[2] = arrEndTime[2].split('.');
+
+        // leave the miliseconds after the dot
+        let secondsEndTime = convert(arrEndTime);
+
+        // and place them back after the seconds are dealt with
+        secondsEndTime = secondsEndTime + '.' + arrEndTime[2][1];
+
+        paragraphIndex.push({
+          text: p.innerHTML.slice(24), // remove the timestamps and the trailing space
+          start: secondsStartTime,
+          end: secondsEndTime,
+        });
+      } else {
+        console.error('No match found in paragraph text');
+      }
+    });
+
+    document.querySelector('video').addEventListener('timeupdate', (event) => {
+      counter.innerText = event.target.currentTime;
+      paragraphIndex.forEach((p) => {
+        event.target.currentTime > p.start &&
+          event.target.currentTime < p.end &&
+          subtitlecontainer.innerHTML !== p.text
+          ? (subtitlecontainer.innerHTML = p.text)
+          : null;
+      });
+    });
+  }
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+  handleSubtitles();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/imageFullSize.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_imageFullSize.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_imageFullSize.js.md
+---
+
+# Source: clientModules/imageFullSize.js
+
+```
+/**
+ * @file This file adds functionality to display images in full-size on a web page when clicked. The functionality is implemented via a class added to the image element.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-09-11
+ */
+
+const imageFullSize = () => {
+  const imageFullSizeClass = 'image-full-page';
+
+  // All images get a click event listener via event delegation
+  const markdownElement = document.querySelector('body');
+  // const markdownElement = document.querySelector('.markdown');
+
+  function removeContainer() {
+    let container = document.querySelector('.image-container-full-page');
+    if (container) {
+      document.body.removeChild(container);
+    }
+  }
+
+  if (markdownElement) {
+    console.log("event listener added");
+    markdownElement.addEventListener('click', (event) => {
+
+      // // A: Images in search results not included
+      // if (event.target.tagName === 'IMG' && event.target.closest('.markdown')) {
+
+      // B: Images in search results included
+      if (event.target.tagName === 'IMG') {
+
+        // To be implemented: also account for SVG, path, circle, rect
+        // if ((event.target.tagName === 'svg' || event.target.tagName === 'path' || event.target.tagName === 'circle' || event.target.tagName === 'rect') && event.target.closest('.markdown')) {
+
+        let image = event.target;
+
+        if (document.querySelector('.image-container-full-page') === null) {
+          // Add container if it doesn't exist
+
+          // Clone the image element
+          const clonedImage = image.cloneNode(true);
+
+          // Create a new div element with the class .full-page-image-container
+          const container = document.createElement('div');
+          container.classList.add('image-container');
+          container.classList.add('image-container-full-page');
+
+          // Add the cloned image to the new container div
+          container.appendChild(clonedImage);
+
+          // Append the new container div to the body
+          document.body.appendChild(container);
+
+          // Add event listener to the new container
+          container.addEventListener('click', function containerClickEvent() {
+            container.removeEventListener('click', containerClickEvent); // remove this click listener
+            removeContainer();
+          });
+
+        }
+
+        // Toggle the full size class on the original image
+        image.classList.toggle(imageFullSizeClass);
+      }
+    });
+
+    // Add keydown event listener to handle the ESC key
+    document.addEventListener('keydown', (event) => {
+      if (event.key === "Escape") {
+        removeContainer();
+      }
+    });
+
+  } else {
+    console.log("Element with class '.markdown' not found.");
+  }
+};
+
+if (typeof window !== 'undefined') {// should run on client only
+  document.addEventListener('DOMContentLoaded', (event) => {
+    imageFullSize();
+  });
+}
+```
+
+
+
+
+---
+title: Source: clientModules/horizontalScrollHint.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_horizontalScrollHint.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_horizontalScrollHint.js.md
+---
+
+# Source: clientModules/horizontalScrollHint.js
+
+```
+/**
+ * @file This file contains a function that adds a visual hint to a web page, indicating that the content can be scrolled horizontally. The hint consists of an image of a hand with a pointing finger and the text "Scroll to the right." This hint is shown when the content inside the targeted HTML element is wider than the visible area, indicating that horizontal scrolling is possible.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @license MIT
+ * @see https://example.com/more_info_about_calculator for more information about the usage
+ * @since 2022-01-01
+ */
+
+const horizontalScrollHint = (element) => {
+  const el = document.querySelector(element);
+
+  // Credits: Hand cursor icons created by Icon Bolt - Flaticon
+  const fingerHorizontalScrollingImage =
+    'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAgAAAAIACAYAAAD0eNT6AAAACXBIWXMAAA7DAAAOwwHHb6hkAAAAGXRFWHRTb2Z0d2FyZQB3d3cuaW5rc2NhcGUub3Jnm+48GgAAIABJREFUeJzt3Xe4XVWZ+PHvTU8IJBB6D6ELGgUVRRTGhgoqjugAIvqzYMGCOuo4o6KDzMDYkBkcxRl7F50BRAEdpFgQpBO60iFAIAmB9NzfH+tecxNu2efstdYu5/t5nvUkhHvXftc5Z+/9nrVXAUmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJElqs76qA5CkHrE3cAzwbGAzYFNgGXArcAFwBvBQZdFJapWtgdnA+KoDkXrce4HVQP8oZQHw8qoClNR8WwNfJHyTGLywPAr8O7B5hXFJvWp3YCWj3/wHyyrguGrClNRkbwEWM/LF5R5gbmXRSb3pNIrd/IeWL2HPnaQCxgGnUuzCcjewRTVhSj3pFjpPAPqBc4ANK4hXUkNMAr5PZxeWsyqJVOo9Ewnd+t0kAP3AtcAO2aOWVHvTgHPp/KKyBti5gnilXjOH7m/+g+U+YN/cgUuqr5nApXR/UTkmf8hSz9mG8glAP/A4cFjm2CXV0NbAdZS7oDjSWEpvIsVnAIxVVhOmE0rqUbMJC4eUvZi8NHfgUo/q5jHdaOVUwsBfST1kLnA/5S8gi4DpmWOXetURxE0A+oEzgak5GyGpOgcQFvSJcfE4JXPsUi+bTJh+GzsJuBjYJGM7JFXgEOAJ4lw07gI2yhu+1PPeTfwEoJ/wONAZPVJLHQWsIM7FYgWwf97wJRF6AW4iTRJwH/CMfE2RlMP7CHP2Y10o3pI3fElDPI+xNwTqtjwGvDhfUySl9BHiXiBOyBq9pOGcQpoEoB9YThhwKBXSV3UAepI+4PPA+yPW+V3gaMJFQvU1BdiHsOrbzsC2rJ2t8RjwAHADcBlwJaF3SM0yjrAU9ysS1d8PfBj4bKL6JSXSzbr+Y5VfD9SretoI+H/Az4FlFH9fHwZOJyQMapaZwNWk6wnoB07CL3hSY0wDfkHci8C1wIycjVBhuwD/SfhmX/Z9PhcHgTXNZsA80iYB3wQm5GqQpO5sTLl1/YcrdxO6kFUvOxAuzGV2iBuurCI8OnJxmObYBvgzaZOAs/AzIdXWVpRf13/98giwR85GaExTCQM7Y3zjH63Mw/e+SeYQ1uZI+Zm4hPDYQVKNbA/cQtyTfTnwNzkboTHtQ5z9G4qWBcBzsrRMMWxPujUCBsv1hE3EJNXArsTP/NcQFg5SfbyHzgb3xSpLMBFsks0JMztSfib+DOyUq0GShrcncC/xT/DjczZCo+oj7ZzvIuVx4LmpG6poZgAXkfYzcRewW64GSVrXPsBDxD+xT8/ZCI1qPPAdqr35D5b5wHZpm6uIJhN2+kv9mZibq0GSggMIW/HGPqF/hPuD18m/U/2Nf2i5jHBjUTOMB75G2s/Eo7gvSM9zoYh8Xgr8lDDfP6ZLCWuAL4tcr7rzYeDkqoMYxhfxEVFKGxFu3BNZu3rjhoR5+BsMlOmEbv4NCNeBGQM/M23g3zYe+LeNBv7cMnHMjwN/C5yX+DiqKROAPA4lfEufErneeYRehUci16vuHABcSLgR1E0/YVvpc6sOJJIJhJvn4A13EuEmOplwQ51CmHo5deDvfaydCjf4/2DtjXuwPgbqmbTe7wzWw8C/9Q05VpOtAA4nrBegHmMCkN5RwDeIvyLXvYQBXndFrlfdGVzedYeqAxnFg8BTCc+A62QcYe+D3QfKzsAswms6g/DNePBmPJ5w01Y8y4CXAb+pOA5lZgKQ1psIz/JifyNcRPi2eV3kelOZQfgGNY1wER/8ZrbxkL/PHPj/U1nbTTqJdb95rW8RYerjcsICO48Qnm0OloeAewj7pa+I36x1nAG8NfExYvgB9dgxbjfCTecFhM/yrGrD6XmLgacTpgqqR5gApPMW4KvEH5y3HDiYtNn6BoTu0A1Z+zxyw/X+bSah63Xov21IuGFPH/jvqQN1Va2fsJPevcCdhMTpV8BvI9U/F7iCdF3/S4m7nOvBVPPcdyvgDYQE5OkVHF+juxg4CHeZ7BkmAGm8HfgyaUbmnwT84zD/PpFwA57J2pvxYJnBujfx6cP829Cbfa/MKLgeeB/wfyXruQB4Uflw1nEP8N+EgaM3Ap8BPkicc/bPwF6ExCKXIwi9JHVICDWyIwi9RJK68E5CBp1q+s4Cwrf/PwG3E7q5lyY8XtvLGuDE4d7Igp4eOZ75wNsICd36DiGs8BfjOJ8q0eZOHUj8zY8sacofhn8LJY3lPaS9+VvSlU8P834W8Y2IMfyCsE3saJ5LGN9Q9lhLSD/NDEIiE3u/C0vass2w76SkEb0fb/5NLqsJA9I6sRHx1vn/BsXHEDyTMIe77DFzrB55eIQ4LXnLq4Z9JyUN6wNUf9Jaypc/rv/GjuHvIh33QjofQHg45RPOFcAuHR63Uz8rGaMlf3nzsO+kpCf5CNWfsJZ45RkU94MIx1sMzO7gmEP9a4Tjn9HlsYuYiONTmliOHO7NlLSu91L9yWqJWz5AMeMJ6w6UPd77Cx5vOJMJq0GWOf4ywvS8FLYvGZulmvLU4d5MtU+vTPdK4VnA56oOQtHtUfDnnk5YyKiMhYSForq1nLD4UH+JOiZTLgkZzeaJ6lU6CwjTY9UDTAC69zniL++r6hVdcOeFEY71NcJo/DJ+R3jOXsbbSbOm/a3kXWtA5X0VFwLqGSYA3Xkm8Lyqg1ASjxb8uYMiHOvMCHUAnEC5i/ZM4LVxQlnHIsICRmqGJcCpVQehfEwAuuMgmfa6rcDP9BEeAZWxiLB8cAzXAWeXrOMtMQIZxkmEb5Wqvw9Rv42ipNopO/DKUt+yO2ObE+E45xQ4TideUTKeNaSdEvhmQtJT9ftrGb6chUvD9xx7ADo3jbCTmdrnj8BNBX5u3wjHij3Q6pfA3SV+v4+wrkEqXweeAnyJ8uMeFNc84GhCIqAe4iC2zm2PiVNbfazgz82NcKxbItQx1Grgh4Ru3G4dBvxznHCGdQ9h86UPE2ZbPIWwKdE2rN3y+QnC7IamWkx4L4oaRxiDMVgGN+nahLGXhY5hAfBKQu+MpDE8leq76yzxyxco7swIxzuwg+MVdVCEuHZMEJc6NwO4hrSf+RXEGcwq9YxNqP5mZYlbvk1nvWHXRjjmnh0cr6iJhLUFysSVak0AFTcVuIT0n/tjczVIapOLqf6mZSlfFhNueJ0MfuojzkY8qbp3/6dkXGVnE6ic8ZR/D4uUTnq8JA3xTEL3WdU3MEvnZRVh2tzH6W473K0ixLCGdONvPloytoV0vjGR4jmN9OfAL3H8l/BD0K3LCYOlut1Dfix3EboAHx/h//cRBgwVsSHF3+eN6OziP4XiK+dBZ3EPmkBow6DBmxSEwVaLCTfURQNlCfDYwN8fAh4GHiTMb34I+DNh/ftubVHidwc9TkhEUuh0R8P1zSAscxxrjQIV9wnguMTHuB54Hek+f1JPmAD8nvjZ+T2UX2Ne6byY8u/xvQnj24jy2wQfnzA+DW9wT4eU5T5gh1wNktpuJ8I30Ngn6vnYDVtXg/Oly5R5iWO8o2R830wcn9Z1KLCStDf/x+hsq2tJBbyNNCfsKTkbocJibAH9h8QxnlsyvmsSx6e15hJuzilv/quAV+VqkNRrziLNifvmnI1QIf9I+ff1vMQxfq5kfCsI2wQrra0I431S3vz7ST+uQOppmxMGmcU+cZ8gDMhSffwL5d/XHyeOMcbz5L0Tx9jrpgKXkf7m/2+5GqTmcUnbOB4EjiGccDFNJcwJzrEkqIrZcOwfGVPqZVdvjFDHThHq0PD6gO9QfkfJsZwJfCTxMdRgJgDx/BL4rwT1bg/8AKds1sX0CHUsjlDHaGIMMjQBSOfTwGsSH+MPwBsJM0IkZTAduJU0XXmfzdgOjSzGPgAnZIjzgZIxfilDjL3oSMpP0xyrXI9TiaVK7EPYzSzFiX1MxnZoeOdR/n38YIY4LywZ4zkZYuw1+wNLSXvzv4fQayiNyUcA8f2JsMxsCl/GubxVa8IjACj/GGB2lCg0aFvgZ6zd9jiFR4GXEmYWSKpIH+EbVIoM/w5g02wt0fpi7AT4+gxxHlcyxqV0tkmSRjYO+DVpv/kvBQ7I1SBJo9scuJ80J/sFuFJgVf5M+ffvZRnifFGEOLfJEGcv+CRpb/6rgFdna42kQl5KugE//5KxHVrrQcq/d/tniHN2hDj9RlneXqQbEzRY3pOtNZI68lnSnPRrCLt6Ka8nKP/e7ZUhzgmU37L6jRnibLNxpNkwbGj5VLbWSOrYRMKc3BQn/2PkuZkoGEecHp1co7RvKxnnCZnibKs3k/bmf0a+pkjq1i6k2/DjVmBmvqb0tA2J857ler/KTll0V8DuTQHuJN3N/2xcHExqjGNIdzFw++A8tqT8e7WGfO/Vl0vGekmmONvofaQ7338LTMvXFEkxfIt0FwWfBaa3M+Xfp8cyxvuhkrHemzHWtkm10c88YFbGdkiKZAPgBtJcGNYAR+RrSk96GuXfp5w31cNKxrqGsCGVOjOJ8gMwhyuu8ic13J7AEtIkAY8De+RrSs95LuXfoxg79RUVI2HZLWO8bbEZ8c/thYT3U4rGpYDzmwe8LVHd0wjbjE5MVH+va8oywINuj1CH3zg7F3u532XAocA1ketVjzMBqMb3SbN1MIS9Ao5LVHev2yBCHTkTgCXA/JJ17BAjkB4T87q6mvBozwGZis4EoDrHAVclqvvjwCaJ6u5lTesBgPIbw9gD0Ln7CMvzxvAu4H8i1SWtwwSgOsuAvyPNqPCNCdOQFFeMHoBFEeroxD0lf98EoHMrgSsj1PMJ4KsR6pGGZQJQrVuAtyaq+53A5ER196qmPQKA8gmAjwC688OSv/8V4J9jBCKNxASgej8iLNgS22bAKxPU28ua+Aig7LRDewC681W6H4T5I+DdEWORhmUCUA/HE6fLcH3PSFBnL4vRA5BzISAo3wOwLV4nurEEOJjOR+6fARxFGPwnJeWJXQ/LgdcAD0eud+fI9fW6XnwEMImwBLI6dxuwD/Bi4FTgj8D9hHn9Qy0HfjHwc28n3gBCaVRuJlEfdwJvAM4lXmLmhTuuJj4CKJsAQBgHcF+EenrRauBXA2WojQnrBUwlvEcrMscl2QNQM+cRRv7GknvEeds1tQdg/W+cnXIcQHyPEnoD/ow3f1XEBKB+TgLOjFSXCUBcTUwAllP+0ZIzAaQWMgGon37gzcRZM/6GCHVorSY+AgDXApA0DBOAenqMMCiw7M3ivAixaK0m9gBA+amA9gBILWQCUF83EUYEd+te0i013Kti9ADkngYI8GDJ3982ShSSasUEoN5+CHy+y989mbCfu+KJ0QPweIQ6OvVQyd/fJkoUkqSOTAAupLO9w+/EZYBTWEi5Pd1XA33Zo4YPdhnvYFmDnyepdewBqL9VwOuB6wv+/CLgcMLob8VVtgfgccpPyetG2UcAfcBWMQKRJHVuFvAzRv+mdgWwd1UBttxkyn2L7ifM+67CwR3EOFLZP3vUkpJyJcDmWAAcBjwfOIKwxOgswoIiNwI/Bn6Oa4inMjVCHVU8/4fyYwDAcQBS65gANM/FA0V5xXgGviRCHd0o+wgAYOsIdUiqEccASMVMiVCHPQCSasMEQComRg9AVQnAMsqvP2ACILWMCYBUTIwegKoeAYBrAUhajwmAVEyTewCg/IZAJgBSy5gASMU0eQwAhEWMynAQoNQyJgBSMU2eBQDlE4CpwCYxApFUDyYAUjG93gMAPgaQWsUEQCpmUoQ6nohQR7cWRajDBEBqERMAqZgYKwEui1BHt2IkAI4DkFrEBEAqJsYYgCoTAB8BSFqHCYBUTIxHACYAkmrDBEAqZmKEOkwAJNWGCYBUTIxzxQRAUm2YAEjFjI9Qx/IIdXTLWQCS1mECIBUTIwFoeg/AZsQZDCmpBkwApGJ8BAB9wJYR6pFUAyYAUjFN7wFYAqyMUI9rAUgtYQIgFdP0HgCAxRHqcByA1BImAFIxTe8BAGcCSBrCBEAqJsa5UuUsADABkDSECYBUjD0AwVYR6pBUAyYAUjEmAMHmEeqQVAMmAFIxMc6VGKPwy4ixGNBmEeqQVAMmAFIxMc6VNRHqKMMeAEl/ZQIgFVP25t0foY6yYvUA9EWoR1LFTACkYlaX/P2qb/4QpwdgErBRhHokVcwEQCqm7A28LQkA+BhAagUTAKkYewDWciCg1AImAFIxJgBrmQBILWACIBXTX/L363CuxRgECD4CkFqhDhclqQnK9gBMiBJFOfYASPorEwCpmLIJwHiqP99MACT9VdUXJKkpYjzDr7oXYAnlH2WAjwCkVjABkIop2wMAMDFCHWWsBh6PUI89AFILmABIxbShBwBCL0BZm0SoQ1LFTACkYlZFqKPqHgCIMxNg4wh1SKqYCYBUTIwegCkR6ijrsQh1mABILWACIBUTIwGYFqGOsmIkADPw2iE1niexVEyMQYB1SAAWR6hjHG4IJDWeCYBUTIwegKkR6igrRg8A+BhAajwTAKkYewDWZQIgNZwJgFSMYwDWNTNSPZIqYgIgFdOWHgAfAUgCTACkotqSAPgIQBJgAiAV5SOAdZkASA1nAiAVE6MHoA6zAOwBkASYAEhFtaUHIFYC4CBAqeFMAKRiHAOwLnsApIYzAZCKacsjAMcASAJMAKSiYjwC2CBCHWX5CEASUI/9yaUmsAdgXbF6AOYAuwGzgW2A8YTk4nHgjoFyBXBfpONJGmACIBXTljEAS4B+oK9kPd32AGwFvBo4CDgA2LLg780DzgXOAG7p8tiSJHXsIMKNs0z5Zfaoh7eY8m1Z3sHxNgbeA1xMSKTKHHcN4XXcr4t2S5LUsedT/qZ5cfaoh3cP5dvSz9hjGp4FfB14ItLx1k8EvkXoUZAkKZn9KX/Tujx71MO7kTg34W2GqbsPOBT4XaRjjFUeBl5R/iWRJGl4z6L8zeqG7FEP7zLi3Hz3GlLnOOAI4NpIdXfaG/BvhAGEkgpyEKBUzIoIddRhECDE3xL4UOAk1k0IcuoDPkSYUXAksCzDMbckPH6YxdoZEUuAe4EHB0qMqaNSMiYAUjErI9RRh2mAEG8tgJcBJwPPjVRfWYcB5wOvBBZGrHc68GLgBcBzgD0H/m00qwlJwDxCj8sfB8r9EeOSJGWwC+W7qmPdeMv6Jvm76XOW3wMblnyNJhB6Nv6X0KMQK7Y7gdOBF+IjC0lqhB0of/GP0YsQw2lUf5NOXS6kux6XScDbgNszxPgQYV2DfbqIU5KUydbEuehPyh34ME6i+ht0jnI2nX3LfglwU0Wx/ho4mPILNEmSItuUOBf6GbkDH8ZHqf7mnKt8ocDrsRFhvYKqY+0HriKsOSFJqokZxLnA12HhmndT/Y0uZzl2lNdib/J093dS1hDGaWw+StySpEymEufiPid34MM4mupvcjnLCob/Vn0oYUpk1fGNVB4hTGuUJFVoAnEu6k/JHfgwXk31N7fc5V5giyGvwdGEQZlVx1WknApMRJJUmbIb2fQDc7NH/WR/Q/U3tcHyJ+C9rJ1bPxnYEXg58EVgfsRj/YowKPBI4ryXOctFrJvASJIyWkr5C/kzs0f9ZM+k+hvao4Qb8Vij3qcC7yPODob9wM8IjwSqbn835XZguzFeL0lSAjFuQvtnj/rJdqPaG9ltwE4dxrwjYYR81TfhqsttmARIUnYPU/4CfmDuoIcRa02Dbsp9hEWVujGTsJxu1TfhqsttwLZdvobSX42rOgCpQWKs5FeHwVxVLUm8CngdYTncbiwEXkNYY7+XzQF+Tn02l1JDmQBIxcXYEbAOCcDjVLNT3WnApSXruAc4PkIsMTwKnAf8eKBcCDyQ6dhPJSwjLEnK4FbKd9++OnvUw1tI3m7r+YQV92IYB1yTOf7BsoawxPBzGHkA4+bAG4DvEebyp4zn/Z2+eCXMHPtHJKmd5lH+gn149qiHdzd5b5zviBz/+zPH3w8sofP3bwohGbgoUUwrgGd1GNNIphG2Pf4oIXm5jLB+wvpTJpcRHuNcAnwD+ABwED6SkNRiV1P+gl2Xld1uIN+N8wbCQkox7ZQx/sGbf9kpnPuRJhG4mu5f3y2B4wiPL5aXjGM5ISn4KLBrl/FIUi1dTvmL9THZox7e78l383x5gvj7yPcYYzVwWMTYX03cBY76gb/v4Ph9wAsJayKsihzH+onJe4FNOohNkmrpt5S/KL4te9TDO588N88LE7bhD5nacGqC2LckDCCMFeMSwloJYzmEOIlsJ2Up8BXsFZDUYL+h/MXwXbmDHsFPyHPxf17CNnwnQ/z3EW/w4vrGE56hx4r1h6Mc62nAxRGP1U1ZDZyJiYCkBorxrfl92aMe3tdJf8H/ReI2fCpDG45J3IZxhG/HsW6we65X/zTgC6Tt6u+0LANOxEGDkhrkHMpf/D6UPerhnUrai/waYN/EbUi9rfFfiD94cTgTgP+LFPP3htT7bODmSPWmKLcBzyj1yqkUFwKSiouxEuCkCHXE8Fji+s8Crkh8jD8nrv+zhG/Oqa0CjgDuj1DX64A9CD1Nl1Dv7vY5hHE1b606EEkayw8p/63nk9mjHt6HSfvtLseuh7MTxv8AYSfCnN4QKfaHItWTs5zK2DtDKjJ7AKTi2rIXAKTtAfglYaR5ajG+MY/kS4TR6zl9lziv26YR6sjtvYSxEN6TMvLFloqLsRdAXR4BpNwQ6DMJ6x5qGWGp3diWA19LUO9Y+sn32tXR2wivuz0BmZgASMW1ZTMgSNcD8BvKb/jTiRS9AD+luh0Hf07ano26ezPwkaqD6BUmAFJxbXoEkKoH4MRE9Y5kQYI6v5KgzqJWEdY36GWfISxYpMRMAKTi7AEY3e+BXyeodzSLItc3j7Bef5UuqPj4VRsHfBvYuupA2s4EQCquTT0AKRKA3N/+IX5Pxjci19eN3xIn2WyymVTbE9MTTACk4to0CPDRyPVdSfqV/4azMGJd/Yy+nG4uTwDXVR1EDRxCfbbPbiUTAKm4Nj0CeJi43zJPItxAc4vZk/Fb4K6I9ZWRepGjpjiF+pwzrWMCIBXXppUA+4E7I9V1I2Fr2SrETGK+H7Gusu6oOoAhbgT+CdiPsLVvHzAF2Bt4ByFxSmVH4I0J65ekQo6n/Ipn52SPemSxdtM7MnfgQ/zTKHF1UlYDm2eOfTTvpvrV+a4DXkaxefkvAK5OFMdt5NmToefYAyAV16ZBgAC/ilDHVcAPItTTrRjvCYQV+Kqa+z+cOyo89ipCYvV0wriOIo92LiJsPpRi4N4cQiKiyMyq1K0JwM7AToRuutnANoRlSDcldBUO7qM+DZhMuJAsJFy0lxCmcN0HzAfuJXRJ3wzcRHhGXTdtGgMAYW/204DpXf5+P6FXZE20iDoXa7OecyPVE8sdFR33EeA1dDcVcjnhkcCDwMdjBgUcBZwduU5JBYwD5hLW6/4vwi5vy0jb/fgwYT70icCrgC2Tt3Jsb6J8u3KuklfECXTfllPzh/sk7yHO5y311sWdmk7+Lv97gKdEij/2dtNPsPYLhaTEJhG2Fj2TcDPOfTEartxAuLAcQvffWss4qsN4hyuXZY96dNMI3fidtuMS8u+WN5xjKf+ePEA9H4cuIt+5tQDYM2LsE4ALI8d4VMT4JA1jO+Bz1H9L0WWEPeffCGyc5JV4ssMjxH1lplg7sS1wPcXbcBlhoZY6eDPl35MqNv4p4k7ynEvLgf0TxL8DYaGmWHF+L0GMkgjP7E8hbIFa9c29mwvYWYRHBSmfsb8qQqx1XeBlOmE8wHJGjn0V8GXCFLC6eDXl35NDs0ddzLXkOX/+PmEb3hcxzgU4bk2K7ijC4J+qb+Qxyv3AyYTBibG9PEJ8NyeIK6ZtCQP7zgFuAW4H/khIDnevMK6R7E+59+Mx6vEoYziXkP58OY+0jz8mET5DseI9IGGsUk/ZiHhzwetWVgE/JixeEsuLIsTlCm9xbU+59+Ob+UMu7GzSniMPkGdw7TERYz4pQ7xS6+1E+IZX9Y06R7kUeGmE1+z5EWK5O0IcWleZ3quDKoi3qJTJ+Rrg4EztmETomYsR9zWZYpZaay7xTsgmlUsod8F/ToQYHihxfA3vXLp7L66j2Cp3Vfl30p0LX8rYDoBPRox9u8yxS62xL2ExnqpvxlWWXwFP6+K12yfCsR/p4rga3dF09168vopgOzC4wVLsch8wI2M7IDxqiLV2yLGZY5daYTvCyV/1DbgOZRVh2dJO1n/fO8JxY+5ep2AqcCudvQ8XUs+5/0N9lDSf/arm03+rgxhHK2fmDlxqug1Jt1lHk8tCwgqH4wu8hrtHON6yAsdR5w4gLC9d5D24jzBHve5SbAh0IdU99ti3YIxjlQXUP3mTauVrVH+zrXO5DHjqGK/hThGOs3qMY6h7+zB2kns1Yd+KJjiSuJ/xFcRd7a8bnSw4NVp5Ru7ApaZ6CWHUb9U32bqXFYTnrpNHeB23jXQcFzNJ60DCoLP/IewncT5wOmGTmyZ9czyAuJ/vU/KGP6xY2zenXLyoZ9R5BKzimE5YQ3/7jMe8l7DgzQLCUqBLCVOBNhqIZ2tgV6pZz7+Ia4E38ORV+7Ygzij+aYTXRBrNDsTbFfBeYA+qH4OyM2G8Rlm/xC2CpTF9mLTfmlcBvwM+TZgn38mOXVsT5ud/krDveJ1mJywFPsC6SfLGkep2VzMVMYHQKxXjM3dE5thHcznl27OE8KVC0gg2IOzNneIGeSvwMcJNPJZxhO1I3wJ8A5ifKPZOyi9YO2Uq1hatm8Z4sdQTLqX85+031Ku39wPEOY9SbGAktUasE21ouRY4jDwXlHGEpXxPIt/L7BGLAAAXJklEQVTGKMOVGwgDxyZFqm+rmC+SWq1sD94SwuO2OtmBOOfR8bkDl5rkOuLeCL9Ctd1uOwIfoZoljOcTvnHEGEyZczyGmm1T4HG6/6y9M3/IhdxM+fPo29mjlhriKcS9AZ6eN/xR9RGW9P0uebcvfoI4CcDO8V8StVi3vQDnUK+u/6FOp/x5dEP2qKWG+Gfi3fguBybmDb+wTQhjERaQLxEoW/ZI8kqorcYDP6Szz9gV1Huw6d9S/jxaRRjnJGk9fyDeDevFmWPvxgzCbII6zSQYqYy14JC0vonAvwIrGfvz9QtgZjVhFrYJYVGssufSc3MHLtXdJOJ1jd+fOfayNiEMGoy18UiKsk+y1qvtngKcBjzMkz9X1xE2RmrKYkdXUP5cek/2qKWai7Fr3WC5MHPssexJ3F6QmOU5Cdut3rEDYSzM8wirVDbNFyl/Ln0te9Qt4pKk7dTNVrcjqesgorHMI4zafx9hPMS0asNZR13HU6hZ7hwoTXV1hDp2ilBHz2pKV5E6s0XEupo8ZW018HlCQnRtxbEMZQIgwTUR6mjKxk61ZALQTp3scT+W2cCciPVV4TZCN+nZVQcywARACtP4VpSsY1vsye6aCUA7bRa5vjasuPUY8Grg36oOBNcwlyDc/G8sWccE4l/veoYJgIp4G2H0cdOtISyqcixhAFFV7AGQghjjANxbo0smAO30ROT6JgFn0J7Py1cJgwOrYgIgBTdHqMMEoEttuaBrXbETAAhT196boN6qnAZ8vKJj+whACu6KUEfdFz2qLROAdlqQqN6Tadcc9hOBz1ZwXHsApODuCHVMjlBHTzIBaKebEtU7CfgxcacZVu3DwLmZj2kCIAUxEgB71LpkAtBOZUfWjmYb4JfAxgmPkVM/YfnUGF2RRZkASME9hPU6yjAB6JIJQDvdQvn5taOZC/wv9Vpdr4xHCEnAqkzH84IlBSuB+SXr8HzqkglAO60ALk18jAOAn9OeATgXA5/KdCx7AKS1Hij5+44B6JIJQHvleK59IPBbwqYkbXAycGuG45gASGstKfn79gB0yQSgvX6e6Th7Ar8H9s10vJRWkmdqoAmAtJYJQEVMANrrJuBPmY61FXAR8LeZjpfSj4ArEx/DC5a01mMlf99HAF0yAWi30zIeaxphiuAJNHcLYQizAk5OfAw3L5HWKtsDYI9al0wA2u0HlB9g04k+4JPA94ApGY8b25mEHQRTsQdAWqtsAmAPQJdMANptOfD5Co77d8D5NHeN7tWk7T0xAZDWerzk75sAdMkEoP1OJawLkNsBwB+A3Ss4dgzfJSRQKeRab0BqgvElf9+EuksmAO23Aji+omPPAS4BnlHR8ctYAJyVqO5FieqVmqjsmBjH1HTJBKA3nEsYD1CFTYFfA8+t6PhlfDdRvYsT1Ss1UdkbeNmlhHuWCUDveBvVPAqAsFrgBcCLKzp+t84nzdbKCxPUKTVV2QRgZZQoepAJQO9YAhxF2j0CRjON0KX+ioqO342lwK8S1Jtqu2apicomAI6p6ZIJQG+5grD9bVWmAD8FDq8whk79b4I6r0tQp9RUJgBSRmcQFrypqqwCjkneyjhmEboYY7V9CSbe0lA/oNw59bn8IbeDF6Le9C7CM/mqjAe+DrypwhiKWgD8JmJ91wJrItYnNV3Z9UIcA9AlE4DetJLQDT+vwhj6gK/SjDEBP4pY19UR65LaYJOSv+8sAKkL2xKWvK3yccATwPNTN7Sk6YS5+zHa+8rMsUt1dzflzqkTskcstcT2wF+oNglYCDw9dUNL+jLl27kImJo7cKnmllDuvMqxhbfUWrOBO6k2CZgP7Jq6oSXsTehqLNPGf80etVRvUyl/7fiH7FFLLTMbuJFqk4A7ge1SN7SEr9N92x4ENssfslRr21H+uvH32aOWWmgWcCnVJgE3AhunbmiXNgHuoPM2rcZn/9Jw9qP8NeP92aOWWmoq8BOqTQLOp74bfMwlPK4o2pZVwFsriVSqv9dR/nrx7uxRSy02DjiNapOAU5O3snu7EHY5HKsNNxO2RZY0vA9R/lpxdPaopR7wUcKiNVUlAXX+5twHvJwwLuA6woJBDxMeYXwTeA3l9zmX2u5Uyl8nXpU9aqlHHE3YQKiKBGAFcGDyFkqqys8of514QfaopR7yQuIthNNpeRjYKX0TJVXgT5S/RtR9DRGp8fals8FvMcs1hNX4JLXLg5S/PszJHrXUg/YA7qeaJODHGdonKZ+pxBljVHYzIUkF7QrcQzVJwDsytE9SHrsR57owKXfgUi/bhfIbeHRTlgJPy9A+Sem9iPLXhCeyR90ibgesbtxKmN/+l8zHnQJ8D5iW+biS4ts+Qh2LItTRs0wA1K07CBn8nZmPuyfwhczHlBRfjH0/FkeoQ1KX5gD3kf9xwBE5Gicpmf+i/HXgj9mjlrSOucBC8iYAjwI7ZmibpDTOp/x14FfZo24RHwEohqsJu90tzXjMmYTxAHXdNEjS6GIs8LUwQh2SIjgEWEnenoAPZ2mZpJgmEGeJ8dNyBy5pZEcBq8mXACwjLFAkqTnmEOf8/1juwNvERwCK7bvkPSknA18m7M4nqRli7e/xQKR6JEV0BnkfBRybp1mSIngHcc77g3MHLmlsE4HfkC8BWEScecWS0juFOOe9K4NKNTULuI18ScDP8zRLUklnEuec3zx34JKK25O8awS4QJBUf1dR/lxfiePYpNo7hHwzAx4ENsnTLEldWkT5c/2e7FFL6sqnyNcL8KVMbZLUuc2Ic55fnjtwSd0ZR5ylP4t2De6Vp1mSOvRs4pznZ+UOvG18fqJc1gBvIGwclNoE4IsZjiOpc3Mi1XN/pHp6lgmAcnoQOBJYleFYLwRekeE4kjpjAlATJgDK7SLghEzH+hxhPQJJ9TE7Uj05ehMlRTYOOI884wGOz9QmScVcQpxz+0W5A5cUx9bAAtInAI8SRh1LqoeHiHNu75g5bkkRHUmeXoDTczVI0qg2Ic45vRwYnzl2SZH9kPQJwAri7T4mqXvPJc45fVPuwNvIQYCq2rtJv6XnRODjiY8haWy7Rarntkj19DQTAFXtYeDtGY5zNPEuPpK6YwJQIyYAqoOzgW8mPsZ47AWQqrZrpHpuj1SPpBqYRVgoKOVYgFXAHrkaJOlJ5hHnXH5Z7sAlpfUW0g8I/EG21kgaajywjDjncayeBEk10Qf8hrQJwBrgaZnaI2mtXYjXkzcpc+ySMtiLMG0vZRLwk2ytkTToEOKcvz7/j8RBgKqb64FTEx/jNcDcxMeQtC4HANaMCYDq6FPA3Qnr78MZAVJusaYA3hqpHkk1dTTpxwI8NVtrJF1EnHP32NyBS8prHHAFaZMAZwRI+TxAnPN2v9yBS8rvhaRNAFbjugBSDjOJd85umDl2SRU5l7RJwHfyNUXqWfsT53z1+b/UQ/YAVpIuAViFewRIqb2dOOerU3gjchaA6u5G4FsJ6x8P/EPC+iXBUyLVc22keiQ1xLbAE6TrBVgJzMnWGqn3XECcc/Ww3IFLqt5nSTsW4Ix8TZF6zn3EOU9n5w5cUvU2BRaRLgFYgRcXKYWNiXOOLiYs4qVIHAOgpngY+ELC+icCH05Yv9SrYj7/749Ul6SGmQ7MJ20vwA7ZWiP1hmOJc37+R+7A284eADXJEuCUhPVPBD6UsH6pFzkDQFIUUwkbBaXqBVgKbJ2tNVL7/Zo45+azcwcuqX5idSmOVFKONZB6TYw9AJYCk3IHLql+JgA3YS+AVHeziHNOXpI78F7gGAA10Srg0wnrnwIcn7B+qVfEev7/+0j1SGqBccBVpOsFWAJsnq01Uju9kzjnoysAJmAPgJpqDfCJhPVvgL0AUln2AEhK5rek7QXYLF9TpNa5kPLn4e3Zo5bUCAeSLgHoB07M1hKpXfqABZQ/B7+bO3BJzXEe6RKAhYS1zCV1ZjfinIPH5Q5cUnPsQxgTYC+AVB9vIs759/TMcUtqmB+TLgF4DGcESJ36MuXPvSWEdT8kaUQ7ActJlwS4OqDUmaspf979X/aoJTXSf5AuAVgKbJevKVKjbQCspPx55+M3SYVsASwmXRLw1XxNkRrthcQ55w7OHbik5voE6RKAVYSRzZJGdzLlz7flhJ4ESSpkA+A+0iUBzkmWxnYN5c81n/9L6tg7SJcArAaelq8pUuNsSZxpuR/LHbik5hsP3EC6JOB/8jVFapw3Eec8e1bmuCW1xGGkSwD6gf3yNUVqlO9T/vx6lJDIS1JXUm4UdEHGdkhNMR54mPLn15m5A5fULvuRdongv8nXFKkRXkycc+uduQOX1D4/I10CcBlhxzNJwdeIc27tnDtwSe2zG3FWJBupHJKvKVKtTSTO9r93ZI5bUot9hXQJwLXAuHxNkWrrEOKcU2fkDlxSe21O2iWCX5+vKVJtfRvPJ0k19GnSJQA34Zal6m1TgUWUP5dWA5tljl1Sy00HHiBdEvD/8jVFqp03Eec8ujhz3JJ6xLtJlwDcAUzO1hKpXn5HnPPo+NyBS+oN44HrSZcEvCdfU6TaeCrxzqHZmWOX1ENijVQerjxIeNQg9ZLTiXP+XJ47cEm95wLSJQEfzdgOqWrTiTP4rx/4x8yxS+pBTwNWkSYBWIijmNU7jiXeubNH5tgl9ahYS5YOV/4jYzukqowHbibOOXND5tgl9bAtiNd1uX5ZBeyVrylSJV5PvHPm05ljl9TjPk66XoBzM7ZDyq0PuJJ458sz8oYvqddNBe4kXRLw0nxNkbJ6GfHOk5szxy5JALyRdAnAPFwiWO10MfHOk49kjl2SgLCT3xWkSwLela8pUhYvIN75sQrYJm/4krRWzAva+uURwm6EUhv0Ab8l3vnxi7zhS9KT/Yx0ScB/Z2yHlNJriXtuvC5v+JL0ZHOAZaRJANYAz8nXFCmJicAtxDsv7gcmZW2BJI3gC6TrBbgWBwSq2WLvpnli3vAlaWQbAw+TLgk4Ll9TpKimE76xxzoXVgM75myAJI3leNIlAI8SViCUmuYU4p4LZ+UNX5LGFvs55/rlB/maIkWxF7CCuOfBC7K2QJIKOox0CUA/cEi+pkiljAN+R9zP/+VZWyBJHTqfdAnAvcCMfE2RuhZzu9/B8vqsLZCkDj2NsEpZqiTgtHxNkbqyBWEhq5if+7/gbBhJDfCfpEsAVuPaAKq37xP/c/+OrC2QpC5tBiwkXRJwPS6Eonr6O+J/3u8CJudshCSV8QHSJQD9wGfyNUUqZBtgAfE/6+/O2QhJKmsSYb/yVAnASuDZ2VojjW4c8Gvif87vAaZkbIckRXEIaXsBbgKmZmuNNLIPkuYz/pacjZCkmM4jbRLw+XxNkYb1VNJsiDUPGJ+xHZIU1R7EXw1taFkNHJirMdJ6ZgK3kuaz/aqM7ZCkJE4jbS/A7YRNV6ScxgHnkOYzfUnGdkhSMql3C+wHfgr05WqQBPwz6Xq19s3YDklK6j2kTQD6CVMPpRxeSbhRp/gcn56xHZKU3ATgBtImACuBl+RqkHrWHsAi0nyGFwCz8jVFkvJ4Cel7AZbgUsFKZ0fCynypPr9vzdYSScrsbNInAY8Cc3M1SD1ja+A20n1u/w/HsUhqsTmkmTM9XBLwgkxtUvttStpHWE8AO2drjSRV5HOkTwD6gaXAazO1Se01E7iStJ/VD2VrjSRVaCbwIHmSgNWEjYPcS13d2BT4A2k/oxcR1hSQpJ5wLHkSgKEX2W2ytExtMQe4hbSfy4WEgYWS1DPGAVeQNwl4FHh7jsap8Z4NzCf9Z/INuRokSXWyH2Hufs4koJ+wauAWGdqnZjqMMCgv9efw27kaJEl1lGo51bHKQ8DrMrRPzdFHWE0y1Qp/Q8v1wAZ5miVJ9TQBuIxqkoB+4EfAZslbqbqbAfyQPJ+5x4A98zRLkuptD/J0uY5U5gNH4yIsver5wN3k+aytAV6fp1mS1AzHUV0CMFguAvZK3VDVxnjgBGAV+T5jJ+ZomCQ1zX9TfRKwAvgssGHitqpaOwMXk/ez9VOc7y9Jw5pE/ovySOUe7KptoymEb/1Lyft5ugqYnr55ktRcmwK3U30CMFh+Q5gTruZ7OWk38xmp/BnYKkP7JKnxnkK6/da7KWuAnwC7pWy0ktke+BnVfHbmA7ukb6Iktcf+wGKqv/kPLSuB/8Rvc02xGXAK8DjVfF4WAfsmb6UktVAdk4B+YAlhg6FN0zVdJcwC/oUw376qz8hjwPNSN1SS2uy51OtxwNCyDPgKoYtZ1dsQ+Ahhg50qPxePAwclbqsk9YQ6JwH9wHLCFMbdU70AGtVs4GSqv/EP3vxflLa5ktRb9gb+QvUX+NHKauBM7PrNYRzwMuBs8qzdX6Q8SnhsJUmKbBZhWl7VF/oi5SZCd/QmKV6IHjaDsKXzDVT/Hg8t84G5CdstST1vMvANqr/gFy1LgK8Bz0zwWvSKycCrge9T7Z4RI5XbgF2TtV6StI4PEqblVX3x76RcBfw9sEOC16NtJgAHA1+nHs/2Ryq/x90kJSm7/cm3i1vMsoZw43g/sE30V6W5JhMG0H0ZeIjq36exyk+AqUleCUnSmDYFzqX6m0G3ZTVh/4MPEgY69ppdCDtBnkN4XFL1+1E0gfsMbuwjSZXrA/6B5j0SGK7cRxjjcCSwecTXqC62AV4LnE699nwoWh7HTaJ6Xl/VAUh6kmcB36Y9A7L6gWuBPwB/BC4H5hF6DZpgEvAMYD/gOQNlu0ojKucuwmDEq6oORNUyAZDqaRph/fd30c7zdAlwJSEhuBa4daAsqDCmCcAcwiZOuw/8uQewJ+G5fhv8Angj8HDVgah6bbywSG3yEsLqfL0yyO4R1iYDtxHmpc8n3LCGlv4O692IMNBtK2BbYOuBss3Av80GdiZ822+jVcA/EZLKTl87tZQJgFR/GxMu3G/BcxbCo4PFA39fzNpHCSsJPQsbEL6xzwSm4Aj3u4CjgEurDkSS1J3nUb+V4yz1Lj8iJJCSpIabSFiadxnV31ws9S3zCQP9JEktszvNXjfAkqasAb5FWFdCktRiLwKup/obj6X6chth0KgkqUdMBD5A2Ma16puQJX95AjiBMOBRktSDNgH+lbDKW9U3JUv6soYwyG82kiQR5rf/B7Cc6m9SljTlYtyaWZI0gtmEbWhXUP0NyxKnXAa8DEmSCtgeOBUfDTS5XAMcjgtBSZK6sClhsNgCqr+hWYqVS4FD8cYvSYpgOvBOnD5Y17KMsJXy3iO8f5IklfY8wkjylVR/4+v1cgthlcfNR33HJEmKaDvg44Rd+Kq+EfZSWQJ8F/gb7OaXJFVsH+ArhJ32qr5BtrGsAi4A3ghsWPA9kSQpmw0I28ieg1MJy5blwHmELZ3dnU+S1BizgHcQFqBZTfU31CaUhwkb8xyO3/RVQz5zktSpLYBXAIcQNp/ZoNpwamMVcDlwIfBL4HeEZEmqJRMASWVMAQ4CXgocSJi6Nq7KgDJaDVxFuOFfCFxCGNQnNYIJgKSYZgHPJyQDzyMkBBOrDCiiO4E/DilX4g1fDWYCICmlycBcYN+BMhfYnXpvXbsQuBG4YcifVwEPVhmUFJsJgKTcxgE7EhKBPYBdCesQbD/w50aJj78CuJvwjf4u4I6Bv98J3Azcl/j4Ui2YAEiqm40IicAswpS5oWUSMJNw7RoHzBj4nYWEkfePDvy5kDD1bsGQ8hBhZP7iTO2QJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEkJ/X8dZ5aEVHOx+QAAAABJRU5ErkJggg==';
+
+  if (el !== null) {
+    // let hintVisible = false;
+    el.style.position = 'relative';
+    const scrollHint = document.createElement('p');
+    scrollHint.classList.add('scrollHint');
+    // scrollHint.style.position = 'absolute';
+    // scrollHint.style.top = '1em';
+    // scrollHint.style.right = '1em';
+    scrollHint.innerHTML = `finger scrolling horizontally Scroll to the right`;
+    scrollHint.style.opacity = '0';
+    scrollHint.style.animation =
+      'arrow-tweet-panel-pulse 0.82s ease-in-out infinite';
+
+    el.appendChild(scrollHint);
+
+    document.head.insertAdjacentHTML(
+      'beforeend',
+      ``
+    );
+
+    function showHideScrollHint() {
+      if (el.scrollWidth > el.clientWidth) {
+        scrollHint.style.opacity = '1';
+        scrollHint.style.transition = 'all 1s ease-in-out';
+      } else {
+        scrollHint.style.opacity = '0';
+        scrollHint.style.transition = 'all 1s ease-in-out';
+      }
+    }
+
+    function hideScrollHint() {
+      scrollHint.style.opacity = '0';
+      scrollHint.style.transition = 'all 1s ease-in-out';
+    }
+
+    showHideScrollHint();
+
+    new ResizeObserver(showHideScrollHint).observe(el);
+
+    let userHasScrolled = false;
+    el.onscroll = function (e) {
+      hideScrollHint();
+      userHasScrolled = true;
+    };
+  }
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  // if (location.pathname === previousLocation?.pathname) return;
+  horizontalScrollHint('.googlesheet');
+}
+```
+
+
+
+
+---
+title: Source: clientModules/findMentalModelMatches.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_findMentalModelMatches.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_findMentalModelMatches.js.md
+---
+
+# Source: clientModules/findMentalModelMatches.js
+
+```
+/**
+ * @file This file adds the same term from external glossaries to the glossary. The terms are added as Bootstrap accordions in the glossary page. The terms are fetched from json files.
+ * It only works on pages in /docs/glossary/
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-10-31
+ */
+
+import { toLowerCaseAndRemoveSpecialChars } from '../modules-js-universal/toLowerCaseAndRemoveSpecialChars.js';
+
+import termsDefinitionsDigitalgovtnz from '@site/static/json/external-glosseries/glossaries/terms-definitions-digitalgovtnz.json';
+
+import termsDefinitionsEssiflab from '@site/static/json/external-glosseries/glossaries/terms-definitions-essiflab.json';
+
+import termsDefinitionsNist from '@site/static/json/external-glosseries/glossaries/terms-definitions-nist.json';
+
+import termsDefinitionsToip from '@site/static/json/external-glosseries/glossaries/terms-definitions-toip.json';
+
+import termsDefinitionsToipDidWebs from '@site/static/json/external-glosseries/glossaries/terms-definitions-toipdidwebs.json';
+
+import termsDefinitionsW3cDid from '@site/static/json/external-glosseries/glossaries/terms-definitions-w3cdid.json';
+
+const allTermsDefinitions = [...termsDefinitionsToip, ...termsDefinitionsEssiflab, ...termsDefinitionsDigitalgovtnz, ...termsDefinitionsNist, ...termsDefinitionsW3cDid, ...termsDefinitionsToipDidWebs];
+
+// Remove links from term.definition
+const removeLinks = (html) => {
+  const doc = new DOMParser().parseFromString(html, 'text/html');
+  const links = doc.querySelectorAll('a');
+  links.forEach(link => {
+    const text = doc.createTextNode(link.textContent);
+    link.parentNode.replaceChild(text, link);
+  });
+  return doc.body.innerHTML;
+};
+
+const findMentalModelMatches = () => {
+  // Code should only run in the documentation section
+  const inDocSection =
+    window.location.href.indexOf('/docs/glossary/') > -1 ? true : false;
+
+  let headingAdded = false;
+
+  if (inDocSection) {
+    const markdown = document.querySelector('.markdown');
+    const heading = document.querySelector('.markdown h1:first-child');
+
+    // This is not working, because the heading sometimes contains child elements:
+    // const headingText = heading.innerText;
+
+    // This works: (to avoid also selecting text in child elements, e.g. )
+    const headingText = heading.firstChild && heading.firstChild.nodeType === Node.TEXT_NODE ? heading.firstChild.textContent : '';
+
+    allTermsDefinitions.forEach((term) => {
+      // Remove zero-width space and other non-printable characters
+      term.term = term.term.normalize('NFD').replace(/[\u200B-\u200D\uFEFF]/g, '');
+
+      const termToLowerCaseAndRemoveSpecialChars = toLowerCaseAndRemoveSpecialChars(term.term);
+
+      if (termToLowerCaseAndRemoveSpecialChars === toLowerCaseAndRemoveSpecialChars(headingText)) {
+        if (headingAdded === false) {
+          // Create h2 element
+          const h2 = document.createElement('h2');
+          h2.textContent = 'Other glossaries (or mental models)';
+          markdown.appendChild(h2);
+          headingAdded = true;
+        }
+
+        // Create Bootstrap accordion container
+        const accordionContainer = document.createElement('div');
+        accordionContainer.classList.add('accordion');
+        accordionContainer.classList.add('mb-3');
+
+        // Create Bootstrap accordion item
+        const accordionItem = document.createElement('div');
+        accordionItem.classList.add('accordion-item');
+
+        const accordionHeader = document.createElement('h2');
+        accordionHeader.classList.add('accordion-header');
+        accordionItem.appendChild(accordionHeader);
+
+        const accordionButton = document.createElement('button');
+        accordionButton.classList.add('accordion-button', 'fs-4');
+        accordionButton.setAttribute('type', 'button');
+        accordionButton.setAttribute('data-bs-toggle', 'collapse');
+        accordionButton.setAttribute('data-bs-target', `#collapse-${termToLowerCaseAndRemoveSpecialChars}`);
+        accordionButton.innerHTML = `${term.organisation} definition`;
+        accordionHeader.appendChild(accordionButton);
+
+        const accordionCollapse = document.createElement('div');
+        accordionCollapse.classList.add('accordion-collapse', 'collapse');
+        accordionCollapse.setAttribute('id', `collapse-${termToLowerCaseAndRemoveSpecialChars}`);
+        accordionItem.appendChild(accordionCollapse);
+
+        const accordionBody = document.createElement('div');
+        accordionBody.classList.add('accordion-body');
+        accordionBody.classList.add('fs-6');
+
+        const definitionWithoutLinks = removeLinks(term.definition);
+        accordionBody.innerHTML = "
" + term.term + ": " + "
" + definitionWithoutLinks + `(source)`;
+        accordionCollapse.appendChild(accordionBody);
+
+        // Insert accordion item as first child of accordion container
+        accordionContainer.appendChild(accordionItem);
+
+        markdown.appendChild(accordionContainer);
+      }
+    });
+  }
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+  findMentalModelMatches();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/fetchFormsColumnFromWotTerms.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_fetchFormsColumnFromWotTerms.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_fetchFormsColumnFromWotTerms.js.md
+---
+
+# Source: clientModules/fetchFormsColumnFromWotTerms.js
+
+```
+/**
+ * @file This file adds a “form” to the title of a term in the glossary, based on the value in the “Form” column of the overview.json file. “Form” can be one of the following: [noun], [verb], [relation], or [adjective/adverb].
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-11-01
+ */
+
+import overview from '@site/static/json/overview.json';
+
+const fetchFormsColumnFromWotTerms = () => {
+  // Code should only run in the documentation section
+  const inDocSection =
+    window.location.href.indexOf('/docs/glossary/') > -1 ? true : false;
+
+  const entriesIndex = overview.values[0];
+
+  function positionInArray(value) {
+    for (let i = 0; i < entriesIndex.length; i++) {
+      if (entriesIndex[i] === value) return i;
+    }
+    return -1;
+  }
+
+  const termColumn = positionInArray('Term');
+  const formColumn = positionInArray('Form');
+
+  function getNameFromAbbreviation(abbreviation) {
+    const formValuesIndex = [
+      { abbreviation: 'n', name: 'noun' },
+      { abbreviation: 'v', name: 'verb' },
+      { abbreviation: 'r', name: 'relation' },
+      { abbreviation: 'a', name: 'adjective/adverb' }
+    ];
+
+    const matchingForm = formValuesIndex.find(form => form.abbreviation === abbreviation);
+    return matchingForm ? matchingForm.name : null;
+  }
+
+  if (inDocSection) {
+    const markdown = document.querySelector('.markdown');
+    const heading = document.querySelector('.markdown h1:first-child');
+    const headingText = heading.innerText;
+
+    overview.values.forEach((term) => {
+      if (term[termColumn] === headingText) {
+        const text = getNameFromAbbreviation(term[formColumn]);
+        heading.innerHTML += ` [ ${text} ]`;
+      }
+    });
+  }
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+  fetchFormsColumnFromWotTerms();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/fetchCommitHash.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_fetchCommitHash.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_fetchCommitHash.js.md
+---
+
+# Source: clientModules/fetchCommitHash.js
+
+```
+/**
+ * @file This file fetches the commit hashes of current file and shows it after clicking on a button. The info is fetched from the Github API.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2024-04-19
+ */
+
+const paths = require('../docusaurus.paths.js');
+const baseUrl = paths.baseUrl;
+
+const textStrings = {
+  fetchCommitHash: 'Show commit info',
+  loading: 'Loading...',
+  noCommitHash: 'No commit info found',
+};
+
+const fetchCommitHash = () => {
+  // Where are we in the glossary?
+  const urlIsGlossary = baseUrl + 'docs/glossary/'
+  // And, are we in the glossary? Test if urlIsGlossary is in window.location.pathname
+  const urlIsGlossaryInPathname = window.location.pathname.includes(urlIsGlossary);
+
+  // if we are not in the glossary, return
+  if (!urlIsGlossaryInPathname) {
+    return;
+  }
+
+  const owner = 'WebOfTrust';
+  const repo = 'WOT-terms';
+  const pathName = window.location.pathname;
+
+  let filePath = pathName.substring(pathName.indexOf('/', 1) + 1) + ".md";
+  console.log('filePath: ', filePath);
+  // in filePath, replace the string “glossary” with “04_glossary”
+  filePath = filePath.replace('glossary', '04_glossary');
+
+  // GitHub API URL
+  const url = `https://api.github.com/repos/${owner}/${repo}/commits?path=${filePath}`;
+  console.log('url: ', url);
+
+  const buttonElement = document.createElement('button');
+  buttonElement.innerText = textStrings.fetchCommitHash;
+  buttonElement.classList.add('btn', 'btn-outline-secondary', 'mt-5', 'ms-2');
+
+  // add the paragraph to the page at the end of the page
+  document.querySelector('.markdown').appendChild(buttonElement);
+
+  // Function to fetch the latest commit hash of the file
+  async function fetchLatestCommitHash() {
+    buttonElement.innerText = textStrings.loading;
+    try {
+      // Fetch the list of commits for the specified file
+      const response = await fetch(url, {
+        headers: {
+          'Accept': 'application/vnd.github.v3+json'
+        }
+      });
+
+      // Check for rate limit before proceeding
+      if (response.status === 403 && response.headers.get('X-RateLimit-Remaining') === '0') {
+        const resetTime = new Date(response.headers.get('X-RateLimit-Reset') * 1000);
+        console.error(`Github API rate limit exceeded. Try again after ${resetTime}`);
+        alert(`Github API rate limit exceeded. Try again after ${resetTime}`);
+        return;
+      }
+
+      // Check if the request was successful
+      if (!response.ok) {
+        throw new Error(`HTTP error! status: ${response.status}`);
+      }
+
+      // Extract JSON data from the response
+      const data = await response.json();
+
+      // Check if there are any commits
+      if (data.length === 0) {
+        console.log(textStrings.noCommitHash);
+        buttonElement.innerText = textStrings.noCommitHash;
+        return;
+      }
+
+      // Process the last ten commits
+      const commits = data.slice(0, 10); // Get only the last ten commits
+      // reverse commits array to display from oldest to newest
+      commits.reverse();
+
+      commits.forEach((commit, index) => {
+        const date = new Date(commit.commit.committer.date);
+
+        const divElement = document.createElement('div');
+        divElement.innerHTML = `
+        
Commit ${index + 1}

+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
+          
+          
+        
+        
${commit.commit.committer.name} (${commit.commit.committer.email})
on` + date.toDateString() + `
sha:` + commit.sha + `
verification

+        `;
+
+        // Add each new div element after the buttonElement
+        buttonElement.parentNode.insertBefore(divElement, buttonElement.nextSibling);
+      });
+
+      buttonElement.innerText = textStrings.fetchCommitHash;
+
+      return commits.map(commit => commit.sha);
+    } catch (error) {
+      console.error('Failed to fetch commit hash:', error);
+      alert('Failed to fetch commit hash: ' + error);
+    }
+  }
+
+  // Call the function
+  // fetchLatestCommitHash();
+  buttonElement.addEventListener('click', fetchLatestCommitHash);
+
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+
+  fetchCommitHash();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/elementGoFullScreen.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_elementGoFullScreen.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_elementGoFullScreen.js.md
+---
+
+# Source: clientModules/elementGoFullScreen.js
+
+```
+/**
+ * @file This file makes the table on the Overview and context page appear in a modal that is almost full screen. It also adds a button to the table that makes it full screen.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-03-13
+ */
+
+const elementGoFullScreen = (element) => {
+  const elementGoFullScreen = document.querySelector(element);
+  const langMaximizeButton = 'Make fullscreen';
+  const langMinimizeButton = 'Make smaller';
+
+  if (elementGoFullScreen !== null) {
+    const goSmallScreenButtonImage =
+      'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAgAAAAIACAMAAADDpiTIAAAA/1BMVEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD64ociAAAAVXRSTlMADVmZw9n0wphYDCab9v/1miQlCYv6+YkIitLQItEjL+gx7TLvNTDs0wtWl8Hb8/Lx2tjAVYgHz+cOyuqdnIz7xxnjLhjMgZZX6+n4h8bi5RstFYbIHbvg/gAACwVJREFUeAHswQEBABAAACAA/B/sBlQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4SUy51NZqH3MFNjt2cSYxEANRWMv8hplxmTH/xJZ5PMeWdag/BFVZ+tp5zH/rff5rucx/b/+Ab4ViycRV+ff8D9znX6nW+KPeaJq4abbynX+pzYJO1yTH+ff65mYwJMNwZOJilD3/gVv/hmQaT0wcTMZkGjrt4GaHJaYzk+TmhyxxVDEPLQDtgGjfP0DD5f1XQw2ImT/1vqW3D0C0K6D9/27NkjveJGoDlD+F9P8EdwDQFYi3/9+dWGprxG2A8ufUUlsH0BWIuP8Bziy1c+I2QPmzYaldELcByp9L/wIEaoDy58pSuyZuA5Q/N5baFnEboPy5DfAM1Gsw3fsvwDNwh7gNUP7cufwK1hUIs//9fwVbkagNUP5sW3rlOroCMfc/9a45aBCzAcqfe/Pw8IiuQMT9T7tiLvrDiDtA3/9T15yMxvEaoPzH86CL6YWds8ZWIAiA4Hd3hQyHiHjdcLj/fchwZqN6vGbmANs1Xa9xcY8CZ6XZLcBJdgtwit0CnODmqZ8J+lcvQfj7GwYfj5dAP4AvoFfniM/R+zr9Pf4CCgJ8Abkah/xO0u3432ql/Cqer69W45hfvf38LC+7CufrixU5aD08lF8M+MI8n9eqv4Cv8HB+MQQaYnxAqsCLFfb/CUbffGGezysVvw9IjueP+b44nxcqvoDn9Hh8n38QoPm8TvUFRKb4CV+X5fMy1Z8H+O+m9LtLuizL51XK3wdcmdOndFeUz4vUX8DLG/8fKRwf0Gjbo0Bgzs6AcgAfkGjLfcDMHD0HugF8QKEt9wF/5uQFUA3gAwJtWUBZMl2T4i/Zu4MThqEgiKGQcxpK3H9fbkIDK1AJYz3/6yr68xMC4O8PjAiAuD8wIwDi/sCQAEj7A1MC4OrPjwmAqz8/JwDm/vwgPwBBf4EAMYD6A6PUAOrPzzIBqD8wzAyg/sA0M4D6A+PMAOoPzDMDqD8w0Ayg/sBEM4D6AyPNAOoPzDQDqD8w1A+g/sBUP4D682NdAOrPz1UBqD8/WAWg/vxkFYD686NVAOrPz1YBqD8/XAWg/vx0FYD68+NVAOrPz1cB4D9AAlQA+PkJEAHgxydABICfngARAH54AkQA+NkJEAHgRydABICfnAATAHxwAsQA+P4JUAHg+ydABIDvnwABAL5/AqwABv0TIABQ/4EADYBN/wT4ANR/I8ACoP4jARIA9V8JcACo/0yAAkD9dwIMAOo/FCAAUP+hAAGA+k8FnAdQ/62A6wDqPz6Zeh3A+P5rb8B1AKv/PwF+APv+CdgDGPVPgBvAvn8C/AD2/ROwB7DrnwAxgH3/BPgB7PsnYA9g2j8BbgD7/gnwA6j/VsAeQP33AvwA6r8XYARQ/7mAPYD67wX4AdR/L0AHoP5DAQIA9R8KEACo/1CAAED9NwIEAOo/ECAAUP/f5/t/Xnbp2gihKAoC6OJ+P64RGREx7k7/9SANEL0d3p3ZU8PpGNH/A/B1lot6KQV/KqvEvhQggGTdhC+tzdZMAcLpDPpwpDkxU4Cwdnu4MV6aAgR3OMKJ5tIUgOBwggv9kSkAxbkFDzamACQXOFDZKgDL9IT4rUwBaK6I3jxRAJ58CrFLmwIQ3RC7qgIwZRC7hQIw7RC7uwIwPRC7rgIwPRXgt+eb/bk2qASKogC4inNx92h9E9zdXfqvhSr45wUzHYxf2HVF3fiF7VTUkV/YcEX1+IX1VtSaX1hfVwV19fml7VfQsF/c6ETFTM775c1UzJ1fA6aPKuR+w68FZw8V8fjk14bTkwp4ePZrxcvf6rj7M792bFx0VUdNvm74NeXssqs6puvrvF9z+q563m4m64NN3rz9+d3nBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGx/GdjZnagPNrG7M9z72a85/XtD1TFD+6N+TRk7OKyOmpiZ9mvH6M/quKNjv1as7FbAyalfG0Z3K+LkzK8F03MVcj7m14CDirnwy+s/rJj/Z35xexV06Ze2PVRBXZ/9wr5U1JVf2EBFffUL26moI7+w64q68QubrKhbv7DJd3brwgYBIIbC8MPdXRZAokgMd/f9Z2EIrrk2vG+Gv5L1C8KyDMDjimQAJz6BugPgE5hnAJLi0C7BACQNoV0yygDkRJNQb8oA5OShX7HCAKRU2zCgwQCkXGBBfcEAZFzHMGFzYwAS7g8YsV4xAPduT5jx6jMA164bGDLeRRmAS9X3GLZs9s4SYADRUBv2JA/xz6nKAH5TPX163ST+z5d9ejFhKIahGJpZ3qfdf8POYEBgFd0NHJ18vv8E4HlPA/oLACQA6C8AkACgvwBAAoD+AgAJAPpbACQA6K8HkACgvx9AAvj+PIAE8P39ABLA9PcDSADcnweQAL6/H0ACsP5+AAkg+/MAEsD39wNIANnfDyABWH8eQAL4/n4ACYD7+wEkgOnPA0gA2N8PYC6g3dfg0a7tAEbH3KfN/v/zbgcwPOfMVv+zHcBBBdR/PwBUQP0FAEgB9TcAAAXUXwGAE1B/BwBMQP0lACgB9bcAgATUXwOAEVB/DwBEQP1FAAgB9TcBAATU3wQAEFB/EwBAQP1NAAAB9TcBAATU3wQAEFB/EwBAQP1NAAAB9TcBAATU3wQAEFB/EwBAQP1NAAAB9VcBSADwAOsBJAA43wUgAT926YACAAAAglj/1p/iYD7CWIAHAvADAroTwB8QwJ0A/oCAjQXwB/RoIIA5ICADAT4gAAMBzAEBFwjwAQEWCOAMCKhAgA8IoEAAbkDANAJ8QIAEAmADAqIS4AMCIBCAGhDwnAAfEOCAANCAgCYF+IAABgRgBgQsK8AHBCggADggIPkB/AERCAgADAg4D2ANCDFAAGBAQHkAZ0AMAQIAAwLGAxgDegQQABgQEB5g7F2DdjRhDC1H1XJQ27Zt6/2fpYfl7JQ3J+ne7wFyucmP4h80QEpAmD35AiQPj2+8AQNSvzL1LHv0OVooDh9vIeDJ13c9e/YuQBwO3/4OkC9vLnu4B1CHxre/AySJ+9nTFwHycPj2GyC/ugIna7oTIIXi8U1eAeHabmWNz2Gl4vEN7gBpyoVy5fFhJ1gsHl/aToOEk8rzL+Fy8fjyhlo7WvFupflXy3jBeHwxS82SPbxOn39zixeMx5cz1e66OthPm399hxeMx5e31WJV7ydT9u8hXjAeX95Ym0VdPnbejg8f8PdfEB9urX2ShyevInDq8X//k8XHm2ufYnDqPZ6H4fnjxHiAl4vHV94A/shLGsz8aTHzp8nMnzb3ff8PKHz4Pwn2SdHK92rMnw3o7ZYhFXdw/+u8AqNFEU4JP/9ad0AiwaiprDV/NiDMCxBq5v7XewVyeDpjjt782YC2AM7G5/7XfAVO4WTqNefPBnhwLg3c/5qvgAunMqU5fzZgDs5kWnP+bMA0vgCa82cDZuA85jTnzwY0wmm4mvNnAybxfw3k3/80/23Qg5PwNefPBozL/1Mw97+iK9AW4Dnk9ObPBtQLUCiE3P9ar0DYLUEh0po/GxCJMFhe4f7XeQXaizIMunv5+de4A1Y7pRj09KbiD8ug8/Wl+98jx6C76yN+RyeTqR7/4yR8Cx9GMXOpKv/zubYX+LZcN0OpOv+DU89tdJxG1xsP5NH56D+f1ffUHhwIAAAAAAD5vzaCqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoANIpzUoj0ZyUAAAAASUVORK5CYII=';
+
+    const goFullScreenButtonImage =
+      'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAgAAAAIACAMAAADDpiTIAAAC7lBMVEUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC1zwCeAAAA+nRSTlMAC1KSwuf1//zr1q2APgUBL3Ok0Pn46siaWxEnnPPuljAfg+OnEpj9/rMunfqjFz37jAgDcfTpRFrPJBO5ZVntOt9hOOZAD+Ls3eWT0wohlXs2IpsGxKzyQyhQq5GvwFhG5N6FvQQrEC0jDsOyhnk03H4eFItPkMEHrsW8tH8CcM0zJrvVTsw8NZSqgilVmcYgQRkVDbds8Rh3ZuFeTKLvuJ9tv1e6dco3DM5T22pWtjn2X4Ec8BrLhCpIPxtgaEXJ98dvSWmeoG6wfXaNiXwxJYiOZBboO6Edl9hi13RjVKXa0UqKXbVNZ0tRQgmxpqhHqdngetTSj75r++YBkgAAD4lJREFUeAHs0gN6nWEQBtA3nNi2bdu27eSytm0vubbb/2Lme+as4eArAYFBwSGh5E9h4RGRUdExMFJsXHxCYkgS+VNySmpaegZ+JjMrm5jIyc2DcfILComJ5KI8fK+4pJQYKSuvgFHyK6uIkbLqGnyjtpCYqatvgDEam5qJmZZWfKUtifhp74AhOruIn7BufNZTShz19sEIHf3EUdkAPupLIp6yB2GAzCHiqWoY742MEldjmRCvZpy4mujEO5PE19Q0hGsMJr5K8NZMHTE2C+HmiLGwTABBxFnpPERbSCbOFoGlcGJtGaKtEGur01gj5oYh2Hop8baBAmJuE4LlEnNb2CbmkoshVswYMbeDROJuF2LtEXf7OCDuKiHWIXEXigniLhFiHRF3ZZgg7pJtkKqQ2MMEsVcDoWJKNYAn2CGUgzSAJzghVI0G8AgXhHJrAI9wQKjYMA3gAb0Qa1wDeMAxiHVcA3jACYh1UgN4wBrEOqUBrEuxQazY0xrAsnoIdkYDWFV1FoKdy9YAFuVCtPMawJreTojm3tcAlrRBuAtlGsCCLIh3UQP8v0uXIV7jFQ3wv66OwADT1zTA/7keACNcLtIA/yHsxk0YIvZWkgb4V7fvwCB372mAf3J/9yaMEvvgoQb4W/tpj2Cgx08OjA7Q/tQTFp/tPoexXC9uvHzqCa8YBsi5Ax9RZ8ffsHcXNkAsYRhF5wnuWgBRLIpHiWGloFEKQCK4S7W0gE3OTnK/Fu6Zf+PrASTA9/cAEuD7ewAJ8P09gAT4/h5AAnx/DCABvr8FkADf3wJIgO3vASTA9vcAEmD7ewAJsP09gATY/h5AAmx/DyABtr8HkADb3wNIgO3vASTA9vcAEmD7ewAJsP09gATY/h5AAmx/DyABtr8HkADb3wNIAOvvASQA9PcAEgD6ewAJAP09gASA/h5AAkB/D+Dpn/xnfM+Z8Qtrb6/v+v1dfD4FwL2XO7oBK7z/ne9ezwEw1hBQ/zELwBoC6j8NwBIC6j8PwAoC6j8RwAIC6j8TwAIC6j8TwAIC6j8TwAIC6j8TwAIC6j8TwAIC6j8TwAIC6j8TwAIC6j8TwAIC6j8TwAIC6j8TQAI22x8ASMCG+gMACdhQfwAgARvqDwAkYEP9JYAE+P4WQAJ8fwsgAb6/BZAA398CSIDvbwEkwPe3ABLg+1sACfD9LYAE+P4WQAJ8fwsgAb6/BZAA398CSIDvbwEkwPe3ABLg+1sACfD9LYAE+P4WQAJ8fwsgAb4/BZAA358CSIDvTwEkwPenABLg+1MACfD9KYAE+P4UQAJ8fwogAb4/BZAA358CSIDvDwBMEHDyzPi91Z8CSIDvTwEkwPenABLg+1MACfD9KYAE+P4UQAJ8fwIgAb4/AJAA338BAOPMyV2/v0vXxqJ7/yf9Lx4YmwQABDz6MJbcx2Oo/0QA5ivw6dBYcefN/Z8JQN2Az2PBXVHvfyIAdQO+fB3L7eNt9f4nAmA34M5YbqfY+58IgN2AnR/GYvvnJnv/EwG4G/BtLLbv7v1PBOBuwLGx2B679z8RALwBb39Qaw9dcEZBEIbf8E5s27a9i23btpNNuI5t27aTPxUn4286rNPPus+5qBoPrlRuoHn8/3oBDppHJ6BswCFcOazMnxrm9WJsNs8eQdmAfriyQZk/y80LHmWEeXY8ygYcw5XSyvwZbF5xKsfNsydQNmAzrpxU5s8p85KnOWOe7YCyAb1w5awyf2bbn9Y5Zx1teh5lAwrgygVl/mysbl30IjOOGkfzg7IBl3BlnjJ/WGNctGUXqGicvYy0ARVwZYI0f64YV70KXLONXu+CtAGlcWW5NH9a97Ate8X+bJUPpA1YiCs3pPnDTdvrahuA0ZbRgrfQNmAbrgzV5k+Xo/avVxlnfwDKGnB7OL4sluYPlw3rri3BV3dyJ3F3OH/f7F9owHGcuafNnzarcq97n+8eNAjRjs4BbQMe4kznmDR/eJTzch/z05MQqexTIvyP/wc8w52R/+H3/0jbq4VI04hjYYjwfAVxmueAp7gzu6Xm8R/3tF2I0K8EiQ40Ddn0eAjiBkzAoX7i/OFc+5BNg8GkuHYwZPaiFogbUP4ODu26JM4f7kzMdqMPSDN3ZcuQbu/LGSBuQOwVLm1/Ls4fNr6uHtI1fLOTTKq8bRqS3Z4Wn9Q14DJOXWygyj+uXtEeqc/+42qSzc53E8vF03/fcQD/w+z2IcoH3DoQ2YBRxfjETj0C6AGAAQD9hn+228pUZtu2bZaxzLZte2VeXJxts/d+6Yx2fq/nlxda3aqY2kCLVS8fRo6G3ul1/9W+12+mv20deeXdwLLZKvc4CrFbtctmK/E28sq6BXsXvd/3YffHykeiQPrUpWw2Ps+IQu3L6bLZGLssSLGuzfiyWdnVLAq5hl+blM1CmRFzg7QONapdNqPSfaMI6DGnbEa1Ln4LMjrxYkvZNLrX6x1FxI7vA8qm8aPSg8gSnX7W3/yrf2LJqnPXes+NImTujd9fVy1J9P+1+fufd5ENAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2/V30Yd++lr8nLYvihtYznibKpjg9fHvVKCpWNF/07/rAdjP/z2nUdWJkhSR26wHIkiAIwnAe82zbtm3btkNn27Zt27Zt22bYa++gV1PXG+8LG/n3TA291JdBvE89GpFBwXWHGMDzUYfhEtTFdzQwdi+0d+Y8g0re9DACcinSjsZytUsArR1uTyPpE4+GH5cCk2lq00Jo7EMKmthUAP+l0eNX7Vq2bPODkk/hmLk7aWHyAGhrcU6aqn0XTuk+rlS8j7ML9/vUpxksLdx/rSJ9dV49KIEz+1empckLoanrtFKiF5ywbeXn9PRVfO3ynjDTYFpMBpZiVHb5/clyRaGl9bSWwoEClg5sycDOPZtrHMrHfAxuyYXuiFiZK9PWAejoS05KF5Bgc3EGl+9eFART1WyHLU3E92esrdDP01qkcAFNjtBY7T4I4ms+mjnUKSL370IVR0ZDOyNJ4QJaHaKZZFXUrxUm6yi9P9kRuvlGChfwPTnN5bqBABbTUqzviBj9a1NR0oTQzFiqSZEHEeNHcloaAz+DctFazF6y759kVeilFUnRb8D4lrSW86LfDhlo5+U24f05GHpJQtkChialndgH1a8VDkS4e9qXVLcTWvmZniQF/wKjaO8XvAyignzHEM76d2GInIRO5pGiBcw9RwWr4GkyVfwWff8kv0En1ylbQEaqGJsQwBkqidVA5v73Uww6+UPRAgaco5K/AN5SzSjZ/fkROjlC0QIWU80/4GdMqnkuuz+fQSe1KVrAcKo5FwXzqOqp6P6cDZ08omQBCwtR0UVcp6rUCCdPazMUbkInWSlZwBmquoffVHVUdH8uc2/HHoBuyaEgjvfqnrWNZ9u2X9a2bdu2bdu2bdu2XVqbUzeTmz7z9b9s9K9mksBTL1hOAbdb0TriFivap1nuf791Pjx1puUUML8V7TM8Z0XbPev+9gg8tbDlFNDVijYB461oc2TdfwxcNcpyCljRitYDwYq2V8797W64al3LKWADK1xjAVxR9/72CXy1gNVZs135AWTY//M14asvLMM3gBzAFRdY3Z0GZz1xqcV/A8gAZNz/+AXhreYW/w0gA5Bvf5sU7nriZIv/BnAByLf/p3DYaZbtG0AIIGr/F46Aw2bYwHJ9A/gARO0/5hC47PBNcn0D6ADcELP/7OvAaYP6ZRLABuCYqRn2z9ABU8T/BYgA5Nm/EyAB/AC0P5MAFgDx+zfbFZAAVgDan0AAAQDtTyCAAID2JxBAAED7EwhgAdBN++cRQAKg2x7aP70ADgDan0AAAQDtTyCAAED8/hsjIgkgAKD98wggABC//8lR+0sAAQDtn0IAAQDtTyCAAID2JxBAAED7EwggAKD9CQRkAECwvwQQAND+BAJ4AMTtvw8ikgACAN2+1P4MAhIB0P4kAlgBPKH9SQQkAqD9aQQQAND+BAIIAGh/AgEZAGh/AgEEALQ/gQACANqfQEAGANqfQAADgCcWiNl/UUQkARkAaH8eAQwAova/Mm5/CcgAQPtTCcgAQPtTCcgAQPtTCcgAQPtTCcgAQPtTCcgAQPtTCcgAQPtTCcgB4PCo/c+BSiCggQAO/0r70wpICkD78wtICkD78wtICkD78wtICkD78wtICkD78wtICkD78wtICkD78wtICUD78wtICSBu/9FQ6QWkBKD9+QWkA+BlfwlIBSBq/6O1f8MEJALgZX8JSAPggte0f8PqNJXV31R7JAFgXvbXN8BIAPDvLwEI/veXAHIAfaeDYhWAwL+/BLAC8L+/BCA06f0lAMH//hLAC6Dv9VDUAhD495cAVgD+95cABP79JYAVgP/9JQChSe8vAQj+95cAQgB9x0J5EIDgdH8JIADgf38JQHC6vwQQAPC/vwQgON1fAggA+N9fAhCc7i8BBAD87y8BCP73lwAaADWe/SUgA4DaoVDOBCA43V8CCAD4318CEPzvLwEUAPY6qIwefeiiTjuhoq33yc7zz7xfGQ1MAICnZtte1AuVq9vOc0xpfCEYY8MvH4xKNWjxWY0yBOPs5Nt7ozItuDrp/MQAzLa+ARVp2a/MiAHQNvtoVKITayYAddX3ZlSgYT1MAOqsNgLuu3lWE4C663cVnPfI0iYAEa20E1y3zWsmAFHdBNc9ZAIQV7O2cNwNlwpAbNPCcY+ZAMQ2vBfcdkRfAYjvQLhtlAlAfNPAbRcLQAkN3wlOW3NpASijdeC0XU0AmvQhYC4BKKWN4LT7BKCUHoTTegpAKS0MpzUXgFJ6DE77WgBK6XI47XIBKKXH4bSXBKCUpoPTnjL6OmCisddjPThtwdmMvb7YxdibA26b3NhrjeX1DpSuPsbeN7jPyGu/GdzWrYuR9xi6G3krwnEnGXknovcYo67DxnDcslMadSf3Ah416maG61Yw6vYFcNitRlyzw+C69cYbcV0OAYDVjbcO78F558xqvG2BH1vwM6PtGrjvOKPtgiPwUzPWjLTOM8B/GxlptYfxSyf2MMq22glV6Nv2xliPt/Fbe15qfN16EyrSJ/2Mr77v4g/tuomxdfaMqEyH7WdsvbAO/tQRj/UwpkY+vhOq1PuTG1OX7v8B/tpCzU82kqY8c67pUbUuOaiZkbTqht3wT/U6cavTQ1/LWYdmq+0+2UWHo5L1XvTFzut/OTFvt3y6yCU74fe+BwS7xqku9X5mAAAAAElFTkSuQmCC';
+
+    let isFullScreen = false;
+
+    document.head.insertAdjacentHTML(
+      'beforeend',
+      ``
+    );
+
+    elementGoFullScreen.style.position = 'relative';
+    let maxMinButton = document.createElement('button');
+    maxMinButton.classList.add('maxMinButton');
+    maxMinButton.classList.add('button--secondary');
+    maxMinButton.classList.add('margin--md');
+    maxMinButton.classList.add('button');
+    maxMinButton.style.width = '2.5em';
+    maxMinButton.style.height = '2.5em';
+    maxMinButton.style.padding = '0.5em';
+    maxMinButton.style.position = 'absolute';
+    maxMinButton.style.top = '0.5em';
+    maxMinButton.style.right = '0.5em';
+    maxMinButton.style.background = `#EBEDF0 url(${goFullScreenButtonImage}) no-repeat center`;
+    maxMinButton.style.backgroundSize = '60% 60%';
+    maxMinButton.style.cursor = 'pointer';
+    maxMinButton.title = langMaximizeButton;
+
+    elementGoFullScreen.appendChild(maxMinButton);
+
+    maxMinButton.addEventListener('click', function () {
+      elementGoFullScreen.classList.toggle('elementGoFullScreen');
+      // The maximize / minimize button:
+      if (isFullScreen) {
+        maxMinButton.style.background = `#EBEDF0 url(${goFullScreenButtonImage}) no-repeat center`;
+        maxMinButton.title = langMaximizeButton;
+        maxMinButton.style.backgroundSize = `70% 70%`;
+      } else {
+        maxMinButton.style.background = `#EBEDF0 url(${goSmallScreenButtonImage}) no-repeat center`;
+        maxMinButton.title = langMinimizeButton;
+        maxMinButton.style.backgroundSize = `70% 70%`;
+      }
+
+      isFullScreen = !isFullScreen;
+    });
+    document.addEventListener('keyup', (event) => {
+      switch (event.key) {
+        case 'Escape':
+          elementGoFullScreen.classList.remove('elementGoFullScreen');
+          elementGoFullScreen.classList.remove('elementGoFullScreenStarter');
+          maxMinButton.style.background = `#EBEDF0 url(${goFullScreenButtonImage}) no-repeat center`;
+          maxMinButton.style.backgroundSize = `70% 70%`;
+          break;
+      }
+    });
+  }
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  // if (location.pathname === previousLocation?.pathname) return;
+  elementGoFullScreen('#table-container');
+}
+```
+
+
+
+
+---
+title: Source: clientModules/dynamicTables.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_dynamicTables.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_dynamicTables.js.md
+---
+
+# Source: clientModules/dynamicTables.js
+
+```
+/**
+ * @file This file makes tables filterable and sortable.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-03-13
+ */
+
+import { List } from './libs/list.js';
+
+const dynamicTables = () => {
+  let options = {
+    valueNames: [],
+  };
+
+  // th's in first row contain classnames that are needed for list.js config…
+  let tdClass = document.querySelectorAll('table tr:first-child td');
+  // … so we can add them to the options
+  tdClass.forEach((item) => {
+    options.valueNames.push(item.getAttribute('class'));
+  });
+
+  let list = new List('table-container', options);
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  // if (location.pathname === previousLocation?.pathname) return;
+  dynamicTables();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/crossLinks.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_crossLinks.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_crossLinks.js.md
+---
+
+# Source: clientModules/crossLinks.js
+
+```
+/**
+ * @file This file creates links in the content based on keywords. It also creates links to a timestamp in video's. Keywords and urls are in a local json file.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-02-01
+ */
+
+import { crossLinks } from '../crossLinksIndex';
+import config from '@generated/docusaurus.config';
+
+const doCrossLinks = () => {
+  let insertVideos;
+  document.querySelector('.markdown div.no-video-insert') === null
+    ? (insertVideos = true)
+    : (insertVideos = false);
+
+  // const domElements = document.querySelectorAll('p');
+  // const domElements = document.querySelectorAll(".markdown *:not(a)");
+  const domElements = document.querySelectorAll(
+    '.markdown div:not(.no-crosslinks) p'
+  );
+
+  // part 1: replace keywords with (almost) unique ID's
+  //TODO: add check if it is not already a link
+  if (domElements.length > 0) {
+    domElements.forEach((element) => {
+      crossLinks.forEach((textFragment) => {
+        let innerText = element.innerHTML;
+
+        // Assign only once:
+        textFragment.randomNumber === undefined
+          ? (textFragment.randomNumber = Math.floor(
+            Math.random() * 10000000000000000000
+          ))
+          : null;
+
+        let innerTextNew = innerText.replace(
+          textFragment.keyword,
+          textFragment.randomNumber
+        );
+        element.innerHTML = innerTextNew;
+      });
+    });
+
+    // part 2: replace (almost) unique ID's with link
+    domElements.forEach((element) => {
+      crossLinks.forEach((textFragment) => {
+        let innerText = element.innerHTML;
+
+        let strInnerTextNew =
+          `' +
+          textFragment.keyword +
+          '' +
+          ' (Level: ' +
+          textFragment.level +
+          ')';
+
+        if (textFragment.youtubeID !== undefined && insertVideos) {
+          strInnerTextNew += ``;
+        }
+        if (textFragment.video !== undefined && insertVideos) {
+          // let path = `${config.baseUrl}docs/video/video-files/${textFragment.video}#t=${textFragment.timeStart}`; // does not want to play for unknown reasons
+          let path = `https://dwarshuis.com/video/WOT-terms/${textFragment.video}#t=${textFragment.timeStart}`;
+
+          strInnerTextNew += `
More about ${textFragment.keyword}:
`;
+        }
+
+        let innerTextNew = innerText.replace(
+          textFragment.randomNumber,
+          strInnerTextNew
+        );
+
+        // textFragment.youtubeID !== undefined
+        //   ? (innerTextNew += ``)
+        //   : null;
+
+        element.innerHTML = innerTextNew;
+      });
+    });
+  }
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  if (location.pathname === previousLocation?.pathname) return;
+
+  doCrossLinks();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/createLinkToWikiPage.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_createLinkToWikiPage.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_createLinkToWikiPage.js.md
+---
+
+# Source: clientModules/createLinkToWikiPage.js
+
+```
+/**
+ * @file This file creates a link at the bottom in a glossary page to the Wiki article that is the source for the page.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-11-23
+ */
+
+const paths = require('../docusaurus.paths.js');
+const baseUrl = paths.baseUrl;
+
+const createLinkToWikiPage = () => {
+    // Where are we in the glossary?
+    const urlIsGlossary = baseUrl + 'docs/glossary/'
+    // And, are we in the glossary? Test if urlIsGlossary is in window.location.pathname
+    const urlIsGlossaryInPathname = window.location.pathname.includes(urlIsGlossary);
+
+    // if we are not in the glossary, return
+    if (!urlIsGlossaryInPathname) {
+        return;
+    }
+
+    // everything after the last slash in the url pathname
+    const pathname = window.location.pathname.split('/').pop();
+
+    // in pathname remove everything after the first hash and everything after the first question mark
+    const pathnameWithoutHash = pathname.split('#')[0];
+    const pathnameWithoutQuestionMark = pathnameWithoutHash.split('?')[0];
+
+    // create a url to the wiki page
+    const urlToWiki = baseUrl + 'wiki/' + pathnameWithoutQuestionMark + '/';
+
+    // create a link to the wiki page
+    const linkToWiki = document.createElement('a');
+
+    // add classes to the link
+    linkToWiki.classList.add('btn', 'btn-outline-secondary', 'mt-5');
+
+    // set the link's href TODO: 'https://github.com/WebOfTrust' in a variable
+    linkToWiki.setAttribute('href', 'https://github.com/WebOfTrust' + urlToWiki);
+
+    // set the link's text
+    linkToWiki.innerText = 'Edit on Wiki';
+
+    // set title attribute
+    linkToWiki.setAttribute('title', 'Edit this term definition on GitHub Wiki');
+
+    // set target attribute
+    linkToWiki.setAttribute('target', '_blank');
+
+    // set rel attribute
+    linkToWiki.setAttribute('rel', 'noopener noreferrer');
+
+    // add the link to the Wiki page at the end of the page
+    document.querySelector('.markdown').appendChild(linkToWiki);
+};
+
+// function to call when the route changes
+export function onRouteDidUpdate({ location, previousLocation }) {
+    // Don't execute if we are still on the same page; the lifecycle may be fired
+    // because the hash changes (e.g. when navigating between headings)
+    // if (location.pathname === previousLocation?.pathname) return;
+    createLinkToWikiPage();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/addUiToSidebar.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_addUiToSidebar.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_addUiToSidebar.js.md
+---
+
+# Source: clientModules/addUiToSidebar.js
+
+```
+/**
+ * @file This file adds filtering options plus a search field in the main menu below the “Glossary” menu item.
+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-11-03
+ */
+
+import overview from '/static/json/overview.json';
+import tippy from 'tippy.js';
+import 'tippy.js/themes/light-border.css';
+const paths = require('../docusaurus.paths.js');
+const baseUrl = paths.baseUrl;
+
+const entriesIndex = overview.values[0];
+
+function positionInArray(value) {
+    for (let i = 0; i < entriesIndex.length; i++) {
+        if (entriesIndex[i].trim() === value) return i;
+    }
+    return -1;
+}
+
+function getUniqueValues(data, columnIndex) {
+    const uniqueValues = new Set();
+    for (let i = 1; i < data.length; i++) {
+        const value = data[i][columnIndex];
+        if (value) {
+            uniqueValues.add(value);
+        }
+    }
+    return uniqueValues;
+}
+
+// overview.values is a 2D array and formColumnNumber, levelColumnNumber, typeColumnNumber are the respective column indexes
+const formColumnNumber = positionInArray('Form');
+const levelColumnNumber = positionInArray('level');
+const typeColumnNumber = positionInArray('Type');
+
+// Get unique values for each column
+const uniqueValuesForm = getUniqueValues(overview.values, formColumnNumber);
+const uniqueValuesLevel = getUniqueValues(overview.values, levelColumnNumber);
+const uniqueValuesType = getUniqueValues(overview.values, typeColumnNumber);
+
+// convert Set to Array
+let uniqueValuesArrayForm = Array.from(uniqueValuesForm);
+let uniqueValuesArrayLevel = Array.from(uniqueValuesLevel);
+let uniqueValuesArrayType = Array.from(uniqueValuesType);
+
+// Create a checkbox state object
+function createCheckboxState(uniqueValues) {
+    const checkboxState = {};
+    Array.from(uniqueValues).forEach((value) => {
+        checkboxState[value] = false;
+    });
+    return checkboxState;
+}
+
+const allFormCheckboxesState = createCheckboxState(uniqueValuesForm);
+const allLevelCheckboxesState = createCheckboxState(uniqueValuesLevel);
+const allTypeCheckboxesState = createCheckboxState(uniqueValuesType);
+
+function setLocalStorage() {
+    localStorage.setItem('allFormCheckboxesStateLocalStorage', JSON.stringify(allFormCheckboxesState));
+    localStorage.setItem('allLevelCheckboxesStateLocalStorage', JSON.stringify(allLevelCheckboxesState));
+    localStorage.setItem('allTypeCheckboxesStateLocalStorage', JSON.stringify(allTypeCheckboxesState));
+}
+
+function getLocalStorage() {
+    const allFormCheckboxesStateLocalStorage = JSON.parse(localStorage.getItem('allFormCheckboxesStateLocalStorage'));
+    const allLevelCheckboxesStateLocalStorage = JSON.parse(localStorage.getItem('allLevelCheckboxesStateLocalStorage'));
+    const allTypeCheckboxesStateLocalStorage = JSON.parse(localStorage.getItem('allTypeCheckboxesStateLocalStorage'));
+    return [allFormCheckboxesStateLocalStorage, allLevelCheckboxesStateLocalStorage, allTypeCheckboxesStateLocalStorage];
+}
+
+function nothingChecked() {
+    // If only one checkbox is checked, this function returns false, else it returns true. “some” is used to check if any checkbox in each category is checked. If any some call returns true, the function returns false, indicating that not "nothing is checked". If all some calls return false, the function returns true, indicating that "nothing is checked".
+    const formCheckboxes = document.querySelectorAll('input[type="checkbox"][data-form]');
+    const levelCheckboxes = document.querySelectorAll('input[type="checkbox"][data-level]');
+    const typeCheckboxes = document.querySelectorAll('input[type="checkbox"][data-type]');
+
+    const isFormChecked = Array.from(formCheckboxes).some(checkbox => checkbox.checked);
+    const isLevelChecked = Array.from(levelCheckboxes).some(checkbox => checkbox.checked);
+    const isTypeChecked = Array.from(typeCheckboxes).some(checkbox => checkbox.checked);
+
+    return !(isFormChecked || isLevelChecked || isTypeChecked);
+}
+
+function areAllCheckboxesFalse() {
+    const allCheckboxes = [allFormCheckboxesState, allLevelCheckboxesState, allTypeCheckboxesState];
+    for (const checkboxes of allCheckboxes) {
+        for (const checkbox in checkboxes) {
+            if (checkboxes[checkbox]) {
+                return false;
+            }
+        }
+    }
+    return true;
+}
+
+const addUiToSidebar = () => {
+    // if the sidebar is not present, do nothing
+    if (!document.querySelector('.theme-doc-sidebar-container')) {
+        return;
+    }
+
+    // “a[href=” does not work on iOS…
+    // const selectorString = ".theme-doc-sidebar-menu li a[href$='" + baseUrl + "docs/glossary']"
+    // const glossaryMainMenuItem = document.querySelector(selectorString);
+
+    //… so we use this instead:
+    let glossaryMainMenuItem;
+
+    const links = document.querySelectorAll(".theme-doc-sidebar-menu li a");
+    for (let i = 0; i < links.length; i++) {
+        const link = links[i];
+        const href = link.getAttribute('href');
+        const regex = new RegExp(baseUrl + 'docs/category/glossary$');
+        if (regex.test(href)) {
+            glossaryMainMenuItem = link;
+            break;
+        }
+    }
+
+    // if glossaryMainMenuItem does not exist, do nothing
+    if (!glossaryMainMenuItem) {
+        return
+    }
+    const parentElement = glossaryMainMenuItem.parentNode.parentNode; // This is the 'li'
+    const ulElement = parentElement.querySelector('ul');
+
+    parentElement.classList.add('glossary-menu');
+
+    // if the sidebar is present but the glossary menu is not present, do nothing
+    if (!ulElement) {
+        return
+    }
+
+    // now get the ul, so we skip the glossary link
+    const ulElementChildLinks = ulElement.querySelectorAll('a');
+
+    function createFilters() {
+        // add checkboxes to the sidebar, first add a container
+        if (document.querySelector('.check-container-form')) {
+            // checkboxes already added, do nothing
+            return;
+        }
+        const classesToAdd = ['border', 'me-2', 'mb-1', 'ps-2', 'pt-2', 'pe-2', 'rounded', 'd-block', 'bg-light', 'border-secondary'];
+        const fontSize = '0.8rem';
+
+        const checkboxFormContainer = document.createElement('div');
+        checkboxFormContainer.classList.add(...classesToAdd);
+        checkboxFormContainer.classList.add('check-container-form');
+        checkboxFormContainer.style.fontSize = fontSize;
+        checkboxFormContainer.innerHTML = `
Form:
?`
+
+        const checkboxLevelContainer = document.createElement('div');
+        checkboxLevelContainer.classList.add(...classesToAdd);
+        checkboxLevelContainer.classList.add('check-container-level');
+        checkboxLevelContainer.style.fontSize = fontSize;
+        checkboxLevelContainer.innerHTML = `
Level:
?`
+
+        const checkboxTypeContainer = document.createElement('div');
+        checkboxTypeContainer.classList.add(...classesToAdd);
+        checkboxTypeContainer.classList.add('check-container-type');
+        checkboxTypeContainer.style.fontSize = fontSize;
+        checkboxTypeContainer.innerHTML = `
Type:
?`
+
+        const searchContainer = document.createElement('div');
+        // searchContainer.classList.add(...classesToAdd);
+        searchContainer.classList.add('glossary-search-container', 'pe-2');
+        searchContainer.style.fontSize = fontSize;
+        searchContainer.innerHTML = `
Search:
`
+
+        // add the container with filters to the sidebar
+        if (ulElement) {
+            ulElement.insertBefore(searchContainer, ulElement.firstChild);
+            ulElement.insertBefore(checkboxLevelContainer, ulElement.firstChild);
+            ulElement.insertBefore(checkboxFormContainer, ulElement.firstChild);
+            ulElement.insertBefore(checkboxTypeContainer, ulElement.firstChild);
+        }
+
+        const explanationType = document.querySelector('.explanation-type');
+        const explanationLevel = document.querySelector('.explanation-level');
+        const explanationForm = document.querySelector('.explanation-form');
+
+        tippy(explanationType, {
+            triggerTarget: explanationType, // button
+            trigger: 'click',
+            arrow: true,
+            // arrowType: 'round',
+            theme: 'light-border',
+            allowHTML: true,
+            content: `
+                

+                    
Type

+                    
    
+                        
  • K: Keri-related
    • 
+                        
  • S: SSI related
    • 
+                        
  • G: General
    • 
+                    

+                

+                    
Level

+                    
    
+                        
  • 1: level 1
    • 
+                        
  • 2: level 2
    • 
+                        
  • 3: level 3
    • 
+                    

+                
+            `,
+        });
+        tippy(explanationForm, {
+            triggerTarget: explanationForm, // button
+            trigger: 'click',
+            arrow: true,
+            // arrowType: 'round',
+            theme: 'light-border',
+            allowHTML: true,
+            content: `
+                

+                    
Form

+                    
    
+                        
  • n: noun
    • 
+                        
  • r: verb
    • 
+                        
  • v: relation
    • 
+                        
  • a: adjective/adverb
    • 
+                    

+                

+            `,
+        });
+
+        const checkboxesForm = [];
+        const checkboxesLevel = [];
+        const checkboxesType = [];
+
+        // Form checkboxes
+        for (let i = 0; i < uniqueValuesArrayForm.length; i++) {
+            const checkboxForm = document.createElement('div');
+            checkboxForm.classList.add('form-check');
+            checkboxForm.classList.add('form-check-inline');
+            checkboxForm.innerHTML = `
+          
+          
+      `;
+            checkboxForm.addEventListener('click', (e) => {
+                checkboxesForm.forEach((cb, index) => {
+                    allFormCheckboxesState[cb.dataset.form] = cb.checked;
+                });
+                // update the menu items based on the checkboxData array
+                setMenuItems(e);
+            });
+
+            const formCheckContainer = document.querySelector('.check-container-form');
+            formCheckContainer.appendChild(checkboxForm);
+
+            checkboxesForm.push(checkboxForm.querySelector('input'));
+        }
+
+        // Level checkboxes
+        for (let i = 0; i < uniqueValuesArrayLevel.length; i++) {
+            const checkboxLevel = document.createElement('div');
+            checkboxLevel.classList.add('form-check');
+            checkboxLevel.classList.add('form-check-inline');
+
+            checkboxLevel.innerHTML = `
+          
+          
+      `;
+            checkboxLevel.addEventListener('click', (e) => {
+                checkboxesLevel.forEach((cb, index) => {
+                    allLevelCheckboxesState[cb.dataset.level] = cb.checked;
+                });
+                // update the menu items based on the checkboxData array
+                setMenuItems(e);
+            });
+
+            const levelCheckContainer = document.querySelector('.check-container-level');
+            levelCheckContainer.appendChild(checkboxLevel);
+
+            checkboxesLevel.push(checkboxLevel.querySelector('input'));
+        }
+        // Type checkboxes
+        for (let i = 0; i < uniqueValuesArrayType.length; i++) {
+            const checkboxType = document.createElement('div');
+            checkboxType.classList.add('form-check');
+            checkboxType.classList.add('form-check-inline');
+
+            checkboxType.innerHTML = `
+          
+          
+      `;
+            checkboxType.addEventListener('click', (e) => {
+                checkboxesType.forEach((cb, index) => {
+                    allTypeCheckboxesState[cb.dataset.type] = cb.checked;
+                });
+                // update the menu items based on the checkboxData array
+                setMenuItems(e);
+            });
+
+            const typeCheckContainer = document.querySelector('.check-container-type');
+            typeCheckContainer.appendChild(checkboxType);
+
+            checkboxesType.push(checkboxType.querySelector('input'));
+        }
+
+        // Search input
+        const searchInput = document.createElement('input');
+        searchInput.classList.add('form-control');
+        searchInput.classList.add('form-control-sm');
+        searchInput.classList.add('mb-1');
+        searchInput.classList.add('mt-1');
+        searchInput.classList.add('border', 'border-secondary');
+        searchInput.classList.add('search-input');
+        searchInput.setAttribute('type', 'text');
+        searchInput.setAttribute('placeholder', 'Search');
+        searchInput.setAttribute('aria-label', 'Search');
+        searchInput.setAttribute('aria-describedby', 'search-addon');
+        // searchInput.setAttribute('autocomplete', 'on');
+        searchInput.setAttribute('autofocus', 'on');
+        // empty the search input when the user clicks on it
+        searchInput.addEventListener('click', (e) => {
+            e.target.value = '';
+            removeDisplayNoneAllLinks();
+        });
+
+        searchInput.addEventListener('keyup', (e) => {
+            const searchValue = e.target.value.toLowerCase();
+            ulElementChildLinks.forEach((link) => {
+                if (link.innerText.toLowerCase().includes(searchValue)) {
+                    link.classList.remove('d-none');
+                } else {
+                    link.classList.add('d-none');
+                }
+            });
+        });
+        const searchContainerElement = document.querySelector('.glossary-search-container');
+        searchContainerElement.appendChild(searchInput);
+
+    }
+
+    createFilters();
+
+    document.querySelector('.navbar__toggle').addEventListener('click', (e) => {
+        createFilters();
+    });
+
+    function greyOutAllLinks() {
+        ulElementChildLinks.forEach((link) => {
+            link.classList.add('greyed-out');
+        });
+    }
+    function removeGreyOutAllLinks() {
+        ulElementChildLinks.forEach((link) => {
+            link.classList.remove('greyed-out');
+        });
+    }
+
+    function removeDisplayNoneAllLinks() {
+        ulElementChildLinks.forEach((link) => {
+            link.classList.remove('d-none');
+        });
+    }
+
+    function setMenuItems(e) {
+        let eTargetChecked = e.target.checked;
+        let eTargetDatasetFilter = e.target.dataset.filter
+
+        // update the checkboxes state object
+        if (e.target.dataset.form !== undefined) {
+            allFormCheckboxesState[e.target.dataset.form] = true;
+        }
+        if (e.target.dataset.level !== undefined) {
+            allLevelCheckboxesState[e.target.dataset.level] = true;
+        }
+        if (e.target.dataset.type !== undefined) {
+            allTypeCheckboxesState[e.target.dataset.type] = true;
+        }
+
+        // loop through all links in the glossary menu
+        ulElementChildLinks.forEach((link) => {
+            // loop through all entries in the overview.json
+            for (let i = 0; i < overview.values.length; i++) {
+
+                // if the link text matches the term in the overview.json
+                if (overview.values[i][positionInArray('Term')].trim() === link.innerText) {
+                    // now we can lookup the form, level and type of the entry
+
+                    // if the checkbox belongs to the “Form” (name of the column in the source data, has nothing to do with html forms) filter
+                    if (eTargetDatasetFilter === "form") {
+                        // if the checkbox value matches the value in the overview.json
+                        if (e.target.dataset.form === overview.values[i][positionInArray('Form')]) {
+                            // then it should control this menu item
+                            // the state of the checkbox determines if the menu item is greyed-out or not
+                            // if the checkbox is checked then remove the greyed-out class
+
+                            if (eTargetChecked) {
+                                link.classList.remove('greyed-out');
+                            } else {
+                                link.classList.add('greyed-out');
+                            }
+                        }
+                    }
+                    if (eTargetDatasetFilter === "level") {
+                        // if the checkbox value matches the value in the overview.json
+                        if (e.target.dataset.level === overview.values[i][positionInArray('level')]) {
+                            // if the checkbox is checked then remove the greyed-out class
+
+                            if (eTargetChecked) {
+                                link.classList.remove('greyed-out');
+                            } else {
+                                link.classList.add('greyed-out');
+                            }
+                        }
+                    }
+                    if (eTargetDatasetFilter === "type") {
+                        // if the checkbox value matches the value in the overview.json
+                        if (e.target.dataset.type === overview.values[i][positionInArray('Type')]) {
+                            // if the checkbox is checked then remove the greyed-out class
+
+                            if (eTargetChecked) {
+                                link.classList.remove('greyed-out');
+                            } else {
+                                link.classList.add('greyed-out');
+                            }
+                        }
+                    }
+
+                }
+
+                // for (const checkbox in allFormCheckboxesState) {
+                //     if (checkbox === formValue) {
+                //         link.classList.remove('greyed-out');
+                //     } else {
+                //         link.classList.add('greyed-out');
+                //     }
+                // }
+
+            }
+        });
+    }
+};
+
+// function to call when the route changes
+export function onRouteDidUpdate({ location, previousLocation }) {
+    // Don't execute if we are still on the same page; the lifecycle may be fired
+    // because the hash changes (e.g. when navigating between headings)
+    // if (location.pathname === previousLocation?.pathname) return;
+    addUiToSidebar();
+}
+```
+
+
+
+
+---
+title: Source: clientModules/addDataTypes.js
+source_url:
+  html: https://weboftrust.github.io/keridoc/JSDoc/clientModules_addDataTypes.js
+  md: https://weboftrust.github.io/keridoc/JSDoc/clientModules_addDataTypes.js.md
+---
+
+# Source: clientModules/addDataTypes.js
+
+```
+/**
+ * @file This file adds html attributes with information to the article html-element.
+ * The info is fetched from a json file.
+ * @example An article element could look like this:
+ * 
…

+ * @author Kor Dwarshuis
+ * @version 1.0.0
+ * @since 2023-04-01
+ */
+
+import overview from '@site/static/json/overview.json';
+
+const addDataTypes = () => {
+  //TODO: make generic function for column number finder
+
+  // Find the column number of the column with the name 'Shortened version static copy'
+  const termColumnName = 'Term';
+  // loop through the first entry of the overview.json and find the column number of the column with the name 'Shortened version static copy'
+  let termColumnNumber;
+  for (let i = 0; i < overview.values[0].length; i++) {
+    if (overview.values[0][i].trim() === termColumnName) {
+      termColumnNumber = i;
+    }
+  }
+
+  // Find the column number of the column with the name 'Shortened version static copy'
+  const typeColumnName = 'Type';
+  // loop through the first entry of the overview.json and find the column number of the column with the name 'Shortened version static copy'
+  let typeColumnNumber;
+  for (let i = 0; i < overview.values[0].length; i++) {
+    if (overview.values[0][i].trim() === typeColumnName) {
+      typeColumnNumber = i;
+    }
+  }
+
+  // Find the column number of the column with the name 'Shortened version static copy'
+  const levelColumnName = 'level';
+  // loop through the first entry of the overview.json and find the column number of the column with the name 'Shortened version static copy'
+  let levelColumnNumber;
+  for (let i = 0; i < overview.values[0].length; i++) {
+    if (overview.values[0][i].trim() === levelColumnName) {
+      levelColumnNumber = i;
+    }
+  }
+
+  if (document.querySelector('.markdown h1:first-child')) {
+    const heading = document.querySelector('.markdown h1:first-child').innerText;
+
+    // for every row in overview.json except the first one
+    overview.values.forEach((row, index) => {
+      if (index < 1) return;
+      if (
+        heading === row[termColumnNumber] &&
+        // if the level is not empty
+        row[levelColumnNumber] !== ''
+      ) {
+
+        // add row[levelColumnNumber] to data-set of body
+        document.querySelector('article').dataset.level =
+          row[levelColumnNumber];
+        document.querySelector('article').classList.add('level');
+        document
+          .querySelector('article')
+          .classList.add('level' + row[levelColumnNumber]);
+        document.querySelector('article').classList.add(row[levelColumnNumber]);
+
+      }
+
+      if (
+        heading === row[termColumnNumber] &&
+        // if the type is not empty
+        row[typeColumnNumber] !== ''
+      ) {
+        // add row[typeColumnNumber] to data-set of body
+        document.querySelector('article').dataset.type = row[typeColumnNumber];
+        document.querySelector('article').classList.add('type');
+        document
+          .querySelector('article')
+          .classList.add('type' + row[typeColumnNumber]);
+        document.querySelector('article').classList.add(row[typeColumnNumber]);
+      }
+    });
+  }
+};
+
+export function onRouteDidUpdate({ location, previousLocation }) {
+  // Don't execute if we are still on the same page; the lifecycle may be fired
+  // because the hash changes (e.g. when navigating between headings)
+  // if (location.pathname === previousLocation?.pathname) return;
+  addDataTypes();
+}
+```
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/vlei
+  md: https://weboftrust.github.io/keridoc/slack/html/vlei.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/signify
+  md: https://weboftrust.github.io/keridoc/slack/html/signify.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/signify-dev
+  md: https://weboftrust.github.io/keridoc/slack/html/signify-dev.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/random
+  md: https://weboftrust.github.io/keridoc/slack/html/random.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/licencing
+  md: https://weboftrust.github.io/keridoc/slack/html/licencing.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/keripy
+  md: https://weboftrust.github.io/keridoc/slack/html/keripy.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/keriml
+  md: https://weboftrust.github.io/keridoc/slack/html/keriml.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/keri-swift
+  md: https://weboftrust.github.io/keridoc/slack/html/keri-swift.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/keri-rs
+  md: https://weboftrust.github.io/keridoc/slack/html/keri-rs.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/keri-dev
+  md: https://weboftrust.github.io/keridoc/slack/html/keri-dev.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/keri-cesr-licensing
+  md: https://weboftrust.github.io/keridoc/slack/html/keri-cesr-licensing.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/introductions
+  md: https://weboftrust.github.io/keridoc/slack/html/introductions.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/index
+  md: https://weboftrust.github.io/keridoc/slack/html/index.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/iiw-nov-2022
+  md: https://weboftrust.github.io/keridoc/slack/html/iiw-nov-2022.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/governance
+  md: https://weboftrust.github.io/keridoc/slack/html/governance.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/general
+  md: https://weboftrust.github.io/keridoc/slack/html/general.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/edu
+  md: https://weboftrust.github.io/keridoc/slack/html/edu.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/did-keri
+  md: https://weboftrust.github.io/keridoc/slack/html/did-keri.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/did-keri-dev
+  md: https://weboftrust.github.io/keridoc/slack/html/did-keri-dev.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/cesr
+  md: https://weboftrust.github.io/keridoc/slack/html/cesr.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: Slack Archive
+source_url:
+  html: https://weboftrust.github.io/keridoc/slack/html/cesr-dev
+  md: https://weboftrust.github.io/keridoc/slack/html/cesr-dev.md
+---
+
+# Slack Archive
+
+
+
+
+---
+title: 1     
+KERI Specifications
+source_url:
+  html: https://weboftrust.github.io/keridoc/html/GLEIF/2022-12-06_id_l-id_b-Ecosystem-Governance-Framework-Technical-Requirements-Part1-KERI-Infrastructure-Prep-1.0-Publication_v0.6_work
+  md: https://weboftrust.github.io/keridoc/html/GLEIF/2022-12-06_id_l-id_b-Ecosystem-Governance-Framework-Technical-Requirements-Part1-KERI-Infrastructure-Prep-1.0-Publication_v0.6_work.md
+---
+
+# 1     
+KERI Specifications
+
+
+
+
+---
+title: 1     
+Related Specifications
+source_url:
+  html: https://weboftrust.github.io/keridoc/html/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/keridoc/html/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: 1      
+Introduction
+source_url:
+  html: https://weboftrust.github.io/keridoc/html/GLEIF/2022-11-30_Legal-Entity-QVI-AUTH-vLEI-Credential-GF-Prep-1.0-Publication_v0.6_work
+  md: https://weboftrust.github.io/keridoc/html/GLEIF/2022-11-30_Legal-Entity-QVI-AUTH-vLEI-Credential-GF-Prep-1.0-Publication_v0.6_work.md
+---
+
+# 1      
+Introduction
+
+
+
+
+---
+title: Tags
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/tags/index
+  md: https://weboftrust.github.io/keridoc/docs/tags/index.md
+---
+
+# Tags
+
+-   [ACDC1](https://weboftrust.github.io/keridoc/docs/tags/acdc.md)
+
+* * *
+
+
+
+
+---
+title: KERI Suite Glossary in ToIP style
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/glossary-toip-style/index
+  md: https://weboftrust.github.io/keridoc/docs/glossary-toip-style/index.md
+---
+
+# KERI Suite Glossary in ToIP style
+
+
+
+
+---
+title: Dictionary SSI
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/dictionary/index
+  md: https://weboftrust.github.io/keridoc/docs/dictionary/index.md
+---
+
+# Dictionary SSI
+
+Toggle GlossariesAll onAll off
+
+* * *
+
+* * *
+
+-   ## [(risk) control](#\(risk\)control)
+
+    -   ### digital.govt.nz
+
+        (noun) measure that maintains and / or modifies risk\[Source: ISO 31073:2022 modified to add note 3\]Additional notes:Note 1: Risk controls include, but are not limited to, any process, policy, device, practice, or other conditions and / or actions which maintain and / or modify risk.Note 2: Risk controls do not always exert the intended or assumed modifying effect.Note 3: When using the Assessing identification risk guidance to calculate levels of identification process, these processes are not included as risk controls.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [AAL](#h.l6kidod3jk1m)
+
+    -   ### ToIP
+
+        See: [authenticator assurance level](#h.a7560ebfrt4m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ABAC](#h.mzsxtamnq3ko)
+
+    -   ### ToIP
+
+        See: [attribute-based access control](#h.ckr2atznm0o).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ACDC](#h.8qlmnalwgxgy)
+
+    -   ### ToIP
+
+        See: [Authentic Chained Data Container](#h.1yn1ii2u6xtt).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # ACDC
+
+        ###### See
+
+        [authentic chained data container](https://weboftrust.github.io/keridoc/docs/glossary/authentic-chained-data-container.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ADC](#ADC)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/adc)
+
+    -   ### WebOfTrust
+
+        # ADC
+
+        ###### See
+
+        [Authentic data container](https://weboftrust.github.io/keridoc/docs/glossary/authentic-data-container.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ADR](#ADR)
+
+    -   ### WebOfTrust
+
+        # ADR
+
+        ###### See
+
+        [Architectural Decision Record](https://weboftrust.github.io/keridoc/docs/glossary/architectural-decision-record.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [AID](#AID)
+
+    -   ### Nist
+
+        A globally unique identifier of a card application as defined in ISO/IEC 7816-4.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/aid)
+
+    -   ### ToIP
+
+        See [autonomic identifier](#h.bz098kwwc559).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # AID
+
+        ###### See
+
+        [Autonomic identifier](https://weboftrust.github.io/keridoc/docs/glossary/autonomic-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [AID controlled identifiers](#AIDcontrolledidentifiers)
+
+    -   ### ToIP (DID:Webs)
+
+        Any identifier, including did:webs DIDs, that have the same AID are by definition referencing the same identity. As defined in the KERI specification
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [APC](#APC)
+
+    -   ### WebOfTrust
+
+        # APC
+
+        ###### See
+
+        [Authentic provenance chain](https://weboftrust.github.io/keridoc/docs/glossary/authentic-provenance-chain.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [API](#API)
+
+    -   ### Nist
+
+        A system access point or library function that has a well-defined syntax and is accessible from application programs or user code to provide well-defined functionality.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/api)
+
+    -   ### WebOfTrust
+
+        # API
+
+        ###### See
+
+        [Application programming interface](https://weboftrust.github.io/keridoc/docs/glossary/application-programming-interface.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [AVR](#AVR)
+
+    -   ### WebOfTrust
+
+        # AVR
+
+        ###### See
+
+        [Authorized vLEI Representative](https://weboftrust.github.io/keridoc/docs/glossary/authorized-vlei-representative.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Action](#action)
+
+    -   ### Essif-Lab
+
+        something that is actually done (a 'unit of work' that is executed) by a single [actor](https://essif-lab.github.io/framework/docs/terms/actor) (on behalf of a given [party](https://essif-lab.github.io/framework/docs/terms/party)), as a single operation, in a specific context.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Actor](#actor)
+
+    -   ### Essif-Lab
+
+        entity that can act (do things/execute [action](https://essif-lab.github.io/framework/docs/terms/action)), e.g. people, machines, but not [organization](https://essif-lab.github.io/framework/docs/terms/organization).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Advertisement](#advertisement)
+
+    -   ### Essif-Lab
+
+        an offer by a specific [party](https://essif-lab.github.io/framework/docs/terms/party) to provide a (type of) [credential](https://essif-lab.github.io/framework/docs/terms/credential), where the offer includes (a reference to) the syntax and semantics specifications of that [credential](https://essif-lab.github.io/framework/docs/terms/credential), and also lists various other characteristics that enable other [parties](https://essif-lab.github.io/framework/docs/terms/party) to decide whether or not a [credential](https://essif-lab.github.io/framework/docs/terms/credential) that the advertising [party](https://essif-lab.github.io/framework/docs/terms/party) has issued under this offer, is [valid](https://essif-lab.github.io/framework/docs/terms/validate) to be processed in one or more of its [information processes](https://essif-lab.github.io/framework/docs/terms/information-process).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Agent](#agent)
+
+    -   ### Essif-Lab
+
+        an [actor](https://essif-lab.github.io/framework/docs/terms/actor) that is executing an [action](https://essif-lab.github.io/framework/docs/terms/action) on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party) (called the [principal](https://essif-lab.github.io/framework/docs/terms/principal) of that [actor](https://essif-lab.github.io/framework/docs/terms/actor)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Assertion](#assertion)
+
+    -   ### Essif-Lab
+
+        a declaration/statement, made by a specific [party](https://essif-lab.github.io/framework/docs/terms/party), that something is the case.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Assessment Framework](#assessment-framework)
+
+    -   ### Essif-Lab
+
+        the combination of a set of criteria that an auditor can assess by applying them to an [entity](https://essif-lab.github.io/framework/docs/terms/entity) (of a specific kind), and the procedures that this auditor will follow for doing so, for the purpose of establishing the extent in which that [entity](https://essif-lab.github.io/framework/docs/terms/entity) conforms to a stated set of requirements.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Attribute](#attribute)
+
+    -   ### Essif-Lab
+
+        [data](https://essif-lab.github.io/framework/docs/terms/data), that represents a characteristic that a [party](https://essif-lab.github.io/framework/docs/terms/party) (the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of the [attribute](https://essif-lab.github.io/framework/docs/terms/attribute)) has attributed to an [entity](https://essif-lab.github.io/framework/docs/terms/entity) (which is the [subject](https://essif-lab.github.io/framework/docs/terms/subject) of that attribute).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+    -   ### TSWG (ACDC)
+
+        a top-level field map within an ACDC that provides a property of an entity that is inherent or assigned to the entity.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Authentic Chained Data Container](#h.1yn1ii2u6xtt)
+
+    -   ### ToIP
+
+        A digital [data](#h.o783ayrrkc6g) structure designed for both cryptographic [verification](#h.2bnb6g8na7cu) and [chaining](#h.kgtwd73pdfae) of data containers. ACDC may be used for [digital credentials](#h.ddna9lucn4k6).
+
+        For more information, see: [ToIP ACDC Task Force](https://www.google.com/url?q=https://wiki.trustoverip.org/display/HOME/ACDC%2B%2528Authentic%2BChained%2BData%2BContainer%2529%2BTask%2BForce&sa=D&source=editors&ust=1718703186587727&usg=AOvVaw2-WTCW8gNZEYtSILgPq8f6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### TSWG (Keri)
+
+        a directed acyclic graph with properties to provide a verifiable chain of proof-of-authorship. See the full specification
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Authority (Centralized or Decentralized)](#authority-centralized-or-decentralized)
+
+    -   ### Essif-Lab
+
+        a [party](https://essif-lab.github.io/framework/docs/terms/party) of which certain decisions, ideas, rules etc. are followed by other [parties](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Autonomic Identifier](#AutonomicIdentifier)
+
+    -   ### TSWG (ACDC)
+
+        a self-managing cryptonymous identifier that must be self-certifying (self-authenticating) and must be encoded in CESR as a qualified Cryptographic Primitive.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Autonomic Identifier (AID)](#AutonomicIdentifier\(AID\))
+
+    -   ### TSWG (CESR)
+
+        a self-managing cryptonymous identifier that must be self-certifying (self-authenticating) and must be encoded in CESR as a qualified Cryptographic Primitive.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Autonomic identifier](#Autonomicidentifier)
+
+    -   ### TSWG (Keri)
+
+        a self-managing cryptonymous identifier that must be self-certifying (self-authenticating) and must be encoded in CESR as a qualified Cryptographic primitive.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Autonomic identity system](#Autonomicidentitysystem)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Autonomic namespace](#Autonomicnamespace)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [BADA](#BADA)
+
+    -   ### WebOfTrust
+
+        # BADA
+
+        ###### See
+
+        [Best available data acceptance mechanism](https://weboftrust.github.io/keridoc/docs/glossary/best-available-data-acceptance-mechanism.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [BADA-RUN](#BADARUN)
+
+    -   ### ToIP (DID:Webs)
+
+        Best available data acceptance - Read/Update/Nullify provides a medium level of security because events are ordered in a consistent way, using a combination of date-time and a key state. The latest event is the one with the latest date-time for the latest key state. See The KERI spec for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [BFT](#BFT)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/bft)
+
+    -   ### WebOfTrust
+
+        # BFT
+
+        ###### See
+
+        [Byzantine fault tolerance](https://weboftrust.github.io/keridoc/docs/glossary/byzantine-fault-tolerance.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [BOLA](#BOLA)
+
+    -   ### WebOfTrust
+
+        # BOLA
+
+        ###### See
+
+        [Broken Object Level Authorization](https://weboftrust.github.io/keridoc/docs/glossary/broken-object-level-authorization.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Backer](#Backer)
+
+    -   ### TSWG (Keri)
+
+        an alternative to a traditional KERI based Witness commonly using Distributed Ledger Technology (DLT) to store the KEL for an identifier.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [C2PA](#h.ad62zphsbkd8)
+
+    -   ### ToIP
+
+        See: [Coalition for Content Provenance and Authenticity](#h.38i7kn574fiz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [CA](#h.jg9jwebqbw5x)
+
+    -   ### ToIP
+
+        See: [certificate authority](#h.dm6pt5kg2uim).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [CAI](#h.m7kywkkniutc)
+
+    -   ### ToIP
+
+        See: [Content Authenticity Initiative](#h.9jxxi75k6blt).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [CBOR](#CBOR)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/cbor)
+
+    -   ### WebOfTrust
+
+        # CBOR
+
+        ###### See
+
+        [Concise Binary Object Representation](https://weboftrust.github.io/keridoc/docs/glossary/concise-binary-object-representation.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [CESR](#CESR)
+
+    -   ### WebOfTrust
+
+        # CESR
+
+        ###### See
+
+        [composable event streaming representation](https://weboftrust.github.io/keridoc/docs/glossary/composable-event-streaming-representation.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [CLC](#CLC)
+
+    -   ### WebOfTrust
+
+        # CLC
+
+        ###### See
+
+        [Chain link confidential](https://weboftrust.github.io/keridoc/docs/glossary/chain-link-confidentiality.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [CRUD](#CRUD)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/crud)
+
+    -   ### WebOfTrust
+
+        # CRUD
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/RUN.md) which is the acronym for the new peer-to-peer end-verifiable monotonic update policy.
+
+        ###### OOBI related
+
+        We [RUN off the CRUD](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [CSPRNG](#CSPRNG)
+
+    -   ### WebOfTrust
+
+        # CSPRNG
+
+        ###### Definition
+
+        means "Cryptographically Secure Pseudorandom Number Generator" which means that a sequence of numbers (bits, bytes...) that is produced from an algorithm which is deterministic (the sequence is generated from some unknown internal state), hence pseudorandom, is also 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))
+
+        ###### See also
+
+        [PRNG](https://weboftrust.github.io/keridoc/docs/glossary/PRNG.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [CT](#CT)
+
+    -   ### Nist
+
+        A framework for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed in a manner that allows anyone to audit CA activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. (Experimental RFC 6962)
+
+        [Learn more](https://csrc.nist.gov/glossary/term/ct)
+
+    -   ### WebOfTrust
+
+        # CT
+
+        ###### See
+
+        [Certificate transparency](https://weboftrust.github.io/keridoc/docs/glossary/certificate-transparency.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Capability (of a Party)](#capability-of-a-party)
+
+    -   ### Essif-Lab
+
+        the (named) combination of (a) the means of a specific [party](https://essif-lab.github.io/framework/docs/terms/party) to get something done, (b) the [party](https://essif-lab.github.io/framework/docs/terms/party) [governance](https://essif-lab.github.io/framework/docs/terms/governance) process that ensures that its (business) [policies](https://essif-lab.github.io/framework/docs/terms/policy) for getting that something done are being created and maintained, and (c) the [party](https://essif-lab.github.io/framework/docs/terms/party) [management](https://essif-lab.github.io/framework/docs/terms/management) process that creates and maintains the (operational) [policies](https://essif-lab.github.io/framework/docs/terms/policy), such that every [employee](https://essif-lab.github.io/framework/docs/terms/employee) that has a task in getting this something done can find and interpret a [policy](https://essif-lab.github.io/framework/docs/terms/policy) and use it as it executes [action](https://essif-lab.github.io/framework/docs/terms/action) in such tasks.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Capability (of an Actor)](#capability-of-an-actor)
+
+    -   ### Essif-Lab
+
+        the potential of an [actor](https://essif-lab.github.io/framework/docs/terms/actor) to execute a (named) coherent set of [action](https://essif-lab.github.io/framework/docs/terms/action) (a 'function', or 'task') on behalf of some [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Chain-link Confidential Disclosure](#ChainlinkConfidentialDisclosure)
+
+    -   ### TSWG (ACDC)
+
+        contractual restrictions and liability imposed on a recipient of a disclosed ACDC 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 unpermissioned exploitation of the data disclosed via an ACDC.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Coalition for Content Provenance and Authenticity](#h.38i7kn574fiz)
+
+    -   ### ToIP
+
+        C2PA is a Joint Development Foundation project of the Linux Foundation that addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content.
+
+        Also known as: [C2PA](#h.ad62zphsbkd8).
+
+        See also: [Content Authenticity Initiative](#h.9jxxi75k6blt).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Colleague](#colleague)
+
+    -   ### Essif-Lab
+
+        two or more (digital or non-digital) [agent](https://essif-lab.github.io/framework/docs/terms/agent) that have the same [principal](https://essif-lab.github.io/framework/docs/terms/principal) (i.e. [party](https://essif-lab.github.io/framework/docs/terms/party) on whose behalf they are executing an [action](https://essif-lab.github.io/framework/docs/terms/action)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Commitment Decision](#commitment-decision)
+
+    -   ### Essif-Lab
+
+        the decision of that [party](https://essif-lab.github.io/framework/docs/terms/party) whether or not to commit to that [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction), i.e. (promise) to fulfill the [obligation](https://essif-lab.github.io/framework/docs/terms/obligation) that the associated [transaction agreement proposal](https://essif-lab.github.io/framework/docs/terms/transaction-proposal) would impose on that [party](https://essif-lab.github.io/framework/docs/terms/party) once it were signed.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Communication Channel](#communication-channel)
+
+    -   ### Essif-Lab
+
+        a (digital or non-digital) means by which two [actor](https://essif-lab.github.io/framework/docs/terms/actor) can exchange messages with one another.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Communication Session](#communication-session)
+
+    -   ### Essif-Lab
+
+        a time interval during which two [actor](https://essif-lab.github.io/framework/docs/terms/actor) have an established [communication channel](https://essif-lab.github.io/framework/docs/terms/communication-channel) that does not exist outside of that time interval.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Community](#community)
+
+    -   ### Essif-Lab
+
+        a [party](https://essif-lab.github.io/framework/docs/terms/party), consisting of at least two different [parties](https://essif-lab.github.io/framework/docs/terms/party) (the members of the [community](https://essif-lab.github.io/framework/docs/terms/community)) that seek to collaborate with each other so that each of them can achieve its individual [objective](https://essif-lab.github.io/framework/docs/terms/objective) more efficiently and/or effectively.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Compact Disclosure](#CompactDisclosure)
+
+    -   ### TSWG (ACDC)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Compliance](#compliance)
+
+    -   ### Essif-Lab
+
+        the state of realization of a set of conformance criteria or normative framework of a [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Compliance Objective](#compliance-objective)
+
+    -   ### Essif-Lab
+
+        an [objective](https://essif-lab.github.io/framework/docs/terms/objective), owned by a [party](https://essif-lab.github.io/framework/docs/terms/party), that aims to reach and maintain a state of affairs in which a specific set of [entities](https://essif-lab.github.io/framework/docs/terms/entity) that this [party](https://essif-lab.github.io/framework/docs/terms/party) controls are in accordance with a specific set of requirements (e.g., laws, regulations, standards, etc.).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Compliance level](#compliance-level)
+
+    -   ### Essif-Lab
+
+        a measure for stating how well an [entity](https://essif-lab.github.io/framework/docs/terms/entity) conforms with a stated (set of) requirement(s).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Compliance management](#compliance-management)
+
+    -   ### Essif-Lab
+
+        the process that is run by (or on behalf of) a specific [party](https://essif-lab.github.io/framework/docs/terms/party) for the purpose of [managing](https://essif-lab.github.io/framework/docs/terms/management) its [compliance objectives](https://essif-lab.github.io/framework/docs/terms/compliance-objective).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Composability](#Composability)
+
+    -   ### TSWG (CESR)
+
+        short for text-binary concatenation composability. An encoding has Composability when any set of Self-Framing 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.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Concept](#concept)
+
+    -   ### Essif-Lab
+
+        the ideas/thoughts behind a classification of [entities](https://essif-lab.github.io/framework/docs/terms/entity) (what makes [entities](https://essif-lab.github.io/framework/docs/terms/entity) in that class 'the same').
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Concise Binary Object Representation](#ConciseBinaryObjectRepresentation)
+
+    -   ### TSWG (Keri)
+
+        a binary serialization format, similar in concept to JSON but aiming for greater conciseness. Defined in \[RFC7049\].
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Configuration traits](#Configurationtraits)
+
+    -   ### TSWG (Keri)
+
+        a list of specially defined strings representing a configuration of a KEL. See (Configuration traits field)\[#configuration-traits-field\].
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Content Authenticity Initiative](#h.9jxxi75k6blt)
+
+    -   ### ToIP
+
+        The Content Authenticity Initiative (CAI) is an association founded in November 2019 by Adobe, the New York Times and [Tw](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Twitter&sa=D&source=editors&ust=1718703186617117&usg=AOvVaw3SdwI2M7lGKb1kYssr9h77)i[tter](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Twitter&sa=D&source=editors&ust=1718703186617276&usg=AOvVaw0cuZ5rwCKPM4uvQ-mw7VJ-). The CAI promotes an industry standard for provenance [metadata](#h.t63bf0ssndfd) defined by the [C2PA](#h.ad62zphsbkd8). The CAI cites curbing disinformation as one motivation for its activities.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Content_Authenticity_Initiative&sa=D&source=editors&ust=1718703186617591&usg=AOvVaw0sQC-CvuHrBH_AI0pOU-p_).
+
+        Also known as: [CAI](#h.m7kywkkniutc).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Contractually Protected Disclosure](#ContractuallyProtectedDisclosure)
+
+    -   ### TSWG (ACDC)
+
+        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 disclose 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.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Control](#control)
+
+    -   ### Essif-Lab
+
+        the combination of resources (e.g. people, tools, budgets, time) and processes that are tasked to realize a specific [control objective](https://essif-lab.github.io/framework/docs/terms/control-objective) of a particular [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Control Objective](#control-objective)
+
+    -   ### Essif-Lab
+
+        an [objective](https://essif-lab.github.io/framework/docs/terms/objective), owned by a [party](https://essif-lab.github.io/framework/docs/terms/party), that aims to contribute to the realization of another (set of) [objective](https://essif-lab.github.io/framework/docs/terms/objective) of that [party](https://essif-lab.github.io/framework/docs/terms/party), by producing results that this [party](https://essif-lab.github.io/framework/docs/terms/party) needs to realize these other [objective](https://essif-lab.github.io/framework/docs/terms/objective).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Control Process](#control-process)
+
+    -   ### Essif-Lab
+
+        a process, [owned](https://essif-lab.github.io/framework/docs/terms/owned) and run by a [party](https://essif-lab.github.io/framework/docs/terms/party), to ensure that a specific subset of its control [objective](https://essif-lab.github.io/framework/docs/terms/objective) are realized.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Control level](#control-level)
+
+    -   ### Essif-Lab
+
+        a measure for the efficiency and effectiveness in which a [control](https://essif-lab.github.io/framework/docs/terms/controller) produces the results specified by its [control objective](https://essif-lab.github.io/framework/docs/terms/control-objective)
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Controller](#controller)
+
+    -   ### Essif-Lab
+
+        the role that an [actor](https://essif-lab.github.io/framework/docs/terms/actor) performs as it is executing actions on that [entity](https://essif-lab.github.io/framework/docs/terms/entity) for the purpose of ensuring that the [entity](https://essif-lab.github.io/framework/docs/terms/entity) will act/behave, or be used, in a particular way.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+    -   ### TSWG (ACDC)
+
+        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. See controller.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Controllership](#controllership)
+
+    -   ### Essif-Lab
+
+        the [capability](https://essif-lab.github.io/framework/docs/terms/capability) of an [actor](https://essif-lab.github.io/framework/docs/terms/actor) to execute [action](https://essif-lab.github.io/framework/docs/terms/action) on a specific [entity](https://essif-lab.github.io/framework/docs/terms/entity) for the purpose of ensuring that this [entity](https://essif-lab.github.io/framework/docs/terms/entity) will act/behave, or be used, in a particular way.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Corpus of Terminology](#corpus-of-terminology)
+
+    -   ### Essif-Lab
+
+        the documentation that describes the [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) around a set of [term](https://essif-lab.github.io/framework/docs/terms/term) and [concept](https://essif-lab.github.io/framework/docs/terms/concept).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Credential](#credential)
+
+    -   ### Essif-Lab
+
+        data, representing a set of [assertion](https://essif-lab.github.io/framework/docs/terms/assertion) (claims, statements), authored and signed by, or on behalf of, a specific [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Credential Catalogue](#credential-catalogue)
+
+    -   ### Essif-Lab
+
+        a functional component that has the [capability](https://essif-lab.github.io/framework/docs/terms/capability-of-an-actor) to register and advertise the information about [credential types](https://essif-lab.github.io/framework/docs/terms/credential-type) that their respective [governing parties](https://essif-lab.github.io/framework/docs/terms/governance) have decided to disclose so as to enable other [parties](https://essif-lab.github.io/framework/docs/terms/party) to decide whether or not it is beneficial for them to use [credential](https://essif-lab.github.io/framework/docs/terms/credential) of such types.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Credential Type](#credential-type)
+
+    -   ### Essif-Lab
+
+        the specification of the contents, properties, constraints etc. that [credential](https://essif-lab.github.io/framework/docs/terms/credential) of this type must have/comply with.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Cryptographic Primitive](#CryptographicPrimitive)
+
+    -   ### TSWG (CESR)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Cryptonym](#Cryptonym)
+
+    -   ### TSWG (Keri)
+
+        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) \[13\] \[14\] \[12\] \[11\]. A Cryptonym is a type of Primitive. Due to the entropy in its derivation, a Cyptonym is a universally unique identifier and only the Controller of the secret salt or seed 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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Current threshold](#Currentthreshold)
+
+    -   ### TSWG (Keri)
+
+        represents the number or fractional weights of signatures from the given set of current keys required to be attached to a Message for the Message to be considered fully signed.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [DAG](#DAG)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/dag)
+
+    -   ### WebOfTrust
+
+        # DAG
+
+        ###### See
+
+        [Directed acyclic graph](https://weboftrust.github.io/keridoc/docs/glossary/directed-acyclic-graph.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [DAR](#DAR)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/dar)
+
+    -   ### WebOfTrust
+
+        # DAR
+
+        ###### See
+
+        [Designated Authorized Representatives](https://weboftrust.github.io/keridoc/docs/glossary/designated-authorized-representative.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [DEL](#DEL)
+
+    -   ### WebOfTrust
+
+        # DEL
+
+        ###### See
+
+        [Duplicitous event log](https://weboftrust.github.io/keridoc/docs/glossary/duplicitous-event-log.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [DHT](#DHT)
+
+    -   ### WebOfTrust
+
+        # DHT
+
+        ###### See
+
+        [Distributed hash table](https://weboftrust.github.io/keridoc/docs/glossary/distributed-hash-table.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [DID](#DID)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/did)
+
+    -   ### ToIP
+
+        See: [decentralized identifier](#h.x1jp59hgbk2l).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # DID
+
+        ###### See
+
+        [Decentralized Identifier](https://github.com/trustoverip/acdc/wiki/decentralized-identifier)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [DID URL](#h.2lqom8dcqvzy)
+
+    -   ### ToIP
+
+        A [DID](#h.zh539v9ul471) plus any additional syntactic component that conforms to the definition in section 3.2 of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.google.com/url?q=https://www.w3.org/TR/did-core/&sa=D&source=editors&ust=1718703186648719&usg=AOvVaw0mnda0S_lxDlwrGp2Ip0Jr) specification. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character).
+
+        Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23dfn-did-urls&sa=D&source=editors&ust=1718703186649133&usg=AOvVaw0EaEzL0r-feVdq05848E3A).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### W3C (DID)
+
+        A DID plus any additional syntactic component that conforms to thedefinition in 3.2 DID URL Syntax. This includes an optional DIDpath (with its leading / character), optional DID query(with its leading ? character), and optional DID fragment(with its leading # character).
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID URL dereferencer](#DIDURLdereferencer)
+
+    -   ### W3C (DID)
+
+        A software and/or hardware system that performs the DID URL dereferencingfunction for a given DID URL or DID document.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID URL dereferencing](#DIDURLdereferencing)
+
+    -   ### W3C (DID)
+
+        The process that takes as its input a DID URL and a set of inputmetadata, and returns a resource. This resource might be a DIDdocument plus additional metadata, a secondary resourcecontained within the DID document, or a resource entirelyexternal to the DID document. The process uses DID resolution tofetch a DID document indicated by the DID contained within theDID URL. The dereferencing process can then perform additional processingon the DID document to return the dereferenced resource indicated by theDID URL. The inputs and outputs of this process are defined in7.2 DID URL Dereferencing.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID controller](#h.4yr00jpenf4z)
+
+    -   ### ToIP
+
+        An [entity](#h.5imtbzl1f4xo) that has the capability to make changes to a [DID document](#h.yjwocacp570p). A [DID](#h.zh539v9ul471) might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the [DID document](#h.yjwocacp570p). Note that a DID controller might be the [DID subject](#h.486g323w9jsf).
+
+        Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186646023&usg=AOvVaw1f53u6vss7TVjsp5QRIGqs).
+
+        See also: [controller](#h.gemoqe2m303z).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### W3C (DID)
+
+        An entity that has the capability to make changes to a DID document. ADID might have more than one DID controller. The DID controller(s)can be denoted by the optional controller property at the top level of theDID document. Note that a DID controller might be the DIDsubject.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID delegate](#DIDdelegate)
+
+    -   ### W3C (DID)
+
+        An entity to whom a DID controller has granted permission to use averification method associated with a DID via a DIDdocument. For example, a parent who controls a child's DID documentmight permit the child to use their personal device in order toauthenticate. In this case, the child is the DID delegate. Thechild's personal device would contain the private cryptographic materialenabling the child to authenticate using the DID. However, the childmight not be permitted to add other personal devices without the parent'spermission.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID document](#h.yjwocacp570p)
+
+    -   ### ToIP
+
+        A set of data describing the [DID subject](#h.486g323w9jsf), including mechanisms, such as cryptographic public keys, that the [DID subject](#h.486g323w9jsf) or a DID delegate can use to [authenticate](#h.gp553sxzbmv1) itself and prove its association with the [DID](#h.zh539v9ul471). A DID document might have one or more different representations as defined in section 6 of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.google.com/url?q=https://www.w3.org/TR/did-core/&sa=D&source=editors&ust=1718703186646649&usg=AOvVaw3-xXcWUxmbYaKwaUmlIyDG) specification.
+
+        Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186646894&usg=AOvVaw0mWmFJ9wZ8e3kS6Sa9hKGt).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### ToIP (DID:Webs)
+
+        A set of data describing the subject of a DID, as defined by DID Core. See also section DID Documents.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### W3C (DID)
+
+        A set of data describing the DID subject, including mechanisms, such ascryptographic public keys, that the DID subject or a DID delegatecan use to authenticate itself and prove its association with theDID. A DID document might have one or more differentrepresentations as defined in 6. Representations or in theW3C DID Specification Registries \[DID-SPEC-REGISTRIES\].
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID document metadata](#DIDdocumentmetadata)
+
+    -   ### ToIP (DID:Webs)
+
+        DID document metadata is metadata about the DID and the DID document that is the result of the DID Resolution process. See also DID Document Metadata in the DID Core specification.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [DID fragment](#DIDfragment)
+
+    -   ### W3C (DID)
+
+        The portion of a DID URL that follows the first hash sign character(#). DID fragment syntax is identical to URI fragment syntax.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID method](#h.fuy2eub1xls)
+
+    -   ### ToIP
+
+        A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which [DIDs](#h.zh539v9ul471) and [DID documents](#h.yjwocacp570p) are created, resolved, updated, and deactivated.
+
+        Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23dfn-did-methods&sa=D&source=editors&ust=1718703186647497&usg=AOvVaw1vdVhC_YEVLy6Ie7URbBD_).
+
+        For more information: [https://www.w3.org/TR/did-core/#methods](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23methods&sa=D&source=editors&ust=1718703186647803&usg=AOvVaw1sy56E2s8fPDepYzRzKQqm) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### W3C (DID)
+
+        A definition of how a specific DID method scheme is implemented. A DID method isdefined by a DID method specification, which specifies the precise operations bywhich DIDs and DID documents are created, resolved, updated,and deactivated. See 8. Methods.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID path](#DIDpath)
+
+    -   ### W3C (DID)
+
+        The portion of a DID URL that begins with and includes the first forwardslash (/) character and ends with either a question mark(?) character, a fragment hash sign (#) character,or the end of the DID URL. DID path syntax is identical to URI path syntax.See Path.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID query](#DIDquery)
+
+    -   ### W3C (DID)
+
+        The portion of a DID URL that follows and includes the first questionmark character (?). DID query syntax is identical to URI querysyntax. See Query.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID resolution](#DIDresolution)
+
+    -   ### W3C (DID)
+
+        The process that takes as its input a DID and a set of resolutionoptions and returns a DID document in a conforming representationplus additional metadata. This process relies on the "Read" operation of theapplicable DID method. The inputs and outputs of this process aredefined in 7.1 DID Resolution.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID resolution metadata](#DIDresolutionmetadata)
+
+    -   ### ToIP (DID:Webs)
+
+        DID resolution metadata is metadata about the DID Resolution process that was performed in order to obtain the DID document for a given DID. See also DID Resolution Metadata in the DID Core specification.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [DID resolver](#DIDresolver)
+
+    -   ### W3C (DID)
+
+        A DID resolver is a software and/or hardware component that performs theDID resolution function by taking a DID as input and producing aconforming DID document as output.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID scheme](#DIDscheme)
+
+    -   ### W3C (DID)
+
+        The formal syntax of a decentralized identifier. The generic DID schemebegins with the prefix did: as defined in 3.1 DID Syntax. Each DID method specification defines a specificDID method scheme that works with that specific DID method. In a specific DIDmethod scheme, the DID method name follows the first colon and terminates withthe second colon, e.g., did:example:
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DID subject](#h.486g323w9jsf)
+
+    -   ### ToIP
+
+        The [entity](#h.5imtbzl1f4xo) identified by a [DID](#h.zh539v9ul471) and described by a [DID document](#h.yjwocacp570p). Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.
+
+        Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23dfn-did-subjects&sa=D&source=editors&ust=1718703186648301&usg=AOvVaw2PJKnozNU1z_FVlS-oQFnI).
+
+        See also: [subject](#h.voca6uuv1a4).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### W3C (DID)
+
+        The entity identified by a DID and described by a DID document.Anything can be a DID subject: person, group, organization, physical thing,digital thing, logical thing, etc.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [DKMI](#DKMI)
+
+    -   ### WebOfTrust
+
+        # DKMI
+
+        ###### See
+
+        [Decentralized key management infrastructure](https://weboftrust.github.io/keridoc/docs/glossary/decentralized-key-management-infrastructure.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [DPKI](#DPKI)
+
+    -   ### WebOfTrust
+
+        # DPKI
+
+        ###### See
+
+        [Decentralized key management infrastructure](https://weboftrust.github.io/keridoc/docs/glossary/decentralized-key-management-infrastructure.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [DRM](#h.m9um65bhu37)
+
+    -   ### ToIP
+
+        See: [digital rights management](#h.d6exis1ya9fd).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [DWN](#h.i5nlq6yo16yd)
+
+    -   ### ToIP
+
+        See: [Decentralized Web Node](#h.ygukfig9m4mn).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Data](#data)
+
+    -   ### Essif-Lab
+
+        something (tangible) that can be used to communicate a meaning (which is intangible/information).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Dead-Attack](#DeadAttack)
+
+    -   ### TSWG (Keri)
+
+        an attack on an establishment event 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. See (Security Properties of Prerotation)\[#dead-attacks\].
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Decentralized GRC Pattern](#decentralized-grc-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain one's thinking about topics related to Governance, Risk management and Compliance (GRC) in a decentralized context, i.e., a context in which [parties](https://essif-lab.github.io/framework/docs/terms/party) all autonomously do their own GRC.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Decentralized Identity Foundation](#h.w2py1eklfcb)
+
+    -   ### ToIP
+
+        A non-profit project of the [Linux Foundation](https://www.google.com/url?q=https://www.linuxfoundation.org/&sa=D&source=editors&ust=1718703186637612&usg=AOvVaw1NBi3BR3Js9frDbrox4gGQ) chartered to develop the foundational components of an open, standards-based, [decentralized identity](#h.xodo7ytn4cx2) [ecosystem](#h.edgw5dskp7an) for people, [organizations](#h.z27mp1358pi9), apps, and devices.
+
+        See also: [OpenWallet Foundation](#h.271hay7m0g55), [ToIP Foundation](#h.500jynxuxkms).
+
+        For more information, see: [http://identity.foundation/](https://www.google.com/url?q=http://identity.foundation/&sa=D&source=editors&ust=1718703186638237&usg=AOvVaw1cq_xhR1TVsRIaK4RU8Thc) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Decentralized Risk Management Pattern](#decentralized-risk-management-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how individual [parties](https://essif-lab.github.io/framework/docs/terms/party) can efficiently and effectively perform their own [risk management](https://essif-lab.github.io/framework/docs/terms/risk-management) processes, while taking into account that there are other [parties](https://essif-lab.github.io/framework/docs/terms/party) that have [expectations](https://essif-lab.github.io/framework/docs/terms/expectation) towards them.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Decentralized Web Node](#h.ygukfig9m4mn)
+
+    -   ### ToIP
+
+        A decentralized personal and application data storage and message relay node, as defined in the DIF Decentralized Web Node specification. Users may have multiple nodes that replicate their data between them.
+
+        Source: [DIF DWN Specification](https://www.google.com/url?q=https://identity.foundation/decentralized-web-node/spec/&sa=D&source=editors&ust=1718703186638640&usg=AOvVaw2M_gpxeLr_Tx56O1dOKrOl).
+
+        Also known as: DWN.
+
+        For more information, see: [https://identity.foundation/decentralized-web-node/spec/](https://www.google.com/url?q=https://identity.foundation/decentralized-web-node/spec/&sa=D&source=editors&ust=1718703186638940&usg=AOvVaw0pW-Ck6-0ypO9ydKK4SCqz) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Decentralized key management infrastructure](#Decentralizedkeymanagementinfrastructure)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Decision](#decision)
+
+    -   ### Essif-Lab
+
+        the conclusion that a [party](https://essif-lab.github.io/framework/docs/terms/party) inferences from a set of [data](https://essif-lab.github.io/framework/docs/terms/data) that it considers to be facts.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Decision Making Pattern](#decision-making-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [parties](https://essif-lab.github.io/framework/docs/terms/party) would, could, or should reason in order to reach good conclusions and make good decisions. This can be used as a basis for understanding the information needs of [parties](https://essif-lab.github.io/framework/docs/terms/party) as they need to decide e.g. whether or not to commit to a [Transaction](https://essif-lab.github.io/framework/docs/terms/transaction) proposal, or whether or not data is [valid](https://essif-lab.github.io/framework/docs/terms/validate) for some purpose. This pattern is based on [Toulmin's use of arguments](https://www.cambridge.org/core/books/uses-of-argument/26CF801BC12004587B66778297D5567C) (of which a pragmatical text can be found [here](https://owl.purdue.edu/owl/general_writing/academic_writing/historical_perspectives_on_argumentation/toulmin_argument.html))
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Define](#define)
+
+    -   ### Essif-Lab
+
+        to provide a criterion and a [term](https://essif-lab.github.io/framework/docs/terms/term), where the criterion can be used by people to determine whether or not something is an instance/example of a [concept](https://essif-lab.github.io/framework/docs/terms/concept) (or other [semantic unit](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit)), and the [term](https://essif-lab.github.io/framework/docs/terms/term) is used to refer to that [concept](https://essif-lab.github.io/framework/docs/terms/concept), or an arbitrary instance thereof.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Definition](#definition)
+
+    -   ### Essif-Lab
+
+        a text that helps [parties](https://essif-lab.github.io/framework/docs/terms/party) to have the same understanding about the meaning of (and [concept](https://essif-lab.github.io/framework/docs/terms/concept) behind) a [term](https://essif-lab.github.io/framework/docs/terms/term), ideally in such a way that these [parties](https://essif-lab.github.io/framework/docs/terms/party) can determine whether or not they make the same distinction.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Definition Pattern](#definition-pattern)
+
+    -   ### Essif-Lab
+
+        a [mental model](https://essif-lab.github.io/framework/docs/terms/mental-model) that describes the relations between a [concept](https://essif-lab.github.io/framework/docs/terms/concept) (or any other [semantic unit](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit)), the [term(s)](https://essif-lab.github.io/framework/docs/terms/term) that are used to refer to it, and the criteria to use for determining whether or not something is an instance (example) of that [semantic unit](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Delegate](#delegate)
+
+    -   ### Essif-Lab
+
+        the transferral of [ownership](https://essif-lab.github.io/framework/docs/terms/ownership) of one or more [obligation](https://essif-lab.github.io/framework/docs/terms/obligation) of a [party](https://essif-lab.github.io/framework/docs/terms/party) (the [delegator](https://essif-lab.github.io/framework/docs/terms/delegate)), including the associated accountability, to another [party](https://essif-lab.github.io/framework/docs/terms/party) (the [delegatee](https://essif-lab.github.io/framework/docs/terms/delegate))), which implies that the [delegatee](https://essif-lab.github.io/framework/docs/terms/delegate) can realize such [obligation](https://essif-lab.github.io/framework/docs/terms/obligation) as it sees fit.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Dependent](#dependent)
+
+    -   ### Essif-Lab
+
+        an [entity](https://essif-lab.github.io/framework/docs/terms/entity) for the caring for and/or protecting/guarding/defending of which a [guardianship arrangement](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement) has been established.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Dictionary](#dictionary)
+
+    -   ### Essif-Lab
+
+        an alphabetically sorted list of [term](https://essif-lab.github.io/framework/docs/terms/term) with various meanings they may have in different contexts.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Disclosee](#Disclosee)
+
+    -   ### TSWG (ACDC)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Discloser](#Discloser)
+
+    -   ### TSWG (ACDC)
+
+        a role of an entity that discloses an ACDC. A Discloser may or may not be the Issuer of the disclosed ACDC.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Documentation Interoperability](#documentation-interoperability)
+
+    -   ### Essif-Lab
+
+        the property that a documentation system of making its content comprehensible for a variety of people that come from different backgrounds.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Domain](#Domain)
+
+    -   ### TSWG (CESR)
+
+        a representation of a Primitive either Text (T), Binary (B) or Raw binary (R).
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Duplicity](#Duplicity)
+
+    -   ### TSWG (ACDC)
+
+        the existence of more than one Version of a Verifiable KEL for a given AID. See duplicity.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        the existence of more than one Version of a Verifiable KEL for a given AID.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Duties and Rights Pattern](#duties-and-rights-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain what a generic duties and rights consists of (based on [Hofeld's theories](https://plato.stanford.edu/entries/rights/#FormRighHohfAnalSyst)), and relates it to [jurisdictions](https://essif-lab.github.io/framework/docs/terms/jurisdiction), [parties](https://essif-lab.github.io/framework/docs/terms/party) and [legal entities](https://essif-lab.github.io/framework/docs/terms/legal-entity).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [E2E](#E2E)
+
+    -   ### WebOfTrust
+
+        # E2E
+
+        ###### See
+
+        [End-to-end](https://weboftrust.github.io/keridoc/docs/glossary/end-to-end.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ECR](#ECR)
+
+    -   ### WebOfTrust
+
+        # ECR
+
+        ###### See
+
+        [Engagement context role](https://weboftrust.github.io/keridoc/docs/glossary/engagement-context-role.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ESSR](#ESSR)
+
+    -   ### WebOfTrust
+
+        # ESSR
+
+        ###### See
+
+        [Encrypt‐Sender‐Sign‐Receiver](https://github.com/WebOfTrust/WOT-terms/wiki/encrypt-sender-sign-receiver)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Ecosystem](#ecosystem)
+
+    -   ### Essif-Lab
+
+        a set of at least two (autonomous) [parties](https://essif-lab.github.io/framework/docs/terms/party) (its 'members') whose individual work complements that of other members, and is of benefit to the set as a whole.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Edge](#Edge)
+
+    -   ### TSWG (ACDC)
+
+        a top-level field map within an ACDC that provides edges that connect to other ACDCs, forming a labeled property graph (LPG).
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Employee](#employee)
+
+    -   ### Essif-Lab
+
+        a (human or non-human (digital)) [actor](https://essif-lab.github.io/framework/docs/terms/actor) for whom/which it is realistic that it might execute [action](https://essif-lab.github.io/framework/docs/terms/action) on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party) (called the [employer](https://essif-lab.github.io/framework/docs/terms/employer) of that [actor](https://essif-lab.github.io/framework/docs/terms/actor)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Employer](#employer)
+
+    -   ### Essif-Lab
+
+        a [party](https://essif-lab.github.io/framework/docs/terms/party) on whose behalf a (human or non-human) [actor](https://essif-lab.github.io/framework/docs/terms/actor) (called an [employee](https://essif-lab.github.io/framework/docs/terms/employee) of that [party](https://essif-lab.github.io/framework/docs/terms/party)) might execute [action](https://essif-lab.github.io/framework/docs/terms/action).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Employment Contract](#employment-contract)
+
+    -   ### Essif-Lab
+
+        an agreement/contract between two [parties](https://essif-lab.github.io/framework/docs/terms/party), one of which controls a set of [actor](https://essif-lab.github.io/framework/docs/terms/actor) (the [subject](https://essif-lab.github.io/framework/docs/terms/subject) of the contract), that states (or refers to) all (sets of) rights and duties under which these [actor](https://essif-lab.github.io/framework/docs/terms/actor) can and/or must work for the other [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [End-to-End Principle](#h.g44v4jgpfsdl)
+
+    -   ### ToIP
+
+        The end-to-end principle is a design framework in computer networking. In networks designed according to this principle, guaranteeing certain application-specific features, such as reliability and security, requires that they reside in the communicating end [nodes](#h.w1aty8c036fp) of the network. [Intermediary](#h.p89mgcb8dbec) nodes, such as [gateways](#h.x6n84riqc6ll) and [routers](#h.oqbqyf914pln), that exist to establish the network, may implement these to improve efficiency but cannot guarantee end-to-end correctness.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/End-to-end_principle&sa=D&source=editors&ust=1718703186669641&usg=AOvVaw1g64gTffvO6PdeNc7usH-Y).
+
+        For more information, see: [https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf](https://www.google.com/url?q=https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf&sa=D&source=editors&ust=1718703186669859&usg=AOvVaw20lJ9vohjlIvPN17cIhYxl) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [End-verifiability](#Endverifiability)
+
+    -   ### TSWG (Keri)
+
+        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 verifiers ultimate control.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Entity](#entity)
+
+    -   ### Essif-Lab
+
+        someone or something that is known to exist.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Establishment event](#Establishmentevent)
+
+    -   ### TSWG (Keri)
+
+        a Key event that establishes or changes the Key state which includes the current set of authoritative keypairs (Key state) for an AID.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Expectation](#expectation)
+
+    -   ### Essif-Lab
+
+        an [objective](https://essif-lab.github.io/framework/docs/terms/objective) that is [owned](https://essif-lab.github.io/framework/docs/terms/owned) by a [party](https://essif-lab.github.io/framework/docs/terms/party) for having a specific (set of) result(s) produced, where the actual production thereof is (going to be) outsourced to another [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [FAL](#h.88wfh0m6wbd6)
+
+    -   ### ToIP
+
+        See: [federation assurance level](#h.8fhj7rpnpjy3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [FFI](#FFI)
+
+    -   ### WebOfTrust
+
+        # FFI
+
+        ###### See
+
+        [Foreign Function Interface](https://weboftrust.github.io/keridoc/docs/glossary/foreign-function-interface.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [First-Seen](#FirstSeen)
+
+    -   ### TSWG (Keri)
+
+        refers to the first instance of a Message received by any Witness or Watcher. The first-seen event is always seen, and can never be unseen. It forms the basis for Duplicity detection in KERI based systems.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Framework (Conceptual)](#framework-conceptual)
+
+    -   ### Essif-Lab
+
+        a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Framing Code](#FramingCode)
+
+    -   ### TSWG (ACDC)
+
+        a code that delineate a number of characters or bytes, as appropriate, that can be extracted atomically from a Stream.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Framing Codes](#FramingCodes)
+
+    -   ### TSWG (CESR)
+
+        codes that delineate a number of characters or bytes, as appropriate, that can be extracted atomically from a Stream.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Full Disclosure](#FullDisclosure)
+
+    -   ### TSWG (ACDC)
+
+        a disclosure of an ACDC that discloses the full details of some or all of its field maps. In the context of Selective Disclosure, 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, Full Disclosure means detailed disclosure of the field map that was so far only partially disclosed.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [GAR](#GAR)
+
+    -   ### WebOfTrust
+
+        # GAR
+
+        ###### See
+
+        [GLEIF authorized representative](https://weboftrust.github.io/keridoc/docs/glossary/gleif-authorized-representative.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [GDPR](#h.5oxryjdg8s9w)
+
+    -   ### ToIP
+
+        See: [General Data Protection Regulation](#h.tks8sagp6iy0).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [GLEIF](#GLEIF)
+
+    -   ### WebOfTrust
+
+        # GLEIF
+
+        ###### Definition
+
+        Global Legal Entity Identifier Foundation
+
+        ###### More information
+
+        [https://www.gleif.org/en](https://www.gleif.org/en)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [GLEIS](#GLEIS)
+
+    -   ### WebOfTrust
+
+        # GLEIS
+
+        ###### Definition
+
+        Global Legal Entity Identifier System
+
+        [Learn more](https://kerisse.org)
+
+-   ## [GPG](#GPG)
+
+    -   ### WebOfTrust
+
+        # GPG
+
+        ###### See
+
+        [Gnu privacy guard](https://weboftrust.github.io/keridoc/docs/glossary/gnu-privacy-guard.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [GRC](#h.jdf5ep893jgd)
+
+    -   ### ToIP
+
+        See: [Governance, Risk Management, and Compliance](#h.qo8q5iquhh9u).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [General Data Protection Regulation](#h.tks8sagp6iy0)
+
+    -   ### ToIP
+
+        The General Data Protection Regulation (Regulation (EU) 2016/679, abbreviated GDPR) is a European Union regulation on information privacy in the European Union (EU) and the European Economic Area (EEA). The GDPR is an important component of EU privacy law and human rights law, in particular Article 8(1) of the Charter of Fundamental Rights of the European Union. It also governs the transfer of [personal data](#h.rpiib2ml3s9c) outside the EU and EEA. The GDPR's goals are to enhance individuals' control and rights over their personal information and to simplify the regulations for international business.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/General_Data_Protection_Regulation&sa=D&source=editors&ust=1718703186681950&usg=AOvVaw3c3DJfeK4c6lgnqWiaG__l).
+
+        Also known as: [GDPR](#h.5oxryjdg8s9w).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Glossary](#glossary)
+
+    -   ### Essif-Lab
+
+        an alphabetically sorted list of [term](https://essif-lab.github.io/framework/docs/terms/term) with the (single) meaning it has in (at least) one context.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Governance](#governance)
+
+    -   ### Essif-Lab
+
+        the [act](https://essif-lab.github.io/framework/docs/terms/action) or process of governing or overseeing the realization of (the results associated with) a set of [objective](https://essif-lab.github.io/framework/docs/terms/objective) by the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of these [objective](https://essif-lab.github.io/framework/docs/terms/objective), in order to ensure they will be fit for the purposes that this [owner](https://essif-lab.github.io/framework/docs/terms/owner) intends to use them for.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Governance and Management Pattern](#governance-and-management-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [parties](https://essif-lab.github.io/framework/docs/terms/party) organize that their [objectives](https://essif-lab.github.io/framework/docs/terms/objective) are realized, either by doing the associated work themselves, or by arranging for other [parties](https://essif-lab.github.io/framework/docs/terms/party) to do that.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Governance, Risk Management, and Compliance](#h.qo8q5iquhh9u)
+
+    -   ### ToIP
+
+        [Governance](#h.mu68tj5xpknp), [risk management](#h.8i5edrs9npxn), and [compliance](#h.r0iiayz1za1i) (GRC) are three related facets that aim to assure an [organization](#h.z27mp1358pi9) reliably achieves [objectives](#h.k0v6ir8wmcav), addresses uncertainty and acts with integrity. [Governance](#h.mu68tj5xpknp) is the combination of processes established and executed by the directors (or the board of directors) that are reflected in the [organization's](#h.z27mp1358pi9) structure and how it is managed and led toward achieving goals. [Risk management](#h.8i5edrs9npxn) is predicting and managing risks that could hinder the [organization](#h.z27mp1358pi9) from reliably achieving its [objectives](#h.k0v6ir8wmcav) under uncertainty. [Compliance](#h.r0iiayz1za1i) refers to adhering with the mandated boundaries (laws and regulations) and voluntary boundaries (company's policies, procedures, etc.)
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Governance,_risk_management,_and_compliance&sa=D&source=editors&ust=1718703186684422&usg=AOvVaw3ACgI_g0tD8c6xBllHqEz0).
+
+        Also known as: [GRC](#h.jdf5ep893jgd).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Governor](#governor)
+
+    -   ### Essif-Lab
+
+        a [role](https://essif-lab.github.io/framework/docs/terms/role) that a [party](https://essif-lab.github.io/framework/docs/terms/party) (better: [employee](https://essif-lab.github.io/framework/docs/terms/employee) of a specific [party](https://essif-lab.github.io/framework/docs/terms/party)) performs as it [governs](https://essif-lab.github.io/framework/docs/terms/governance) a (coherent) set of [expectation](https://essif-lab.github.io/framework/docs/terms/expectation) of that [party](https://essif-lab.github.io/framework/docs/terms/party), within a particular focus.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Graduated Disclosure](#GraduatedDisclosure)
+
+    -   ### TSWG (ACDC)
+
+        a disclosure of an ACDC that does not to reveal its entire content in the initial interaction with the recipient and, instead, partially or selectively reveal only the information contained within the ACDC that is necessary to further a transaction with the recipient. A Graduated disclosure may invole multiple steps where more information is prgressively revealed as the recipient satisfy the conditions set by the discloser. Compact disclosure, Partial disclosure, Selective disclosure and Full disclosure are all Graduated disclosure mechanisms.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Group/Count Codes](#Group%2FCountCodes)
+
+    -   ### TSWG (CESR)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Guardian](#guardian)
+
+    -   ### Essif-Lab
+
+        a [party](https://essif-lab.github.io/framework/docs/terms/party) that has been assigned rights and duties in a [Guardianship Arrangement](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement) for the purpose of caring for and/or protecting/guarding/defending the [entity](https://essif-lab.github.io/framework/docs/terms/entity) that is the [dependent](https://essif-lab.github.io/framework/docs/terms/dependent) in that Guardianship Arrangement.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Guardianship (in a Jurisdiction)](#guardianship-in-a-jurisdiction)
+
+    -   ### Essif-Lab
+
+        the specification of a set of rights and duties between [legal entities](https://essif-lab.github.io/framework/docs/terms/legal-entity) of the [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) that enforces these rights and duties, for the purpose of caring for and/or protecting/guarding/defending one or more of these [entities](https://essif-lab.github.io/framework/docs/terms/legal-entity). (Synonym of [Guardianship Arrangement](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement))
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Guardianship Arrangement](#guardianship-arrangement)
+
+    -   ### Essif-Lab
+
+        guardianship Arrangement (in a Jurisdiction): the specification of a set of rights and duties between [legal entities](https://essif-lab.github.io/framework/docs/terms/legal-entity) of the [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) that enforces these rights and duties, for the purpose of caring for and/or protecting/guarding/defending one or more of these [entities](https://essif-lab.github.io/framework/docs/terms/legal-entity).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Guardianship Pattern](#guardianship-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain what a generic [guardianship](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement) consists of, and how it relates to [guardians](https://essif-lab.github.io/framework/docs/terms/guardian), [dependents](https://essif-lab.github.io/framework/docs/terms/dependent), [jurisdictions](https://essif-lab.github.io/framework/docs/terms/jurisdiction), etc.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Guardianship-type](#guardianship-type)
+
+    -   ### Essif-Lab
+
+        a class of [guardianship arrangements](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement) within the [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) that governs and manages them.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [HSM](#HSM)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/hsm)
+
+    -   ### ToIP
+
+        See: [hardware security module](#h.vs7ugzdzujtz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # HSM
+
+        ###### See
+
+        [Hardware security model](https://weboftrust.github.io/keridoc/docs/glossary/hardware-security-module.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Holder](#holder)
+
+    -   ### Essif-Lab
+
+        a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to handle [presentation requests](https://essif-lab.github.io/framework/docs/terms/presentation-request) from a [peer agent](https://essif-lab.github.io/framework/docs/terms/peer-agent), produce the requested data (a presentation) according to its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [holder-policy](https://essif-lab.github.io/framework/docs/terms/holder-policy), and send that in response to the request.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Holder Policy](#holder-policy)
+
+    -   ### Essif-Lab
+
+        a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [holder](https://essif-lab.github.io/framework/docs/terms/holder) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Home](#Home)
+
+    -   ### WebOfTrust
+
+        # Home
+
+        ###### Welcome to the WebofTrust terms wiki!
+
+        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.
+
+        ##### KERISSE reads this wiki
+
+        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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Human Being](#human-being)
+
+    -   ### Essif-Lab
+
+        a person of flesh and blood (homo sapiens), that we classify both as a [party](https://essif-lab.github.io/framework/docs/terms/party),an [actor](https://essif-lab.github.io/framework/docs/terms/actor), and a [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [I O](#I-O)
+
+    -   ### WebOfTrust
+
+        # I O
+
+        ###### See
+
+        [Input output](https://weboftrust.github.io/keridoc/docs/glossary/input-output.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [IAL](#h.llbw3xojtkuj)
+
+    -   ### ToIP
+
+        See: [identity assurance level](#h.udr0qmo2ubln).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [IANA](#IANA)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/iana)
+
+    -   ### WebOfTrust
+
+        # IANA
+
+        ###### See
+
+        [Internet assigned numbers authority](https://weboftrust.github.io/keridoc/docs/glossary/internet-assigned-numbers-authority.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [IDP](#h.f0lhza3e60fv)
+
+    -   ### ToIP
+
+        See: [identity provider](#h.m9zmriuoidyt).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [IP](#h.oh0hm0ivunoz)
+
+    -   ### ToIP
+
+        See: [Internet Protocol](#h.jmao5ngtvqnm).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [IP address](#h.a8c3q7adyz7c)
+
+    -   ### ToIP
+
+        An [Internet Protocol](#h.jmao5ngtvqnm) 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](#h.jmao5ngtvqnm) for [communication](#h.w02a6srdng3j). An IP address serves two main functions: network interface [identification](#h.fslz9gxdlb84), and location [addressing](#h.tv1389o42vzp).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/IP_address&sa=D&source=editors&ust=1718703186721471&usg=AOvVaw1HTCqf8CSWF6Lh599Dr3e5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [IPEX](#IPEX)
+
+    -   ### WebOfTrust
+
+        # IPEX
+
+        ###### See
+
+        [Issuance and presentation exchange protocol](https://weboftrust.github.io/keridoc/docs/glossary/issuance-and-presentation-exchange-protocol.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Identification Pattern](#identification-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain the mechanisms that [parties](https://essif-lab.github.io/framework/docs/terms/party) may use to [identify](https://essif-lab.github.io/framework/docs/terms/identify) [entities](https://essif-lab.github.io/framework/docs/terms/entity), and mechanisms for communicating with another [parties](https://essif-lab.github.io/framework/docs/terms/party) such that both [parties](https://essif-lab.github.io/framework/docs/terms/party) can [identify](https://essif-lab.github.io/framework/docs/terms/identify) an [entity](https://essif-lab.github.io/framework/docs/terms/entity) and know whether or not they [identify](https://essif-lab.github.io/framework/docs/terms/identify) the same [entity](https://essif-lab.github.io/framework/docs/terms/entity).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Identifier](#identifier)
+
+    -   ### Essif-Lab
+
+        a character string that is being used for the identification of some [entity](https://essif-lab.github.io/framework/docs/terms/entity) (yet may refer to 0, 1, or more [entities](https://essif-lab.github.io/framework/docs/terms/entity), depending on the context within which it is being used).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Identifier Pattern](#identifier-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [identifiers](https://essif-lab.github.io/framework/docs/terms/identifier) are defined and used for [identification](https://essif-lab.github.io/framework/docs/terms/pattern-identification) purposes.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Identify](#identify)
+
+    -   ### Essif-Lab
+
+        an [act](https://essif-lab.github.io/framework/docs/terms/action), by or on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party), that results in the selection of either
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Identity](#identity)
+
+    -   ### Essif-Lab
+
+        the combined [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) about that [entity](https://essif-lab.github.io/framework/docs/terms/entity) of all [parties](https://essif-lab.github.io/framework/docs/terms/party), i.e. the union of all [partial identities](https://essif-lab.github.io/framework/docs/terms/partial-identity) of which that [entity](https://essif-lab.github.io/framework/docs/terms/entity) is the [subject](https://essif-lab.github.io/framework/docs/terms/subject).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Identity Pattern](#identity-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [digital identities](https://essif-lab.github.io/framework/docs/terms/identity) work, how this relates to (attributes in) [credentials](https://essif-lab.github.io/framework/docs/terms/credential), and how all this can be made to work in [SSI](https://essif-lab.github.io/framework/docs/terms/ssi) contexts.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Inception](#Inception)
+
+    -   ### TSWG (Keri)
+
+        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 AIDs KEL.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Inception event](#Inceptionevent)
+
+    -   ### TSWG (ACDC)
+
+        an Establishment event that provides the incepting information needed to derive an AID and establish its initial Key state. See inception event.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        an Establishment event that provides the incepting information needed to derive an AID and establish its initial Key state.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Information Process](#information-process)
+
+    -   ### Essif-Lab
+
+        a coherent set of \[actions@\] that are (to be) performed by a single \[party@\], in which [data](https://essif-lab.github.io/framework/docs/terms/data) (that is controlled by this [party](https://essif-lab.github.io/framework/docs/terms/party) is created, read, updated and/or deleted.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Information theoretic security](#Informationtheoreticsecurity)
+
+    -   ### TSWG (ACDC)
+
+        the highest level of cryptographic security with respect to a cryptographic secret (seed, salt, or private key).
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Interaction event](#Interactionevent)
+
+    -   ### TSWG (ACDC)
+
+        a Non-establishment event that anchors external data to the Key state as established by the most recent prior Establishment event. See interaction event.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        a Non-establishment event that anchors external data to the Key state as established by the most recent prior Establishment event.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Internet Protocol](#h.jmao5ngtvqnm)
+
+    -   ### ToIP
+
+        The Internet Protocol (IP) is the network layer [communications](#h.w02a6srdng3j) protocol in the Internet protocol suite (also known as the [TCP/IP](#h.txn6vkany9z9) suite) for relaying [datagrams](#h.mxq90rincwo) across network boundaries. Its [routing](#h.tbxetxt0mdlp) function enables internetworking, and essentially establishes the Internet.
+
+        IP has the task of delivering [packets](#h.9hc1adgu2nrx) from the source host to the destination host solely based on the [IP addresses](#h.a8c3q7adyz7c) in the packet headers. For this purpose, IP defines [packet](#h.9hc1adgu2nrx) structures that encapsulate the data to be delivered. It also defines addressing methods that are used to label the datagram with source and destination information.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_Protocol&sa=D&source=editors&ust=1718703186719640&usg=AOvVaw1rUWR-HemJ5T6gJxQ7C8o5).
+
+        Also known as: [IP](#h.oh0hm0ivunoz).
+
+        See also: Transmission Control Protocol, User Datagram Protocol.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Internet protocol suite](#h.oj5ut8qopq0w)
+
+    -   ### ToIP
+
+        The Internet protocol suite, commonly known as [TCP/IP](#h.txn6vkany9z9), is a framework for organizing the set of [communication](#h.w02a6srdng3j) protocols used in the Internet and similar computer networks according to functional criteria. The foundational protocols in the suite are the [Transmission Control Protocol](#h.4wb0yz8sizvi) (TCP), the User Datagram Protocol (UDP), and the [Internet Protocol](#h.jmao5ngtvqnm) (IP).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_protocol_suite&sa=D&source=editors&ust=1718703186720328&usg=AOvVaw3IYTGCRVfB9FiJEu52X6xQ)
+
+        Also known as: [TCP/IP](#h.txn6vkany9z9).
+
+        See also: [protocol stack](#h.6ik2cef0ipsr).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Issuee](#Issuee)
+
+    -   ### TSWG (ACDC)
+
+        a role of an entity to which the claims of an ACDC are asserted.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Issuer](#issuer)
+
+    -   ### Essif-Lab
+
+        a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to construct [credential](https://essif-lab.github.io/framework/docs/terms/credential) from data objects, according to the content of its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [issuer](https://essif-lab.github.io/framework/docs/terms/issuer)\-Policy (specifically regarding the way in which the [credential](https://essif-lab.github.io/framework/docs/terms/credential) is to be digitally signed), and pass it to the [wallet](https://essif-lab.github.io/framework/docs/terms/wallet)\-component of its [principal](https://essif-lab.github.io/framework/docs/terms/principal) allowing it to be issued.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+    -   ### TSWG (ACDC)
+
+        a role of an entity that asserts claims and creates an ACDC from these claims.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Isuer Policy](#isuer-policy)
+
+    -   ### Essif-Lab
+
+        a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [issuer](https://essif-lab.github.io/framework/docs/terms/issuer) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [JOSE](#JOSE)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/jose)
+
+    -   ### WebOfTrust
+
+        # JOSE
+
+        ###### See
+
+        [Javascript object signing and encryption](https://weboftrust.github.io/keridoc/docs/glossary/javascript-object-signing-and-encryption.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [JSON](#JSON)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/json)
+
+    -   ### WebOfTrust
+
+        # JSON
+
+        ###### Definition
+
+        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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Jurisdiction](#jurisdiction)
+
+    -   ### Essif-Lab
+
+        the composition of a [legal system](https://essif-lab.github.io/framework/docs/terms/legal-system) (legislation, enforcement thereof, and conflict resolution), a [party](https://essif-lab.github.io/framework/docs/terms/party) that governs that [legal system](https://essif-lab.github.io/framework/docs/terms/legal-system), a scope within which that [legal system](https://essif-lab.github.io/framework/docs/terms/legal-system) is operational, and one or more [objective](https://essif-lab.github.io/framework/docs/terms/objective) for the purpose of which the [legal system](https://essif-lab.github.io/framework/docs/terms/legal-system) is operated. See also the [Jurisdictions pattern](https://essif-lab.github.io/framework/docs/terms/pattern-jurisdiction).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Jurisdiction Pattern](#jurisdiction-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain what a generic [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) consists of, and relates it to [parties](https://essif-lab.github.io/framework/docs/terms/party) and [legal entities](https://essif-lab.github.io/framework/docs/terms/legal-entity).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [KA2CE](#KA2CE)
+
+    -   ### WebOfTrust
+
+        # KA2CE
+
+        ###### See
+
+        [KERI agreement algorithm for control establishment](https://weboftrust.github.io/keridoc/docs/glossary/keri-agreement-algorithm-for-control-establishment.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KAACE](#KAACE)
+
+    -   ### WebOfTrust
+
+        # KAACE
+
+        ###### See
+
+        [KERI agreement algorithm for control establishment](https://weboftrust.github.io/keridoc/docs/glossary/keri-agreement-algorithm-for-control-establishment.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KAPI](#KAPI)
+
+    -   ### WebOfTrust
+
+        # KAPI
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KATE](#h.m06ht5n5sabj)
+
+    -   ### ToIP
+
+        See: [keys-at-the-edge](#h.41san6iwsd69).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [KEL](#KEL)
+
+    -   ### WebOfTrust
+
+        # KEL
+
+        A Key Event Log.
+
+        ###### See
+
+        [Key Event Log](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KEL backed data](#KELbackeddata)
+
+    -   ### ToIP (DID:Webs)
+
+        KEL backed data in did:webs provides the highest level of data security assurance and such data can be found either in the KEL or anchored to an event in the KEL. This means that the signatures on the events in the KEL are strongly bound to the key state at the time the events are entered in the KEL, that is the data. This provides strong guarantees of non-duplicity to any verifiers receiving a presentation as the KELs are protected and can be watched by agents (watcher) of the verifiers. The information is end-verifiable and any evidence of duplicity in the events is evidence that the data or presentation should not be trusted. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [KERI](#h.7pp65h7qs9lu)
+
+    -   ### ToIP
+
+        See: [Key Event Receipt Infrastructure](#h.nivehnhovlik).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # KERI
+
+        ###### See
+
+        [Key event receipt infrastructure](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-infrastructure.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KERI Request Authentication Mechanism](#KERIRequestAuthenticationMechanism)
+
+    -   ### ToIP (DID:Webs)
+
+        A non-interactive replay attack protection algorithm that uses a sliding window of date-time stamps and key state (similar to the tuple in BADA-RUN) but the date-time is the repliers not the queriers. KRAM is meant to protect a host. See the WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [KERI event stream](#KERIeventstream)
+
+    -   ### ToIP (DID:Webs)
+
+        A stream of verifiable KERI data, consisting of the key event log (KEL) and other data such as a transaction event log (TEL). This data is a CESR event stream, with media type application/cesr, and may be serialized in a file using CESR encoding. We refer to these CESR stream resources as KERI event streams to simplify the vocabulary. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [KERIMask](#KERIMask)
+
+    -   ### WebOfTrust
+
+        # KERIMask
+
+        ###### Definition
+
+        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.
+
+        ###### Status
+
+        As of October 2023 KERIMask is only planned.
+
+        ###### Related
+
+        [Signify keria request authentication protocol](https://weboftrust.github.io/keridoc/docs/glossary/signify-keria-request-authentication-protocol.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KERISSE](#KERISSE)
+
+    -   ### WebOfTrust
+
+        # KERISSE
+
+        ###### See
+
+        [KERI suite search engine](https://weboftrust.github.io/keridoc/docs/glossary/keri-suite-search-engine.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KERIs Algorithm for Witness Agreement](#KERIsAlgorithmforWitnessAgreement)
+
+    -   ### TSWG (Keri)
+
+        a type of Byzantine Fault Tolerant (BFT) algorithm
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [KERL](#KERL)
+
+    -   ### WebOfTrust
+
+        # KERL
+
+        ###### See
+
+        [Key event receipt log](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-log.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KID](#KID)
+
+    -   ### WebOfTrust
+
+        # KID
+
+        ###### See
+
+        [KERI improvement doc](https://weboftrust.github.io/keridoc/docs/glossary/keri-improvement-doc.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [KMS](#h.wcbd8vhwq6z1)
+
+    -   ### ToIP
+
+        See: [key management system](#h.q0w3jq78va39).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [KRAM](#KRAM)
+
+    -   ### WebOfTrust
+
+        # KRAM
+
+        ###### See
+
+        [KERI Request Authentication Method](https://weboftrust.github.io/keridoc/docs/glossary/keri-request-authentication-method.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Key Event Receipt Infrastructure](#h.nivehnhovlik)
+
+    -   ### ToIP
+
+        A decentralized permissionless [key management](#h.q0w3jq78va39) architecture.
+
+        Also known as: KERI.
+
+        For more information, see: [https://keri.one/](https://www.google.com/url?q=https://keri.one/&sa=D&source=editors&ust=1718703186729075&usg=AOvVaw3GffNWuLlxTAgiMSkgFO5O), [ToIP ACDC Task Force](https://www.google.com/url?q=https://wiki.trustoverip.org/display/HOME/ACDC%2B%2528Authentic%2BChained%2BData%2BContainer%2529%2BTask%2BForce&sa=D&source=editors&ust=1718703186729294&usg=AOvVaw1G8CAvkNEHsjMuK_JkyAb4)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Key Event Receipt Infrastructure (KERI)](#KeyEventReceiptInfrastructure\(KERI\))
+
+    -   ### TSWG (CESR)
+
+        or the KERI protocol, is an identity system-based secure overlay for the Internet.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Key event](#Keyevent)
+
+    -   ### TSWG (Keri)
+
+        concretely, 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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Key event log](#Keyeventlog)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Key event message](#Keyeventmessage)
+
+    -   ### TSWG (Keri)
+
+        message whose body is a Key event and whose attachments may include signatures on its body.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Key event receipt](#Keyeventreceipt)
+
+    -   ### TSWG (Keri)
+
+        message whose body references a Key event and whose attachments must include one or more signatures on that Key event.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Key event receipt log](#Keyeventreceiptlog)
+
+    -   ### TSWG (Keri)
+
+        a key event receipt log is a KEL that also includes all the consistent key event receipt Messages created by the associated set of witnesses. See annex Key event receipt log
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Key-State](#KeyState)
+
+    -   ### TSWG (Keri)
+
+        a set of authoritative keys for an AID along with 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; witnesses and their thresholds; and configurations. An AIDs key state is first established through its inception event and may evolve via subsequent rotation events. Thus, an AIDs key state is time-dependent.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Key-state](#Keystate)
+
+    -   ### TSWG (ACDC)
+
+        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. See validator.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Knowledge](#knowledge)
+
+    -   ### Essif-Lab
+
+        the (intangible) sum of what is known by a specific [party](https://essif-lab.github.io/framework/docs/terms/party), as well as the familiarity, awareness or understanding of someone or something by that [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [LEI](#h.83vh5ev7dz93)
+
+    -   ### ToIP
+
+        See: [Legal Entity Identifier](#h.tvqq4mlccuun).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # LEI
+
+        ###### Definition
+
+        Legal Entity Identifier
+
+        [Learn more](https://kerisse.org)
+
+-   ## [LID](#LID)
+
+    -   ### WebOfTrust
+
+        # LID
+
+        ###### See
+
+        [Legitimized human meaningful identifier](https://weboftrust.github.io/keridoc/docs/glossary/legitimized-human-meaningful-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [LLM](#LLM)
+
+    -   ### WebOfTrust
+
+        # LLM
+
+        ###### See [Large Language Model](https://weboftrust.github.io/keridoc/docs/glossary/large-language-model.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Laws of Identity](#h.mxikvsxmz83w)
+
+    -   ### ToIP
+
+        A set of seven “laws” written by Kim Cameron, former Chief Identity Architect of Microsoft (1941-2021), to describe the dynamics that cause digital identity systems to succeed or fail in various contexts. His goal was to define the requirements for a unifying identity metasystem that can offer the Internet the identity layer it needs.
+
+        For more information, see: [https://www.identityblog.com/?p=352](https://www.google.com/url?q=https://www.identityblog.com/?p%3D352&sa=D&source=editors&ust=1718703186732501&usg=AOvVaw0DVEsYxisLWEVheHw5sabs).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Layer 1](#h.v1hjglhanrdl)
+
+    -   ### ToIP
+
+        See: [ToIP Layer 1](#h.24ggrl8oz4ma).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Layer 2](#h.ujeavtvl4hoc)
+
+    -   ### ToIP
+
+        See: [ToIP Layer 2](#h.ikqr9hyt133k).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Layer 3](#h.b72avxgmeyfo)
+
+    -   ### ToIP
+
+        See: [ToIP Layer 3](#h.7rbvlbpp8vwp).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Layer 4](#h.w2hkrmbk64y4)
+
+    -   ### ToIP
+
+        See: [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Legal Entity](#legal-entity)
+
+    -   ### Essif-Lab
+
+        an [entity](https://essif-lab.github.io/framework/docs/terms/entity) that is known by, recognized to exist, and registered in that [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Legal Entity Identifier](#h.tvqq4mlccuun)
+
+    -   ### ToIP
+
+        The Legal Entity Identifier (LEI) is a unique global [identifier](#h.u3bfehmj4ed3) for [legal entities](#h.5328bxxk02sb) participating in financial transactions. Also known as an LEI code or LEI number, its purpose is to help identify [legal entities](#h.5328bxxk02sb) on a globally accessible database. Legal entities are [organisations](#h.z27mp1358pi9) such as companies or government entities that participate in financial transactions.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_Entity_Identifier&sa=D&source=editors&ust=1718703186734167&usg=AOvVaw2QxgRRsZGaVhWp1teZkTMi).
+
+        Note: LEIs are administered by the [Global Legal Entity Identifier Foundation](https://www.google.com/url?q=https://www.gleif.org/&sa=D&source=editors&ust=1718703186734406&usg=AOvVaw1dP6cd-BmZVaU1RbNIbCIC) (GLEIF).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Legal Jurisdiction](#legal-jurisdiction)
+
+    -   ### Essif-Lab
+
+        a [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) that is governed/operated by a governmental body.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Legal System](#legal-system)
+
+    -   ### Essif-Lab
+
+        a system in which rules are defined, and mechanisms for their enforcement and conflict resolution are (implicitly or explicitly) specified.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Live-Attack](#LiveAttack)
+
+    -   ### TSWG (Keri)
+
+        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\].
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [LoA](#LoA)
+
+    -   ### WebOfTrust
+
+        # LoA
+
+        ###### See
+
+        [Levels of assurance](https://weboftrust.github.io/keridoc/docs/glossary/levels-of-assurance.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [LoC](#LoC)
+
+    -   ### WebOfTrust
+
+        # LoC
+
+        ###### See
+
+        [Loci of control](https://weboftrust.github.io/keridoc/docs/glossary/loci-of-control.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [MFA](#MFA)
+
+    -   ### Nist
+
+        Authentication using two or more factors to achieve authentication. Factors include: (i) something you know (e.g., password/personal identification number \[PIN\]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric).
+
+        [Learn more](https://csrc.nist.gov/glossary/term/mfa)
+
+    -   ### WebOfTrust
+
+        # MFA
+
+        ###### See
+
+        [Multi-factor Authentication](https://weboftrust.github.io/keridoc/docs/glossary/multi-factor-authentication.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [MIME type](#MIME-type)
+
+    -   ### WebOfTrust
+
+        # MIME type
+
+        ###### See
+
+        [Media type](https://weboftrust.github.io/keridoc/docs/glossary/media-type.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [MPC](#h.ck8vxbqkll6d)
+
+    -   ### ToIP
+
+        See: [multi-party computation](#h.2x62jfcai7ch).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Management](#management)
+
+    -   ### Essif-Lab
+
+        the [act](https://essif-lab.github.io/framework/docs/terms/action) or process of managing or actually realizing of (the results associated with) a set of [objective](https://essif-lab.github.io/framework/docs/terms/objective) by the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of these [objective](https://essif-lab.github.io/framework/docs/terms/objective).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Mandate](#mandate)
+
+    -   ### Essif-Lab
+
+        a right or duty that one [party](https://essif-lab.github.io/framework/docs/terms/party) (the [mandator](https://essif-lab.github.io/framework/docs/terms/mandate)) has granted to another [party](https://essif-lab.github.io/framework/docs/terms/party) or [employee](https://essif-lab.github.io/framework/docs/terms/employee) (the [mandatee](https://essif-lab.github.io/framework/docs/terms/mandate)) for executing a specific (set of) [action](https://essif-lab.github.io/framework/docs/terms/action) in the name of, and under responsibility/accountability of, this (first) [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Mandates, Delegation and Hiring Pattern](#mandates-delegation-and-hiring-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain the ideas behind Mandating, Delegating, Hiring and their relations.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Mental Model](#mental-model)
+
+    -   ### Essif-Lab
+
+        a description, both casual and formal, of a set of [concept](https://essif-lab.github.io/framework/docs/terms/concept) (ideas), relations between them, and constraints, that together form a coherent and consistent 'viewpoint', or 'way of thinking' about a certain topic.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Mental Model Pattern](#mental-model-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how to create, maintain and use (decentralized) [vocabularies](https://essif-lab.github.io/framework/docs/terms/vocabulary) ([terminologies](https://essif-lab.github.io/framework/docs/terms/terminology)) that groups of people can use for the specific purposes they pursue.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Message](#Message)
+
+    -   ### TSWG (CESR)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Mission](#mission)
+
+    -   ### Essif-Lab
+
+        an [objective](https://essif-lab.github.io/framework/docs/terms/objective) of a [party](https://essif-lab.github.io/framework/docs/terms/party) that provides an answer to the question why that [party](https://essif-lab.github.io/framework/docs/terms/party) exists - i.e. its 'raison d'tre'.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [NFT](#NFT)
+
+    -   ### Nist
+
+        An owned, transferable, and indivisible data record that is a digital representation of a physical or virtual linked asset. The data record is created and managed by a smart contract on a blockchain.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/nft)
+
+    -   ### WebOfTrust
+
+        # NFT
+
+        ###### See
+
+        [Non-fungible token](https://weboftrust.github.io/keridoc/docs/glossary/non-fungible-token.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Next threshold](#Nextthreshold)
+
+    -   ### TSWG (Keri)
+
+        represents the number or fractional weights of signatures from the given set of next keys required to be attached to a Message for the Message to be considered fully signed.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Non-establishment event](#Nonestablishmentevent)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Normative framework](#normative-framework)
+
+    -   ### Essif-Lab
+
+        a set of rules that are followed and/or criteria that remain fulfilled by (a specific kind of) [entities](https://essif-lab.github.io/framework/docs/terms/entity) whose behavior and/or properties are characterized as 'normal'.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [OOBI](#h.1168y6n7c8w)
+
+    -   ### ToIP
+
+        See: [out-of-band introduction](#h.tsslu4lnog0s).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # OOBI
+
+        ###### See
+
+        [Out-of-band introduction](https://weboftrust.github.io/keridoc/docs/glossary/out-of-band-introduction.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [OOR](#OOR)
+
+    -   ### WebOfTrust
+
+        # OOR
+
+        ###### See
+
+        [Official Organizational Role](https://weboftrust.github.io/keridoc/docs/glossary/official-organizational-role.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Objective](#objective)
+
+    -   ### Essif-Lab
+
+        something toward which a [party](https://essif-lab.github.io/framework/docs/terms/party) (its [owner](https://essif-lab.github.io/framework/docs/terms/owner)) directs effort (an aim, goal, or end of action).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Obligation](#obligation)
+
+    -   ### Essif-Lab
+
+        an [objective](https://essif-lab.github.io/framework/docs/terms/objective) that is [owned](https://essif-lab.github.io/framework/docs/terms/owned) by the [party](https://essif-lab.github.io/framework/docs/terms/party) for producing a specific (set of) result(s) that are to be used (consumed) by that [party](https://essif-lab.github.io/framework/docs/terms/party) and/or other [parties](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Onboarding](#onboarding)
+
+    -   ### Essif-Lab
+
+        a process that is run for a specific (set of) [actor](https://essif-lab.github.io/framework/docs/terms/actor) on behalf of a specific [party](https://essif-lab.github.io/framework/docs/terms/party), that terminates successfully if and only if the [party](https://essif-lab.github.io/framework/docs/terms/party) has (a) established the suitability of the [actor](https://essif-lab.github.io/framework/docs/terms/actor) for executing certain kinds of [action](https://essif-lab.github.io/framework/docs/terms/action) on its behalf, (b) ensured that their mutual rights and duties are properly specified and will be appropriately enforced, and (c) provided the circumstances/contexts within which the [actor](https://essif-lab.github.io/framework/docs/terms/actor) is enabled to do so.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [OpenWallet Foundation](#h.271hay7m0g55)
+
+    -   ### ToIP
+
+        A non-profit project of the [Linux Foundation](https://www.google.com/url?q=https://www.linuxfoundation.org/&sa=D&source=editors&ust=1718703186751387&usg=AOvVaw15ETg-sNsLdDiJxWrdZv_L) chartered to build a world-class open source [wallet engine](#h.jsmi4264di2s).
+
+        See also: [Decentralized Identity Foundation](#h.w2py1eklfcb), [ToIP Foundation](#h.500jynxuxkms).
+
+        For more information, see: [https://openwallet.foundation/](https://www.google.com/url?q=https://openwallet.foundation/&sa=D&source=editors&ust=1718703186751885&usg=AOvVaw0NU5itzzXE_LYwmo0Y0zyG) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Operator](#Operator)
+
+    -   ### TSWG (ACDC)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Organization](#organization)
+
+    -   ### Essif-Lab
+
+        a [party](https://essif-lab.github.io/framework/docs/terms/party) that is capable of setting [objective](https://essif-lab.github.io/framework/docs/terms/objective) and making sure these are realized by [actor](https://essif-lab.github.io/framework/docs/terms/actor) that it has [onboarded](https://essif-lab.github.io/framework/docs/terms/onboarding) and/or by (vetted) [parties](https://essif-lab.github.io/framework/docs/terms/party) that are committed to contribute to these [objective](https://essif-lab.github.io/framework/docs/terms/objective).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Outsourcing](#outsourcing)
+
+    -   ### Essif-Lab
+
+        the state of affairs in which a [party](https://essif-lab.github.io/framework/docs/terms/party) has an [objective](https://essif-lab.github.io/framework/docs/terms/objective) (better: an [expectation](https://essif-lab.github.io/framework/docs/terms/expectation)) for the realization of a (set of) result(s), where the actual production of these results is expected to be done by a [party](https://essif-lab.github.io/framework/docs/terms/party) other than itself.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Owned](#owned)
+
+    -   ### Essif-Lab
+
+        an [entity](https://essif-lab.github.io/framework/docs/terms/entity) over which another [entity](https://essif-lab.github.io/framework/docs/terms/entity) (its [owner](https://essif-lab.github.io/framework/docs/terms/owner)) has the power (duty, right) to enjoy it, dispose of it and control it; that power is limited to (the scope of) that [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction), and by its rules.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Owner](#owner)
+
+    -   ### Essif-Lab
+
+        the role that a [party](https://essif-lab.github.io/framework/docs/terms/party) performs when it is exercising its legal, rightful or natural title to control that [entity](https://essif-lab.github.io/framework/docs/terms/entity).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Ownership](#ownership)
+
+    -   ### Essif-Lab
+
+        a relationship between two [entities](https://essif-lab.github.io/framework/docs/terms/entity) that exists within the [scope of control](https://essif-lab.github.io/framework/docs/terms/scope-of-control) of a [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction), in which one of them (called the [owner](https://essif-lab.github.io/framework/docs/terms/owner)) has legal, rightful or natural rights and/or duties to enjoy, dispose of, and control the other (called the [owned](https://essif-lab.github.io/framework/docs/terms/owned)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [P2P](#P2P)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/p2p)
+
+    -   ### ToIP
+
+        See: [peer-to-peer](#h.ikjsqxobvozv).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # P2P
+
+        ###### See
+
+        [Peer to peer](https://weboftrust.github.io/keridoc/docs/glossary/peer-to-peer.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [PGP](#PGP)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/pgp)
+
+    -   ### WebOfTrust
+
+        # PGP
+
+        ###### See
+
+        [Pretty good privacy](https://weboftrust.github.io/keridoc/docs/glossary/pretty-good-privacy.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [PID](#PID)
+
+    -   ### WebOfTrust
+
+        # PID
+
+        ###### See
+
+        [percolated information discovery](https://weboftrust.github.io/keridoc/docs/glossary/percolated-information-discovery.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [PII](#h.pumw0ocr1xf2)
+
+    -   ### ToIP
+
+        See: [personally identifiable information](#h.yww9djvhorxc).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [PKI](#PKI)
+
+    -   ### Nist
+
+        The architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a certificate-based public key cryptographic system. Framework established to issue, maintain, and revoke public key certificates.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/pki)
+
+    -   ### ToIP
+
+        See: [public key infrastructure](#h.mdxu5kpbdo4x).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # PKI
+
+        ###### See
+
+        [Public key infrastructure](https://weboftrust.github.io/keridoc/docs/glossary/public-key-infrastructure.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [PRNG](#PRNG)
+
+    -   ### Nist
+
+        A deterministic computational process that has one or more inputs called "seeds", and it outputs a sequence of values that appears to be random according to specified statistical tests. A cryptographic PRNG has the additional property that the output is unpredictable, given that the seed is not known.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/prng)
+
+    -   ### WebOfTrust
+
+        # PRNG
+
+        ###### Definition
+
+        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))
+
+        ###### See also
+
+        [CSPRNG](https://weboftrust.github.io/keridoc/docs/glossary/CSPRNG.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [PTEL](#PTEL)
+
+    -   ### WebOfTrust
+
+        # PTEL
+
+        ###### See
+
+        [Public transaction event log](https://weboftrust.github.io/keridoc/docs/glossary/public-transaction-event-log.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Partial Disclosure](#PartialDisclosure)
+
+    -   ### TSWG (ACDC)
+
+        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 later exchange of the uncompacted content is verifiable to an earlier Partial Disclosure. Unlike Selective dDsclosure, a partially disclosable field becomes correlatable to its encompassing block after its Full Disclosure.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Partial identity](#partial-identity)
+
+    -   ### Essif-Lab
+
+        all [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) that a specific [party](https://essif-lab.github.io/framework/docs/terms/party) (= the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of the partial identity) has about that [entity](https://essif-lab.github.io/framework/docs/terms/entity) (= the '[subject](https://essif-lab.github.io/framework/docs/terms/subject)' of the partial identity).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Participant](#participant)
+
+    -   ### Essif-Lab
+
+        a [party](https://essif-lab.github.io/framework/docs/terms/party) is negotiating (or has negotiated) a [transaction agreement](https://essif-lab.github.io/framework/docs/terms/transaction-agreement).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Party](#party)
+
+    -   ### Essif-Lab
+
+        an [entity](https://essif-lab.github.io/framework/docs/terms/entity) that sets its [objective](https://essif-lab.github.io/framework/docs/terms/objective), maintains its [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge), and uses that [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) to pursue its [objective](https://essif-lab.github.io/framework/docs/terms/objective) in an autonomous (sovereign) manner. Humans and [organization](https://essif-lab.github.io/framework/docs/terms/organization) are the typical examples.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Party Representation Pattern](#party-representation-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [parties](https://essif-lab.github.io/framework/docs/terms/party) can be represented in various circumstances.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Party, Actor and Actions Pattern](#party-actor-and-actions-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how things get done. It answers questions such as: 'Who/what does things?', 'How are their actions being guided/controlled?', 'Who controls whom/what?', 'Who/what may be held accountable?'.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Pattern](#pattern)
+
+    -   ### Essif-Lab
+
+        a description, both casual and formal, of a set of [concept](https://essif-lab.github.io/framework/docs/terms/concept) (ideas), relations between them, and constraints, that together form a coherent and consistent 'viewpoint', or 'way of thinking' about a certain topic.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Peer Actor](#peer-actor)
+
+    -   ### Essif-Lab
+
+        the [actor](https://essif-lab.github.io/framework/docs/terms/actor) with whom/which this other [actor](https://essif-lab.github.io/framework/docs/terms/actor) is communicating in that [communication session](https://essif-lab.github.io/framework/docs/terms/communication-session).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Peer Party](#peer-party)
+
+    -   ### Essif-Lab
+
+        a [party](https://essif-lab.github.io/framework/docs/terms/party) that also participates in that [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Peer-agent](#peer-agent)
+
+    -   ### Essif-Lab
+
+        the [agent](https://essif-lab.github.io/framework/docs/terms/agent) with whom/which this other [agent](https://essif-lab.github.io/framework/docs/terms/agent) is communicating in that [communication session](https://essif-lab.github.io/framework/docs/terms/communication-session).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Percolated discovery](#Percolateddiscovery)
+
+    -   ### TSWG (ACDC)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Perfect security](#Perfectsecurity)
+
+    -   ### TSWG (ACDC)
+
+        a special case of Information theoretic security ITPS
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [PoP](#h.3u71l1o5j9qt)
+
+    -   ### ToIP
+
+        See: [proof of personhood](#h.1686ws2z2rnl).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Policy](#policy)
+
+    -   ### Essif-Lab
+
+        a (set of) rules, working-instructions, preferences and other guidance for the execution of one or more kinds of [action](https://essif-lab.github.io/framework/docs/terms/action), that [agent](https://essif-lab.github.io/framework/docs/terms/agent) of the [party](https://essif-lab.github.io/framework/docs/terms/party) that [governs](https://essif-lab.github.io/framework/docs/terms/governance) the policy have access to and can interpret such that this results in these [action](https://essif-lab.github.io/framework/docs/terms/action) being executed as intended by that [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Presentation](#presentation)
+
+    -   ### Essif-Lab
+
+        a (signed) digital message that a [holder](https://essif-lab.github.io/framework/docs/terms/holder) component may send to a [verifier](https://essif-lab.github.io/framework/docs/terms/verifier) component that contains data derived from one or more [verifiable](https://essif-lab.github.io/framework/docs/terms/verify) [credential](https://essif-lab.github.io/framework/docs/terms/credential) (that (a [colleague](https://essif-lab.github.io/framework/docs/terms/colleague) component of) the [holder](https://essif-lab.github.io/framework/docs/terms/holder) component has received from [issuer](https://essif-lab.github.io/framework/docs/terms/issuer) components of one or more [parties](https://essif-lab.github.io/framework/docs/terms/party)), as a response to a specific [presentation request](https://essif-lab.github.io/framework/docs/terms/presentation-request) of a [Verifier](https://essif-lab.github.io/framework/docs/terms/verifier) component.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Presentation Request](#presentation-request)
+
+    -   ### Essif-Lab
+
+        a (signed) digital message that a [verifier](https://essif-lab.github.io/framework/docs/terms/verifier) component sends to a [holder](https://essif-lab.github.io/framework/docs/terms/holder) component asking for specific data from one or more [verifiable](https://essif-lab.github.io/framework/docs/terms/verify) [credential](https://essif-lab.github.io/framework/docs/terms/credential) that are issued by specific Parties.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Primitive](#Primitive)
+
+    -   ### TSWG (ACDC)
+
+        a serialization of a unitary value. All Primitives in KERI must be expressed in CESR.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (CESR)
+
+        a serialization of a unitary value. All Primitives in KERI must be expressed in CESR.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Primitive:](#Primitive%3A)
+
+    -   ### TSWG (Keri)
+
+        a serialization of a unitary value. All Primitives in KERI must be expressed in CESR \[1\].
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Principal](#principal)
+
+    -   ### Essif-Lab
+
+        the [party](https://essif-lab.github.io/framework/docs/terms/party) for whom, or on behalf of whom, the [actor](https://essif-lab.github.io/framework/docs/terms/actor) is executing an [action](https://essif-lab.github.io/framework/docs/terms/action) (this [actor](https://essif-lab.github.io/framework/docs/terms/actor) is then called an [agent](https://essif-lab.github.io/framework/docs/terms/agent) of that [party](https://essif-lab.github.io/framework/docs/terms/party)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Principles of SSI](#h.dk15fkyq7xn5)
+
+    -   ### ToIP
+
+        A set of principles for [self-sovereign identity](#h.wdojy63bltd4) systems originally defined by the Sovrin Foundation and republished by the [ToIP Foundation](#h.500jynxuxkms).
+
+        For more information, see: [https://sovrin.org/principles-of-ssi/](https://www.google.com/url?q=https://sovrin.org/principles-of-ssi/&sa=D&source=editors&ust=1718703186771205&usg=AOvVaw1XTS-F4SEcuTTCW-BO-FHQ) and [https://trustoverip.org/wp-content/uploads/2021/10/ToIP-Principles-of-SSI.pdf](https://www.google.com/url?q=https://trustoverip.org/wp-content/uploads/2021/10/ToIP-Principles-of-SSI.pdf&sa=D&source=editors&ust=1718703186771389&usg=AOvVaw08o_bhDpWOM0uyLg0GIuiC) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Property (of a Concept)](#property-of-a-concept)
+
+    -   ### Essif-Lab
+
+        a connection or association between a [concept](https://essif-lab.github.io/framework/docs/terms/concept) and a primitive data element, such as a text or a number, that represents some characteristic that instances of the [concept](https://essif-lab.github.io/framework/docs/terms/concept) may have.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [QAR](#QAR)
+
+    -   ### WebOfTrust
+
+        # QAR
+
+        ###### See
+
+        [QVI Authorized Representative](https://weboftrust.github.io/keridoc/docs/glossary/qvi-authorized-representative.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [QR code](#h.6qi3agm0afv3)
+
+    -   ### ToIP
+
+        A QR code (short for "quick-response code") is a type of two-dimensional matrix barcode—a [machine-readable](#h.8s3s84fzcfi3) optical image that contains information specific to the identified item. In practice, QR codes contain data for a locator, an identifier, and web tracking.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/QR_code&sa=D&source=editors&ust=1718703186782665&usg=AOvVaw11TQ0r927bq5411Z8AOf1f).
+
+        See also: [out-of-band introduction](#h.tsslu4lnog0s).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [QVI](#QVI)
+
+    -   ### WebOfTrust
+
+        # QVI
+
+        ###### See
+
+        [Qualified vLEI issuer](https://weboftrust.github.io/keridoc/docs/glossary/qualified-vlei-issuer.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Quadlet](#Quadlet)
+
+    -   ### TSWG (CESR)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Qualified Data](#qualified-data)
+
+    -   ### Essif-Lab
+
+        [data](https://essif-lab.github.io/framework/docs/terms/data) that comes with assurances, at least regarding its provenance and integrity (immutability), that make this data valid to be used for specific purposes of individual [parties](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [RBAC](#h.9pd74syajps6)
+
+    -   ### ToIP
+
+        See: [role-based access control](#h.isj9yeecvwmw).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [RID](#RID)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/rid)
+
+    -   ### WebOfTrust
+
+        # RID
+
+        ###### See
+
+        [Root autonomic identifier (AID)](https://weboftrust.github.io/keridoc/docs/glossary/root-autonomic-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [RUN](#RUN)
+
+    -   ### WebOfTrust
+
+        # RUN
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/CRUD.md) which is the traditional client-server database update policy.
+
+        ###### OOBI related
+
+        We [RUN off the CRUD](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [RWI](#h.rzufdn5u9c1c)
+
+    -   ### ToIP
+
+        See: [real world identity](#h.x0sst0y7375w).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Relation (between Concepts)](#relation-between-concepts)
+
+    -   ### Essif-Lab
+
+        a (significant) connection or association between two or more [concepts](https://essif-lab.github.io/framework/docs/terms/concept).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Revocation Policy](#revocation-policy)
+
+    -   ### Essif-Lab
+
+        a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [revocation component](https://essif-lab.github.io/framework/docs/terms/revocation-component) to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Revocation component](#revocation-component)
+
+    -   ### Essif-Lab
+
+        a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to [revoke](https://essif-lab.github.io/framework/docs/terms/revoke) [credential](https://essif-lab.github.io/framework/docs/terms/credential) that are issued by its [principal](https://essif-lab.github.io/framework/docs/terms/principal), according to its [principal](https://essif-lab.github.io/framework/docs/terms/principal) [revocation policy](https://essif-lab.github.io/framework/docs/terms/revocation-policy).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Revoke/Revocation](#revokerevocation)
+
+    -   ### Essif-Lab
+
+        the act, by or on behalf of the [party](https://essif-lab.github.io/framework/docs/terms/party) that has issued the [credential](https://essif-lab.github.io/framework/docs/terms/credential), of no longer vouching for the correctness or any other qualification of (arbitrary parts of) that [credential](https://essif-lab.github.io/framework/docs/terms/credential).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Risk](#risk)
+
+    -   ### Essif-Lab
+
+        the effects that uncertainty (i.e. a lack of information, understanding or [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) of events, their consequences or likelihoods) can have on the intended realization of an [objective](https://essif-lab.github.io/framework/docs/terms/objective) of a [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Risk Objective](#risk-objective)
+
+    -   ### Essif-Lab
+
+        an [objective](https://essif-lab.github.io/framework/docs/terms/objective), owned by a [party](https://essif-lab.github.io/framework/docs/terms/party), that aims to reach and maintain a state of affairs in which the [risk](https://essif-lab.github.io/framework/docs/terms/risk) associated with a specific set of its [objective](https://essif-lab.github.io/framework/docs/terms/objective) become, and/or remain, acceptable.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Risk Owner](#risk-owner)
+
+    -   ### Essif-Lab
+
+        the [party](https://essif-lab.github.io/framework/docs/terms/party) that is the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of the [objective](https://essif-lab.github.io/framework/docs/terms/objective) to which a [risk](https://essif-lab.github.io/framework/docs/terms/risk) is associated.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Risk level](#risk-level)
+
+    -   ### Essif-Lab
+
+        a measure for the deviation of the intended realization (results) of a specific [objective](https://essif-lab.github.io/framework/docs/terms/objective) that its [owner](https://essif-lab.github.io/framework/docs/terms/owner) uses to represent the priority with which the [risk](https://essif-lab.github.io/framework/docs/terms/risk) of that [objective](https://essif-lab.github.io/framework/docs/terms/objective) should be reckoned with.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Risk management](#risk-management)
+
+    -   ### Essif-Lab
+
+        a process that is run by (or on behalf of) a specific [party](https://essif-lab.github.io/framework/docs/terms/party) for the purpose of [managing](https://essif-lab.github.io/framework/docs/terms/management) the [risk](https://essif-lab.github.io/framework/docs/terms/risk) that it [owns](https://essif-lab.github.io/framework/docs/terms/owner) (thereby realizing specific [risk objectives](https://essif-lab.github.io/framework/docs/terms/risk-objective)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Role](#role)
+
+    -   ### Essif-Lab
+
+        a defined set of characteristics that an [entity](https://essif-lab.github.io/framework/docs/terms/entity) has in some context, such as [responsibilities](https://essif-lab.github.io/framework/docs/terms/obligation) it may have, [action](https://essif-lab.github.io/framework/docs/terms/action) (behaviors) it may execute, or pieces of [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) that it is expected to have in that context, which are referenced to by a specific [role name](https://essif-lab.github.io/framework/docs/terms/role-name).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Role name](#role-name)
+
+    -   ### Essif-Lab
+
+        name (text) that refers to (and identifies) a [role](https://essif-lab.github.io/framework/docs/terms/role) in a specific context.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Rotation](#Rotation)
+
+    -   ### TSWG (Keri)
+
+        the operation of revoking and replacing the set of authoritative keypairs for an AID. This operation is made verifiable and Duplicity evident upon acceptance as a Rotation event that is appended to the AIDs KEL.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Rotation event](#Rotationevent)
+
+    -   ### TSWG (ACDC)
+
+        an Establishment Event that provides the information needed to change the Key state which includes a change to the set of authoritative keypairs for an AID. See rotation event.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        an Establishment Event that provides the information needed to change the Key state which includes a change to the set of authoritative keypairs for an AID.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Rules](#Rules)
+
+    -   ### TSWG (ACDC)
+
+        a top-level field map within an ACDC that provides a legal language as a Ricardian Contract \[43\], which is both human and machine-readable and referenceable by a cryptographic digest.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [SAD](#SAD)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/sad)
+
+    -   ### WebOfTrust
+
+        # SAD
+
+        ###### See
+
+        [Self addressing data](https://weboftrust.github.io/keridoc/docs/glossary/self-addressing-data.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [SAID](#SAID)
+
+    -   ### WebOfTrust
+
+        # SAID
+
+        ###### See
+
+        [Self-addressing identifier](https://weboftrust.github.io/keridoc/docs/glossary/self-addressing-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [SATP](#SATP)
+
+    -   ### WebOfTrust
+
+        # SATP
+
+        ###### See
+
+        [Secure asset transfer protocol](https://weboftrust.github.io/keridoc/docs/glossary/secure-asset-transfer-protocol.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [SCID](#h.1hgjtlg27gg4)
+
+    -   ### ToIP
+
+        See: [self-certifying identifier](#h.hub48c59i8wj).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # SCID
+
+        ###### See
+
+        [Self-certifying identifier](https://weboftrust.github.io/keridoc/docs/glossary/self-certifying-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [SEMVER](#SEMVER)
+
+    -   ### TSWG (ACDC)
+
+        Semantic Versioning Specification 2.0. See also (https://semver.org)\[https://semver.org\]
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [SKRAP](#SKRAP)
+
+    -   ### WebOfTrust
+
+        # SKRAP
+
+        ###### See
+
+        [Signify/KERIA Request Authentication Protocol](https://weboftrust.github.io/keridoc/docs/glossary/signify-keria-request-authentication-protocol.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [SKWA](#SKWA)
+
+    -   ### WebOfTrust
+
+        # SKWA
+
+        ###### See
+
+        [Simple KERI for web auth](https://weboftrust.github.io/keridoc/docs/glossary/simple-keri-for-web-auth.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [SPAC](#SPAC)
+
+    -   ### WebOfTrust
+
+        # SPAC
+
+        ###### See
+
+        [Secure Private Authentic Confidentiality](https://weboftrust.github.io/keridoc/docs/glossary/secure-private-authentic-confidentiality.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [SSI](#SSI)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/ssi)
+
+    -   ### ToIP
+
+        See: [self-sovereign identity](#h.wdojy63bltd4).
+
+        Note: In some contexts, such as academic papers or industry conferences, this acronym has started to replace the term it represents.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # SSI
+
+        ###### See
+
+        [Self-sovereign identity](https://weboftrust.github.io/keridoc/docs/glossary/self-sovereign-identity.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [SSI (Self-Sovereign Identity)](#ssi-self-sovereign-identity)
+
+    -   ### Essif-Lab
+
+        sSI (Self-Sovereign Identity) is a term that has many different interpretations, and that we use to refer to concepts/ideas, architectures, processes and technologies that aim to support (autonomous) [parties](https://essif-lab.github.io/framework/docs/terms/party) as they negotiate and execute electronic [transaction](https://essif-lab.github.io/framework/docs/terms/transaction) with one another.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [SSI Agent](#ssi-agent)
+
+    -   ### Essif-Lab
+
+        a [digital agent](https://essif-lab.github.io/framework/docs/terms/agent) that provides one or more of the [ssi functionalities](https://essif-lab.github.io/framework/docs/terms/ssi-agent) ([issuer](https://essif-lab.github.io/framework/docs/terms/issuer), [holder](https://essif-lab.github.io/framework/docs/terms/holder), [verifier](https://essif-lab.github.io/framework/docs/terms/verifier), [wallet](https://essif-lab.github.io/framework/docs/terms/wallet)) to its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [SSI Assurance Community (SSI-AC)](#ssi-assurance-community-ssi-ac)
+
+    -   ### Essif-Lab
+
+        a [community](https://essif-lab.github.io/framework/docs/terms/community) that supports its members as they seek to increase their confidence in the [SSI infrastructure](https://essif-lab.github.io/framework/docs/terms/ssi-infrastructure) and/or (specific) [qualifications](https://essif-lab.github.io/framework/docs/terms/qualified-data) of the data exchanged through that infrastructure.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [SSI Infrastructure](#ssi-infrastructure)
+
+    -   ### Essif-Lab
+
+        the technological components that are (envisaged to be) all over the world for the purpose of providing, requesting and obtaining [qualified data](https://essif-lab.github.io/framework/docs/terms/qualified-data), for the purpose of negotiating and/or executing electronic [transaction](https://essif-lab.github.io/framework/docs/terms/transaction).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [SSL](#h.y0pexeg8ynlg)
+
+    -   ### ToIP
+
+        See: [Secure Sockets Layer](#h.gxktv8f54wc8).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Salt](#Salt)
+
+    -   ### TSWG (Keri)
+
+        random data fed as an additional input to a one-way function that hashes data.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Schema](#Schema)
+
+    -   ### TSWG (ACDC)
+
+        the SAID of a JSON schema that is used to issue and verify an ACDC.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Scope](#scope)
+
+    -   ### Essif-Lab
+
+        the extent of the area or subject matter (which we use, e.g., to define [pattern](https://essif-lab.github.io/framework/docs/terms/pattern), [concept](https://essif-lab.github.io/framework/docs/terms/concept), [term](https://essif-lab.github.io/framework/docs/terms/term) and [glossaries](https://essif-lab.github.io/framework/docs/terms/glossary) in, but it serves other purposes as well).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Scope of Control](#scope-of-control)
+
+    -   ### Essif-Lab
+
+        the extent of the area or subject matter that a [party](https://essif-lab.github.io/framework/docs/terms/party) [controls](https://essif-lab.github.io/framework/docs/terms/controller).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Scope: essifLabTerminology](#scope-essiflabterminology)
+
+    -   ### Essif-Lab
+
+        specification of the eSSIF-Lab scope.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Seal](#Seal)
+
+    -   ### TSWG (Keri)
+
+        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. See annex (Seal)\[#seal\].
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Secure Enclave](#h.lf0txjgjs67z)
+
+    -   ### ToIP
+
+        A coprocessor on Apple iOS devices that serves as a [trusted execution environment](#h.rsly6bxjqeg5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Secure Sockets Layer](#h.gxktv8f54wc8)
+
+    -   ### ToIP
+
+        The original transport layer security protocol developed by Netscape and partners. Now deprecated in favor of [Transport Layer Security](#h.6hbp4j6qy89) (TLS).
+
+        Also known as: [SSL](#h.y0pexeg8ynlg).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Selective Disclosure](#SelectiveDisclosure)
+
+    -   ### TSWG (ACDC)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Self-Addressing Identifier (SAID)](#SelfAddressingIdentifier\(SAID\))
+
+    -   ### TSWG (ACDC)
+
+        any identifier which is deterministically generated out of the content, digest of the content.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Self-Framing](#SelfFraming)
+
+    -   ### TSWG (CESR)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Self-Sovereign Identity (SSI)](#self-sovereign-identity-ssi)
+
+    -   ### Essif-Lab
+
+        self-Sovereign Identity (SSI) is a term that has many different interpretations, and that we use to refer to concepts/ideas, architectures, processes and technologies that aim to support (autonomous) [parties](https://essif-lab.github.io/framework/docs/terms/party) as they negotiate and execute electronic [transaction](https://essif-lab.github.io/framework/docs/terms/transaction) with one another.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Self-Sovereignty](#self-sovereignty)
+
+    -   ### Essif-Lab
+
+        the characteristic of every [party](https://essif-lab.github.io/framework/docs/terms/party) that it is autonomous in managing and operating its [owns](https://essif-lab.github.io/framework/docs/terms/owner) [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge), particularly in making decisions and deciding how to decide.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Self-addressed data](#Selfaddresseddata)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Self-addressing identifiers](#Selfaddressingidentifiers)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Self-certifying identifier](#Selfcertifyingidentifier)
+
+    -   ### TSWG (Keri)
+
+        a type of Cryptonym that is uniquely cryptographically derived from the public key of an asymmetric signing keypair, (public, private).
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Semantic Unit](#semantic-unit)
+
+    -   ### Essif-Lab
+
+        a basic building block of meaning or representation that exists within the 'mind' of a [party](https://essif-lab.github.io/framework/docs/terms/party) (i.e., in its [knowledge](https://weboftrust.github.io/keridoc/framework/docs/@essif-lab.md)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Semantics](#semantics)
+
+    -   ### Essif-Lab
+
+        a mapping between the (tangible/textual) [term](https://essif-lab.github.io/framework/docs/terms/term) and (intangible) ideas/[concept](https://essif-lab.github.io/framework/docs/terms/concept) - their meaning.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Semantics Pattern](#semantics-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain the relations between the (intangible) [concepts](https://essif-lab.github.io/framework/docs/terms/concept) (and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit)) that are part of a [party's](https://essif-lab.github.io/framework/docs/terms/party) [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge), and how they are (tangibly) represented by [terms](https://essif-lab.github.io/framework/docs/terms/term), [attributes](https://essif-lab.github.io/framework/docs/terms/attribute), etc.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Sovrin Foundation](#h.hj7rs7lm2bcn)
+
+    -   ### ToIP
+
+        A 501 (c)(4) nonprofit organization established to administer the [governance framework](#h.2x05z0r097mn) governing the Sovrin Network, a public service utility enabling [self-sovereign identity](#h.wdojy63bltd4) on the internet. The Sovrin Foundation is an independent [organization](#h.z27mp1358pi9) that is responsible for ensuring the Sovrin [identity](#h.z1gairv0pej5) system is public and globally accessible.
+
+        For more information, see: [https://sovrin.org/](https://www.google.com/url?q=https://sovrin.org/&sa=D&source=editors&ust=1718703186816403&usg=AOvVaw2dI7ngMiRRzs8IH6qkY984) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Stable](#Stable)
+
+    -   ### TSWG (CESR)
+
+        todo
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Stream](#Stream)
+
+    -   ### TSWG (ACDC)
+
+        a CESR Stream is any set of concatenated Primitives, concatenated groups of Primitives or hierarchically composed groups of Primitives.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (CESR)
+
+        any set of concatenated Primitives, concatenated groups of Primitives or hierarchically composed groups of Primitives.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Subject](#subject)
+
+    -   ### Essif-Lab
+
+        the (single) [entity](https://essif-lab.github.io/framework/docs/terms/entity) to which a given set of coherent data relates/pertains. Examples of such sets include attributes, [Claims/Assertions](https://essif-lab.github.io/framework/docs/terms/assertion), files/dossiers, [(verifiable) credentials](https://essif-lab.github.io/framework/docs/terms/credential), [(partial) identities](https://essif-lab.github.io/framework/docs/terms/partial-identity), [employment contracts](https://essif-lab.github.io/framework/docs/terms/employment-contract), etc.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Sybil attack](#h.jkl5esndzhl8)
+
+    -   ### ToIP
+
+        A Sybil attack is a type of attack on a computer network service in which an attacker subverts the service's [reputation system](#h.yzq3axr0dh87) by creating a large number of [pseudonymous](#h.tgbgt5tqzl4m) [identities](#h.z1gairv0pej5) and uses them to gain a disproportionately large influence. It is named after the subject of the book Sybil, a case study of a woman diagnosed with dissociative identity disorder.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Sybil_attack&sa=D&source=editors&ust=1718703186821728&usg=AOvVaw1E48ZkJZc3hYHGLIJFYaZt).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [TCP](#TCP)
+
+    -   ### Nist
+
+        TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees the delivery of data and also guarantees that packets will be delivered in the same order in which they were sent. 
+
+        [Learn more](https://csrc.nist.gov/glossary/term/tcp)
+
+    -   ### ToIP
+
+        See: [Transmission Control Protocol](#h.4wb0yz8sizvi).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # TCP
+
+        ###### See
+
+        [Transmission control protocol](https://weboftrust.github.io/keridoc/docs/glossary/transmission-control-protocol.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [TCP/IP](#h.txn6vkany9z9)
+
+    -   ### ToIP
+
+        See: [Internet Protocol Suite](#h.oj5ut8qopq0w).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [TCP/IP stack](#h.ph6h8stn1kne)
+
+    -   ### ToIP
+
+        The [protocol stack](#h.6ik2cef0ipsr) implementing the [TCP/IP](#h.txn6vkany9z9) suite.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [TEE](#TEE)
+
+    -   ### Nist
+
+        An area or enclave protected by a system processor.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/tee)
+
+    -   ### ToIP
+
+        See: [trusted execution environment](#h.rsly6bxjqeg5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # TEE
+
+        ###### See
+
+        [trusted execution environment](https://weboftrust.github.io/keridoc/docs/glossary/trusted-execution-environment.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [TEL](#TEL)
+
+    -   ### WebOfTrust
+
+        # TEL
+
+        ###### See
+
+        [Transaction event log](https://weboftrust.github.io/keridoc/docs/glossary/transaction-event-log.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [TLS](#h.edtto4e17uc0)
+
+    -   ### ToIP
+
+        See: [Transport Layer Security](#h.6hbp4j6qy89).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [TOAD](#TOAD)
+
+    -   ### WebOfTrust
+
+        # TOAD
+
+        ###### See
+
+        [threshold of accountable duplicity](https://weboftrust.github.io/keridoc/docs/glossary/threshold-of-accountable-duplicity.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [TPM](#TPM)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/tpm)
+
+    -   ### WebOfTrust
+
+        # TPM
+
+        ###### See
+
+        [Trusted platform module](https://weboftrust.github.io/keridoc/docs/glossary/trusted-platform-module.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [TSP](#TSP)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/tsp)
+
+    -   ### ToIP
+
+        See: [trust service provider](#h.lob8zt6w1hh), [trust spanning protocol](#h.fnuaao3a1j25).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # TSP
+
+        ###### See
+
+        [Trust Spanning Protocol](https://weboftrust.github.io/keridoc/docs/glossary/trust-spanning-protocol.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [TTA](#h.xeindhl0hc8h)
+
+    -   ### ToIP
+
+        See: [trusted timestamp authority](#h.ryrs51vhrwny).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [TTP](#h.v0r7skqmr47v)
+
+    -   ### ToIP
+
+        See: [trusted third party](#h.gzkj2oe82fof).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Tag](#tag)
+
+    -   ### Essif-Lab
+
+        an alphanumeric string that is used to identify [scope](https://essif-lab.github.io/framework/docs/terms/scope) (so called 'scopetags'), group [term](https://essif-lab.github.io/framework/docs/terms/term) (so called 'grouptags'), or identify a specific version of a [terminology](https://essif-lab.github.io/framework/docs/terms/terminology) (so called 'versiontags') from within a specific [scope](https://essif-lab.github.io/framework/docs/terms/scope).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Targeted ACDC](#TargetedACDC)
+
+    -   ### TSWG (ACDC)
+
+        an ACDC with the presence of the Issuee field in the attribute or attribute aggregate sections.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Term](#term)
+
+    -   ### Essif-Lab
+
+        a word or phrase (i.e.: text) that is used in at least one [scope](https://essif-lab.github.io/framework/docs/terms/scope)/context to represent a specific [concept](https://essif-lab.github.io/framework/docs/terms/concept).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Term (Scoped)](#term-scoped)
+
+    -   ### Essif-Lab
+
+        a [term](https://essif-lab.github.io/framework/docs/terms/term), the meaning of which is determined by the [definition](https://essif-lab.github.io/framework/docs/terms/definition) to which it refers in a specific [scope](https://essif-lab.github.io/framework/docs/terms/scope)/context.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Terminology](#terminology)
+
+    -   ### Essif-Lab
+
+        the set of [term](https://essif-lab.github.io/framework/docs/terms/term) that are used within a single [scope](https://essif-lab.github.io/framework/docs/terms/scope) to refer to a single [definition](https://essif-lab.github.io/framework/docs/terms/definition), enabling [parties](https://essif-lab.github.io/framework/docs/terms/party) to reason and communicate ideas they have about one or more specific topics.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Terminology Pattern](#terminology-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that one can use to explain one's thinking about a certain topic, as well as to devise/design a way of thinking that members of a [community](https://essif-lab.github.io/framework/docs/terms/community) can use to align their thinking as they pursue that [community's](https://essif-lab.github.io/framework/docs/terms/community) [objectives](https://essif-lab.github.io/framework/docs/terms/objective).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Terminology Process](#terminology-process)
+
+    -   ### Essif-Lab
+
+        a method for recognizing misunderstandings as such, and creating or maintaining [definition](https://essif-lab.github.io/framework/docs/terms/definition) that resolve them.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Terms Community](#terms-community)
+
+    -   ### Essif-Lab
+
+        a [community](https://essif-lab.github.io/framework/docs/terms/community) that maintains a [terminology](https://essif-lab.github.io/framework/docs/terms/terminology) for the purpose of avoiding misunderstandings between its members as they collaborate.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [ToIP](#h.c9o3btot3dtb)
+
+    -   ### ToIP
+
+        See: Trust Over IP
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Foundation](#h.500jynxuxkms)
+
+    -   ### ToIP
+
+        A non-profit project of the [Linux Foundation](https://www.google.com/url?q=https://www.linuxfoundation.org/&sa=D&source=editors&ust=1718703186833392&usg=AOvVaw3WNAWEqQp8-1b0Nzxws4OT) chartered to define an overall architecture for decentralized digital trust infrastructure known as the [ToIP stack](#h.wms58fgdch9m).
+
+        See also: [Decentralized Identity Foundation](#h.w2py1eklfcb), [OpenWallet Foundation](#h.271hay7m0g55).
+
+        For more information, see: [https://trustoverip.org/](https://www.google.com/url?q=https://trustoverip.org/&sa=D&source=editors&ust=1718703186833944&usg=AOvVaw2DpnPzT5cEJ4iG9FN9Jsng).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3)
+
+    -   ### ToIP
+
+        The specification defining the [requirements](#h.ajxlw8r3dvcc) for the [ToIP Governance Stack](#h.ciwa0pidrb2e) published by the [ToIP Foundation](#h.500jynxuxkms).
+
+        For more information, see: [https://trustoverip.org/our-work/deliverables/](https://www.google.com/url?q=https://trustoverip.org/our-work/deliverables/&sa=D&source=editors&ust=1718703186834705&usg=AOvVaw22Anwp25y09yG2brigajtn).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Governance Metamodel](#h.rgnaglzbhy9v)
+
+    -   ### ToIP
+
+        A structural model for [ToIP governance frameworks](#h.ns22ebn9xjun) that specifies the recommended [governance documents](#h.c8fvvxachz5h) that should be included depending on the [objectives](#h.k0v6ir8wmcav) of the [trust community](#h.a9l3odcb1s29).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Governance Stack](#h.ciwa0pidrb2e)
+
+    -   ### ToIP
+
+        The governance half of the four layer [ToIP stack](#h.wms58fgdch9m) as defined by the [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3).
+
+        See also: [ToIP Technology Stack](#h.9looruc0w4ac).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Layer 1](#h.24ggrl8oz4ma)
+
+    -   ### ToIP
+
+        The [trust support](#h.451usstmcuuk) layer of the [ToIP stack](#h.wms58fgdch9m), responsible for supporting the [trust spanning protocol](#h.fnuaao3a1j25) at [ToIP Layer 2](#h.ikqr9hyt133k).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Layer 2](#h.ikqr9hyt133k)
+
+    -   ### ToIP
+
+        The [trust spanning layer](#h.k9uiol17u620) of the [ToIP stack](#h.wms58fgdch9m), responsible for enabling the [trust task protocols](#h.uo2gx58kwj2o) at [ToIP Layer 3](#h.7rbvlbpp8vwp).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Layer 3](#h.7rbvlbpp8vwp)
+
+    -   ### ToIP
+
+        The [trust task](#h.vzu8kc1yz84q) layer of the [ToIP stack](#h.wms58fgdch9m), responsible for enabling [trust applications](#h.3pfn27y1gu2o) at [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Layer 4](#h.ym4v87xpn7gq)
+
+    -   ### ToIP
+
+        The [trust application](#h.3pfn27y1gu2o) layer of the [ToIP stack](#h.wms58fgdch9m), where end users have the direct [human experience](#h.p2mpipjsl834) of using applications that call [trust task protocols](#h.uo2gx58kwj2o) to engage in [trust relationships](#h.pu2asd79bqzo) and make [trust decisions](#h.m8c86ccqis9r) using ToIP decentralized digital trust infrastructure.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm)
+
+    -   ### ToIP
+
+        The [technical specification](#h.u62ak0cgfdb1) defining the [requirements](#h.ajxlw8r3dvcc) for the [ToIP Technology Stack](#h.9looruc0w4ac) published by the [ToIP Foundation](#h.500jynxuxkms).
+
+        For more information: [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Technology Stack](#h.9looruc0w4ac)
+
+    -   ### ToIP
+
+        The technology half of the four layer [ToIP stack](#h.wms58fgdch9m) as defined by the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+        See also: [ToIP Governance Stack](#h.ciwa0pidrb2e), [ToIP layer](#h.k5gg61txum2c).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Trust Registry Protocol](#h.1ma9v3f1h53f)
+
+    -   ### ToIP
+
+        The open standard [trust task protocol](#h.uo2gx58kwj2o) defined by the [ToIP Foundation](#h.500jynxuxkms) to perform the [trust task](#h.vzu8kc1yz84q) of querying a [trust registry](#h.5kzln6m5e8j5). The ToIP Trust Registry Protocol operates at [Layer 3](#h.b72avxgmeyfo) of the [ToIP stack](#h.wms58fgdch9m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl)
+
+    -   ### ToIP
+
+        The ToIP Layer 2 protocol for [verifiable messaging](#h.7zrsx7mki2fr) that implements the [trust spanning layer](#h.k9uiol17u620) of the [ToIP stack](#h.wms58fgdch9m).  The ToIP Trust Spanning Protocol enables [actors](#h.gzdfngxkp0ip) in different digital [trust domains](#h.60miqe21hd5h) to interact in a similar way to how the Internet Protocol (IP) enables devices on different local area networks to exchange data.
+
+        Mental model: [hourglass model,](#h.u8d1rxc2o86) see the [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf&sa=D&source=editors&ust=1718703186845093&usg=AOvVaw2OdtZNJIngp7qyOGhwsAqf).
+
+        For more information, see: [Section 7.3](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2373-layer-2-trust-spanning&sa=D&source=editors&ust=1718703186845538&usg=AOvVaw1hU_wKPSeewSeBGelbHYl5) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm) and the [Trust Spanning Protocol Task Force](https://www.google.com/url?q=https://wiki.trustoverip.org/display/HOME/ToIP%2BTrust%2BSpanning%2BProtocol%2BSpecification&sa=D&source=editors&ust=1718703186845871&usg=AOvVaw073rjCIFI_izeotXCMg_Q6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP application](#h.ieky0ghaj0ky)
+
+    -   ### ToIP
+
+        A [trust application](#h.3pfn27y1gu2o) that runs at [ToIP Layer 4](#h.ym4v87xpn7gq), the [trust application layer](#h.z9t23rwrm0qi).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP channel](#h.rp39gncihzvx)
+
+    -   ### ToIP
+
+        See: [VID relationship](#h.b3tilu21ql66).[\[c\]](#cmnt3)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP communication](#h.mqkudtdvvqw9)
+
+    -   ### ToIP
+
+        [Communication](#h.w02a6srdng3j) that uses the [ToIP stack](#h.wms58fgdch9m) to deliver [ToIP messages](#h.5th2gmjr7ij) between [ToIP endpoints](#h.2ahqabymbkn3), optionally using [intermediary systems](#h.i4pfys3yiku)[\[d\]](#cmnt4)[\[e\]](#cmnt5), to provide [authenticity](#h.pitlm5jn3v6u), [confidentiality](#h.445sv27j3c2m), and [correlation privacy](#h.7a6p0irhnbh5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP connection](#h.5i1yn2scvzvz)
+
+    -   ### ToIP
+
+        A [connection](#h.thbpewq1px8x) formed using the [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl) between two [ToIP endpoints](#h.e787fzjepk60) identified with [verifiable identifiers](#h.wyda231qefe). A ToIP connection is instantiated as one or more [VID relationships](#h.b3tilu21ql66).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP controller](#h.x1z2vxghptdm)
+
+    -   ### ToIP
+
+        The [controller](#h.gemoqe2m303z) of a [ToIP identifier](#h.xtyidw4bnytz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP endpoint](#h.2ahqabymbkn3)
+
+    -   ### ToIP
+
+        An [endpoint](#h.yodlnk353mx) that communicates via the [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl) as described in the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP governance framework](#h.ns22ebn9xjun)
+
+    -   ### ToIP
+
+        A [governance framework](#h.2x05z0r097mn) that conforms to the requirements of the [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP identifier](#h.xtyidw4bnytz)
+
+    -   ### ToIP
+
+        A [verifiable identifier](#h.wyda231qefe) for an [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186836307&usg=AOvVaw3YTdFNIU09N86o6Z_aoRKj) that is addressable using the [ToIP stack](#h.wms58fgdch9m).
+
+        See also: [autonomous identifier](#h.bz098kwwc559), [decentralized identifier](#h.x1jp59hgbk2l).
+
+        For more information, see: [Section 6.4](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2364-toip-identifiers&sa=D&source=editors&ust=1718703186836781&usg=AOvVaw2uPOrR_GopOna1LXDBQWy3) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP intermediary](#h.aiissvz29ktv)
+
+    -   ### ToIP
+
+        See: [intermediary system](#h.i4pfys3yiku).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP layer](#h.k5gg61txum2c)
+
+    -   ### ToIP
+
+        One of four [protocol layers](#h.pe8dekl2dtq0) in the [ToIP stack](#h.wms58fgdch9m). The four layers are [ToIP Layer 1](#h.24ggrl8oz4ma), [ToIP Layer 2](#h.ikqr9hyt133k), [ToIP Layer 3](#h.7rbvlbpp8vwp), and [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+        For more information, see: [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm), [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP message](#h.5th2gmjr7ij)
+
+    -   ### ToIP
+
+        A [message](#h.bge7ubygwk2q) communicated between [ToIP endpoints](#h.e787fzjepk60) using the [ToIP stack](#h.wms58fgdch9m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP stack](#h.wms58fgdch9m)
+
+    -   ### ToIP
+
+        The layered architecture for decentralized digital trust infrastructure defined by the [ToIP Foundation](#h.500jynxuxkms). The ToIP stack is a dual stack consisting of two halves: the [ToIP Technology Stack](#h.9looruc0w4ac) and the [ToIP Governance Stack](#h.ciwa0pidrb2e). The four layers in the ToIP stack are [ToIP Layer 1](#h.24ggrl8oz4ma), [ToIP Layer 2](#h.ikqr9hyt133k), [ToIP Layer 3](#h.7rbvlbpp8vwp), and [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+        For more information, see: [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm), [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP system](#h.jxcr1cndl4co)
+
+    -   ### ToIP
+
+        A computing system that participates in the [ToIP Technology Stack](#h.9looruc0w4ac). There are three types of ToIP systems: [endpoint systems](#h.scy14dobg777), [intermediary systems](#h.i4pfys3yiku), and [supporting systems](#h.nqtdtghyfspz).
+
+        For more information, see: [Section 6.3](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2363-high-level-system-architecture&sa=D&source=editors&ust=1718703186841331&usg=AOvVaw3QjJFkhLaKImWzycwIG8cH) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP trust community](#h.psztqwnbl6o7)
+
+    -   ### ToIP
+
+        A [trust community](#h.a9l3odcb1s29) governed by a [ToIP governance framework](#h.ns22ebn9xjun).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ToIP trust network](#h.xomvclbue1bi)
+
+    -   ### ToIP
+
+        A [trust network](#h.iy4t4brzsjkb) implemented using the [ToIP stack](#h.wms58fgdch9m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Transaction](#transaction)
+
+    -   ### Essif-Lab
+
+        the exchange of goods, services, funds, or data between some [parties](https://essif-lab.github.io/framework/docs/terms/party) (called [participant](https://essif-lab.github.io/framework/docs/terms/participant) of the [transaction](https://essif-lab.github.io/framework/docs/terms/transaction)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Transaction Agreement](#transaction-agreement)
+
+    -   ### Essif-Lab
+
+        the set of rules that specify the rights ([expectation](https://essif-lab.github.io/framework/docs/terms/expectation)) and duties ([obligation](https://essif-lab.github.io/framework/docs/terms/obligation)) of [participant](https://essif-lab.github.io/framework/docs/terms/participant) towards one another in the context of a specific [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Transaction Form](#transaction-form)
+
+    -   ### Essif-Lab
+
+        the specification of the set of data that this [party](https://essif-lab.github.io/framework/docs/terms/party) needs to (a) commit to a (proposed) [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction) of that kind, (b) fulfill its duties/[obligation](https://essif-lab.github.io/framework/docs/terms/obligation) and (c) escalate if necessary.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Transaction Id](#transaction-id)
+
+    -   ### Essif-Lab
+
+        character string that this [participant](https://essif-lab.github.io/framework/docs/terms/participant) uses to identify, and refer to, that [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Transaction Proposal](#transaction-proposal)
+
+    -   ### Essif-Lab
+
+        a [transaction agreement](https://essif-lab.github.io/framework/docs/terms/transaction-agreement) that is 'in-the-making' (ranging from an empty document to a document that would be a [transaction agreement](https://essif-lab.github.io/framework/docs/terms/transaction-agreement) if it were signed by all [participant](https://essif-lab.github.io/framework/docs/terms/participant)).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Transaction Request](#transaction-request)
+
+    -   ### Essif-Lab
+
+        a message, send by a requesting [party](https://essif-lab.github.io/framework/docs/terms/party) to a providing [party](https://essif-lab.github.io/framework/docs/terms/party), that initiates the negotiation of a new [transaction agreement](https://essif-lab.github.io/framework/docs/terms/transaction-agreement) between these [parties](https://essif-lab.github.io/framework/docs/terms/party) for the provisioning of a specific product or service.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Transmission Control Protocol](#h.4wb0yz8sizvi)
+
+    -   ### ToIP
+
+        The Transmission Control Protocol (TCP) is one of the main protocols of the [Internet protocol suite](#h.oj5ut8qopq0w). It originated in the initial network implementation in which it complemented the [Internet Protocol](#h.jmao5ngtvqnm) (IP). Therefore, the entire suite is commonly referred to as [TCP/IP](#h.txn6vkany9z9). TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. [SSL/TLS](#h.6hbp4j6qy89) often runs on top of TCP.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Transmission_Control_Protocol&sa=D&source=editors&ust=1718703186850002&usg=AOvVaw14as7a3Oa3YEBMnrdflgyI).
+
+        Also known as: [TCP](#h.6ztn6qj1hrax).
+
+        See also: [User Datagram Protocol](#h.di36optpv6sl).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Transport Layer Security](#h.6hbp4j6qy89)
+
+    -   ### ToIP
+
+        Transport Layer Security (TLS) is a cryptographic protocol designed to provide [communications](#h.w02a6srdng3j) security over a computer network. The protocol is widely used in applications such as email, instant messaging, and [Voice over IP](#h.k9c3o28fbg3b), but its use in securing HTTPS remains the most publicly visible. The TLS protocol aims primarily to provide security, including privacy ([confidentiality](#h.445sv27j3c2m)), integrity, and [authenticity](#h.pitlm5jn3v6u) through the use of cryptography, such as the use of [certificates](#h.vpsiiv68xxwc), between two or more communicating computer applications.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Transport_Layer_Security&sa=D&source=editors&ust=1718703186851595&usg=AOvVaw0uQxJzuq2uMY30-61wpmnF).
+
+        Also known as: [TLS](#h.edtto4e17uc0).
+
+        Note: TLS replaced the deprecated [Secure Sockets Layer](#h.gxktv8f54wc8) (SSL) protocol.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Tritet](#Tritet)
+
+    -   ### TSWG (CESR)
+
+        3 bits. See Performant resynchronization with unique start bits
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Trust](#trust)
+
+    -   ### Essif-Lab
+
+        the (un)conscious decision by a [party](https://essif-lab.github.io/framework/docs/terms/party) to believe that X is in fact the case.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Trust Pattern](#trust-pattern)
+
+    -   ### Essif-Lab
+
+        a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how the concept of [trust](https://essif-lab.github.io/framework/docs/terms/trust) relates to [parties](https://essif-lab.github.io/framework/docs/terms/party) that do the trusting, and other concepts that express what it is that these [parties](https://essif-lab.github.io/framework/docs/terms/party) trust.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Trust level](#trust-level)
+
+    -   ### Essif-Lab
+
+        the (subjective) degree of belief or confidence that a [party](https://essif-lab.github.io/framework/docs/terms/party) has in X (someone, something, ...).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Trust over IP](#h.nkx8p3tuemz)
+
+    -   ### ToIP
+
+        A term coined by John Jordan to describe the decentralized digital trust infrastructure made possible by the [ToIP stack](#h.wms58fgdch9m). A play on the term Voice over IP (abbreviated VoIP).
+
+        Also known as: [ToIP](#h.c9o3btot3dtb).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [UDP](#h.o11assyhncpl)
+
+    -   ### ToIP
+
+        See: [User Datagram Protocol](#h.di36optpv6sl).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [UI](#UI)
+
+    -   ### Nist
+
+        The physical or logical means by which users interact with a system, device or process.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/ui)
+
+    -   ### WebOfTrust
+
+        # UI
+
+        ###### See
+
+        [User interface](https://weboftrust.github.io/keridoc/docs/glossary/user-interface.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [URL](#URL)
+
+    -   ### Nist
+
+        A uniform resource locator, or URL, is a short string containing an address which refers to an object in the "web." URLs are a subset of URIs.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/url)
+
+    -   ### WebOfTrust
+
+        # URL
+
+        ###### See
+
+        [Uniform resource locator](https://weboftrust.github.io/keridoc/docs/glossary/uniform-resource-locator.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [Uniform Resource Identifier (URI)](#UniformResourceIdentifier\(URI\))
+
+    -   ### W3C (DID)
+
+        The standard identifier format for all resources on the World Wide Web asdefined by \[RFC3986\]. A DID is a type of URI scheme.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [Universally Unique Identifier (UUID)](#UniversallyUniqueIdentifier\(UUID\))
+
+    -   ### W3C (DID)
+
+        A type of globally unique identifier defined by \[RFC4122\]. UUIDs are similarto DIDs in that they do not require a centralized registration authority. UUIDsdiffer from DIDs in that they are not resolvable orcryptographically-verifiable.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [Unpermissioned correlation](#Unpermissionedcorrelation)
+
+    -   ### TSWG (ACDC)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Untargeted ACDC](#UntargetedACDC)
+
+    -   ### TSWG (ACDC)
+
+        an ACDC without the presence of the Issuee field in the attribute or attribute aggregate sections.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [User Datagram Protocol](#h.di36optpv6sl)
+
+    -   ### ToIP
+
+        In computer networking, the User Datagram Protocol (UDP) is one of the core [communication](#h.w02a6srdng3j) protocols of the [Internet protocol suite](#h.oj5ut8qopq0w) used to send [messages](#h.bge7ubygwk2q) (transported as [datagrams](#h.mxq90rincwo) in [packets](#h.9hc1adgu2nrx)) to other hosts on an [Internet Protocol](#h.jmao5ngtvqnm) (IP) network. Within an IP network, UDP does not require prior communication to set up [communication channels](#h.oc2pelzel246) or data paths.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User_Datagram_Protocol&sa=D&source=editors&ust=1718703186885768&usg=AOvVaw0gZAT2QNpuEZ-pmLgjgcd8).
+
+        Also known as: [UDP](#h.o11assyhncpl).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [VC](#VC)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/vc)
+
+    -   ### ToIP
+
+        See: [verifiable credential](#h.co5algna3zkh).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # VC
+
+        ###### See
+
+        [Verifiable credential](https://weboftrust.github.io/keridoc/docs/glossary/verifiable-credential.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [VC TEL](#VC-TEL)
+
+    -   ### WebOfTrust
+
+        # VC TEL
+
+        ###### See
+
+        [Virtual credential transaction event log](https://weboftrust.github.io/keridoc/docs/glossary/virtual-credential-transaction-event-log.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [VDS](#VDS)
+
+    -   ### Nist
+
+        Term found but the definition does not exist yet.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/vds)
+
+    -   ### WebOfTrust
+
+        # VDS
+
+        ###### See
+
+        [Verifiable data structure](https://weboftrust.github.io/keridoc/docs/glossary/verifiable-data-structure.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [VID](#h.qr5qljyd3se)
+
+    -   ### ToIP
+
+        See [​​verifiable identifier](#h.wyda231qefe).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # VID
+
+        ###### See
+
+        [Verifiable Identifier](https://weboftrust.github.io/keridoc/docs/glossary/verifiable-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [VID relationship](#h.b3tilu21ql66)
+
+    -   ### ToIP
+
+        The [communications](#h.w02a6srdng3j) relationship formed between two [VIDs](#h.qr5qljyd3se) using the [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl). A particular feature of this protocol is its ability to establish as many VID relationships as needed to establish different [relationship contexts](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2j6x3j2tgc4t&sa=D&source=editors&ust=1718703186900519&usg=AOvVaw0YNkhJfoy0tl8aWYrhgY9-) between the communicating [entities](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5imtbzl1f4xo&sa=D&source=editors&ust=1718703186900766&usg=AOvVaw2XMxnN1gK__Fr3uuGi-TUC).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [VID-to-VID](#h.s9775ggumyaj)
+
+    -   ### ToIP
+
+        The specialized type of [peer-to-peer](#h.ikjsqxobvozv) [communications](#h.w02a6srdng3j) enabled by the [ToIP Trust Spanning Protocol](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.6kyv8gxdd4sl&sa=D&source=editors&ust=1718703186901214&usg=AOvVaw2rDfSE4QUmX5LVdZ75ydZ8). Each pair of VIDs creates a unique [VID relationship](#h.b3tilu21ql66).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Validate](#validate)
+
+    -   ### Essif-Lab
+
+        the act, by or on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party), of determining whether or not that data is valid to be used for some specific purpose(s) of that [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Validator](#validator)
+
+    -   ### Essif-Lab
+
+        a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to determine whether or not ([verified](https://essif-lab.github.io/framework/docs/terms/verify)) data is valid to be used for some specific purpose(s).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+    -   ### TSWG (ACDC)
+
+        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. See validator.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        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.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Validator Policy](#validator-policy)
+
+    -   ### Essif-Lab
+
+        a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [validator](https://essif-lab.github.io/framework/docs/terms/validator) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Variable Length](#VariableLength)
+
+    -   ### TSWG (CESR)
+
+        a type of count code allowing for vaiable size signatures or attachments which can be parsed to get the full size
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [Verifiable](#Verifiable)
+
+    -   ### TSWG (Keri)
+
+        a condition of a KEL: being internally consistent with integrity of its backward and forward chaining digest as well as authenticity of its non-repudiable signatures.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Verifiable data registry](#Verifiabledataregistry)
+
+    -   ### TSWG (ACDC)
+
+        A role a system might perform by mediating issuance and verification of ACDCs. See verifiable data registry.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Verifier](#verifier)
+
+    -   ### Essif-Lab
+
+        a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to request [peer agents](https://essif-lab.github.io/framework/docs/terms/peer-agent) to present (provide) data from credentials (of a specified kind, issued by specified [parties](https://essif-lab.github.io/framework/docs/terms/party)), and to verify such responses (check structure, signatures, dates), according to its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [verifier policy](https://essif-lab.github.io/framework/docs/terms/verifier-policy).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+    -   ### TSWG (ACDC)
+
+        any entity or agent that cryptographically verifies the signature(s) and/or digests on an event Message. See verifier.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        any entity or agent that cryptographically verifies the signature(s) and digests on an event Message.
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Verifier Policy](#verifier-policy)
+
+    -   ### Essif-Lab
+
+        a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [verifier](https://essif-lab.github.io/framework/docs/terms/verifier) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Verify](#verify)
+
+    -   ### Essif-Lab
+
+        the act, by or on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party), of determining whether that data is authentic (i.e. originates from the [party](https://essif-lab.github.io/framework/docs/terms/party) that authored it), timely (i.e. has not expired), and conforms to other specifications that apply to its structure.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Version](#Version)
+
+    -   ### TSWG (CESR)
+
+        the CESR Version is provided by a special Count Code that specifies the Version of all the the CESR code tables in a given Stream or Stream section.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+    -   ### TSWG (Keri)
+
+        an instance of a KEL for an AID in which at least one event is unique between two instances of the KEL
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Version String](#VersionString)
+
+    -   ### TSWG (CESR)
+
+        the first field in any top-level KERI field map in which it appears.
+
+        [Learn more](https://trustoverip.github.io/tswg-cesr-specification/index.html)
+
+-   ## [VoIP](#h.uc1cvjmqqq0u)
+
+    -   ### ToIP
+
+        See: [Voice over IP](#h.k9c3o28fbg3b).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Vocabulary](#vocabulary)
+
+    -   ### Essif-Lab
+
+        the sum or stock of words employed by a language, group, individual, or work or in a field of knowledge.
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Voice over IP](#h.k9c3o28fbg3b)
+
+    -   ### ToIP
+
+        Voice over Internet Protocol (VoIP), also called IP telephony, is a method and group of technologies for voice calls for the delivery of voice [communication](#h.w02a6srdng3j) sessions over [Internet Protocol](#h.jmao5ngtvqnm) (IP) networks, such as the Internet.
+
+        Also known as: [VoIP](#h.uc1cvjmqqq0u).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [W3C Verifiable Credentials Data Model Specification](#h.mitd3elf05tf)
+
+    -   ### ToIP
+
+        A W3C Recommendation defining a standard data model and representation format for [cryptographically-verifiable](#h.422iwwfur12) [digital credentials](#h.ddna9lucn4k6). Version 1.1 was published on 03 March 2022.
+
+        For more information, see: [https://www.w3.org/TR/vc-data-model/](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/&sa=D&source=editors&ust=1718703186902762&usg=AOvVaw3f-vj70MyrOBmHgFL0kz7Q) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [Wallet](#wallet)
+
+    -   ### Essif-Lab
+
+        a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to securely store data as requested by [colleague agents](https://essif-lab.github.io/framework/docs/terms/colleague), and to provide stored data to [colleague agents](https://essif-lab.github.io/framework/docs/terms/colleague) or [peer agents](https://essif-lab.github.io/framework/docs/terms/peer-agent), all in [compliance](https://essif-lab.github.io/framework/docs/terms/compliance) with the rules of its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [wallet policy](https://essif-lab.github.io/framework/docs/terms/wallet-policy).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Wallet Policy](#wallet-policy)
+
+    -   ### Essif-Lab
+
+        a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [wallet](https://essif-lab.github.io/framework/docs/terms/wallet) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [Watcher](#Watcher)
+
+    -   ### TSWG (Keri)
+
+        an entity or component that keeps a copy of a KERL for an identifier but that is not designated by the controller of the identifier as one of its witnesses. See annex watcher
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [Weight](#Weight)
+
+    -   ### TSWG (ACDC)
+
+        an optional field map in the Edge section that provides edge weight property that enables directed weighted edges and operators that use weights.
+
+        [Learn more](https://trustoverip.github.io/tswg-acdc-specification/index.html)
+
+-   ## [Witness](#Witness)
+
+    -   ### TSWG (Keri)
+
+        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 Annex A under KAWA (KERIs Algorithm for Witness Agreement).
+
+        [Learn more](https://trustoverip.github.io/tswg-keri-specification/index.html)
+
+-   ## [XBRL](#XBRL)
+
+    -   ### WebOfTrust
+
+        # XBRL
+
+        ###### See
+
+        [eXtensible Business Reporting Language](https://weboftrust.github.io/keridoc/docs/glossary/extensible-business-reporting-language.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ZKP](#h.22kx42l0qs54)
+
+    -   ### ToIP
+
+        See: [zero-knowledge proof](#h.zc9pf8eexjs).
+
+        [\[a\]](#cmnt_ref1)@christine.martin@continuumloop.com you're good to go - start moving this to a 
+
+        https://github.com/trustoverip/ctwg-main-glossary
+
+        put the content in specs/terms\_and\_definitions.md
+
+        ping me with questions.
+
+        \_Assigned to christine.martin@continuumloop.com\_
+
+        [\[b\]](#cmnt_ref2)focus on the terms - do \[\[def: first, then see how many \[\[ref: you can get done.
+
+        [\[c\]](#cmnt_ref3)Christine, I had forgotten this link. Just added it now.
+
+        [\[d\]](#cmnt_ref4)definition no longer in document
+
+        [\[e\]](#cmnt_ref5)My bad. As you can tell, aligning terms with the ToIP Technology Architecture Specification was the last step I took, and when I did that, I didn't check to see where I had used the old terms. I fixed this.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [access control](#h.lmk4gqobt99b)
+
+    -   ### ToIP
+
+        The process of granting or denying specific requests for obtaining and using information and related information processing services.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/access_control&sa=D&source=editors&ust=1718703186568494&usg=AOvVaw02RGKmN9heCmnpzGUgnzBE).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Access_control&sa=D&source=editors&ust=1718703186568970&usg=AOvVaw326ZY5cVjD13BsU0qZguen): In [physical security](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Physical_security&sa=D&source=editors&ust=1718703186569181&usg=AOvVaw0Ol4CFpD64FW-u3vfnnFP4) and [information security](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Information_security&sa=D&source=editors&ust=1718703186569400&usg=AOvVaw0Fz4LdlyBdd8ePZaC_kTug), access control (AC) is the selective restriction of access to a place or other resource, while access management describes the process. The act of accessing may mean consuming, entering, or using. Permission to access a resource is called [authorization](#h.576ssfpt348i).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [access controlled interaction](#access-controlled-interaction)
+
+    -   ### WebOfTrust
+
+        # access controlled interaction
+
+        ###### Definition
+
+        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 attack prevention
+
+        Replay attacks are less of a concern, other than DDoS attack using resubmissions.
+
+        ##### Also see
+
+        [Registration Interaction](https://weboftrust.github.io/keridoc/docs/glossary/registration-interaction.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [account](#account)
+
+    -   ### digital.govt.nz
+
+        an instance of entity information in a contextAdditional note:Note 1: A common term for the set of entity information relating to 1 entity to which an authenticator can be registered and from which credential subject information can be taken to establish a Credential.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [accountable](#accountable)
+
+    -   ### digital.govt.nz
+
+        responsible for some action; answerable\[Source: expanded Dictionary meaning of accountable\]Additional note:Note 1: For roles such as Credential Provider and Relying Party, it is the primary publicly accessible party.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [accreditation (of an entity)](#h.so5aazavq41d)
+
+    -   ### ToIP
+
+        The independent, [third-party](#h.zu2vj8151tr) evaluation of an [entity,](#h.5imtbzl1f4xo) by a conformity assessment body (such as [certification body](#h.noh9fchc9jx), inspection body or laboratory) against recognised standards, conveying formal demonstration of its impartiality and competence to carry out specific conformity assessment tasks (such as [certification](#h.ytzysnyu57ec), inspection and testing).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Accreditation&sa=D&source=editors&ust=1718703186570253&usg=AOvVaw1GgA2DnKm2wZbqyTpF5LSk).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [accreditation body](#h.o68rspgihn1f)
+
+    -   ### ToIP
+
+        A [legal entity](#h.5328bxxk02sb) that performs [accreditation](#h.so5aazavq41d).
+
+        See also: [certification body](#h.noh9fchc9jx).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [action](#h.l54nzmooy631)
+
+    -   ### ToIP
+
+        Something that is actually done (a 'unit of work' that is executed) by a single [actor](#h.gzdfngxkp0ip) (on behalf of a given [party](#h.cn6bno48fomj)), as a single operation, in a specific context.
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23action&sa=D&source=editors&ust=1718703186571656&usg=AOvVaw2gC3qmEzDm8AgmATqaC4yD).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [actor](#h.gzdfngxkp0ip)
+
+    -   ### ToIP
+
+        An [entity](#h.5imtbzl1f4xo) that can act (do things/execute [actions](#h.l54nzmooy631)), e.g. people, machines, but not [organizations](#h.z27mp1358pi9). A [digital agent](#h.z3ugzt4hgdf6) can serve as an actor acting on behalf of its [principal](#h.sydbe7rk6244).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186572643&usg=AOvVaw0AY_fsx6wg0BL8LJHQsO-o).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [address](#h.tv1389o42vzp)
+
+    -   ### ToIP
+
+        See: [network address](#h.v9gosdu5b7z5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [administering authority](#h.7bgku6bcbjmq)
+
+    -   ### ToIP
+
+        See: [administering body](#h.w8r6jg7mkdaj).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [administering body](#h.w8r6jg7mkdaj)
+
+    -   ### ToIP
+
+        A [legal entity](#h.5328bxxk02sb) [delegated](#h.l7p0oyq4rvsz) by a [governing body](#h.1wptecwzvuvz) to administer the operation of a [governance framework](#h.2x05z0r097mn) and governed infrastructure for a [digital trust ecosystem](#h.h47f86smlz4y), such as one or more [trust registries](#h.5kzln6m5e8j5).
+
+        Also known as: [administering authority](#h.7bgku6bcbjmq).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [affected party](#affectedparty)
+
+    -   ### digital.govt.nz
+
+        a party that could be influenced; acted upon\[Source: expanded Dictionary meaning of affected\]Additional note:Note 1: For identification risk, the affected parties have been identified as:Entitled individual for example, an entitled individual applies for a service and is deemed ineligible because their identity has been used previously by someone else to claim the same service.Service provider for example, an organisations reputation suffers because of publicity that the agency has been defrauded by large numbers of individuals claiming false identities.Wider community for example, identification documents are mistakenly issued to people with false identities and are then used to commit fraud against other organisations.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [agency](#agency)
+
+    -   ### Nist
+
+        Any executive department, military department, government corporation, government controlled corporation, or other establishment in the executive branch of the government (including the Executive Office of the President), or any independent regulatory agency, but does not include: (i) the Government Accountability Office; (ii) the Federal Election Commission; (iii) the governments of the District of Columbia and of the territories and possessions of the United States, and their various subdivisions; or (iv) government-owned contractor-operated facilities, including laboratories engaged in national defense research and production activities.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/agency)
+
+    -   ### ToIP
+
+        In the context of decentralized digital trust infrastructure, the empowering of a [party](#h.cn6bno48fomj) to act independently of its own accord, and in particular to empower the party to employ an [agent](#h.6xkhfkjpo6xg) to act on the [party’s](#h.cn6bno48fomj) behalf.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # agency
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/agency.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [agent](#agent)
+
+    -   ### digital.govt.nz
+
+        a person, firm, etc. empowered to act for another\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        An [actor](#h.gzdfngxkp0ip) that is executing an [action](#h.l54nzmooy631) on behalf of a [party](#h.cn6bno48fomj) (called the [principal](#h.sydbe7rk6244) of that [actor](#h.gzdfngxkp0ip)). In the context of decentralized digital trust infrastructure, the term “agent” is most frequently used to mean a [digital agent](#h.z3ugzt4hgdf6).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23agent&sa=D&source=editors&ust=1718703186575067&usg=AOvVaw0Ti533d-l34TH_OEA5AlYq).
+
+        See also: [wallet](#h.mh27630t20d).
+
+        Note: In a ToIP context, an agent is frequently assumed to have privileged access to the [wallet](#h.mh27630t20d)(s) of its principal. In market parlance, a mobile app performing the [actions](#h.l54nzmooy631) of an agent is often simply called a [wallet](#h.mh27630t20d) or a [digital wallet](#h.sxnvf3f5v156).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # agent
+
+        ###### Definition
+
+        A representative for an identity. MAY require the use of a wallet. MAY support transfer.
+
+        ##### KERIA Agent
+
+        An agent in [KERIA](https://weboftrust.github.io/keridoc/docs/glossary/keria.md) terms is an instance of a keystore ([Hab](https://weboftrust.github.io/keridoc/docs/glossary/hab.md)) that runs in a given instance of the KERIA agent server.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ambient verifiability](#ambient-verifiability)
+
+    -   ### WebOfTrust
+
+        # ambient verifiability
+
+        ###### Definition
+
+        Verifiable by anyone, anywhere, at anytime. Although this seems a pretty general term, it was first used in the context of KERI by Sam Smith.
+
+        An example of ambient verifiability is _Ambient Duplicity Detection_ that describes the possibility of detecting duplicity by anyone, anywhere, anytime.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ample](#ample)
+
+    -   ### WebOfTrust
+
+        # ample
+
+        ###### Definition
+
+        The minimum required number of participants in an event to have a [supermajority](https://weboftrust.github.io/keridoc/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/keridoc/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 atall despite a dishonest controller but where at most F of the witnesses are potentially faulty.
+
+        Ample Agreement Constraint:
+        ![image](https://github.com/WebOfTrust/WOT-terms/assets/65027257/5c8733c1-4370-420c-83f0-f6e778a6b68f)
+
+        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.
+
+        ###### Problems avoided by using `ample`
+
+        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.
+
+        ###### Table of minimum required, or ample, number of participants
+
+        N = Number of total participants
+        M = Number of participants needed to get the guarantees of "ample"
+
+        ![image](https://github.com/WebOfTrust/WOT-terms/assets/65027257/01363aeb-7055-4413-bbc4-8f89325e703a)
+
+        ###### Code Example
+
+        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/keridoc/docs/glossary/KAACE.md):
+
+        ```python
+        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))
+        ```
+
+        [Learn more](https://kerisse.org)
+
+-   ## [amplification attack](#amplificationattack)
+
+    -   ### W3C (DID)
+
+        A class of attack where the attacker attempts to exhaust a target system'sCPU, storage, network, or other resources by providing small, valid inputs intothe system that result in damaging effects that can be exponentially more costlyto process than the inputs themselves.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [anonymous](#anonymous)
+
+    -   ### digital.govt.nz
+
+        not easily distinguished from others or from one another because of a lack of individual features or character\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        An adjective describing when the [identity](#h.z1gairv0pej5) of a [natural person](#h.yx4qb6dcjdvj) or other [actor](#h.gzdfngxkp0ip) is unknown.
+
+        See also: [pseudonym](#h.tgbgt5tqzl4m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [anycast](#h.adr8osyk2zcx)
+
+    -   ### ToIP
+
+        Anycast is a network [addressing](#h.tv1389o42vzp) and [routing](#h.tbxetxt0mdlp) methodology in which a single [IP address](#h.a8c3q7adyz7c) is shared by devices (generally servers) in multiple locations. [Routers](#h.oqbqyf914pln) direct packets addressed to this destination to the location nearest the sender, using their normal decision-making algorithms, typically the lowest number of BGP network hops. Anycast [routing](#h.tbxetxt0mdlp) is widely used by [content deliv](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Content_delivery_network&sa=D&source=editors&ust=1718703186576871&usg=AOvVaw1K-35RI9OYmc0RNt5TnWIy)e[ry networks](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Content_delivery_network&sa=D&source=editors&ust=1718703186577067&usg=AOvVaw1vUmNkGdR46g54M8gSItNH) such as web and name servers, to bring their content closer to end users.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Anycast&sa=D&source=editors&ust=1718703186577320&usg=AOvVaw0l60-mwZYJaygD4t1c45Nl).
+
+        See also: [broadcast](#h.s1uti8f9ufsv), [multicast](#h.nopxfdr8qtr6), [unicast](#h.bqegn99wxkdi).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [anycast address](#h.1jx31qh8hnuk)
+
+    -   ### ToIP
+
+        A [network address](#h.v9gosdu5b7z5) (especially an [IP address](#h.a8c3q7adyz7c)) used for [anycast](#h.adr8osyk2zcx) routing of network transmissions.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [append only event logs](#append-only-event-logs)
+
+    -   ### WebOfTrust
+
+        # append only event logs
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [application programming interface](#application-programming-interface)
+
+    -   ### WebOfTrust
+
+        # application programming interface
+
+        ###### Definition
+
+        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).
+
+        ###### API specification
+
+        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/keridoc/docs/glossary/API.md) may refer either to the specification or to the implementation.
+
+        More on [source](https://en.wikipedia.org/wiki/API) Wikipedia.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [appraisability (of a communications endpoint)](#h.wtzlm8ocwx7a)
+
+    -   ### ToIP
+
+        The ability for a [communication endpoint](#h.qstkv072p5tx) identified with a [verifiable identifier](#h.wyda231qefe) to be appraised for the set of its [properties](#h.c8vs1xa4uwn) that enable a [relying party](#h.61sr3qnr1eci) or a [verifier](#h.xfewd7t01hu0) to make a [trust decision](#h.m8c86ccqis9r) about communicating with that [endpoint](#h.yodlnk353mx).
+
+        See also: [trust basis](#h.hwb3cttekok1), [verifiability](#h.v9dou4wg2h9d).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [appropriate friction](#h.gqvsid8fr4dm)
+
+    -   ### ToIP
+
+        A user-experience design principle for information systems (such as digital wallets) specifying that the level of attention required of the [holder](#h.64mptmm24w7u) for a particular transaction should provide a reasonable opportunity for an informed choice by the [holder](#h.64mptmm24w7u).
+
+        Source: [PEMC IGR](https://www.google.com/url?q=https://kantarainitiative.org/download/pemc-implementors-guidance-report/&sa=D&source=editors&ust=1718703186579110&usg=AOvVaw0yeDeyAykKPgU7ui8ISfyN).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [architectural decision record](#architectural-decision-record)
+
+    -   ### WebOfTrust
+
+        # architectural decision record
+
+        ###### Definition
+
+        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/)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [assurance](#assurance)
+
+    -   ### digital.govt.nz
+
+        a statement, assertion, etc. intended to inspire confidence or give encouragement\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [assurance level](#h.hsktvoq15zz7)
+
+    -   ### ToIP
+
+        A level of confidence in a [claim](#h.akieli6njkk5) that may be relied on by others. Different types of assurance levels are defined for different types of trust assurance mechanisms. Examples include [authenticator assurance level](#h.a7560ebfrt4m), [federation assurance level](#h.8fhj7rpnpjy3), and [identity assurance level](#h.udr0qmo2ubln).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [attestation](#h.rewdd795x7iu)
+
+    -   ### ToIP
+
+        The issue of a statement, based on a decision, that fulfillment of specified [requirements](#h.ajxlw8r3dvcc) has been demonstrated. In the context of decentralized digital trust infrastructure, an attestation usually has a [digital signature](#h.s93np0i5rcne) so that it is [cryptographically verifiable](#h.422iwwfur12).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/attestation&sa=D&source=editors&ust=1718703186579678&usg=AOvVaw2FilfhASEGB9nm1zpHx0pP).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [attribute](#attribute)
+
+    -   ### digital.govt.nz
+
+        (noun) a characteristic or quality of a person or thing\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        An identifiable set of data that describes an [entity](#h.5imtbzl1f4xo), which is the [subject](#h.voca6uuv1a4) of the attribute.
+
+        See also: [property](#h.c8vs1xa4uwn).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23attribute&sa=D&source=editors&ust=1718703186580390&usg=AOvVaw2TIPmlM5liVH-mpbXlpMXA): [Data](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/data&sa=D&source=editors&ust=1718703186580583&usg=AOvVaw1XNG-vjV4TpbK061nv5nL2) that represents a characteristic that a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186580833&usg=AOvVaw09JwhXedtNKkI3yOHz-wTE) (the [owner](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/owner&sa=D&source=editors&ust=1718703186581004&usg=AOvVaw2PAgjZSHuYHFP_80jNoffU) of the [attribute](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/attribute&sa=D&source=editors&ust=1718703186581211&usg=AOvVaw0wC9nadaVSoNpNHSW7Q82p)) has attributed to an [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186581439&usg=AOvVaw0EJGlbOCpwgrP8UaEpHWZ0) (which is the [subject](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/subject&sa=D&source=editors&ust=1718703186581608&usg=AOvVaw38X7MyfxPP9j4x37JhiUzX) of that attribute).
+
+        Note: An [identifier](#h.u3bfehmj4ed3) is an attribute that uniquely identifies an [entity](#h.5imtbzl1f4xo) within some context.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [attribute-based access control](#h.ckr2atznm0o)
+
+    -   ### ToIP
+
+        An [access control](#h.lmk4gqobt99b) approach in which access is mediated based on [attributes](#h.ky5nh3yri7ak) associated with [subjects](#h.voca6uuv1a4) (requesters) and the objects to be accessed. Each object and [subject](#h.voca6uuv1a4) has a set of associated [attributes](#h.ky5nh3yri7ak), such as location, time of creation, access rights, etc. Access to an object is [authorized](#h.576ssfpt348i) or denied depending upon whether the required (e.g., policy-defined) correlation can be made between the [attributes](#h.ky5nh3yri7ak) of that object and of the requesting [subject](#h.voca6uuv1a4).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/attribute_based_access_control&sa=D&source=editors&ust=1718703186582598&usg=AOvVaw3LiKlM91tb7d6UypLqk9ct).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Attribute-based_access_control&sa=D&source=editors&ust=1718703186582857&usg=AOvVaw3dpsUD7Thf94nQr-CJDZnH): Attribute-based access control (ABAC), also known as policy-based access control for [IAM](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Identity_management&sa=D&source=editors&ust=1718703186583016&usg=AOvVaw3iRf5JLfwx77zgEqgYMVma), defines an access control paradigm whereby a subject's authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment attributes.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [attributional trust](#attributional-trust)
+
+    -   ### WebOfTrust
+
+        # attributional trust
+
+        ###### Definition
+
+        KERI offers cryptographic root-of-trust to establish attributional trust. In the real world you'd also need [reputational trust](https://weboftrust.github.io/keridoc/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)
+
+        ###### OOBI
+
+        [Out-of-band Introduction](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/identity-assurance.md) by a to be trusted middle-men party, like [GLEIF](https://weboftrust.github.io/keridoc/docs/glossary/GLEIF.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [audit (of system controls)](#h.3gz7xw796mvp)
+
+    -   ### ToIP
+
+        Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established [policies](#h.udts41hso4w4) and operational procedures.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/audit&sa=D&source=editors&ust=1718703186583421&usg=AOvVaw28_0FIZJOFGxirs1KJWEiy).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [audit log](#h.t9sy0qj2hw3p)
+
+    -   ### ToIP
+
+        An audit log is a security-relevant chronological [record](#h.y4ybzkfe6yzv), set of [records](#h.y4ybzkfe6yzv), and/or destination and source of [records](#h.y4ybzkfe6yzv) that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Audit_trail&sa=D&source=editors&ust=1718703186583886&usg=AOvVaw3dZs1Tm7kvkGvttzINf7Ge).
+
+        Also known as: audit trail.
+
+        See also: [key event log](#h.6jhhyjh47h).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [auditor (of an entity)](#h.g2w6uyjqzrr)
+
+    -   ### ToIP
+
+        The [party](#h.cn6bno48fomj) responsible for performing an [audit](#h.3gz7xw796mvp). Typically an auditor must be [accredited](#h.so5aazavq41d).
+
+        See also: [human auditable](#h.22bo41j3q290).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [authentic chained data container](#authentic-chained-data-container)
+
+    -   ### WebOfTrust
+
+        # authentic chained data container
+
+        ###### Definition
+
+        In brief, an ACDC or [ADC](https://weboftrust.github.io/keridoc/docs/glossary/authentic-data-container.md) proves digital data consistency and authenticity in one go. An ACDC cryptographically secures commitment to data contained, and its identifiers are self-addressing, which means they point to themselves and are also contained ìn the data.
+
+        ![](https://hackmd.io/_uploads/HJDwDAUsq.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authentic chained data container (ACDC)](#authenticchaineddatacontainer\(ACDC\))
+
+    -   ### ToIP (DID:Webs)
+
+        a variant of the Verifiable Credential (VC) specification that inherits the security model derived from KERI, as defined by the ACDC specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [authentic data](#authentic-data)
+
+    -   ### WebOfTrust
+
+        # authentic data
+
+        ###### Definition
+
+        [Integer](https://weboftrust.github.io/keridoc/docs/glossary/integrity.md) and [Provenanced](https://weboftrust.github.io/keridoc/docs/glossary/provenance.md) data. Source: Timothy Ruff #IIW37
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authentic data container](#authentic-data-container)
+
+    -   ### WebOfTrust
+
+        # authentic data container
+
+        ###### Definition
+
+        A mechanism for conveying data that allows the [authenticity](https://weboftrust.github.io/keridoc/docs/glossary/authenticity.md) of its content to be proved.
+
+        ###### Instance
+
+        A [Verifiable Credential](https://w3.org/TR/vc-data-model/) is an ACDC
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authentic provenance chain](#authentic-provenance-chain)
+
+    -   ### WebOfTrust
+
+        # authentic provenance chain
+
+        ###### Definition
+
+        Interlinked presentations of evidence that allow data to be tracked back to its origin in an objectively verifiable way.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authentic web](#authentic-web)
+
+    -   ### WebOfTrust
+
+        # authentic web
+
+        ###### Definition
+
+        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'.
+
+        ###### Related
+
+        -   `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/keridoc/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'.
+
+        ###### Scalability of Key state at rest
+
+        -   You can append to any part of the (directed-acyclic) [graph](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/root-of-trust.md)
+
+        ###### KERI related
+
+        KERI solves all hard problems of the authentic web in a scalable manner.
+
+        ###### Technically oriented deep dive
+
+        See more in [Concepts](https://weboftrust.github.io/WOT-terms/docs/concepts/concepts?level=2) behind KERI
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authenticate](#authenticate)
+
+    -   ### W3C (DID)
+
+        Authentication is a process by which an entity can prove it has a specificattribute or controls a specific secret using one or more verificationmethods. With DIDs, a common example would be proving control of thecryptographic private key associated with a public key published in a DIDdocument.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [authentication](#authentication)
+
+    -   ### digital.govt.nz
+
+        process for establishing an authenticator is genuine or as represented\[Source: expanded Dictionary meaning of authenticate\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [authentication (of a user, process, or device)](#h.gp553sxzbmv1)
+
+    -   ### ToIP
+
+        Verifying the [identity](#h.z1gairv0pej5) of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authentication&sa=D&source=editors&ust=1718703186584961&usg=AOvVaw2XCY26WFB-FaCYqMMU4Rn6).
+
+        See also: [authenticator](#h.ej596duqqmnb), [verifiable message](#h.7zrsx7mki2fr).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Authentication&sa=D&source=editors&ust=1718703186585448&usg=AOvVaw3dM0Hnrcxha8UHy4HZVymu): The act of proving an [assertion](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Logical_assertion&sa=D&source=editors&ust=1718703186585626&usg=AOvVaw01KB6TC9x03v-a_x_8sEF0), such as the [identity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_identity&sa=D&source=editors&ust=1718703186585764&usg=AOvVaw1_PCfFG6X3G1_zyB8qkV-6) of a computer system user.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [authenticator](#authenticator)
+
+    -   ### digital.govt.nz
+
+        things known and/or possessed and controlled by an entity that are used to be recognised when they return to an organisation\[Source: Based on NIST SP 800-63-3 Digital Identity Guidelines\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [authenticator (of an entity)](#h.ej596duqqmnb)
+
+    -   ### ToIP
+
+        Something the claimant possesses and controls (typically a cryptographic module or password) that is used to [authenticate](#h.gp553sxzbmv1) the claimant’s [identity](#h.z1gairv0pej5).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authenticator&sa=D&source=editors&ust=1718703186586186&usg=AOvVaw1p3p1yMLrUuUUebBdmSkVT).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [authenticator assurance level](#h.a7560ebfrt4m)
+
+    -   ### ToIP
+
+        A measure of the strength of an [authentication](#h.gp553sxzbmv1) mechanism and, therefore, the confidence in it.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authenticator_assurance_level&sa=D&source=editors&ust=1718703186586640&usg=AOvVaw0gZCj0xRd3v7FYwZuQaMaJ).
+
+        See also: [federation assurance level](#h.8fhj7rpnpjy3), [identity assurance level](#h.udr0qmo2ubln), [identity binding](#h.kwudvu8h2zex).
+
+        Note: In [NIST SP 800-63-3](https://www.google.com/url?q=https://pages.nist.gov/800-63-3/sp800-63-3.html&sa=D&source=editors&ust=1718703186587091&usg=AOvVaw3VMIT-pTrDFSmAcKYF1WS0), AAL is defined in terms of three levels: AAL1 (Some confidence), AAL2 (High confidence), AAL3 (Very high confidence).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [authenticator holder](#authenticatorholder)
+
+    -   ### digital.govt.nz
+
+        the entity to which an authenticator was initially bound; the rightful holder\[Source: New definition\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [authenticity](#authenticity)
+
+    -   ### Nist
+
+        The property of being genuine and being able to be verified and trusted; confidence in the validity of a transmission, a message, or message originator
+
+        [Learn more](https://csrc.nist.gov/glossary/term/authenticity)
+
+    -   ### ToIP
+
+        The [property](#h.c8vs1xa4uwn) of being genuine and being able to be [verified](#h.k2qmzn3tjzsl) and trusted; confidence in the [validity](#h.rbp41an0omv6) of a transmission, a [message](#h.bge7ubygwk2q), or message originator.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authenticity&sa=D&source=editors&ust=1718703186588270&usg=AOvVaw2BF-37XWwAhukJ2ZKlmwD5).
+
+        See also: [confidentiality](#h.445sv27j3c2m), [correlation privacy](#h.7a6p0irhnbh5), [cryptographic verifiability](#h.lbqfpvfmcmoq).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # authenticity
+
+        ###### Definition
+
+        The quality of having an objectively verifiable origin ; contrast [veracity](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/security.md). Ideally it should be [verifiable](https://weboftrust.github.io/keridoc/docs/glossary/verifiable.md) (to a [root-of-trust](https://weboftrust.github.io/keridoc/docs/glossary/root-of-trust.md)). The future picture therein is the [Authentic Web](https://weboftrust.github.io/keridoc/docs/glossary/authentic-web.md).
+
+        ###### KERI related
+
+        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.
+
+        ###### Also see
+
+        -   [confidentiality](https://weboftrust.github.io/keridoc/docs/glossary/confidentiality.md)
+        -   [privacy](https://weboftrust.github.io/keridoc/docs/glossary/privacy.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authoritative](#authoritative)
+
+    -   ### digital.govt.nz
+
+        possessing or supported by authority; official\[Source: Dictionary\]Additional note:Note 1: Indigenous peoples, society and industry communities can nominate a party as authoritative. Its possible that such a party is subject to legal controls.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### WebOfTrust
+
+        # authoritative
+
+        ###### Definition
+
+        Established control [authority](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/PKI.md) key pairs that have this feature.
+
+        ###### Four A’s of secure data control
+
+        1.  Author: creator, [source-of-truth](https://weboftrust.github.io/keridoc/docs/glossary/source-of-truth.md)
+        2.  Authentic: provable origin, [root-of-trust](https://weboftrust.github.io/keridoc/docs/glossary/root-of-trust.md)
+        3.  Authorized: consent, [loci-of-control](https://weboftrust.github.io/keridoc/docs/glossary/loci-of-control.md)
+        4.  **Authoritative: accurate, reputable**
+
+        "A4" data control securely is established via [self-certifying](https://weboftrust.github.io/keridoc/docs/glossary/self-certifying-identifier.md) pseudonymous identifiers
+        [Source](https://youtu.be/L82O9nqHjRE) Samuel M. Smith
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authoritative source](#h.9tt1qpgdfnxs)
+
+    -   ### ToIP
+
+        A source of information that a [relying party](#h.61sr3qnr1eci) considers to be [authoritative](#h.gln5i78kxlfh) for that information. In ToIP architecture, the [trust registry](#h.5kzln6m5e8j5) authorized by the [governance framework](#h.2x05z0r097mn) for a [trust community](#h.a9l3odcb1s29) is typically considered an authoritative source by the members of that [trust community](#h.a9l3odcb1s29). A [system of record](#h.ceh3cl4l0xnp) is an authoritative source for the data records it holds. A [trust root](#h.vfnyletkzjv5) is an authoritative source for the beginning of a [trust chain](#h.xsqvwmepvctc).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [authority](#h.gln5i78kxlfh)
+
+    -   ### ToIP
+
+        A [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186591524&usg=AOvVaw3bE93LTsr3IaDtWDyCpZGT) of which certain decisions, ideas, [rules](#h.v7s575ulon74) etc. are followed by other [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186591748&usg=AOvVaw0tzEpT0XBXPEBLljOuUsIH).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/authority&sa=D&source=editors&ust=1718703186591943&usg=AOvVaw1cKo_K6CCUhtXdXEyrVjGP).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # authority
+
+        ###### See ToIP glossary
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authorization](#h.576ssfpt348i)
+
+    -   ### ToIP
+
+        The process of [verifying](#h.xfewd7t01hu0) that a requested [action](#h.l54nzmooy631) or service is approved for a specific [entity](#h.5imtbzl1f4xo).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authorization&sa=D&source=editors&ust=1718703186589082&usg=AOvVaw0h1k7PuVzCrS2l8WGhMoV2).
+
+        See also: [permission](#h.mnqlrmrkqb9).
+
+        authorized organizational representative
+
+        A [person](#h.yx4qb6dcjdvj) who has the authority to make [claims](#h.akieli6njkk5), sign documents or otherwise commit resources on behalf of an [organization](#h.z27mp1358pi9).
+
+        Source: [Law Insider](https://www.google.com/url?q=https://www.lawinsider.com/dictionary/authorized-organizational-representative%23:~:text%3DAuthorized%2520Organizational%2520Representative%2520means%2520the,the%2520resources%2520of%2520the%2520organization.&sa=D&source=editors&ust=1718703186589822&usg=AOvVaw3l0HKtZgF4Ilo7RhnkgOh3)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # authorization
+
+        ###### Definition
+
+        Is the function of specifying access rights/privileges to resources, which is related to general [information security](https://en.wikipedia.org/wiki/Information_security) and [computer security](https://en.wikipedia.org/wiki/Computer_security), and to [access control](https://en.wikipedia.org/wiki/Access_control) in particular.
+
+        More formally, "to authorize" is to define an access policy.
+
+        ###### KERI specific
+
+        Authorizations have the form of a signed authorization statement where the statement typically includes the [AID](https://weboftrust.github.io/keridoc/docs/glossary/autonomic-identifier.md) under which the authorization is issued. A [verifier](https://weboftrust.github.io/keridoc/docs/glossary/verifier.md) may then [verify](https://weboftrust.github.io/keridoc/docs/glossary/verify.md) the authorization by verifying the attached signature using the keys that were authoritative at the time the authorization was issued. These authorizations are secure to the extent that the established control authority is secure. The authorizations inherit their [security](https://weboftrust.github.io/keridoc/docs/glossary/security.md) from their associated AID.
+
+        ##### W3C VC form
+
+        Authorizations may take many forms. One form of particular interest is the _W3C Verifiable Credential_ [VC](https://weboftrust.github.io/keridoc/docs/glossary/VC.md) standard. Verifiable credentials use the W3C Decentralized Identifier [DID](https://weboftrust.github.io/keridoc/docs/glossary/DID.md) standard. The DID standard provides name spacing syntax for decentralized identifiers that is evocative of URIs. A given DID may be a type of AID but **not all DIDs are AIDs**. Furthermore, because AIDs may use other name space syntax standards besides DIDs, **not all AIDs are DIDs**. KERI itself is name space agnostic so may be used to support AIDs in any name space that accepts [pseudo-random](https://weboftrust.github.io/keridoc/docs/glossary/pseudo-random-number.md) strings as an element.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [authorization graph](#h.5tvkchqqqka8)
+
+    -   ### ToIP
+
+        A graph of the [authorization](#h.576ssfpt348i) relationships between different entities in a [trust community](#h.a9l3odcb1s29). In a [digital trust ecosystem](#h.h47f86smlz4y), the [governing body](#h.1wptecwzvuvz) is typically the [trust root](#h.vfnyletkzjv5) of an authorization graph. In some cases, an authorization graph can be traversed by making queries to one or more [trust registries](#h.5kzln6m5e8j5).
+
+        See also: [governance graph](#h.u9xnz96ecf5x), [reputation graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.4wwkekt1wrs7&sa=D&source=editors&ust=1718703186590578&usg=AOvVaw08xfTXgPY0_DWgvZM_8DqP), [trust graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.eqx98nkqjzsv&sa=D&source=editors&ust=1718703186590782&usg=AOvVaw3Z5RhHKcsyLA8dVqSl4s_a).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [authorized vlei representative](#authorized-vlei-representative)
+
+    -   ### WebOfTrust
+
+        # authorized vlei representative
+
+        ###### Definition
+
+        Also 'AVR'. This a representative of a Legal Entity that are authorized by the [DAR](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/official-organizational-role.md) vLEI Credentials)
+        -   Legal Entity Engagement Context Role vLEI Credentials ([ECR](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [autonomic computing systems](#autonomic-computing-systems)
+
+    -   ### WebOfTrust
+
+        # autonomic computing systems
+
+        ###### Definition
+
+        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".
+
+        [Learn more](https://kerisse.org)
+
+-   ## [autonomic identifier](#h.bz098kwwc559)
+
+    -   ### ToIP
+
+        The specific type of [self-certifying identifier](#h.hub48c59i8wj) specified by the [KERI](#h.7pp65h7qs9lu) specifications.
+
+        Also known as: [AID](#h.15sa9rrid2f).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # autonomic identifier
+
+        ###### Definition
+
+        An identifier that is [self-certifying](https://weboftrust.github.io/keridoc/docs/glossary/self-certifying-identifier.md) and [self-sovereign](https://weboftrust.github.io/keridoc/docs/glossary/self-sovereign-identity.md) (or _self-managing_).
+
+        ###### KERI related requirements
+
+        A self-managing [cryptonym](https://weboftrust.github.io/keridoc/docs/glossary/cryptonym.md)ous identifier that MUST be self-certifying (self-authenticating) and MUST be encoded in CESR as a [qualified](https://weboftrust.github.io/keridoc/docs/glossary/qualified.md) cryptographic primitive. An AID MAY exhibit other self-managing properties such as transferable control using key [pre-rotation](https://weboftrust.github.io/keridoc/docs/glossary/pre-rotation.md) which enables control over such an AID to persist in spite of key weakness or compromise due to exposure. [Authoritative](https://weboftrust.github.io/keridoc/docs/glossary/authoritative.md) control over the identifier persists in spite of the evolution of the key-state.
+        Source Samuel M. Smith, [ietf-keri draft](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md)
+
+        ###### Autonomic Identifier more general
+
+        Autonomic Identifiers have been pretty well described in this piece as opposed to centralised (administrative) and blockchain-based (algorithmic) identifier systems: **Architectural types of Identity Systems**; originally by Phil Windley in this [article](https://www.windley.com/archives/2020/09/the_architecture_of_identity_systems.shtml).
+
+        A summarizing comparison table might say more than a hundred words:
+
+        ![summarising the trust bases of administrative, algorithmic and autonomic identifier systems](https://hackmd.io/_uploads/HyOi3r81j.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [autonomic identifier (AID)](#autonomicidentifier\(AID\))
+
+    -   ### ToIP (DID:Webs)
+
+        A self-certifying identifier (SCID) that is cryptographically bound cryptographically bound to a key event log (KEL), as defined by the KERI specification. An AID is either non-transferable or transferable. A non-transferable AID does not support key rotation while a transferable AID supports key rotation using a key pre-rotation mechanism that enables the AID to persist in spite of the evolution of its key state. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [autonomic identity system](#autonomic-identity-system)
+
+    -   ### WebOfTrust
+
+        # autonomic identity system
+
+        ###### Definition
+
+        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.
+
+        ![](https://raw.githubusercontent.com/WebOfTrust/keri/main/images/ais.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [autonomic namespace](#autonomic-namespace)
+
+    -   ### WebOfTrust
+
+        # autonomic namespace
+
+        ###### Definition
+
+        A namespace that is self-certifying and hence self-administrating. ANs are therefore portable = truly self sovereign.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [autonomic trust basis](#autonomic-trust-basis)
+
+    -   ### WebOfTrust
+
+        # autonomic trust basis
+
+        ###### Definition
+
+        When use an [AID](https://weboftrust.github.io/keridoc/docs/glossary/AID.md) as the [root-of-trust](https://weboftrust.github.io/keridoc/docs/glossary/root-of-trust.md) we form a so-called _autonomic trust basis_. This is diagrammed as follows:
+
+        ![](https://github.com/weboftrust/WOT-terms/static/img/autonomic-trust-basis.png)
+
+        ###### Other trust bases
+
+        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/keridoc/docs/glossary/security.md) nor [decentralized](https://weboftrust.github.io/keridoc/docs/glossary/decentralized-identifier.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [backer](#backer)
+
+    -   ### WebOfTrust
+
+        # backer
+
+        ###### Definition
+
+        The terms Backer and [Witness](https://github.com/trustoverip/acdc/wiki/witness) are closely related in KERI. Backers include both regular KERI witnesses and ledger-registered backers.
+
+        ![](https://raw.githubusercontent.com/WebOfTrust/keri/main/images/backer-witness.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [base media type](#base-media-type)
+
+    -   ### WebOfTrust
+
+        # base media type
+
+        ###### Definition
+
+        `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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [base64](#base64)
+
+    -   ### WebOfTrust
+
+        # base64
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [bespoke credential](#bespoke-credential)
+
+    -   ### WebOfTrust
+
+        # bespoke credential
+
+        ###### Definition
+
+        It's an [issuance](https://weboftrust.github.io/keridoc/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).
+
+        ###### Example
+
+        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)
+
+        ###### Advantage
+
+        We can use all the tools available for issuance and presentation we already have.
+
+        ###### How the process work
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [best available data acceptance mechanism](#best-available-data-acceptance-mechanism)
+
+    -   ### WebOfTrust
+
+        # best available data acceptance mechanism
+
+        ###### Definition
+
+        The BADA security model provides a degree of [replay attack](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/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.
+
+        ###### See also
+
+        -   [Run off the crud](https://weboftrust.github.io/keridoc/docs/glossary/run-off-the-crud.md)
+        -   [RUN](https://weboftrust.github.io/keridoc/docs/glossary/read-update-nullify.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [bexter](#bexter)
+
+    -   ### WebOfTrust
+
+        # bexter
+
+        ###### Definition
+
+        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.
+
+        ###### More details
+
+        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 theqb64 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'
+
+        ###### Example uses:
+
+        -   CESR encoded paths for nested SADs and SAIDs
+        -   CESR encoded fractionally weighted threshold expressions
+
+        ###### Attributes
+
+        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 otherwiseProperties: .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 Base64Methods:"""
+
+        [Learn more](https://kerisse.org)
+
+-   ## [binding](#binding)
+
+    -   ### digital.govt.nz
+
+        (noun) the action of a person or thing that binds\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### Nist
+
+        Process of associating two related elements of information.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/binding)
+
+    -   ### WebOfTrust
+
+        # binding
+
+        ###### Definition
+
+        In short, the technique of connecting two data elements together. In the context of [KERI](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-infrastructure.md) it's the association of data or an [identifier](https://weboftrust.github.io/keridoc/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**.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [biometric](#h.grifxl8vyuuu)
+
+    -   ### ToIP
+
+        A measurable physical characteristic or personal behavioral trait used to recognize the [identity](#h.z1gairv0pej5), or verify the [claimed](#h.akieli6njkk5) [identity](#h.z1gairv0pej5), of an applicant. Facial images, fingerprints, and iris scan samples are all examples of biometrics.
+
+        Source: [NIST](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/biometric&sa=D&source=editors&ust=1718703186592701&usg=AOvVaw2eYT1YOC0_pmawPFfkLuE3)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [bis](#bis)
+
+    -   ### WebOfTrust
+
+        # bis
+
+        ###### Definition
+
+        bis = backed vc issue, registry-backed transaction event log credential issuance
+
+        [Learn more](https://kerisse.org)
+
+-   ## [bivalent](#bivalent)
+
+    -   ### WebOfTrust
+
+        # bivalent
+
+        ###### Definition
+
+        A nested set of layered delegations in a [delegation](https://weboftrust.github.io/keridoc/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.
+
+        ![bivalent-key-management-infrastructure](https://github.com/weboftrust/WOT-terms/static/img/bivalent-key-management-infrastructure.png)
+
+        To elaborate, in a [cooperative delegation](https://weboftrust.github.io/keridoc/docs/glossary/cooperative-delegation.md), the key generation and storage functions of the delegator and delegate, in terms of the 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
+
+        ###### Also see
+
+        [Multivalent](https://weboftrust.github.io/keridoc/docs/glossary/multi-valent.md)[Univalent](https://weboftrust.github.io/keridoc/docs/glossary/univalent.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [blake3](#blake3)
+
+    -   ### WebOfTrust
+
+        # blake3
+
+        ###### Definition
+
+        BLAKE3 is a relatively young (2020) cryptographic hash function based on Bao and BLAKE2.
+
+        ###### Features and programming languages
+
+        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).
+
+        ###### Fast, parallel and streaming
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [blind oobi](#blind-oobi)
+
+    -   ### WebOfTrust
+
+        # blind oobi
+
+        ###### Definition
+
+        A blind [OOBI](https://weboftrust.github.io/keridoc/docs/glossary/OOBI.md) means that you have some mechanisms in place for verifying the [AID](https://weboftrust.github.io/keridoc/docs/glossary/AID.md) instead of via the OOBI itself. A blind OOBI is essentially a [URL](https://weboftrust.github.io/keridoc/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.
+
+        ###### Example
+
+        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/keridoc/docs/glossary/KEL.md) out there, which has been securely established, you can trust it. So a blind OOBI makes a via-via commitment.
+
+        ###### The working
+
+        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."
+
+        ###### Unblind
+
+        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.
+
+        ###### Why is a blind OOBI interesting
+
+        type 2 authentication: minimise the friction| TBW prio 3 |
+
+        ###### Related terms
+
+        Authentication by reference, latent authenticity
+
+        [Learn more](https://kerisse.org)
+
+-   ## [blinded revocation registry](#blinded-revocation-registry)
+
+    -   ### WebOfTrust
+
+        # blinded revocation registry
+
+        ###### Definition
+
+        The current state of a [transaction event log](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/rainbow-table-attack.md) because the hash has enough [entropy](https://weboftrust.github.io/keridoc/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)
+
+        ###### Important observation
+
+        The presenter does the decomposition in a way that allows a verifier to conclude: "Yes that was an approved schema issued by the issuer!"
+
+        [Learn more](https://kerisse.org)
+
+-   ## [blockchain](#h.bxz57auzxstx)
+
+    -   ### ToIP
+
+        A [distributed digital ledger](#h.eoh04mpatko3) of cryptographically-signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one (making it tamper evident) after [validation](#h.rbp41an0omv6) and undergoing a consensus decision. As new blocks are added, older blocks become more difficult to modify (creating [tamper resistance](#h.hpl12if94wa6)). New blocks are replicated across copies of the ledger within the network, and any conflicts are resolved automatically using established rules.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/blockchain&sa=D&source=editors&ust=1718703186593146&usg=AOvVaw14aaKdKV1SIFOAIIfyroJV)
+
+        Supporting definitions:
+
+        [Wikipedia:](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Blockchain&sa=D&source=editors&ust=1718703186593440&usg=AOvVaw1tu4bB1HV_2AKLC6MwNYM-) A [distributed ledger](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Distributed_ledger&sa=D&source=editors&ust=1718703186593587&usg=AOvVaw1oDytPyrpBRIntEu_7uwyo) with growing lists of [records](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Record_\(computer_science\)&sa=D&source=editors&ust=1718703186593740&usg=AOvVaw2f0K_rlHaS7xBZExpy6THK) (blocks) that are securely linked together via [cryptographic hashes](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Cryptographic_hash_function&sa=D&source=editors&ust=1718703186593885&usg=AOvVaw0Ya70gDrQtHy79owcgA1gO). Each block contains a cryptographic hash of the previous block, a [timestamp](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Trusted_timestamping&sa=D&source=editors&ust=1718703186594044&usg=AOvVaw35zctcldPDIbNIFcK3K9D1), and transaction data (generally represented as a [Merkle tree](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Merkle_tree&sa=D&source=editors&ust=1718703186594182&usg=AOvVaw1vxopUk95qXMXln8yJltq8), where [data nodes](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Node_\(computer_science\)&sa=D&source=editors&ust=1718703186594323&usg=AOvVaw14HvA36v2NMVPnfVtGj0Ih) are represented by leaves). Since each block contains information about the previous block, they effectively form a chain (compare [linked list](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Linked_list&sa=D&source=editors&ust=1718703186594472&usg=AOvVaw0re8R1iojwYvWERpByhccK) data structure), with each additional block linking to the ones before it. Consequently, blockchain transactions are irreversible in that, once they are recorded, the data in any given block cannot be altered retroactively without altering all subsequent blocks.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [bran](#bran)
+
+    -   ### WebOfTrust
+
+        # bran
+
+        ###### Definition
+
+        A cryptographic string used as a primary input, a seed, for creating key material for and [autonomic-identifier](https://weboftrust.github.io/keridoc/docs/glossary/autonomic-identifier.md).
+
+        ###### Usages
+
+        This is used in Signify TS:
+
+        -   `Controller` [constructor argument](https://github.com/WebOfTrust/signify-ts/blob/516539f8bb68c8504e10221bf144a54b8c507dc3/src/keri/app/controller.ts#L104C77-L104C89)
+            ```javascript
+            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 })...
+            ```
+
+
+        ###### Sources
+
+        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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [branch](#branch)
+
+    -   ### WebOfTrust
+
+        # branch
+
+        ###### Definition
+
+        In software development a 'branch' refers to the result of branching: the duplication of an object under version control for further separate modification.
+
+        ###### More info on Wikipedia
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [broadcast](#h.s1uti8f9ufsv)
+
+    -   ### ToIP
+
+        In computer networking, telecommunication and information theory, broadcasting is a method of transferring a [message](#h.bge7ubygwk2q) to all recipients simultaneously. Broadcast delivers a message to all [nodes](#h.w1aty8c036fp) in the network using a one-to-all association; a single [datagram](#h.mxq90rincwo) (or [packet](#h.9hc1adgu2nrx)) from one sender is routed to all of the possibly multiple endpoints associated with the [broadcast address](#h.7gok5zmnh6an). The network automatically replicates [datagrams](#h.mxq90rincwo) as needed to reach all the recipients within the scope of the broadcast, which is generally an entire network subnet.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Broadcasting_\(networking\)&sa=D&source=editors&ust=1718703186595471&usg=AOvVaw2WbVj4Els0QLJ84ZuVOOCg).
+
+        See also: [anycast](#h.adr8osyk2zcx), [multicast](#h.nopxfdr8qtr6), [unicast](#h.bqegn99wxkdi).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/broadcast&sa=D&source=editors&ust=1718703186595998&usg=AOvVaw1DOFmqtIyR5FrPD8PeESlc): Transmission to all devices in a network without any acknowledgment by the receivers.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [broadcast address](#h.7gok5zmnh6an)
+
+    -   ### ToIP
+
+        A broadcast address is a [network address](#h.v9gosdu5b7z5) used to transmit to all devices connected to a multiple-access [communications](#h.w02a6srdng3j) network. A [message](#h.bge7ubygwk2q) sent to a broadcast address may be received by all network-attached [hosts](#h.3f5tvermqc9k). In contrast, a [multicast address](#h.obmynoe7gkec) is used to address a specific group of devices, and a [unicast address](#h.2p49ftuui3ug) is used to address a single device. For network layer communications, a broadcast address may be a specific [IP address](#h.a8c3q7adyz7c).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Network_address&sa=D&source=editors&ust=1718703186596885&usg=AOvVaw3Bmq_tPzQ-KXOWpCJNJZoe).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [broken object level authorization](#broken-object-level-authorization)
+
+    -   ### WebOfTrust
+
+        # broken object level authorization
+
+        ###### Definition
+
+        Refers to [security](https://weboftrust.github.io/keridoc/docs/glossary/security.md) flaws where users can access data they shouldn't, due to inadequate permission checks on individual (sub)objects.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [brv](#brv)
+
+    -   ### WebOfTrust
+
+        # brv
+
+        ###### Definition
+
+        brv = backed vc revoke, registry-backed transaction event log credential revocation
+
+        [Learn more](https://kerisse.org)
+
+-   ## [byzantine agreement](#byzantine-agreement)
+
+    -   ### WebOfTrust
+
+        # byzantine agreement
+
+        ###### Definition
+
+        (non PoW) Byzantine Agreement is [Byzantine fault tolerance](https://weboftrust.github.io/keridoc/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).
+
+        ###### Stellar
+
+        [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
+        ```
+
+        [Learn more](https://kerisse.org)
+
+-   ## [byzantine fault tolerance](#byzantine-fault-tolerance)
+
+    -   ### WebOfTrust
+
+        # byzantine fault tolerance
+
+        ###### Definition
+
+        A Byzantine fault (also interactive consistency, source congruency, error avalanche, [Byzantine agreement](https://weboftrust.github.io/keridoc/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 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 to first 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.
+
+        ###### Consensus two third
+
+        A system has Byzantine Fault Tolerance (BFT) when it can keep functioning correctly as long as two-thirds of the network agree or reaches 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
+
+        ###### More on Wikipedia
+
+        -   [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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [certificate authority](#h.dm6pt5kg2uim)
+
+    -   ### ToIP
+
+        The entity in a [public key infrastructure](#h.mdxu5kpbdo4x) (PKI) that is responsible for issuing [public key certificates](#h.anf8g7aq0gk5) and exacting compliance to a PKI policy.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/certificate_authority&sa=D&source=editors&ust=1718703186598103&usg=AOvVaw2Zthh1-oJH-jBmn9ieIKdZ).
+
+        Also known as: [certification authority](#h.lubcv4tm2i7r).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Certificate_authority&sa=D&source=editors&ust=1718703186598432&usg=AOvVaw2929yQoKs4ZFLoXiXmLJJ5): In [cryptography](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Cryptography&sa=D&source=editors&ust=1718703186598602&usg=AOvVaw3ugxuJcrBgi3fyfnPgNZu_), a certificate authority or certification authority (CA) is an entity that stores, signs, and issues [digital certificates](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public_key_certificate&sa=D&source=editors&ust=1718703186598760&usg=AOvVaw237WzCaEnqhixqwMKJCwXt). A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.[\[1\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Certificate_authority%23cite_note-1&sa=D&source=editors&ust=1718703186599013&usg=AOvVaw1tIh3kyp4Wce2NsyL-tsJf) The format of these certificates is specified by the [X.509](https://www.google.com/url?q=https://en.wikipedia.org/wiki/X.509&sa=D&source=editors&ust=1718703186599186&usg=AOvVaw123XmjygU4cjwqIJQn41mF) or [EMV](https://www.google.com/url?q=https://en.wikipedia.org/wiki/EMV&sa=D&source=editors&ust=1718703186599332&usg=AOvVaw0F21XPmhhoB8Ezc07S1fDe) standard.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [certificate transparency](#certificate-transparency)
+
+    -   ### WebOfTrust
+
+        # certificate transparency
+
+        ###### Definition
+
+        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.
+
+        ###### 2011 Diginotar Attack
+
+        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 information
+
+        More on [certificate.transparency.dev](https://certificate.transparency.dev/) and [Wikipedia](https://en.wikipedia.org/wiki/Certificate_Transparency).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [certification (of a party)](#h.ytzysnyu57ec)
+
+    -   ### ToIP
+
+        A comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security [accreditation](#h.so5aazavq41d), to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security [requirements](#h.ajxlw8r3dvcc) for the system.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/certification&sa=D&source=editors&ust=1718703186600025&usg=AOvVaw3H6z_qy9K8uY3ausvbixCO).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [certification authority](#h.lubcv4tm2i7r)
+
+    -   ### ToIP
+
+        See: [certificate authority](#h.dm6pt5kg2uim).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [certification body](#h.noh9fchc9jx)
+
+    -   ### ToIP
+
+        A [legal entity](#h.5328bxxk02sb) that performs [certification](#h.ytzysnyu57ec).
+
+        For more information: [https://en.wikipedia.org/wiki/Professional\_certification](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Professional_certification&sa=D&source=editors&ust=1718703186600654&usg=AOvVaw2CxBOAUtu5vxbR3CsEyRW2) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cesr proof signatures](#cesr-proof-signatures)
+
+    -   ### WebOfTrust
+
+        # cesr proof signatures
+
+        ###### Definition
+
+        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.
+        (Philip Feairheller, IETF-cesr-proof)
+
+        ![](https://hackmd.io/_uploads/ByxcPBQT5.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [cesride](#cesride)
+
+    -   ### WebOfTrust
+
+        # cesride
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/diger.md)
+        -   [Verfer](https://weboftrust.github.io/keridoc/docs/glossary/verfer.md)
+        -   [Signer](https://weboftrust.github.io/keridoc/docs/glossary/signer.md)
+        -   [Siger](https://weboftrust.github.io/keridoc/docs/glossary/siger.md)
+        -   [Cigar](https://weboftrust.github.io/keridoc/docs/glossary/cigar.md)
+        -   [Salter](https://weboftrust.github.io/keridoc/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/keridoc/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
+
+        ###### Related
+
+        [Parside](https://weboftrust.github.io/keridoc/docs/glossary/parside.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [chain link confidentiality](#chain-link-confidentiality)
+
+    -   ### WebOfTrust
+
+        # chain link confidentiality
+
+        ###### Definition
+
+        Chains together a sequence of [Disclosees](https://weboftrust.github.io/keridoc/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/keridoc/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.
+
+        ###### Contrast
+
+        Disclosures via [Presentations Exchanges](https://weboftrust.github.io/keridoc/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/keridoc/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)
+
+        ###### Article Woodrow Hartzog
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [chain of custody](#chain-of-custody)
+
+    -   ### WebOfTrust
+
+        # chain of custody
+
+        ###### Definition
+
+        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).
+
+        ###### New technology shortens CoC
+
+        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))
+
+        [Learn more](https://kerisse.org)
+
+-   ## [chain of trust](#h.1acc0g28edqg)
+
+    -   ### ToIP
+
+        See: [trust chain](#h.xsqvwmepvctc).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [chained credentials](#h.wjc1hh3dzgc7)
+
+    -   ### ToIP
+
+        Two or more [credentials](#h.kcj6iw2vib1v) linked together to create a [trust chain](#h.xsqvwmepvctc) between the credentials that is [cryptographically verifiable](#h.422iwwfur12).
+
+        Note: [ACDCs](#h.8qlmnalwgxgy) are a type of [digital credential](#h.ddna9lucn4k6) that explicitly supports [chaining](#h.kgtwd73pdfae).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [chaining](#h.kgtwd73pdfae)
+
+    -   ### ToIP
+
+        See: [trust chain](#h.xsqvwmepvctc).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [challenge](#challenge)
+
+    -   ### digital.govt.nz
+
+        (verb) to order (a person) to halt and be identified or to give a password\[Source: Dictionary\]Additional note:Note 1: A challenger issues a challenge and a responder replies.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [channel](#h.rvovbroy25sx)
+
+    -   ### ToIP
+
+        See: [communication channel](#h.oc2pelzel246).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cigar](#cigar)
+
+    -   ### WebOfTrust
+
+        # cigar
+
+        ###### Definition
+
+        An **_un_**[indexed signature](https://weboftrust.github.io/keridoc/docs/glossary/indexed-signature.md).
+        [Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ciphertext](#h.9ripqbaz7egw)
+
+    -   ### ToIP
+
+        [Encrypted](#h.iyq318f2vg61) (enciphered) [data](#h.o783ayrrkc6g). The [confidential](#h.445sv27j3c2m) form of the [plaintext](#h.ylf3pqlex968) that is the output of the [encryption](#h.iyq318f2vg61) function.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/ciphertext&sa=D&source=editors&ust=1718703186602446&usg=AOvVaw0KwzRGO5BqHWmEijGfupsc).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [claim](#claim)
+
+    -   ### Nist
+
+        A true-false statement about the limitations on the values of an unambiguously defined property called the claims property; and limitations on the uncertainty of the propertys values falling within these limitations during the claims duration of applicability under stated conditions.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/claim)
+
+    -   ### ToIP
+
+        An assertion about a [subject](#h.voca6uuv1a4), typically expressed as an [attribute](#h.ky5nh3yri7ak) or [property](#h.c8vs1xa4uwn) of the [subject](#h.voca6uuv1a4). It is called a “claim” because the assertion is always made by some [party](#h.cn6bno48fomj), called the [issuer](#h.xyrplzbvtffq) of the claim, and the [validity](#h.rbp41an0omv6) of the claim must be judged by the [verifier](#h.xfewd7t01hu0). 
+
+        Supporting definitions:
+
+        [W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186603230&usg=AOvVaw19sqjo7N3V96ThNaPVibgF): An assertion made about a [subject](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-subjects&sa=D&source=editors&ust=1718703186603403&usg=AOvVaw1Ow97tXakwKWcSnuu9vs7C).
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Claims-based_identity&sa=D&source=editors&ust=1718703186603610&usg=AOvVaw3uK9PAUdOisDBGtq2G5al7): A claim is a statement that one subject, such as a person or organization, makes about itself or another subject. For example, the statement can be about a name, group, buying preference, ethnicity, privilege, association or capability.
+
+        Note: If the [issuer](#h.xyrplzbvtffq) of the claim is also the [subject](#h.voca6uuv1a4) of the claim, the claim is [self-asserted](#h.yg81kearf9rl).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # claim
+
+        ###### Definition
+
+        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)).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [clone](#clone)
+
+    -   ### WebOfTrust
+
+        # clone
+
+        ###### Definition
+
+        A copy of a system that is - and works exactly as the original
+
+        ###### More detail
+
+        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\))
+
+        [Learn more](https://kerisse.org)
+
+-   ## [cloud agent](#cloud-agent)
+
+    -   ### WebOfTrust
+
+        # cloud agent
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/agent.md).
+
+        ###### Cloud computing
+
+        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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [code table](#code-table)
+
+    -   ### WebOfTrust
+
+        # code table
+
+        ###### Definition
+
+        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)
+
+        ##### Example text code table from CESR
+
+        ![](https://hackmd.io/_uploads/H1LHEQDfj.png)
+
+        ###### CESR related
+
+        Multiple text and binary code tables exist to pre-pend characters before the respective stream parts to characterize ([self-framing](https://weboftrust.github.io/keridoc/docs/glossary/self-framing.md)) them or group them.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [code table selector](#code-table-selector)
+
+    -   ### WebOfTrust
+
+        # code table selector
+
+        ###### Definition
+
+        the first character in the text code of [CESR stream](https://weboftrust.github.io/keridoc/docs/glossary/composable-event-streaming-representation.md) that determines which [code table](https://weboftrust.github.io/keridoc/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.
+
+        ###### Selector code table
+
+        See row 1.![](https://hackmd.io/_uploads/H1LHEQDfj.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [cold start stream parsing](#cold-start-stream-parsing)
+
+    -   ### WebOfTrust
+
+        # cold start stream parsing
+
+        ###### Definition
+
+        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.
+
+        ###### re-synchronization
+
+        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)
+
+        ###### CESR related
+
+        Special CESR count codes support re-synchronization at each boundary between interleaved CESR and other serializations like JSON, CBOR, or MGPK.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [collective signature](#collective-signature)
+
+    -   ### WebOfTrust
+
+        # collective signature
+
+        ###### Definition
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [collision](#collision)
+
+    -   ### Nist
+
+        An event in which two different messages have the same message digest.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/collision)
+
+    -   ### WebOfTrust
+
+        # collision
+
+        ###### Definition
+
+        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).
+
+        ###### Naming collision
+
+        A circumstance where two or more identifiers in a given [namespace](https://weboftrust.github.io/keridoc/docs/glossary/namespace.md) or a given scope cannot be unambiguously resolved.
+        [Source Wikipedia](https://en.wikipedia.org/wiki/Naming_collision)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [communication](#h.w02a6srdng3j)
+
+    -   ### ToIP
+
+        The transmission of information.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Communication&sa=D&source=editors&ust=1718703186604647&usg=AOvVaw1XXR_sWpw9bILtYIFrqJlq).
+
+        See also: [ToIP communication](#h.mqkudtdvvqw9).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [communication channel](#h.oc2pelzel246)
+
+    -   ### ToIP
+
+        A communication channel refers either to a physical transmission medium such as a wire, or to a logical [connection](#h.thbpewq1px8x) over a multiplexed medium such as a radio channel in telecommunications and computer networking. A channel is used for information transfer of, for example, a digital bit stream, from one or several senders to one or several receivers.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Communication_channel&sa=D&source=editors&ust=1718703186606136&usg=AOvVaw3VVOtz0XGDiOkXbvIhUvcH).
+
+        See also: [ToIP channel](#h.rp39gncihzvx).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/communication-channel&sa=D&source=editors&ust=1718703186606503&usg=AOvVaw15ZOp3wBFdLvJKei2KRQog): a (digital or non-digital) means by which two [actors](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186606721&usg=AOvVaw1gQwpO-gZ2APlatjJRHQyW) can exchange messages with one another.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [communication endpoint](#h.qstkv072p5tx)
+
+    -   ### ToIP
+
+        A type of communication network node. It is an interface exposed by a communicating party or by a [communication channel](#h.oc2pelzel246). An example of the latter type of a communication endpoint is a publish-subscribe topic or a group in group communication systems.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Communication_endpoint&sa=D&source=editors&ust=1718703186605385&usg=AOvVaw1lu4Q8V6vRnZBV4-oyurs2).
+
+        See also: [ToIP endpoint](#h.e787fzjepk60).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [communication metadata](#h.jvfwgs8vd2rd)
+
+    -   ### ToIP
+
+        [Metadata](#h.t63bf0ssndfd) that describes the sender, receiver, [routing](#h.tbxetxt0mdlp), handling, or contents of a [communication](#h.w02a6srdng3j). Communication metadata is often observable even if the contents of the [communication](#h.w02a6srdng3j) are encrypted.
+
+        See also: [correlation privacy](#h.7a6p0irhnbh5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [communication session](#h.i82tgrmxy0d8)
+
+    -   ### ToIP
+
+        A finite period for which a [communication channel](#h.oc2pelzel246) is instantiated and maintained, during which certain [properties](#h.c8vs1xa4uwn) of that channel, such as authentication of the participants, are in effect. A session has a beginning, called the session initiation, and an ending, called the session termination.
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/session&sa=D&source=editors&ust=1718703186607621&usg=AOvVaw3RvPdFayjsRLfjCObaYEQ7): A persistent interaction between a subscriber and an end point, either a relying party or a Credential Service Provider. A session begins with an authentication event and ends with a session termination event. A session is bound by use of a session secret that the subscriber’s software (a browser, application, or operating system) can present to the relying party or the Credential Service Provider in lieu of the subscriber’s authentication credentials.
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Session_\(computer_science\)&sa=D&source=editors&ust=1718703186607859&usg=AOvVaw2ey_VfYWrB1dw6pYtu2K1V): In [computer science](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_science&sa=D&source=editors&ust=1718703186608028&usg=AOvVaw3HS7hL-cTpG0xUoWKV5SAC) and [networking](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_network&sa=D&source=editors&ust=1718703186608216&usg=AOvVaw2YKDeON_MZTnYU0CEd0czv) in particular, a session is a time-delimited two-way link, a practical (relatively high) layer in the [TCP/IP protocol](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_protocol_suite&sa=D&source=editors&ust=1718703186608399&usg=AOvVaw2XqVUG1KjKJpdMLJ4blb8G) enabling interactive expression and information exchange between two or more communication devices or ends – be they computers, [automated systems](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Automation&sa=D&source=editors&ust=1718703186608553&usg=AOvVaw0fOFBrTYzA9iu99aj8-Cwc), or live active users (see [login session](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Login_session&sa=D&source=editors&ust=1718703186608728&usg=AOvVaw3oHycynihFUzg9W5KD3RrN)). A session is established at a certain point in time, and then ‘torn down’ - brought to an end - at some later point. An established communication session may involve more than one message in each direction. A session is typically [stateful](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Stateful&sa=D&source=editors&ust=1718703186608897&usg=AOvVaw0_s4IqbtOR2FAfYZ6kJvyx), meaning that at least one of the communicating parties needs to hold current state information and save information about the session history to be able to communicate, as opposed to [stateless](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Stateless_server&sa=D&source=editors&ust=1718703186609052&usg=AOvVaw0ujlbIvp9JbkaehpRFIrAV) communication, where the communication consists of independent [requests](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Request-response&sa=D&source=editors&ust=1718703186609242&usg=AOvVaw0Snz-mdV9kN8ndGrZ0_ra3) with responses. An established session is the basic requirement to perform a [connection-oriented communication](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Connection-oriented_communication&sa=D&source=editors&ust=1718703186609412&usg=AOvVaw2i8Od65bRit6KyxqyNpgz3). A session also is the basic step to transmit in [connectionless communication](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Connectionless_communication&sa=D&source=editors&ust=1718703186609635&usg=AOvVaw2LpvVtlhA5xh-VAV6cj9w4) modes. However, any unidirectional transmission does not define a session.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [compact event streaming representation (CESR)](#compacteventstreamingrepresentation\(CESR\))
+
+    -   ### ToIP (DID:Webs)
+
+        An encoding format that enables round-trip text-binary conversion of concatenated cryptographic primitives and general data types, as defined by the CESR specification and CESR Proof Signature specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [compact variant](#compact-variant)
+
+    -   ### WebOfTrust
+
+        # compact variant
+
+        ###### Definition
+
+        Either a [most compact](https://weboftrust.github.io/keridoc/docs/glossary/most-compact.md) version of an ACDC or the [fully compact](https://weboftrust.github.io/keridoc/docs/glossary/fully-compact.md) version of an ACDC. An [Issuer](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/top-level-section.md) is either the [SAD](https://weboftrust.github.io/keridoc/docs/glossary/SAD.md) or the [SAID](https://weboftrust.github.io/keridoc/docs/glossary/SAID.md) of the SAD of the associated section.
+
+        ###### Relation
+
+        All the variants of an [ACDC](https://weboftrust.github.io/keridoc/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)
+
+        ###### Also see
+
+        [Fully (expanded)](https://weboftrust.github.io/keridoc/docs/glossary/fully-expanded.md) version of an ACDC
+        [Fully compact(ed)](https://weboftrust.github.io/keridoc/docs/glossary/fully-compact.md) version of an ACDC
+        [Most compact](https://weboftrust.github.io/keridoc/docs/glossary/most-compact.md) version of an ACDC.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [complementary integrity verification](#complementary-integrity-verification)
+
+    -   ### WebOfTrust
+
+        # complementary integrity verification
+
+        ###### Definition
+
+        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
+
+        ###### Complementary nature
+
+        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/keridoc/docs/glossary/key-event-log.md) that has been verified to its [root-of-trust](https://weboftrust.github.io/keridoc/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.
+
+        ###### See also
+
+        [integrity](https://weboftrust.github.io/keridoc/docs/glossary/integrity.md)
+        [verified integrity](https://weboftrust.github.io/keridoc/docs/glossary/verified-integrity.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [complex password](#h.ydm2hpca9zws)
+
+    -   ### ToIP
+
+        A [password](#h.5u3l7bhbpjno) that meets certain security requirements, such as minimum length, inclusion of different character types, non-repetition of characters, and so on.
+
+        Supporting definitions:
+
+        [Science Direct](https://www.google.com/url?q=https://www.sciencedirect.com/topics/computer-science/complex-password&sa=D&source=editors&ust=1718703186610218&usg=AOvVaw1OmcCJdBdTWSe3VvgtbY7m): According to Microsoft, complex passwords consist of at least seven characters, including three of the following four character types: uppercase letters, lowercase letters, numeric digits, and non-alphanumeric characters such as & $ \* and !
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [compliance](#h.r0iiayz1za1i)
+
+    -   ### ToIP
+
+        In the context of decentralized digital trust infrastructure, the extent to which a system, [actor](#h.gzdfngxkp0ip), or [party](#h.cn6bno48fomj) conforms to the requirements of a [governance framework](#h.2x05z0r097mn) or [trust framework](#h.2r5mn949idq) that pertains to that particular [entity](#h.5imtbzl1f4xo).
+
+        See also: [Governance, Risk Management, and Compliance](#h.qo8q5iquhh9u).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23compliance&sa=D&source=editors&ust=1718703186611117&usg=AOvVaw3E_CW9kQkyI74iCqQWRhdK): The state of realization of a set of conformance criteria or normative framework of a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186611320&usg=AOvVaw3mVpp8fbOy6UxOXjRLVbu6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [comply ~ance](#comply~ance)
+
+    -   ### digital.govt.nz
+
+        to act in accordance with rules, wishes, etc; be obedient (to)\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [composability](#composability)
+
+    -   ### WebOfTrust
+
+        # composability
+
+        ###### See
+
+        [Text binary concatenation composability](https://weboftrust.github.io/keridoc/docs/glossary/text-binary-concatenation-composability.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [composable](#composable)
+
+    -   ### WebOfTrust
+
+        # composable
+
+        ###### See
+
+        [Composability](https://weboftrust.github.io/keridoc/docs/glossary/composable.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [composable event streaming representation](#composable-event-streaming-representation)
+
+    -   ### WebOfTrust
+
+        # composable event streaming representation
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/composability.md) in both the textual and binary streaming domains. The primitives 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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [concatenation](#concatenation)
+
+    -   ### WebOfTrust
+
+        # 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)
+
+        ###### KERI related
+
+        In CESR Concatenation is an important property of CESR's [Composability](https://weboftrust.github.io/keridoc/docs/glossary/composability.md); it is associative and may be applied to any two [primitives](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/self-framing.md) property of the primitives enables de-concatenation.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [concept](#h.6hyxh4mxxbu2)
+
+    -   ### ToIP
+
+        An abstract idea that enables the classification of [entities](#h.5imtbzl1f4xo), i.e., a mental construct that enables an instance of a class of [entities](#h.5imtbzl1f4xo) to be distinguished from [entities](#h.5imtbzl1f4xo) that are not an instance of that class. A concept can be [identified](#h.u3bfehmj4ed3) with a [term](#h.ojn7uxdcaf7u).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23concept&sa=D&source=editors&ust=1718703186612000&usg=AOvVaw3irPtehydfd1GY4FF8Xr7G): the ideas/thoughts behind a classification of [entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186612167&usg=AOvVaw2k_GD_VA-RRQDheq1bE71A) (what makes [entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186612375&usg=AOvVaw3IhjMuDaYqmEJCli5DmH4B) in that class 'the same').
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Concept&sa=D&source=editors&ust=1718703186612593&usg=AOvVaw1atiwMVF0BBFFdORyydef-): A concept is defined as an [abstract](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Abstraction&sa=D&source=editors&ust=1718703186612779&usg=AOvVaw3_zXWuO4qE5Z5OJEa7qkW5) [idea](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Idea&sa=D&source=editors&ust=1718703186612933&usg=AOvVaw1dBorw6YrdbH8IpesFxQKI). It is understood to be a fundamental building block underlying principles, [thoughts](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Thought&sa=D&source=editors&ust=1718703186613074&usg=AOvVaw2Kxkuxi2IMbq36QMjBHCjQ) and [beliefs](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Belief&sa=D&source=editors&ust=1718703186613201&usg=AOvVaw3cD5gsKSu5ynk1Nkc9FlsK). Concepts play an important role in all aspects of [cognition](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Cognition&sa=D&source=editors&ust=1718703186613342&usg=AOvVaw0xBAfqtmMNpQiW-JKQ-dKD).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [concise binary object representation](#concise-binary-object-representation)
+
+    -   ### WebOfTrust
+
+        # concise binary object representation
+
+        ###### Definition
+
+        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).
+
+        ##### IETF specification
+
+        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)
+
+        ##### MessagePack
+
+        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)
+
+        ##### More on Wikipedia
+
+        [CBOR](https://en.wikipedia.org/wiki/CBOR)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [confidential computing](#h.w12e1nuzy65z)
+
+    -   ### ToIP
+
+        Hardware-enabled features that isolate and process [encrypted](#h.iyq318f2vg61) [data](#h.o783ayrrkc6g) in memory so that the [data](#h.o783ayrrkc6g) is at less risk of exposure and compromise from concurrent workloads or the underlying system and platform.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/confidential_computing&sa=D&source=editors&ust=1718703186613956&usg=AOvVaw2xb-kwlg1XViJuGscwhIuP).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Confidential_computing&sa=D&source=editors&ust=1718703186614184&usg=AOvVaw30BgMR8CCuvFL5IyFWkjg2): Confidential computing is a security and [privacy-enhancing computational technique](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Privacy-enhancing_technologies&sa=D&source=editors&ust=1718703186614347&usg=AOvVaw1g9rCiCuCjKYXXbRxt7MYd) focused on protecting [data in use](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data_in_use&sa=D&source=editors&ust=1718703186614484&usg=AOvVaw33xJjaY-5gCe9VK510fsrw). Confidential computing can be used in conjunction with storage and network encryption, which protect [data at rest](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data_at_rest&sa=D&source=editors&ust=1718703186614770&usg=AOvVaw1fbAXPbtxTlQliRtPgOgKa) and [data in transit](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data_in_transit&sa=D&source=editors&ust=1718703186614952&usg=AOvVaw1HIFV1QGNkirs_hJhuRrET) respectively. It is designed to address software, protocol, cryptographic, and basic physical and supply-chain attacks, although some critics have demonstrated architectural and [side-channel attacks](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Side-channel_attack&sa=D&source=editors&ust=1718703186615128&usg=AOvVaw0Dm_mb18NcgPzi-CK-eJtq) effective against the technology.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [confidentiality](#h.445sv27j3c2m)
+
+    -   ### ToIP
+
+        In a [communications](#h.w02a6srdng3j) context, a type of privacy protection in which [messages](#h.bge7ubygwk2q) use [encryption](#h.iyq318f2vg61) or other privacy-preserving technologies so that only [authorized](#h.576ssfpt348i) [parties](#h.cn6bno48fomj) have access.
+
+        See also: [authenticity](#h.pitlm5jn3v6u), [correlation privacy](#h.7a6p0irhnbh5).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/confidentiality&sa=D&source=editors&ust=1718703186615901&usg=AOvVaw2FfQ9y-tIBLV1mo5wqcbEy): Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Confidentiality&sa=D&source=editors&ust=1718703186616095&usg=AOvVaw1PoHEbxMjsPHS7kazW--Gk): Confidentiality involves a set of rules or a promise usually executed through [confidentiality agreements](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Confidentiality_agreements&sa=D&source=editors&ust=1718703186616278&usg=AOvVaw20jGSVNN0UD55jb5hKAF0d) that limits the access or places restrictions on certain types of [information](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Information&sa=D&source=editors&ust=1718703186616456&usg=AOvVaw107moUB5Qyc4xPxTHOFJ95).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # confidentiality
+
+        ###### Definition
+
+        All statements in a conversation are only known by the parties to that conversation. Source: Samuel Smith, at IIW-37, Oct 2023.
+
+        Confidentiality involves a set of rules or a promise usually executed through [confidentiality agreements](https://en.wikipedia.org/wiki/Confidentiality_agreements) that limits the access or places restrictions on certain types of information.
+        More on source [Wikipedia](https://en.wikipedia.org/wiki/Confidentiality)
+
+        ###### KERI related
+
+        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.
+
+        ###### Also see
+
+        -   [authenticity](https://weboftrust.github.io/keridoc/docs/glossary/authenticity.md)
+        -   [privacy](https://weboftrust.github.io/keridoc/docs/glossary/privacy.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [configuration files](#configuration-files)
+
+    -   ### WebOfTrust
+
+        # configuration files
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [connection](#h.thbpewq1px8x)
+
+    -   ### ToIP
+
+        A [communication channel](#h.oc2pelzel246) established between two [communication endpoints](#h.qstkv072p5tx). A connection may be [ephemeral](#h.5xjtv29e8z6i) or [persistent](#h.ccf1vkxvhh1l).
+
+        See also: [ToIP connection](#h.5i1yn2scvzvz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [consensus mechanism](#consensus-mechanism)
+
+    -   ### WebOfTrust
+
+        # consensus mechanism
+
+        ###### Definition
+
+        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.
+
+        ###### Overall reliability
+
+        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 information
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [consent management](#h.wvxqsesvez2w)
+
+    -   ### ToIP
+
+        A system, process or set of policies under which a [person](#h.yx4qb6dcjdvj) agrees to share [personal data](#h.rpiib2ml3s9c) for specific usages. A consent management system will typically create a [record](#h.y4ybzkfe6yzv) of such consent.
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Consent_management&sa=D&source=editors&ust=1718703186619770&usg=AOvVaw1F_DY8OBhGPKbdiP0ff33W): Consent management is a system, process or set of policies for allowing consumers and patients to determine what health information they are willing to permit their various care providers to access. It enables patients and consumers to affirm their participation in e-health initiatives and to establish consent directives to determine who will have access to their protected health information (PHI), for what purpose and under what circumstances. Consent management supports the dynamic creation, management and enforcement of consumer, organizational and jurisdictional privacy policies.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [consequence](#consequence)
+
+    -   ### digital.govt.nz
+
+        outcome of an event affecting objectives\[Source: ISO 31073:2022\]Additional notes:Note 1: A consequence can have positive or negative, direct or indirect, effects on objectives.Note 2: Consequences can be expressed qualitatively or quantitatively.Note 3: Any consequences can escalate through cascading and cumulative effects.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [content addressable hash](#content-addressable-hash)
+
+    -   ### WebOfTrust
+
+        # content addressable hash
+
+        ###### Definition
+
+        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
+
+        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_.
+
+        ###### IPFS
+
+        In the IPFS ecosystem, this hash is called Content Identifier, or CID.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [context](#context)
+
+    -   ### digital.govt.nz
+
+        environment with defined boundary conditions in which entities exist and interact\[Source: ITU-T X.1252\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [contextual linkability](#contextual-linkability)
+
+    -   ### WebOfTrust
+
+        # contextual linkability
+
+        ###### Definition
+
+        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 through zero knowledge proofs 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/keridoc/docs/glossary/contractually-protected-disclosure.md) is the primary defense against contextual linkability.
+
+        ###### Example
+
+        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.
+
+        ###### Dangers
+
+        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/)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [contiguous](#contiguous)
+
+    -   ### digital.govt.nz
+
+        immediately preceding or following in time\[Source: Dictionary modified by adding immediately\]Additional note:Note 1: When applied to authentication, multiple factors are tested in such adjacent steps, that they are considered part of a single process.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [contingent disclosure](#contingent-disclosure)
+
+    -   ### WebOfTrust
+
+        # contingent disclosure
+
+        ###### Definition
+
+        [Chain link confidentiality](https://weboftrust.github.io/keridoc/docs/glossary/chain-link-confidentiality.md) is a form of contingent disclosure.
+
+        | TBW prio 1 |
+
+        [Learn more](https://kerisse.org)
+
+-   ## [contractually protected disclosure](#contractually-protected-disclosure)
+
+    -   ### WebOfTrust
+
+        # contractually protected disclosure
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/IPEX.md). Contractually protected disclosure includes both [chain-link confidential](https://weboftrust.github.io/keridoc/docs/glossary/chain-link-confidentiality.md) and [contingent disclosure](https://weboftrust.github.io/keridoc/docs/glossary/contingent-disclosure.md).
+        Paraphrased by @henkvancann based on [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#discussion)
+
+        ###### Relation
+
+        This [IPEX](https://weboftrust.github.io/keridoc/docs/glossary/IPEX.md) protocol leverages important features of [ACDC](https://weboftrust.github.io/keridoc/docs/glossary/ACDC.md)s and ancillary protocols such as [CESR](https://weboftrust.github.io/keridoc/docs/glossary/CESR.md), [SAID](https://weboftrust.github.io/keridoc/docs/glossary/SAID.md)s, and [CESR-Proofs](https://weboftrust.github.io/keridoc/docs/glossary/cesr-proof-signatures.md) as well as [Ricardian contract](https://weboftrust.github.io/keridoc/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/keridoc/docs/dictionary/chain-link confidential.md) and \[contingent disclosure\](https://weboftrust.github.io/keridoc/docs/dictionary/contingent disclosure.md).
+
+        ###### Rule
+
+        The disclosure performed by a presentation exchange MAY be [graduated](https://weboftrust.github.io/keridoc/docs/glossary/graduated-disclosure.md) and MAY be [contractually](https://weboftrust.github.io/keridoc/docs/glossary/contractually-protected-disclosure.md) protected.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [control](#control)
+
+    -   ### digital.govt.nz
+
+        (verb) to command, direct, or rule\[Source: Dictionary\]Additional note:Note 1: Control is also used outside the context of risk mitigation. For example, to indicate the ability for an authenticator holder to retain use of their authenticator.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [control authority](#control-authority)
+
+    -   ### WebOfTrust
+
+        # control authority
+
+        ###### Definition
+
+        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**.
+
+        ###### Source of truth
+
+        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.
+
+        ###### Change control authority
+
+        In the 2022 implementation of [KeriPy](https://weboftrust.github.io/keridoc/docs/glossary/keripy.md) two [rotations](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/docs/glossary/dual-indexed-codes.md) in CESR.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [controlled document](#h.t0afqk7h7n97)
+
+    -   ### ToIP
+
+        A [governance document](#h.c8fvvxachz5h) whose authority is derived from a primary document.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [controller](#controller)
+
+    -   ### ToIP (DID:Webs)
+
+        A controlling entity that can cryptographically prove the control authority (signing and rotation) over an AID as well as make changes on the associated KEL. A controller may consist of multiple controlling entities in a multi-signature scheme. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # controller
+
+        ###### Definition
+
+        A controller is a controlling entity (person, organization, or autonomous software) of an identifier. For an [autonomic identifier (AID)](https://weboftrust.github.io/keridoc/docs/glossary/autonomic-identifier.md), a controlling entity has the capability to make changes to the [key event log (KEL)](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/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/keridoc/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/keridoc/docs/glossary/delegated-identifier.md), the delegated identifier is granted some degree of control authority from its delegating identifier.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [controller (of a key, vault, wallet, agent, or device)](#h.gemoqe2m303z)
+
+    -   ### ToIP
+
+        In the context of digital [communications](#h.w02a6srdng3j), the [entity](#h.5imtbzl1f4xo) in control of sending and receiving digital [communications](#h.w02a6srdng3j). In the context of decentralized digital trust infrastructure, the [entity](#h.5imtbzl1f4xo) in control of the [cryptographic keys](#h.53rzpn1yn6q7) necessary to perform [cryptographically verifiable](#h.422iwwfur12) [actions](#h.l54nzmooy631) using a [digital agent](#h.z3ugzt4hgdf6) and [digital wallet](#h.sxnvf3f5v156). In a ToIP context, the [entity](#h.5imtbzl1f4xo) in control of a [ToIP endpoint](#h.e787fzjepk60).
+
+        See also: [device controller](#h.tf0m8u61wh87), [DID controller](#h.4yr00jpenf4z), [ToIP controller](#h.x1z2vxghptdm).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23controller&sa=D&source=editors&ust=1718703186618764&usg=AOvVaw2GAYo9fRsbw5ey5ZnG7gJp): the role that an [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186618940&usg=AOvVaw3vsMZ2je8q0ZcRad1zMhed) performs as it is executing actions on that [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186619092&usg=AOvVaw0rPUebWNfbMv5uCJ76yssH) for the purpose of ensuring that the [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186619237&usg=AOvVaw0QjFe8DV9aQTsfXMCzdXIz) will act/behave, or be used, in a particular way.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cooperative delegation](#cooperative-delegation)
+
+    -   ### WebOfTrust
+
+        # cooperative delegation
+
+        ###### Definition
+
+        The way KERI addresses the [security-cost-performance architecture trade-off](https://weboftrust.github.io/keridoc/docs/glossary/security-cost-performance-architecture-trade-off.md) is via [delegation](https://weboftrust.github.io/keridoc/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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [coroutines](#coroutines)
+
+    -   ### WebOfTrust
+
+        # coroutines
+
+        ###### Definition
+
+        Computer programs that can be suspended and resumed at will.
+
+        ###### What is a coroutine exactly?
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [correlate~ion](#correlate~ion)
+
+    -   ### digital.govt.nz
+
+        to place or be placed in a mutual, complementary, or reciprocal relationship\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [correlation](#correlation)
+
+    -   ### WebOfTrust
+
+        # correlation
+
+        ###### Definition
+
+        In our scope this is an identifier used to indicate that external parties have observed how wallet contents are related.
+
+        ###### Example
+
+        When a public key is reused, it conveys that some common entity is controlling both identifiers. Tracking correlation allows for software to warn when some new information might be about to be exposed, for example: "Looks like you are about to send cryptocurrency, from an account you frequently use to a new account you just created."
+
+        [Learn more](https://kerisse.org)
+
+-   ## [correlation privacy](#h.7a6p0irhnbh5)
+
+    -   ### ToIP
+
+        In a [communications](#h.w02a6srdng3j) context, a type of privacy protection in which [messages](#h.bge7ubygwk2q) use [encryption](#h.iyq318f2vg61), [hashes](#h.otz98gjrt2s), or other privacy-preserving technologies to avoid the use of [identifiers](#h.u3bfehmj4ed3) or other content that [unauthorized](#h.576ssfpt348i) [parties](#h.cn6bno48fomj) may use to correlate the sender and/or receiver(s).
+
+        See also: [authenticity](#h.pitlm5jn3v6u), [confidentiality](#h.445sv27j3c2m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [corroborate~ing](#corroborate~ing)
+
+    -   ### digital.govt.nz
+
+        to confirm or support (facts, opinions, etc), esp by providing fresh evidence\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [count code](#count-code)
+
+    -   ### WebOfTrust
+
+        # count code
+
+        ###### See
+
+        [Group framing code](https://weboftrust.github.io/keridoc/docs/glossary/group-framing-code.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [counterparty](#h.4cqjkp626h88)
+
+    -   ### ToIP
+
+        From the perspective of one [party](#h.cn6bno48fomj), the other [party](#h.cn6bno48fomj) in a [transaction](#h.92pu88ke4p7k), such as a financial transaction.
+
+        See also: [first party](#h.uxx5bjam20ag), [second party](#h.hk94wskqnzri), [third party](#h.zu2vj8151tr).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Counterparty&sa=D&source=editors&ust=1718703186621117&usg=AOvVaw2jWRCvbkMnZaFHnRJ0qPB7): A counterparty (sometimes contraparty) is a [legal entity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Juristic_person&sa=D&source=editors&ust=1718703186621328&usg=AOvVaw3SVOcAXR2zYlSGBdgxQm4u), [unincorporated entity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Unincorporated_entity&sa=D&source=editors&ust=1718703186621509&usg=AOvVaw0Rh9Wp-RE1KukBCeh4p9WP), or collection of entities to which an exposure of [financial risk](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Financial_risk&sa=D&source=editors&ust=1718703186621722&usg=AOvVaw20JtoaXHMZCRjYOSTMVnce) may exist.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [credential](#credential)
+
+    -   ### digital.govt.nz
+
+        an artefact created as the result of a series of processes that bind an entity with information and an authenticator, on which other parties relyAdditional note:Note 1: At a minimum a credential includes an authenticator and information to enable presentation.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### Nist
+
+        Evidence attesting to ones right to credit or authority. In this Standard, it is the PIV Card or derived PIV credential associated with an individual that authoritatively binds an identity (and, optionally, additional attributes) to that individual.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/credential)
+
+    -   ### ToIP
+
+        A container of [claims](#h.akieli6njkk5) describing one or more [subjects](#h.voca6uuv1a4). A credential is generated by the [issuer](#h.xyrplzbvtffq) of the credential and given to the [holder](#h.64mptmm24w7u) of the credential. A credential typically includes a signature or some other means of proving its [authenticity](#h.pitlm5jn3v6u). A credential may be either a [physical credential](#h.xnlz1vfx60mn) or a [digital credential](#h.ddna9lucn4k6).
+
+        See also: [verifiable credential](#h.co5algna3zkh).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186622446&usg=AOvVaw0KHeLhBIsRiObGHGgaED19): data, representing a set of [assertions](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/assertion&sa=D&source=editors&ust=1718703186622607&usg=AOvVaw0saxIsXZ_RrXFW9hDuTT7Q) (claims, statements), authored and signed by, or on behalf of, a specific [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186622758&usg=AOvVaw10_m6Rq6lTo5yyqYPNO_Qe).
+
+        [W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186622975&usg=AOvVaw2J9XD_8aUQIAFCiRJmGRZZ): A set of one or more [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186623155&usg=AOvVaw32hUWVhy1KyZgWoOyYzaIl) made by an [issuer](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-issuers&sa=D&source=editors&ust=1718703186623345&usg=AOvVaw0eNKMi75ILGrTyFxvRlCo_).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # credential
+
+        ###### Definition
+
+        Evidence of authority, status, rights, entitlement to privileges, or the like.
+        ([source](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#introduction))
+        A credential has its current state and a history, which is captured in a doc or a graph.
+
+        ###### ACDC specific
+
+        The credential is the whole graph.
+        The pointers in the doc that contain the whole graph are universally globally distributable references via the SAIDs. Whereas in other credential systems pointers are only local in a credential doc.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [credential family](#h.z0q6zr8y239c)
+
+    -   ### ToIP
+
+        A set of related [digital credentials](#h.ddna9lucn4k6) defined by a [governing body](#h.1wptecwzvuvz) (typically in a [governance framework](#h.2x05z0r097mn)) to empower [transitive trust decisions](#h.syc9o7x61rkm) among the participants in a [digital trust ecosystem](#h.h47f86smlz4y).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [credential governance framework](#h.tlmucrcg1d6g)
+
+    -   ### ToIP
+
+        A [governance framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2x05z0r097mn&sa=D&source=editors&ust=1718703186624047&usg=AOvVaw3ZK6MUQtg-ht_dWXLUXpSm) for a [credential family](#h.z0q6zr8y239c). A credential governance framework may be included within or referenced by an [ecosystem governance framework](#h.dkge5gglsmk3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [credential offer](#h.wahkjodu4pg1)
+
+    -   ### ToIP
+
+        A protocol request invoked by an [issuer](#h.xyrplzbvtffq) to offer to [issue](#h.zfdojht594xv) a [digital credential](#h.ddna9lucn4k6) to the  [holder](#h.64mptmm24w7u) of a [digital wallet](#h.sxnvf3f5v156). If the request is invoked by the [holder](#h.64mptmm24w7u), it is called an [issuance request](#h.tt253lgfp4hz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [credential provider](#credentialprovider)
+
+    -   ### digital.govt.nz
+
+        the party accountable for the establishment and presentation facilitation of a credentialAdditional note:Note 1: A Credential Provider may employ other parties in the carrying out of their function.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [credential request](#h.4gqimi7x8ecp)
+
+    -   ### ToIP
+
+        See: [issuance request](#h.tt253lgfp4hz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [credential schema](#h.ssow89h7w4eq)
+
+    -   ### ToIP
+
+        A [data schema](#h.nia930avy74i) describing the structure of a [digital credential](#h.ddna9lucn4k6). The [W3C Verifiable Credentials Data Model Specification](#h.mitd3elf05tf) defines a set of requirements for credential schemas.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [criterion](#h.1db3bhbgm7ba)
+
+    -   ### ToIP
+
+        In the context of [terminology](#h.189fachpwy1a), a written description of a [concept](#h.6hyxh4mxxbu2) that anyone can evaluate to determine whether or not an [entity](#h.5imtbzl1f4xo) is an instance or example of that [concept](#h.6hyxh4mxxbu2). Evaluation leads to a yes/no result.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [crypto libraries](#crypto-libraries)
+
+    -   ### WebOfTrust
+
+        # crypto libraries
+
+        ###### Definition
+
+        Cryptography libraries deal with cryptography algorithms and have API function calls to each of the supported features.
+
+        ###### Selection criteria
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [cryptocurrency](#cryptocurrency)
+
+    -   ### WebOfTrust
+
+        # cryptocurrency
+
+        ###### Definition
+
+        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 related
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [cryptographic binding](#h.kj56ogm6q6b3)
+
+    -   ### ToIP
+
+        Associating two or more related elements of information using cryptographic techniques.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/cryptographic_binding&sa=D&source=editors&ust=1718703186625944&usg=AOvVaw3ad3i2p7_q_xMIjNQoaZRL).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cryptographic commitment scheme](#cryptographic-commitment-scheme)
+
+    -   ### WebOfTrust
+
+        # cryptographic commitment scheme
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [cryptographic key](#h.53rzpn1yn6q7)
+
+    -   ### ToIP
+
+        A key in cryptography is a piece of information, usually a string of numbers or letters that are stored in a file, which, when processed through a cryptographic algorithm, can encode or decode cryptographic [data](#h.o783ayrrkc6g). Symmetric cryptography refers to the practice of the same [key](#h.53rzpn1yn6q7) being used for both [encryption](#h.iyq318f2vg61) and [decryption](#h.fuc05ut9lwmq). Asymmetric cryptography has separate [keys](#h.53rzpn1yn6q7) for [encrypting](#h.iyq318f2vg61) and [decrypting](#h.fuc05ut9lwmq). These keys are known as the [public keys](#h.hohpk6z1qk4f) and [private keys](#h.74y9dvxzg24c), respectively.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Key_\(cryptography\)&sa=D&source=editors&ust=1718703186627046&usg=AOvVaw2MbObh-xAld-jF2OnVTiNm).
+
+        See also: [controller](#h.gemoqe2m303z).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cryptographic primitive](#cryptographic-primitive)
+
+    -   ### WebOfTrust
+
+        # cryptographic primitive
+
+        ###### Definition
+
+        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)
+
+        ###### KERI related
+
+        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/keridoc/docs/glossary/composable-event-streaming-representation.md).
+
+        ###### See also
+
+        The more general term [primitive](https://weboftrust.github.io/keridoc/docs/glossary/primitive.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [cryptographic strength](#cryptographic-strength)
+
+    -   ### WebOfTrust
+
+        # cryptographic strength
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [cryptographic suite](#cryptographicsuite)
+
+    -   ### W3C (DID)
+
+        A specification defining the usage of specific cryptographic primitives inorder to achieve a particular security goal. These documents are often usedto specify verification methods, digital signature types,their identifiers, and other related properties.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [cryptographic trust](#h.uyr0uz94fhmu)
+
+    -   ### ToIP
+
+        A specialized type of [technical trust](#h.7vxscxecc0g) that is achieved using cryptographic algorithms.
+
+        Contrast with: [human trust](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.a4jfn38wd17o&sa=D&source=editors&ust=1718703186627701&usg=AOvVaw2BZh3ysUM_2qfeWecgRZin).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cryptographic verifiability](#h.lbqfpvfmcmoq)
+
+    -   ### ToIP
+
+        The [property](#h.c8vs1xa4uwn) of being [cryptographically verifiable](#h.422iwwfur12).
+
+        Contrast with: [human auditability](#h.g4qotp7yir9x).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cryptographically bound](#h.2vfuhxpyn3td)
+
+    -   ### ToIP
+
+        A state in which two or more elements of information have a [cryptographic binding](#h.kj56ogm6q6b3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cryptographically verifiable](#h.422iwwfur12)
+
+    -   ### ToIP
+
+        A property of a data structure that has been digitally signed using a [private key](#h.74y9dvxzg24c) such that the [digital signature](#h.s93np0i5rcne) can be verified using the [public key](#h.hohpk6z1qk4f). [Verifiable data](#h.7n80iyjxkofu), [verifiable messages](#h.7zrsx7mki2fr), [verifiable credentials](#h.co5algna3zkh), and [verifiable data registries](#h.q1dr1v2lltfe) are all cryptographically verifiable. Cryptographic verifiability is a primary goal of the [ToIP Technology Stack](#h.9looruc0w4ac).
+
+        Contrast with: [human auditable](#h.22bo41j3q290).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [cryptonym](#cryptonym)
+
+    -   ### WebOfTrust
+
+        # cryptonym
+
+        ###### Definition
+
+        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)
+
+        ###### KERI related
+
+        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/keridoc/docs/glossary/cryptographic-strength.md). A cryptonym is a type of primitive.
+        Due the [entropy](https://weboftrust.github.io/keridoc/docs/glossary/entropy.md) in its derivation, a cryptonym is a universally unique identifier and only the [controller](https://weboftrust.github.io/keridoc/docs/glossary/controller.md) of the secret [salt](https://weboftrust.github.io/keridoc/docs/glossary/salt.md) or [seed](https://weboftrust.github.io/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [custodial agent](#custodial-agent)
+
+    -   ### WebOfTrust
+
+        # custodial agent
+
+        ###### Definition
+
+        An [agent](https://weboftrust.github.io/keridoc/docs/glossary/agent.md) owned by an individual who has granted [signing authority](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/partial-rotation.md) to facilitate custodial key management the owner of the identifier retains [rotational authority](https://weboftrust.github.io/keridoc/docs/glossary/rotation-authority.md) and thus the ability to "fire" the custodian at any time without requiring the cooperation of the custodian.
+
+        ###### Importance
+
+        Custodial Agents are important for individuals who may not be comfortable managing their own [signing keys](https://weboftrust.github.io/keridoc/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)
+
+        ###### Key functionality
+
+        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/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [custodial rotation](#custodial-rotation)
+
+    -   ### WebOfTrust
+
+        # custodial rotation
+
+        ###### Definition
+
+        Rotation based on control authority that is split between two key sets. The first for signing authority and the second (pre-roateted) for rotation authority the associated thresholds and key list can be structured in such a way 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/keridoc/docs/glossary/partial-rotation.md) supports the important use case that of custodial key rotation to authorize a [custodial agent](https://weboftrust.github.io/keridoc/docs/glossary/custodial-agent.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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [custodial wallet](#h.5qanwm5930bp)
+
+    -   ### ToIP
+
+        A [digital wallet](#h.sxnvf3f5v156) that is directly in the custody of a [principal](#h.sydbe7rk6244), i.e., under the principal’s direct personal or organizational control. A [digital wallet](#h.sxnvf3f5v156) that is in the custody of a [third party](#h.zu2vj8151tr) is called a [non-custodial wallet](#h.ridlo7ub9haf).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [custodian](#h.8kx1mv7y64ps)
+
+    -   ### ToIP
+
+        A [third party](#h.zu2vj8151tr) that has been assigned rights and duties in a [custodianship arrangement](#h.4hh9dvbp6177) for the purpose of hosting and safeguarding a [principal’s](#h.sydbe7rk6244) [private keys](#h.74y9dvxzg24c), [digital wallet](#h.sxnvf3f5v156) and [digital assets](#h.emffux4xw3th) on the [principal’s](#h.sydbe7rk6244) behalf. Depending on the [custodianship](#h.4hh9dvbp6177) [arrangement](#h.4hh9dvbp6177), the custodian may act as an exchange and provide additional services, such as staking, lending, account recovery, or security features.
+
+        Contrast with: [guardian](#h.y3s9f56kpets), [zero-knowledge service provider](#h.qhfq42vp7l55).
+
+        See also: [custodial wallet](#h.5qanwm5930bp).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/custodian&sa=D&source=editors&ust=1718703186630760&usg=AOvVaw2oSYiig3FQbOSVLaorJ2dT): A third-party [entity](#h.5imtbzl1f4xo) that holds and safeguards a user’s [private keys](#h.74y9dvxzg24c) or digital assets on their behalf. Depending on the system, a custodian may act as an exchange and provide additional services, such as staking, lending, account recovery, or security features.
+
+        Note: While a custodian technically has the necessary access to in theory [impersonate](#h.rifdelabky9n) the [principal](#h.sydbe7rk6244), in most cases a custodian is expressly prohibited from taking any action on the [principal’s](#h.sydbe7rk6244) account unless explicitly [authorized](#h.gln5i78kxlfh) by the [principal](#h.sydbe7rk6244). This is what distinguishes custodianship from [guardianship](#h.y3s9f56kpets).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [custodianship arrangement](#h.4hh9dvbp6177)
+
+    -   ### ToIP
+
+        The informal terms or formal legal agreement under which a [custodian](#h.8kx1mv7y64ps) agrees to provide service to a [principal](#h.sydbe7rk6244).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [dark pattern](#h.u6zclym3wpbs)
+
+    -   ### ToIP
+
+        A design pattern, mainly in user interfaces, that has the effect of deceiving individuals into making choices that are advantageous to the designer.
+
+        Source: Kantara PEMC Implementors Guidance Report
+
+        Also known as: [deceptive pattern](#h.rxt5u3tqdfny).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [data](#h.o783ayrrkc6g)
+
+    -   ### ToIP
+
+        In the pursuit of [knowledge](#h.k96lktyswxnb), data is a collection of discrete values that convey information, describing quantity, quality, fact, statistics, other basic units of meaning, or simply sequences of symbols that may be further interpreted. A datum is an individual value in a collection of data.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data&sa=D&source=editors&ust=1718703186632423&usg=AOvVaw1Ft9yUMVjzF7xZjcFg74DP).
+
+        See also: [verifiable data](#h.7n80iyjxkofu).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23data&sa=D&source=editors&ust=1718703186632835&usg=AOvVaw0Mguik6I8QKPjWxfa8j7de): something (tangible) that can be used to communicate a meaning (which is intangible/information).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [data anchor](#data-anchor)
+
+    -   ### WebOfTrust
+
+        # data anchor
+
+        ###### Definition
+
+        Data anchors are [digests](https://weboftrust.github.io/keridoc/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.
+
+        ###### Anchoring data
+
+        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'.
+
+        ###### KERI related
+
+        [SADs](https://weboftrust.github.io/keridoc/docs/glossary/self-addressing-data.md) are a type of data anchors.
+
+        ###### Beware
+
+        [Link anchors](https://en.wikipedia.org/wiki/Hyperlink#Anchor_links) are a totally different concepts.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [data packet](#h.9hc1adgu2nrx)
+
+    -   ### ToIP
+
+        In telecommunications and computer networking, a network packet is a formatted unit of [data](#h.o783ayrrkc6g) carried by a packet-switched network such as the Internet. A packet consists of control information and user [data](#h.o783ayrrkc6g); the latter is also known as the payload. Control information provides data for delivering the payload (e.g., source and destination network addresses, error detection codes, or sequencing information). Typically, control information is found in packet headers and trailers.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Network_packet&sa=D&source=editors&ust=1718703186633666&usg=AOvVaw23BpfBClAhEQ2EUJB6U6US).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [data schema](#h.nia930avy74i)
+
+    -   ### ToIP
+
+        A description of the structure of a digital document or object, typically expressed in a [machine-readable](#h.8s3s84fzcfi3) language in terms of constraints on the structure and content of documents or objects of that type. A credential schema is a particular type of data schema.
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/XML_schema&sa=D&source=editors&ust=1718703186634158&usg=AOvVaw2cb8uHt_U1WT1ZRZcvQmT-): An XML schema is a description of a type of [XML](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Extensible_Markup_Language&sa=D&source=editors&ust=1718703186634343&usg=AOvVaw2XV29COXzSCr-D3mYHAuFK) document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself. These constraints are generally expressed using some combination of grammatical rules governing the order of elements, [Boolean predicates](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Boolean_predicates&sa=D&source=editors&ust=1718703186634516&usg=AOvVaw0HRa-_OeddpN3S1-pJOGp3) that the content must satisfy, data types governing the content of elements and attributes, and more specialized rules such as [uniqueness](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Uniqueness_quantification&sa=D&source=editors&ust=1718703186634678&usg=AOvVaw26vAk5skYnZG_L-D2caMRY) and [referential integrity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Referential_integrity&sa=D&source=editors&ust=1718703186634819&usg=AOvVaw2-_PXkbSYFKv1ROV3pWb1Y) constraints.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [data subject](#h.3r9gd9iy7a6e)
+
+    -   ### ToIP
+
+        The [natural person](#h.yx4qb6dcjdvj) that is described by [personal data](#h.rpiib2ml3s9c). Data subject is the term used by the EU [General Data Protection Regulation](#h.tks8sagp6iy0).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [data vault](#h.r86ltcrr5evr)
+
+    -   ### ToIP
+
+        See: [digital vault](#h.cz29glapo2tg).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [datagram](#h.mxq90rincwo)
+
+    -   ### ToIP
+
+        See: [data packet](#h.9hc1adgu2nrx).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [dead drop](#dead-drop)
+
+    -   ### WebOfTrust
+
+        # dead drop
+
+        ###### Definition
+
+        | TBW | the presenter controls the disclosure so you can't re-identify the data
+
+        Tech meet KERI [recording](https://hackmd.io/-soUScAqQEaSw5MJ71899w#2023-06-27) from minute 55, date June 29 2023.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [decentralized identifier](#h.x1jp59hgbk2l)
+
+    -   ### ToIP
+
+        A globally unique persistent [identifier](#h.u3bfehmj4ed3) that does not require a centralized [registration](#h.scqeh7q9ln83) [authority](#h.gln5i78kxlfh) and is often generated and/or registered cryptographically. The generic format of a DID is defined in section [3.1 DID Syntax](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23did-syntax&sa=D&source=editors&ust=1718703186635704&usg=AOvVaw12cGHZBrqgqP1Oz-F85DiR) of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.google.com/url?q=https://www.w3.org/TR/did-core/&sa=D&source=editors&ust=1718703186635864&usg=AOvVaw2lfTzZ31TSWUx-6t5L-0Ot) specification. A specific DID scheme is defined in a [DID method](#h.fuy2eub1xls) specification.
+
+        Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186636252&usg=AOvVaw2yDrxoekGFLhxf2XFSEZ-C).
+
+        Also known as: [DID](#h.zh539v9ul471).
+
+        See also: [DID method](#h.fuy2eub1xls), [DID URL](#h.2lqom8dcqvzy).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # decentralized identifier
+
+        ###### Definition
+
+        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.
+
+        ###### Relation to federated identifiers
+
+        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.
+
+        ###### Technical presence
+
+        _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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [decentralized identifier (DID)](#decentralizedidentifier\(DID\))
+
+    -   ### ToIP (DID:Webs)
+
+        A globally unique persistent identifier, as defined by DID Core.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### W3C (DID)
+
+        A globally unique persistent identifier that does not require a centralizedregistration authority and is often generated and/or registeredcryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DIDmethod specification. Manybut not allDID methods make use ofdistributed ledger technology (DLT) or some other form of decentralizednetwork.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [decentralized identity](#h.xodo7ytn4cx2)
+
+    -   ### ToIP
+
+        A [digital identity](#h.r5y8zwxvzyd3) architecture in which a [digital identity](#h.r5y8zwxvzyd3) is established via the control of a set of [cryptographic keys](#h.53rzpn1yn6q7) in a [digital wallet](#h.sxnvf3f5v156) so that the [controller](#h.gemoqe2m303z) is not dependent on any external [identity provider](#h.m9zmriuoidyt) or other [third party](#h.zu2vj8151tr).
+
+        See also: [federated identity](#h.cb1le64hx6h5), [self-sovereign identity](#h.wdojy63bltd4).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # decentralized identity
+
+        ###### Definition
+
+        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 need not cede control to centralized service providers or companies.
+
+        `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`.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [decentralized identity management](#decentralizedidentitymanagement)
+
+    -   ### W3C (DID)
+
+        Identitymanagement that is based on the use of decentralized identifiers.Decentralized identity management extends authority for identifier generation,registration, and assignment beyond traditional roots of trust such asX.500 directory services,the Domain Name System,and most national ID systems.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [decentralized key management infrastructure](#decentralized-key-management-infrastructure)
+
+    -   ### WebOfTrust
+
+        # decentralized key management infrastructure
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [deceptive pattern](#h.rxt5u3tqdfny)
+
+    -   ### ToIP
+
+        See: [dark pattern](#h.u6zclym3wpbs).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [decryption](#h.fuc05ut9lwmq)
+
+    -   ### ToIP
+
+        The process of changing [ciphertext](#h.9ripqbaz7egw) into [plaintext](#h.ylf3pqlex968) using a cryptographic algorithm and [key](#h.53rzpn1yn6q7). The opposite of [encryption](#h.iyq318f2vg61).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/decryption&sa=D&source=editors&ust=1718703186639696&usg=AOvVaw0Dd0ejgKOo7P9pyHCBZF7U).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [deep link](#h.ubxk9l39j7w)
+
+    -   ### ToIP
+
+        In the context of the World Wide Web, deep linking is the use of a hyperlink that links to a specific, generally searchable or indexed, piece of web content on a website (e.g. "https://example.com/path/page"), rather than the website's home page (e.g., "https://example.com"). The URL contains all the information needed to point to a particular item. Deep linking is different from [mobile deep linking](#h.le2xkm9qaw28), which refers to directly linking to in-app content using a non-HTTP URI.
+
+        See also: [out-of-band introduction](#h.tsslu4lnog0s).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Deep_linking&sa=D&source=editors&ust=1718703186640301&usg=AOvVaw2fl5jSPTiLAXFuq8kbODYI).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [definition](#h.beph188xy39q)
+
+    -   ### ToIP
+
+        A textual statement defining the meaning of a [term](#h.ojn7uxdcaf7u) by specifying [criterion](#h.1db3bhbgm7ba) that enable the [concept](#h.6hyxh4mxxbu2) identified by the [term](#h.ojn7uxdcaf7u) to be distinguished from all other [concepts](#h.6hyxh4mxxbu2) within the intended [scope](#h.5cfb6xokygh4).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23definition&sa=D&source=editors&ust=1718703186641149&usg=AOvVaw0ivqDDbpxRfX25ZHBP6xhx): a text that helps [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186641361&usg=AOvVaw3lOMT0dF1PiXJWzOE456lN) to have the same understanding about the meaning of (and [concept](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186641549&usg=AOvVaw3OsC8MiDBGgkbTqBE8Yh5g) behind) a [term](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186641721&usg=AOvVaw2NuGNseNEK90QRPuLZiH2y), ideally in such a way that these [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186641938&usg=AOvVaw0Dld6tmqqHfaAArxc4cfb-) can determine whether or not they make the same distinction.
+
+        Wikipedia: A definition is a statement of the meaning of a term (a [word](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Word&sa=D&source=editors&ust=1718703186642164&usg=AOvVaw3gP_6gYiqg6AiKsqbvNT5E), [phrase](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Phrase&sa=D&source=editors&ust=1718703186642311&usg=AOvVaw25x3KqFrhr7dnh4YousIkn), or other set of [symbols](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Symbol&sa=D&source=editors&ust=1718703186642445&usg=AOvVaw1FHLdYA6IFOU2VuEDIxz0f)). Definitions can be classified into two large categories: [intensional definitions](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Intensional_definition&sa=D&source=editors&ust=1718703186642594&usg=AOvVaw0zkQba6jhDkQouChTepErN) (which try to give the sense of a term), and [extensional definitions](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Extensional_definition&sa=D&source=editors&ust=1718703186642743&usg=AOvVaw2pC25ZoGKf6ES2zxlEFNpU) (which try to list the objects that a term describes). Another important category of definitions is the class of [ostensive definitions](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Ostensive_definition&sa=D&source=editors&ust=1718703186642889&usg=AOvVaw1QFV7bu7sc76qz-B8Y1NIM), which convey the meaning of a term by pointing out examples. A term may have many different senses and multiple meanings, and thus require multiple definitions.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [delegate](#delegate)
+
+    -   ### digital.govt.nz
+
+        (noun) a person chosen or elected to act for or represent another or others\[Source: Dictionary\]Additional note:Note 1: Modified to remove reference to conference or meeting.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [delegated identifier](#delegated-identifier)
+
+    -   ### WebOfTrust
+
+        # delegated identifier
+
+        ###### Definition
+
+        Matches the act of [delegation](https://weboftrust.github.io/keridoc/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)
+
+        ###### More KERI context
+
+        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/keridoc/docs/glossary/transferable-identifier.md)
+        -   [non-transferable identifiers](https://weboftrust.github.io/keridoc/docs/glossary/non-transferable-identifier.md)
+        -   delegated identifiers
+
+        [Learn more](https://kerisse.org)
+
+-   ## [delegate~ed](#delegate~ed)
+
+    -   ### digital.govt.nz
+
+        (verb) to give or commit (duties, powers, etc) to another as agent or representative; depute\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [delegation](#h.l7p0oyq4rvsz)
+
+    -   ### ToIP
+
+        TODO
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # delegation
+
+        ###### Definition
+
+        A person or group of persons officially elected or appointed to represent another or others.
+
+        ###### Assign tasks but stay in control
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [delegation credential](#h.pubtsqoyrab2)
+
+    -   ### ToIP
+
+        TODO
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [dependent](#h.qvhbv3ov9zmy)
+
+    -   ### ToIP
+
+        An [entity](#h.5imtbzl1f4xo) for the caring for and/or protecting/guarding/defending of which a [guardianship arrangement](#h.tc250ixnd67w) has been established with a [guardian](#h.y3s9f56kpets).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23dependent&sa=D&source=editors&ust=1718703186643621&usg=AOvVaw0GMTD9YGRXkr6EdRalhpHW)
+
+        See also: [custodian](#h.8kx1mv7y64ps).
+
+        Mental Model: [eSSIF-Lab Guardianship](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/pattern-guardianship&sa=D&source=editors&ust=1718703186643938&usg=AOvVaw3SXr6OskPXZg9H5uVtNAuP)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [derivation code](#derivation-code)
+
+    -   ### WebOfTrust
+
+        # derivation code
+
+        ###### Definition
+
+        To properly extract and use the [public key](https://weboftrust.github.io/keridoc/docs/glossary/public-key-infrastructure.md) embedded in a [self-certifying identifier](https://weboftrust.github.io/keridoc/docs/glossary/self-certifying-identifier.md) we need to know the cryptographic _signing scheme_ used by the [key pair](https://weboftrust.github.io/keridoc/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_.
+
+        ##### Example
+
+        > 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`
+
+        ##### Relation with KERI
+
+        All crypto material appears in `KERI` in a fully [qualified](https://weboftrust.github.io/keridoc/docs/glossary/qualified.md) representation. This includes a derivation code prepended to the crypto-material.![](https://github.com/WebOfTrust/keri/blob/main/images/derivation-code.png)
+
+        ###### Example KERI derivation codes
+
+        ![example derivation code in KERI](https://raw.githubusercontent.com/WebOfTrust/WOT-terms/main/static/img/derivation-code.png)
+
+        ###### Beware
+
+        [Key derivation functions](https://en.wikipedia.org/wiki/Key_derivation_function) are not related to the pre-pended derivation codes used in KERI.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [derived value](#derivedvalue)
+
+    -   ### digital.govt.nz
+
+        value obtained by reasoning; deduction or inference\[Source: expanded Dictionary meaning of derive\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [designated aliases](#designatedaliases)
+
+    -   ### ToIP (DID:Webs)
+
+        An array of AID controlled identifiers that have been designated by the AID controller to be used as aliases for equivalentId and alsoKnownAs DID document metadata and to foster verification of redirection to different did:webs identifiers. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # designated aliases
+
+        ###### Definition
+
+        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/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [designated authorized representative](#designated-authorized-representative)
+
+    -   ### WebOfTrust
+
+        # designated authorized representative
+
+        ###### Definition
+
+        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/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [device controller](#h.tf0m8u61wh87)
+
+    -   ### ToIP
+
+        The [controller](#h.gemoqe2m303z) of a device capable of digital [communications](#h.w02a6srdng3j), e.g., a smartphone, tablet, laptop, IoT device, etc.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [dictionary](#h.ajluzjr0e4sa)
+
+    -   ### ToIP
+
+        A dictionary is a listing of lexemes (words or [terms](#h.ojn7uxdcaf7u)) from the lexicon of one or more specific languages, often arranged alphabetically, which may include information on [definitions](#h.beph188xy39q), usage, etymologies, pronunciations, translation, etc. It is a lexicographical reference that shows inter-relationships among the [data](#h.o783ayrrkc6g). Unlike a [glossary](#h.z1he49173rzw), a dictionary may provide multiple [definitions](#h.beph188xy39q) of a [term](#h.ojn7uxdcaf7u) depending on its [scope](#h.5cfb6xokygh4) or context.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Dictionary&sa=D&source=editors&ust=1718703186645118&usg=AOvVaw3j_sHHgLJBDfHjDY_O4tSb).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [diger](#diger)
+
+    -   ### WebOfTrust
+
+        # diger
+
+        ###### Definition
+
+        A _primitive_ that represents a [digest](https://weboftrust.github.io/keridoc/docs/glossary/digest.md). It has the ability to [verify](https://weboftrust.github.io/keridoc/docs/glossary/verify.md) that an input hashes to its raw value.
+        [Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
+
+        [Learn more](https://kerisse.org)
+
+-   ## [digest](#digest)
+
+    -   ### WebOfTrust
+
+        # digest
+
+        ###### Definition
+
+        verifiable cryptographic commitment. It's a collision resistant hash of content.
+
+        From Wikipedia ([Source](https://en.wikipedia.org/wiki/Cryptographic_hash_function)):
+
+        A **digest** is a cryptographic hash function (CHF) is a mathematical [algorithm](https://en.wikipedia.org/wiki/Algorithm) that [maps](https://en.wikipedia.org/wiki/Map_\(mathematics\)) data of an arbitrary size (often called the "message") to a [bit array](https://en.wikipedia.org/wiki/Bit_array) of a fixed size (the "[hash value](https://en.wikipedia.org/wiki/Hash_value)", "hash", or "message digest"). It is a [one-way function](https://en.wikipedia.org/wiki/One-way_function), that is, a function for which it is practically infeasible to invert or reverse the computation.[\[1\]](https://en.wikipedia.org/wiki/Message_digest#cite_note-MrThfd-1)
+
+        ###### Digest and ACDCs
+
+        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. [Authentic Chained Data Containers (ACDCs)](https://weboftrust.github.io/keridoc/docs/glossary/authentic-chained-data-container.md) 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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [digital agent](#h.z3ugzt4hgdf6)
+
+    -   ### ToIP
+
+        In the context of ​​decentralized digital trust infrastructure, an [agent](#h.6xkhfkjpo6xg) (specifically a type of [software agent](#h.qv9e403ohhxe)) that operates in conjunction with a [digital wallet](#h.sxnvf3f5v156).
+
+        Note: In a ToIP context, a digital agent is frequently assumed to have privileged access to the [digital wallet](#h.sxnvf3f5v156)(s) of its principal. In market parlance, a mobile app that performs the [actions](#h.l54nzmooy631) of a digital agent is often simply called a [wallet](#h.mh27630t20d) or a [digital wallet](#h.sxnvf3f5v156).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital asset](#h.emffux4xw3th)
+
+    -   ### ToIP
+
+        A digital asset is anything that exists only in digital form and comes with a distinct usage right. [Data](#h.o783ayrrkc6g) that do not possess that right are not considered assets.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_asset&sa=D&source=editors&ust=1718703186650250&usg=AOvVaw25uMZiNUOb714myiHO_xs7).
+
+        See also: [digital credential](#h.ddna9lucn4k6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital certificate](#h.vpsiiv68xxwc)
+
+    -   ### ToIP
+
+        See: [public key certificate](#h.anf8g7aq0gk5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital credential](#h.ddna9lucn4k6)
+
+    -   ### ToIP
+
+        A [credential](#h.kcj6iw2vib1v) in digital form that is signed with a [digital signature](#h.s93np0i5rcne) and held in a [digital wallet](#h.sxnvf3f5v156). A digital credential is issued to a [holder](#h.64mptmm24w7u) by an [issuer](#h.xyrplzbvtffq); a [proof](#h.r2qw6757lopw) of the credential is [presented](#h.h5d1xfsxbbr0) by the [holder](#h.64mptmm24w7u) to a [verifier](#h.xfewd7t01hu0).
+
+        See also: [issuance request](#h.tt253lgfp4hz), [presentation request](#h.onnn49cjzreh), [verifiable credential](#h.co5algna3zkh).
+
+        Contrast with: [physical credential](#h.xnlz1vfx60mn).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_credential&sa=D&source=editors&ust=1718703186651879&usg=AOvVaw2TnU3thde7MSmOlVvfJRRS): Digital credentials are the digital equivalent of paper-based [credentials](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Credentials&sa=D&source=editors&ust=1718703186652129&usg=AOvVaw2gK2zwzOPrUoNc-nIbivgE). Just as a paper-based credential could be a [passport](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Passport&sa=D&source=editors&ust=1718703186652294&usg=AOvVaw1DHIT6qLt3xQZwncITQqL4), a [driver's license](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Driver%2527s_license&sa=D&source=editors&ust=1718703186652452&usg=AOvVaw2YGcWkDOoI5EXju3t9iI5Z), a membership certificate or some kind of ticket to obtain some service, such as a cinema ticket or a public transport ticket, a digital credential is a proof of qualification, competence, or clearance that is attached to a person.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital ecosystem](#h.edgw5dskp7an)
+
+    -   ### ToIP
+
+        A digital ecosystem is a distributed, adaptive, open socio-technical system with properties of self-organization, scalability and sustainability inspired from natural ecosystems. Digital ecosystem models are informed by knowledge of natural ecosystems, especially for aspects related to competition and collaboration among diverse [entities](#h.5imtbzl1f4xo).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_ecosystem&sa=D&source=editors&ust=1718703186653056&usg=AOvVaw24Bgtp-FZTqpU-3ESvI_QX).
+
+        See also: [digital trust ecosystem](#h.h47f86smlz4y), [trust community](#h.a9l3odcb1s29).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital identity](#h.r5y8zwxvzyd3)
+
+    -   ### ToIP
+
+        An [identity](#h.z1gairv0pej5) expressed in a digital form for the purpose representing the identified [entity](#h.5imtbzl1f4xo) within a computer system or digital network.
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary&sa=D&source=editors&ust=1718703186653665&usg=AOvVaw3H3O1mvGsCv5K5aWjNoerY): [Digital data](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23data&sa=D&source=editors&ust=1718703186653844&usg=AOvVaw182PR81TdrnULE1pFF-F2I) that enables a specific [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23entity&sa=D&source=editors&ust=1718703186654027&usg=AOvVaw3hlrvcRJbkFhz1c3GJsgHW) to be distinguished from all others in a specific context.
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_identity&sa=D&source=editors&ust=1718703186654250&usg=AOvVaw19ZGTDnk15WW_JPoclQqgh): Digital identity refers to the information utilized by [computer systems](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_systems&sa=D&source=editors&ust=1718703186654403&usg=AOvVaw3MoK6DkwJmvsCLi8ySPkE6) to represent external entities, including a person, organization, application, or device. When used to describe an individual, it encompasses a person's compiled information and plays a crucial role in automating access to computer-based services, verifying identity online, and enabling computers to mediate relationships between entities.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital rights management](#h.d6exis1ya9fd)
+
+    -   ### ToIP
+
+        Digital rights management (DRM) is the management of legal access to digital content. Various tools or technological protection measures (TPM) like [access control](#h.lmk4gqobt99b) technologies, can restrict the use of proprietary hardware and copyrighted works. DRM technologies govern the use, modification and distribution of copyrighted works (e.g. software, multimedia content) and of systems that enforce these policies within devices.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_rights_management&sa=D&source=editors&ust=1718703186654970&usg=AOvVaw2VLnTYAQMRy-DLI8fmleZM).
+
+        Also known as: [DRM](#h.m9um65bhu37).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital signature](#h.s93np0i5rcne)
+
+    -   ### ToIP
+
+        A digital signature is a mathematical scheme for verifying the authenticity of digital [messages](#h.bge7ubygwk2q) or documents. A valid digital signature, where the prerequisites are satisfied, gives a recipient very high confidence that the [message](#h.bge7ubygwk2q) was created by a known sender ([authenticity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Authentication&sa=D&source=editors&ust=1718703186656384&usg=AOvVaw3Fx7ketDNkjM1l0foH4lmh)), and that the message was not altered in transit ([integrity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data_integrity&sa=D&source=editors&ust=1718703186656566&usg=AOvVaw0tH5Rth6P1Z7Nfe3Ur8hWK)).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_signature&sa=D&source=editors&ust=1718703186656777&usg=AOvVaw2RSHDvq1eKSGR1EK9XhveE).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/digital_signature&sa=D&source=editors&ust=1718703186657033&usg=AOvVaw2DxFBA1CvHVeY4Q2aO0fwn): The result of a cryptographic transformation of data which, when properly implemented, provides the services of: 1. origin authentication, 2. data integrity, and 3. signer non-repudiation.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # digital signature
+
+        ###### Definition
+
+        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).
+
+        ###### Electronic signatures
+
+        There are `digital signatures` and [Electronic signatures](https://weboftrust.github.io/keridoc/docs/glossary/electronic-signature.md), the latter are quite different in purpose and practical use.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [digital trust ecosystem](#h.h47f86smlz4y)
+
+    -   ### ToIP
+
+        A [digital ecosystem](#h.edgw5dskp7an) in which the participants are one or more interoperating [trust communities](#h.a9l3odcb1s29). Governance of the various [roles](#h.sf54cyuamo6x) of [governed parties](#h.c1jlj376y5m3) within a digital trust ecosystem (e.g., [issuers](#h.xyrplzbvtffq), [holders](#h.64mptmm24w7u), [verifiers](#h.xfewd7t01hu0), [certification bodies](#h.noh9fchc9jx), [auditors](#h.g2w6uyjqzrr)) is typically managed by a [governing body](#h.1wptecwzvuvz) using a [governance framework](#h.2x05z0r097mn) as recommended in the [ToIP Governance Stack](#h.ciwa0pidrb2e). Many digital trust ecosystems will also maintain one or more [trust lists](#h.f1feh0fmucqd) and/or [trust registries](#h.5kzln6m5e8j5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital trust utility](#h.ou8opzfswu3c)
+
+    -   ### ToIP
+
+        An information system, network, distributed database, or [blockchain](#h.bxz57auzxstx) designed to provide one or more supporting services to higher level components of decentralized digital trust infrastructure. In the [ToIP stack](#h.wms58fgdch9m), digital trust utilities are at [Layer 1](#h.v1hjglhanrdl). A [verifiable data registry](#h.q1dr1v2lltfe) is one type of digital trust utility.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital vault](#h.cz29glapo2tg)
+
+    -   ### ToIP
+
+        A secure container for [data](#h.o783ayrrkc6g) whose [controller](#h.gemoqe2m303z) is the [principal](#h.sydbe7rk6244). A digital vault is most commonly used in conjunction with a [digital wallet](#h.sxnvf3f5v156) and a [digital agent](#h.z3ugzt4hgdf6). A digital vault may be implemented on a local device or in the cloud; multiple digital vaults may be used by the same [principal](#h.sydbe7rk6244) across different devices and/or the cloud; if so they may use some type of synchronization. If the capability is supported, [data](#h.o783ayrrkc6g) may flow into or out of the digital vault automatically based on [subscriptions](#h.59sxmlru2xqb) approved by the [controller](#h.gemoqe2m303z).
+
+        Also known as: [data vault](#h.r86ltcrr5evr), [encrypted data vault](#h.x4ayv74r9gbs).
+
+        See also: [enterprise data vault](#h.3una07qf7p4u), [personal data vault](#h.9b2ram5w4omg), [virtual vault](#h.7dcabufiu2bo).
+
+        For more information, see: [https://en.wikipedia.org/wiki/Personal\_data\_service](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Personal_data_service&sa=D&source=editors&ust=1718703186658182&usg=AOvVaw2Z1K2se_1d2wFJZsA_4tqm), [https://digitalbazaar.github.io/encrypted-data-vaults/](https://www.google.com/url?q=https://digitalbazaar.github.io/encrypted-data-vaults/&sa=D&source=editors&ust=1718703186658428&usg=AOvVaw0aJk85N9Tc7pAL1EMp77V0)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [digital wallet](#h.sxnvf3f5v156)
+
+    -   ### ToIP
+
+        A [user agent](#h.jb61co23rlut), optionally including a hardware component, capable of securely storing and processing [cryptographic keys](#h.53rzpn1yn6q7), [digital credentials](#h.ddna9lucn4k6), [digital assets](#h.emffux4xw3th) and other sensitive private [data](#h.o783ayrrkc6g) that enables the [controller](#h.gemoqe2m303z) to perform [cryptographically verifiable](#h.422iwwfur12) operations. A [non-custodial wallet](#h.ridlo7ub9haf) is directly in the custody of a [principal](#h.sydbe7rk6244). A [custodial wallet](#h.5qanwm5930bp) is in the [custody](#h.8kx1mv7y64ps) of a [third party](#h.zu2vj8151tr). [Personal wallets](#h.1qe7g02c5t4p) are held by individual persons; [enterprise wallets](#h.lwbrzpnzaqth) are held by [organizations](#h.z27mp1358pi9) or other [legal entities](#h.5328bxxk02sb).
+
+        See also: [digital agent](#h.z3ugzt4hgdf6), [key management system](#h.q0w3jq78va39), [wallet engine](#h.jsmi4264di2s).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23wallet&sa=D&source=editors&ust=1718703186659930&usg=AOvVaw35Qs_vv2EcDTKPht9wePgV): a component that implements the [capability](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/capability&sa=D&source=editors&ust=1718703186660122&usg=AOvVaw0aod1TundJ62xxXa4Xo-34) to securely store data as requested by [colleague agents](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/colleague&sa=D&source=editors&ust=1718703186660279&usg=AOvVaw0CSFja5fdzGwQIE3K-ShSP), and to provide stored data to [colleague agents](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/colleague&sa=D&source=editors&ust=1718703186660424&usg=AOvVaw0WyEhP8cJ0PWgxWikeZqBP) or [peer agents](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/peer-agent&sa=D&source=editors&ust=1718703186660598&usg=AOvVaw1WvaBzrA7jsVxafZErln6v), all in [compliance](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/compliance&sa=D&source=editors&ust=1718703186660746&usg=AOvVaw3CYSL6ilG8bi49BdYX5DnM) with the rules of its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186660896&usg=AOvVaw2oNKODgcKOS09JfUO6RORR)'s [wallet policy](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/wallet-policy&sa=D&source=editors&ust=1718703186661055&usg=AOvVaw0cL7lLHsyX18MHADWffuA8).
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_wallet&sa=D&source=editors&ust=1718703186661250&usg=AOvVaw1dT-0Km4FWHyjjOJAMeB-N): A digital wallet, also known as an e-wallet, is an [electronic device](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Consumer_electronics&sa=D&source=editors&ust=1718703186661401&usg=AOvVaw2G73RRSafu7c4xx6iE6URV), [online service](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Online_service_provider&sa=D&source=editors&ust=1718703186661554&usg=AOvVaw3wYxAJEw-hPjYR4L4RWNZN), or [software program](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_program&sa=D&source=editors&ust=1718703186661705&usg=AOvVaw21GWC9FflhOXEfqfgZW7U1) that allows one party to make [electronic transactions](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_transaction&sa=D&source=editors&ust=1718703186661847&usg=AOvVaw1i4cmKH8Q8i6WHWSc2iruQ) with another party bartering [digital currency](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_currency&sa=D&source=editors&ust=1718703186661999&usg=AOvVaw2kyBJmoxSR45TmyiEUx81J) units for [goods and services](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Goods_and_services&sa=D&source=editors&ust=1718703186662140&usg=AOvVaw0oJYK1i6-YrsIC1o19aRyn). This can include purchasing items either [online](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Online_and_offline&sa=D&source=editors&ust=1718703186662306&usg=AOvVaw1Of-9a_c4dmYRvTlYwejIu) or at the [point of sale](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Point_of_sale&sa=D&source=editors&ust=1718703186662514&usg=AOvVaw0LxWFgYflg4pei_7ZIbG3x) in a [brick and mortar](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Brick_and_mortar&sa=D&source=editors&ust=1718703186662659&usg=AOvVaw1_tKY3bKdiXLIMtxsFN3fi) store, using either [mobile payment](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mobile_payment&sa=D&source=editors&ust=1718703186662796&usg=AOvVaw3nizWzMu1nodlW9P9iTLrr) (on a [smartphone](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Smartphone&sa=D&source=editors&ust=1718703186662925&usg=AOvVaw2pgz95IcLTKBoCROYB8IaZ) or other [mobile device](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mobile_device&sa=D&source=editors&ust=1718703186663060&usg=AOvVaw3C9ehhYf1Kl00VbiQcT-kQ)) or (for online buying only) using a [laptop](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Laptop&sa=D&source=editors&ust=1718703186663194&usg=AOvVaw2wcvLMum9Hrf4CKduPzM-L) or other [personal computer](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Personal_computer&sa=D&source=editors&ust=1718703186663376&usg=AOvVaw0aNWXkxebZySu2EgJDJJU8). Money can be deposited in the digital wallet prior to any transactions or, in other cases, an individual's bank account can be linked to the digital wallet. Users might also have their [driver's license](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Driver%2527s_license&sa=D&source=editors&ust=1718703186663543&usg=AOvVaw08ZnaUOiR7X_TMV52vkcsy), [health card](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Health_Care_Card&sa=D&source=editors&ust=1718703186663741&usg=AOvVaw1zmdq_hhLoaRGSlpVEpYFM), loyalty card(s) and other ID documents stored within the wallet. The credentials can be passed to a merchant's terminal wirelessly via [near field communication](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Near_field_communication&sa=D&source=editors&ust=1718703186663901&usg=AOvVaw3-PqXWexCF9GXJBgmZC8Ds) (NFC).
+
+        Note: In market parlance, a mobile app that performs the [actions](#h.l54nzmooy631) of a [digital agent](#h.z3ugzt4hgdf6) and has access to a set of [cryptographic keys](#h.53rzpn1yn6q7) is often simply called a [wallet](#h.mh27630t20d) or a digital wallet.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [dip](#dip)
+
+    -   ### WebOfTrust
+
+        # dip
+
+        ###### Definition
+
+        dip = delcept, delegated inception
+
+        [Learn more](https://kerisse.org)
+
+-   ## [direct mode](#directmode)
+
+    -   ### ToIP (DID:Webs)
+
+        an operational mode of the KERI protocol where a controller and a verifier of an AID exchange the KEL of the AID directly, as defined by the KERI whitepaper. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # direct mode
+
+        ###### Definition
+
+        Two primary trust modalities motivated the KERI design, One of these is the _direct_ (one-to-one) mode, in which the identity controller establishes control via verified signatures of the controlling key-pair. The direct mode doesn't use witnesses nor [KERL](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-log.md)s, but has direct (albeit intermittent) network contact with the validator.
+
+        ###### Operational mode
+
+        To protect a [validator](https://weboftrust.github.io/keridoc/docs/glossary/validator.md) when engaging with some other controller’s identifier, be it [verification](https://weboftrust.github.io/keridoc/docs/glossary/verification.md), control authority establishment, or [duplicity](https://weboftrust.github.io/keridoc/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 direct mode, the promulgation of events to a validator does not happen unless the controller is attached to the network and able to communicate directly with a validator.
+        Direct mode assumes that the controller may have intermittent network availability, it also assumes that these mechanism may not be trusted in any persistent sense to promulgate key events. Nonetheless, direct mode is important as it is compatible with the use of mobile internet devices such as cell phones. A single direct mode identifier may be re-used in multiple one-to-one relationships as part of a select group.
+        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)
+
+        ###### Security concerns
+
+        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.
+
+        ###### Also see
+
+        [Indirect mode](https://weboftrust.github.io/keridoc/docs/glossary/indirect-mode.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [directed acyclic graph](#directed-acyclic-graph)
+
+    -   ### WebOfTrust
+
+        # directed acyclic graph
+
+        ###### Definition
+
+        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.
+
+        ![A directed acyclic graph (DAG)](https://hackmd.io/_uploads/rywIzRLo5.png)
+
+        ###### Why a directed acyclic graph (DAG)
+
+        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.
+
+        ###### Unique properties
+
+        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.
+
+        ###### Applications
+
+        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).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [disclosee](#disclosee)
+
+    -   ### WebOfTrust
+
+        # disclosee
+
+        ###### Definition
+
+        an ACDC in a disclosure is disclosed to the Disclosee
+
+        [Learn more](https://kerisse.org)
+
+-   ## [discloser](#discloser)
+
+    -   ### WebOfTrust
+
+        # discloser
+
+        ###### Definition
+
+        An [ACDC](https://weboftrust.github.io/keridoc/docs/glossary/authentic-chained-data-container.md) in a disclosure is disclosed by the Discloser.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [discovery](#discovery)
+
+    -   ### WebOfTrust
+
+        # discovery
+
+        ###### Definition
+
+        A mechanism that helps systems or devices find each other automatically, often used in networks to identify services or resources. In decentralized identifier systems it helps to locate and verify digital identities without relying on a central authority.
+
+        ###### Related but not the same
+
+        [Percolated information discovery](https://weboftrust.github.io/keridoc/docs/glossary/percolated-information-discovery.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [distributed hash table](#distributed-hash-table)
+
+    -   ### WebOfTrust
+
+        # distributed hash table
+
+        ###### Definition
+
+        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))
+
+        [Learn more](https://kerisse.org)
+
+-   ## [distributed ledger](#h.eoh04mpatko3)
+
+    -   ### ToIP
+
+        A distributed ledger (also called a shared ledger or distributed ledger technology or DLT) is the consensus of replicated, shared, and synchronized digital [data](#h.o783ayrrkc6g) that is geographically spread (distributed) across many sites, countries, or institutions. In contrast to a centralized database, a distributed ledger does not require a central administrator, and consequently does not have a single (central) point-of-failure. In general, a distributed ledger requires a [peer-to-peer](#h.ikjsqxobvozv) (P2P) computer network and consensus algorithms so that the ledger is reliably replicated across distributed computer [nodes](#h.w1aty8c036fp) (servers, clients, etc.). The most common form of distributed ledger technology is the [blockchain](#h.bxz57auzxstx), which can either be on a public or private network.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Distributed_ledger&sa=D&source=editors&ust=1718703186665039&usg=AOvVaw2HXsEotMWsLtEyXEtD-aIL).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [distributed ledger (DLT)](#distributedledger\(DLT\))
+
+    -   ### W3C (DID)
+
+        A non-centralized system for recording events. These systems establishsufficient confidence for participants to rely upon the data recorded by othersto make operational decisions. They typically use distributed databases wheredifferent nodes use a consensus protocol to confirm the ordering ofcryptographically signed transactions. The linking of digitally signedtransactions over time often makes the history of the ledger effectivelyimmutable.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [dnd](#dnd)
+
+    -   ### WebOfTrust
+
+        # dnd
+
+        ###### Definition
+
+        Do Not Delegate is a flag / attribute for a AID and this is default set to you can delegate.
+
+        | TBW |
+
+        [Learn more](https://kerisse.org)
+
+-   ## [domain](#domain)
+
+    -   ### Nist
+
+        A set of elements, data, resources, and functions that share a commonality in combinations of (1) roles supported, (2) rules governing their use, and (3) protection needs.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/domain)
+
+    -   ### ToIP
+
+        See: [security domain](#h.d7ry9j100f36).
+
+        See also: [trust domain](#h.60miqe21hd5h).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # domain
+
+        ###### See
+
+        [Trust domain](https://weboftrust.github.io/keridoc/docs/glossary/trust-domain.md) and / or [Domain name](https://weboftrust.github.io/keridoc/docs/glossary/domain-name.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [domain name](#domain-name)
+
+    -   ### WebOfTrust
+
+        # domain name
+
+        ###### Definition
+
+        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).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [double spend proof](#double-spend-proof)
+
+    -   ### WebOfTrust
+
+        # double spend proof
+
+        ###### Definition
+
+        Total global ordering of transaction so that value can’t be spend twice at the same time from the unit of value. Or in common language: you can't spend your money twice.
+
+        | TBW |
+
+        ##### KERI related
+
+        The most important feature of a [cryptocurrency](https://weboftrust.github.io/keridoc/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).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [drt](#drt)
+
+    -   ### WebOfTrust
+
+        # drt
+
+        ###### Definition
+
+        drt = deltate, delegated rotation
+
+        [Learn more](https://kerisse.org)
+
+-   ## [dual indexed codes](#dual-indexed-codes)
+
+    -   ### WebOfTrust
+
+        # dual indexed codes
+
+        ###### Definition
+
+        a context-specific coding scheme, for the common use case of thresholded multi-signature schemes in [CESR](https://weboftrust.github.io/keridoc/docs/glossary/CESR.md).
+
+        ###### Related to CESR
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [dual text binary encoding format](#dual-text-binary-encoding-format)
+
+    -   ### WebOfTrust
+
+        # dual text binary encoding format
+
+        ###### Definition
+
+        An encoding format that allows for both text and binary encoding format, which is fully interchangeable. The [composability](https://weboftrust.github.io/keridoc/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
+
+        ###### Related
+
+        -   [CESR](https://weboftrust.github.io/keridoc/docs/glossary/CESR.md)
+        -   [composability](https://weboftrust.github.io/keridoc/docs/glossary/composability.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [duplicitous event log](#duplicitous-event-log)
+
+    -   ### WebOfTrust
+
+        # duplicitous event log
+
+        ###### Definition
+
+        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/keridoc/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/keridoc/docs/glossary/inconsistency.md) event messages with respect to a KERL. Each [juror](https://weboftrust.github.io/keridoc/docs/glossary/juror.md) keeps a duplicitous event log (DEL) for each [controller](https://weboftrust.github.io/keridoc/docs/glossary/controller.md) and all designated witness with respect to a KERL. Any [validator](https://weboftrust.github.io/keridoc/docs/glossary/validator.md) may confirm [duplicity](https://weboftrust.github.io/keridoc/docs/glossary/duplicity.md) by examining a DEL.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [duplicity](#duplicity)
+
+    -   ### WebOfTrust
+
+        # duplicity
+
+        ###### Duplicity
+
+        _Duplicity_ is used to describe external inconsistency. Publication of two or more versions of a KEL, each of which is internally consistent is duplicity. Given that signatures are non-repudiable any duplicity is detectable and provable given possession of any two mutually inconsistent versions of a KEL. In KERI [consistency](https://weboftrust.github.io/keridoc/docs/glossary/inconsistency.md) is is used to described data that is internally consistent and cryptographically verifiably so.
+
+        ###### KERI related
+
+        Duplicity means the existence of **more than one version** of a verifiable KEL for a given AID. Because every event in a KEL must be signed with non-repudiable signatures any inconsistency between any two instances of the KEL for a given AID is provable evidence of duplicity on the part of the signers with respect to either or both the key-state of that AID and/or any anchored data at a given key-state. A shorter KEL that does not differ in any of its events with respect to another but longer KEL is not duplicitous but merely incomplete. To clarify, duplicity evident means that duplicity is provable via the presentation of a set of two or more mutually inconsistent but independently verifiable instances of a KEL.Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
+
+        ###### Outside world
+
+        In common language 'duplicity' has a slightly different connotation: 'two-facedness', 'dishonesty', 'deceitfulness', 'deviousness,'two-facedness', 'falseness'.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [duplicity detection](#duplicity-detection)
+
+    -   ### WebOfTrust
+
+        # duplicity detection
+
+        ###### Definition
+
+        A mechanism to detect [duplicity](https://weboftrust.github.io/keridoc/docs/glossary/duplicity.md) in cryptographically secured event logs.
+
+        ###### KERI related
+
+        Duplicity detection, which protects, _not against an external attacker_, but against a malicious [controller](https://weboftrust.github.io/keridoc/docs/glossary/controller.md) does require access to [watchers](https://weboftrust.github.io/keridoc/docs/glossary/watcher.md) that are also recording duplicitous events.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [eIDAS](#h.jf3x05g0bptv)
+
+    -   ### ToIP
+
+        eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation with the stated purpose of governing "electronic identification and [trust services](#h.lob8zt6w1hh) for electronic transactions". It passed in 2014 and its provisions came into effect between 2016-2018.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/EIDAS&sa=D&source=editors&ust=1718703186666543&usg=AOvVaw0CBeB68r9Ja_zlWzsU17tT).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [eSSIF-Lab World Model](#essif-lab-world-model)
+
+    -   ### Essif-Lab
+
+        the set of [concept](https://essif-lab.github.io/framework/docs/terms/concept), relations between them ([pattern](https://essif-lab.github.io/framework/docs/terms/pattern)), and [Principles](https://weboftrust.github.io/keridoc/framework/docs/essifLab-principles.md) (that are the starting point for eSSIF-Lab's thinking).
+
+        [Learn more](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+-   ## [eclipse attack](#eclipse-attack)
+
+    -   ### WebOfTrust
+
+        # eclipse attack
+
+        ###### Definition
+
+        An eclipse attack is a [P2P](https://weboftrust.github.io/keridoc/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/)
+
+        ###### KERI related
+
+        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)
+
+        ###### Working of Eclipse Attack
+
+        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/)
+
+        ![working of an eclipse attack](https://hackmd.io/_uploads/B1uNi0Egi.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ecosystem](#h.6lbj6fqiooii)
+
+    -   ### ToIP
+
+        See: [digital ecosystem](#h.edgw5dskp7an).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ecosystem governance framework](#h.dkge5gglsmk3)
+
+    -   ### ToIP
+
+        A [governance framework](#h.2x05z0r097mn) for a [digital trust ecosystem](#h.h47f86smlz4y). An ecosystem governance framework may incorporate, aggregate, or reference other types of governance frameworks such as a [credential governance framework](#h.tlmucrcg1d6g) or a [utility governance framework](#h.n08ql59sgrtn).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [electronic signature](#electronic-signature)
+
+    -   ### WebOfTrust
+
+        # electronic signature
+
+        ###### Definition
+
+        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).
+
+        ###### Digital signature implementation of e-signatures
+
+        _Electronic_ signatures are a legal concept _distinct_ from **[digital signatures](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [encrypt sender sign receiver](#encrypt-sender-sign-receiver)
+
+    -   ### WebOfTrust
+
+        # encrypt sender sign receiver
+
+        ###### Definition
+
+        An authenticated encryption approach, using [PKI](https://weboftrust.github.io/keridoc/docs/glossary/PKI.md). It covers [authenticity](https://weboftrust.github.io/keridoc/docs/glossary/authenticity.md) and [confidentiality](https://weboftrust.github.io/keridoc/docs/glossary/confidentiality.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [encrypted data vault](#h.x4ayv74r9gbs)
+
+    -   ### ToIP
+
+        See: [digital vault](#h.cz29glapo2tg).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [encryption](#h.iyq318f2vg61)
+
+    -   ### ToIP
+
+        Cryptographic transformation of [data](#h.o783ayrrkc6g) (called [plaintext](#h.ylf3pqlex968)) into a form (called [ciphertext](#h.9ripqbaz7egw)) that conceals the [data’s](#h.o783ayrrkc6g) original meaning to prevent it from being known or used. If the transformation is reversible, the corresponding reversal process is called [decryption](#h.fuc05ut9lwmq), which is a transformation that restores encrypted [data](#h.o783ayrrkc6g) to its original state.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/encryption&sa=D&source=editors&ust=1718703186667381&usg=AOvVaw0xeaceME-sZGIK6QtMO1kQ).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [end role](#end-role)
+
+    -   ### WebOfTrust
+
+        # end role
+
+        ###### Definition
+
+        An end role is an authorization for one [AID](https://weboftrust.github.io/keridoc/docs/glossary/AID.md) to serve in a role for another [AID](https://weboftrust.github.io/keridoc/docs/glossary/AID.md).
+
+        For example, declaring that your [Agent](https://weboftrust.github.io/keridoc/docs/glossary/agent.md) [AID](https://weboftrust.github.io/keridoc/docs/glossary/AID.md) is serving in the role of [Agent](https://weboftrust.github.io/keridoc/docs/glossary/agent.md) for your business AIDs.
+
+        Source: Phil Feairheller
+
+        [Learn more](https://kerisse.org)
+
+-   ## [end to end](#end-to-end)
+
+    -   ### WebOfTrust
+
+        # end to end
+
+        ###### Definition
+
+        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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [end verifiable](#end-verifiable)
+
+    -   ### WebOfTrust
+
+        # end verifiable
+
+        ###### Definition
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [end-to-end encryption](#h.q2kyp3tnhmic)
+
+    -   ### ToIP
+
+        [Encryption](#h.iyq318f2vg61) that is applied to a [communication](#h.w02a6srdng3j) before it is transmitted from the sender’s [communication endpoint](#h.qstkv072p5tx) and cannot be [decrypted](#h.fuc05ut9lwmq) until after it is received at the receiver’s [communication endpoint](#h.qstkv072p5tx). When end-to-end encryption is used, the [communication](#h.w02a6srdng3j) cannot be [decrypted](#h.fuc05ut9lwmq) in transit no matter how many [intermediary systems](#h.i4pfys3yiku) are involved in the [routing](#h.tbxetxt0mdlp) process.
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/End-to-end_encryption&sa=D&source=editors&ust=1718703186668207&usg=AOvVaw0dC1_2oMsihnDwtY9rDKCN): End-to-end encryption (E2EE) is a private communication system in which only communicating users can participate. As such, no one, including the communication system provider, [telecom providers](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Telecommunications_service_providers&sa=D&source=editors&ust=1718703186668402&usg=AOvVaw22A-aRjwLrWzLN2bC4QBKY), [Internet providers](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_providers&sa=D&source=editors&ust=1718703186668552&usg=AOvVaw2PRFvoTEmUjerPd1Gnt4wc) or malicious actors, can access the [cryptographic keys](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Key_\(cryptography\)&sa=D&source=editors&ust=1718703186668699&usg=AOvVaw10Qf53r4NTDWEwCFgsHBBf) needed to converse. End-to-end [encryption](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Encryption&sa=D&source=editors&ust=1718703186668875&usg=AOvVaw2ijLrOUUGzDhNQUZzq-zoR) is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [endpoint](#h.yodlnk353mx)
+
+    -   ### ToIP
+
+        See: [communication endpoint](#h.qstkv072p5tx).
+
+        See also: [ToIP endpoint](#h.2ahqabymbkn3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [endpoint system](#h.scy14dobg777)
+
+    -   ### ToIP
+
+        The system that operates a [communications](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.w02a6srdng3j&sa=D&source=editors&ust=1718703186670436&usg=AOvVaw2xvNokdBbHJ97hL1bfXBUq) [endpoint](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.yodlnk353mx&sa=D&source=editors&ust=1718703186670696&usg=AOvVaw0Ykbq76esIt0v5iTIYTekI). In the context of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186670926&usg=AOvVaw2fZ7KYFu5SRQHm8weaMvgk), an endpoint system is one of three types of systems defined in the [ToIP Technology Architecture Specification](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.bjv9ltwjbiqm&sa=D&source=editors&ust=1718703186671174&usg=AOvVaw1k-4nMgTP4IAgZtJZSVr4B).
+
+        See also: [intermediary system](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.i4pfys3yiku&sa=D&source=editors&ust=1718703186671490&usg=AOvVaw2w8kCvcKIAIh_MahjKZRhm), [supporting system](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.nqtdtghyfspz&sa=D&source=editors&ust=1718703186671707&usg=AOvVaw3KPDimzc9fVX8um5h1g6PC).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [engagement context role](#engagement-context-role)
+
+    -   ### WebOfTrust
+
+        # engagement context role
+
+        ###### Definition
+
+        A person that represents the [Legal Entity](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity.md) in a functional or in another context role and is issued an ECR [vLEI Credential](https://weboftrust.github.io/keridoc/docs/glossary/vlei-credential.md).
+
+        ###### Issuance of credentials
+
+        On the basis of [Legal entity engagement context role vLEI credential governance framework](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md) an ECR [vLEI Credential](https://weboftrust.github.io/keridoc/docs/glossary/vlei-credential.md) is **issued to** an engagement context role (ECR).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [enrol ~ment](#enrol~ment)
+
+    -   ### digital.govt.nz
+
+        to become or cause to become a member; enlist; register\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [enterprise data vault](#h.3una07qf7p4u)
+
+    -   ### ToIP
+
+        A [digital vault](#h.cz29glapo2tg) whose [controller](#h.gemoqe2m303z) is an [organization](#h.z27mp1358pi9).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [enterprise wallet](#h.lwbrzpnzaqth)
+
+    -   ### ToIP
+
+        A [digital wallet](#h.sxnvf3f5v156) whose [holder](#h.64mptmm24w7u) is an [organization](#h.z27mp1358pi9).
+
+        Contrast with: [personal wallet](#h.1qe7g02c5t4p).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [entity](#entity)
+
+    -   ### digital.govt.nz
+
+        something that has real or distinct existence from other things\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        Someone or something that is known to exist.
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary&sa=D&source=editors&ust=1718703186672621&usg=AOvVaw2kh7HUuctRkQmUxOwa2rqV).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # entity
+
+        ###### See
+
+        [entity](https://trustoverip.github.io/essiflab/glossary#entity) in the **#essiflab** glossary.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [entropy](#entropy)
+
+    -   ### WebOfTrust
+
+        # entropy
+
+        ###### Definition
+
+        Unpredictable information. Often used as a _secret_ or as input to a _key_ generation algorithm.
+
+        ##### More on Wikipedia
+
+        [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_.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ephemeral](#ephemeral)
+
+    -   ### WebOfTrust
+
+        # ephemeral
+
+        ###### Definition
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ephemeral connection](#h.5xjtv29e8z6i)
+
+    -   ### ToIP
+
+        A [connection](#h.thbpewq1px8x) that only exists for the duration of a single [communication session](#h.i82tgrmxy0d8) or [transaction](#h.92pu88ke4p7k).
+
+        Contrast with: [persistent connection](#h.ccf1vkxvhh1l).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [escrow](#escrow)
+
+    -   ### WebOfTrust
+
+        # escrow
+
+        ###### Definition
+
+        '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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [escrow state](#escrow-state)
+
+    -   ### WebOfTrust
+
+        # escrow state
+
+        ###### Definition
+
+        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.
+
+        ###### Inner-working and motivation
+
+        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
+
+        ###### Beware
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [establishment event](#establishment-event)
+
+    -   ### WebOfTrust
+
+        # establishment event
+
+        ###### Definition
+
+        A key creation or rotation event that establishes or transfers control authority for an identifier.
+
+        Establishment events indicate which key pairs are authoritative (controlling) for an identifier at a given point in time.
+
+        The subset of a [key event log](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) (KEL) that are establishment events are an ordered subsequence of the full KEL.
+
+        For a non-transferable identifier this is one authoritative key pair and it never changes so there will only ever be one establishment event, the inception event.
+
+        For transferable identifiers there can be multiple establishment events which would include the initial rotation event and any subsequent rotation events.
+
+        Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [evidence](#evidence)
+
+    -   ### digital.govt.nz
+
+        to give proof of or evidence for\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [exn](#exn)
+
+    -   ### WebOfTrust
+
+        # exn
+
+        ###### Definition
+
+        exn = exchange
+
+        [Learn more](https://kerisse.org)
+
+-   ## [exp](#exp)
+
+    -   ### WebOfTrust
+
+        # exp
+
+        ###### Definition
+
+        exp = expose, sealed data exposition
+
+        [Learn more](https://kerisse.org)
+
+-   ## [expression language](#h.21tvck8eyp4o)
+
+    -   ### ToIP
+
+        A language for creating a computer-interpretable ([machine-readable](#h.8s3s84fzcfi3)) representation of specific [knowledge](#h.k96lktyswxnb).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Expression_language&sa=D&source=editors&ust=1718703186673561&usg=AOvVaw2iuUQfrnbdCGQw09L8JkIx).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [extensible business reporting language](#extensible-business-reporting-language)
+
+    -   ### WebOfTrust
+
+        # extensible business reporting language
+
+        ###### Definition
+
+        XBRL is the open international standard for digital business reporting, managed by a global not for profit consortium, XBRL International.
+
+        ###### Practical
+
+        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/)
+
+        ###### Technical
+
+        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/)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [facilitate~ion](#facilitate~ion)
+
+    -   ### digital.govt.nz
+
+        to make easier; assist the progress of\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [facilitation providerFP](#facilitationproviderFP)
+
+    -   ### digital.govt.nz
+
+        the party accountable for the establishment and functioning of a facilitation mechanism\[Source: New definition\]Additional note:Note 1: A facilitation mechanism facilitates the presentation of 1 or more Credentials to a Relying Party.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [federated identity](#h.cb1le64hx6h5)
+
+    -   ### ToIP
+
+        A [digital identity](#h.r5y8zwxvzyd3) architecture in which a [digital identity](#h.r5y8zwxvzyd3) established on one computer system, network, or [trust domain](#h.60miqe21hd5h) is linked to other computer systems, networks, or [trust domains](#h.60miqe21hd5h) for the purpose of identifying the same [entity](#h.5imtbzl1f4xo) across those domains.
+
+        See also: [decentralized identity](#h.xodo7ytn4cx2), [self-sovereign identity](#h.wdojy63bltd4).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/federated_identity_management&sa=D&source=editors&ust=1718703186674567&usg=AOvVaw03588NDUaj1uHtocuLGFYg); A process that allows for the conveyance of identity and authentication information across a set of networked systems.
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Federated_identity&sa=D&source=editors&ust=1718703186674784&usg=AOvVaw2DYBFB-uuGfNCUaSrD1Gor): A federated identity in [information technology](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Information_technology&sa=D&source=editors&ust=1718703186674964&usg=AOvVaw1Wvy8Yhph3o9igtchfyyyq) is the means of linking a person's [electronic identity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_identity&sa=D&source=editors&ust=1718703186675113&usg=AOvVaw31bRR2JjwYwVH6vqEBjIk-) and attributes, stored across multiple distinct [identity management](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Identity_management&sa=D&source=editors&ust=1718703186675529&usg=AOvVaw03SOCXGH7PaCL2M9DylN96) systems.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [federate~d~ion](#federate~d~ion)
+
+    -   ### digital.govt.nz
+
+        united by common agreement under an authority\[Source: Dictionary modified to remove central government\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [federation](#h.7ph0icfh463b)
+
+    -   ### ToIP
+
+        A group of [organizations](#h.z27mp1358pi9) that collaborate to establish a common [trust framework](#h.2r5mn949idq) or [governance framework](#h.2x05z0r097mn) for the exchange of [identity data](#h.t3ho4tago38u) in a [federated identity](#h.cb1le64hx6h5) system.
+
+        See also: [trust community](#h.a9l3odcb1s29)
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/federation&sa=D&source=editors&ust=1718703186676170&usg=AOvVaw0y-nqiCjU5eFmhORdTMogU): A collection of realms (domains) that have established trust among themselves. The level of trust may vary, but typically includes authentication and may include authorization.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [federation assurance level](#h.8fhj7rpnpjy3)
+
+    -   ### ToIP
+
+        A category that describes the [federation](#h.7ph0icfh463b) protocol used to communicate an assertion containing [authentication](#h.ej596duqqmnb) and [attribute](#h.ky5nh3yri7ak) information (if applicable) to a [relying party](#h.61sr3qnr1eci), as defined in [NIST SP 800-63-3](https://www.google.com/url?q=https://pages.nist.gov/800-63-3/&sa=D&source=editors&ust=1718703186676668&usg=AOvVaw1Rqq9sCCCpSS0Hb9l7523p) in terms of three levels: FAL 1 (Some confidence), FAL 2 (High confidence), FAL 3 (Very high confidence).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/federation_assurance_level&sa=D&source=editors&ust=1718703186676887&usg=AOvVaw0KnpTCf7cQYIcoWCsowPN1).
+
+        See also: [authenticator assurance level](#h.a7560ebfrt4m), [identity assurance level](#h.udr0qmo2ubln).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [fiduciary](#h.5w05xlh4j8ms)
+
+    -   ### ToIP
+
+        A fiduciary is a person who holds a legal or ethical relationship of trust with one or more other [parties](#h.cn6bno48fomj) (person or group of persons). Typically, a fiduciary prudently takes care of money or other [assets](#h.emffux4xw3th) for another person. One [party](#h.cn6bno48fomj), for example, a corporate trust company or the trust department of a bank, acts in a fiduciary capacity to another [party](#h.cn6bno48fomj), who, for example, has entrusted funds to the fiduciary for safekeeping or investment. In a fiduciary relationship, one person, in a position of vulnerability, justifiably vests confidence, good faith, reliance, and trust in another whose aid, advice, or protection is sought in some matter.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Fiduciary&sa=D&source=editors&ust=1718703186677639&usg=AOvVaw1c7pYb56LNZ7hrGEAeEZe4).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [field map](#field-map)
+
+    -   ### WebOfTrust
+
+        # field map
+
+        ###### Definition
+
+        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.
+
+        ###### Nested field maps
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [first party](#h.uxx5bjam20ag)
+
+    -   ### ToIP
+
+        The [party](#h.cn6bno48fomj) who initiates a [trust relationship](#h.pu2asd79bqzo), [connection](#h.thbpewq1px8x), or [transaction](#h.92pu88ke4p7k) with a [second party](#h.hk94wskqnzri).
+
+        See also: [third party](#h.zu2vj8151tr), [fourth party](#h.ur40pjfb49t1).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [first seen](#first-seen)
+
+    -   ### WebOfTrust
+
+        # first seen
+
+        ###### Definition
+
+        A "First seen" event in KERI refers to the first event received by validator such as a witness and that 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.
+
+        ###### The rule
+
+        From the perspective of a validator, the rule is "First seen, always seen, never unseen".
+
+        ###### Key Compromise, Duplicity, and Recovery
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [foreign function interface](#foreign-function-interface)
+
+    -   ### WebOfTrust
+
+        # foreign function interface
+
+        ###### Definition
+
+        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)
+
+        ###### Relevance in CESR
+
+        To have the output from RUST-based developed (e.g. cesride) consumed by higher level languages.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [forgery](#forgery)
+
+    -   ### digital.govt.nz
+
+        the act of reproducing something for a deceitful or fraudulent purpose\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [foundational identity](#h.ig62zx2lc56o)
+
+    -   ### ToIP
+
+        A set of [identity data](#h.t3ho4tago38u), such as a [credential](#h.kcj6iw2vib1v), [issued](#h.xyrplzbvtffq) by an [authoritative source](#h.9tt1qpgdfnxs) for the [legal identity](#h.s0f760qh7yij) of the [subject](#h.voca6uuv1a4). Birth certificates, passports, driving licenses, and other forms of government ID documents are considered foundational [identity documents](#h.k7034pvtr21k). Foundational identities are often used to provide [identity binding](#h.kwudvu8h2zex) for [functional identities](#h.tk5si1lqyz9q).
+
+        Contrast with: [functional identity](#h.tk5si1lqyz9q).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [fourth party](#h.ur40pjfb49t1)
+
+    -   ### ToIP
+
+        A [party](#h.cn6bno48fomj) that is not directly involved in the trust relationship between a [first party](#h.uxx5bjam20ag) and a [second party](#h.hk94wskqnzri), but provides supporting services exclusively to the [first party](#h.uxx5bjam20ag) (in contrast with a [third party](#h.zu2vj8151tr), who in most cases provides supporting services to the [second party](#h.hk94wskqnzri)). In its strongest form, a [fourth party](#h.ur40pjfb49t1) has a [fiduciary](#h.5w05xlh4j8ms) relationship with the [first party](#h.uxx5bjam20ag).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [frame code](#frame-code)
+
+    -   ### WebOfTrust
+
+        # frame code
+
+        ###### See
+
+        [Group framing code](https://weboftrust.github.io/keridoc/docs/glossary/group-framing-code.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [full disclosure](#full-disclosure)
+
+    -   ### WebOfTrust
+
+        # full disclosure
+
+        ###### Definition
+
+        A disclosure of data in all its details.
+
+        When used in the context of [selective disclosure](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/partial-disclosure.md), full disclosure means _detailed disclosure of the [field map](https://weboftrust.github.io/keridoc/docs/glossary/field-map.md)_ that was so far only partially disclosed.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [fully compact](#fully-compact)
+
+    -   ### WebOfTrust
+
+        # fully compact
+
+        ###### definition
+
+        The most compact form of an ACDC. This is the only signed variant of an ACDC and this signature is anchored in a transaction event log (TEL) for the ACDC.This is one valid choice for an ACDC schema.
+        This form is part of the graduated disclosure mechanism in ACDCs.
+
+        ###### Anchoring to the TEL
+
+        The extra a fully compact version has to offer over a [most compact](https://weboftrust.github.io/keridoc/docs/glossary/most-compact.md) version is the anchoring to the [Tranaction event log](https://weboftrust.github.io/keridoc/docs/glossary/transaction-event-log.md). Here were various proofs ([hashes](https://weboftrust.github.io/keridoc/docs/glossary/distributed-hash-table.md)) can be "stored" which are optional in all kind of [ACDC](https://weboftrust.github.io/keridoc/docs/glossary/ACDC.md) variants.
+
+        ###### See
+
+        [Fully (expanded)](https://weboftrust.github.io/keridoc/docs/glossary/fully-expanded.md) version of an ACDC
+        [Most compact](https://weboftrust.github.io/keridoc/docs/glossary/most-compact.md) version of an ACDC.
+
+        ###### Analogy
+
+        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/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [fully expanded](#fully-expanded)
+
+    -   ### WebOfTrust
+
+        # fully expanded
+
+        ###### Definition
+
+        The most user-friendly version of an [ACDC](https://weboftrust.github.io/keridoc/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/keridoc/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.
+
+        ###### See also
+
+        [Fully compact(ed)](https://weboftrust.github.io/keridoc/docs/glossary/fully-compact.md) version of an ACDC
+        [Most compact](https://weboftrust.github.io/keridoc/docs/glossary/most-compact.md) version of an ACDC.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [functional identity](#h.tk5si1lqyz9q)
+
+    -   ### ToIP
+
+        A set of [identity data](#h.t3ho4tago38u), such as a [credential](#h.kcj6iw2vib1v), that is [issued](#h.xyrplzbvtffq) not for the purpose of establishing a [foundational identity](#h.ig62zx2lc56o) for the subject, but for the purpose of establishing other attributes, qualifications, or capabilities of the subject. Loyalty cards, library cards, and employee IDs are all examples of functional identities. [Foundational identities](#h.ig62zx2lc56o) are often used to provide [identity binding](#h.kwudvu8h2zex) for functional identities.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [gateway](#h.x6n84riqc6ll)
+
+    -   ### ToIP
+
+        A gateway is a piece of networking hardware or software used in telecommunications networks that allows [data](#h.o783ayrrkc6g) to flow from one discrete network to another. Gateways are distinct from [routers](#h.oqbqyf914pln) or switches in that they communicate using more than one protocol to connect multiple networks[\[1\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Gateway_\(telecommunications\)%23cite_note-1&sa=D&source=editors&ust=1718703186680622&usg=AOvVaw2SCSBdvdoEN26XC0TMnfYG)[\[2\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Gateway_\(telecommunications\)%23cite_note-2&sa=D&source=editors&ust=1718703186680842&usg=AOvVaw0tZeeETG0WZZFqXaavKvYl) and can operate at any of the seven layers of the open systems interconnection model (OSI).
+
+        See also: [intermediary](#h.p89mgcb8dbec).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Gateway_\(telecommunications\)&sa=D&source=editors&ust=1718703186681147&usg=AOvVaw3F2E3tpXb6JhbSPvyBeIyU).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ghost credential](#ghost-credential)
+
+    -   ### WebOfTrust
+
+        # ghost credential
+
+        ###### Definition
+
+        Is a valid credential within in a 90 days grace period (the revocation transaction time frame before it's booked to revocation registry). | TBW prio 3 |
+
+        ###### Design
+
+        When a relationship needs to be terminated with a [QVI](https://weboftrust.github.io/keridoc/docs/glossary/QVI.md) and the QVI has not revoked their credentials (yet) then those credentials become ghost credentials.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [gleif authorized representative](#gleif-authorized-representative)
+
+    -   ### WebOfTrust
+
+        # gleif authorized representative
+
+        ###### Definition
+
+        A representative of GLEIF authorized to perform the identity verifications requirements needed to issue the [QVI](https://weboftrust.github.io/keridoc/docs/glossary/QVI.md) [vLEI](https://weboftrust.github.io/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [glossary](#h.z1he49173rzw)
+
+    -   ### ToIP
+
+        A glossary (from Ancient Greek: γλῶσσα, glossa; language, speech, wording), also known as a vocabulary or clavis, is an alphabetical list of [terms](#h.ojn7uxdcaf7u) in a particular domain of [knowledge](#h.k96lktyswxnb) ([scope](#h.5cfb6xokygh4)) together with the [definitions](#h.beph188xy39q) for those terms. Unlike a [dictionary](#h.ajluzjr0e4sa), a glossary has only one [definition](#h.beph188xy39q) for each term.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Glossary&sa=D&source=editors&ust=1718703186682877&usg=AOvVaw1KEPBsT5C6tjp_NNDBZ1TA).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [gnu privacy guard](#gnu-privacy-guard)
+
+    -   ### WebOfTrust
+
+        # gnu privacy guard
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/PGP.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [governance](#h.mu68tj5xpknp)
+
+    -   ### ToIP
+
+        The [act](#h.gzdfngxkp0ip) or process of governing or overseeing the realization of (the results associated with) a set of [objectives](#h.k0v6ir8wmcav) by the [owner](#h.y450rpi0zmuu) of these [objectives](#h.k0v6ir8wmcav), in order to ensure they will be fit for the purposes that this [owner](#h.y450rpi0zmuu) intends to use them for.
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23governance&sa=D&source=editors&ust=1718703186683542&usg=AOvVaw2KItVEp2stATVuSXZLIpDb).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governance diamond](#h.i3i9gk48w4)
+
+    -   ### ToIP
+
+        A term that refers to the addition of a [governing body](#h.1wptecwzvuvz) to the standard [trust triangle](#h.n29niebkxky7) of [issuers](#h.xyrplzbvtffq), [holders](#h.64mptmm24w7u), and [verifiers](#h.xfewd7t01hu0) of [credentials](#h.kcj6iw2vib1v). The resulting combination of four [parties](#h.cn6bno48fomj) represents the basic structure of a [digital trust ecosystem](#h.h47f86smlz4y).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governance document](#h.c8fvvxachz5h)
+
+    -   ### ToIP
+
+        A document with at least one [identifier](#h.u3bfehmj4ed3) that specifies [governance requirements](#h.j4z5czk0dk8t) for a [trust community](#h.a9l3odcb1s29).
+
+        Note: A governance document is a component of a [governance framework](#h.2x05z0r097mn).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governance framework](#h.2x05z0r097mn)
+
+    -   ### ToIP
+
+        A collection of one or more [governance documents](#h.c8fvvxachz5h) published by the [governing body](#h.1wptecwzvuvz) of a [trust community](#h.a9l3odcb1s29).
+
+        Also known as: [trust framework](#h.2r5mn949idq).
+
+        Note: In the [digital identity](#h.r5y8zwxvzyd3) industry specifically, a governance framework is better known as a [trust framework](#h.2r5mn949idq). ToIP-conformant governance frameworks conform to the [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3) and follow the [ToIP Governance Metamodel](#h.rgnaglzbhy9v).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # governance framework
+
+        ###### Definition
+
+        Also called 'Governance structure'. Governance frameworks are the structure of a government and reflect the interrelated relationships, factors, and other influences upon the institution. Governance frameworks structure and delineate power and the governing or [management](https://en.wikipedia.org/wiki/Management) roles in an organization. They also set rules, procedures, and other informational guidelines.
+        More in [source](https://en.wikipedia.org/wiki/Governance_framework) Wikipedia.
+
+        ###### Related to GLEIF and vLEI
+
+        In addition, governance frameworks define, guide, and provide for enforcement of these processes. These frameworks are shaped by the goals, strategic mandates, financial incentives, and established power structures and processes of the organization.
+
+        Within GLEIF context, _governance frameworks_ manifest in a document that details the requirements for vLEI credentials.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [governance graph](#h.u9xnz96ecf5x)
+
+    -   ### ToIP
+
+        A graph of the [governance](#h.mu68tj5xpknp) relationships between [entities](#h.5imtbzl1f4xo) with a [trust community](#h.a9l3odcb1s29). A governance graph shows which [nodes](#h.w1aty8c036fp) are the [governing bodies](#h.1wptecwzvuvz) and which are the [governed parties](#h.c1jlj376y5m3). In some cases, a governance graph can be traversed by making queries to one or more [trust registries](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5kzln6m5e8j5&sa=D&source=editors&ust=1718703186686341&usg=AOvVaw2EHKAygpru6gduxqrXsD0G).Note: a [party](#h.cn6bno48fomj) can play both [roles](#h.sf54cyuamo6x) and also be a participant in multiple [governance frameworks](#h.2x05z0r097mn).
+
+        See also: [authorization graph](#h.5tvkchqqqka8), [reputation graph](#h.4wwkekt1wrs7), [trust graph](#h.eqx98nkqjzsv).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governance requirement](#h.j4z5czk0dk8t)
+
+    -   ### ToIP
+
+        A [requirement](#h.ajxlw8r3dvcc) such as a [policy](#h.udts41hso4w4), [rule](#h.v7s575ulon74), or [technical specification](#h.u62ak0cgfdb1) specified in a [governance document](#h.c8fvvxachz5h).
+
+        See also: [technical requirement](#h.l7t266ck3tjw).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governed information](#h.g58y5pmth1sb)
+
+    -   ### ToIP
+
+        Any information published under the authority of a [governing body](#h.1wptecwzvuvz) for the purpose of governing a [trust community](#h.a9l3odcb1s29). This includes its [governance framework](#h.2x05z0r097mn) and any information available via an authorized [trust registry](#h.5kzln6m5e8j5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governed party](#h.c1jlj376y5m3)
+
+    -   ### ToIP
+
+        A [party](#h.cn6bno48fomj) whose [role(s)](#h.sf54cyuamo6x) in a [trust community](#h.a9l3odcb1s29) is governed by the [governance requirements](#h.j4z5czk0dk8t) in a [governance framework](#h.2x05z0r097mn).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governed use case](#h.64z12c84k1b)
+
+    -   ### ToIP
+
+        A use case specified in a [governance document](#h.c8fvvxachz5h) that results in specific [governance requirements](#h.j4z5czk0dk8t) within that [governance framework](#h.2x05z0r097mn). Governed use cases may optionally be discovered via a [trust registry](#h.5kzln6m5e8j5) authorized by the relevant [governance framework](#h.2x05z0r097mn).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governing authority](#h.hhkhnnadzpo1)
+
+    -   ### ToIP
+
+        See: [governing body](#h.1wptecwzvuvz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [governing body](#h.1wptecwzvuvz)
+
+    -   ### ToIP
+
+        The [party](#h.cn6bno48fomj) (or set of [parties](#h.cn6bno48fomj)) authoritative for governing a [trust community](#h.a9l3odcb1s29), usually (but not always) by developing, publishing, maintaining, and enforcing a [governance framework](#h.2x05z0r097mn). A governing body may be a government, a formal legal entity of any kind, an informal group of any kind, or an individual. A governing body may also delegate operational responsibilities to an [administering body](#h.w8r6jg7mkdaj).
+
+        Also known as: [governing authority](#h.hhkhnnadzpo1).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [graduated disclosure](#graduated-disclosure)
+
+    -   ### WebOfTrust
+
+        # graduated disclosure
+
+        ###### Definition
+
+        Lifting confidentiality step by step: Selectively disclosing more data as time and/or necessity progresses, offering backwards verifiability of earlier issued cryptographic proofs.
+
+        ###### Example
+
+        You proof your insurance policy without disclosing details, before enjoying extreme sports. Only when something goes wrong, e.g. 1 in a 100, you disclose the data. This way confidentiality is kept in 99% of the cases.
+
+        ###### KERI specific
+
+        Disclosure performed by a presentation exchange that has cross-variant (see [compact variant](https://weboftrust.github.io/keridoc/docs/glossary/compact-variant.md)) Issuer commitment verifiability as an essential property. It supports graduated disclosure by the [Disclosee](https://weboftrust.github.io/keridoc/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)
+
+        ###### Reuse
+
+        The [SAID](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/issuer.md) signed because during graduated disclosure the [Discloser](https://weboftrust.github.io/keridoc/docs/glossary/discloser.md) MAY choose to sign that given variant to fulfil a given step in an IPEX graduated disclosure transaction.
+
+        ###### Rule
+
+        The disclosure performed by a presentation exchange MAY be [graduated](https://weboftrust.github.io/keridoc/docs/glossary/graduated-disclosure.md) and MAY be [contractually](https://weboftrust.github.io/keridoc/docs/glossary/contractually-protected-disclosure.md) protected.
+
+        ###### Related terms
+
+        -   [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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [graph fragment](#graph-fragment)
+
+    -   ### WebOfTrust
+
+        # graph fragment
+
+        ###### Definition
+
+        An ACDC is a verifiable data structure and _part of a graph_, consisting of a node property and one or two edge proporties.
+
+        ![](https://hackmd.io/_uploads/r1KDqKxzj.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [group code](#group-code)
+
+    -   ### WebOfTrust
+
+        # group code
+
+        ###### See
+
+        [Group framing code](https://weboftrust.github.io/keridoc/docs/glossary/group-framing-code.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [group framing code](#group-framing-code)
+
+    -   ### WebOfTrust
+
+        # group framing code
+
+        ###### Definition
+
+        special framing codes can be specified to support groups of [primitives](https://weboftrust.github.io/keridoc/docs/glossary/primitive.md) in [CESR](https://weboftrust.github.io/keridoc/docs/glossary/composable-event-streaming-representation.md). Grouping enables [pipelining](https://weboftrust.github.io/keridoc/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)
+
+        ###### Composability property
+
+        One of the primary advantages of composable encoding is that we can use special framing code to support the above mentioned grouping.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [guardian](#h.y3s9f56kpets)
+
+    -   ### ToIP
+
+        A [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186689289&usg=AOvVaw0Qr1YU-9fd4agGK19qlIVC) that has been assigned rights and duties in a [guardianship arrangement](#h.tc250ixnd67w) for the purpose of caring for, protecting, guarding, and defending the [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186689578&usg=AOvVaw10l-CAhS2Nn7A1VLBA_pEq) that is the [dependent](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/dependent&sa=D&source=editors&ust=1718703186689787&usg=AOvVaw1IN-LXZb8T2t3_AyqiUfVo) in that [guardianship arrangement](#h.tc250ixnd67w). In the context of decentralized digital trust infrastructure, a guardian is issued [guardianship credentials](#h.mjrnala919ld) into their own [digital wallet](#h.sxnvf3f5v156) in order to perform such [actions](#h.l54nzmooy631) on behalf of the [dependent](#h.qvhbv3ov9zmy) as are required by this [role](#h.sf54cyuamo6x).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23guardian&sa=D&source=editors&ust=1718703186690285&usg=AOvVaw0apt2EiH0rZVERiDi6EoLK)
+
+        See also: [custodian](#h.8kx1mv7y64ps), [zero-knowledge service provider](#h.qhfq42vp7l55).
+
+        Mental Model: [eSSIF-Lab Guardianship](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/pattern-guardianship&sa=D&source=editors&ust=1718703186690665&usg=AOvVaw0ADOU217b-pX6O-6VfharF)
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_guardian&sa=D&source=editors&ust=1718703186690970&usg=AOvVaw0GKORujHmWNmnvrUTyqmiD): A legal guardian is a person who has been appointed by a court or otherwise has the legal authority (and the corresponding [duty](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Duty&sa=D&source=editors&ust=1718703186691172&usg=AOvVaw2Le1apnR4F6vtR9hQ7C9Ex)) to make decisions relevant to the personal and [property](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Property&sa=D&source=editors&ust=1718703186691394&usg=AOvVaw3r1MnLoeF-UybfLYT0OdeU) interests of another person who is deemed incompetent, called a [ward](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Ward_\(law\)&sa=D&source=editors&ust=1718703186691597&usg=AOvVaw1zRp3QLw7DNONg8dxHK6lx).
+
+        For more information, see: [On Guardianship in Self-Sovereign Identity V2.0](https://www.google.com/url?q=https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf&sa=D&source=editors&ust=1718703186691823&usg=AOvVaw3jfhBDorL-ZgeqzQ8BwA4e) (April, 2023).
+
+        Note: A guardian is a very different role than a [custodian](#h.8kx1mv7y64ps), who does not take any [actions](#h.l54nzmooy631) on behalf of a [principal](#h.sydbe7rk6244) unless explicitly [authorized](#h.gln5i78kxlfh).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [guardianship arrangement](#h.tc250ixnd67w)
+
+    -   ### ToIP
+
+        A guardianship arrangement (in a [jurisdiction](#h.uw2s3y6sjzjf)) is the specification of a set of rights and duties between [legal entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/legal-entity&sa=D&source=editors&ust=1718703186692447&usg=AOvVaw0rLDryxbsdJmvxNszHcwAG) of the [jurisdiction](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/jurisdiction&sa=D&source=editors&ust=1718703186692611&usg=AOvVaw0T82Us93E6rZ7i4wfV_d9o) that enforces these rights and duties, for the purpose of caring for, protecting, guarding, and defending one or more of these [entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/legal-entity&sa=D&source=editors&ust=1718703186692766&usg=AOvVaw1gF8qnBKk79OTuKvMdY9VH). At a minimum, the entities participating in a guardianship arrangement are the [guardian](#h.y3s9f56kpets) and the [dependent](#h.qvhbv3ov9zmy).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23guardian&sa=D&source=editors&ust=1718703186693069&usg=AOvVaw34TWEwIEOhBxH0ZopN1CSz)
+
+        See also: [custodianship arrangement](#h.4hh9dvbp6177).
+
+        Mental Model: [eSSIF-Lab Guardianship](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/pattern-guardianship&sa=D&source=editors&ust=1718703186693382&usg=AOvVaw1R7NnFXHnmjTL8ty54F0jW)
+
+        For more information, see: [On Guardianship in Self-Sovereign Identity V2.0](https://www.google.com/url?q=https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf&sa=D&source=editors&ust=1718703186693672&usg=AOvVaw1NNFISQUbhcEqly5ttxxvz) (April, 2023).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [guardianship credential](#h.mjrnala919ld)
+
+    -   ### ToIP
+
+        A [digital credential](#h.ddna9lucn4k6) [issued](#h.xyrplzbvtffq) by a [governing body](#h.1wptecwzvuvz) to a [guardian](#h.y3s9f56kpets) to empower the [guardian](#h.y3s9f56kpets) to undertake the rights and duties of a [guardianship arrangement](#h.tc250ixnd67w) on behalf of a [dependent](#h.qvhbv3ov9zmy).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [hab](#hab)
+
+    -   ### WebOfTrust
+
+        # hab
+
+        ###### Definition
+
+        A Hab is a keystore for one identifier. The Python implementation in [KERIpy](https://weboftrust.github.io/keridoc/docs/glossary/keripy.md), also used by [KERIA](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/habery.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [habery](#habery)
+
+    -   ### WebOfTrust
+
+        # habery
+
+        ###### Definition
+
+        'Hab' comes from ‘Habitat’. It’s a place where multi-sigs and AIDs are linked. Habery manages a collection of Habs. A Hab is a datastructure (a Python object).
+
+        | TBW |-prio2
+
+        ###### Beware
+
+        The only hit (2022) in a Google search pointing to a github site 'habery DOT github DOT io' is NOT related.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [hardware security module](#h.vs7ugzdzujtz)
+
+    -   ### ToIP
+
+        A physical computing device that provides tamper-evident and intrusion-resistant safeguarding and management of digital [keys](#h.53rzpn1yn6q7) and other secrets, as well as crypto-processing.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/hardware_security_module_hsm&sa=D&source=editors&ust=1718703186694601&usg=AOvVaw1OvO8id3fDQS_8fTkEFEbv).
+
+        Also known as: [HSM](#h.jj97g1z2zrr8).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/hardware_security_module_hsm&sa=D&source=editors&ust=1718703186695020&usg=AOvVaw2-0IIUzwh-pnnF8OPv6LU-): A physical computing device that provides tamper-evident and intrusion-resistant safeguarding and management of digital keys and other secrets, as well as crypto-processing. FIPS 140-2 specifies requirements for HSMs.
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Hardware_security_module&sa=D&source=editors&ust=1718703186695308&usg=AOvVaw3M_GSdcKE0_33SwGB9mKP7): A physical computing device that safeguards and manages secrets (most importantly [digital keys](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_keys&sa=D&source=editors&ust=1718703186695472&usg=AOvVaw3WMIKkKcgSEtG7bFwbfiOW)), performs [encryption](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Encryption&sa=D&source=editors&ust=1718703186695662&usg=AOvVaw0gMNB6ORVYBatjSCxJe2MP) and decryption functions for [digital signatures](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_signature&sa=D&source=editors&ust=1718703186695862&usg=AOvVaw2e9NhEjuecyO78r0u5y_vY), [strong authentication](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Strong_authentication&sa=D&source=editors&ust=1718703186696034&usg=AOvVaw0QbifaDKgN4KslutZS6aNb) and other cryptographic functions. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a [computer](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer&sa=D&source=editors&ust=1718703186696187&usg=AOvVaw37IVC14EjH0VCLlm8P1IN_) or [network server](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Server_\(computing\)&sa=D&source=editors&ust=1718703186696363&usg=AOvVaw3BtqNNWp4E9PP7tRZKeDHF). A hardware security module contains one or more [secure cryptoprocessor](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Secure_cryptoprocessor&sa=D&source=editors&ust=1718703186696511&usg=AOvVaw1u98tFu4TRraMh29uxkOwS) [chips](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Integrated_circuit&sa=D&source=editors&ust=1718703186696650&usg=AOvVaw2wpNG4_MG912rZ0qlx9OrW).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # hardware security module
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/authenticity.md) and other cryptographic functions.
+        More in source [Wikipedia](https://en.wikipedia.org/wiki/Hardware_security_module)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [hash](#h.otz98gjrt2s)
+
+    -   ### ToIP
+
+        The result of applying a [hash function](#h.q2vi1qb2i4z) to a [message](#h.bge7ubygwk2q).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/hash_value&sa=D&source=editors&ust=1718703186697163&usg=AOvVaw3Zx9D54llQewyys5LCv-NT).
+
+        Also known as: hash output, hash result, hash value.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [hash function](#h.q2vi1qb2i4z)
+
+    -   ### ToIP
+
+        An algorithm that computes a numerical value (called the [hash value](#h.otz98gjrt2s)) on a [data](#h.o783ayrrkc6g) file or electronic [message](#h.bge7ubygwk2q) that is used to represent that file or message, and depends on the entire contents of the file or message. A hash function can be considered to be a fingerprint of the file or message. Approved hash functions satisfy the following properties: one-way (it is computationally infeasible to find any input that maps to any pre-specified output); and collision resistant (it is computationally infeasible to find any two distinct inputs that map to the same output).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/hash_function&sa=D&source=editors&ust=1718703186697908&usg=AOvVaw3HDpwive2IH4ItGFAcZhEm).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [hierarchical asynchronous coroutines and input output](#hierarchical-asynchronous-coroutines-and-input-output)
+
+    -   ### WebOfTrust
+
+        # hierarchical asynchronous coroutines and input output
+
+        ###### Definition
+
+        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).
+
+        ##### More info on Github
+
+        [Repo ioflo hio](https://github.com/ioflo/hio)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [hierarchical composition](#hierarchical-composition)
+
+    -   ### WebOfTrust
+
+        # hierarchical composition
+
+        ###### Definition
+
+        Encoding protocol that is composable in a hierarchy and enables [pipelining](https://weboftrust.github.io/keridoc/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.
+
+        ###### Example
+
+        | TBW prio2 |
+
+        ###### CESR related
+
+        Because of [count codes](https://weboftrust.github.io/keridoc/docs/glossary/count-code.md) and the [composability](https://weboftrust.github.io/keridoc/docs/glossary/composability.md) - and [concatenation](https://weboftrust.github.io/keridoc/docs/glossary/concatenation.md) property in CESR, [pipelining](https://weboftrust.github.io/keridoc/docs/glossary/pipelining.md) is possible, which then uses [multiplexing](https://weboftrust.github.io/keridoc/docs/glossary/multiplexing.md) (combining [self-framing](https://weboftrust.github.io/keridoc/docs/glossary/self-framing.md) primitives) and _de-multiplexing_ (unravelling self-framing [primitives](https://weboftrust.github.io/keridoc/docs/glossary/primitive.md)).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [hierchical deterministic keys](#hierchical-deterministic-keys)
+
+    -   ### WebOfTrust
+
+        # hierchical deterministic keys
+
+        ###### Definition
+
+        A HDK type is a type of deterministic bitcoin wallet derived from a known [seed](https://weboftrust.github.io/keridoc/docs/glossary/seed.md), that allow for the creation of child keys from the parent key. Because the child key is generated from a known seed there is a relationship between the child and parent keys that 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, providing the functionality of being able 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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [hio](#hio)
+
+    -   ### WebOfTrust
+
+        # hio
+
+        ###### Definition
+
+        Weightless hierarchical asynchronous coroutines and I/O in Python.
+        Rich Flow Based Programming Hierarchical Structured Concurrency with Asynchronous IO.
+
+        ###### More on Github
+
+        This very technical topic can best be studied further at the Github [Repository](https://github.com/ioflo/hio)
+
+        ###### Relation to KERI
+
+        Choosing HIO complies with the asynchronous nature of KERI, the minimal sufficient means design principle of KERI and the leading KERIpy implementation.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [holder (of a claim or credential)](#h.64mptmm24w7u)
+
+    -   ### ToIP
+
+        A [role](#h.sf54cyuamo6x) an [agent](#h.6xkhfkjpo6xg) performs by serving as the [controller](#h.gemoqe2m303z) of the [cryptographic keys](#h.53rzpn1yn6q7) and [digital](#h.ddna9lucn4k6) [credentials](#h.ddna9lucn4k6) in a [digital wallet](#h.sxnvf3f5v156). The holder makes [issuance requests](#h.tt253lgfp4hz) for [credentials](#h.kcj6iw2vib1v) and responds to [presentation requests](#h.onnn49cjzreh) for [credentials](#h.kcj6iw2vib1v). A holder is usually, but not always, a [subject](#h.voca6uuv1a4) of the [credentials](#h.kcj6iw2vib1v) they are holding.
+
+        See also: [issuer](#h.xyrplzbvtffq), [verifier](#h.xfewd7t01hu0).
+
+        Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186699012&usg=AOvVaw36lfrdGNtzdzeXTFRtKyfU)
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/holder&sa=D&source=editors&ust=1718703186699345&usg=AOvVaw0iKDhH3rj1sXzi6MlBv0hW): a component that implements the [capability](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/capability&sa=D&source=editors&ust=1718703186699570&usg=AOvVaw1aSsFU8iyMNbsbxNqfosAc) to handle [presentation requests](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/presentation-request&sa=D&source=editors&ust=1718703186699768&usg=AOvVaw1V7qwAUoRQBFq9J0Zc7-ia) from a [peer agent](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/peer-agent&sa=D&source=editors&ust=1718703186699923&usg=AOvVaw2tvMvWoYBi8hS5KORm_-SA), produce the requested data (a presentation) according to its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186700080&usg=AOvVaw00DGEPQeHjwPcS2ibCCMeU)'s [holder-policy](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/holder-policy&sa=D&source=editors&ust=1718703186700273&usg=AOvVaw0kgntv62GRx7PUurx3DISN), and send that in response to the request.
+
+        [W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-holders&sa=D&source=editors&ust=1718703186700461&usg=AOvVaw1UwDt1ej0MsLzVXA-zOemJ): A role an [entity](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-entities&sa=D&source=editors&ust=1718703186700657&usg=AOvVaw3lJq3C2jTFhPY3QYXWjXes) might perform by possessing one or more [verifiable credentials](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186700816&usg=AOvVaw1QVJm6LbUsjf25M0H1egX6) and generating [presentations](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-presentations&sa=D&source=editors&ust=1718703186700958&usg=AOvVaw0PFu2nFZlXm-rjR-JX9XZC) from them. A holder is usually, but not always, a [subject](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-subjects&sa=D&source=editors&ust=1718703186701137&usg=AOvVaw3M1YqtMel9pKUGD60ib40M) of the [verifiable credentials](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186701329&usg=AOvVaw2m0K8RovojAaGWUjn2yeD8) they are holding. Holders store their [credentials](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-credential&sa=D&source=editors&ust=1718703186701490&usg=AOvVaw0KfCb_-KvqGfywrLm18huM) in [credential repositories](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-credential-repository&sa=D&source=editors&ust=1718703186701677&usg=AOvVaw0MQSRkD7TD4xhdoKtUunSq).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [holder binding](#h.rz5xcharat07)
+
+    -   ### ToIP
+
+        The process of creating and verifying a relationship between the [holder](#h.64mptmm24w7u) of a [digital wallet](#h.sxnvf3f5v156) and the wallet itself. Holder binding is related to but NOT the same as subject binding.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [host](#h.3f5tvermqc9k)
+
+    -   ### ToIP
+
+        A host is any hardware device that has the capability of permitting access to a network via a user interface, specialized software, [network address](#h.v9gosdu5b7z5), [protocol stack](#h.6ik2cef0ipsr), or any other means. Some examples include, but are not limited to, computers, personal electronic devices, thin clients, and multi-functional devices.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/host&sa=D&source=editors&ust=1718703186702427&usg=AOvVaw2mZe-r6ziul1y8LYWGOGle).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Host_\(network\)&sa=D&source=editors&ust=1718703186702656&usg=AOvVaw1QZ54xHiY7Mb8dQDGA-nUO): A network host is a [computer](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer&sa=D&source=editors&ust=1718703186702790&usg=AOvVaw2MbLiZ0ZZx4OzFtZoIO8Yk) or other device connected to a [computer network](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_network&sa=D&source=editors&ust=1718703186702938&usg=AOvVaw0u2Usa7MUnmz0EmxdYMtgI). A host may work as a [server](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Server_\(computing\)&sa=D&source=editors&ust=1718703186703132&usg=AOvVaw3TlO0R3iWhyUBwkQrocmbc) offering information resources, services, and applications to users or other hosts on the network. Hosts are assigned at least one [network address](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Network_address&sa=D&source=editors&ust=1718703186703290&usg=AOvVaw0FTkjxbo3fgHwKiteI-HG5). A computer participating in networks that use the [Internet protocol suite](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_protocol_suite&sa=D&source=editors&ust=1718703186703438&usg=AOvVaw3d22hYZQe7jcYgSS9cEVQb) may also be called an IP host. Specifically, computers participating in the [Internet](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet&sa=D&source=editors&ust=1718703186703598&usg=AOvVaw1XdyLAtdTfkUVJrs-mGqzl) are called Internet hosts. Internet hosts and other IP hosts have one or more [IP addresses](https://www.google.com/url?q=https://en.wikipedia.org/wiki/IP_address&sa=D&source=editors&ust=1718703186703735&usg=AOvVaw2hryOFkmVLRB1Mksd1_iTT) assigned to their network interfaces.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### ToIP (DID:Webs)
+
+        The part of a URL that can be either a domain name or an IP address. This component specifies the server that the client needs to communicate with in order to access the desired resource on the web.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [hourglass model](#h.u8d1rxc2o86)
+
+    -   ### ToIP
+
+        An architectural model for layered systems—and specifically for the [protocol layers](#h.pe8dekl2dtq0) in a [protocol stack](#h.6ik2cef0ipsr)—in which a diversity of supporting protocols and services at the lower layers are able to support a great diversity of protocols and applications at the higher layers through the use of a single protocol in the [spanning layer](#h.wf49e15shob9) in the middle—the “neck” of the hourglass.
+
+        See also: [trust spanning protocol](#h.fnuaao3a1j25).
+
+        For more information, see: [https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf](https://www.google.com/url?q=https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf&sa=D&source=editors&ust=1718703186704312&usg=AOvVaw1rLPgu0c2r-q6-RWGwgQ6i) and [https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/abstract](https://www.google.com/url?q=https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/abstract&sa=D&source=editors&ust=1718703186704488&usg=AOvVaw29G-gqCzyU4nwKRKT6_prd) 
+
+        Note: The Internet’s [TCP/IP stack](#h.txn6vkany9z9) follows the hourglass model, and it is the design model for the [ToIP stack](#h.wms58fgdch9m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [human auditability](#h.g4qotp7yir9x)
+
+    -   ### ToIP
+
+        See: [human auditable](#h.22bo41j3q290).
+
+        Contrast with: [cryptographic verifiability](#h.lbqfpvfmcmoq).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [human auditable](#h.22bo41j3q290)
+
+    -   ### ToIP
+
+        A process or procedure whose [compliance](#h.r0iiayz1za1i) with the [policies](#h.udts41hso4w4) in a [trust framework](#h.2r5mn949idq) or [governance framework](#h.2x05z0r097mn) can only be [verified](#h.k2qmzn3tjzsl) by a human performing an [audit](#h.3gz7xw796mvp). Human auditability is a primary goal of the [ToIP Governance Stack](#h.ciwa0pidrb2e).
+
+        Contrast with: [cryptographically verifiable](#h.422iwwfur12).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [human experience](#h.p2mpipjsl834)
+
+    -   ### ToIP
+
+        The processes, patterns and rituals of acquiring [knowledge](#h.k96lktyswxnb) or skill from doing, seeing, or feeling things as a [natural person.](#h.yx4qb6dcjdvj) In the context of decentralized digital trust infrastructure, the direct experience of a [natural person](#h.yx4qb6dcjdvj) using [trust applications](#h.3pfn27y1gu2o) to make [trust decisions](#h.m8c86ccqis9r) within one or more [digital trust ecosystems](#h.h47f86smlz4y).
+
+        Note: Human experience includes social experiences (e.g., rituals, behaviors, ceremonies and rites of passage), as well as customer experience, worker or employee experience, and user experience.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [human trust](#h.a4jfn38wd17o)
+
+    -   ### ToIP
+
+        A [level of assurance](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.qseghs6dqcd&sa=D&source=editors&ust=1718703186706977&usg=AOvVaw01wRN6cKieimrFCcIh8gAy) in a [trust relationship](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.pu2asd79bqzo&sa=D&source=editors&ust=1718703186707327&usg=AOvVaw3J-DXT0-JWLTjc8nWcLUkM) that can be achieved only via human evaluation of applicable [trust](#h.sdrgtm7bwb51) factors.
+
+        Contrast with: [technical](#h.7vxscxecc0g) [trust](#h.7vxscxecc0g).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [human-readable](#h.ywyofmy4do4t)
+
+    -   ### ToIP
+
+        Information that can be processed by a human but that is not intended to be [machine-readable](#h.8s3s84fzcfi3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [icp](#icp)
+
+    -   ### WebOfTrust
+
+        # icp
+
+        ###### Definition
+
+        icp = incept, inception
+
+        [Learn more](https://kerisse.org)
+
+-   ## [identification](#identification)
+
+    -   ### digital.govt.nz
+
+        the act of identifying or the state of being identified\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        The [action](#h.l54nzmooy631) of a [party](#h.cn6bno48fomj) obtaining the set of [identity data](#h.t3ho4tago38u) necessary to serve as that [party’s](#h.cn6bno48fomj) [identity](#h.z1gairv0pej5) for a specific [entity](#h.5imtbzl1f4xo).
+
+        Note: The act of identification of a specific [entity](#h.5imtbzl1f4xo) is relational to each [party](#h.cn6bno48fomj) that needs to perform that action. Therefore each party may end up with their own set of [identity data](#h.t3ho4tago38u) that meets their specific [requirements](#h.ajxlw8r3dvcc) for their specific [scope](#h.5cfb6xokygh4).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [identifier](#identifier)
+
+    -   ### digital.govt.nz
+
+        information that is enough to uniquely represent an entity in a given context\[Source: New definition\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        A single [attribute](#h.ky5nh3yri7ak)—typically a character string—that uniquely identifies an [entity](#h.5imtbzl1f4xo) within a specific context (which may be a global context). Examples include the name of a [party,](#h.cn6bno48fomj) the URL of an [organization](#h.z27mp1358pi9), or a serial number for a [man-made thing](#h.98jmqz1068vj).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23identifier&sa=D&source=editors&ust=1718703186708955&usg=AOvVaw1q1icZ0GOaGmcY87McCq5F): a character string that is being used for the identification of some [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186709188&usg=AOvVaw3EkN-jN5soZH6OtSH3iOtc) (yet may refer to 0, 1, or more [entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186709395&usg=AOvVaw0e1ol5KrbHXw_0I8f4IB0-), depending on the context within which it is being used).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # identifier
+
+        ###### Definition
+
+        Something to uniquely identify (public) identities; pointing to something or someone else.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [identifier system](#identifier-system)
+
+    -   ### WebOfTrust
+
+        # identifier system
+
+        ###### Definition
+
+        a system for uniquely identifying (public) identities
+
+        ##### Example identifier system
+
+        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)
+
+        ##### The properties of an identifier system:
+
+        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)
+
+        ##### Relationship with KERI / ACDC plus example vLEI
+
+        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.
+
+        ###### A first implementation of KERI and ACDC has been at GLEIF (.org)
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [identity](#identity)
+
+    -   ### digital.govt.nz
+
+        one or more attributes that allow an entity record to be unique from all others in the contextAdditional noteNote 1: Due to the contextual nature of the attributes that make up an identity and its poor interaction with other words, use of the word identity as a descriptor should be avoided wherever possible.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### Nist
+
+        Unique group element \\(0\\) for which \\(x+0=x\\) for each group element \\(x\\), relative to the binary group operator \\(+\\).
+
+        [Learn more](https://csrc.nist.gov/glossary/term/identity)
+
+    -   ### ToIP
+
+        A collection of [attributes](#h.ky5nh3yri7ak) or other [identity data](#h.t3ho4tago38u) that describe an [entity](#h.5imtbzl1f4xo) and enable it to be distinguished from all other [entities](#h.5imtbzl1f4xo) within a specific [scope](#h.5cfb6xokygh4) of [identification](#h.fslz9gxdlb84). Identity attributes may include one or more [identifiers](#h.u3bfehmj4ed3) for an [entity](#h.5imtbzl1f4xo), however it is possible to establish an identity without using [identifiers](#h.u3bfehmj4ed3).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23identity&sa=D&source=editors&ust=1718703186710132&usg=AOvVaw0H5ENOWIImaCNw8HDPAbRy): the combined [knowledge](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/knowledge&sa=D&source=editors&ust=1718703186710329&usg=AOvVaw1-XYPGzz_bPPB6ME7YkE6L) about that [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186710477&usg=AOvVaw1-J5cmK82VByApdvfSibqf) of all [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186710626&usg=AOvVaw10-MGxjt_0ovgcoYbfxAsZ), i.e. the union of all [partial identities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/partial-identity&sa=D&source=editors&ust=1718703186710781&usg=AOvVaw1b_BUEZz6Am9OOMqepKEK4) of which that [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186710930&usg=AOvVaw3ZE8wkmfvuNgGcMJpVoW9-) is the [subject](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/subject&sa=D&source=editors&ust=1718703186711086&usg=AOvVaw0BmaiJx2PPtx8sI8AFM1Ti).
+
+        Note: Identity is relational to the [party](#h.cn6bno48fomj) performing the identification. For example, if 100 different [parties](#h.cn6bno48fomj) have an identity for the same [entity](#h.5imtbzl1f4xo), each of them may hold a different set of [identity data](#h.t3ho4tago38u) enabling identification of that [entity](#h.5imtbzl1f4xo).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # identity
+
+        ###### Definition
+
+        A unique entity. Typically represented by a unique [identifier](https://weboftrust.github.io/keridoc/docs/glossary/identifier.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [identity assurance](#identity-assurance)
+
+    -   ### WebOfTrust
+
+        # identity assurance
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/GLEIF.md). Instead, KERI is for [attributional trust](https://weboftrust.github.io/keridoc/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)
+
+        ###### Out-of-band
+
+        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/keridoc/docs/glossary/out-of-band-introduction.md)s (OOBIs) to establish attributional trust, which is done with KERI.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [identity assurance level](#h.udr0qmo2ubln)
+
+    -   ### ToIP
+
+        A category that conveys the degree of confidence that a person’s claimed [identity](#h.z1gairv0pej5) is their real [identity](#h.z1gairv0pej5), for example as defined in [NIST SP 800-63-3](https://www.google.com/url?q=https://pages.nist.gov/800-63-3/sp800-63-3.html&sa=D&source=editors&ust=1718703186711847&usg=AOvVaw22RQ2oq0cKO0BNkz5oXjOF) in terms of three levels: IAL 1 (Some confidence), IAL 2 (High confidence), IAL 3 (Very high confidence).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/identity_assurance_level&sa=D&source=editors&ust=1718703186712148&usg=AOvVaw1FHhgJfsv2Gym7v2nZUFHe).
+
+        See also: [authenticator assurance level](#h.a7560ebfrt4m), [federation assurance level](#h.8fhj7rpnpjy3).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [identity binding](#h.kwudvu8h2zex)
+
+    -   ### ToIP
+
+        The process of associating a set of [identity data](#h.t3ho4tago38u), such as a [credential](#h.kcj6iw2vib1v), with its [subject](#h.voca6uuv1a4), such as a [natural person](#h.yx4qb6dcjdvj). The strength of an identity binding is one factor in determining an [authenticator assurance level](#h.a7560ebfrt4m).
+
+        See also: [identity assurance level](#h.udr0qmo2ubln), [identity proofing](#h.8o667cv8194w).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [identity data](#h.t3ho4tago38u)
+
+    -   ### ToIP
+
+        The set of [data](#h.o783ayrrkc6g) held by a [party](#h.cn6bno48fomj) in order to provide an [identity](#h.z1gairv0pej5) for a specific [entity](#h.5imtbzl1f4xo).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [identity document](#h.k7034pvtr21k)
+
+    -   ### ToIP
+
+        A physical or digital document containing [identity data](#h.t3ho4tago38u). A [credential](#h.kcj6iw2vib1v) is a specialized form of identity document. Birth certificates, bank statements, and utility bills can all be considered identity documents.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [identity proofing](#h.8o667cv8194w)
+
+    -   ### ToIP
+
+        The process of a [party](#h.cn6bno48fomj) gathering sufficient [identity data](#h.t3ho4tago38u) to establish an [identity](#h.z1gairv0pej5) for a particular [subject](#h.voca6uuv1a4) at a particular [identity assurance level](#h.udr0qmo2ubln).
+
+        See also: [identity binding](#h.kwudvu8h2zex).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/identity_proofing&sa=D&source=editors&ust=1718703186714697&usg=AOvVaw3hYVBEnFJimCcDBNUyG7vi): The process of providing sufficient information (e.g., identity history, credentials, documents) to establish an identity.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [identity provider](#h.m9zmriuoidyt)
+
+    -   ### ToIP
+
+        An identity provider (abbreviated IdP or IDP) is a system [entity](#h.5imtbzl1f4xo) that creates, maintains, and manages [identity](#h.z1gairv0pej5) information for [principals](#h.sydbe7rk6244) and also provides [authentication](#h.gp553sxzbmv1) services to relying applications within a [federation](#h.7ph0icfh463b) or distributed network.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Identity_provider&sa=D&source=editors&ust=1718703186715254&usg=AOvVaw29kbcz0D5tUAJLC4M8slQm).
+
+        Note: The term “identity provider” is used in [federated identity](#h.cb1le64hx6h5) systems because it is a required component of their architecture. By contrast, [decentralized identity](#h.xodo7ytn4cx2) and [self-sovereign identity](#h.wdojy63bltd4) systems do not use the term because they are architected to enable [entities](#h.5imtbzl1f4xo) to create and control their own [digital identities](#h.r5y8zwxvzyd3) without the need to depend on an external provider.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [identity theft](#identitytheft)
+
+    -   ### digital.govt.nz
+
+        the theft or assumption of a pre-existing identity (or significant part thereof) with or without consent, and, whether, in the case of an individual, the person is living or deceased\[Source: Australian Centre for Policing Research\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [impersonation](#h.rifdelabky9n)
+
+    -   ### ToIP
+
+        In the context of cybersecurity, impersonation is when an attacker pretends to be another person in order to commit fraud or some other digital crime.
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Impersonator&sa=D&source=editors&ust=1718703186716010&usg=AOvVaw36rFjuuiZYvKFPPmMc2xyR): An impersonator is someone who imitates or copies the behavior or actions of another. As part of a [criminal act](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Crime&sa=D&source=editors&ust=1718703186716158&usg=AOvVaw2SHh7LeBDlV6AvWOmNkgRT) such as [identity theft](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Identity_theft&sa=D&source=editors&ust=1718703186716303&usg=AOvVaw045WR2A1JHRT5pkoXEEUl8), the criminal is trying to assume the identity of another, in order to commit [fraud](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Fraud&sa=D&source=editors&ust=1718703186716455&usg=AOvVaw12AHcSoiwoR7qp9H-HTvuy), such as accessing confidential information, or to gain property not belonging to them. Also known as [social engineering](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Social_engineering_\(security\)&sa=D&source=editors&ust=1718703186716662&usg=AOvVaw3JMRy0z8BslQ-4YVbB9saw) and [impostors](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Impostor&sa=D&source=editors&ust=1718703186716831&usg=AOvVaw0gh729IrOV-BPW4yMHeH91).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [inception](#inception)
+
+    -   ### WebOfTrust
+
+        # inception
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [inception event](#inceptionevent)
+
+    -   ### ToIP (DID:Webs)
+
+        A key event that provides the incepting information needed to derive an AID and establish its initial key state, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # inception event
+
+        ###### Definition
+
+        An inception event is an establishment key event that represents the creation operation of anidentifier including its derivation and its initial set of controlling keys as well as other inceptionor configuration data for supporting infrastructure.
+        This is the information needed to derive an [AID](https://weboftrust.github.io/keridoc/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)
+        Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
+
+        ##### Inception Statement
+
+        ![inception statement](https://raw.githubusercontent.com/WebOfTrust/keri/7fc96da6c277d3921fb1248ce9235400a4ff6af7/images/inception-statement.png)
+
+        **In brief: It's the signed version of a statement containing the inception event with some extra data.**
+        (_@henkvancann_)
+
+        ##### Components and self-contained
+
+        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_)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [inconsistency](#inconsistency)
+
+    -   ### WebOfTrust
+
+        # inconsistency
+
+        ###### Definition
+
+        If a reason, idea, opinion, etc. is inconsistent, different parts of it do not agree, or it does not agree with something else. Data inconsistency occurs when similar data is kept in different formats in more than one file. When this happens, it is important to match the data between files.
+
+        ###### KERI related
+
+        A data structure like a [KEL](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) can be internally _inconsistent_ which is a clear indication that this data structure is not [verifiable](https://weboftrust.github.io/keridoc/docs/glossary/verifiable.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [indexed signature](#indexed-signature)
+
+    -   ### WebOfTrust
+
+        # indexed signature
+
+        ###### Definition
+
+        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
+
+        ###### Example working
+
+        An indexed signature attachment would look something like:
+
+        ```
+        03.
+        ```
+
+        All encoded as [qualified](https://weboftrust.github.io/keridoc/docs/glossary/qualified.md) [base64](https://weboftrust.github.io/keridoc/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
+
+        ###### Witness signatures indexed
+
+        In addition, [witness](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [indirect mode](#indirectmode)
+
+    -   ### ToIP (DID:Webs)
+
+        An operational mode of the KERI protocol where the KEL of an AID is discovered by a verifier via witnesses, as defined by the KERI whitepaper. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # indirect mode
+
+        ###### Definition
+
+        Two primary trust modalities motivated the KERI design, One 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/keridoc/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/keridoc/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)
+
+        ###### Operational mode
+
+        To protect a [validator](https://weboftrust.github.io/keridoc/docs/glossary/validator.md) when engaging with some other controller’s identifier, be it [verification](https://weboftrust.github.io/keridoc/docs/glossary/verification.md), control authority establishment, or [duplicity](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/controller.md) is not attached to the network and therefore not able to communicate directly with a [validator](https://weboftrust.github.io/keridoc/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)
+
+        ###### Security concerns
+
+        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)
+
+        ###### Also see
+
+        [Direct mode](https://weboftrust.github.io/keridoc/docs/glossary/direct-mode.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [input output](#input-output)
+
+    -   ### WebOfTrust
+
+        # input output
+
+        ###### Definition
+
+        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).
+
+        ###### More on source Wikipedia
+
+        [Input/Output](https://en.wikipedia.org/wiki/Input/output)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [inquisitor](#inquisitor)
+
+    -   ### WebOfTrust
+
+        # inquisitor
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/witness.md).
+
+        ###### More broadly accepted notion
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [integrity](#integrity)
+
+    -   ### WebOfTrust
+
+        # integrity
+
+        ###### Definition
+
+        Integrity (of a message or data) means that the information is whole, sound, and unimpaired (not necessarily correct). It means nothing is missing from the information; it is complete and in intended good order. (Source: Neil Thomson)
+
+        ###### KERI suite criteria
+
+        In KERI's "security first" approach Authenticity includes _technical integrity_ of data involved. This includes:
+
+        1.  [internal consistency](https://weboftrust.github.io/keridoc/docs/glossary/internal-inconsistency.md)
+        2.  external consistency or [duplicity](https://weboftrust.github.io/keridoc/docs/glossary/duplicity.md) evident
+
+        Integrity in ACDCs is "self-verifying": the [SAID](https://weboftrust.github.io/keridoc/docs/glossary/self-addressing-identifier.md) that is contained in the data is also the of hash of the data.
+
+        The integrity of streaming data in [CESR](https://weboftrust.github.io/keridoc/docs/glossary/composable-event-streaming-representation.md) and [CESR proof signatures](https://weboftrust.github.io/keridoc/docs/glossary/cesr-proof-signatures.md) is established by code tables and verifiable by the mere (killer-)feature: round-robin [composability](https://weboftrust.github.io/keridoc/docs/glossary/composability.md). If you can toggle between the text - and binary representation, _then that's the integrity proof_, if not, then it's provably lacking integrity.
+
+        A side-benefit of how integrity is implemented in KERI is [non-repudiation](https://weboftrust.github.io/keridoc/docs/glossary/non-repudiable.md) - done via a crypto-hash verification via the signer's public key - is not inherent in the meaning of integrity.
+
+        Furthermore for KERI integrity, as an assessment of the substance or the content itself, does not fall within its narrow definition. **Our criterium is cryptographic verifiability**. Once you can't verify, for KERI this type of non-technical integrity is not included in `integrity`. For the same reason we wouldn't use [validation](https://weboftrust.github.io/keridoc/docs/glossary/validate.md)\* as a mechanism to prove integrity.
+
+        ###### ToIP related
+
+        On today's Technology Architecture TF call,..., we defined authenticity to include integrity.
+        [Source ToIP issue 10](https://github.com/trustoverip/TechArch/issues/10)
+
+        [message integrity](https://github.com/trustoverip/TechArch/issues/10) seems to be included in `technical integrity`.
+
+        The further separation of Authenticity and Integrity in the ToIP glossary can be largely adopted by KERI? | TBW prio 2 |
+
+        ###### See also
+
+        [verified integrity](https://weboftrust.github.io/keridoc/docs/glossary/verified-integrity.md)
+        [(complementary) integrity verification](https://weboftrust.github.io/keridoc/docs/glossary/complementary-integrity-verification.md)
+
+        \*Validation in relation to integrity, in KERI's view would be an assessment of what's been verified before; in a certain context from a certain angle. And this mechanism is too close to _veracity judgement_, to be an objective verdict over integrity of data.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [integrity (of a data structure)](#h.n34avr5qvr0j)
+
+    -   ### ToIP
+
+        In IT security, data integrity means maintaining and assuring the accuracy and completeness of [data](#h.o783ayrrkc6g) over its entire lifecycle. This means that [data](#h.o783ayrrkc6g) cannot be modified in an [unauthorized](#h.576ssfpt348i) or undetected manner.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Information_security%23Integrity&sa=D&source=editors&ust=1718703186717432&usg=AOvVaw0V3dDyUSdSxv6cE2UuP9YG).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [interaction event](#interactionevent)
+
+    -   ### ToIP (DID:Webs)
+
+        A key event that anchors external data to an AID, as defined by the KERI specification. An interaction event does not change the key state of the AID. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # 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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [interactive authentication design](#interactive-authentication-design)
+
+    -   ### WebOfTrust
+
+        # interactive authentication design
+
+        ###### Definition
+
+        A group of approaches having an interactive mechanism that requires a set of requests and responses or challenge responses with challenge response replies for secure authentication.
+        More in [source](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw) Keri Request Authentication Mechanism (KRAM) by Samuel Smith
+
+        ###### Related
+
+        [Non-interactive authentication design](https://weboftrust.github.io/keridoc/docs/glossary/non-interactive-authentication-design.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [interceptor](#interceptor)
+
+    -   ### WebOfTrust
+
+        # interceptor
+
+        ###### Definition
+
+        a [keria](https://weboftrust.github.io/keridoc/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.
+
+        ###### Origin
+
+        [https://github.com/WebOfTrust/keria/pull/67](https://github.com/WebOfTrust/keria/pull/67)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [interleaved serialisation](#interleaved-serialisation)
+
+    -   ### WebOfTrust
+
+        # interleaved serialisation
+
+        ###### Definition
+
+        Serializations of different types interleaved in an overarching format
+
+        ###### CESR related
+
+        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/keridoc/docs/glossary/distributed-hash-table.md).
+        [Source IETF-CESR](https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html#section-3.5)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [intermediary system](#h.i4pfys3yiku)
+
+    -   ### ToIP
+
+        A system that operates at [ToIP Layer 2](#h.ikqr9hyt133k), the [trust spanning layer](#h.k9uiol17u620) of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186717875&usg=AOvVaw08jEHtvtRXJ_fFRlrb4Vch), in order to route [ToIP messages](#h.5th2gmjr7ij) between [endpoint systems](#h.scy14dobg777). A supporting system is one of three types of systems defined in the [ToIP Technology Architecture Specification](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.bjv9ltwjbiqm&sa=D&source=editors&ust=1718703186718192&usg=AOvVaw0wXAJ3-one5-nACCfOvHhO).
+
+        See also: [endpoint system](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.scy14dobg777&sa=D&source=editors&ust=1718703186718484&usg=AOvVaw059YKQRWKkM-_kGdQh9aOg), [supporting system](#h.nqtdtghyfspz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [internal inconsistency](#internal-inconsistency)
+
+    -   ### WebOfTrust
+
+        # internal inconsistency
+
+        ###### Definition
+
+        Internal is used to describe things that exist or happen inside an [entity](https://weboftrust.github.io/keridoc/docs/glossary/entity.md). In our scope of digital [identifiers](https://weboftrust.github.io/keridoc/docs/glossary/identifier.md) its (in)consistency is considered within the defining data structures and related data stores.
+
+        In [KERI](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-infrastructure.md) we are protected against internal inconsistency by the hash chain datastructure of the [KEL](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md), because the only [authority](https://weboftrust.github.io/keridoc/docs/glossary/authority.md) that can sign the log is the [controller](https://weboftrust.github.io/keridoc/docs/glossary/controller.md) itself.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [internet assigned numbers authority](#internet-assigned-numbers-authority)
+
+    -   ### WebOfTrust
+
+        # internet assigned numbers authority
+
+        ###### Definition
+
+        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)
+
+        ##### What are IANA responsibilities?
+
+        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)
+
+        ##### More information
+
+        [Wikipedia](https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [interoperability](#interoperability)
+
+    -   ### WebOfTrust
+
+        # interoperability
+
+        ###### Definition
+
+        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)
+
+        ###### Types relevant for KERI and ACDC
+
+        [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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [interoperable](#interoperable)
+
+    -   ### WebOfTrust
+
+        # interoperable
+
+        ###### See
+
+        [Interoperability](https://weboftrust.github.io/keridoc/docs/glossary/interoperability.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ip address](#ip-address)
+
+    -   ### WebOfTrust
+
+        # 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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [iss](#iss)
+
+    -   ### WebOfTrust
+
+        # iss
+
+        ###### Definition
+
+        iss = vc issue, verifiable credential issuance
+
+        [Learn more](https://kerisse.org)
+
+-   ## [issuance](#h.zfdojht594xv)
+
+    -   ### ToIP
+
+        The [action](#h.l54nzmooy631) of an [issuer](#h.xyrplzbvtffq) producing and transmitting a [digital credential](#h.ddna9lucn4k6) to a [holder](#h.64mptmm24w7u). A [holder](#h.64mptmm24w7u) may request issuance by submitting an [issuance request](#h.tt253lgfp4hz).
+
+        See also: [presentation](#h.h5d1xfsxbbr0), [revocation](#h.ilt4dj4huwza).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [issuance and presentation exchange protocol](#issuance-and-presentation-exchange-protocol)
+
+    -   ### WebOfTrust
+
+        # issuance and presentation exchange protocol
+
+        ###### Definition
+
+        provides a uniform mechanism for the issuance and presentation of ACDCs in a securely attributable manner.
+
+        ###### Relation
+
+        A single protocol is able to work for both types of exchanges ([issuance](https://weboftrust.github.io/keridoc/docs/glossary/issuance-exchange.md) and [presentation](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/discloser.md) to a [Disclosee](https://weboftrust.github.io/keridoc/docs/glossary/disclosee.md).
+        The _difference_ between exchange types is _the information disclosed not the mechanism for disclosure_.
+
+        ###### More info at source
+
+        ([Source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md))
+
+        [Learn more](https://kerisse.org)
+
+-   ## [issuance event](#issuance-event)
+
+    -   ### WebOfTrust
+
+        # issuance event
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/inception-event.md)" of a verifiable credential.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [issuance exchange](#issuance-exchange)
+
+    -   ### WebOfTrust
+
+        # issuance exchange
+
+        ###### Definition
+
+        A special case of a [presentation exchange](https://weboftrust.github.io/keridoc/docs/glossary/presentation-exchange.md) where the [Discloser](https://weboftrust.github.io/keridoc/docs/glossary/discloser.md) is the [Issuer](https://weboftrust.github.io/keridoc/docs/glossary/issuer.md) of the origin (Primary) ACDC of the [DAG](https://weboftrust.github.io/keridoc/docs/glossary/directed-acyclic-graph.md) formed by the set of chained [ACDC](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/issuee.md), the [Disclosee](https://weboftrust.github.io/keridoc/docs/glossary/disclosee.md) MAY also be the origin ACDC's Issuee.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [issuance request](#h.tt253lgfp4hz)
+
+    -   ### ToIP
+
+        A protocol request invoked by the [holder](#h.64mptmm24w7u) of a [digital wallet](#h.sxnvf3f5v156) to obtain a [digital credential](#h.ddna9lucn4k6) from an [issuer](#h.xyrplzbvtffq).
+
+        See also: [presentation request](#h.onnn49cjzreh).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [issuee](#issuee)
+
+    -   ### WebOfTrust
+
+        # issuee
+
+        ###### Definition
+
+        An [ACDC](https://weboftrust.github.io/keridoc/docs/glossary/authentic-chained-data-container.md) is optionally issued to the Issuee. When present, the Issuee identifier ([AID](https://weboftrust.github.io/keridoc/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.
+
+        ###### Rule
+
+        Each ACDC MUST have an [Issuer](https://weboftrust.github.io/keridoc/docs/glossary/issuer.md) and MAY have an [Issuee](https://weboftrust.github.io/keridoc/docs/glossary/issuee.md). The set of [ACDC](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/directed-acyclic-graph.md) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [issuer](#issuer)
+
+    -   ### Nist
+
+        The organization that is issuing the PIV Card to an applicant. Typically, this is an organization for which the applicant is working.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/issuer)
+
+    -   ### WebOfTrust
+
+        # issuer
+
+        ###### Definition
+
+        An [ACDC](https://weboftrust.github.io/keridoc/docs/glossary/authentic-chained-data-container.md) is issued by the Issuer. The Issuer identifier ([AID](https://weboftrust.github.io/keridoc/docs/glossary/autonomic-identifier.md)) appears in the top level of the ACDC.
+
+        ###### Rule
+
+        Each ACDC MUST have an [Issuer](https://weboftrust.github.io/keridoc/docs/glossary/issuer.md) and MAY have an [Issuee](https://weboftrust.github.io/keridoc/docs/glossary/issuee.md). The set of [ACDC](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/directed-acyclic-graph.md) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [issuer (of a claim or credential)](#h.xyrplzbvtffq)
+
+    -   ### ToIP
+
+        A [role](#h.sf54cyuamo6x) an [agent](#h.6xkhfkjpo6xg) performs to package and [digitally sign](#h.s93np0i5rcne) a set of [claims](#h.akieli6njkk5), typically in the form of a [digital credential](#h.ddna9lucn4k6), and transmit them to a [holder](#h.64mptmm24w7u).
+
+        See also: [verifier](#h.xfewd7t01hu0), [holder](#h.64mptmm24w7u).
+
+        Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186723213&usg=AOvVaw0_AGwri4srsp2cEQpDWp_H)
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23issuer&sa=D&source=editors&ust=1718703186723485&usg=AOvVaw2d5GevHFNc1NqGpQUuyhi5): a component that implements the [capability](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/capability&sa=D&source=editors&ust=1718703186723660&usg=AOvVaw36xi0UzmcGBFdxxLnEetmI) to construct [credentials](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186723855&usg=AOvVaw2AEP8x0PmwP2UZ_5DG655e) from data objects, according to the content of its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186724029&usg=AOvVaw2qBLXUcsdIBU3llXBN3U9M)'s [issuer](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/issuer&sa=D&source=editors&ust=1718703186724184&usg=AOvVaw1DczPHb6yigSR3oGD83UwT)\-Policy (specifically regarding the way in which the [credential](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186724356&usg=AOvVaw2q1W1MOpikVAYlsSkxEYhD) is to be digitally signed), and pass it to the [wallet](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/wallet&sa=D&source=editors&ust=1718703186724522&usg=AOvVaw00xrIw65dqouvjxVT-p0pa)\-component of its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186724676&usg=AOvVaw2GMpcomki3Iu_E_WuEPg85) allowing it to be issued.
+
+        [W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186724878&usg=AOvVaw3FqBy5R09jGmSC-6Xh7tQi): A role an [entity](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-entities&sa=D&source=editors&ust=1718703186725033&usg=AOvVaw2NOSPMHqR8d4F84lJ-LOht) can perform by asserting [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186725190&usg=AOvVaw1a5q-fwDYznCZbxu_jcNJi) about one or more [subjects](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-subjects&sa=D&source=editors&ust=1718703186725335&usg=AOvVaw0jpsFDBhwn0UuuHwlVxYHg), creating a [verifiable credential](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186725500&usg=AOvVaw32UZO7oT58-l_Peacm-Twc) from these [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186725680&usg=AOvVaw1X1X_Xrq8oe0p099tW1wYi), and transmitting the [verifiable credential](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186725824&usg=AOvVaw3O1MrBYho_wa1qKvTsYcLm) to a [holder](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-holders&sa=D&source=editors&ust=1718703186725960&usg=AOvVaw1zuRGtoteHbNNcU3FKjN2E).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ixn](#ixn)
+
+    -   ### WebOfTrust
+
+        # ixn
+
+        ###### Definition
+
+        [JSON](https://weboftrust.github.io/keridoc/docs/glossary/JSON.md) field name (attribute) for Interaction Event; its content (value) contains a hash pointer. All [TEL](https://weboftrust.github.io/keridoc/docs/glossary/transaction-event-log.md) events are anchored in a [KEL](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) in either ixn ([interaction](https://weboftrust.github.io/keridoc/docs/glossary/interaction-event.md)) or [rot](https://weboftrust.github.io/keridoc/docs/glossary/rot.md) ([rotation event](https://weboftrust.github.io/keridoc/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
+
+        ###### Also see
+
+        [rot](https://weboftrust.github.io/keridoc/docs/glossary/rot.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [javascript object notation (JSON)](#javascript-object-notation-\(JSON\))
+
+    -   ### WebOfTrust
+
+        # javascript object notation (JSON)
+
+        ###### Definition
+
+        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\)).
+
+        ##### Language independent
+
+        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.
+
+        ##### More on Wikipedia
+
+        [JSON](https://en.wikipedia.org/wiki/JSON)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [javascript object signing and encryption](#javascript-object-signing-and-encryption)
+
+    -   ### WebOfTrust
+
+        # javascript object signing and encryption
+
+        ###### Definition
+
+        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 and more info
+
+        Related: `JWK`, `JWT`. [More info](https://jose.readthedocs.io/en/latest/)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [judge](#judge)
+
+    -   ### WebOfTrust
+
+        # judge
+
+        ###### Definition
+
+        A judge is an entity or component that examines the entries of one or more [KERLs](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/duplicity.md) controller and has been witnessed by a sufficient number of non-duplicitous [witnesses](https://weboftrust.github.io/keridoc/docs/glossary/witness.md) such that it may be trusted or conversely not-trusted by a [validator](https://weboftrust.github.io/keridoc/docs/glossary/validator.md).
+
+        ###### Task and result
+
+        A judge determines current \[authoritative\] key set for identifier from the [key event receipt logs](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-log.md) from a set of witnesses. Judges transmit the 'judgement' of watchers concerning duplicity.
+
+        ###### Where judges run
+
+        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/keridoc/docs/glossary/duplicity.md) is the only thing [watchers](https://weboftrust.github.io/keridoc/docs/glossary/watcher.md) are looking for.
+
+        ###### Competitor and common interest
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [jurisdiction](#h.uw2s3y6sjzjf)
+
+    -   ### ToIP
+
+        The composition of: a) a [legal system](#h.5eaw7wimeo81) (legislation, enforcement thereof, and conflict resolution), b) a [party](#h.cn6bno48fomj) that governs that [legal system](#h.5eaw7wimeo81), c) a scope within which that [legal system](#h.5eaw7wimeo81) is operational, and d) one or more [objectives](#h.k0v6ir8wmcav) for the purpose of which the [legal system](#h.5eaw7wimeo81) is operated.
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23jurisdiction&sa=D&source=editors&ust=1718703186726633&usg=AOvVaw20ccpxEG7k1cvzSbbxtOzE)
+
+        Mental model: [eSSIF-Lab Jurisdictions](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/pattern-jurisdiction&sa=D&source=editors&ust=1718703186726910&usg=AOvVaw0y4Pnl1q7C1AkhNqbtSUw9)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [juror](#juror)
+
+    -   ### WebOfTrust
+
+        # juror
+
+        ###### Definition
+
+        A juror has a simpler task of performing [duplicity](https://weboftrust.github.io/keridoc/docs/glossary/duplicity.md) detection on events and event receipts.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [jury](#jury)
+
+    -   ### WebOfTrust
+
+        # jury
+
+        ###### Definition
+
+        The jury is the set of entities or components acting as [jurors](https://weboftrust.github.io/keridoc/docs/glossary/juror.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keep](#keep)
+
+    -   ### WebOfTrust
+
+        # keep
+
+        ###### Definition
+
+        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
+
+        ###### Interface
+
+        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).
+
+        ###### Usecases
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keri agreement algorithm for control establishment](#keri-agreement-algorithm-for-control-establishment)
+
+    -   ### WebOfTrust
+
+        # keri agreement algorithm for control establishment
+
+        ##DefinitionAgreement on an event in a key event log [KEL](https://weboftrust.github.io/keridoc/docs/glossary/KEL.md) means each [witness](https://weboftrust.github.io/keridoc/docs/glossary/witness.md) has observed the same version of the event and each witness’ [receipt](https://weboftrust.github.io/keridoc/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.
+
+        Acronyms: 'KA2CE' '[KA2CE](https://weboftrust.github.io/keridoc/docs/glossary/KA2CE.md)' and 'KAACE'.
+
+        # Whitepaper definition:
+
+        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 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\]
+
+        # Additional Definition
+
+        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 that was missing liveness and total ordering but had safety and was completely decentralized, portable, and permission less? It would be named KERI.
+        (SamMSmith)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keri command line interface](#keri-command-line-interface)
+
+    -   ### WebOfTrust
+
+        # keri command line interface
+
+        ###### Definition
+
+        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.
+
+        ##### More information
+
+        [IIW34 presentation slides](https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68_0_5)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keri event stream](#keri-event-stream)
+
+    -   ### WebOfTrust
+
+        # keri event stream
+
+        ###### Definition
+
+        A stream of verifiable KERI data, consisting of the [key event log](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) and other data such as a [transaction event log](https://weboftrust.github.io/keridoc/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/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keri improvement doc](#keri-improvement-doc)
+
+    -   ### WebOfTrust
+
+        # keri improvement doc
+
+        ###### Definition
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keri ox](#keri-ox)
+
+    -   ### WebOfTrust
+
+        # keri ox
+
+        ###### Definition
+
+        The RUST programming-language implementation of the [KERI](https://github.com/trustoverip/acdc/wiki/KERI) protocol.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keri request authentication method](#keri-request-authentication-method)
+
+    -   ### WebOfTrust
+
+        # keri request authentication method
+
+        ###### Definition
+
+        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)
+
+        ###### Related
+
+        [SKWA](https://weboftrust.github.io/keridoc/docs/glossary/SKWA.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keri suite](#keri-suite)
+
+    -   ### WebOfTrust
+
+        # keri suite
+
+        ###### Definition
+
+        The _KERI suite_ is the set of inter-related developments (KERI, ACDC, OOBI, CESR, IPEX, etc) under the Web-of -Trust user on Github
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keri suite search engine](#keri-suite-search-engine)
+
+    -   ### WebOfTrust
+
+        # keri suite search engine
+
+        ###### Definition
+
+        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/keridoc/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/keridoc/docs/glossary/keri-suite.md) it's more a search engine that drills down on documentation.
+
+        ###### Related kerific
+
+        [kerific](https://weboftrust.github.io/keridoc/docs/glossary/kerific.md) is a front-end tool that show all available glossary-definition in [KERISSE](https://weboftrust.github.io/keridoc/docs/glossary/KERISSE.md) for matching words in any web text; combined in the [Dictionary SSI](https://weboftrust.github.io/WOT-terms/docs/dictionary?level=2). This is based on a large JSON file
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keria](#keria)
+
+    -   ### WebOfTrust
+
+        # keria
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keride](#keride)
+
+    -   ### WebOfTrust
+
+        # keride
+
+        ###### Definition
+
+        is a _Rust_ programming language library for [Key Event Receipt Infrastructure](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-infrastructure.md). Among its features is [CESR](https://weboftrust.github.io/keridoc/docs/glossary/CESR.md), signing, prefixing, pathing, and parsing.
+        More on [Github repo](https://github.com/WebOfTrust/keride)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keridemlia](#keridemlia)
+
+    -   ### WebOfTrust
+
+        # keridemlia
+
+        ###### Definition
+
+        It is a contraction of [KERI](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/distributed-hash-table.md). It also does the CNAME - stuff that [Domain Name](https://weboftrust.github.io/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [kerific](#kerific)
+
+    -   ### WebOfTrust
+
+        # kerific
+
+        ###### Definition
+
+        _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/keridoc/docs/glossary/self-sovereign-identity.md) field.
+
+        ###### Relation with KERISSE
+
+        All glossaries that [KERISSE](https://weboftrust.github.io/keridoc/docs/glossary/KERISSE.md) is allowed to scrape are combined in the [Dictionary SSI](https://weboftrust.github.io/WOT-terms/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.
+
+        ###### Download kerific
+
+        It is in the [Chrome Webstore](https://chromewebstore.google.com/detail/kerific/ckbmkbbmnfbeecfmoiohobcdmopekgmp?hl=nl)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keripy](#keripy)
+
+    -   ### WebOfTrust
+
+        # keripy
+
+        ###### Definition
+
+        The Python programming-language implementation of the [KERI](https://weboftrust.github.io/keridoc/docs/glossary/KERI.md) protocol.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [kever](#kever)
+
+    -   ### WebOfTrust
+
+        # kever
+
+        ###### Definition
+
+        Kever is a key event verifier.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key](#key)
+
+    -   ### Nist
+
+        A parameter used in conjunction with a cryptographic algorithm that determines the specific operation of that algorithm.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/key)
+
+    -   ### ToIP
+
+        See: [cryptographic key](#h.53rzpn1yn6q7).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # key
+
+        ###### Definition
+
+        In our digital scope it's a mechanism for granting or restricting access to something. MAY be used to issue and prove, MAY be used to transfer and control over _identity_ and _cryptocurrency_. [More](https://en.wikipedia.org/wiki/Key_\(cryptography\))
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key compromise](#key-compromise)
+
+    -   ### WebOfTrust
+
+        # key compromise
+
+        ###### Definition
+
+        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 verificationSo when we say “key compromise” we really mean compromise of one of those three things.
+
+        ##### More information
+
+        More in the security sections of [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key establishment](#h.pkh9vfulrizg)
+
+    -   ### ToIP
+
+        A process that results in the sharing of a key between two or more entities, either by transporting a key from one entity to another (key transport) or generating a key from information shared by the entities (key agreement).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/key_establishment&sa=D&source=editors&ust=1718703186727884&usg=AOvVaw1M3z4HwWHMAHboWXgOrMxY).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [key event](#h.w6skxxfqgbqp)
+
+    -   ### ToIP
+
+        An event in the history of the usage of a [cryptographic key pair](#h.53rzpn1yn6q7). There are multiple types of key events. The inception event is when the key pair is first generated. A rotation event is when the key pair is changed to a new key pair. In some [key management systems](#h.q0w3jq78va39) (such as [KERI](#h.7pp65h7qs9lu)), key events are tracked in a [key event log](#h.6jhhyjh47h).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### ToIP (DID:Webs)
+
+        A serialized data structure of an entry in the key event log(KEL) for an AID, as defined by the KERI specification. There are three types of key events, namely inception event, rotation event, and interaction event. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # key event
+
+        ###### Definition
+
+        Concretely, the serialized data structure of an entry in the key event log 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 key event log actualized by a particular entry.
+        Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
+
+        ###### Loose definition in KERI
+
+        Events happening to controlling keys of an identifier recorded in a Key Event Log (KEL).
+
+        ###### Data structure angle
+
+        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_)
+
+        ![](https://github.com/WebOfTrust/keri/blob/main/images/Key-Event.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key event log](#h.6jhhyjh47h)
+
+    -   ### ToIP
+
+        An ordered sequence of [records](#h.y4ybzkfe6yzv) of [key events](#h.w6skxxfqgbqp).
+
+        Note: Key event logs are a fundamental data structure in [KERI](#h.7pp65h7qs9lu).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # key event log
+
+        ###### Definition
+
+        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)
+
+        ##### Put differently
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key event log (KEL)](#keyeventlog\(KEL\))
+
+    -   ### ToIP (DID:Webs)
+
+        A verifiable append-only log of key events for an AID that is both backward and forward-chained, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [key event message](#key-event-message)
+
+    -   ### WebOfTrust
+
+        # key event message
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key event receipt](#keyeventreceipt)
+
+    -   ### ToIP (DID:Webs)
+
+        A message whose body references a key event of an AID and includes one or more signatures on that key event, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # key event receipt
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key event receipt infrastructure](#key-event-receipt-infrastructure)
+
+    -   ### WebOfTrust
+
+        # key event receipt infrastructure
+
+        ###### Definition
+
+        Also `KERI`. 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_)
+
+        ###### Trust spanning layer for the internet
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key event receipt infrastructure (KERI)](#keyeventreceiptinfrastructure\(KERI\))
+
+    -   ### ToIP (DID:Webs)
+
+        A protocol that provides an identity system-based secure overlay for the internet and uses AIDs as the primary roots of trust, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [key event receipt log](#key-event-receipt-log)
+
+    -   ### WebOfTrust
+
+        # key event receipt log
+
+        ###### Definition
+
+        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)
+
+        ![](https://github.com/WebOfTrust/keri/blob/main/images/inception-rotation.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key event receipt log (KERL)](#keyeventreceiptlog\(KERL\))
+
+    -   ### ToIP (DID:Webs)
+
+        A verifiable append-only log that includes all the consistent key event receipt messages, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [key management](#key-management)
+
+    -   ### WebOfTrust
+
+        # key management
+
+        ###### Definition
+
+        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](https://weboftrust.github.io/keridoc/docs/glossary.md#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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key management system](#h.q0w3jq78va39)
+
+    -   ### ToIP
+
+        A system for the management of [cryptographic keys](#h.53rzpn1yn6q7) and their [metadata](#h.t63bf0ssndfd) (e.g., generation, distribution, storage, backup, archive, recovery, use, [revocation](#h.ilt4dj4huwza), and destruction). An automated key management system may be used to oversee, automate, and secure the key management process. A key management is often protected by implementing it within the [trusted execution environment](#h.rsly6bxjqeg5) (TEE) of a device. An example is the [Secure Enclave](#h.lf0txjgjs67z) on Apple iOS devices.
+
+        Also known as: [KMS](#h.wcbd8vhwq6z1).
+
+        Source: [NIST-CRSC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/key_management_system&sa=D&source=editors&ust=1718703186730303&usg=AOvVaw3xcm-_c9qKTN_Fuf3cbNfz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [key pair](#key-pair)
+
+    -   ### WebOfTrust
+
+        # key pair
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/public-key-infrastructure.md) (PKI).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key state](#keystate)
+
+    -   ### ToIP (DID:Webs)
+
+        The set of currently authoritative key pairs (current keys) for an AID and any other information necessary to secure or establish control authority over the AID. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # key state
+
+        ###### Definition
+
+        Includes the set of currently authoritative keypairs for an AID and any other information necessary to secure or establish control authority over an AID.
+        Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key stretching](#key-stretching)
+
+    -   ### WebOfTrust
+
+        # key stretching
+
+        ###### Definition
+
+        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.
+
+        ###### Humans are predictable
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [key transparency](#key-transparency)
+
+    -   ### WebOfTrust
+
+        # key transparency
+
+        ###### Definition
+
+        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.
+
+        ##### Use cases
+
+        -   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/)
+
+        ##### Merkle tree
+
+        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_)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [keys-at-the-edge](#h.41san6iwsd69)
+
+    -   ### ToIP
+
+        A [key management](#h.q0w3jq78va39) architecture in which [keys](#h.bk8tq6m7ylyl) are stored on a user’s local edge devices, such as a smartphone, tablet, or laptop, and then used in conjunction with a secure protocol to unlock a [key management system](#h.q0w3jq78va39) (KMS) and/or a [digital vault](#h.cz29glapo2tg) in the cloud. This approach can enable the storage and sharing of large [data](#h.o783ayrrkc6g) structures that are not feasible on edge devices. This architecture can also be used in conjunction with [confidential computing](#h.w12e1nuzy65z) to enable cloud-based [digital agents](#h.z3ugzt4hgdf6) to safely carry out “user not present” operations.
+
+        Also known as: [KATE](#h.m06ht5n5sabj).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [keystore](#keystore)
+
+    -   ### WebOfTrust
+
+        # keystore
+
+        ###### Definition
+
+        A keystore in KERI is the encrypted data store that hold the private keys for a collection of AIDs.
+        Source: Philip Feairheller.
+
+        ###### KERI related
+
+        KERI explicitly distinguishes [keystore](https://weboftrust.github.io/keridoc/docs/glossary/keystore.md) and [wallet](https://weboftrust.github.io/keridoc/docs/glossary/wallet.md); the latter being a superset of the former. [Keep](https://weboftrust.github.io/keridoc/docs/glossary/keep.md) is KERI's and ACDC's user interface with Keripy agent API as a back end.
+
+        ###### Beware
+
+        A [Java Keystore](https://en.wikipedia.org/wiki/Java_KeyStore) is a non-related concept!
+
+        [Learn more](https://kerisse.org)
+
+-   ## [kli](#kli)
+
+    -   ### WebOfTrust
+
+        # kli
+
+        ###### See
+
+        [KERI command line interface](https://weboftrust.github.io/keridoc/docs/glossary/keri-command-line-interface.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [knowledge](#h.k96lktyswxnb)
+
+    -   ### ToIP
+
+        The (intangible) sum of what is known by a specific [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186731755&usg=AOvVaw1AnZwxcHhjcBeT4jp9Xh1t), as well as the familiarity, awareness or understanding of someone or something by that [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186731935&usg=AOvVaw0NeyacND9fzb62lst7gsqO).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23knowledge&sa=D&source=editors&ust=1718703186732141&usg=AOvVaw3dJ0C-ca2HXlyi-X1v10Jt).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ksn](#ksn)
+
+    -   ### WebOfTrust
+
+        # ksn
+
+        ###### Definition
+
+        ksn = state, key state notice
+
+        [Learn more](https://kerisse.org)
+
+-   ## [large language model](#large-language-model)
+
+    -   ### WebOfTrust
+
+        # large language model
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [lead bytes](#lead-bytes)
+
+    -   ### WebOfTrust
+
+        # lead bytes
+
+        ###### Definition
+
+        In order to avoid confusion with the use of the term [pad](https://weboftrust.github.io/keridoc/docs/glossary/pad.md) character, when [pre-pad](https://weboftrust.github.io/keridoc/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".
+
+        ###### CESR related
+
+        The term [pad](https://weboftrust.github.io/keridoc/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_.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ledger backer](#ledger-backer)
+
+    -   ### WebOfTrust
+
+        # ledger backer
+
+        ###### Definition
+
+        A [witness](https://weboftrust.github.io/keridoc/docs/glossary/witness.md) in KERI that is ledger-registered. It's a type of [backer](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [legal entity](#h.5328bxxk02sb)
+
+    -   ### ToIP
+
+        An [entity](#h.5imtbzl1f4xo) that is not a [natural person](#h.yx4qb6dcjdvj) but is recognized as having legal rights and responsibilities. Examples include corporations, partnerships, sole proprietorships, non-profit [organizations](#h.z27mp1358pi9), associations, and governments. (In some cases even natural systems such as rivers are treated as legal entities.)
+
+        See also: [Legal Entity Identifier](#h.tvqq4mlccuun), [legal person](#h.a2q7i8my0jte), [organization](#h.z27mp1358pi9).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # legal entity
+
+        ###### Definition
+
+        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.
+
+        ###### More detailed and inclusive
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [legal entity engagement context role vlei credential governance framework](#legal-entity-engagement-context-role-vlei-credential-governance-framework)
+
+    -   ### WebOfTrust
+
+        # legal entity engagement context role vlei credential governance framework
+
+        ###### Definition
+
+        A document that details the requirements for [vLEI Role Credentials](https://weboftrust.github.io/keridoc/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.
+
+        ###### Related
+
+        -   [Legal entity](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity.md)
+        -   [Engagement context role (ECR)](https://weboftrust.github.io/keridoc/docs/glossary/engagement-context-role.md)
+        -   [vLEI credential](https://weboftrust.github.io/keridoc/docs/glossary/vlei-credential.md)
+        -   [Governance framework](https://weboftrust.github.io/keridoc/docs/glossary/governance-framework.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [legal entity official organizational role vlei credential governance framework](#legal-entity-official-organizational-role-vlei-credential-governance-framework)
+
+    -   ### WebOfTrust
+
+        # legal entity official organizational role vlei credential governance framework
+
+        ###### Definition
+
+        A document that details the requirements for [vLEI Role Credentials](https://weboftrust.github.io/keridoc/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.
+
+        ###### Related
+
+        -   [Legal entity](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity.md)
+        -   [Official organizational role (OOR)](https://weboftrust.github.io/keridoc/docs/glossary/official-organizational-role.md)
+        -   [vLEI credential](https://weboftrust.github.io/keridoc/docs/glossary/vlei-credential.md)
+        -   [Governance framework](https://weboftrust.github.io/keridoc/docs/glossary/governance-framework.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [legal entity vlei credential governance framework](#legal-entity-vlei-credential-governance-framework)
+
+    -   ### WebOfTrust
+
+        # legal entity vlei credential governance framework
+
+        ###### Definition
+
+        A _document_ that details the requirements for vLEI Credential **issued by** a [Qualified vLEI Issuer](https://weboftrust.github.io/keridoc/docs/glossary/qualified-vlei-issuer.md) to a [Legal Entity](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [legal identity](#h.s0f760qh7yij)
+
+    -   ### ToIP
+
+        A set of [identity data](#h.t3ho4tago38u) considered [authoritative](#h.9tt1qpgdfnxs) to identify a [party](#h.cn6bno48fomj) for purposes of legal accountability under one or more [jurisdictions](#h.uw2s3y6sjzjf).
+
+        See also: [foundational identity](#h.ig62zx2lc56o), [functional identity](#h.tk5si1lqyz9q).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [legal person](#h.a2q7i8my0jte)
+
+    -   ### ToIP
+
+        In law, a legal person is any person or 'thing' that can do the things a human person is usually able to do in law – such as enter into contracts, sue and be sued, own property, and so on.[\[3\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_person%23cite_note-3&sa=D&source=editors&ust=1718703186735422&usg=AOvVaw3cBimnI41SjF3nkzhqx_U2)[\[4\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_person%23cite_note-oxdic-4&sa=D&source=editors&ust=1718703186735610&usg=AOvVaw33CWh1pmoT1yFZzFW14wLP)[\[5\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_person%23cite_note-5&sa=D&source=editors&ust=1718703186735776&usg=AOvVaw1oCSXIjM-0M8EgmCGRmD98) The reason for the term "legal person" is that some legal persons are not people: companies and corporations are "persons" legally speaking (they can legally do most of the things an ordinary person can do), but they are not people in a literal sense (human beings).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_person&sa=D&source=editors&ust=1718703186736152&usg=AOvVaw3STdUCmJ8ai9y3DjRQBTgW).
+
+        Contrast with: [natural person](#h.yx4qb6dcjdvj).
+
+        See also: [legal entity](#h.5328bxxk02sb), [organization](#h.z27mp1358pi9).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [legal system](#h.5eaw7wimeo81)
+
+    -   ### ToIP
+
+        A system in which [policies](#h.udts41hso4w4) and [rules](#h.v7s575ulon74) are defined, and mechanisms for their enforcement and conflict resolution are (implicitly or explicitly) specified. Legal systems are not just defined by governments; they can also be defined by a [governance framework](#h.2x05z0r097mn).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23legal-system&sa=D&source=editors&ust=1718703186736926&usg=AOvVaw1FHzk-9IbKoVXaaXd5jbjC)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [legitimized human meaningful identifier](#legitimized-human-meaningful-identifier)
+
+    -   ### WebOfTrust
+
+        # legitimized human meaningful identifier
+
+        ###### Definition
+
+        An [AID](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/end-verifiable.md) [authorization](https://weboftrust.github.io/keridoc/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.
+
+        ###### Problematic human meaningfulness
+
+        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/keridoc/docs/glossary/autonomic-identifier.md) comes to rescue.
+
+        ###### Couplet for scarcity and security
+
+        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 |.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [level of assurance](#h.qseghs6dqcd)
+
+    -   ### ToIP
+
+        See: [assurance level](#h.hsktvoq15zz7).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [level of risk](#levelofrisk)
+
+    -   ### digital.govt.nz
+
+        magnitude of a risk or combination of risks, expressed in terms of the combination of consequences and their likelihood\[Source: ISO 31073:2022\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [levels of assurance](#levels-of-assurance)
+
+    -   ### WebOfTrust
+
+        # levels of assurance
+
+        ###### Definition
+
+        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'.
+
+        ##### Relationship with KERI
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [likelihood](#likelihood)
+
+    -   ### digital.govt.nz
+
+        chance of something happening\[Source: ISO 31073:2022\]Additional notes:Note 1: In risk management terminology, the word likelihood is used to refer to the chance of something happening, whether defined, measured or determined objectively or subjectively, qualitatively or quantitatively, and described using general terms or mathematically (such as a probability or a frequency over a given time period).Note 2: The English term likelihood does not have a direct equivalent in some languages instead, the equivalent of the term probability is often used. However, in English, probability is often narrowly interpreted as a mathematical term. Therefore, in risk management terminology, likelihood is used with the intent that it should have the same broad interpretation as the term probability has in many languages other than English.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [listed identifier](#listed-identifier)
+
+    -   ### WebOfTrust
+
+        # listed identifier
+
+        ###### Definition
+
+        Is a list in an [ACDC](https://weboftrust.github.io/keridoc/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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [liveness](#liveness)
+
+    -   ### WebOfTrust
+
+        # liveness
+
+        ###### Definition
+
+        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.
+
+        ##### Meaning
+
+        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](https://weboftrust.github.io/keridoc/docs/glossary.md#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}
+
+        ##### More information
+
+        On [wikipedia](https://en.wikipedia.org/wiki/Liveness)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [liveness detection](#h.v2edf5qj0ig4)
+
+    -   ### ToIP
+
+        Any technique used to detect a [presentation attack](#h.p0f7ugeoyf0l) by determining whether the source of a biometric sample is a live human being or a fake representation. This is typically accomplished using algorithms that analyze biometric sensor data to detect whether the source is live or reproduced.
+
+        Also known as: [proof of presence](#h.gmumid2hix8v).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [loci of control](#loci-of-control)
+
+    -   ### WebOfTrust
+
+        # loci of control
+
+        ###### Definition
+
+        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 domain
+
+        In SSI loci-of-control was decribed by Tim Bouma in 2019:![](https://github.com/WebOfTrust/keri/blob/main/images/loci-of-control.png?raw=true)
+
+        ###### KERI development
+
+        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](https://weboftrust.github.io/keridoc/docs/glossary.md#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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [locked state](#locked-state)
+
+    -   ### WebOfTrust
+
+        # locked state
+
+        ###### Definition
+
+        The default status a KERI data store is in once it has been created using a [passcode](https://weboftrust.github.io/keridoc/docs/glossary/passcode.md); it is by default encrypted.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [locus of control](#h.ms19insimzmb)
+
+    -   ### ToIP
+
+        The set of computing systems under a [party’s](#h.cn6bno48fomj) direct control, where [messages](#h.bge7ubygwk2q) and [data](#h.o783ayrrkc6g) do not cross [trust boundaries](#h.91w031j2r3g).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [machine-readable](#h.8s3s84fzcfi3)
+
+    -   ### ToIP
+
+        Information written in a computer language or [expression language](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.21tvck8eyp4o&sa=D&source=editors&ust=1718703186738297&usg=AOvVaw1iBCnU_GvKujE41pmpSVfh) so that it can be read and processed by a computing device.
+
+        Contrast with: [human-readable](#h.ywyofmy4do4t).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [man-made thing](#h.98jmqz1068vj)
+
+    -   ### ToIP
+
+        A [thing](#h.yyvwb9txkdzw) generated by human activity of some kind. Man-made things include both active things, such as cars or drones, and passive things, such as chairs or trousers.
+
+        Source: [Sovrin Foundation Glossary V3](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit&sa=D&source=editors&ust=1718703186738805&usg=AOvVaw14RTMIusm1lzBmHKskUEEu)
+
+        Contrast with: [natural thing](#h.njbtirxy3jvo).
+
+        Note: Active things are the equivalent of non-human [actors](#h.gzdfngxkp0ip) in the eSSIF-Lab mental model [Parties, Actors, Actions](https://www.google.com/url?q=https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-party-actor-action&sa=D&source=editors&ust=1718703186739151&usg=AOvVaw3fLuXbYNrTYSOjmibUVKi7). Also see [Appendix B](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit%23heading%3Dh.mq7pzglc1j96&sa=D&source=editors&ust=1718703186739338&usg=AOvVaw0wFv48EqS-oJH-WpaKss8y) and [Appendix C](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit%23heading%3Dh.uiq9py7xnmxd&sa=D&source=editors&ust=1718703186739518&usg=AOvVaw3F9A6bwsvh88cmf2mL9kNg) of the Sovrin Glossary.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [management TEL](#management-TEL)
+
+    -   ### WebOfTrust
+
+        # management TEL
+
+        ###### See
+
+        [Management transaction event log](https://weboftrust.github.io/keridoc/docs/glossary/management-transaction-event-log.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [management transaction event log](#management-transaction-event-log)
+
+    -   ### WebOfTrust
+
+        # management transaction event log
+
+        ###### Definition
+
+        A 'management TEL' will signal the creation of the _Virtual Credential Registry (VCR)_ and track the list of _Registrars_ that will act as _Backers_ for the individual \_ transaction event logs (TELs)\_ for each virtual credential (VC).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [mandatory](#h.n3iynmuwwbf8)
+
+    -   ### ToIP
+
+        A [requirement](#h.ajxlw8r3dvcc) that must be implemented in order for an implementer to be in [compliance](#h.r0iiayz1za1i). In [ToIP governance frameworks](#h.ns22ebn9xjun), a mandatory [requirement](#h.ajxlw8r3dvcc) is expressed using a MUST or REQUIRED keyword as defined in IETF RFC 2119.
+
+        See also: [recommended](#h.db3a5yf4o7iu), [optional](#h.9411lfbb9qf2).
+
+        For more information, see: [https://www.rfc-editor.org/rfc/rfc2119](https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc2119&sa=D&source=editors&ust=1718703186740197&usg=AOvVaw19Ap9K04kbJH6xriGWVIDW).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [mechanism](#mechanism)
+
+    -   ### digital.govt.nz
+
+        a process or technique, esp. of execution\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [media type](#media-type)
+
+    -   ### WebOfTrust
+
+        # media type
+
+        ###### Definition
+
+        A Media type (formerly known as _MIME type_) is a standard way to indicate the nature and format of a file, like '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.
+
+        More on source [Wikipedia](https://en.wikipedia.org/wiki/Media_type)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [message](#h.bge7ubygwk2q)
+
+    -   ### ToIP
+
+        A discrete unit of [communication](#h.w02a6srdng3j) intended by the source for consumption by some recipient or group of recipients.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Message&sa=D&source=editors&ust=1718703186741650&usg=AOvVaw3lD9WqlDsU0rLcatxD3nyW).
+
+        See also: [ToIP message](#h.5th2gmjr7ij), [verifiable message](#h.7zrsx7mki2fr).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # message
+
+        ###### Definition
+
+        serialized data structure event, an actionable message
+
+        ###### KERI details
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [messagepack](#messagepack)
+
+    -   ### WebOfTrust
+
+        # messagepack
+
+        ###### Definition
+
+        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
+
+        ##### More on Wikipedia
+
+        [MessagePack](https://en.wikipedia.org/wiki/MessagePack)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [metadata](#h.t63bf0ssndfd)
+
+    -   ### ToIP
+
+        Information describing the characteristics of [data](#h.o783ayrrkc6g) including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/metadata&sa=D&source=editors&ust=1718703186740622&usg=AOvVaw3S1oP4ihYOTYxTIgpZDrhb).
+
+        See also: [communication metadata](#h.jvfwgs8vd2rd).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Metadata&sa=D&source=editors&ust=1718703186740976&usg=AOvVaw36T1iVJ4CoFTPYV7Z8z1Oz): Metadata (or metainformation) is "[data](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data&sa=D&source=editors&ust=1718703186741117&usg=AOvVaw1-IPo8AtiOTn1fWmif1p3c) that provides information about other data", but not the content of the data itself, such as the text of a message or the image itself.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [method-specific identifier](#methodspecificidentifier)
+
+    -   ### ToIP (DID:Webs)
+
+        The method-specific-id part of DID Syntax, as defined in DID Core. See section Method-Specific Identifier.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [mobile deep link](#h.le2xkm9qaw28)
+
+    -   ### ToIP
+
+        In the context of mobile apps, [deep linking](#h.ubxk9l39j7w) consists of using a uniform resource identifier (URI) that links to a specific location within a mobile app rather than simply launching the app. Deferred deep linking allows users to deep link to content even if the app is not already installed. Depending on the mobile device platform, the URI required to trigger the app may be different.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mobile_deep_linking&sa=D&source=editors&ust=1718703186742397&usg=AOvVaw31qqHEvEU8AKTyPSU4b9Pa).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [moobi](#moobi)
+
+    -   ### WebOfTrust
+
+        # moobi
+
+        ###### Definition
+
+        Multi [OOBI](https://weboftrust.github.io/keridoc/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.
+
+        ###### Limitation
+
+        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.
+
+        ###### Also see
+
+        Source: Philip Feairheller [KERI-dev meeting](https://github.com/WebOfTrust/keri/discussions/39) July 27 2023
+
+        [Learn more](https://kerisse.org)
+
+-   ## [most compact](#most-compact)
+
+    -   ### WebOfTrust
+
+        # most compact
+
+        ###### Definition
+
+        An [ACDC](https://weboftrust.github.io/keridoc/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/keridoc/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 will have a "most compacted" version. If all the blocks are expanded of 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.
+
+        ###### See also
+
+        [Fully (expanded)](https://weboftrust.github.io/keridoc/docs/glossary/fully-expanded.md) version of an ACDC
+        [Fully compact(ed)](https://weboftrust.github.io/keridoc/docs/glossary/fully-compact.md) version of an ACDC
+
+        [Learn more](https://kerisse.org)
+
+-   ## [multi factor authentication](#multi-factor-authentication)
+
+    -   ### WebOfTrust
+
+        # multi factor authentication
+
+        ###### Definition
+
+        Authentication by combining multiple security factors. Well-known factors are _what you know_, _what you have_ and _what you are_.
+
+        ###### Wikipedia citation
+
+        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/keridoc/docs/glossary/authenticity.md) mechanism.
+        [Source Wikipedia](https://en.wikipedia.org/wiki/Multi-factor_authentication)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [multi valent](#multi-valent)
+
+    -   ### WebOfTrust
+
+        # multi valent
+
+        ###### Definition
+
+        A delegator may have multiple delegates 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.
+
+        ![multivalent-delegated-controller-key-management-infrastructure](https://github.com/weboftrust/WOT-terms/static/img/multivalent-delegated-controller-key-management-infrastructure.png)
+
+        Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith
+
+        ###### Also see
+
+        [Univalent](https://weboftrust.github.io/keridoc/docs/glossary/univalent.md)[Bivalent](https://weboftrust.github.io/keridoc/docs/glossary/bivalent.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [multi-party computation](#h.2x62jfcai7ch)
+
+    -   ### ToIP
+
+        Secure multi-party computation (also known as secure computation, multi-party computation (MPC) or privacy-preserving computation) is a subfield of cryptography with the goal of creating methods for [parties](#h.cn6bno48fomj) to jointly compute a function over their inputs while keeping those inputs private. Unlike traditional cryptographic tasks, where cryptography assures security and [integrity](#h.n34avr5qvr0j) of [communication](#h.w02a6srdng3j) or storage and the adversary is outside the system of participants (an eavesdropper on the sender and receiver), the cryptography in this model protects participants' privacy from each other.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Secure_multi-party_computation&sa=D&source=editors&ust=1718703186744947&usg=AOvVaw3gvXhGAIMLKHZepYux4V8f).
+
+        Also known as: [MPC](#h.ck8vxbqkll6d), [secure multi-party computation](#h.w5uvxlcshb5o).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [multi-party control](#h.lghkwllpu04n)
+
+    -   ### ToIP
+
+        A variant of [multi-party computation](#h.2x62jfcai7ch) where multiple parties must act in concert to meet a control requirement without revealing each other’s data. All parties are privy to the output of the control, but no party learns anything about the others.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [multi-signature](#h.ild3gzrn48xj)
+
+    -   ### ToIP
+
+        A cryptographic [signature](#h.s93np0i5rcne) scheme where the process of signing information (e.g., a transaction) is distributed among multiple [private keys](#h.74y9dvxzg24c).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/multi_signature&sa=D&source=editors&ust=1718703186745612&usg=AOvVaw0bWzufZjvgAg-XJk7DYXMr).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### ToIP (DID:Webs)
+
+        A mechanism that enables multiple parties to sign a message, as defined by the KERI specification. See Controller Application in the KERI spec for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [multicast](#h.nopxfdr8qtr6)
+
+    -   ### ToIP
+
+        In computer networking, multicast is group [communication](#h.w02a6srdng3j) where [data](#h.o783ayrrkc6g) transmission is addressed (using a [multicast address](#h.obmynoe7gkec)) to a group of destination computers simultaneously. Multicast can be one-to-many or many-to-many distribution. Multicast should not be confused with physical layer point-to-multipoint communication.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Multicast&sa=D&source=editors&ust=1718703186743391&usg=AOvVaw018ZPAcDxaSMp56nz9OhE2).
+
+        See also: [anycast](#h.adr8osyk2zcx), [broadcast](#h.s1uti8f9ufsv), [unicast](#h.bqegn99wxkdi).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [multicast address](#h.obmynoe7gkec)
+
+    -   ### ToIP
+
+        A multicast address is a logical [identifier](#h.u3bfehmj4ed3) for a group of [hosts](#h.3f5tvermqc9k) in a computer network that are available to process [datagrams](#h.mxq90rincwo) or frames intended to be [multicast](#h.nopxfdr8qtr6) for a designated network service.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Multicast_address&sa=D&source=editors&ust=1718703186744309&usg=AOvVaw2-Ny7K8_VsPNypQZI6fEEq).
+
+        See also: [broadcast address](#h.7gok5zmnh6an), unicast address.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [multicodec](#multicodec)
+
+    -   ### WebOfTrust
+
+        # multicodec
+
+        ###### Definition
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [multiplexing](#multiplexing)
+
+    -   ### WebOfTrust
+
+        # multiplexing
+
+        ###### Definition
+
+        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)
+
+        ###### CESR related
+
+        Because of [count codes](https://weboftrust.github.io/keridoc/docs/glossary/count-code.md) and the [composability](https://weboftrust.github.io/keridoc/docs/glossary/composability.md) - and [concatenation](https://weboftrust.github.io/keridoc/docs/glossary/concatenation.md) property in CESR, [pipelining](https://weboftrust.github.io/keridoc/docs/glossary/pipelining.md) is possible, which then uses _multiplexing_ (combining [self-framing](https://weboftrust.github.io/keridoc/docs/glossary/self-framing.md) primitives) and _de-multiplexing_ (unravelling self-framing [primitives](https://weboftrust.github.io/keridoc/docs/glossary/primitive.md)). The addition of group framing codes as independently composable primitives enables [hierarchical compositions](https://weboftrust.github.io/keridoc/docs/glossary/hierarchical-composition.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [multisig](#multisig)
+
+    -   ### WebOfTrust
+
+        # multisig
+
+        ###### Definition
+
+        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)
+
+        ###### KERI multi-signatures
+
+        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/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [naive conversion](#naive-conversion)
+
+    -   ### WebOfTrust
+
+        # naive conversion
+
+        ###### Definition
+
+        Non-CESR Base64 conversion. How people are used to using the Base64 encode and decode. Without [pre-pad](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/CESR.md) never uses the '=' pad character. But naive [Base64](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/composability.md) and / or on the [concatenation](https://weboftrust.github.io/keridoc/docs/glossary/concatenation.md) capability of the result of such an operation.
+
+        ###### CESR related
+
+        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/keridoc/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/keridoc/docs/glossary/self-framing.md)
+        -   round-robin [composability](https://weboftrust.github.io/keridoc/docs/glossary/composability.md)
+        -   [concatenation](https://weboftrust.github.io/keridoc/docs/glossary/concatenation.md) options
+        -   [pipelined](https://weboftrust.github.io/keridoc/docs/glossary/pipelining.md) streaming
+
+        [Learn more](https://kerisse.org)
+
+-   ## [namespace](#namespace)
+
+    -   ### WebOfTrust
+
+        # namespace
+
+        ###### Definition
+
+        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.
+        ```
+
+        [Learn more](https://kerisse.org)
+
+-   ## [natural person](#h.yx4qb6dcjdvj)
+
+    -   ### ToIP
+
+        A person (in legal meaning, i.e., one who has its own legal personality) that is an individual human being, distinguished from the broader category of a [legal person](#h.a2q7i8my0jte), which may be a private (i.e., business entity or non-governmental [organization](#h.z27mp1358pi9)) or public (i.e., government) [organization](#h.z27mp1358pi9).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Natural_person&sa=D&source=editors&ust=1718703186746189&usg=AOvVaw1BIsXe85EnFKFojKKZ8HhV).
+
+        See also: [legal entity](#h.5328bxxk02sb), [party](#h.cn6bno48fomj).
+
+        Contrast with: [legal person](#h.a2q7i8my0jte)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [natural thing](#h.njbtirxy3jvo)
+
+    -   ### ToIP
+
+        A [thing](#h.yyvwb9txkdzw) that exists in the natural world independently of humans. Although natural things may form part of a [man-made thing](https://www.google.com/url?q=https://trustoverip.github.io/hxwg/glossary.html%23man-made-thing&sa=D&source=editors&ust=1718703186746925&usg=AOvVaw2CM-vKIF0oZB5Y43OkFCz0), natural things are mutually exclusive with [man-made things](https://www.google.com/url?q=https://trustoverip.github.io/hxwg/glossary.html%23man-made-thing&sa=D&source=editors&ust=1718703186747151&usg=AOvVaw13pz3QfeWR-CUoVptpj5J0).
+
+        Source: [Sovrin Foundation Glossary V3](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit&sa=D&source=editors&ust=1718703186747382&usg=AOvVaw0tcwPUCiCBoAoIzF1A6wmc).
+
+        Contrast with: [man-made thing](#h.98jmqz1068vj).
+
+        For more information see: [Appendix B](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit%23heading%3Dh.mq7pzglc1j96&sa=D&source=editors&ust=1718703186747764&usg=AOvVaw3st-pLsZulQxeiDFW3n55U) and [Appendix C](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit%23heading%3Dh.uiq9py7xnmxd&sa=D&source=editors&ust=1718703186748011&usg=AOvVaw1Ik3KT0Jy-9EoqGMbS0HFw) of the Sovrin Glossary
+
+        Note: Natural things (those recognized to have legal rights) can be [parties](#h.cn6bno48fomj) but never [actors](#h.gzdfngxkp0ip) in the eSSIF-Lab mental model [Parties, Actors, Actions](https://www.google.com/url?q=https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-party-actor-action&sa=D&source=editors&ust=1718703186748362&usg=AOvVaw1a8IRlaYd2U4XSaDW3ASYa).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ndigs](#ndigs)
+
+    -   ### WebOfTrust
+
+        # ndigs
+
+        ###### Definition
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [nested cooperative delegated identifiers](#nested-cooperative-delegated-identifiers)
+
+    -   ### WebOfTrust
+
+        # nested cooperative delegated identifiers
+
+        ###### Definition
+
+        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.
+
+        ##### Recursive application
+
+        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 information
+
+        More in chapter Nested Delegation Recovery of the [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [network address](#h.v9gosdu5b7z5)
+
+    -   ### ToIP
+
+        A network address is an [identifier](#h.u3bfehmj4ed3) for a [node](#h.w1aty8c036fp) or [host](#h.3f5tvermqc9k) on a telecommunications network. Network addresses are designed to be unique [identifiers](#h.u3bfehmj4ed3) across the network, although some networks allow for local, private addresses, or locally administered addresses that may not be unique. Special network addresses are allocated as [broadcast](#h.7gok5zmnh6an) or [multicast](#h.nopxfdr8qtr6) addresses. A network address designed to address a single device is called a [unicast address](#h.2p49ftuui3ug).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Network_address&sa=D&source=editors&ust=1718703186749243&usg=AOvVaw3E0sK96TT4lsgPwUpwJgBz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [node](#h.w1aty8c036fp)
+
+    -   ### ToIP
+
+        In telecommunications networks, a node (Latin: nodus, ‘knot’) is either a redistribution point or a [communication endpoint](#h.qstkv072p5tx). The definition of a node depends on the network and [protocol layer](#h.pe8dekl2dtq0) referred to. A physical network node is an electronic device that is attached to a network, and is capable of creating, receiving, or transmitting information over a [communication channel](#h.oc2pelzel246).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Node_\(networking\)&sa=D&source=editors&ust=1718703186749847&usg=AOvVaw2_ovrIidQLWOrg_T64vO63).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [non establishment event](#non-establishment-event)
+
+    -   ### WebOfTrust
+
+        # non establishment event
+
+        ###### Definition
+
+        A key event tieing or anchoring a data payload to the [key event log](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) of an identifier. This data payload includes a set of one or more [seals](https://weboftrust.github.io/keridoc/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 eventsequence 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)
+
+        ###### Made easier
+
+        A non-establishment event is a key event that does not change the current key-state for an [identifier](https://weboftrust.github.io/keridoc/docs/glossary/identifier.md). The event (only) ties or anchors digital data to the [key event log](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) of the identifier.
+        _(@henkvancann)_
+
+        [Learn more](https://kerisse.org)
+
+-   ## [non fungible token](#non-fungible-token)
+
+    -   ### WebOfTrust
+
+        # non fungible token
+
+        ###### Definition
+
+        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).
+
+        ##### Ownership
+
+        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.
+
+        ##### Fungible
+
+        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).
+
+        ##### KERI / ACDC related
+
+        There's nothing "non fungible" to a Non-fungible Token in our perspective. It's just another unique identifier controlled by a public private key pair. The fact that an NFT uniquely identifies a digital entity isn't very impressing, because of their
+
+        -   security fault : the security is dependent of the host ledger the NFT is anchored to.
+        -   transferability fault : you need a transaction to transfer ownership on the host blockchain, controlling keys can't be rotated
+        -   monitization fault : there's no good reason whatsoever to mingle the value aspect and the uniqueness property of a digital asset, and unfortunately that's what NFTs are doing.
+
+        Because uniqueness tokenization "done right" is to be praised, **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 separate from the identifier system. Key (pre-)rotation can transfer ownership of a unique digital asset without the need of a transaction on a blockchain.
+
+        ##### Asset backing
+
+        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 emcompassing too, because in the KERI/ACDC case we are dealing with globally portable unique digital twins, not anchored to (read `locked in`) a blockchain.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [non interactive authentication design](#non-interactive-authentication-design)
+
+    -   ### WebOfTrust
+
+        # non interactive authentication design
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/zero-trust.md) architectures.
+        More in [source](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw) Keri Request Authentication Mechanism (KRAM) by Samuel Smith
+
+        ###### Related
+
+        [Interactive authentication design](https://weboftrust.github.io/keridoc/docs/glossary/interactive-authentication-design.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [non normative](#non-normative)
+
+    -   ### WebOfTrust
+
+        # non normative
+
+        ###### Definition
+
+        A theory is called non-normative if it does not do what has described under '[Normative](https://weboftrust.github.io/keridoc/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).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [non repudiable](#non-repudiable)
+
+    -   ### WebOfTrust
+
+        # non repudiable
+
+        ###### Definition
+
+        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".
+
+        ###### KERI related
+
+        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 inner-working of KERI's non-repudiation
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [non transferable](#non-transferable)
+
+    -   ### WebOfTrust
+
+        # non transferable
+
+        ###### Definition
+
+        No [capacity to transfer](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/transferable.md).
+
+        For example not legally transferable to the ownership of another entity.
+
+        ###### KERI related
+
+        A specific type of identifier we distinguish is a [non-transferable identifier](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [non transferable identifier](#non-transferable-identifier)
+
+    -   ### WebOfTrust
+
+        # non transferable identifier
+
+        ###### Definition
+
+        Controlling keys over this identifier cannot be rotated and therefore this identifier is [non-transferable](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/transferable.md).
+
+        ###### KERI related
+
+        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/keridoc/docs/glossary/transferable-identifier.md)
+        -   non-transferable identifiers
+        -   [delegated identifiers](https://weboftrust.github.io/keridoc/docs/glossary/delegated-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [non-custodial wallet](#h.ridlo7ub9haf)
+
+    -   ### ToIP
+
+        A [digital wallet](#h.sxnvf3f5v156) that is directly in the control of the [holder](#h.64mptmm24w7u), usually because the holder is the [device controller](#h.tf0m8u61wh87) of the device hosting the [digital wallet](#h.sxnvf3f5v156) (smartcard, smartphone, tablet, laptop, desktop, car, etc.) A [digital wallet](#h.sxnvf3f5v156) that is in the custody of a [third party](#h.zu2vj8151tr) is called a [custodial wallet](#h.5qanwm5930bp).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [normative](#normative)
+
+    -   ### WebOfTrust
+
+        # normative
+
+        ###### Definition
+
+        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).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [objective](#h.k0v6ir8wmcav)
+
+    -   ### ToIP
+
+        Something toward which a [party](#h.cn6bno48fomj) (its [owner](#h.y450rpi0zmuu)) directs effort (an aim, goal, or end of [action](#h.l54nzmooy631)).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/objective&sa=D&source=editors&ust=1718703186750843&usg=AOvVaw2bFGtC12sbKk-auVXoAoDj).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [official organizational role](#official-organizational-role)
+
+    -   ### WebOfTrust
+
+        # official organizational role
+
+        ###### Definition
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [one way function](#one-way-function)
+
+    -   ### WebOfTrust
+
+        # one way function
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [one-time password OTP](#onetimepasswordOTP)
+
+    -   ### digital.govt.nz
+
+        a password that is valid for only 1 login session or transaction\[Source: Wikipedia\]Additional notes:Note 1: Also known as one-time pin or dynamic password.Note 2: Generation can be time-based OTP (TOTP) or event-based OTP also known as hash-based message authentication codes (HMAC) (HOTP).
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [opcode](#opcode)
+
+    -   ### WebOfTrust
+
+        # opcode
+
+        ###### Definition
+
+        Opcodes are meant to provide stream processing instructions that are more general and flexible than simply concatenated primitives or groups of primitives.
+
+        ###### Why opcodes
+
+        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/keridoc/docs/glossary/composable-event-streaming-representation.md).
+
+        ##### Opcode tables
+
+        The ‘\_’ selector is reserved for the yet to be defined [opcode](https://weboftrust.github.io/keridoc/docs/glossary/opcode.md) table or tables.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [operational circumstances](#h.kwek1g2x9lwy)
+
+    -   ### ToIP
+
+        In the context of privacy protection, this term denotes the context in which privacy trade-off decisions are made. It includes the regulatory environment and other non-technical factors that bear on what reasonable privacy expectations might be.
+
+        Source: [PEMC IGR](https://www.google.com/url?q=https://kantarainitiative.org/download/pemc-implementors-guidance-report/&sa=D&source=editors&ust=1718703186752237&usg=AOvVaw22dK8Lx5ed1XbWW5pKosm8)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [optional](#h.9411lfbb9qf2)
+
+    -   ### ToIP
+
+        A [requirement](#h.ajxlw8r3dvcc) that is not [mandatory](#h.n3iynmuwwbf8) or [recommended](#h.db3a5yf4o7iu) to implement in order for an implementer to be in [compliance](#h.r0iiayz1za1i), but which is left to the implementer’s choice. In [ToIP governance frameworks](#h.ns22ebn9xjun), an optional [requirement](#h.ajxlw8r3dvcc) is expressed using a MAY or OPTIONAL keyword as defined in IETF RFC 2119.
+
+        See also: [mandatory](#h.n3iynmuwwbf8), [recommended](#h.db3a5yf4o7iu).
+
+        For more information, see: [https://www.rfc-editor.org/rfc/rfc2119](https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc2119&sa=D&source=editors&ust=1718703186753055&usg=AOvVaw1GhL5Xgf1E8Z2muS1c7JnU).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [organization](#h.z27mp1358pi9)
+
+    -   ### ToIP
+
+        A [party](#h.cn6bno48fomj) that consists of a group of [parties](#h.cn6bno48fomj) who agree to be organized into a specific form in order to better achieve a common set of [objectives](#h.k0v6ir8wmcav). Examples include corporations, partnerships, sole proprietorships, non-profit organizations, associations, and governments.
+
+        See also: [legal entity](#h.5328bxxk02sb), [legal person](#h.a2q7i8my0jte).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23organization&sa=D&source=editors&ust=1718703186753771&usg=AOvVaw1rrk5I1LAI02hqJ_aBdOv2): a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186753960&usg=AOvVaw1gqvitpp9zsDL-FVRnucFg) that is capable of setting [objectives](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/objective&sa=D&source=editors&ust=1718703186754134&usg=AOvVaw023rei-ALvTQsWJRQYOmMb) and making sure these are realized by [actors](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186754352&usg=AOvVaw3nuKa3fd5e1k8CBOlFweY9) that it has [onboarded](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/onboarding&sa=D&source=editors&ust=1718703186754587&usg=AOvVaw3Va3rr5DFre0orcVhtIAfX) and/or by (vetted) [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186754822&usg=AOvVaw3Cpn0T5JeXlyI6s0FQsGBd) that are committed to contribute to these [objectives](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/objective&sa=D&source=editors&ust=1718703186754995&usg=AOvVaw1ZWAyfHjXLWlHuXewBie5o).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [organizational authority](#h.7i5v7dseofok)
+
+    -   ### ToIP
+
+        A type of [authority](#h.gln5i78kxlfh) where the [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186755369&usg=AOvVaw0ykDdPNJbVYpMaz2b0mPOm) asserting its right is an [organization](#h.z27mp1358pi9).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [orphan ~ed](#orphan~ed)
+
+    -   ### digital.govt.nz
+
+        entity information that is not bound to an entity or authenticator
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [out of band introduction](#out-of-band-introduction)
+
+    -   ### WebOfTrust
+
+        # out of band introduction
+
+        ###### Definition
+
+        Out-of-band Introductions (OOBIs) are discovery and validation of IP resources for [KERI](https://weboftrust.github.io/keridoc/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:
+
+        ```code
+        (url, aid)
+        ```
+
+        and concretely
+
+        ```code
+        ("http://8.8.5.6:8080/oobi", "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM")
+        ```
+
+        ###### Validation
+
+        Validation is done based on [BADA](https://weboftrust.github.io/keridoc/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).
+
+        ###### High-end definition
+
+        ![](https://hackmd.io/_uploads/H13bNyPiq.png)
+
+        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/keridoc/docs/glossary/autonomic-identifier-\(AID.md) or [self-addressing identifier (SAID)](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/key-event-receipt-infrastructure.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [out-of-band introduction](#h.tsslu4lnog0s)
+
+    -   ### ToIP
+
+        A process by which two or more [entities](#h.5imtbzl1f4xo) exchange [VIDs](#h.qr5qljyd3se) in order to form a [cryptographically verifiable](#h.422iwwfur12) [connection](#h.thbpewq1px8x) (e.g., a [ToIP connection](#h.5i1yn2scvzvz)), such as by scanning a [QR code](#h.6qi3agm0afv3) (in person or remotely) or clicking a [deep link](#h.ubxk9l39j7w).
+
+        Also known as: [OOBI](#h.1168y6n7c8w).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [out-of-band introduction (OOBI)](#outofbandintroduction\(OOBI\))
+
+    -   ### ToIP (DID:Webs)
+
+        A protocol for discovering verifiable information on an AID or a SAID, as defined by the KERI specification. The OOBI by itself is insecure, and the information discovered by the OOBI must be verified. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [owner](#owner)
+
+    -   ### WebOfTrust
+
+        # owner
+
+        ###### See
+
+        [Owner](https://github.com/trustoverip/toip/wiki/owner) in ToIP glossary
+
+        [Learn more](https://kerisse.org)
+
+-   ## [owner (of an entity)](#h.y450rpi0zmuu)
+
+    -   ### ToIP
+
+        The [role](#h.sf54cyuamo6x) that a [party](#h.cn6bno48fomj) performs when it is exercising its legal, rightful or natural title to control a specific [entity](#h.5imtbzl1f4xo).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23owner&sa=D&source=editors&ust=1718703186756640&usg=AOvVaw3Epr1YjPTgCUZ2BUDdSjZR).
+
+        See also: [controller](#h.gemoqe2m303z).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ownership](#ownership)
+
+    -   ### WebOfTrust
+
+        # ownership
+
+        ###### See
+
+        [Ownership](https://github.com/trustoverip/toip/wiki/ownership) in ToIP glossary
+
+        [Learn more](https://kerisse.org)
+
+-   ## [pad](#pad)
+
+    -   ### WebOfTrust
+
+        # pad
+
+        ###### Definition
+
+        is a [character](https://www.webopedia.com/definitions/character/) used to fill empty space, because many [applications](https://www.webopedia.com/definitions/application-software/) have [fields](https://www.webopedia.com/definitions/field/) that must be a particular length.
+        [Source](https://www.webopedia.com/definitions/pad-character/)
+
+        ###### KERI related
+
+        In order to avoid confusion with the use of the term _pad_ character, when pre-padding with bytes that are not replaced later, we use the term [lead bytes](https://weboftrust.github.io/keridoc/docs/glossary/lead-bytes.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [parside](#parside)
+
+    -   ### WebOfTrust
+
+        # parside
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/count-code.md). (Source Cesride: meeting Feb 2 2023)
+
+        ###### Background
+
+        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/keridoc/docs/glossary/strip-parameter.md) tells us what part will be parsed be which code.
+
+        ###### Design ideas Feb 2023
+
+        1.  Parside should be concerned with parsing group codes, [cesride](https://weboftrust.github.io/keridoc/docs/glossary/cesride.md) concerned with parsing primitives.
+        2.  Parside will contain a [count code](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/docs/glossary/group-code.md)
+
+        | TBW |
+
+        ###### Related
+
+        -   [Version code](https://weboftrust.github.io/keridoc/docs/glossary/version-code.md)
+        -   [Version string](https://weboftrust.github.io/keridoc/docs/glossary/version-string.md)
+        -   [Strip parameter](https://weboftrust.github.io/keridoc/docs/glossary/strip-parameter.md)
+        -   [Cesride](https://weboftrust.github.io/keridoc/docs/glossary/cesride.md)
+        -   [Sniffer](https://weboftrust.github.io/keridoc/docs/glossary/sniffer.md)
+
+        Source Cesride: meeting Feb 2 2023
+
+        ###### Working
+
+        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/keridoc/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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [partial disclosure](#partial-disclosure)
+
+    -   ### WebOfTrust
+
+        # partial disclosure
+
+        ###### Definition
+
+        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.
+
+        ###### Related
+
+        [Selective disclosure](https://weboftrust.github.io/keridoc/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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [partial pre rotation](#partial-pre-rotation)
+
+    -   ### WebOfTrust
+
+        # partial pre rotation
+
+        ###### See
+
+        [Partial rotation](https://weboftrust.github.io/keridoc/docs/glossary/partial-rotation.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [partial rotation](#partial-rotation)
+
+    -   ### WebOfTrust
+
+        # partial rotation
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/reserve-rotation.md)
+        -   [Custodial rotation](https://weboftrust.github.io/keridoc/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.
+
+        ###### More detailed explanation
+
+        A valid rotation operation requires the satisfaction of two different thresholds. These are the current [threshold](https://weboftrust.github.io/keridoc/docs/glossary/signing-threshold.md) of the given [rotation](https://weboftrust.github.io/keridoc/docs/glossary/rotation.md) ([establishment](https://weboftrust.github.io/keridoc/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/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [party](#party)
+
+    -   ### digital.govt.nz
+
+        an entity who participates or is concerned in an action, proceeding, plan, etc.\[Source: Dictionary modified to include non-persons\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### Nist
+
+        An individual (person), organization, device, or a combination thereof. In this Recommendation, an entity may be a functional unit that executes certain processes.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/party)
+
+    -   ### ToIP
+
+        An [entity](#h.5imtbzl1f4xo) that sets its [objectives](#h.k0v6ir8wmcav), maintains its [knowledge](#h.k96lktyswxnb), and uses that [knowledge](#h.k96lktyswxnb) to pursue its [objectives](#h.k0v6ir8wmcav) in an autonomous (sovereign) manner. Humans and [organizations](#h.z27mp1358pi9) are the typical examples.
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary&sa=D&source=editors&ust=1718703186757677&usg=AOvVaw0az_jqwASyCHdiLgYipcoU).
+
+        See also: [first party](#h.uxx5bjam20ag), [second party](#h.hk94wskqnzri), [third party](#h.zu2vj8151tr), [natural person](#h.yx4qb6dcjdvj)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # party
+
+        ###### Definition
+
+        An entity who participates or is concerned in an action, proceeding, plan, etc.
+        Source: ToIP
+
+        [Learn more](https://kerisse.org)
+
+-   ## [passcode](#passcode)
+
+    -   ### WebOfTrust
+
+        # passcode
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [password](#h.5u3l7bhbpjno)
+
+    -   ### ToIP
+
+        A string of characters (letters, numbers and other symbols) that are used to authenticate an identity, verify access authorization or derive cryptographic keys.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/password&sa=D&source=editors&ust=1718703186758265&usg=AOvVaw1FLPlPJtOGBkKOL0ts8pHn).
+
+        See also: [complex password](#h.ydm2hpca9zws).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [pathing](#pathing)
+
+    -   ### WebOfTrust
+
+        # pathing
+
+        ###### Definition
+
+        It was designed send to sign portions of a credential. Designed for 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).
+
+        ###### Important
+
+        We don't sign our credentials, you shouldn't either!
+
+        Source: Philip Feairheller, July 20 2023, KERI-dev meeting
+
+        [Learn more](https://kerisse.org)
+
+-   ## [payload](#payload)
+
+    -   ### WebOfTrust
+
+        # payload
+
+        ###### Definition
+
+        The term 'payload' is used to distinguish between the 'interesting' information in a chunk of data or similar, and the overhead to support it. 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).
+
+        ###### KERI context
+
+        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 keyNote tha KERI never puts raw data or privacy-sensitive data in a `KEL` or `KERL`.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [peer](#h.269t7i1hwzp)
+
+    -   ### ToIP
+
+        In the context of digital networks, an [actor](#h.gzdfngxkp0ip) on the network that has the same status, privileges, and communications options as the other actors on the network.
+
+        See also: [peer-to-peer](#h.ikjsqxobvozv).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23peer-actor&sa=D&source=editors&ust=1718703186758889&usg=AOvVaw2IVYxSDN3oh4I16qDCLbFH): the [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186759060&usg=AOvVaw10hS7yCa28ummRFI62kSfv) with whom/which this other [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186759268&usg=AOvVaw3Kw-uBRZTZMSoOB4usxjzs) is communicating in that [communication session](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/communication-session&sa=D&source=editors&ust=1718703186759436&usg=AOvVaw1FFxgptVJ8fyBaues7GhvJ).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [peer to peer](#peer-to-peer)
+
+    -   ### WebOfTrust
+
+        # peer to peer
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [peer-to-peer](#h.ikjsqxobvozv)
+
+    -   ### ToIP
+
+        Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or workloads between [peers](#h.269t7i1hwzp). [Peers](#h.269t7i1hwzp) are equally privileged, equipotent participants in the network. This forms a peer-to-peer network of [nodes](#h.w1aty8c036fp).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Peer-to-peer&sa=D&source=editors&ust=1718703186760063&usg=AOvVaw28vmmTkpYHqeObUEwFbzEM).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [percolated information discovery](#percolated-information-discovery)
+
+    -   ### WebOfTrust
+
+        # percolated information discovery
+
+        ###### Definition
+
+        In the OOBI protocol, a discovery mechanism for the KERI and the ACDC 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
+
+        [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 Theory
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [permission](#h.mnqlrmrkqb9)
+
+    -   ### ToIP
+
+        [Authorization](#h.576ssfpt348i) to perform some [action](#h.l54nzmooy631) on a system.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/permission&sa=D&source=editors&ust=1718703186760459&usg=AOvVaw0kHZGG5-k--phXAXYxqqIw).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [persistent connection](#h.ccf1vkxvhh1l)
+
+    -   ### ToIP
+
+        A [connection](#h.thbpewq1px8x) that is able to persist across multiple [communication sessions](#h.i82tgrmxy0d8). In a ToIP context, a persistent connection is established when two [ToIP endpoints](#h.e787fzjepk60) exchange [verifiable identifiers](#h.wyda231qefe) that they can use to re-establish the [connection](#h.thbpewq1px8x) with each other whenever it is needed.
+
+        Contrast with: [ephemeral connection](#h.5xjtv29e8z6i).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [persistent data structure](#persistent-data-structure)
+
+    -   ### WebOfTrust
+
+        # persistent data structure
+
+        ###### Definition
+
+        An append only verifiable data structure. What we sign may not change.
+
+        ###### Related Work
+
+        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).
+
+        ###### ACDC Related
+
+        The persistent data structure is a graph
+
+        [Learn more](https://kerisse.org)
+
+-   ## [persistent identifier](#persistent-identifier)
+
+    -   ### WebOfTrust
+
+        # persistent identifier
+
+        ###### See
+
+        [Transferable Identifiers](https://weboftrust.github.io/keridoc/docs/glossary/transferable-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [personal data](#h.rpiib2ml3s9c)
+
+    -   ### ToIP
+
+        Any information relating to an identified or identifiable [natural person](#h.yx4qb6dcjdvj) (called a [data subject](#h.3r9gd9iy7a6e) under [GDPR](#h.5oxryjdg8s9w)).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/personal_data&sa=D&source=editors&ust=1718703186761568&usg=AOvVaw3PIrDM3z5RqmvLZkliBpSh).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [personal data store](#h.988mlodymjse)
+
+    -   ### ToIP
+
+        See: [personal data vault](#h.9b2ram5w4omg).
+
+        Note: In the market, the term “personal data store” has also been used to generally mean a combination of the functions of a personal [digital agent](#h.z3ugzt4hgdf6), [personal wallet](#h.1qe7g02c5t4p), and [personal data vault](#h.9b2ram5w4omg).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [personal data vault](#h.9b2ram5w4omg)
+
+    -   ### ToIP
+
+        A [digital vault](#h.cz29glapo2tg) whose [controller](#h.gemoqe2m303z) is a [natural person](#h.yx4qb6dcjdvj).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [personal wallet](#h.1qe7g02c5t4p)
+
+    -   ### ToIP
+
+        A [digital wallet](#h.sxnvf3f5v156) whose [holder](#h.64mptmm24w7u) is a [natural person](#h.yx4qb6dcjdvj).
+
+        Contrast with: [enterprise wallet](#h.lwbrzpnzaqth).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [personally identifiable information](#h.yww9djvhorxc)
+
+    -   ### ToIP
+
+        Information (any form of [data](#h.o783ayrrkc6g)) that can be used to directly or indirectly [identify](#h.z1gairv0pej5) or re-identify an individual person either singly or in combination within a single [record](#h.y4ybzkfe6yzv) or in correlation with other [records](#h.y4ybzkfe6yzv). This information can be one or more [attributes](#h.ky5nh3yri7ak)/fields/[properties](#h.c8vs1xa4uwn) in a [record](#h.y4ybzkfe6yzv) (e.g., date-of-birth) or one or more [records](#h.y4ybzkfe6yzv) (e.g., medical records).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/personally_identifiable_information&sa=D&source=editors&ust=1718703186763575&usg=AOvVaw3ExgKzkykN0bKp4ozv8zcV)
+
+        Also known as: [PII](#h.pumw0ocr1xf2).
+
+        See also: [personal data](#h.rpiib2ml3s9c), [sensitive data](#h.l8f0y0lobzpi).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [physical credential](#h.xnlz1vfx60mn)
+
+    -   ### ToIP
+
+        A [credential](#h.kcj6iw2vib1v) in a physical form such as paper, plastic, or metal.
+
+        Contrast with: [digital credential](#h.ddna9lucn4k6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [pii](#pii)
+
+    -   ### WebOfTrust
+
+        # pii
+
+        ###### Definition
+
+        personally identifiable information
+
+        [Learn more](https://kerisse.org)
+
+-   ## [pipelining](#pipelining)
+
+    -   ### WebOfTrust
+
+        # pipelining
+
+        ###### Definition
+
+        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\))
+
+        ###### Why CESR needs to anticipate pipelining
+
+        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.
+
+        ##### JSON is slow
+
+        With JSON I don’t know where the end is, so I have to parse the initial stream to find out. That's slow.
+
+        ##### Meaning of Pipelining
+
+        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/keridoc/docs/glossary/CESR.md) is the only streaming protocol that has this anticipation on board.
+        Source: Samuel Smith, KERI Zoom meeting Dec 5 2023.
+
+        ##### Related
+
+        [Multiplexing](https://weboftrust.github.io/keridoc/docs/glossary/multiplexing.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [plaintext](#h.ylf3pqlex968)
+
+    -   ### ToIP
+
+        Unencrypted information that may be input to an [encryption](#h.iyq318f2vg61) operation. Once encrypted, it becomes [ciphertext](#h.9ripqbaz7egw).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/plaintext&sa=D&source=editors&ust=1718703186765040&usg=AOvVaw30yQYBDyMWv1OQjELWUPjN).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [policy](#h.udts41hso4w4)
+
+    -   ### ToIP
+
+        Statements, rules or assertions that specify the correct or expected behavior of an entity. For example, an [authorization](#h.576ssfpt348i) policy might specify the correct [access control](#h.lmk4gqobt99b) rules for a software component. Policies may be [human-readable](#h.ywyofmy4do4t) or [machine-readable](#h.8s3s84fzcfi3) or both.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/policy&sa=D&source=editors&ust=1718703186765725&usg=AOvVaw16tYnYfJd365qHHc4BZuQ_)
+
+        See also: [governance framework](#h.2x05z0r097mn), [governance requirement](#h.j4z5czk0dk8t), [rule](#h.v7s575ulon74).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [post pad](#post-pad)
+
+    -   ### WebOfTrust
+
+        # post pad
+
+        ###### Definition
+
+        the action and / or result of extending a string with _trailing_ pad characters to align to a certain length in bits or bytes.
+
+        ###### CESR related
+
+        There are two ways to provide the required alignment on 24-bit boundaries to satisfy the [composability](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/naive-conversion.md) does.
+        The other way is to [pre-pad](https://weboftrust.github.io/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [post quantum](#post-quantum)
+
+    -   ### WebOfTrust
+
+        # post quantum
+
+        ###### Definition
+
+        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)
+
+        ###### KERI pre-rotation related
+
+        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/keridoc/docs/glossary/entropy.md) might be used for key generation.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [pre pad](#pre-pad)
+
+    -   ### WebOfTrust
+
+        # pre pad
+
+        ###### Definition
+
+        the action and / or result of prepending a string with _leading_ pad characters to align to a certain length in bits or bytes.
+
+        ###### CESR related
+
+        There are two ways to provide the required alignment on 24-bit boundaries to satisfy the [composability](https://weboftrust.github.io/keridoc/docs/glossary/composability.md) property. One is [post-pad](https://weboftrust.github.io/keridoc/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/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [pre rotation](#pre-rotation)
+
+    -   ### WebOfTrust
+
+        # pre rotation
+
+        ###### Definition
+
+        Cryptographic commitment to next rotated key set in previous rotation or [inception event](https://weboftrust.github.io/keridoc/docs/glossary/inception-event.md).
+
+        ###### Rotation
+
+        The main purpose of [key rotation](https://weboftrust.github.io/keridoc/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
+
+        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.
+
+        ###### Origin and technique
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [pre-rotation](#prerotation)
+
+    -   ### ToIP (DID:Webs)
+
+        A key rotation mechanism whereby a set of rotation keys are pre-commited using cryptographic digests, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [prefix](#prefix)
+
+    -   ### WebOfTrust
+
+        # prefix
+
+        ###### Definition
+
+        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`
+
+        ![Basic Prefix Derivation image](https://github.com/WebOfTrust/keri/blob/main/images/prefix.png?raw=true)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [present ~ation](#present~ation)
+
+    -   ### digital.govt.nz
+
+        (verb) to offer or hand over for action or settlement\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [presentation](#h.h5d1xfsxbbr0)
+
+    -   ### ToIP
+
+        A [verifiable](#h.k2qmzn3tjzsl) [message](#h.bge7ubygwk2q) that a [holder](#h.64mptmm24w7u) may send to a [verifier](#h.xfewd7t01hu0) containing [proofs](#h.r2qw6757lopw) of one or more [claims](#h.akieli6njkk5) derived from one or more [digital credentials](#h.ddna9lucn4k6) from one or more [issuers](#h.xyrplzbvtffq) as a response to a specific [presentation request](#h.onnn49cjzreh) from a  [verifier](#h.xfewd7t01hu0).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/presentation&sa=D&source=editors&ust=1718703186766870&usg=AOvVaw1ATMkFlPhQVh8YjO9QxPNv): A (signed) digital [message](#h.bge7ubygwk2q) that a [holder](#h.64mptmm24w7u) component may send to a [verifier](#h.xfewd7t01hu0) component that contains [data](#h.o783ayrrkc6g) derived from one or more [verifiable credentials](#h.co5algna3zkh) (that (a [colleague](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/colleague&sa=D&source=editors&ust=1718703186767309&usg=AOvVaw2OrZX9ePtlyuBba1pXweeL) component of) the [holder](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/holder&sa=D&source=editors&ust=1718703186767532&usg=AOvVaw31z476nRraFxAe2sW7IGI9) component has received from [issuer](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/issuer&sa=D&source=editors&ust=1718703186767704&usg=AOvVaw3YtP_7nFgctoFUaVoFNNmm) components of one or more [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186767852&usg=AOvVaw1QMWXwl2j9ju3me8cIub9e)), as a response to a specific [presentation request](#h.onnn49cjzreh) of a  [verifier](#h.xfewd7t01hu0) component.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [presentation attack](#h.p0f7ugeoyf0l)
+
+    -   ### ToIP
+
+        A type of cybersecurity attack in which the attacker attempts to defeat a [biometric](#h.grifxl8vyuuu) [liveness detection](#h.v2edf5qj0ig4) system by providing false inputs.
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/presentation_attack&sa=D&source=editors&ust=1718703186768505&usg=AOvVaw0Cqoyfk5N2_JvfeXLEO-M1): Presentation to the biometric data capture subsystem with the goal of interfering with the operation of the biometric system.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [presentation exchange](#presentation-exchange)
+
+    -   ### WebOfTrust
+
+        # presentation exchange
+
+        ###### Definition
+
+        An exchange that provides disclosure of one or more [ACDC](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/authenticity.md) information may be exchanged between two parties, namely, the [Discloser](https://weboftrust.github.io/keridoc/docs/glossary/discloser.md) and [Disclosee](https://weboftrust.github.io/keridoc/docs/glossary/disclosee.md).
+
+        ###### Rule
+
+        Each ACDC MUST have an [Issuer](https://weboftrust.github.io/keridoc/docs/glossary/issuer.md) and MAY have an [Issuee](https://weboftrust.github.io/keridoc/docs/glossary/issuee.md). The set of [ACDC](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/directed-acyclic-graph.md) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [presentation request](#h.onnn49cjzreh)
+
+    -   ### ToIP
+
+        A protocol request sent by the [verifier](#h.xfewd7t01hu0) to the [holder](#h.64mptmm24w7u) of a [digital wallet](#h.sxnvf3f5v156) to request a [presentation](#h.h5d1xfsxbbr0).
+
+        See also: [issuance request](#h.tt253lgfp4hz).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [pretty good privacy](#pretty-good-privacy)
+
+    -   ### WebOfTrust
+
+        # pretty good privacy
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/GPG.md) term.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [primary document](#h.2106nmcoo867)
+
+    -   ### ToIP
+
+        The [governance document](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.c8fvvxachz5h&sa=D&source=editors&ust=1718703186769299&usg=AOvVaw0InhOrkcy7yq4yFNIL-ywn) at the root of a [governance framework](#h.2x05z0r097mn). The primary document specifies the other [controlled documents](#h.t0afqk7h7n97) in the governance framework.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [primary root of trust](#primary-root-of-trust)
+
+    -   ### WebOfTrust
+
+        # primary root of trust
+
+        ###### Definition
+
+        In KERI a [root-of-trust](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [primitive](#primitive)
+
+    -   ### WebOfTrust
+
+        # primitive
+
+        ###### Definition
+
+        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)
+
+        ###### Cryptographic primitive
+
+        See [Cryptographic primitive](https://weboftrust.github.io/keridoc/docs/glossary/cryptographic-primitive.md)
+
+        ###### KERI related
+
+        In KERI and ACDC it a serialization of a unitary value. A [cryptographic primitive](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/composable-event-streaming-representation.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [principal](#h.sydbe7rk6244)
+
+    -   ### ToIP
+
+        The [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186769680&usg=AOvVaw3KeJ0LqZgaP3DvhwhBeGcg) for whom, or on behalf of whom, an [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186769836&usg=AOvVaw2qJpot1jbco7WdRLNQ7pLi) is executing an [action](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/action&sa=D&source=editors&ust=1718703186769989&usg=AOvVaw1VG1y4-WDr30gQM0Rr2CDa) (this [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186770160&usg=AOvVaw0NIPogQlJIuKyAbYSlnlJP) is then called an [agent](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/agent&sa=D&source=editors&ust=1718703186770324&usg=AOvVaw0hqtrxB8W4FDBzyyNoWn8Q) of that [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186770464&usg=AOvVaw2NUu6TFnYGdtRT_12oXous)).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23principal&sa=D&source=editors&ust=1718703186770753&usg=AOvVaw0F-q9_u-7KaugC43Tl2Oct)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [privacy](#privacy)
+
+    -   ### WebOfTrust
+
+        # privacy
+
+        ###### Definition
+
+        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)
+
+        ###### KERI related
+
+        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.
+
+        ###### Also see
+
+        -   [authenticity](https://weboftrust.github.io/keridoc/docs/glossary/authenticity.md)
+        -   [confidentiality](https://weboftrust.github.io/keridoc/docs/glossary/confidentiality.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [privacy policy](#h.xbjzswct9aqi)
+
+    -   ### ToIP
+
+        A statement or legal document (in privacy law) that discloses some or all of the ways a [party](#h.cn6bno48fomj) gathers, uses, discloses, and manages a customer or client's [data.](#h.o783ayrrkc6g)
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Privacy_policy&sa=D&source=editors&ust=1718703186771822&usg=AOvVaw2jW9bYEkDKLYcJwURk0Kut)
+
+        See also: [security policy](#h.2fcbwog0w43a).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [privacy washing](#privacy-washing)
+
+    -   ### WebOfTrust
+
+        # privacy washing
+
+        ###### Definition
+
+        De-identification so that it provides a personal data safe harbour and could be legally acceptable forwarded.
+
+        ###### Possible solution
+
+        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".
+
+        [Learn more](https://kerisse.org)
+
+-   ## [private key](#h.74y9dvxzg24c)
+
+    -   ### ToIP
+
+        In [public key cryptography](#h.jhvr6rbo5z3q), the [cryptographic key](#h.53rzpn1yn6q7) which must be kept secret by the [controller](#h.gemoqe2m303z) in order to maintain security.
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/private_key&sa=D&source=editors&ust=1718703186772368&usg=AOvVaw2wRK0zcfNeRCvWM29wOBa_): The secret part of an asymmetric key pair that is typically used to digitally sign or decrypt data.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [promiscuous mode](#promiscuous-mode)
+
+    -   ### WebOfTrust
+
+        # promiscuous mode
+
+        ###### Definition
+
+        It is the mode a [watcher](https://weboftrust.github.io/keridoc/docs/glossary/watcher.md) runs in. A watcher uses the same code as a [witness](https://weboftrust.github.io/keridoc/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)
+
+        ###### Meaning
+
+        The function of watcher is different from a witness, however they can both use the same protocol and code, just in a distinct mode.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [proof](#h.r2qw6757lopw)
+
+    -   ### ToIP
+
+        A digital object that enables [cryptographic verification](#h.lbqfpvfmcmoq) of either: a) the [claims](#h.akieli6njkk5) from one or more [digital credentials](#h.ddna9lucn4k6), or b) facts about [claims](#h.akieli6njkk5) that do not reveal the [data](#h.o783ayrrkc6g)  itself (e.g., proof of the [subject](#h.voca6uuv1a4) being over/under a specific age without revealing a birthdate).
+
+        See also: [zero-knowledge proof](#h.zc9pf8eexjs).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [proof of authority](#proof-of-authority)
+
+    -   ### WebOfTrust
+
+        # proof of authority
+
+        ###### Definition
+
+        Proof that somebody or something has certain rights or permissions. It's about _data_. Whereas [proof of authorship](https://weboftrust.github.io/keridoc/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.
+
+        ###### ACDC and proofs
+
+        _Proof of authorship_ and [proof of authority](https://weboftrust.github.io/keridoc/docs/glossary/proof-of-authority.md) are integrated in [Authentic Chained Data Containers (ACDCs)](https://weboftrust.github.io/keridoc/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))
+
+        ##### Example APC : book rights sold
+
+        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/keridoc/docs/glossary/controller.md) over the book and its digital twin: the proof of authority by the chain of ACDCs.
+
+        ###### Do not confuse blockchains or consensus algorithms
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [proof of authorship](#proof-of-authorship)
+
+    -   ### WebOfTrust
+
+        # proof of authorship
+
+        ###### Definition
+
+        Proof that somebody or something has originally created certain content. It's about _data_'s inception. Whereas [proof-of-authority](https://weboftrust.github.io/keridoc/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\))
+
+        ###### ACDC and proofs
+
+        _Proof of authorship_ and [proof of authority](https://weboftrust.github.io/keridoc/docs/glossary/proof-of-authority.md) are integrated in [Authentic Chained Data Containers (ACDCs)](https://weboftrust.github.io/keridoc/docs/glossary/authentic-chained-data-container.md) constituting an [Authentic Provenance Chain (APC)](https://weboftrust.github.io/keridoc/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))
+
+        ##### Example APC : book rights sold
+
+        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/keridoc/docs/glossary/controller.md) over the book and its digital twin: the proof of authority by the chain of ACDCs.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [proof of control](#h.3ss2tnb5pf4s)
+
+    -   ### ToIP
+
+        See: [proof of possession](#h.s0sx91peii5f).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [proof of personhood](#h.1686ws2z2rnl)
+
+    -   ### ToIP
+
+        Proof of personhood (PoP) is a means of resisting malicious attacks on [peer-to-peer](#h.ikjsqxobvozv) networks, particularly, attacks that utilize multiple fake [identities](#h.z1gairv0pej5), otherwise known as a [Sybil attack](#h.jkl5esndzhl8). Decentralized online platforms are particularly vulnerable to such attacks by their very nature, as notionally democratic and responsive to large voting blocks. In PoP, each unique human participant obtains one equal unit of voting power, and any associated rewards.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Proof_of_personhood&sa=D&source=editors&ust=1718703186773574&usg=AOvVaw3JM8VlhKlv1iSL8KDRl6yi).
+
+        Also known as: [PoP](#h.3u71l1o5j9qt).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [proof of possession](#h.s0sx91peii5f)
+
+    -   ### ToIP
+
+        A [verification](#h.2bnb6g8na7cu) process whereby a [level of assurance](#h.qseghs6dqcd) is obtained that the owner of a [key pair](#h.53rzpn1yn6q7) actually controls the [private key](#h.74y9dvxzg24c) associated with the [public key](#h.hohpk6z1qk4f).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/proof_of_possession&sa=D&source=editors&ust=1718703186774136&usg=AOvVaw0LhLfZtFf3n1ZeFaEKTE-Q).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [proof of presence](#h.gmumid2hix8v)
+
+    -   ### ToIP
+
+        See: [liveness detection](#h.v2edf5qj0ig4).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [property](#h.c8vs1xa4uwn)
+
+    -   ### ToIP
+
+        In the context of digital communication, an [attribute](#h.ky5nh3yri7ak) of a digital object or [data](#h.o783ayrrkc6g) structure, such as a [DID document](#h.yjwocacp570p) or a [schema](#h.rwxa1n5inr2e).
+
+        See also: [attribute](#h.ky5nh3yri7ak), [claim](#h.akieli6njkk5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [protected data](#h.7dgrgq3e85jg)
+
+    -   ### ToIP
+
+        [Data](#h.o783ayrrkc6g) that is not publicly available but requires some type of [access control](#h.lmk4gqobt99b) to gain access.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [protocol](#protocol)
+
+    -   ### WebOfTrust
+
+        # protocol
+
+        ###### Definition
+
+        Generic term to describe a code of correct conduct. Also called "[etiquette](https://en.wikipedia.org/wiki/Etiquette)": a code of personal behavior.
+
+        ###### KERI and ACDC related
+
+        We can distinguish three relevant elaborations on the term 'protocol' to make the concept more specific:
+
+        -   [Communication protocol](https://en.wikipedia.org/wiki/Communication_protocol), a defined set of rules and regulations that determine how data is transmitted in telecommunications and computer networking
+        -   [Cryptographic protocol](https://en.wikipedia.org/wiki/Cryptographic_protocol), a protocol for encrypting messages
+        -   [Decentralized network protocol](https://en.wikipedia.org/wiki/Decentralized_network_protocol), a protocol for operation of an [open source](https://en.wikipedia.org/wiki/Open_source_software) [peer-to-peer](https://en.wikipedia.org/wiki/Peer-to-peer) network where no single entity nor colluding group controls a majority of the network nodes
+            Paraphrased by @henkvancann from source on Wikipedia (click on individual links).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [protocol layer](#h.pe8dekl2dtq0)
+
+    -   ### ToIP
+
+        In modern protocol design, protocols are layered to form a [protocol stack](#h.6ik2cef0ipsr). Layering is a design principle that divides the protocol design task into smaller steps, each of which accomplishes a specific part, interacting with the other parts of the protocol only in a small number of well-defined ways. Layering allows the parts of a protocol to be designed and tested without a combinatorial explosion of cases, keeping each design relatively simple.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Communication_protocol%23Layering&sa=D&source=editors&ust=1718703186775370&usg=AOvVaw0cou_2Dgnl_3E1r84FDzqn).
+
+        See also: [hourglass model](#h.u8d1rxc2o86), [ToIP stack](#h.wms58fgdch9m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [protocol stack](#h.6ik2cef0ipsr)
+
+    -   ### ToIP
+
+        The protocol stack or network stack is an implementation of a computer networking protocol suite or protocol family. Some of these terms are used interchangeably but strictly speaking, the suite is the definition of the communication protocols, and the stack is the software implementation of them.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Protocol_stack&sa=D&source=editors&ust=1718703186775979&usg=AOvVaw0Ujzwopa-O9rJ3JawUlAAa)
+
+        See also: [protocol layer](#h.pe8dekl2dtq0).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [provenance](#provenance)
+
+    -   ### WebOfTrust
+
+        # provenance
+
+        ###### Defintion
+
+        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.
+
+        ###### Purpose
+
+        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))
+
+        ###### Provenance and ACDC
+
+        [Authentic chained data containers (ACDC)](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/credential.md) (result: attested [veracity](https://weboftrust.github.io/keridoc/docs/glossary/veracity.md))
+            (_@henkvancann_)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [provenanced](#provenanced)
+
+    -   ### WebOfTrust
+
+        # provenanced
+
+        ###### Definition
+
+        The act of verifying [authenticity](https://weboftrust.github.io/keridoc/docs/glossary/authenticity.md) or quality of documented history or origin of something
+
+        ###### KERI specific
+
+        Focus on authenticity. See [provenance](https://weboftrust.github.io/keridoc/docs/glossary/provenance.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [pseudo random number](#pseudo-random-number)
+
+    -   ### WebOfTrust
+
+        # pseudo random number
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [pseudonym](#h.tgbgt5tqzl4m)
+
+    -   ### ToIP
+
+        A pseudonym is a fictitious name that a [person](#h.yx4qb6dcjdvj) assumes for a particular purpose, which differs from their original or true name (orthonym). This also differs from a new name that entirely or legally replaces an individual's own. Many pseudonym [holders](#h.64mptmm24w7u) use pseudonyms because they wish to remain [anonymous](#h.95pnj4tchl4m), but anonymity is difficult to achieve and often fraught with legal issues.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Pseudonym&sa=D&source=editors&ust=1718703186776556&usg=AOvVaw34RNN02hz32mjST2FnFx9c).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [pseudonymous](#pseudonymous)
+
+    -   ### digital.govt.nz
+
+        using a pseudonym\[Source: Dictionary\]Additional note:Note 1: A pseudonym being an identifier that may relate to an individual entity but does not allow the entity to be identifiable outside the context.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [public key](#h.hohpk6z1qk4f)
+
+    -   ### ToIP
+
+        [Drummond Reed](mailto:drummond.reed@avast.com): In [public key cryptography](#h.jhvr6rbo5z3q), the [cryptographic key](#h.53rzpn1yn6q7) that can be freely shared with anyone by the [controller](#h.gemoqe2m303z) without compromising security. A [party’s](#h.cn6bno48fomj) public key must be verified as [authoritative](#h.gln5i78kxlfh) in order to verify their [digital signature](#h.s93np0i5rcne).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/public_key&sa=D&source=editors&ust=1718703186777286&usg=AOvVaw0k9y9xFKwd5gK_dHKSv1wM): The public part of an asymmetric key pair that is typically used to verify signatures or encrypt data.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [public key certificate](#h.anf8g7aq0gk5)
+
+    -   ### ToIP
+
+        A set of [data](#h.o783ayrrkc6g) that uniquely identifies a [public key](#h.hohpk6z1qk4f) (which has a corresponding [private key](#h.74y9dvxzg24c)) and an [owner](#h.y450rpi0zmuu) that is authorized to use the [key pair](#h.53rzpn1yn6q7). The certificate contains the owner’s [public key](#h.hohpk6z1qk4f) and possibly other information and is [digitally signed](#h.s93np0i5rcne) by a [certification authority](#h.lubcv4tm2i7r) (i.e., a trusted [party](#h.cn6bno48fomj)), thereby binding the [public key](#h.hohpk6z1qk4f) to the [owner](#h.y450rpi0zmuu).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/public_key_certificate&sa=D&source=editors&ust=1718703186778260&usg=AOvVaw3-8ps0cAuyQI5ac1hpLVq4).
+
+        See also: [public key infrastructure](#h.mdxu5kpbdo4x).
+
+        Supporting definitions:
+
+        Wikipedia : In [cryptography](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Cryptography&sa=D&source=editors&ust=1718703186778604&usg=AOvVaw1ANfGrWhNqdWt-Bg0WL9J8), a public key certificate, also known as a digital certificate or identity certificate, is an [electronic document](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_document&sa=D&source=editors&ust=1718703186778754&usg=AOvVaw1qujl7s2qcBdSPSEFtdpBU) used to prove the validity of a [public key](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Key_authentication&sa=D&source=editors&ust=1718703186778923&usg=AOvVaw1_uR-yE95PaqgL9DGrIeDJ). The certificate includes information about the key, information about the identity of its owner (called the subject), and the [digital signature](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_signature&sa=D&source=editors&ust=1718703186779153&usg=AOvVaw2Tkh-TVqFV-ENpnetekSyC) of an entity that has verified the certificate's contents (called the issuer). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In [email encryption](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Email_encryption&sa=D&source=editors&ust=1718703186779319&usg=AOvVaw0h-SX3JgMwFPpxwopqzqx-), [code signing](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Code_signing&sa=D&source=editors&ust=1718703186779460&usg=AOvVaw3CD4zGTOX16McAGeZvrgKI), and [e-signature](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_signature&sa=D&source=editors&ust=1718703186779612&usg=AOvVaw0GAcEwTCzvqZUCTxF8pC9A) systems, a certificate's subject is typically a person or organization. However, in [Transport Layer Security](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Transport_Layer_Security&sa=D&source=editors&ust=1718703186779762&usg=AOvVaw0u2Tc8sSZkV9HIgcEtexRQ) (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [public key cryptography](#h.jhvr6rbo5z3q)
+
+    -   ### ToIP
+
+        Public key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related [keys](#h.53rzpn1yn6q7). Each key pair consists of a [public key](#h.hohpk6z1qk4f) and a corresponding [private key](#h.74y9dvxzg24c). [Key pairs](#h.53rzpn1yn6q7) are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public key cryptography depends on keeping the [private key](#h.74y9dvxzg24c) secret; the [public key](#h.hohpk6z1qk4f) can be openly distributed without compromising security.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public-key_cryptography&sa=D&source=editors&ust=1718703186780533&usg=AOvVaw0idv5Jtfy1Xar81749nqm8).
+
+        See also: [public key infrastructure](#h.mdxu5kpbdo4x).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [public key description](#publickeydescription)
+
+    -   ### W3C (DID)
+
+        A data object contained inside a DID document that contains all themetadata necessary to use a public key or a verification key.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [public key infrastructure](#h.mdxu5kpbdo4x)
+
+    -   ### ToIP
+
+        A set of policies, processes, server platforms, software and workstations used for the purpose of administering [certificates](#h.anf8g7aq0gk5) and [public-private key pairs](#h.jhvr6rbo5z3q), including the ability to [issue](#h.xyrplzbvtffq), maintain, and [revoke](#h.ilt4dj4huwza) [public key certificates](#h.anf8g7aq0gk5). The PKI includes the hierarchy of [certificate authorities](#h.dm6pt5kg2uim) that allow for the deployment of [digital certificates](#h.vpsiiv68xxwc) that support [encryption](#h.iyq318f2vg61), [digital signature](#h.s93np0i5rcne) and [authentication](#h.gp553sxzbmv1) to meet business and security requirements.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/public_key_infrastructure&sa=D&source=editors&ust=1718703186781472&usg=AOvVaw3ei6FjkA2XTeptjzTZR-q0).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public_key_infrastructure&sa=D&source=editors&ust=1718703186781707&usg=AOvVaw1X_fFIXLAYBvxacWgvfKx4): A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke [digital certificates](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public_key_certificate&sa=D&source=editors&ust=1718703186781923&usg=AOvVaw3N9v-5SzKjmjOaQupK3xpZ) and manage [public-key encryption](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public-key_cryptography&sa=D&source=editors&ust=1718703186782111&usg=AOvVaw0xLzeVDbz89E5LQTlJbwzk). The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # public key infrastructure
+
+        ###### Definition
+
+        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.
+
+        ![Public Private Key caveat to KERI](https://github.com/WebOfTrust/keri/blob/main/images/pubprivkey-caveat.png?raw=true)
+
+        More on [Wikipedia](https://en.wikipedia.org/wiki/Public_key_infrastructure)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [public transaction event log](#public-transaction-event-log)
+
+    -   ### WebOfTrust
+
+        # public transaction event log
+
+        ###### Definition
+
+        is a public hash-linked data structure of transactions that can be used to track state anchored to a KEL.
+
+        ##### Public Verifiable Credential Registry
+
+        A Public Verifiable Credential Registry can be represented in several [TEL](https://weboftrust.github.io/keridoc/docs/glossary/TEL.md)s to establish issuance or revocation state of a [Verifiable Credential](https://weboftrust.github.io/keridoc/docs/glossary/verifiable-credential.md) (VC).
+
+        ##### Control authority vs. issuance and revocation of VCs
+
+        The [KEL](https://weboftrust.github.io/keridoc/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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [public verifiable credential registry](#public-verifiable-credential-registry)
+
+    -   ### WebOfTrust
+
+        # public verifiable credential registry
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/key-event-log.md).
+
+        Two types of TELs will be used for this purpose. The first type of [TEL](https://weboftrust.github.io/keridoc/docs/glossary/transaction-event-log.md) is the [management TEL](https://weboftrust.github.io/keridoc/docs/glossary/management-transaction-event-log.md) and will signal the creation of the Registry and track the list of Registrars that will act as [Backers](https://weboftrust.github.io/keridoc/docs/glossary/backer.md) for the individual TELs for each [VC](https://weboftrust.github.io/keridoc/docs/glossary/verifiable-credential.md). The second type of TEL is the [VC TEL](https://weboftrust.github.io/keridoc/docs/glossary/virtual-credential-transaction-event-log.md) which will track the issued or revoked state of each VC and will contain a reference to it's corresponding management TEL.
+
+        ###### Why do we need this?
+
+        | TBW | prio2
+
+        [Learn more](https://kerisse.org)
+
+-   ## [qry](#qry)
+
+    -   ### WebOfTrust
+
+        # qry
+
+        ###### Definition
+
+        qry = query
+
+        [Learn more](https://kerisse.org)
+
+-   ## [qualified](#qualified)
+
+    -   ### WebOfTrust
+
+        # qualified
+
+        ###### Definition
+
+        When qualified, a cryptographic primitive includes a prepended derivation code (as a proem) 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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [qualified vlei issuer](#qualified-vlei-issuer)
+
+    -   ### WebOfTrust
+
+        # qualified vlei issuer
+
+        ###### Definition
+
+        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.
+
+        ###### Function
+
+        Is an authoritative role at the GLEIF organization that is mandated to issue [vLEI](https://weboftrust.github.io/keridoc/docs/glossary/vLEI.md) credentials to others.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [qualified vlei issuer vlei credential governance framework](#qualified-vlei-issuer-vlei-credential-governance-framework)
+
+    -   ### WebOfTrust
+
+        # qualified vlei issuer vlei credential governance framework
+
+        ###### Definition
+
+        A _document_ that details the requirements to enable this Credential to be **issued by** [GLEIF](https://weboftrust.github.io/keridoc/docs/glossary/GLEIF.md) **to** [Qualified vLEI Issuers](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/legal-entity-vlei-credential-governance-framework.md), [Legal Entity Official Organizational Role vLEI Credentials](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity-official-organizational-role-vlei-credential-governance-framework.md), and [Legal Entity Engagement Context Role vLEI Credentials](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [qvi authorized representative](#qvi-authorized-representative)
+
+    -   ### WebOfTrust
+
+        # qvi authorized representative
+
+        A designated representative of a [QVI](https://weboftrust.github.io/keridoc/docs/glossary/QVI.md) authorized, to conduct QVI operations with GLEIF and [Legal Entities](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [race condition](#race-condition)
+
+    -   ### WebOfTrust
+
+        # race condition
+
+        ###### Definition
+
+        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).
+
+        ###### KERI related
+
+        | TBW prio 2 |
+
+        [Learn more](https://kerisse.org)
+
+-   ## [rainbow table attack](#rainbow-table-attack)
+
+    -   ### WebOfTrust
+
+        # rainbow table attack
+
+        ###### Definition
+
+        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/keridoc/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/keridoc/docs/glossary/authenticity.md) and able to log
+        More on [source](https://www.beyondidentity.com/glossary/rainbow-table-attack)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [rct](#rct)
+
+    -   ### WebOfTrust
+
+        # rct
+
+        ###### Definition
+
+        rct = receipt
+
+        [Learn more](https://kerisse.org)
+
+-   ## [read update nullify](#read-update-nullify)
+
+    -   ### WebOfTrust
+
+        # read update nullify
+
+        ###### Definition
+
+        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".
+
+        ###### See also
+
+        -   [Run off the CRUD](https://weboftrust.github.io/keridoc/docs/glossary/run-off-the-crud.md)
+        -   [BADA](https://weboftrust.github.io/keridoc/docs/glossary/BADA.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [real world identity](#h.x0sst0y7375w)
+
+    -   ### ToIP
+
+        A term used to describe the opposite of [digital identity](#h.r5y8zwxvzyd3), i.e., an identity (typically for a person) in the physical instead of the digital world.
+
+        Also known as: [RWI](#h.rzufdn5u9c1c).
+
+        See also: [legal identity](#h.s0f760qh7yij).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [receipt](#receipt)
+
+    -   ### WebOfTrust
+
+        # receipt
+
+        ###### Definition
+
+        event message or reference with one or more witness signatures.
+
+        See Also:
+        [key event receipt](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [receipt log](#receipt-log)
+
+    -   ### WebOfTrust
+
+        # receipt log
+
+        ###### Definition
+
+        ordered record of all key event receipts for a given set of witnesses
+
+        [Learn more](https://kerisse.org)
+
+-   ## [recommended](#h.db3a5yf4o7iu)
+
+    -   ### ToIP
+
+        A [requirement](#h.ajxlw8r3dvcc) that is not [mandatory](#h.n3iynmuwwbf8) to implement in order for an implementer to be in [compliance](#h.r0iiayz1za1i), but which should be implemented unless the implementer has a good reason. In [ToIP governance frameworks](#h.ns22ebn9xjun), a recommendation is expressed using a SHOULD or RECOMMENDED keyword as defined in IETF RFC 2119.
+
+        See also: [mandatory](#h.n3iynmuwwbf8), [optional](#h.9411lfbb9qf2).
+
+        For more information, see: [https://www.rfc-editor.org/rfc/rfc2119](https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc2119&sa=D&source=editors&ust=1718703186784192&usg=AOvVaw3vphCZaLd_IF2yNFdLhVUw).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [reconciliation](#reconciliation)
+
+    -   ### WebOfTrust
+
+        # reconciliation
+
+        ###### Definition
+
+        Reconciliation is the process in which you decide to accept a fork of the [KEL](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) or not.
+        Source: Samuel Smith, Zoom meeting Jan 2 2024.
+
+        ###### Advantage
+
+        -   You might not have to abandon your identifier after key compromise
+        -   Only few people will see your reconciliation or clean up
+
+        [Learn more](https://kerisse.org)
+
+-   ## [record](#h.y4ybzkfe6yzv)
+
+    -   ### ToIP
+
+        A uniquely identifiable entry or listing in a database or [registry](#h.farjhbxfa3lh).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [redundant credential](#redundant-credential)
+
+    -   ### WebOfTrust
+
+        # redundant credential
+
+        ###### Definition
+
+        Multiple credentials issued by the same issuer (e.g. a [QVI](https://weboftrust.github.io/keridoc/docs/glossary/QVI.md)). They do not have anything to do with each other. They are independently valid.
+
+        ###### Misbehaviour
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [registrant](#h.60ettadb44j)
+
+    -   ### ToIP
+
+        The [party](#h.cn6bno48fomj) submitting a [registration](#h.scqeh7q9ln83) [record](#h.y4ybzkfe6yzv) to a [registry](#h.farjhbxfa3lh).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [registrar](#h.shktv8q59naw)
+
+    -   ### ToIP
+
+        The [party](#h.cn6bno48fomj) who performs [registration](#h.scqeh7q9ln83) on behalf of a [registrant](#h.60ettadb44j).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # registrar
+
+        ###### Definition
+
+        identifiers that serve as backers for each [transaction event log](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [registration](#h.scqeh7q9ln83)
+
+    -   ### ToIP
+
+        The process by which a [registrant](#h.60ettadb44j) submits a [record](#h.y4ybzkfe6yzv) to a [registry](#h.farjhbxfa3lh).
+
+        registration agent
+
+        A [party](#h.cn6bno48fomj) responsible for accepting [registration](#h.scqeh7q9ln83) requests and [authenticating](#h.gp553sxzbmv1) the [entity](#h.5imtbzl1f4xo) making the request. The term may also apply to a [party](#h.cn6bno48fomj) accepting [issuance](#h.zfdojht594xv) requests for [digital credentials](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.ddna9lucn4k6&sa=D&source=editors&ust=1718703186786011&usg=AOvVaw1sljogAgKIa28MyaOWX8lU).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [registration interaction](#registration-interaction)
+
+    -   ### WebOfTrust
+
+        # registration interaction
+
+        ###### Definition
+
+        Setup/Registration interaction, new AID and authorization to establish access control. You present a ([vLEI](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/delegation.md) authority.
+
+        The [Credential](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/issuee.md)? The token is [proof of the authorization](https://weboftrust.github.io/keridoc/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
+
+        ###### Replay attack prevention
+
+        is important, depending on the context or governance model the issuance itself needs / should / could be signed.
+
+        ##### Also see
+
+        [Access-controlled interaction](https://weboftrust.github.io/keridoc/docs/glossary/access-controlled-interaction.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [registry](#h.farjhbxfa3lh)
+
+    -   ### ToIP
+
+        A specialized database of [records](#h.y4ybzkfe6yzv) that serves as an [authoritative source](#h.9tt1qpgdfnxs) of information about [entities](#h.5imtbzl1f4xo).
+
+        See also: [trust registry](#h.5kzln6m5e8j5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # registry
+
+        ###### Definition
+
+        In our digital mental model it's an _official_ digital _record book_. When people refer to a registry, they usually mean a specific instance, within a multi-tenant registry. E.g. [Docker Hub](https://hub.docker.com/) is a multi-tenant registry, where there’s a set of [official / public images](https://docs.docker.com/docker-hub/official_images/).
+
+        ###### Unique Registries
+
+        A unique registry can be referenced in one of two ways, by [namespace](https://weboftrust.github.io/keridoc/docs/glossary/namespace.md), or by [domain](https://weboftrust.github.io/keridoc/docs/glossary/domain.md).
+
+        ![](https://hackmd.io/_uploads/HyXBDKbGi.png)
+
+        [Source](https://stevelasker.blog/2020/02/17/registry-namespace-repo-names/)
+
+        ###### ACDC related
+
+        ACDCs and SAIDS eliminated the need for a centrally controlled namespace registry for credential schemas. [schema registry](https://weboftrust.github.io/keridoc/docs/glossary/schema-registry.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [relationship context](#h.2j6x3j2tgc4t)
+
+    -   ### ToIP
+
+        A context established within the boundary of a [trust relationship](#h.pu2asd79bqzo).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [relying party](#h.61sr3qnr1eci)
+
+    -   ### ToIP
+
+        A [party](#h.cn6bno48fomj) who consumes [claims](#h.akieli6njkk5) or [trust graphs](#h.eqx98nkqjzsv) from other [parties](#h.cn6bno48fomj) (such as [issuers](#h.xyrplzbvtffq), [holders](#h.64mptmm24w7u), and [trust registries](#h.5kzln6m5e8j5)) in order to make a [trust decision](#h.m8c86ccqis9r).
+
+        See also: [verifier](#h.xfewd7t01hu0).
+
+        Note: The term “relying party” is more commonly used in [federated identity](#h.cb1le64hx6h5) architecture; the term “verifier” is more commonly used with [decentralized identity](#h.xodo7ytn4cx2) architecture and [verifiable credentials](#h.co5algna3zkh).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [relying party (RP)](#relyingparty\(RP\))
+
+    -   ### digital.govt.nz
+
+        the accountable party who relies on presented credential(s) in order to make decisionsAdditional notesNote 1: A Relying Party may employ other parties in the carrying out of their function.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [replay attack](#replay-attack)
+
+    -   ### WebOfTrust
+
+        # replay attack
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [replication](#replication)
+
+    -   ### digital.govt.nz
+
+        the act of repeating, duplicating, copying, or reproducing\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [repo](#repo)
+
+    -   ### WebOfTrust
+
+        # repo
+
+        ###### Definition
+
+        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.
+
+        ###### What is a software repository?
+
+        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").
+
+        ###### More on Wikipedia
+
+        [software repository](https://en.wikipedia.org/wiki/Software_repository)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [representation](#representation)
+
+    -   ### W3C (DID)
+
+        As defined for HTTP by \[RFC7231\]: "information that is intended to reflect apast, current, or desired state of a given resource, in a format that can bereadily communicated via the protocol, and that consists of a set ofrepresentation metadata and a potentially unbounded stream of representationdata." A DID document is a representation of information describing aDID subject. See 6. Representations.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [representation-specific entries](#representationspecificentries)
+
+    -   ### W3C (DID)
+
+        Entries in a DID document whose meaning is particular to a specificrepresentation. Defined in 4. Data Model and6. Representations. For example, @context inthe JSON-LD representation is arepresentation-specific entry.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [reputation](#h.4q9bmbf922ui)
+
+    -   ### ToIP
+
+        The reputation or prestige of a social entity (a [person](#h.yx4qb6dcjdvj), a social group, an [organization](#h.z27mp1358pi9), or a place) is an opinion about that entity – typically developed as a result of social evaluation on a set of criteria, such as behavior or performance.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Reputation&sa=D&source=editors&ust=1718703186788027&usg=AOvVaw1KclBDIhqH5R3k3uVg1IV9).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # reputation
+
+        ###### Definition
+
+        Consistent behaviour over time on the basis of which anyone else makes near-future decisions.
+        Source: Samuel Smith at IIW37.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [reputation graph](#h.4wwkekt1wrs7)
+
+    -   ### ToIP
+
+        A graph of the [reputation](#h.4q9bmbf922ui) relationships between different entities in a [trust community](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.a9l3odcb1s29&sa=D&source=editors&ust=1718703186788466&usg=AOvVaw1bWcKoLRhFw-k1UqoKgagQ). In a [digital trust ecosystem](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.h47f86smlz4y&sa=D&source=editors&ust=1718703186788667&usg=AOvVaw1N2po-dergjyomUNbPDiVT), the [governing body](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.1wptecwzvuvz&sa=D&source=editors&ust=1718703186788859&usg=AOvVaw3C_wXKXb3aXbGpa0jXXsm5) may be one [trust root](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.vfnyletkzjv5&sa=D&source=editors&ust=1718703186789040&usg=AOvVaw15P1K4h-O2x-6rFk_cUDMC) of a reputation graph. In some cases, a reputation graph can be traversed by making queries to one or more [trust registries](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5kzln6m5e8j5&sa=D&source=editors&ust=1718703186789236&usg=AOvVaw0wvSkCXTzH8ooTdSUQJ1wB).
+
+        See also: [authorization graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5tvkchqqqka8&sa=D&source=editors&ust=1718703186789480&usg=AOvVaw2djy9uableVBP0SSqx4N4M), [governance graph](#h.u9xnz96ecf5x), [trust graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.eqx98nkqjzsv&sa=D&source=editors&ust=1718703186789767&usg=AOvVaw2TsHI07RFau-g9kG0b7nOu).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [reputation system](#h.yzq3axr0dh87)
+
+    -   ### ToIP
+
+        Reputation systems are programs or algorithms that allow users to rate each other in online communities in order to build [trust](#h.sdrgtm7bwb51) through [reputation](#h.4q9bmbf922ui). Some common uses of these systems can be found on e\-commerce websites such as eBay, Amazon.com, and Etsy as well as online advice communities such as Stack Exchange.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Reputation_system&sa=D&source=editors&ust=1718703186790448&usg=AOvVaw2zE_OnD-jkYiP2cqwm0vmo).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [reputational trust](#reputational-trust)
+
+    -   ### WebOfTrust
+
+        # reputational trust
+
+        ###### Definition
+
+        Established by a trusted party offering [Identity Assurance](https://weboftrust.github.io/keridoc/docs/glossary/identity-assurance.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [requirement](#h.ajxlw8r3dvcc)
+
+    -   ### ToIP
+
+        A specified condition or behavior to which a system needs to [comply](#h.r0iiayz1za1i). [Technical requirements](#h.l7t266ck3tjw) are defined in [technical specifications](#h.u62ak0cgfdb1) and implemented in computer systems to be executed by software [actors](#h.gzdfngxkp0ip). [Governance requirements](#h.j4z5czk0dk8t) are defined in [governance documents](#h.c8fvvxachz5h) that specify [policies](#h.udts41hso4w4) and procedures to be executed by human [actors](#h.gzdfngxkp0ip). In ToIP architecture, requirements are expressed using the keywords defined in Internet RFC 2119.
+
+        See also: [mandatory](#h.n3iynmuwwbf8), [recommended](#h.db3a5yf4o7iu), [optional](#h.9411lfbb9qf2).
+
+        For more information, see: [https://www.rfc-editor.org/rfc/rfc2119](https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc2119&sa=D&source=editors&ust=1718703186791314&usg=AOvVaw0zQYrwe30wP74lCfGXbKDi).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [reserve rotation](#reserve-rotation)
+
+    -   ### WebOfTrust
+
+        # reserve rotation
+
+        ###### Definition
+
+        One important use case for [partial rotation](https://weboftrust.github.io/keridoc/docs/glossary/partial-rotation.md) is to enable pre-rotated key pairs designated in one [establishment event](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [resource](#resource)
+
+    -   ### W3C (DID)
+
+        As defined by \[RFC3986\]: "...the term 'resource' is used in a general sensefor whatever might be identified by a URI." Similarly, any resource might serveas a DID subject identified by a DID.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [rev](#rev)
+
+    -   ### WebOfTrust
+
+        # rev
+
+        ###### Definition
+
+        rev = vc revoke, verifiable credential revocation
+
+        [Learn more](https://kerisse.org)
+
+-   ## [revocation](#revocation)
+
+    -   ### Nist
+
+        The process of permanently ending the binding between a certificate and the identity asserted in the certificate from a specified time forward.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/revocation)
+
+    -   ### ToIP
+
+        In the context of [digital credentials](#h.ddna9lucn4k6), revocation is an event signifying that the [issuer](#h.xyrplzbvtffq) no longer attests to the [validity](#h.rbp41an0omv6) of a [credential](#h.ddna9lucn4k6) they have [issued](#h.xyrplzbvtffq). In the context of cryptographic keys, revocation is an event signifying that the [controller](#h.gemoqe2m303z) no longer attests to the [validity](#h.rbp41an0omv6) of a public/private key pair for which the [controller](#h.gemoqe2m303z) is [authoritative](#h.gln5i78kxlfh).
+
+        See also: [issuance](#h.zfdojht594xv), [presentation](#h.h5d1xfsxbbr0).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23revokerevocation&sa=D&source=editors&ust=1718703186792318&usg=AOvVaw1tqNJJNHLkMok0XI_SckWM): the act, by or on behalf of the [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186792547&usg=AOvVaw2oTju9Kcwp7o06i9o6xztN) that has issued the [credential](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186792714&usg=AOvVaw0LA17m8dj7snDn7SDzKWnb), of no longer vouching for the correctness or any other qualification of (arbitrary parts of) that [credential](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186792870&usg=AOvVaw2M-_J3NW0WQAwxsqfM6C4G).
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/revocation&sa=D&source=editors&ust=1718703186793107&usg=AOvVaw2q8v6ZPUuRhYyBqGGrqEAL): ​​For digital certificates: The process of permanently ending the binding between a certificate and the identity asserted in the certificate from a specified time forward. For cryptographic keys: A process whereby a notice is made available to affected entities that keys should be removed from operational use prior to the end of the established cryptoperiod of those keys.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # revocation
+
+        ###### Definition
+
+        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)
+
+        ###### In identity
+
+        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/keridoc/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/keridoc/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.
+
+        ###### How KERI avoids confusion
+
+        KERI terminology usually avoids confusion between [rotation](https://weboftrust.github.io/keridoc/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.
+
+        ###### Also see
+
+        [Revocation event](https://weboftrust.github.io/keridoc/docs/glossary/revocation-event.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [revocation event](#revocation-event)
+
+    -   ### WebOfTrust
+
+        # revocation event
+
+        ###### Definition
+
+        ###### Considerations
+
+        ###### KERI related
+
+        An event that revokes [control authority](https://weboftrust.github.io/keridoc/docs/glossary/control-authority.md) over an [identifier](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/KEL.md).
+
+        ###### Also see
+
+        [Revocation](https://weboftrust.github.io/keridoc/docs/glossary/revocation.md)
+
+        ###### Beware: Suspension is non-existing
+
+        A temporary revocation of a grant or privilege is called a suspension. We don't have this type of state or event in KERI.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ricardian contract](#ricardian-contract)
+
+    -   ### WebOfTrust
+
+        # ricardian contract
+
+        ###### Definition
+
+        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)
+
+        ###### Related to KERI and ACDC
+
+        Ricardian contracts provide a human readable twin to the seals and and signatures (commitments) in binary format in [ACDC](https://weboftrust.github.io/keridoc/docs/glossary/ACDC.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [risk](#risk)
+
+    -   ### digital.govt.nz
+
+        effect of uncertainty on objectives\[Source: ISO 31073:2022\]Additional notes:Note 1: An effect is a deviation from the expected. It can be positive, negative or both, and can address, create or result in opportunities and threats.Note 2: Objectives can have different aspects and categories and can be applied at different levels.Note 3: Risk is usually expressed in terms of risk sources, potential events, their consequences and their likelihood.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        The effects that uncertainty (i.e. a lack of information, understanding or [knowledge](#h.k96lktyswxnb) of events, their consequences or likelihoods) can have on the intended realization of an [objective](#h.k0v6ir8wmcav) of a [party](#h.cn6bno48fomj).
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary&sa=D&source=editors&ust=1718703186794187&usg=AOvVaw1mVSvBbBNO81Py-zO6bgs8)
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/risk&sa=D&source=editors&ust=1718703186794600&usg=AOvVaw2lBVnu0LSrJZmL2XYVoFc0): A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [risk assessment](#h.91ipsr7y3vb6)
+
+    -   ### ToIP
+
+        The process of identifying [risks](#h.qzpr4qua4ble) to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other [organizations](#h.z27mp1358pi9), and the overall [ecosystem](#h.h47f86smlz4y), resulting from the operation of an information system. Risk assessment is part of [risk management](#h.8i5edrs9npxn), incorporates threat and vulnerability analyses, and considers [risk mitigations](#h.lmnt77k1l43b) provided by security controls planned or in place.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/risk_assessment&sa=D&source=editors&ust=1718703186795237&usg=AOvVaw1-B4ekP7xP4f7R6EsNeE4t).
+
+        Also known as: risk analysis.
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk_assessment&sa=D&source=editors&ust=1718703186795527&usg=AOvVaw1AUNHVwmUE1TLRQkiIl0DO): Risk assessment determines possible mishaps, their likelihood and consequences, and the [tolerances](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Engineering_tolerance&sa=D&source=editors&ust=1718703186795693&usg=AOvVaw0gYoSVROmF8yD8P4wR45T3) for such events.[\[1\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk_assessment%23cite_note-RausandRisk13-1&sa=D&source=editors&ust=1718703186795856&usg=AOvVaw0nWTZ7HyXdvdK46A1hkIVX) The results of this process may be expressed in a [quantitative](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Quantitative_property&sa=D&source=editors&ust=1718703186796013&usg=AOvVaw128PDpF-zbmu_kCD37t6Dz) or [qualitative](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Qualitative_data&sa=D&source=editors&ust=1718703186796151&usg=AOvVaw2-W3jsfOKDaK2LpdojQceq) fashion. Risk assessment is an inherent part of a broader [risk management](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk_management&sa=D&source=editors&ust=1718703186796356&usg=AOvVaw1WzD5Egg24hFIWf2BSrh8w) strategy to help reduce any potential risk-related consequences. More precisely, risk assessment identifies and analyses potential (future) events that may negatively impact individuals, assets, and/or the environment (i.e. [hazard analysis](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Hazard_analysis&sa=D&source=editors&ust=1718703186796567&usg=AOvVaw1X1qwhaGdnInItlw5E2Ebl)). It also makes judgments "on the [tolerability](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Tolerability&sa=D&source=editors&ust=1718703186796744&usg=AOvVaw1Ik2srg0uZ60YQOQOwzQLH) of the risk on the basis of a risk analysis" while considering influencing factors (i.e. risk evaluation).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [risk decision](#h.9g76xvrtlnqp)
+
+    -   ### ToIP
+
+        See: [trust decision](#h.m8c86ccqis9r).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [risk management](#h.8i5edrs9npxn)
+
+    -   ### ToIP
+
+        The process of managing [risks](#h.qzpr4qua4ble) to organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals resulting from the operation of an information system, and includes: (i) the conduct of a [risk assessment](#h.91ipsr7y3vb6); (ii) the implementation of a [risk mitigation](#h.lmnt77k1l43b) strategy; and (iii) employment of techniques and procedures for the continuous monitoring of the security state of the information system.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/risk_management&sa=D&source=editors&ust=1718703186797394&usg=AOvVaw12Zlr6UHi0D7llf_DXrRo7).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23risk-management&sa=D&source=editors&ust=1718703186797718&usg=AOvVaw0vYKxl4VrMQ8OSK8fKOSU9): a process that is run by (or on behalf of) a specific [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186797974&usg=AOvVaw0hmg_XAeKQr9XfzlYjm5pe) for the purpose of [managing](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/management&sa=D&source=editors&ust=1718703186798159&usg=AOvVaw2l3GgULfT-usWCJqLlDbRO) the [risks](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/risk&sa=D&source=editors&ust=1718703186798335&usg=AOvVaw2rznCSvbbISs0WWi6zPDJo) that it [owns](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/owner&sa=D&source=editors&ust=1718703186798513&usg=AOvVaw00KIpGByvuwqWjlGVh45Vw) (thereby realizing specific [risk objectives](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/risk-objective&sa=D&source=editors&ust=1718703186798709&usg=AOvVaw0Y-Sb8CJbfvj5EsxtyB3cS)).
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk_management&sa=D&source=editors&ust=1718703186799018&usg=AOvVaw0CE-2i6uc3bqQKOn9Eu3DB): Risk management is the identification, evaluation, and prioritization of [risks](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk&sa=D&source=editors&ust=1718703186799168&usg=AOvVaw3PxwYKvPgIqng9OUzDXGg5) (defined in [ISO 31000](https://www.google.com/url?q=https://en.wikipedia.org/wiki/ISO_31000&sa=D&source=editors&ust=1718703186799345&usg=AOvVaw1e0gPr_R12HlnINFwHkG2j) as the effect of uncertainty on objectives) followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [risk mitigation](#h.lmnt77k1l43b)
+
+    -   ### ToIP
+
+        Prioritizing, evaluating, and implementing the appropriate [risk](#h.qzpr4qua4ble)\-reducing controls/countermeasures recommended from the [risk management](#h.8i5edrs9npxn) process.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/risk_mitigation&sa=D&source=editors&ust=1718703186799837&usg=AOvVaw1jjAEHYk-SP2DnhAQUgta6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [role](#role)
+
+    -   ### digital.govt.nz
+
+        proper or customary function\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        A defined set of characteristics that an [entity](#h.5imtbzl1f4xo) has in some context, such as responsibilities it may have, [actions](#h.l54nzmooy631) (behaviors) it may execute, or pieces of [knowledge](#h.k96lktyswxnb) that it is expected to have in that context, which are referenced by a specific role name.
+
+        Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23role&sa=D&source=editors&ust=1718703186800341&usg=AOvVaw0SmSdYG4klE9C_V3ln1WAL).
+
+        See also: [role credential](#h.q15w534tm34t).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [role credential](#h.q15w534tm34t)
+
+    -   ### ToIP
+
+        A [credential](#h.kcj6iw2vib1v) [claiming](#h.akieli6njkk5) that the [subject](#h.voca6uuv1a4) has a specific [role](#h.sf54cyuamo6x).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [role-based access control](#h.isj9yeecvwmw)
+
+    -   ### ToIP
+
+        [Access control](#h.lmk4gqobt99b) based on user [roles](#h.sf54cyuamo6x) (i.e., a collection of access [authorizations](#h.576ssfpt348i) a user receives based on an explicit or implicit assumption of a given [role](#h.sf54cyuamo6x)). [Role](#h.sf54cyuamo6x) [permissions](#h.mnqlrmrkqb9) may be inherited through a [role](#h.sf54cyuamo6x) hierarchy and typically reflect the [permissions](#h.mnqlrmrkqb9) needed to perform defined functions within an [organization](#h.z27mp1358pi9). A given [role](#h.sf54cyuamo6x) may apply to a single individual or to several individuals.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/role_based_access_control&sa=D&source=editors&ust=1718703186801128&usg=AOvVaw1JeraP70Rnwb7d1XMB7E1P).
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Role-based_access_control&sa=D&source=editors&ust=1718703186801379&usg=AOvVaw1H_ZhqvR91IGkAnRj_5BYN): In computer systems security, role-based access control (RBAC) or role-based security is an approach to restricting system access to authorized users, and to implementing [mandatory access control](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mandatory_access_control&sa=D&source=editors&ust=1718703186801617&usg=AOvVaw1sqNGZfKldBbqRPLG8YTPz) (MAC) or [discretionary access control](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Discretionary_access_control&sa=D&source=editors&ust=1718703186801795&usg=AOvVaw0BCCrT0Zj1Bo7S3muVVgxE) (DAC).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [root autonomic identifier](#root-autonomic-identifier)
+
+    -   ### WebOfTrust
+
+        # root autonomic identifier
+
+        ###### Definition
+
+        An entity may provide the [root-of-trust](https://weboftrust.github.io/keridoc/docs/glossary/root-of-trust.md) for some ecosystem (with delegation )via its root [AID](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/security.md) in its [key management](https://weboftrust.github.io/keridoc/docs/glossary/key-management.md). Although through the use of a [multi-valent](https://weboftrust.github.io/keridoc/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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [root of trust](#root-of-trust)
+
+    -   ### WebOfTrust
+
+        # root of trust
+
+        ###### Definition
+
+        A root-of-trust is some component of a system that is [secure](https://weboftrust.github.io/keridoc/docs/glossary/security.md) by design and its security characteristics may be inherently trusted or relied upon by other components of the system.
+
+        ###### Root-of-trust
+
+        Replace human basis-of-trust with cryptographic root-of-trust. With verifiable digital signatures from asymmetric key cryptography we may not trust in “what” was said, but we may trust in “who” said it.
+        The root-of-trust is consistent attribution via verifiable integral [non-repudiable](https://weboftrust.github.io/keridoc/docs/glossary/non-repudiable.md) statements.
+
+        A root of trust is a foundational component or process in the identity system that is relied on by other components of the system and whose failure would compromise the integrity of the bindings. A root of trust might be primary or secondary depending on whether or not it is replaceable. Primary roots of trust are irreplaceable. Together, the roots of trust form the trust basis for the system.
+
+        ###### KERI related
+
+        We distinguish a [primary root-of-trust](https://weboftrust.github.io/keridoc/docs/glossary/primary-root-of-trust.md) in a KEL and a [secondary root-of-trust](https://weboftrust.github.io/keridoc/docs/glossary/secondary-root-of-trust.md), for example in a TEL or data on a blockchain.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [rot](#rot)
+
+    -   ### WebOfTrust
+
+        # rot
+
+        ###### Definition
+
+        [JSON](https://weboftrust.github.io/keridoc/docs/glossary/JSON.md) field name (attribute) for Rotation Event; its content (value) contains a hash pointer. All [TEL](https://weboftrust.github.io/keridoc/docs/glossary/transaction-event-log.md) events are anchored in a [KEL](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) in either ixn ([interaction](https://weboftrust.github.io/keridoc/docs/glossary/interaction-event.md)) or [rot](https://weboftrust.github.io/keridoc/docs/glossary/rot.md) ([rotation event](https://weboftrust.github.io/keridoc/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
+
+        ###### Also see
+
+        [ixn](https://weboftrust.github.io/keridoc/docs/glossary/ixn.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [rotation](#rotation)
+
+    -   ### WebOfTrust
+
+        # rotation
+
+        ###### Definition
+
+        The operation of revoking and replacing the set of [authoritative](https://weboftrust.github.io/keridoc/docs/glossary/authoritative.md) [key pairs](https://weboftrust.github.io/keridoc/docs/glossary/key-pair.md) for an [AID](https://weboftrust.github.io/keridoc/docs/glossary/AID.md). This operation is made verifiable and [duplicity](https://weboftrust.github.io/keridoc/docs/glossary/duplicity.md) evident upon acceptance as a rotation event that is appended to the AID's [KEL](https://weboftrust.github.io/keridoc/docs/glossary/KEL.md).
+        Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [rotation authority](#rotation-authority)
+
+    -   ### WebOfTrust
+
+        # rotation authority
+
+        ###### Definition
+
+        The (exclusive) right to rotate the authoritative key pair and establish changed control authority.
+
+        ###### Relation to rotation authority
+
+        The original controller of an [AID](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/signing-authority.md) and the second ([pre-rotated](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/custodial-agent.md) can hold signing authority while the original controller can hold exclusive rotation authority.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [rotation event](#rotationevent)
+
+    -   ### ToIP (DID:Webs)
+
+        A key event that provides the information needed to change the key state for an AID using pre-rotation, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # rotation event
+
+        ###### Definition
+
+        An [establishment event](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/authoritative.md) keypairs for an [AID](https://weboftrust.github.io/keridoc/docs/glossary/autonomic-identifier.md).
+        Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology)
+
+        ###### The inner working
+
+        We start with a [root-of-trust](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/docs/glossary/key-event-receipt-infrastructure.md).\\
+        _(SamASmith)_
+
+        [Learn more](https://kerisse.org)
+
+-   ## [router](#h.oqbqyf914pln)
+
+    -   ### ToIP
+
+        A router is a networking device that forwards [data packets](#h.9hc1adgu2nrx) between computer networks. Routers perform the traffic directing functions between networks and on the global Internet. Data sent through a network, such as a web page or email, is in the form of [data packets](#h.9hc1adgu2nrx). A packet is typically forwarded from one router to another router through the networks that constitute an internetwork (e.g. the Internet) until it reaches its destination [node](#h.w1aty8c036fp). This process is called [routing](#h.tbxetxt0mdlp).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Router_\(computing\)&sa=D&source=editors&ust=1718703186802728&usg=AOvVaw3d6RsAQHtrgq_OVmL5BZOI).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [routing](#h.tbxetxt0mdlp)
+
+    -   ### ToIP
+
+        Routing is the process of selecting a path for traffic in a network or between or across multiple networks. Broadly, routing is performed in many types of networks, including circuit-switched networks, such as the public switched telephone network (PSTN), and computer networks, such as the Internet. A [router](#h.oqbqyf914pln) is a computing device that specializes in performing routing.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Routing&sa=D&source=editors&ust=1718703186803372&usg=AOvVaw2SsUxgHtkg6DTWKsBXlpMp).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [rpy](#rpy)
+
+    -   ### WebOfTrust
+
+        # rpy
+
+        ###### Definition
+
+        rpy = reply
+
+        [Learn more](https://kerisse.org)
+
+-   ## [rule](#h.v7s575ulon74)
+
+    -   ### ToIP
+
+        A prescribed guide for conduct, process or [action](#h.l54nzmooy631) to achieve a defined result or [objective](#h.k0v6ir8wmcav). Rules may be [human-readable](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.ywyofmy4do4t&sa=D&source=editors&ust=1718703186803875&usg=AOvVaw20aTtmDHPKbdwq317Vw7af) or [machine-readable](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.8s3s84fzcfi3&sa=D&source=editors&ust=1718703186804112&usg=AOvVaw34zAFPqYjUtHkzdZtM03dL) or both.
+
+        See also: [governance framework](#h.2x05z0r097mn), [policy](#h.udts41hso4w4).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [run off the crud](#run-off-the-crud)
+
+    -   ### WebOfTrust
+
+        # run off the crud
+
+        ###### Definition
+
+        _RUN off the [CRUD](https://weboftrust.github.io/keridoc/docs/glossary/CRUD.md)_
+
+        RUN stands for Read , Update, Nullify. 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/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [sally](#sally)
+
+    -   ### WebOfTrust
+
+        # sally
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/GLEIF.md) Reporting API can show what [vLEIs](https://weboftrust.github.io/keridoc/docs/glossary/vLEI.md) are; issued to [Legal Entities](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity.md).
+
+        ###### Inner working
+
+        The Sally [vLEI](https://weboftrust.github.io/keridoc/docs/glossary/vLEI.md) Audit Reporting Agent _receives presentations of credentials_ and notices of [revocation](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/URL.md)
+        [Source](https://github.com/GLEIF-IT/sally)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [salt](#salt)
+
+    -   ### Nist
+
+        As used in this Recommendation, a byte string (which may be secret or non-secret) that is used as a MAC key by either: 1) a MAC-based auxiliary function H employed in one-step key derivation or 2) a MAC employed in the randomness-extraction step during two-step key derivation.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/salt)
+
+    -   ### WebOfTrust
+
+        # salt
+
+        ###### Definition
+
+        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).
+
+        ##### Usage
+
+        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.
+
+        ##### More in source
+
+        [Wikipedia](https://en.wikipedia.org/wiki/Salt_\(cryptography\))
+
+        [Learn more](https://kerisse.org)
+
+-   ## [salter](#salter)
+
+    -   ### WebOfTrust
+
+        # salter
+
+        ###### Definition
+
+        A primitive that represents a [seed](https://weboftrust.github.io/keridoc/docs/glossary/seed.md). It has the ability to generate new [Signer](https://weboftrust.github.io/keridoc/docs/glossary/signer.md)s.
+        [Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
+
+        [Learn more](https://kerisse.org)
+
+-   ## [salty nonce blinding factor](#salty-nonce-blinding-factor)
+
+    -   ### WebOfTrust
+
+        # salty nonce blinding factor
+
+        ###### Definition
+
+        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.
+
+        ###### How
+
+        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.
+
+        ###### Example
+
+        I don’t want my employment states shared in the future with former possible employers.
+
+        ###### More info
+
+        [Blindable State TEL](https://github.com/trustoverip/tswg-acdc-specification/blob/main/draft-ssmith-acdc.md#blindable-state-tel)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [schema](#h.rwxa1n5inr2e)
+
+    -   ### ToIP
+
+        A framework, pattern, or set of [rules](#h.v7s575ulon74) for enforcing a specific structure on a digital object or a set of digital [data](#h.o783ayrrkc6g). There are many types of schemas, e.g., data schema, credential verification schema, database schema.
+
+        For more information, see: W3C [Data Schemas](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23data-schemas&sa=D&source=editors&ust=1718703186805038&usg=AOvVaw1IygqRd64Hh0OmnMUaoPC6).
+
+        Note: credentialSchema is a Property Definition in the [W3C VC Data Model, see 3.2.1](https://www.google.com/url?q=https://www.w3.org/2018/credentials/%23credentialSchema&sa=D&source=editors&ust=1718703186805394&usg=AOvVaw3rCeU1r6uCHrF2YjgJIyzd)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [schema namespace registry](#schema-namespace-registry)
+
+    -   ### WebOfTrust
+
+        # schema namespace registry
+
+        ###### Definition
+
+        a centrally managed [schema registry](https://weboftrust.github.io/keridoc/docs/glossary/schema-registry.md) where corporations or individuals reserve schemas within a specific [namespace](https://weboftrust.github.io/keridoc/docs/glossary/namespace.md) in order to have an interoperable schema that is labeled with a corporation-specific or individual-specific namespace.
+
+        ###### ACDC related
+
+        [Graphs](https://weboftrust.github.io/keridoc/docs/glossary/directed-acyclic-graph.md) in ACDC have decentralised the old-school schema registry, so it's [interoperable](https://weboftrust.github.io/keridoc/docs/glossary/interoperability.md) by design.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [schema registry](#schema-registry)
+
+    -   ### WebOfTrust
+
+        # schema registry
+
+        ###### Definition
+
+        Central [registry](https://weboftrust.github.io/keridoc/docs/glossary/registry.md) for credential schemas based on namespaces.
+
+        ###### ACDC related
+
+        ACDCs and SAIDS **eliminated the need** for a centrally controlled namespace registry for credential schemas.
+
+        ###### KERI related and ToIP definitions
+
+        From our vocabulary that contains the term "[Public verifiable credential registry](https://weboftrust.github.io/keridoc/docs/glossary/public-verifiable-credential-registry.md)" there's follow-up on ToIP definitions like | TBW |
+
+        ###### Comparison and explanation
+
+        [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/keridoc/docs/glossary/VDS.md) and [graph fragments](https://weboftrust.github.io/keridoc/docs/glossary/graph-fragment.md).
+
+        ![](https://hackmd.io/_uploads/H1CE6FZfo.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [scope](#h.5cfb6xokygh4)
+
+    -   ### ToIP
+
+        In the context of [terminology](#h.189fachpwy1a), scope refers to the set of possible [concepts](#h.6hyxh4mxxbu2) within which: a) a specific [term](#h.ojn7uxdcaf7u) is intended to uniquely identify a [concept](#h.6hyxh4mxxbu2), or b) a specific [glossary](#h.z1he49173rzw) is intended to identify a set of [concepts](#h.6hyxh4mxxbu2). In the context of [identification](#h.fslz9gxdlb84), scope refers to the set of possible entities within which a specific entity must be uniquely identified. In the context of [specifications](#h.dst3g25dh97g), scope refers to the set of problems (the problem space) within which the specification is intended to specify solutions.
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23scope&sa=D&source=editors&ust=1718703186806303&usg=AOvVaw0EHnxLqIeqX_0-FzdgsWcZ): the extent of the area or subject matter (which we use, e.g., to define [pattern](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186806545&usg=AOvVaw19SHJvAcrks69uWvfXIUya), [concept](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186806695&usg=AOvVaw1uhQarOfqlK3W0mMLq756D), [term](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186806871&usg=AOvVaw0kBeTVRJ6jyPl1HNzTdNAE) and [glossaries](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186807015&usg=AOvVaw0lHGGz93RULsPa-r6VLJAz) in, but it serves other purposes as well).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [seal](#seal)
+
+    -   ### WebOfTrust
+
+        # seal
+
+        ###### Definition
+
+        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
+
+        ###### What is it worth?
+
+        The payload of the seal becomes immutable and the controller commits a signature to the seal.
+
+        | TBW prio 2 |
+
+        [Learn more](https://kerisse.org)
+
+-   ## [second party](#h.hk94wskqnzri)
+
+    -   ### ToIP
+
+        The [party](#h.cn6bno48fomj) with whom a [first party](#h.uxx5bjam20ag) engages to form a [trust relationship](#h.pu2asd79bqzo), establish a [connection](#h.thbpewq1px8x), or execute a [transaction](#h.92pu88ke4p7k).
+
+        See also: [third party](#h.zu2vj8151tr).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [secondary root of trust](#secondary-root-of-trust)
+
+    -   ### WebOfTrust
+
+        # secondary root of trust
+
+        ###### Definition
+
+        In KERI its a [root-of-trust](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/primary-root-of-trust.md).
+        By its nature and cryptographic anchoring via [seals](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [secure](#secure)
+
+    -   ### WebOfTrust
+
+        # secure
+
+        ###### See
+
+        [Security](https://weboftrust.github.io/keridoc/docs/glossary/security.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [secure asset transfer protocol](#secure-asset-transfer-protocol)
+
+    -   ### WebOfTrust
+
+        # secure asset transfer protocol
+
+        ###### Definition
+
+        An IETF protocol (and working group) in the making (as of mid 2022) for moving assets between blockchains.
+
+        ##### More information at IETF
+
+        [About SATP working group](https://datatracker.ietf.org/wg/satp/about/)
+
+        ##### Relationship with KERI
+
+        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).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [secure attribution](#secure-attribution)
+
+    -   ### WebOfTrust
+
+        # secure attribution
+
+        ###### Definition
+
+        In short: secure attribution is "whodunit?!" in cyberspace.
+
+        Secure attribution is strongly related to _making and proving statements_. A [controller](https://weboftrust.github.io/keridoc/docs/glossary/controller.md) makes statements to the a [validator](https://weboftrust.github.io/keridoc/docs/glossary/validator.md) or verifier, who in turn validates the statements issued. A [controller](https://weboftrust.github.io/keridoc/docs/glossary/controller.md) "_owns_" the statement: content and attribution via digital signatures.
+        _Secure attribution of a statement_ is a way of proving that **the statement is an authentic statement of the `controller`**.
+
+        ###### Relationship with KERI
+
+        In the context of KERI and ACDC _secure_ means a **`Validator` may cryptographically verify** the statement.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [secure multi-party computation](#h.w5uvxlcshb5o)
+
+    -   ### ToIP
+
+        See: [multi-party computation](#h.2x62jfcai7ch).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [secure private authentic confidentiality](#secure-private-authentic-confidentiality)
+
+    -   ### WebOfTrust
+
+        # secure private authentic confidentiality
+
+        ###### Definition
+
+        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)
+
+        ###### Reason
+
+        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 |
+
+        ###### Details
+
+        [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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [security](#security)
+
+    -   ### Nist
+
+        A condition that results from the establishment and maintenance of protective measures that enable an organization to perform its mission or critical functions despite risks posed by threats to its use of systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the organizations risk management approach.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/security)
+
+    -   ### WebOfTrust
+
+        # security
+
+        ###### Definition
+
+        'secure' is free from or not exposed to danger or harm; safe. For [identifier](https://weboftrust.github.io/keridoc/docs/glossary/identifier.md)s _security_ typically means secure from _exploit_ or _compromise_. More specifically an identifier is secure with respect to an entity if there is a mechanism by which that entity may prove it has [control](https://weboftrust.github.io/keridoc/docs/glossary/controller.md) over the identifier.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [security cost performance architecture trade off](#security-cost-performance-architecture-trade-off)
+
+    -   ### WebOfTrust
+
+        # security cost performance architecture trade off
+
+        ###### Definition
+
+        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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [security domain](#h.d7ry9j100f36)
+
+    -   ### ToIP
+
+        An environment or context that includes a set of system resources and a set of system entities that have the right to access the resources as defined by a common [security policy](#h.2fcbwog0w43a), security model, or security architecture.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/domain&sa=D&source=editors&ust=1718703186808890&usg=AOvVaw1y8xkkn-oBdZEHCGTsSnzN)
+
+        See also: [trust domain](#h.60miqe21hd5h).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [security overlay properties trillema](#security-overlay-properties-trillema)
+
+    -   ### WebOfTrust
+
+        # security overlay properties trillema
+
+        ###### Definition
+
+        An identifier system has some degree of any combination of the three properties [authenticity](https://weboftrust.github.io/keridoc/docs/glossary/authenticity.md), [privacy](https://weboftrust.github.io/keridoc/docs/glossary/privacy.md) and [confidentiality](https://weboftrust.github.io/keridoc/docs/glossary/confidentiality.md), but not all three completely.
+
+        ###### Why a trillema?
+
+        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
+
+        ![Trilemma of Identifier System Properties](https://github.com/weboftrust/WOT-terms/static/img/Trilemma-of-Identifier-System-Properties.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [security policy](#h.2fcbwog0w43a)
+
+    -   ### ToIP
+
+        A set of [policies](#h.udts41hso4w4) and [rules](#h.v7s575ulon74) that governs all aspects of security-relevant system and system element behavior.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/security_policy&sa=D&source=editors&ust=1718703186809478&usg=AOvVaw3gApqOsTQLcaPaftO1rkko)
+
+        See also: [privacy policy](#h.xbjzswct9aqi).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [seed](#seed)
+
+    -   ### WebOfTrust
+
+        # seed
+
+        ###### Definition
+
+        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)
+
+        ###### Example 24-word 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.
+
+        ###### Pseudorandom is not exactly random
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [selective disclosure](#selective-disclosure)
+
+    -   ### WebOfTrust
+
+        # selective disclosure
+
+        ###### Definition
+
+        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.
+
+        ###### Related
+
+        [Partial Disclosure](https://weboftrust.github.io/keridoc/docs/glossary/partial-disclosure.md)
+
+        Source: distilled from ACDC Zoom meeting, date March 28, 2023
+
+        [Learn more](https://kerisse.org)
+
+-   ## [self addressing data](#self-addressing-data)
+
+    -   ### WebOfTrust
+
+        # self addressing data
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [self addressing identifier](#self-addressing-identifier)
+
+    -   ### WebOfTrust
+
+        # self addressing identifier
+
+        ###### Definition
+
+        An identifier that is deterministically generated from and embedded in the content it identifies, making it and its data mutually tamper-evident.
+
+        ##### To generate a SAID
+
+        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.**
+
+        ##### To verify that a SAID truly identifies a specific chunk of 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_.
+
+        ##### Differences in SAID algorthms manifest in the following choices
+
+        -   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
+
+        ##### Notation
+
+        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)`.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [self certifying identifier](#self-certifying-identifier)
+
+    -   ### WebOfTrust
+
+        # self certifying identifier
+
+        ###### Definition
+
+        A Self-Certifying Identifier (SCID) cryptographically binds an identifier to a public and private key pair. It is an identifier that can be proven to be the one and only identifier tied to a public key using cryptography alone.
+
+        ###### Signing
+
+        A [controller](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/prefix.md) in the identifier.
+
+        ###### Important SCID properties:
+
+        -   Self-contained secure cryptographic [root-of-trust](https://weboftrust.github.io/keridoc/docs/glossary/root-of-trust.md)
+        -   Decentralized control via [private key management](https://weboftrust.github.io/keridoc/docs/glossary/PKI.md)
+        -   Universally unique identifiers
+
+        ###### Related to KERI
+
+        A self-certifying identifier (SCID) is a type of [cryptonym](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/docs/glossary/ephemeral.md) i.e. it does not support [rotation](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [self framing](#self-framing)
+
+    -   ### WebOfTrust
+
+        # self framing
+
+        ###### Definition
+
+        a textual encoding that includes type, size, and value is self-framing.
+        Source [Samual M Smith](https://www.ietf.org/archive/id/draft-ssmith-cesr-02.txt)
+
+        ###### Detailed explanation
+
+        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).
+
+        ###### Related to CESR
+
+        Although a first class textual encoding of cryptographic primitives is the primary motivation for the [CESR](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [self sovereign identity](#self-sovereign-identity)
+
+    -   ### WebOfTrust
+
+        # self sovereign identity
+
+        ###### Definition
+
+        Self-Sovereign Identity (SSI) is a term that has many different interpretations, and that we use to refer to concepts/ideas, architectures, processes and technologies that aim to support (autonomous) parties as they negotiate and execute electronic transactions with one another.
+        Paraphrased by @henkvancann, sources [eSSIF-lab](https://essif-lab.github.io/framework/docs/terms/self-sovereign-identity) and [ToIP](https://github.com/trustoverip/toip/wiki/self-sovereign-identity).
+
+        ###### More in ToIP glossary
+
+        [SSI](https://github.com/trustoverip/toip/wiki/self-sovereign-identity)
+
+        ###### eSSIF-lab excerpt
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [self sovereignty](#self-sovereignty)
+
+    -   ### WebOfTrust
+
+        # self sovereignty
+
+        ###### See
+
+        [Self sovereignty](https://github.com/trustoverip/toip/wiki/self-sovereignty) in Trust over IP wiki.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [self-addressing identifier (SAID)](#selfaddressingidentifier\(SAID\))
+
+    -   ### ToIP (DID:Webs)
+
+        An identifier that is uniquely and cryptographically bound to a serialization of data (content-addressable) while also being included as a component in that serialization (self-referential), as defined by the CESR specification. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [self-asserted](#h.yg81kearf9rl)
+
+    -   ### ToIP
+
+        A term used to describe a [claim](#h.akieli6njkk5) or a [credential](#h.kcj6iw2vib1v) whose [subject](#h.voca6uuv1a4) is also the [issuer](#h.xyrplzbvtffq).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [self-certified](#h.yc694wxuvua1)
+
+    -   ### ToIP
+
+        When a [party](#h.cn6bno48fomj) provides its own [certification](#h.ytzysnyu57ec) that it is [compliant](#h.r0iiayz1za1i) with a set of [requirements](#h.ajxlw8r3dvcc), such as a [governance framework](#h.2x05z0r097mn).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [self-certifying identifier](#h.hub48c59i8wj)
+
+    -   ### ToIP
+
+        A subclass of [verifiable identifier](#h.wyda231qefe) that is [cryptographically verifiable](#h.422iwwfur12) without the need to rely on any [third party](#h.zu2vj8151tr) for [verification](#h.2bnb6g8na7cu) because the [identifier](#h.u3bfehmj4ed3) is cryptographically bound to the [cryptographic keys](#h.53rzpn1yn6q7) from which it was generated.
+
+        See also: [autonomic identifier](#h.bz098kwwc559).
+
+        Also known as: [SCID](#h.1hgjtlg27gg4).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [self-sovereign](#selfsovereign)
+
+    -   ### digital.govt.nz
+
+        (concept) an entity having sole ownership over the ability to control their accounts and information\[Source: Based on searchsecurity.techtarget.com\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [self-sovereign identity](#h.wdojy63bltd4)
+
+    -   ### ToIP
+
+        A [decentralized identity](#h.xodo7ytn4cx2) architecture that implements the [Principles of SSI](#h.dk15fkyq7xn5).
+
+        See also: [federated identity](#h.cb1le64hx6h5).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23ssi-self-sovereign-identity&sa=D&source=editors&ust=1718703186811735&usg=AOvVaw2W75NBll8qRqzuSL11ZbAK): SSI (Self-Sovereign Identity) is a term that has many different interpretations, and that we use to refer to concepts/ideas, architectures, processes and technologies that aim to support (autonomous) [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186811969&usg=AOvVaw1wMTJBa7dvDPEDaxlSmIB7) as they negotiate and execute electronic [transactions](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/transaction&sa=D&source=editors&ust=1718703186812159&usg=AOvVaw0kDfN3l400_x8TePXHhCLM) with one another.
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Self-sovereign_identity&sa=D&source=editors&ust=1718703186812402&usg=AOvVaw3acR3RaITPwf-bTpfyoQ3D): Self-sovereign identity (SSI) is an approach to [digital identity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_identity&sa=D&source=editors&ust=1718703186812558&usg=AOvVaw2Ml4wMadmrKiuXym838EHg) that gives individuals control over the information they use to prove who they are to [websites](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Website&sa=D&source=editors&ust=1718703186812695&usg=AOvVaw3qfYsQz-I1UyS8-0jlJeZN), services, and [applications](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Application_software&sa=D&source=editors&ust=1718703186812861&usg=AOvVaw3Vxhas3LjyscZwP1h7OE_e) across the web. Without SSI, individuals with persistent accounts (identities) across the [internet](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet&sa=D&source=editors&ust=1718703186813046&usg=AOvVaw3i59GcI5ik_xUnopvhJxjf) must rely on a number of large identity providers, such as [Facebook](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Facebook&sa=D&source=editors&ust=1718703186813219&usg=AOvVaw1daNtdIzoeEr9v0v5v0kE4) (Facebook Connect) and [Google](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Google&sa=D&source=editors&ust=1718703186813417&usg=AOvVaw0u7d21VL9mSqVom9ZVgbkP) (Google Sign-In), that have control of the information associated with their identity.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [sensitive data](#h.l8f0y0lobzpi)
+
+    -   ### ToIP
+
+        [Personal data](#h.rpiib2ml3s9c) that a reasonable [person](#h.yx4qb6dcjdvj) would view from a privacy protection standpoint as requiring special care above and beyond other [personal data](#h.rpiib2ml3s9c).
+
+        Supporting definitions:
+
+        [PEMC IGR](https://www.google.com/url?q=https://kantarainitiative.org/download/pemc-implementors-guidance-report/&sa=D&source=editors&ust=1718703186814007&usg=AOvVaw35aHMJq2Yxp0liMCjBRUls): While all Personal Information may be regarded as sensitive in that an unauthorized processing of an individual’s data may be offensive to that person, we use the term here to denote information that a reasonable person would view as requiring special care above and beyond other personal data. For reference see [GDPR Recital #51](https://www.google.com/url?q=https://www.privacy-regulation.eu/en/recital-51-GDPR.htm&sa=D&source=editors&ust=1718703186814255&usg=AOvVaw3ATU0uyr5WziSy4RHoEedQ) or [Sensitive Personal Data](https://www.google.com/url?q=https://w3c.github.io/dpv/dpv/%23SensitivePersonalData&sa=D&source=editors&ust=1718703186814404&usg=AOvVaw05GbtIjLhE5rQNY76lrxNg) in the W3C [Data Privacy Vocabulary](https://www.google.com/url?q=https://w3id.org/dpv&sa=D&source=editors&ust=1718703186814569&usg=AOvVaw2vgkX9g99Yb1MLXd1LHavX).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [server sent event](#server-sent-event)
+
+    -   ### WebOfTrust
+
+        # server sent event
+
+        ###### Definition
+
+        Mailbox notifications; a streaming service for the agent U/I, to get notifications from the KERI system itself.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [service](#service)
+
+    -   ### digital.govt.nz
+
+        a system or method of providing people with the use of something, as electric power, water, transportation, mail delivery.\[Source: Dictionary\]Additional notes:Note 1: Today service has a broader application than utilities, such as finance, employment and compliance services.Note 2: A service may contain 1 or more transactions.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [service endpoint](#serviceendpoint)
+
+    -   ### W3C (DID)
+
+        A network address, such as an HTTP URL, at which services operate onbehalf of a DID subject.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+    -   ### WebOfTrust
+
+        # service endpoint
+
+        ###### Definition
+
+        In our context we consider a **web service endpoint** which is a [URL](https://weboftrust.github.io/keridoc/docs/glossary/uniform-resource-locator.md) at which clients of specific service can get access to the service.
+
+        ###### Inner working
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [services](#services)
+
+    -   ### W3C (DID)
+
+        Means of communicating or interacting with the DID subject orassociated entities via one or more service endpoints.Examples include discovery services, agent services, social networkingservices, file storage services, and verifiable credential repository services.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [session](#session)
+
+    -   ### digital.govt.nz
+
+        an unbroken interactive information interchange between 2 or more entities\[Source: Wikipedia (computer science) modified\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        See: [communication session](#h.i82tgrmxy0d8).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [siger](#siger)
+
+    -   ### WebOfTrust
+
+        # siger
+
+        ###### See [Indexed signature](https://weboftrust.github.io/keridoc/docs/glossary/indexed-signature.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [signed digest](#signed-digest)
+
+    -   ### WebOfTrust
+
+        # signed digest
+
+        ###### Definition
+
+        commitment to content, by digitally signing a digest of this content.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [signer](#signer)
+
+    -   ### WebOfTrust
+
+        # signer
+
+        ###### Definition
+
+        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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [signify](#signify)
+
+    -   ### WebOfTrust
+
+        # signify
+
+        ###### Definition
+
+        Signify is a web client [(key) event](https://weboftrust.github.io/keridoc/docs/glossary/key-event.md) signing - and key pair creation app that minimizes the use of [KERI](https://weboftrust.github.io/keridoc/docs/glossary/KERI.md) on the client.
+
+        The main reason is that we want to minimize what needs to be put in the client or the cloud. Most proofs should be cryptographically verifiable and it should not be able to be repudiated (successful [pointing fingers](https://weboftrust.github.io/keridoc/docs/glossary.md#Finger-pointing) should be prevented), and this happens when the signatures come straight from the controller.
+
+        ###### Background
+
+        On a small set of activities that need to be protected in infrastructure for key management
+
+        -   key pair creation
+        -   key pair storage
+        -   event generating
+        -   event signing
+        -   event verification
+
+        ###### Finger pointing
+
+        What are the liabilities do a cloud host has to worry about?
+
+        -   Cloud host does not want to see keys (non-repudiation). So we want to move event signing out of the cloud agent.
+        -   Key state (next [digest](https://weboftrust.github.io/keridoc/docs/glossary/digest.md) and current signing key) come from the client
+        -   Cloud host ensures that the code supply chain is secure and never sees the private keys
+
+        [Learn more](https://kerisse.org)
+
+-   ## [signify keria request authentication protocol](#signify-keria-request-authentication-protocol)
+
+    -   ### WebOfTrust
+
+        # signify keria request authentication protocol
+
+        ###### Definition
+
+        SKRAP is a client to the KERIA server. Mobile clients will be using SKRAP to connect to KERI [AID](https://weboftrust.github.io/keridoc/docs/glossary/AID.md)s via [agent](https://weboftrust.github.io/keridoc/docs/glossary/agent.md)s in the new, multi-tenant Mark II Agent server, [KERIA](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/docs/glossary/signify.md) signs things at the edge. This includes [ACDC](https://weboftrust.github.io/keridoc/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
+
+        ###### Related to KERIA
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [signing authority](#signing-authority)
+
+    -   ### WebOfTrust
+
+        # signing authority
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/rotation-authority.md) is not included.
+
+        ###### Relation to rotation authority
+
+        The original controller of an [AID](https://weboftrust.github.io/keridoc/docs/glossary/autonomic-identifier.md) can hold exclusive [rotation authority](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/pre-rotation.md)) for [rotation authority](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/custodial-agent.md) can hold signing authority while the original controller can hold exclusive rotation authority.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [signing threshold](#signing-threshold)
+
+    -   ### WebOfTrust
+
+        # signing threshold
+
+        ###### Definition
+
+        Is the minimum number of valid signatures to satisfy the requirement for successful verification in a [Threshold Signature Scheme](https://weboftrust.github.io/keridoc/docs/glossary/threshold-signature-scheme.md).
+
+        ###### Example 2-of-3 signature
+
+        In a 2-of-3 signature scheme the threshold is 2. This means that 2 valid signatures are enough to fulfil the required signature.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [simple keri for web auth](#simple-keri-for-web-auth)
+
+    -   ### WebOfTrust
+
+        # simple keri for web auth
+
+        ###### Definition
+
+        A [KERI](https://weboftrust.github.io/keridoc/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).
+
+        ###### Design
+
+        Designed for private clouds, just like [Keep](https://weboftrust.github.io/keridoc/docs/glossary/keep.md). [Signify](https://weboftrust.github.io/keridoc/docs/glossary/signify.md) is designed for public clouds.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [single signature identifier](#single-signature-identifier)
+
+    -   ### WebOfTrust
+
+        # single signature identifier
+
+        ###### Definition
+
+        or single sig identifier; is an identifier controlled by a one-of-one signing [keypair](https://weboftrust.github.io/keridoc/docs/glossary/key-pair.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [sniffable](#sniffable)
+
+    -   ### WebOfTrust
+
+        # sniffable
+
+        ###### Definition
+
+        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/keridoc/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_.
+
+        ###### Challenge
+
+        We have the Cold start problem of a stream: you don't where to start recognizing structured data.
+
+        ###### Criterium
+
+        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
+
+        ###### Related
+
+        [Sniffer](https://weboftrust.github.io/keridoc/docs/glossary/sniffer.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [sniffer](#sniffer)
+
+    -   ### Nist
+
+        See packet sniffer and passive wiretapping.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/sniffer)
+
+    -   ### WebOfTrust
+
+        # sniffer
+
+        ###### Definition
+
+        The _sniffer_ is part of [Parside](https://weboftrust.github.io/keridoc/docs/glossary/parside.md) and detects if the CESR stream contains CESR binary, CESR Text, JSON, CBOR, MGPK.
+
+        ###### Working
+
+        If any of JSON, CBOR, MGPK then the parser regexes to find the [version string](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/version-code.md) or any other count codes.
+
+        Source Slack Cesride thread: Feb 2 2023
+
+        ###### Related
+
+        [Sniffable](https://weboftrust.github.io/keridoc/docs/glossary/sniffable.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [sociotechnical system](#h.wjui8ufitkkx)
+
+    -   ### ToIP
+
+        An approach to complex organizational work design that recognizes the interaction between people and technology in workplaces. The term also refers to coherent systems of human relations, technical objects, and cybernetic processes that inhere to large, complex infrastructures. Social society, and its constituent substructures, qualify as complex sociotechnical systems.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Sociotechnical_system&sa=D&source=editors&ust=1718703186815186&usg=AOvVaw3o4zuDDUVm3FoM_6eKPbeu)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [software agent](#h.qv9e403ohhxe)
+
+    -   ### ToIP
+
+        In computer science, a software agent is a computer program that acts for a user or other program in a relationship of [agency](#h.7q79v9jnqhrr), which derives from the Latin agere (to do): an agreement to act on one's behalf. A [user agent](#h.jb61co23rlut) is a specific type of software agent that is used directly by an end-user as the [principal](#h.sydbe7rk6244).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Software_agent&sa=D&source=editors&ust=1718703186815707&usg=AOvVaw0DvGJaBV24dKxVKmZe1LPt).
+
+        See also: [digital agent](#h.z3ugzt4hgdf6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [solicited issuance](#solicited-issuance)
+
+    -   ### WebOfTrust
+
+        # solicited issuance
+
+        ###### Definition
+
+        The issuance of a Legal Entity vLEI Credentials, [OOR](https://weboftrust.github.io/keridoc/docs/glossary/OOR.md) vLEI Credentials and [ECR](https://weboftrust.github.io/keridoc/docs/glossary/ECR.md) vLEI Credentials upon receipt by the [QAR](https://weboftrust.github.io/keridoc/docs/glossary/QAR.md) of a Fully Signed issuance request from the [AVR](https://weboftrust.github.io/keridoc/docs/glossary/AVR.md)(s) of the [Legal Entity](https://weboftrust.github.io/keridoc/docs/glossary/legal-entity.md).
+        [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.
+
+        ###### Related
+
+        See [Unsolicited issuance](https://weboftrust.github.io/keridoc/docs/glossary/unsolicited-issuance.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [source of truth](#source-of-truth)
+
+    -   ### WebOfTrust
+
+        # source of truth
+
+        ###### Definition
+
+        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.
+
+        ###### KERI and ACDC context
+
+        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
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [spanning layer](#h.wf49e15shob9)
+
+    -   ### ToIP
+
+        A specific layer within a [protocol stack](#h.6ik2cef0ipsr) that consists of a single protocol explicitly designed to provide interoperability between the [protocols layers](#h.pe8dekl2dtq0) above it and below it.
+
+        See also: [hourglass model](#h.u8d1rxc2o86), [trust spanning layer](#h.k9uiol17u620).
+
+        For more information, see: [https://www.isi.edu/newarch/iDOCS/final.finalreport.pdf](https://www.google.com/url?q=https://www.isi.edu/newarch/iDOCS/final.finalreport.pdf&sa=D&source=editors&ust=1718703186817017&usg=AOvVaw13qUrg0ao-pJeJ2EP_QqYZ), National Academies of Sciences, Engineering, and Medicine. 1997. The Unpredictable Certainty: White Papers. Washington, DC: The National Academies Press. [https://doi.org/10.17226/6062](https://www.google.com/url?q=https://doi.org/10.17226/6062&sa=D&source=editors&ust=1718703186817184&usg=AOvVaw3cdEgwCk_gfPKSLVgOnp1B).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # spanning layer
+
+        ###### Definition
+
+        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.
+
+        ![](https://github.com/WebOfTrust/keri/blob/main/images/spanning_layer.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [specification](#h.dst3g25dh97g)
+
+    -   ### ToIP
+
+        See: [technical specification](#h.u62ak0cgfdb1).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [spoofing](#spoofing)
+
+    -   ### digital.govt.nz
+
+        presenting a recorded image or other biometric data sample, or an artificially derived biometric characteristic, in order to impersonate an individual\[Source: ISO/IEC TR 24714-1:2008\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [spurn](#spurn)
+
+    -   ### WebOfTrust
+
+        # spurn
+
+        ###### Definition
+
+        Reject. The verb 'spurn' is originated in [IPEX](https://weboftrust.github.io/keridoc/docs/glossary/IPEX.md) specification.
+
+        | TBW prio 2 |
+
+        [Learn more](https://kerisse.org)
+
+-   ## [ssi system](#ssi-system)
+
+    -   ### WebOfTrust
+
+        # ssi system
+
+        ###### Definition
+
+        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)
+
+        ###### Purpose
+
+        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)
+
+        ###### KERI and ACDC related
+
+        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/keridoc/docs/glossary/self-sovereign-identity.md) available nowadays.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [stale event](#stale-event)
+
+    -   ### WebOfTrust
+
+        # stale event
+
+        ###### Definition
+
+        A stale key event is an outdated or irrelevant (key) event involving an [expired encryption key](https://weboftrust.github.io/keridoc/docs/glossary/stale-key.md) that may compromise security.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [stale key](#stale-key)
+
+    -   ### WebOfTrust
+
+        # stale key
+
+        ###### Definition
+
+        A stale key is an outdated or expired encryption key that should no longer be used for securing data
+
+        ###### Also see
+
+        [Stale (key) event](https://weboftrust.github.io/keridoc/docs/glossary/stale-event.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [stream](#h.8myrox1avszq)
+
+    -   ### ToIP
+
+        In the context of digital [communications](#h.w02a6srdng3j), and in particular [streaming media](#h.a9wzp42pgiac), a flow of [data](#h.o783ayrrkc6g) delivered in a continuous manner from a server to a client rather than in discrete [messages](#h.bge7ubygwk2q).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [streaming media](#h.a9wzp42pgiac)
+
+    -   ### ToIP
+
+        Streaming media is multimedia for playback using an offline or online media player. Technically, the stream is delivered and consumed in a continuous manner from a client, with little or no intermediate storage in network elements. Streaming refers to the delivery method of content, rather than the content itself.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Streaming_media&sa=D&source=editors&ust=1718703186818760&usg=AOvVaw1-F5O6ENDyNBlN3e2WhLG6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [strip parameter](#strip-parameter)
+
+    -   ### WebOfTrust
+
+        # strip parameter
+
+        ###### Definition
+
+        tells us what part of the [CESR](https://weboftrust.github.io/keridoc/docs/glossary/CESR.md) stream will be parsed by which code.
+
+        ###### Related
+
+        [Parside](https://weboftrust.github.io/keridoc/docs/glossary/parside.md)
+
+        | TBW |
+
+        [Learn more](https://kerisse.org)
+
+-   ## [sub shell](#sub-shell)
+
+    -   ### WebOfTrust
+
+        # sub shell
+
+        ###### Definition
+
+        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/)
+
+        ###### Parent - and child process
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [subject](#subject)
+
+    -   ### digital.govt.nz
+
+        entity that is the focus of entity information
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        The [entity](#h.5imtbzl1f4xo) described by one or more [claims](#h.akieli6njkk5), particularly in the context of [digital credentials](#h.ddna9lucn4k6).
+
+        Supporting definitions:
+
+        [W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186819270&usg=AOvVaw3ucr8wM7ZUoXzk1cPgbUsG): A thing about which [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186819489&usg=AOvVaw2HiAuRd6ISylHyNYeyLmSj) are made.
+
+        [eSSIF-Lab:](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23subject&sa=D&source=editors&ust=1718703186819694&usg=AOvVaw2VfxeqfQpLbsV7SEyoe1-I) the (single) [entity](#h.5imtbzl1f4xo) to which a given set of coherent [data](#h.o783ayrrkc6g) relates/pertains. Examples of such sets include attributes, [Claims](#h.akieli6njkk5)/Assertions, files/dossiers, [(verifiable) credentials](#h.co5algna3zkh), [(partial) identities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/partial-identity&sa=D&source=editors&ust=1718703186820033&usg=AOvVaw04DcZC4RJtsZ3fI4Xr7hNJ), [employment contracts](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/employment-contract&sa=D&source=editors&ust=1718703186820190&usg=AOvVaw34SVY7KR1wdf6FYj1d9mKl), etc.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [subscription](#h.59sxmlru2xqb)
+
+    -   ### ToIP
+
+        In the context of decentralized digital trust infrastructure, a subscription is an agreement between a first [digital agent](#h.z3ugzt4hgdf6)—the publisher—to automatically send a second [digital agent](#h.z3ugzt4hgdf6)—the subscriber—a [message](#h.bge7ubygwk2q) when a specific type of event happens in the [wallet](#h.mh27630t20d) or [vault](#h.cz29glapo2tg) managed by the first [digital agent](#h.z3ugzt4hgdf6).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [supermajority](#supermajority)
+
+    -   ### WebOfTrust
+
+        # supermajority
+
+        ###### Definition
+
+        Sufficient majority that is labeled _immune_ from certain kinds of attacks or faults.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [supporting system](#h.nqtdtghyfspz)
+
+    -   ### ToIP
+
+        A system that operates at [ToIP Layer 1](#h.24ggrl8oz4ma), the [trust support](#h.lk120yblym61) [layer](#h.lk120yblym61) of the [ToIP stack](#h.wms58fgdch9m). A supporting system is one of three types of systems defined in the [ToIP Technology Architecture Specification](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.bjv9ltwjbiqm&sa=D&source=editors&ust=1718703186821069&usg=AOvVaw0I568P-KSjeay-cZ6F0aoz).
+
+        See also: [endpoint system](#h.scy14dobg777), [intermediary system](#h.hcobm4uk16ff).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [synchronise ~ous](#synchronise~ous)
+
+    -   ### digital.govt.nz
+
+        to occur or recur or cause to occur or recur at the same time or in unison\[Source: Dictionary\]
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+-   ## [system of record](#h.ceh3cl4l0xnp)
+
+    -   ### ToIP
+
+        A system of record (SOR) or source system of record (SSoR) is a data management term for an information storage system (commonly implemented on a computer system running a database management system) that is the [authoritative data source](#h.9tt1qpgdfnxs) for a given data element or piece of information.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/System_of_record&sa=D&source=editors&ust=1718703186822106&usg=AOvVaw0xgC48auE4Vhy-G9m6aBmC)
+
+        See also: [authoritative source](#h.9tt1qpgdfnxs), [trust registry](#h.5kzln6m5e8j5), [verifiable data registry](#h.q1dr1v2lltfe).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [tamper resistant](#h.hpl12if94wa6)
+
+    -   ### ToIP
+
+        A process which makes alterations to the [data](#h.o783ayrrkc6g) difficult (hard to perform), costly (expensive to perform), or both.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/tamper_resistant&sa=D&source=editors&ust=1718703186822672&usg=AOvVaw0s1TG3HV1tzc9MuO-XPNW2).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [tcp endpoint](#tcp-endpoint)
+
+    -   ### WebOfTrust
+
+        # tcp endpoint
+
+        ###### Definition
+
+        This is a [service endpoint](https://weboftrust.github.io/keridoc/docs/glossary/service-endpoint.md) of the web [transmission control protocol](https://weboftrust.github.io/keridoc/docs/glossary/transmission-control-protocol.md)
+
+        ###### More details
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [technical requirement](#h.l7t266ck3tjw)
+
+    -   ### ToIP
+
+        A [requirement](#h.ajxlw8r3dvcc) for a hardware or software component or system. In the context of decentralized digital trust infrastructure, technical requirements are a subset of [governance requirements](#h.j4z5czk0dk8t). Technical requirements are often specified in a [technical specification](#h.u62ak0cgfdb1).
+
+        For more information, see: [https://datatracker.ietf.org/doc/html/rfc2119](https://www.google.com/url?q=https://datatracker.ietf.org/doc/html/rfc2119&sa=D&source=editors&ust=1718703186823845&usg=AOvVaw1VOl17XM400y9Dr1JBMXWo) 
+
+        Note: In ToIP architecture, both technical requirements and [governance requirements](#h.j4z5czk0dk8t) are expressed using the keywords defined in IETF RFC 2119.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [technical specification](#h.u62ak0cgfdb1)
+
+    -   ### ToIP
+
+        A document that specifies, in a complete, precise, verifiable manner, the [requirements](#h.ajxlw8r3dvcc), design, behavior, or other characteristics of a system or component and often the procedures for determining whether these provisions have been satisfied.
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/specification&sa=D&source=editors&ust=1718703186824419&usg=AOvVaw1XCUzYsmUW3j9NBGM6u8YM)
+
+        See also: [governance framework](#h.2x05z0r097mn), [governance requirement](#h.j4z5czk0dk8t), [policy](#h.udts41hso4w4), [rule](#h.v7s575ulon74).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [technical trust](#h.7vxscxecc0g)
+
+    -   ### ToIP
+
+        A [level of assurance](#h.qseghs6dqcd) in a [trust relationship](#h.pu2asd79bqzo) that can be achieved only via technical means such as hardware, software, network [protocols](#h.pe8dekl2dtq0), and cryptography. Cryptographic trust is a specialized type of technical trust.
+
+        Contrast with: [human trust](#h.a4jfn38wd17o).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [term](#h.ojn7uxdcaf7u)
+
+    -   ### ToIP
+
+        A unit of text (i.e., a word or phrase) that is used in a particular context or scope to refer to a [concept](#h.6hyxh4mxxbu2) (or a relation between [concepts](#h.6hyxh4mxxbu2), or a [property](#h.c8vs1xa4uwn) of a [concept](#h.6hyxh4mxxbu2)).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23term&sa=D&source=editors&ust=1718703186826144&usg=AOvVaw1idD3SYP2uJgd5uR6IoBTO): a word or phrase (i.e.: text) that is used in at least one [scope](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/scope&sa=D&source=editors&ust=1718703186826444&usg=AOvVaw0WISY_gsrax47VJEsjxiD9)/context to represent a specific [concept](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/concept&sa=D&source=editors&ust=1718703186826605&usg=AOvVaw1y-wu4xdZ6aiAOlqznnrQy).
+
+        [Merriam Webster:](https://www.google.com/url?q=https://www.merriam-webster.com/dictionary/term&sa=D&source=editors&ust=1718703186826794&usg=AOvVaw1JBTpOHHx8Velq8V4ODnQ5) a word or expression that has a precise meaning in some uses or is peculiar to a science, art, profession, or subject.
+
+        Note: A term MUST NOT be confused with the concept it refers to.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [terminology](#h.189fachpwy1a)
+
+    -   ### ToIP
+
+        Terminology is a group of specialized words and respective meanings in a particular field, and also the study of such [terms](#h.ojn7uxdcaf7u) and their use; the latter meaning is also known as terminology science. A term is a word, compound word, or multi-word expressions that in specific contexts is given specific meanings—these may deviate from the meanings the same words have in other contexts and in everyday language.[\[2\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Terminology%23cite_note-2&sa=D&source=editors&ust=1718703186827359&usg=AOvVaw0MUvJWIOjgrVgDAwCvieAb) Terminology is a discipline that studies, among other things, the development of such [terms](#h.ojn7uxdcaf7u) and their interrelationships within a specialized domain. Terminology differs from lexicography, as it involves the study of [concepts](#h.6hyxh4mxxbu2), conceptual systems and their labels (terms), whereas lexicography studies words and their meanings.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Terminology&sa=D&source=editors&ust=1718703186827744&usg=AOvVaw3aRS61gBUAF5kMB2CJmPYN).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [terms community](#h.lm4sxza2a80c)
+
+    -   ### ToIP
+
+        A group of [parties](#h.cn6bno48fomj) who share the need for a common [terminology](#h.189fachpwy1a).
+
+        See also: [trust community](#h.a9l3odcb1s29).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [terms wiki](#h.jhi3ltfxhmy5)
+
+    -   ### ToIP
+
+        A wiki website used by a [terms community](#h.lm4sxza2a80c) to input, maintain, and publish its [terminology](#h.189fachpwy1a). The ToIP Foundation Concepts and Terminology Working Group has established a simple template for GitHub-based terms wikis.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [text binary concatenation composability](#text-binary-concatenation-composability)
+
+    -   ### WebOfTrust
+
+        # text binary concatenation composability
+
+        ###### Definition
+
+        An encoding has _composability_ when any set of [self-framing](https://weboftrust.github.io/keridoc/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 related
+
+        CESR is fully text binary concatenation composable.
+
+        ###### Example in analogy
+
+        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.
+        ![](https://hackmd.io/_uploads/H1e8_BbmMi.png)![](https://hackmd.io/_uploads/B1pFrbXfj.png)
+
+        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).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [thing](#h.yyvwb9txkdzw)
+
+    -   ### ToIP
+
+        An [entity](#h.5imtbzl1f4xo) that is neither a [natural person](#h.yx4qb6dcjdvj) nor an [organization](#h.z27mp1358pi9) and thus cannot be a [party](#h.cn6bno48fomj). A thing may be a [natural thing](#h.njbtirxy3jvo) or a [man-made thing](#h.98jmqz1068vj).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [third party](#h.zu2vj8151tr)
+
+    -   ### ToIP
+
+        A [party](#h.cn6bno48fomj) that is not directly involved in the trust relationship between a [first party](#h.uxx5bjam20ag) and a [second party](#h.hk94wskqnzri), but provides supporting services to either or both of them.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [tholder](#tholder)
+
+    -   ### WebOfTrust
+
+        # tholder
+
+        ###### Definition
+
+        t-holder object that supports fractionally-weighted [thresholds](https://weboftrust.github.io/keridoc/docs/glossary/signing-threshold.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [three party model](#h.2afq075qllho)
+
+    -   ### ToIP
+
+        The issuer—holder—verifier model used by all types of [physical credentials](#h.xnlz1vfx60mn) and [digital credentials](#h.ddna9lucn4k6) to enable [transitive trust decisions](#h.syc9o7x61rkm).
+
+        Also known as: [trust triangle](#h.n29niebkxky7).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [threshold of accountable duplicity](#threshold-of-accountable-duplicity)
+
+    -   ### WebOfTrust
+
+        # threshold of accountable duplicity
+
+        ###### Definition
+
+        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`.
+
+        ###### TOAD in KEL
+
+        A controller declares TOAD in its [key event log (KEL)](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md) during the [key inception event](https://weboftrust.github.io/keridoc/docs/glossary/inception-event.md) and may edit it during subsequent [key rotation events](https://weboftrust.github.io/keridoc/docs/glossary/rotation-event.md).
+
+        ###### Purpose of TOAD
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [threshold signature scheme](#threshold-signature-scheme)
+
+    -   ### WebOfTrust
+
+        # threshold signature scheme
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [threshold structure security](#threshold-structure-security)
+
+    -   ### WebOfTrust
+
+        # threshold structure security
+
+        ###### Definition
+
+        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.
+        In other words, with threshold structures, overall security may be greater than the security of any of the individual parts.
+
+        For example, in [MFA](https://weboftrust.github.io/keridoc/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 Structure Security vs. TEE Security
+
+        Threshold structures may be employed in a complementary manner to trusted execution environments ([TEE](https://weboftrust.github.io/keridoc/docs/glossary/trusted-execution-environment.md)) for security. The two types of security are complementary.
+
+        ###### KERI related
+
+        This applies to KERI as well. The [witnesses](https://weboftrust.github.io/keridoc/docs/glossary/witness.md) and [watchers](https://weboftrust.github.io/keridoc/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.
+
+        ##### Considerations
+
+        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
+
+        [Learn more](https://kerisse.org)
+
+-   ## [timestamp](#h.7l3etghzasqf)
+
+    -   ### ToIP
+
+        A token or packet of information that is used to provide assurance of timeliness; the timestamp contains timestamped data, including a time, and a signature generated by a [t](#h.ryrs51vhrwny)[rusted timestamp authority](#h.ryrs51vhrwny) (TTA).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/timestamp&sa=D&source=editors&ust=1718703186830490&usg=AOvVaw1gaKlvRnromkRohLEz7SjN).
+
+        Supporting definitions:
+
+        [TechTarget](https://www.google.com/url?q=https://www.techtarget.com/whatis/definition/timestamp%23:~:text%3DA%2520timestamp%2520is%2520the%2520current,minute%2520fractions%2520of%2520a%2520second.&sa=D&source=editors&ust=1718703186830923&usg=AOvVaw1eorsetDTlyYtvTpcQ_xPe): A timestamp is the current time of an event that a computer records. Through mechanisms, such as the [Network Time Protocol](https://www.google.com/url?q=https://www.techtarget.com/searchnetworking/definition/Network-Time-Protocol&sa=D&source=editors&ust=1718703186831144&usg=AOvVaw3TgZn7W84yJYRJo0nrUP7w), a computer maintains accurate current time, calibrated to minute fractions of a second. Such precision makes it possible for networked computers and applications to communicate effectively.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [top level section](#top-level-section)
+
+    -   ### WebOfTrust
+
+        # top level section
+
+        ###### Definition
+
+        The fields of an ACDC in [compact variant](https://weboftrust.github.io/keridoc/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).
+
+        ###### Example
+
+        ![top level section of an ACDC](https://hackmd.io/_uploads/rJ0JJcEes.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [trans contextual value](#trans-contextual-value)
+
+    -   ### WebOfTrust
+
+        # trans contextual value
+
+        ###### Definition
+
+        Value that is transferrable between contexts
+
+        ###### Related to KERI
+
+        **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
+
+        ##### 1\. Leverage cooperative network effects
+
+        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.
+
+        ##### 2\. Retake control of our data
+
+        KERI assists in this.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [transaction](#transaction)
+
+    -   ### digital.govt.nz
+
+        one or more exchanges between an individual and an organisation in a process related to a specific outcomeAdditional notes:Note 1: A single transaction may constitute a step in a segmented process or result in the completion of an end to end process.Note 2: A service is usually made up of several transactions.
+
+        [Learn more](https://www.digital.govt.nz/standards-and-guidance/identification-management/identification-terminology/)
+
+    -   ### ToIP
+
+        A discrete event between a user and a system that supports a business or programmatic purpose. A digital system may have multiple categories or types of transactions, which may require separate analysis within the overall digital identity [risk assessment](#h.91ipsr7y3vb6).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/transaction&sa=D&source=editors&ust=1718703186846516&usg=AOvVaw08URSpX_9ifyEw-nrM-c6t).
+
+        See also: [connection](#h.thbpewq1px8x).
+
+        Supporting definitions:
+
+        eSSIF-Lab: the exchange of goods, services, funds, or data between some [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186847031&usg=AOvVaw1SO0tdAmUM4Ug6YIbcTF9Z) (called [participants](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/participant&sa=D&source=editors&ust=1718703186847274&usg=AOvVaw1ujfn9Cx1HlddOLY79dMG3) of the [transaction](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/transaction&sa=D&source=editors&ust=1718703186847491&usg=AOvVaw04hyNXMO3_G5GGzZFl0bol)).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [transaction event log](#transaction-event-log)
+
+    -   ### WebOfTrust
+
+        # transaction event log
+
+        ###### Definition
+
+        The set of transactions that determine registry state form a log called a Transaction Event Log (TEL). The TEL provides a cryptographic proof of registry state by reference to the corresponding controlling [KEL](https://weboftrust.github.io/keridoc/docs/glossary/key-event-log.md). Any validator may therefore cryptographically verify the [authoritative state](https://weboftrust.github.io/keridoc/docs/glossary/authoritative.md) of the [registry](https://weboftrust.github.io/keridoc/docs/glossary/registry.md).
+
+        ##### Put differently
+
+        An externally anchored transactions log via cryptographic commitments in a KEL.
+
+        ![](https://github.com/WebOfTrust/keri/blob/main/images/TEL-and-KEL.png)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [transaction event log (TEL)](#transactioneventlog\(TEL\))
+
+    -   ### ToIP (DID:Webs)
+
+        A verifiable append-only log of transaction data that are cryptographically anchored to a KEL. The transaction events of a TEL may be used to establish the issuance or revocation state of ACDCs. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+-   ## [transfer off ledger](#transfer-off-ledger)
+
+    -   ### WebOfTrust
+
+        # transfer off ledger
+
+        ###### Definition
+
+        The act of transferring control authority over an identifier from a ledger (or blockchain) to the native verifiable KERI data structure Key Event Log.
+
+        ###### Transition option
+
+        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.
+
+        ###### One at a time
+
+        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 justdoing 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.
+
+        ###### Move identifiers across networks
+
+        You can move identifiers across networks with KERI, but it's not what it has been designed for.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [transferable](#transferable)
+
+    -   ### WebOfTrust
+
+        # transferable
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/non-transferable.md).
+        [Source](https://www.wordnik.com/words/transferable)
+
+        ###### KERI related
+
+        Focus is on the digital space and concerning the loss-less transfer of control over [identifiers](https://weboftrust.github.io/keridoc/docs/glossary/transferable-identifier.md), private keys, etc.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [transferable identifier](#transferable-identifier)
+
+    -   ### WebOfTrust
+
+        # transferable identifier
+
+        ###### Definition
+
+        Control over the identifier [can be transferred](https://weboftrust.github.io/keridoc/docs/glossary/transferable.md) by rotating keys.
+        A synonym is 'persistent identifier'.
+
+        | TBW prio 1 |
+
+        ###### KERI related
+
+        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/keridoc/docs/glossary/non-transferable-identifier.md)
+        -   [delegated identifiers](https://weboftrust.github.io/keridoc/docs/glossary/delegated-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [transitive trust decision](#h.syc9o7x61rkm)
+
+    -   ### ToIP
+
+        A [trust decision](#h.m8c86ccqis9r) made by a [first party](#h.uxx5bjam20ag) about a [second party](#h.hk94wskqnzri) or another [entity](#h.5imtbzl1f4xo) based on information about the [second party](#h.hk94wskqnzri) or the other [entity](#h.5imtbzl1f4xo) that is obtained from one or more [third parties](#h.zu2vj8151tr).
+
+        Note: A primary purpose of [digital credentials](#h.ddna9lucn4k6), [chained credentials](#h.wjc1hh3dzgc7), and [trust registries](#h.5kzln6m5e8j5) is to facilitate transitive trust decisions.
+
+        For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186848741&usg=AOvVaw0x4Pvc3qqGt7AKofI7sV78).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [transmission control protocol](#transmission-control-protocol)
+
+    -   ### WebOfTrust
+
+        # transmission control protocol
+
+        ###### Definition
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [tribal knowledge](#h.musmuniitirr)
+
+    -   ### ToIP
+
+        [Knowledge](#h.k96lktyswxnb) that is known within an “in-group” of people but unknown outside of it. A [tribe](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Tribe&sa=D&source=editors&ust=1718703186852516&usg=AOvVaw0ARx3otjHHXraMj5to1xCh), in this sense, is a group of people that share such a common [knowledge](#h.k96lktyswxnb).
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Tribal_knowledge&sa=D&source=editors&ust=1718703186852909&usg=AOvVaw2SZ26pLXdzmd9zOnt6V0Bk)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust](#h.sdrgtm7bwb51)
+
+    -   ### ToIP
+
+        A belief that an [entity](#h.5imtbzl1f4xo) will behave in a predictable manner in specified circumstances. The entity may be a person, process, object or any combination of such components. The entity can be of any size from a single hardware component or software module, to a piece of equipment identified by make and model, to a site or location, to an organization, to a nation-state. Trust, while inherently a subjective determination, can be based on objective evidence and subjective elements. The objective grounds for trust can include for example, the results of information technology product testing and evaluation. Subjective belief, level of comfort, and experience may supplement (or even replace) objective evidence, or substitute for such evidence when it is unavailable. Trust is usually relative to a specific circumstance or situation (e.g., the amount of money involved in a transaction, the sensitivity or criticality of information, or whether safety is an issue with human lives at stake). Trust is generally not transitive (e.g., you trust a friend but not necessarily a friend of a friend). Finally, trust is generally earned, based on experience or measurement.
+
+        Source: [NIST Special Publication 800-39](https://www.google.com/url?q=https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf&sa=D&source=editors&ust=1718703186853623&usg=AOvVaw3pynzcDpzNF_6mmuJSYyqi) p.24
+
+        See also: [transitive trust decision](#h.syc9o7x61rkm).
+
+        For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186854119&usg=AOvVaw3kfUSaa0Dr-slVXeIOkkQS).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust anchor](#h.1w7kojkexdyz)
+
+    -   ### ToIP
+
+        See: [trust root](#h.vfnyletkzjv5).
+
+        Note: The term “trust anchor” is most commonly used in cryptography and [public key infrastructure](#h.mdxu5kpbdo4x).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust application layer](#h.z9t23rwrm0qi)
+
+    -   ### ToIP
+
+        In the context of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186855394&usg=AOvVaw26n_m9uRYzJMW6TXU2HuHp), the [trust application](#h.3pfn27y1gu2o) layer is [ToIP Layer 4](#h.ym4v87xpn7gq). Applications running at this layer call [trust task protocols](#h.uo2gx58kwj2o) at [ToIP Layer 3](#h.7rbvlbpp8vwp).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust assurance](#h.rtm3kplxtvr)
+
+    -   ### ToIP
+
+        A process that provides a [level of assurance](#h.qseghs6dqcd) sufficient to make a particular [trust decision](#h.m8c86ccqis9r).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust basis](#h.hwb3cttekok1)
+
+    -   ### ToIP
+
+        The [properties](#h.c8vs1xa4uwn) of a [verifiable identifier](#h.wyda231qefe) or a [ToIP system](#h.jxcr1cndl4co) that enable a [party](#h.cn6bno48fomj) to [appraise](#h.wtzlm8ocwx7a) it to determine a [trust limit](#h.bceor3akx4ko).
+
+        See also: [appraisability](#h.wtzlm8ocwx7a).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust boundary](#h.91w031j2r3g)
+
+    -   ### ToIP
+
+        The border of a [trust domain](#h.60miqe21hd5h).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust chain](#h.ijfmhuehjm0t)
+
+    -   ### ToIP
+
+        A set of [cryptographically verifiable](#h.422iwwfur12) links between [digital credentials](#h.ddna9lucn4k6) or other [data](#h.o783ayrrkc6g) containers that enable [transitive trust decisions](#h.syc9o7x61rkm).
+
+        See also: [chained credentials](#h.wjc1hh3dzgc7), [trust graph](#h.eqx98nkqjzsv).
+
+        For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186857350&usg=AOvVaw0aO9AEwXL5ArJGUP9X7Twv).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust community](#h.a9l3odcb1s29)
+
+    -   ### ToIP
+
+        A set of [parties](#h.cn6bno48fomj) who collaborate to achieve a mutual set of [trust objectives](#h.jxinqtx7eiev).
+
+        See also: [digital trust ecosystem](#h.h47f86smlz4y), [ToIP trust community](#h.psztqwnbl6o7).
+
+        Note: A trust community may be large or small, formal or informal. In a formal trust community, the set of [policies](#h.udts41hso4w4) and [rules](#h.v7s575ulon74) governing behavior of members are usually published in a [governance framework](#h.2x05z0r097mn) or [trust framework](#h.2r5mn949idq). In an informal trust community, the policies or rules governing the behavior of members may be [tribal knowledge](#h.musmuniitirr).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust context](#h.xc1hsb1i8vdu)
+
+    -   ### ToIP
+
+        The context in which a specific [party](#h.cn6bno48fomj) makes a specific [trust decision](#h.m8c86ccqis9r). Many different factors may be involved in establishing a trust context, such as: the relevant interaction or transaction; the presence or absence of existing [trust relationships](#h.pu2asd79bqzo); the applicability of one or more [governance frameworks](#h.2x05z0r097mn); and the location, time, network, and/or devices involved. A trust context may be implicit or explicit; if explicit, it may be identified using an [identifier](#h.u3bfehmj4ed3). A [ToIP governance framework](#h.ns22ebn9xjun) an example of an explicit trust context identified by a [ToIP identifier](#h.xtyidw4bnytz).
+
+        See also: [trust domain](#h.60miqe21hd5h).
+
+        For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186859065&usg=AOvVaw25UfQhXCANoYHMedq0uI-j).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust decision](#h.m8c86ccqis9r)
+
+    -   ### ToIP
+
+        A decision that a [party](#h.cn6bno48fomj) needs to make about whether to engage in a specific interaction or [transaction](#h.92pu88ke4p7k) with another [entity](#h.5imtbzl1f4xo) that involves real or perceived [risks](#h.qzpr4qua4ble).
+
+        See also: [transitive trust decision](#h.syc9o7x61rkm).
+
+        For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186859782&usg=AOvVaw3tX38JsIUaLnXn1kFV9gvK).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust domain](#h.60miqe21hd5h)
+
+    -   ### ToIP
+
+        A [security domain](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.d7ry9j100f36&sa=D&source=editors&ust=1718703186860091&usg=AOvVaw1bBvm_wnDReJKGsNQuFwKf) defined by a computer hardware or software architecture, a [security policy](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2fcbwog0w43a&sa=D&source=editors&ust=1718703186860290&usg=AOvVaw1g4Nwp50asW6f6Aewc8F4C), or a [trust community](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.a9l3odcb1s29&sa=D&source=editors&ust=1718703186860460&usg=AOvVaw2Wn1aWOZ-5TMhA5pUMV5Y-), typically via a [trust framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2r5mn949idq&sa=D&source=editors&ust=1718703186860639&usg=AOvVaw2nQ7qkp4lO37V1XOSo2wM9) or [governance framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2x05z0r097mn&sa=D&source=editors&ust=1718703186860882&usg=AOvVaw1QpAmZuJ3ggW1lsIa-PVS2).
+
+        See also: [trust context](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.xc1hsb1i8vdu&sa=D&source=editors&ust=1718703186861139&usg=AOvVaw2gDLV4K0G6q2ss6zUhdrpN), [digital trust ecosystem](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.h47f86smlz4y&sa=D&source=editors&ust=1718703186861342&usg=AOvVaw1EiGJFviUEkKlHbwma9l4n).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # trust domain
+
+        ###### Definition
+
+        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))
+
+        ###### Broader definition
+
+        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.
+
+        ###### Domain name
+
+        A more technical meaning of 'domain' is on the internet: [domain name](https://weboftrust.github.io/keridoc/docs/glossary/domain-name.md).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [trust ecosystem](#h.pxw5wsmny1in)
+
+    -   ### ToIP
+
+        See [digital trust ecosystem](#h.h47f86smlz4y).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust establishment](#h.snflr53nk18y)
+
+    -   ### ToIP
+
+        The process two or more [parties](#h.cn6bno48fomj) go through to establish a [trust relationship](#h.pu2asd79bqzo). In the context of decentralized digital trust infrastructure, trust establishment takes place at two levels. At the [technical trust](#h.7vxscxecc0g) level, it includes some form of [key establishment](#h.pkh9vfulrizg). At the [human trust](#h.a4jfn38wd17o) level, it may be accomplished via an [out-of-band introduction](#h.tsslu4lnog0s), the exchange of [digital credentials](#h.ddna9lucn4k6), queries to one or more [trust registries](#h.5kzln6m5e8j5), or evaluation of some combination of [human-readable](#h.ywyofmy4do4t) and [machine-readable](#h.8s3s84fzcfi3) [governance frameworks](#h.2x05z0r097mn).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust framework](#h.2r5mn949idq)
+
+    -   ### ToIP
+
+        A term (most frequently used in the [digital identity](#h.r5y8zwxvzyd3) industry) to describe a [governance framework](#h.2x05z0r097mn) for a [digital identity](#h.r5y8zwxvzyd3) system, especially a [federation](#h.7ph0icfh463b).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust graph](#h.eqx98nkqjzsv)
+
+    -   ### ToIP
+
+        A [data](#h.o783ayrrkc6g) structure describing the [trust relationship](#h.pu2asd79bqzo) between two or more [entities](#h.5imtbzl1f4xo). A simple trust graph may be expressed as a [trust list](#h.f1feh0fmucqd). More complex trust graphs can be recorded or registered in and queried from a [trust registry](#h.5kzln6m5e8j5). Trust graphs can also be expressed via [trust chains](#h.xsqvwmepvctc) and [chained credentials](#h.wjc1hh3dzgc7). Trust graphs can enable [verifiers](#h.xfewd7t01hu0) to make [transitive trust decisions](#h.syc9o7x61rkm).
+
+        See also: [authorization graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5tvkchqqqka8&sa=D&source=editors&ust=1718703186863358&usg=AOvVaw0Kq3a5UjwCqTBzdK4KkD7P), [governance graph](#h.u9xnz96ecf5x), [reputation graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.4wwkekt1wrs7&sa=D&source=editors&ust=1718703186863848&usg=AOvVaw3mR5tfs8cGPVGuXoRU46yg).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust limit](#h.bceor3akx4ko)
+
+    -   ### ToIP
+
+        A limit to the degree a [party](#h.cn6bno48fomj) is willing to trust an [entity](#h.5imtbzl1f4xo) in a specific [trust relationship](#h.pu2asd79bqzo) within a specific [trust context](#h.xc1hsb1i8vdu).
+
+        For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186864695&usg=AOvVaw2oW-t5tUx1C3rN4m1LVVud).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust list](#h.f1feh0fmucqd)
+
+    -   ### ToIP
+
+        A one-dimensional [trust graph](#h.eqx98nkqjzsv) in which an [authoritative source](#h.9tt1qpgdfnxs) publishes a list of [entities](#h.5imtbzl1f4xo) that are trusted in a specific [trust context](#h.xc1hsb1i8vdu). A trust list can be considered a simplified form of a [trust registry](#h.5kzln6m5e8j5).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust network](#h.iy4t4brzsjkb)
+
+    -   ### ToIP
+
+        A network of parties who are connected via [trust relationships](#h.pu2asd79bqzo) conforming to [requirements](#h.ajxlw8r3dvcc) defined in a legal regulation, [trust framework](#h.2r5mn949idq) or [governance framework](#h.2x05z0r097mn). A trust network is more formal than a [digital trust ecosystem](#h.h47f86smlz4y); the latter may connect parties more loosely via transitive trust relationships and/or across multiple trust networks.
+
+        See also: [ToIP trust network](#h.xomvclbue1bi).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust objective](#h.jxinqtx7eiev)
+
+    -   ### ToIP
+
+        An [objective](#h.k0v6ir8wmcav) shared by the [parties](#h.cn6bno48fomj) in a [trust community](#h.a9l3odcb1s29) to establish and maintain [trust relationships](#h.pu2asd79bqzo).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust registry](#h.5kzln6m5e8j5)
+
+    -   ### ToIP
+
+        A [registry](#h.farjhbxfa3lh) that serves as an [authoritative source](#h.9tt1qpgdfnxs) for [trust graphs](#h.eqx98nkqjzsv) or other [governed information](#h.g58y5pmth1sb) describing one or more [trust communities](#h.a9l3odcb1s29). A trust registry is typically [authorized](#h.gln5i78kxlfh) by a [governance framework](#h.2x05z0r097mn).
+
+        See also: [trust list](#h.f1feh0fmucqd), [verifiable data registry](#h.q1dr1v2lltfe).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust registry protocol](#h.f0d81ooa2iz8)
+
+    -   ### ToIP
+
+        See: [ToIP Trust Registry Protocol](#h.1ma9v3f1h53f).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust relationship](#h.pu2asd79bqzo)
+
+    -   ### ToIP
+
+        A relationship between a [party](#h.cn6bno48fomj) and an [entity](#h.5imtbzl1f4xo) in which the [party](#h.cn6bno48fomj) has decided to trust the [entity](#h.5imtbzl1f4xo) in one or more [trust contexts](#h.xc1hsb1i8vdu) up to a [trust limit](#h.bceor3akx4ko).
+
+        Supporting definitions:
+
+        [NIST](https://www.google.com/url?q=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf&sa=D&source=editors&ust=1718703186867386&usg=AOvVaw1khpSNxR4srFGgg8HHut4Z): An agreed upon relationship between two or more system elements that is governed by criteria for secure interaction, behavior, and outcomes relative to the protection of assets.
+
+        For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186867753&usg=AOvVaw1aJOshXxHz_1NQSmnHG-vN).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust root](#h.vfnyletkzjv5)
+
+    -   ### ToIP
+
+        The [authoritative source](#h.9tt1qpgdfnxs) that serves as the origin of a [trust chain](#h.xsqvwmepvctc).
+
+        For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186868340&usg=AOvVaw3nEFuNNQ7nL_MA1LblhihR).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust service provider](#h.lob8zt6w1hh)
+
+    -   ### ToIP
+
+        In the context of specific [digital trust ecosystems](#h.h47f86smlz4y), such as the European Union’s eIDAS regulations, a trust service provider (TSP) is a legal entity that provides specific [trust support](#h.451usstmcuuk) services as required by legal regulations, [trust frameworks](#h.2r5mn949idq), or [governance frameworks](#h.2x05z0r097mn). In the larger context of [ToIP](#h.nkx8p3tuemz) infrastructure, a TSP is a provider of services based on the [ToIP stack](#h.wms58fgdch9m). Most generally, a TSP is to the trust layer for the Internet what an Internet service provider (ISP) is to the Internet layer.
+
+        Also known as: [TSP](#h.vlopzkfv2l6j).
+
+        Supporting definitions:
+
+        Wikipedia: A trust service provider (TSP) is a person or legal entity providing and preserving [digital certificates](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_certificate&sa=D&source=editors&ust=1718703186869112&usg=AOvVaw0yKT2WH0yP7WL4uOzScMuh) to create and validate [electronic signatures](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_signature&sa=D&source=editors&ust=1718703186869284&usg=AOvVaw1XtLEkk9jhwffFzFvUTcnB) and to authenticate their signatories as well as websites in general. Trust service providers are qualified [certificate authorities](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Certificate_authority&sa=D&source=editors&ust=1718703186869459&usg=AOvVaw2Li-ZIRMYaiVH57OSAgL17) required in the [European Union](https://www.google.com/url?q=https://en.wikipedia.org/wiki/European_Union&sa=D&source=editors&ust=1718703186869614&usg=AOvVaw1Y790qcWQDS5vbpSroFo1E) and in Switzerland in the context of regulated [electronic signing](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_signature&sa=D&source=editors&ust=1718703186869767&usg=AOvVaw3GLECngygmR-eD-B2iVqTm) procedures.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust spanning layer](#h.k9uiol17u620)
+
+    -   ### ToIP
+
+        A [spanning layer](#h.wf49e15shob9) designed to span between different digital [trust domains](#h.60miqe21hd5h). In the [ToIP stack](#h.wms58fgdch9m), [ToIP Layer 2](#h.ikqr9hyt133k) is the trust spanning layer.
+
+        See also: [ToIP layer](#h.k5gg61txum2c).
+
+        Mental model: [hourglass model,](#h.u8d1rxc2o86) see [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm)
+
+        For more information, see: [Section 7.3](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2373-layer-2-trust-spanning&sa=D&source=editors&ust=1718703186871868&usg=AOvVaw27wgRgYCypAUZN6-yocuzE) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust spanning protocol](#h.fnuaao3a1j25)
+
+    -   ### ToIP
+
+        See: [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # trust spanning protocol
+
+        ###### Definition
+
+        Protocol using [VID](https://weboftrust.github.io/keridoc/docs/glossary/verifiable-identifier.md)s that signs every single message on the internet and makes them verifiable.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [trust support](#h.451usstmcuuk)
+
+    -   ### ToIP
+
+        A system, protocol, or other infrastructure whose function is to facilitate the establishment and maintenance of [trust relationships](#h.pu2asd79bqzo) at higher [protocol layers](#h.pe8dekl2dtq0). In the [ToIP stack](#h.wms58fgdch9m), the [trust support layer](#h.lk120yblym61) is [Layer 1](#h.v1hjglhanrdl).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust support layer](#h.lk120yblym61)
+
+    -   ### ToIP
+
+        In the context of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186870677&usg=AOvVaw04ulPHTfEl42uGmP65aj1e), the [trust support](#h.451usstmcuuk) layer is [ToIP Layer 1](#h.24ggrl8oz4ma). It supports the operations of the ToIP Trust Spanning Protocol at [ToIP Layer 2](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.ikqr9hyt133k&sa=D&source=editors&ust=1718703186871007&usg=AOvVaw054OXHrARD7c6_jy9_EzOv).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust task](#h.vzu8kc1yz84q)
+
+    -   ### ToIP
+
+        A specific task that involves establishing, verifying, or maintaining [trust relationships](#h.pu2asd79bqzo) or exchanging [verifiable messages](#h.7zrsx7mki2fr) or [verifiable data](#h.7n80iyjxkofu) that can be performed on behalf of a [trust application](#h.3pfn27y1gu2o) by a [trust task protocol](#h.uo2gx58kwj2o) at [Layer 3](#h.7rbvlbpp8vwp) of the [ToIP stack](#h.wms58fgdch9m).
+
+        For more information, see [Section 7.4](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2374-layer-3-trust-tasks&sa=D&source=editors&ust=1718703186872857&usg=AOvVaw1BZ0EhYn8xwMCrnfA79bxG) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust task layer](#h.9cwbkpb6ziep)
+
+    -   ### ToIP
+
+        In the context of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186873319&usg=AOvVaw2VFpNJ2ILRklH-8H6HAxnO), the [trust task](#h.vzu8kc1yz84q) layer is [ToIP Layer 3](#h.7rbvlbpp8vwp). It supports [trust applications](#h.3pfn27y1gu2o) operating at [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust task protocol](#h.uo2gx58kwj2o)
+
+    -   ### ToIP
+
+        A [ToIP Layer 3](#h.7rbvlbpp8vwp) protocol that implements a specific [trust task](#h.vzu8kc1yz84q) on behalf of a [ToIP Layer 4](#h.ym4v87xpn7gq) [trust application](#h.3pfn27y1gu2o).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust triangle](#h.n29niebkxky7)
+
+    -   ### ToIP
+
+        See: [three-party model](#h.2afq075qllho).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trusted execution environment](#h.rsly6bxjqeg5)
+
+    -   ### ToIP
+
+        A trusted execution environment (TEE) is a secure area of a main processor. It helps code and data loaded inside it to be protected with respect to [confidentiality](#h.445sv27j3c2m) and [integrity](#h.n34avr5qvr0j). Data [integrity](#h.n34avr5qvr0j) prevents [unauthorized](#h.576ssfpt348i) [entities](#h.5imtbzl1f4xo) from outside the TEE from altering [data](#h.o783ayrrkc6g), while code integrity prevents code in the TEE from being replaced or modified by [unauthorized](#h.576ssfpt348i) [entities](#h.5imtbzl1f4xo), which may also be the computer [owner](#h.y450rpi0zmuu) itself as in certain [DRM](#h.m9um65bhu37) schemes.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Trusted_execution_environment&sa=D&source=editors&ust=1718703186874943&usg=AOvVaw11hnfqI2Ke3l2R26XibNoq).
+
+        Also known as: [TEE](#h.4y1nwu52qx7g).
+
+        See also: [Secure Enclave](#h.lf0txjgjs67z).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # trusted execution environment
+
+        ###### Definition
+
+        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).
+
+        ##### Examples
+
+        SGX, TrustZone, an HSM, a TPM, or other similarly protected hardware/software/firmware environment
+
+        [Learn more](https://kerisse.org)
+
+-   ## [trusted platform module](#trusted-platform-module)
+
+    -   ### WebOfTrust
+
+        # trusted platform module
+
+        ###### Definition
+
+        A device that enhances the security and privacy (of identity systems) by providing hardware-based cryptographic functions.
+
+        ###### 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.
+
+        ###### Form
+
+        A TPM can be implemented as a physical chip, a firmware module, or a virtual device.
+
+        Source: Bing chat sept 2023
+
+        [Learn more](https://kerisse.org)
+
+-   ## [trusted role](#h.btjt878m4fqi)
+
+    -   ### ToIP
+
+        A [role](https://www.google.com/url?q=http://role&sa=D&source=editors&ust=1718703186875423&usg=AOvVaw0eVbleRrk7b_Lue5xoW0Ju) that performs restricted activities for an [organization](#h.z27mp1358pi9) after meeting competence, security and background [verification](#h.2bnb6g8na7cu) [requirements](#h.ajxlw8r3dvcc) for that [role](#h.sf54cyuamo6x).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trusted third party](#h.gzkj2oe82fof)
+
+    -   ### ToIP
+
+        In [cryptography](#h.jhvr6rbo5z3q), a trusted [third party](#h.zu2vj8151tr) (TTP) is an entity which facilitates interactions between two [parties](#h.cn6bno48fomj) who both trust the third party; the third party reviews all critical transaction communications between the parties, based on the ease of creating fraudulent digital content. In TTP models, the [relying parties](#h.61sr3qnr1eci) use this trust to secure their own interactions. TTPs are common in any number of commercial transactions and in cryptographic digital transactions as well as cryptographic protocols, for example, a [certificate authority](#h.dm6pt5kg2uim) (CA) would issue a [digital certificate](#h.vpsiiv68xxwc) to one of the two parties in the next example. The CA then becomes the TTP to that certificate's issuance. Likewise transactions that need a third party recordation would also need a third-party repository service of some kind.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Trusted_third_party&sa=D&source=editors&ust=1718703186876246&usg=AOvVaw2M5cZs6ZnaxfZVghYOcSiW).
+
+        Also known as: [TTP](#h.v0r7skqmr47v).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/trusted_third_party&sa=D&source=editors&ust=1718703186876602&usg=AOvVaw0_KAyVYHnDRuPPpLItufzn): A third party, such as a CA, that is trusted by its clients to perform certain services. (By contrast, the two participants in a key-establishment transaction are considered to be the first and second parties.)
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trusted timestamp authority](#h.ryrs51vhrwny)
+
+    -   ### ToIP
+
+        An [authority](#h.gln5i78kxlfh) that is trusted to provide accurate time information in the form of a [timestamp](#h.7l3etghzasqf).
+
+        Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/trusted_timestamp_authority&sa=D&source=editors&ust=1718703186877017&usg=AOvVaw1CMKnpTMTMmhLO6YEBeyh0).
+
+        Also known as: [TTA](#h.xeindhl0hc8h).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trustworthiness](#h.tnso3xyimmee)
+
+    -   ### ToIP
+
+        An [attribute](#h.ky5nh3yri7ak) of a [person](#h.yx4qb6dcjdvj) or [organization](#h.z27mp1358pi9) that provides confidence to others of the qualifications, capabilities, and reliability of that [entity](#h.5imtbzl1f4xo) to perform specific tasks and fulfill assigned responsibilities. Trustworthiness is also a characteristic of information technology products and systems. The attribute of trustworthiness, whether applied to people, processes, or technologies, can be measured, at least in relative terms if not quantitatively. The determination of trustworthiness plays a key role in establishing [trust relationships](#h.pu2asd79bqzo) among [persons](#h.yx4qb6dcjdvj) and [organizations](#h.z27mp1358pi9). The [trust relationships](#h.pu2asd79bqzo) are key factors in [risk decisions](#h.9g76xvrtlnqp) made by senior leaders/executives.
+
+        Source: [NIST Special Publication 800-39](https://www.google.com/url?q=https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf&sa=D&source=editors&ust=1718703186878275&usg=AOvVaw1xs6G6xptG_tG4jD8ZWJwu) p.24
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trustworthy](#h.uegl82s0wyj8)
+
+    -   ### ToIP
+
+        A [property](#h.c8vs1xa4uwn) of an [entity](#h.5imtbzl1f4xo) that has the [attribute](#h.ky5nh3yri7ak) of [trustworthiness](#h.tnso3xyimmee).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [trust application](#h.3pfn27y1gu2o)
+
+    -   ### ToIP
+
+        An application that runs at [ToIP Layer 4](#h.ym4v87xpn7gq) in order to perform [trust tasks](#h.vzu8kc1yz84q) or engage in other [verifiable messaging](#h.7zrsx7mki2fr) using the [ToIP stack](#h.wms58fgdch9m).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [ts node](#ts-node)
+
+    -   ### WebOfTrust
+
+        # ts node
+
+        ###### Definition
+
+        npm package that lets you run typescript from a shell
+
+        [Learn more](https://kerisse.org)
+
+-   ## [unicast](#h.bqegn99wxkdi)
+
+    -   ### ToIP
+
+        In computer networking, unicast is a one-to-one transmission from one point in the network to another point; that is, one sender and one receiver, each identified by a [network address](#h.v9gosdu5b7z5) (a [unicast address](#h.2p49ftuui3ug)). Unicast is in contrast to [multicast](#h.nopxfdr8qtr6) and [broadcast](#h.s1uti8f9ufsv) which are one-to-many transmissions. [Internet Protocol](#h.jmao5ngtvqnm) unicast delivery methods such as [Transmission Control Protocol](#h.4wb0yz8sizvi) (TCP) and [User Datagram Protocol](#h.di36optpv6sl) (UDP) are typically used.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Unicast&sa=D&source=editors&ust=1718703186879667&usg=AOvVaw1gW3_34PbJ1RGSQJATfysZ).
+
+        See also: [anycast](#h.adr8osyk2zcx).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [unicast address](#h.2p49ftuui3ug)
+
+    -   ### ToIP
+
+        A [network address](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.v9gosdu5b7z5&sa=D&source=editors&ust=1718703186880080&usg=AOvVaw13IOrY9iVIkwDpIJzxS23P) used for a [unicast](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.bqegn99wxkdi&sa=D&source=editors&ust=1718703186880320&usg=AOvVaw2d3AeF7SGUm0C9ydYMvPMg).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [uniform resource locator](#uniform-resource-locator)
+
+    -   ### WebOfTrust
+
+        # uniform resource locator
+
+        ###### Definition
+
+        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.
+
+        ###### Broader context
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [univalent](#univalent)
+
+    -   ### WebOfTrust
+
+        # univalent
+
+        ###### Definition
+
+        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
+
+        ###### Universal Identity Theory specific
+
+        (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.
+
+        ![univalent-key-management-infrastructure](https://github.com/weboftrust/WOT-terms/static/img/univalent-key-management-infrastructure.png)
+
+        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.
+
+        ###### Also see
+
+        [Multivalent](https://weboftrust.github.io/keridoc/docs/glossary/multi-valent.md)[Bivalent](https://weboftrust.github.io/keridoc/docs/glossary/bivalent.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [unsolicited issuance](#unsolicited-issuance)
+
+    -   ### WebOfTrust
+
+        # unsolicited issuance
+
+        ###### Definition
+
+        Issuance of a Legal Entity vLEI Credential upon notice by a [QAR](https://weboftrust.github.io/keridoc/docs/glossary/QAR.md) to the [AVR](https://weboftrust.github.io/keridoc/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/keridoc/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.
+
+        ###### Related
+
+        See [Solicited issuance](https://weboftrust.github.io/keridoc/docs/glossary/solicited-issuance.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [user agent](#h.jb61co23rlut)
+
+    -   ### ToIP
+
+        A [software agent](#h.qv9e403ohhxe) that is used directly by the end-user as the [principal](#h.sydbe7rk6244). Browsers, email clients, and [digital wallets](#h.sxnvf3f5v156) are all examples of user agents.
+
+        Supporting definitions:
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User_agent&sa=D&source=editors&ust=1718703186880838&usg=AOvVaw0uNCIwfDgbiZzQAwt6opKv): On the [Web](https://www.google.com/url?q=https://en.wikipedia.org/wiki/World_Wide_Web&sa=D&source=editors&ust=1718703186881026&usg=AOvVaw2hQbjA12rIZ_7CMDLPmUNk), a user agent is a [software agent](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Software_agent&sa=D&source=editors&ust=1718703186881252&usg=AOvVaw1afT_WcB8GU36-ZrNHIcfv) capable of and responsible for retrieving and facilitating [end user](https://www.google.com/url?q=https://en.wikipedia.org/wiki/End_user&sa=D&source=editors&ust=1718703186881439&usg=AOvVaw3Sfas8dCU4__5OkNgmxsdz) interaction with Web content.[\[1\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User_agent%23cite_note-1&sa=D&source=editors&ust=1718703186881622&usg=AOvVaw3wDff_o701U63NMiK0lx-9) This includes all common [web browsers](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Web_browser&sa=D&source=editors&ust=1718703186881775&usg=AOvVaw29DVPm7q2h0clzIu9Tcby2), such as [Google Chrome](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Google_Chrome&sa=D&source=editors&ust=1718703186881954&usg=AOvVaw1nAe56OCiamvjvzl_Dlkfq), [Mozilla Firefox](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mozilla_Firefox&sa=D&source=editors&ust=1718703186882142&usg=AOvVaw0dw0cODKFd9S2cJAuYUREa), and [Safari](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Safari_\(web_browser\)&sa=D&source=editors&ust=1718703186882339&usg=AOvVaw14uHb6Kvs248Iv3LsgK1cX), some [email clients](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Email_client&sa=D&source=editors&ust=1718703186882488&usg=AOvVaw2UzPxzSiemSYkiKlvxmMIr), standalone [download managers](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Download_manager&sa=D&source=editors&ust=1718703186882624&usg=AOvVaw1V5fENuaKMPip2U-Qa_kAI) like [youtube-dl](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Youtube-dl&sa=D&source=editors&ust=1718703186882762&usg=AOvVaw1dYGy0YHPxhcq_9CUCoz7i), other [command-line](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Command-line&sa=D&source=editors&ust=1718703186882966&usg=AOvVaw2ozTLryzvAvt8TvTNbcD_m) utilities like [cURL](https://www.google.com/url?q=https://en.wikipedia.org/wiki/CURL&sa=D&source=editors&ust=1718703186883167&usg=AOvVaw2X7NCoCCa3fV_05AYEd1cV), and arguably [headless](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Headless_software&sa=D&source=editors&ust=1718703186883376&usg=AOvVaw3nYeCW52FqlsdlGAoGglwT) [services](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Service_\(systems_architecture\)&sa=D&source=editors&ust=1718703186883569&usg=AOvVaw1ycBlYyxTG8dk4LUal69Rr) that power part of a larger application, such as a [web crawler](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Web_crawler&sa=D&source=editors&ust=1718703186883709&usg=AOvVaw3KYwsBW7XramXPoGABbc5W).
+
+        The user agent plays the role of the [client](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Client_\(computing\)&sa=D&source=editors&ust=1718703186883938&usg=AOvVaw3W-es0kUNu-dfkHTdDRypC) in a [client–server system](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Client%25E2%2580%2593server_model&sa=D&source=editors&ust=1718703186884141&usg=AOvVaw2NWimbWNLAbw6qiiEgDP2w). The [HTTP](https://www.google.com/url?q=https://en.wikipedia.org/wiki/HTTP&sa=D&source=editors&ust=1718703186884346&usg=AOvVaw28eTdcVpdI1prdCCx_ae1m) [User-Agent header](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User-Agent_header&sa=D&source=editors&ust=1718703186884549&usg=AOvVaw1L_F3f8QNHsLL4nzB7CHvx) is intended to clearly identify the agent to the server. However, this header can be omitted or [spoofed](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User_agent_spoofing&sa=D&source=editors&ust=1718703186884741&usg=AOvVaw3JBY567x8Gg1Jzt53gCS_n), so some websites use [other agent detection methods](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Browser_sniffing&sa=D&source=editors&ust=1718703186884928&usg=AOvVaw0uAKVEpCqe3f1UZrR6hmup).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [user interface](#user-interface)
+
+    -   ### WebOfTrust
+
+        # user interface
+
+        ###### Definition
+
+        A user interface (UI or U/I) is the space where interactions between humans and machines occur.
+
+        ###### More on Wikipedia
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [utility governance framework](#h.n08ql59sgrtn)
+
+    -   ### ToIP
+
+        A [governance framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2x05z0r097mn&sa=D&source=editors&ust=1718703186886280&usg=AOvVaw1VdNcukdDikwBGz49HC7YX) for a [digital trust utility](#h.ou8opzfswu3c). A utility governance framework may be a component of or referenced by an [ecosystem governance framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.dkge5gglsmk3&sa=D&source=editors&ust=1718703186886518&usg=AOvVaw166evFLOs04YX3b8H5e8m1) or a [credential governance framework](#h.tlmucrcg1d6g).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [vLEI](#vLEI)
+
+    -   ### WebOfTrust
+
+        # vLEI
+
+        ###### See
+
+        [Verifiable legal entity identifier](https://weboftrust.github.io/keridoc/docs/glossary/verifiable-legal-entity-identifier.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [validate](#validate)
+
+    -   ### WebOfTrust
+
+        # validate
+
+        ###### See
+
+        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/keridoc/docs/glossary/verify.md)
+
+        In contrast, [validator](https://weboftrust.github.io/keridoc/docs/glossary/validator.md) and [verifier](https://weboftrust.github.io/keridoc/docs/glossary/verifier.md) have been clearly outlined in the WebofTrust vocabulary.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [validation](#h.rbp41an0omv6)
+
+    -   ### ToIP
+
+        An [action](#h.l54nzmooy631) an [agent](#h.6xkhfkjpo6xg) (of a [principal](#h.sydbe7rk6244)) performs to determine whether a digital object or set of [data](#h.o783ayrrkc6g) meets the [requirements](#h.ajxlw8r3dvcc) of a specific [party](#h.cn6bno48fomj).
+
+        See also: [verification](#h.2bnb6g8na7cu).
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23validate&sa=D&source=editors&ust=1718703186887405&usg=AOvVaw2MQCrM0n4yPW9voLhIvjkA): The act, by or on behalf of a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186887571&usg=AOvVaw3pZLMjtT9abLXyRFxP67Av), of determining whether or not that data is valid to be used for some specific purpose(s) of that [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186887775&usg=AOvVaw1ThMFpbnZbFSeJM65Z3XPK).
+
+        [NIST:](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/validation&sa=D&source=editors&ust=1718703186887983&usg=AOvVaw1G5jbinLyqRJax-6HW7DZZ) Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [validator](#validator)
+
+    -   ### WebOfTrust
+
+        # validator
+
+        ###### Definition
+
+        determines current authoritative key set for 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/keridoc/docs/glossary/verifier.md) are close to synonyms for our purposes.
+
+        A `validator` in [KERI](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-infrastructure.md) and [ACDC](https://weboftrust.github.io/keridoc/docs/glossary/authentic-chained-data-container.md) is anybody that wants to establish control-authority over an identifier, created by the controller of the identifier. Validators verify the log, they apply duplicity detection or they leverage somebody else's duplicity detection or apply any other logic so they can say "Yes, these are events I can trust".
+
+        ###### Example
+
+        During validation of virtual credentials for example, a [verifier](https://weboftrust.github.io/keridoc/docs/glossary/verifier.md) checks to see if a verifiable [credential](https://weboftrust.github.io/keridoc/docs/glossary/credential.md) ([VC](https://weboftrust.github.io/keridoc/docs/glossary/VC.md)) has been signed by the controller of this VC using the applicable verification method.
+
+        ###### To be Sam-Smith precise in KERI
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [vault](#h.907j5xhvqo3u)
+
+    -   ### ToIP
+
+        See: [digital vault](#h.cz29glapo2tg).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [vcp](#vcp)
+
+    -   ### WebOfTrust
+
+        # vcp
+
+        ###### Definition
+
+        vcp = vdr incept, verifiable data registry inception
+
+        [Learn more](https://kerisse.org)
+
+-   ## [vdr](#vdr)
+
+    -   ### WebOfTrust
+
+        # vdr
+
+        ###### See
+
+        [Verifiable data registry](https://weboftrust.github.io/keridoc/docs/glossary/verifiable-data-registry.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [veracity](#veracity)
+
+    -   ### WebOfTrust
+
+        # veracity
+
+        ###### Definition
+
+        The quality of being true; contrast [authenticity](https://weboftrust.github.io/keridoc/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_).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verfer](#verfer)
+
+    -   ### WebOfTrust
+
+        # verfer
+
+        ###### Definition
+
+        A primitive that represents a public key. It has the ability to [verify](https://weboftrust.github.io/keridoc/docs/glossary/verify.md) signatures on data.
+        [Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifiability (of a digital object, claim, or assertion)](#h.v9dou4wg2h9d)
+
+    -   ### ToIP
+
+        The [property](#h.c8vs1xa4uwn) of a digital object, assertion, [claim](#h.akieli6njkk5), or [communication](#h.w02a6srdng3j), being [verifiable](#h.k2qmzn3tjzsl).
+
+        See also:  [appraisability](#h.wtzlm8ocwx7a).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [verifiable](#h.k2qmzn3tjzsl)
+
+    -   ### ToIP
+
+        In the context of digital [communications](#h.w02a6srdng3j) infrastructure, the ability to determine the [authenticity](#h.pitlm5jn3v6u) of a [communication](#h.w02a6srdng3j) (e.g., sender, contents, [claims](#h.akieli6njkk5), [metadata](#h.t63bf0ssndfd), provenance), or the underlying [sociotechnical](#h.wjui8ufitkkx) infrastructure (e.g., [governance](#h.2x05z0r097mn), [roles](#h.sf54cyuamo6x), [policies](#h.udts41hso4w4), [authorizations](#h.576ssfpt348i), [certifications](#h.ytzysnyu57ec)).
+
+        See also: [appraisability (of a communications end-point)](#h.wtzlm8ocwx7a); [digital signature](#h.s93np0i5rcne).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # verifiable
+
+        ###### Definition
+
+        able to cryptographically verify a certain data structure on its [consistency](https://weboftrust.github.io/keridoc/docs/glossary/inconsistency.md) and its [authenticity](https://weboftrust.github.io/keridoc/docs/glossary/authenticity.md)
+
+        ###### KERI related
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifiable credential](#h.co5algna3zkh)
+
+    -   ### ToIP
+
+        A standard data model and representation format for [cryptographically-verifiable](#h.422iwwfur12) [digital credentials](#h.ddna9lucn4k6) as defined by the [W3C Verifiable Credentials Data Model specification](#h.mitd3elf05tf).
+
+        Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186889932&usg=AOvVaw0gHUoDqAMMiCoCAwbCZfJV)
+
+        See also: [digital credential](#h.ddna9lucn4k6).
+
+        Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186890311&usg=AOvVaw25djW09DwroeV0JBgb0RY1)
+
+        Supporting definitions:
+
+        [W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186890629&usg=AOvVaw3Gg9njWUHBD3NDC3v91csY): A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build [verifiable presentations](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-presentations&sa=D&source=editors&ust=1718703186890821&usg=AOvVaw3C_1dYcyfPRUj6fqfMJdyN), which can also be cryptographically verified. The [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186890977&usg=AOvVaw04cJR9Co5od7ii8CwJIqN8) in a credential can be about different [subjects](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-subjects&sa=D&source=editors&ust=1718703186891144&usg=AOvVaw208udn9WqLk1kDfqcI1vy1).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### W3C (DID)
+
+        A standard data model and representation format for cryptographically-verifiabledigital credentials as defined by the W3C Verifiable Credentials specification\[VC-DATA-MODEL\].
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+    -   ### WebOfTrust
+
+        # verifiable credential
+
+        ###### Definition
+
+        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.
+
+        ##### The ToIP definition
+
+        [here](https://github.com/trustoverip/toip/wiki/verifiable-credential)
+
+        ###### More on source Wikipedia
+
+        [VCs](https://en.wikipedia.org/wiki/Verifiable_credentials)
+
+        ###### W3C DID standardization
+
+        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/)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifiable data](#h.7n80iyjxkofu)
+
+    -   ### ToIP
+
+        Any digital [data](#h.o783ayrrkc6g) or object that is [digitally signed](#h.s93np0i5rcne) in such a manner that it can be [cryptographically verified](#h.422iwwfur12).
+
+        Note: In the context of ToIP architecture, verifiable data is signed with the [cryptographic keys](#h.53rzpn1yn6q7) associated with the [ToIP identifier](#h.xtyidw4bnytz) of the data [controller](#h.gemoqe2m303z).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [verifiable data registry](#h.q1dr1v2lltfe)
+
+    -   ### ToIP
+
+        A [registry](#h.farjhbxfa3lh) that facilitates the creation, [verification](#h.2bnb6g8na7cu), updating, and/or deactivation of [decentralized identifiers](#h.x1jp59hgbk2l) and [DID documents](#h.yjwocacp570p). A verifiable data registry may also be used for other [cryptographically-verifiable](#h.422iwwfur12) data structures such as [verifiable credentials](#h.co5algna3zkh).
+
+        Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186892259&usg=AOvVaw37-SgicwdzMu11510XCGRw)
+
+        Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186892559&usg=AOvVaw1eoubEprJas4Ki3xXqizsb)
+
+        See also: [authoritative source](#h.9tt1qpgdfnxs), [trust registry](#h.5kzln6m5e8j5), [system of record](#h.ceh3cl4l0xnp).
+
+        For more information, see: the W3C Verifiable Credentials specification \[[VC-DATA-MODEL](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23bib-vc-data-model&sa=D&source=editors&ust=1718703186893012&usg=AOvVaw3nrsy8udZFRpYUa3mWVZeN)\].
+
+        Note: There is an [earlier definition in the W3C VC 1.1. glossary](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186893264&usg=AOvVaw3za3qdlw9ok1JAwwD5HLvD) that is not as mature (it is not clear about the use of cryptographically verifiable data structures). We do not recommend that definition.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### W3C (DID)
+
+        A system that facilitates the creation, verification, updating, and/ordeactivation of decentralized identifiers and DID documents. Averifiable data registry might also be used for othercryptographically-verifiable data structures such as verifiablecredentials. For more information, see the W3C Verifiable Credentialsspecification \[VC-DATA-MODEL\].
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+    -   ### WebOfTrust
+
+        # verifiable data registry
+
+        ###### Definition
+
+        a [Verifiable Data Structure](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/digest.md)) to those statements (via a Merkle tree or hash chained data structure).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifiable data structure](#verifiable-data-structure)
+
+    -   ### WebOfTrust
+
+        # verifiable data structure
+
+        ###### Definition
+
+        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](https://weboftrust.github.io/keridoc/docs/glossary.md#Sources-Definition-ChatGPT)
+
+        ###### Related to KERI
+
+        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.
+
+        * * *
+
+        ###### Sources Definition ChatGPT
+
+        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).
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifiable identifier](#h.wyda231qefe)
+
+    -   ### ToIP
+
+        An [identifier](#h.u3bfehmj4ed3) over which the [controller](#h.gemoqe2m303z) can provide cryptographic [proof of control](#h.3ss2tnb5pf4s).
+
+        See also: [decentralized identifier](#h.x1jp59hgbk2l), [autonomous identifier](#h.bz098kwwc559).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # verifiable identifier
+
+        ###### Definition
+
+        Cryptographically verifiable authentic decentralized identifier (verfiable [DID](https://weboftrust.github.io/keridoc/docs/glossary/DID.md))
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifiable legal entity identifier](#verifiable-legal-entity-identifier)
+
+    -   ### WebOfTrust
+
+        # verifiable legal entity identifier
+
+        ###### Definition
+
+        vLEIs are digital verifiable credentials issued by (delegates) of GLEIF to prove that information about a legel entity is verifiably authentic.
+
+        | TBW | prio1 : check definition |
+
+        ##### Explanation
+
+        The v in vLEI stands for “verifiable”, but what does that mean? The term verifiable in this case comes from the term “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.
+
+        ##### More information
+
+        [Here](https://rapidlei.com/what-is-vlei/) at Rapidlei.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifiable message](#h.7zrsx7mki2fr)
+
+    -   ### ToIP
+
+        A [message](#h.bge7ubygwk2q) communicated as [verifiable data](#h.7n80iyjxkofu).
+
+        See also: [ToIP messages](#h.5th2gmjr7ij) 
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [verifiable timestamp](#verifiabletimestamp)
+
+    -   ### W3C (DID)
+
+        A verifiable timestamp enables a third-party to verify that a data objectexisted at a specific moment in time and that it has not been modified orcorrupted since that moment in time.If the data integrity could reasonably havebeen modified or corrupted since that moment in time, the timestamp is notverifiable.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [verification](#h.2bnb6g8na7cu)
+
+    -   ### ToIP
+
+        An [action](#h.l54nzmooy631) an [agent](#h.6xkhfkjpo6xg) (of a [principal](#h.sydbe7rk6244)) performs to determine the [authenticity](#h.pitlm5jn3v6u) of a [claim](#h.akieli6njkk5) or other digital object using a [cryptographic key](#h.53rzpn1yn6q7).
+
+        See also: [validation](#h.rbp41an0omv6).
+
+        Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186895260&usg=AOvVaw3dblWGu-RF-_Xip41iQNBQ)
+
+        Supporting definitions:
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23verify&sa=D&source=editors&ust=1718703186895660&usg=AOvVaw3Pzl9624fkDXgrOQimeIwc): The act, by or on behalf of a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186895820&usg=AOvVaw096L_7J8dc0HUcLXKpTTHd), of determining whether that data is authentic (i.e. originates from the [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186895969&usg=AOvVaw0lAy_Qg2iwxGvCsxaUVt5T) that authored it), timely (i.e. has not expired), and conforms to other specifications that apply to its structure.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # verification
+
+        ###### Definition
+
+        An action an [agent](https://weboftrust.github.io/keridoc/docs/glossary/agent.md) (of a principal) performs to determine the [authenticity](https://weboftrust.github.io/keridoc/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)
+
+        ###### See also
+
+        [verify](https://weboftrust.github.io/keridoc/docs/glossary/verify.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verification method](#verificationmethod)
+
+    -   ### W3C (DID)
+
+        A set of parameters that can be used together with a process to independentlyverify a proof. For example, a cryptographic public key can be used as averification method with respect to a digital signature; in such usage, itverifies that the signer possessed the associated cryptographic private key. "Verification" and "proof" in this definition are intended to apply broadly. Forexample, a cryptographic public key might be used during Diffie-Hellman keyexchange to negotiate a shared symmetric key for encryption. This guarantees theintegrity of the key agreement process. It is thus another type of verificationmethod, even though descriptions of the process might not use the words"verification" or "proof."
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [verification relationship](#verificationrelationship)
+
+    -   ### W3C (DID)
+
+        An expression of the relationship between the DID subject and averification method. An example of a verification relationship is5.3.1 Authentication.
+
+        [Learn more](https://www.w3.org/TR/did-core)
+
+-   ## [verified integrity](#verified-integrity)
+
+    -   ### WebOfTrust
+
+        # verified integrity
+
+        ###### Definition
+
+        A mechanism that can unambiguously assess whether the information is/continues to be whole, sound and unimpaired
+
+        ###### KERI suite related
+
+        -   In KERI's secure attribution focus integrity is verified by [internal consistency](https://weboftrust.github.io/keridoc/docs/glossary/internal-inconsistency.md) of [KE(R)L](https://weboftrust.github.io/keridoc/docs/glossary/key-event-receipt-log.md) and [TEL](https://weboftrust.github.io/keridoc/docs/glossary/transaction-event-log.md) plus [duplicity](https://weboftrust.github.io/keridoc/docs/glossary/duplicity.md) detection.
+        -   In ACDC the [self addressing identifier](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/composability.md).
+
+        ###### See also
+
+        [integrity](https://weboftrust.github.io/keridoc/docs/glossary/integrity.md)
+        [(complementary) integrity verification](https://weboftrust.github.io/keridoc/docs/glossary/complementary-integrity-verification.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifier](#verifier)
+
+    -   ### Nist
+
+        An entity that verifies the claimants identity by verifying the claimants possession and control of a token using an authentication protocol. To do this, the Verifier may also need to validate credentials that link the token and identity and check their status.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/verifier)
+
+    -   ### ToIP (DID:Webs)
+
+        An entity or component that cryptographically verifies the signature(s) on an event message. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # verifier
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/validator.md) and verifier.
+
+        ###### KERI related
+
+        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)
+
+        ###### ESSIF-lab definitions
+
+        -   _[verify](https://essif-lab.github.io/framework/docs/essifLab-glossary#verify)_ definition is in sync with the definition in the KERI/ACDC vocabulary
+        -   _[verifier](https://essif-lab.github.io/framework/docs/essifLab-glossary#verifier)_ definition is in sync with the definition in the KERI/ACDC vocabulary
+        -   _[validate](https://essif-lab.github.io/framework/docs/essifLab-glossary#validate)_ definition is very general, however in the KERI/ACDC vocabulary 'validate' currently has diverse meanings including this one
+        -   _[validator](https://essif-lab.github.io/framework/docs/essifLab-glossary#validator)_ definition is a generalisation of the much more specific definition in the KERI/ACDC vocabulary
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verifier (of a claim or credential)](#h.xfewd7t01hu0)
+
+    -   ### ToIP
+
+        A [role](#h.sf54cyuamo6x) an [agent](#h.6xkhfkjpo6xg) performs to perform [verification](#h.2bnb6g8na7cu) of one or more [proofs](#h.r2qw6757lopw) of the [claims](#h.akieli6njkk5) in a [digital credential](#h.ddna9lucn4k6).
+
+        See also: [relying party](#h.61sr3qnr1eci); [issuer](#h.xyrplzbvtffq), [holder](#h.64mptmm24w7u).
+
+        Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186896852&usg=AOvVaw3ie9r_SPYWvX_tZbKKpf0Z)
+
+        Supporting definitions:
+
+        [W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186897262&usg=AOvVaw2UhFrxaWWtu7MitO1jhtXZ): A role an [entity](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-entities&sa=D&source=editors&ust=1718703186897490&usg=AOvVaw3XAB0NklqH3s5GVK7CUDff) performs by receiving one or more [verifiable credentials](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186897705&usg=AOvVaw2X9Ge-WXRVee-8bRWOa4TV), optionally inside a [verifiable presentation](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-presentations&sa=D&source=editors&ust=1718703186897932&usg=AOvVaw0VpqwC-jAo7BqkqUEXbHSO) for processing. Other specifications might refer to this concept as a [relying party](#h.61sr3qnr1eci).
+
+        [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23verifier&sa=D&source=editors&ust=1718703186898364&usg=AOvVaw11fmOJ_Op-0h_8liBERMnW): a component that implements the [capability](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/capability&sa=D&source=editors&ust=1718703186898604&usg=AOvVaw1nviRRLhq2EOtulDHcWuEq) to request [peer agents](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/peer-agent&sa=D&source=editors&ust=1718703186898825&usg=AOvVaw1i_kbndpQnJCRIAqRcH9cD) to present (provide) data from credentials (of a specified kind, issued by specified [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186898994&usg=AOvVaw1GHulzONww2lHfFuTheBID)), and to verify such responses (check structure, signatures, dates), according to its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186899154&usg=AOvVaw2BUSgJW77W904G60g7K10_)'s [verifier policy](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/verifier-policy&sa=D&source=editors&ust=1718703186899384&usg=AOvVaw2Z0AR7HxcG1ykKV2f4m-U-).
+
+        [NIST:](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/verifier&sa=D&source=editors&ust=1718703186899614&usg=AOvVaw1HjEAyddvM4C-hF_Ti9akM) The entity that verifies the authenticity of a digital signature using the public key.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [verify](#verify)
+
+    -   ### WebOfTrust
+
+        # verify
+
+        ###### Definition
+
+        The act, by or on behalf of a [party](https://weboftrust.github.io/keridoc/docs/glossary/party.md), of determining whether that data is [authentic](https://weboftrust.github.io/keridoc/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
+
+        ###### See also
+
+        [Verification](https://weboftrust.github.io/keridoc/docs/glossary/verification.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [verify signature](#verify-signature)
+
+    -   ### WebOfTrust
+
+        # verify signature
+
+        ###### Definition
+
+        Applying an algorithm that, given the message, public key and signature, either accepts or rejects the message's claim to authenticity.
+
+        ![Private key signing](https://hackmd.io/_uploads/Bk5GHfhT9.png)
+
+        ###### Related ESSIF-lab definitions
+
+        -   _[verify](https://essif-lab.github.io/framework/docs/essifLab-glossary#verify)_ definition is in sync with the definition in the KERI/ACDC vocabulary
+        -   _[verifier](https://essif-lab.github.io/framework/docs/essifLab-glossary#verifier)_ definition is in sync with the definition in the KERI/ACDC vocabulary
+        -   _[validate](https://essif-lab.github.io/framework/docs/essifLab-glossary#validate)_ definition is very general, however in the KERI/ACDC vocabulary 'validate' currently has diverse meanings including this one
+        -   _[validator](https://essif-lab.github.io/framework/docs/essifLab-glossary#validator)_ definition is a generalisation of the much more specific definition in the KERI/ACDC vocabulary
+
+        [Learn more](https://kerisse.org)
+
+-   ## [version](#version)
+
+    -   ### WebOfTrust
+
+        # version
+
+        ###### Definiton
+
+        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)
+
+        ###### KERI related
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [version code](#version-code)
+
+    -   ### WebOfTrust
+
+        # version code
+
+        ###### Definition
+
+        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.
+
+        ###### Compare
+
+        [Version string](https://weboftrust.github.io/keridoc/docs/glossary/version-string.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [version string](#version-string)
+
+    -   ### WebOfTrust
+
+        # version string
+
+        ###### Definition
+
+        The Version String in JSON, CBOR and MGPK is a workaround to make those self-framing.
+
+        ###### Compare
+
+        [Version code](https://weboftrust.github.io/keridoc/docs/glossary/version-code.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [virtual credential transaction event log](#virtual-credential-transaction-event-log)
+
+    -   ### WebOfTrust
+
+        # virtual credential transaction event log
+
+        ###### Definition
+
+        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)_.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [virtual vault](#h.7dcabufiu2bo)
+
+    -   ### ToIP
+
+        A [digital](#h.cz29glapo2tg) [vault](#h.cz29glapo2tg) enclosed inside another [digital vault](#h.cz29glapo2tg) by virtue of having its own [verifiable identifier](#h.wyda231qefe) (VID) and its own set of [encryption](#h.iyq318f2vg61) [keys](#h.bk8tq6m7ylyl) that are separate from those used to unlock the enclosing vault.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [vlei credential](#vlei-credential)
+
+    -   ### WebOfTrust
+
+        # vlei credential
+
+        ###### Definition
+
+        Credential concerning a verifiable Legal Entity Identifier, residing in the [GLEIS](https://weboftrust.github.io/keridoc/docs/glossary/GLEIS.md) and compliant with one or more of the GLEIF [Governance Framework](https://weboftrust.github.io/keridoc/docs/glossary/governance-framework.md)s
+
+        [Learn more](https://kerisse.org)
+
+-   ## [vlei ecosystem governance framework](#vlei-ecosystem-governance-framework)
+
+    -   ### WebOfTrust
+
+        # vlei ecosystem governance framework
+
+        ###### Definition
+
+        The Verifiable LEI (vLEI) Ecosystem [Governance Framework](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [vlei role credential](#vlei-role-credential)
+
+    -   ### WebOfTrust
+
+        # vlei role credential
+
+        ###### Definition
+
+        A [vLEI credential](https://weboftrust.github.io/keridoc/docs/glossary/vlei-credential.md) that attests a role.
+
+        | TBW prio 3 |
+
+        [Learn more](https://kerisse.org)
+
+-   ## [vrt](#vrt)
+
+    -   ### WebOfTrust
+
+        # vrt
+
+        ###### Definition
+
+        vrt = vdr rotate, verifiable data registry rotation
+
+        [Learn more](https://kerisse.org)
+
+-   ## [wallet](#h.mh27630t20d)
+
+    -   ### ToIP
+
+        See: [digital wallet](#h.sxnvf3f5v156).
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### WebOfTrust
+
+        # wallet
+
+        ###### Definition
+
+        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)
+
+        ###### KERI and ACDC context
+
+        A wallet is a collection of data stores; made up of a [keystore](https://weboftrust.github.io/keridoc/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/keridoc/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/keridoc/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/).
+
+        ###### Functions
+
+        In addition to this basic function of **storing the keys**, it's also used to storing [verifiable credentials (VCs)](https://weboftrust.github.io/keridoc/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)
+
+        ###### KERI and ACDC related
+
+        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/keridoc/docs/glossary/verifiable-credential.md).\\
+        KERI explicitly distinguishes [keystore](https://weboftrust.github.io/keridoc/docs/glossary/keystore.md) and [wallet](https://weboftrust.github.io/keridoc/docs/glossary/wallet.md); the latter being a superset of the former. [Keep](https://weboftrust.github.io/keridoc/docs/glossary/keep.md) is KERI's and ACDC's user interface with Keripy agent API as a back end.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [wallet engine](#h.jsmi4264di2s)
+
+    -   ### ToIP
+
+        The set of software components that form the core of a [digital wallet](#h.sxnvf3f5v156), but which by themselves are not sufficient to deliver a fully functional wallet for use by a [digital agent](#h.z3ugzt4hgdf6) (of a [principal](#h.sydbe7rk6244)). A wallet engine is to a [digital wallet](#h.sxnvf3f5v156) what a [browser engine](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Browser_engine&sa=D&source=editors&ust=1718703186903414&usg=AOvVaw0rj8PbDRldoIBFi2iV8K7E) is to a web browser.
+
+        For more information: The charter of the [OpenWallet Foundation](#h.271hay7m0g55) is to produce an open source [digital wallet](#h.sxnvf3f5v156) engine.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [watcher](#watcher)
+
+    -   ### ToIP (DID:Webs)
+
+        An entity that keeps a copy of a KERL of an AID to detect duplicity of key events, as defined by the KERI whitepaper. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # watcher
+
+        ###### Definition
+
+        KERI alternative to total global ordering and consensus protocols is a mechanism called [duplicity](https://weboftrust.github.io/keridoc/docs/glossary/duplicity.md) detection. In the [verification](https://weboftrust.github.io/keridoc/docs/glossary/verifier.md) and [validation](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/first-seen.md) wins".
+
+        ###### KERI operational
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [web of trust](#web-of-trust)
+
+    -   ### WebOfTrust
+
+        # web of trust
+
+        ###### Definition
+
+        In cryptography, a web of trust is a concept used in [PGP](https://weboftrust.github.io/keridoc/docs/glossary/PGP.md), [GnuPG](https://weboftrust.github.io/keridoc/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.
+
+        ![Web of trust illustration](https://github.com/WebOfTrust/keri/raw/main/images/web-of-trust.png)
+
+        More on [Wikipedia](https://en.wikipedia.org/wiki/Web_of_trust)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [weight of weights](#weight-of-weights)
+
+    -   ### WebOfTrust
+
+        # weight of weights
+
+        ###### Definition
+
+        There are 2 levels in the multi-sign weighted thresholds of [multi-signatures](https://weboftrust.github.io/keridoc/docs/glossary/multisig.md) in [KERI](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/delegation.md)).
+
+        ###### CESR related
+
+        It also gives the advantage that the resulting [CESR](https://weboftrust.github.io/keridoc/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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [well known witnesses](#well-known-witnesses)
+
+    -   ### WebOfTrust
+
+        # well known witnesses
+
+        ###### Definition
+
+        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!
+
+        ##### Security
+
+        Don't use the creation of well-known witnesses in a production environment, but for running tests it's suitable.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [witness](#witness)
+
+    -   ### Nist
+
+        An appropriately cleared (if applicable) and designated individual, other than the COMSEC Account Manager, who observes and testifies to the inventory or destruction of COMSEC material.
+
+        [Learn more](https://csrc.nist.gov/glossary/term/witness)
+
+    -   ### ToIP
+
+        A computer system that receives, [verifies](#h.xfewd7t01hu0), and stores [proofs](#h.r2qw6757lopw) of [key events](#h.w6skxxfqgbqp) for a [verifiable identifier](#h.wyda231qefe) (especially an [autonomous identifier](#h.bz098kwwc559)). Each witness controls its own [verifiable identifier](#h.wyda231qefe) used to sign [key event](#h.w6skxxfqgbqp) messages stored by the witness. A witness may use any suitable computer system or database architecture, including a file, centralized database, distributed database, [distributed ledger](#h.eoh04mpatko3), or [blockchain](#h.bxz57auzxstx).
+
+        Note: [KERI](#h.7pp65h7qs9lu) is an example of a [key management system](#h.q0w3jq78va39) that uses witnesses.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+    -   ### ToIP (DID:Webs)
+
+        An entity that is designated by the controller of an AID to verify, sign, and keep the key events associated with the AID, as defined by the KERI whitepaper. See WebOfTrust glossary for more detail.
+
+        [Learn more](https://trustoverip.github.io/tswg-did-method-webs-specification/index.html)
+
+    -   ### WebOfTrust
+
+        # witness
+
+        ###### Definition
+
+        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/keridoc/docs/glossary/trust-domain.md) and may be controlled (but not necessarily so) by its [controller](https://weboftrust.github.io/keridoc/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/keridoc/docs/glossary/backer.md)_ and _Witness_ are closely related in KERI but not synonyms or interchangeable.
+
+        ###### KERI witness confusing
+
+        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)
+
+        ###### Operational description in KERI
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [xip](#xip)
+
+    -   ### WebOfTrust
+
+        # xip
+
+        ###### Definition
+
+        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)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [zero trust](#zero-trust)
+
+    -   ### WebOfTrust
+
+        # zero trust
+
+        ###### Definition
+
+        a Zero Trust approach trusts no one.
+
+        ###### KERI related concepts
+
+        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.
+
+        [Learn more](https://kerisse.org)
+
+-   ## [zero trust computing](#zero-trust-computing)
+
+    -   ### WebOfTrust
+
+        # zero trust computing
+
+        ###### Definition
+
+        Best practices for 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; Locality is not trustworthy. 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 every-thing. 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. Policy is protected by diffuse trust.
+        7.  Hosts locked down. Hosts or host components executing any of the logic mentioned above must be locked down. Any changes to the host execution logic or behavior must be fully security tested and validated over the respective possible combinations of hardware and software platform. 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 specially as 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 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
+
+        ###### Also see
+
+        [zero trust](https://weboftrust.github.io/keridoc/docs/glossary/zero-trust.md)
+
+        [Learn more](https://kerisse.org)
+
+-   ## [zero-knowledge proof](#h.zc9pf8eexjs)
+
+    -   ### ToIP
+
+        A specific kind of cryptographic [proof](#h.r2qw6757lopw) that proves facts about [data](#h.o783ayrrkc6g) to a [verifier](#h.xfewd7t01hu0) without revealing the underlying [data](#h.o783ayrrkc6g) itself. A common example is proving that a person is over or under a specific age without revealing the person’s exact birthdate.
+
+        Also known as: zero-knowledge protocol.
+
+        Supporting definitions:
+
+        [Ethereum:](https://www.google.com/url?q=https://ethereum.org/en/zero-knowledge-proofs/&sa=D&source=editors&ust=1718703186904889&usg=AOvVaw1HGIxXCnaOWvdwxNDLU5F-) A zero-knowledge proof is a way of proving the validity of a statement without revealing the statement itself.
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Zero-knowledge_proof&sa=D&source=editors&ust=1718703186905130&usg=AOvVaw15YjypJZ8t5MboU3IyXmrt): a method by which one [party](#h.cn6bno48fomj) (the prover) can prove to another party (the verifier) that a given statement is true, while avoiding conveying to the [verifier](#h.xfewd7t01hu0) any information beyond the mere fact of the statement's truth.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [zero-knowledge service](#h.lwi61cg5ym5c)
+
+    -   ### ToIP
+
+        In cloud computing, the term “zero-knowledge” refers to an online service that stores, transfers or manipulates [data](#h.o783ayrrkc6g) in a way that maintains a high level of [confidentiality](#h.445sv27j3c2m), where the data is only accessible to the [data's](#h.o783ayrrkc6g) [owner](#h.y450rpi0zmuu) (the client), and not to the service provider. This is achieved by [encrypting](#h.iyq318f2vg61) the raw data at the client's side or [end-to-end](#h.q2kyp3tnhmic) (in case there is more than one client), without disclosing the password to the service provider. This means that neither the service provider, nor any [third party](#h.zu2vj8151tr) that might intercept the [data](#h.o783ayrrkc6g), can [decrypt](#h.fuc05ut9lwmq) and access the [data](#h.o783ayrrkc6g) without prior permission, allowing the client a higher degree of privacy than would otherwise be possible. In addition, zero-knowledge services often strive to hold as little [metadata](#h.t63bf0ssndfd) as possible, holding only that [data](#h.o783ayrrkc6g) that is functionally needed by the service.
+
+        Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Zero-knowledge_service&sa=D&source=editors&ust=1718703186906478&usg=AOvVaw0AR-0F29RWRL7COnn5EosR).
+
+        Also known as: no knowledge, zero access.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [zero-knowledge service provider](#h.qhfq42vp7l55)
+
+    -   ### ToIP
+
+        The provider of a [zero-knowledge service](#h.lwi61cg5ym5c) that hosts [encrypted](#h.iyq318f2vg61) [data](#h.o783ayrrkc6g) on behalf of the [principal](#h.sydbe7rk6244) but does not have access to the [private keys](#h.74y9dvxzg24c) in order to be able to [decrypt](#h.fuc05ut9lwmq) it.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+-   ## [zero-trust architecture](#h.n5o72c1d9x8a)
+
+    -   ### ToIP
+
+        A network security architecture based on the core design principle “never trust, always verify”, so that all [actors](#h.gzdfngxkp0ip) are denied access to resources pending [verification.](#h.2bnb6g8na7cu)
+
+        Also known as: zero-trust security, perimeterless security.
+
+        Contrast with: [attribute-based access control](#h.ckr2atznm0o), [role-based access control](#h.isj9yeecvwmw).
+
+        Supporting definitions:
+
+        [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/zero_trust_architecture&sa=D&source=editors&ust=1718703186907573&usg=AOvVaw1cUreVMcJJt1iegQ0qgOoH): A security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The zero trust security model eliminates implicit trust in any one element, component, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses.
+
+        [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Zero_trust_security_model&sa=D&source=editors&ust=1718703186907834&usg=AOvVaw3K8uSSwQ9HUWp70rHUQxCQ): The zero trust security model, also known as zero trust architecture (ZTA), and sometimes known as perimeterless security, describes an approach to the strategy, design and implementation of [IT systems](https://www.google.com/url?q=https://en.wikipedia.org/wiki/IT_system&sa=D&source=editors&ust=1718703186908028&usg=AOvVaw0Qti3Ur_bJE-xEyDmcHh6O). The main concept behind the zero trust security model is "never trust, always verify," which means that users and devices should not be trusted by default, even if they are connected to a permissioned network such as a corporate [LAN](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Local_area_network&sa=D&source=editors&ust=1718703186908216&usg=AOvVaw39wg7oQ_ZLGPSPk5zPEKe0) and even if they were previously verified.
+
+        [Learn more](https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit)
+
+
+
+
+---
+title: Various visualisations from Slack discussions
+description: 1
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/visualisations/various-visualisations-from-slack/index
+  md: https://weboftrust.github.io/keridoc/docs/visualisations/various-visualisations-from-slack/index.md
+---
+
+# Various visualisations from Slack discussions
+
+![KERI Architecture Overview](https://weboftrust.github.io/keridoc/assets/images/KERI Architecture Overview-47ab2b366f23b8a5533794d914743408.md) ![Screenshot 2023-04-27 at 11.30.17 AM](https://weboftrust.github.io/keridoc/assets/images/Screenshot 2023-04-27 at 11.30.17 AM-59d5525ac1dae4a89c8de6880f0f3dcf.md) ![KERI Architecture Overview](https://weboftrust.github.io/keridoc/assets/images/KERI Architecture Overview-47ab2b366f23b8a5533794d914743408.md) ![Screen Shot 2566-03-08 at 08.31.46](https://weboftrust.github.io/keridoc/assets/images/Screen Shot 2566-03-08 at 08.31.46-bde7bf73766890c35a19b2bd1619fe77.md) ![Screenshot 2023-04-27 at 11.30.17 AM](https://weboftrust.github.io/keridoc/assets/images/Screenshot 2023-04-27 at 11.30.17 AM-1017915e86120cc20d2b35032f049ba4.md) ![@context optionality](https://weboftrust.github.io/keridoc/assets/images/@context optionality-f578a9112412a4e4146dd9b717f3f76b.md) ![KERI and ACDC](https://weboftrust.github.io/keridoc/assets/images/KERI and ACDC-c50be468763b2b7fc2dcc6e24e37ac48.md) ![image2](https://weboftrust.github.io/keridoc/assets/images/image2-bd037f14ba0b0dfaf8473e8a08293714.md) ![image3](https://weboftrust.github.io/keridoc/assets/images/image3-a9001804e03f347b76b753c367b23920.md) ![KERI Architecture Overview - Signify Architecture](https://weboftrust.github.io/keridoc/assets/images/KERI Architecture Overview - Signify Architecture-c4742f74f3abf10edb95ffa7d2e063fc.md) ![Screenshot 2023-04-27 at 11.30.17 AM](https://weboftrust.github.io/keridoc/assets/images/Screenshot 2023-04-27 at 11.30.17 AM-1017915e86120cc20d2b35032f049ba4.md) ![Screenshot 2566-07-11 at 09.16.49](https://weboftrust.github.io/keridoc/assets/images/Screenshot 2566-07-11 at 09.16.49-4176aa12918001e628e835d097935bd5.md) ![Captura de Pantalla 2022-10-17 a la(s) 10.24.40 a.m.](https://weboftrust.github.io/keridoc/assets/images/Captura de Pantalla 2022-10-17 a la(s.md) 10.24.40 a.m.-131702f5ce41775fa0506a59409b0122.png) ![controllers-and-oobis](https://weboftrust.github.io/keridoc/assets/images/controllers-and-oobis-2c171eae5f0486b8c0c76c6ccd4d094f.md) ![Screenshot 2566-04-28 at 17.08.10](https://weboftrust.github.io/keridoc/assets/images/Screenshot 2566-04-28 at 17.08.10-71190c35e865a99338dee5aaa477f0f6.md)
+
+
+
+
+---
+title: Animated visualisation of repo connections
+description: See visualisation
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/visualisations/repo-connections/index
+  md: https://weboftrust.github.io/keridoc/docs/visualisations/repo-connections/index.md
+---
+
+# Animated visualisation of repo connections
+
+See [visualisation](https://weboftrust.github.iokeridoc/visualisations/WebOfTrust/index.htm)
+
+
+
+
+---
+title: KERIA Service Architecture
+description: ;
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/visualisations/keria-service-architecture/index
+  md: https://weboftrust.github.io/keridoc/docs/visualisations/keria-service-architecture/index.md
+---
+
+# KERIA Service Architecture
+
+;
+
+Flow charts created by Phil Feairheller.
+
+
+
+
+---
+title: KERI & ACDC Architecture
+description: Flow charts created by Kent Bull.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/visualisations/keri-and-acdc-architecture/index
+  md: https://weboftrust.github.io/keridoc/docs/visualisations/keri-and-acdc-architecture/index.md
+---
+
+# KERI & ACDC Architecture
+
+Flow charts created by Kent Bull.
+
+![KERI & ACDC Architecture - Ctlr-Node](https://weboftrust.github.io/keridoc/assets/images/KERI-&-ACDC-Architecture---Ctlr-Node-dbe8fbc881d44fbe8c297fc1d2437f2e.md) ![KERI & ACDC Architecture - Wit-Node](https://weboftrust.github.io/keridoc/assets/images/KERI-&-ACDC-Architecture---Wit-Node-e4d02448794d29f297a6188104f1f101.md)
+
+
+
+
+---
+title: Backed and Backerless Issuance and Revocation
+description: Flow charts created by Jason Colburne.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/visualisations/backed-and-backerless-issuance-and-revocation/index
+  md: https://weboftrust.github.io/keridoc/docs/visualisations/backed-and-backerless-issuance-and-revocation/index.md
+---
+
+# Backed and Backerless Issuance and Revocation
+
+Flow charts created by Jason Colburne.
+
+icpKELixnpVCbisra.dACDCrivcpiMGMTiiia.dixnpra.ivrtppa.dixna.da.ia.ia.ivcppbrvpra.ira.dia.da.ibackedissuance/revocation;
+
+icpKELixnpVCissACDCrivcpiMGMTiiiaixnpria.da.iixnprevpia.da.ibackerlessissuance/revocationri;
+
+
+
+
+---
+title: Let's KERI on together
+description: The video
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/video/lets-keri-on-together/index
+  md: https://weboftrust.github.io/keridoc/docs/video/lets-keri-on-together/index.md
+---
+
+# Let's KERI on together
+
+> [!NOTE]
+> okay and I will show slides all right so this is the presentation I did at IIW called 'Let's
+
+0:00:00.080,0:00:00.800 paracore
+
+0:00:03.520,0:00:12.480 okay and I will show slides all right so this is the presentation I did at IIW called 'Let's
+
+0:00:12.480,0:00:20.640 KERI on together'. I did the presentation, I did the card at IIW with instructions on
+
+0:00:20.640,0:00:26.880 how to pull the software and get ready so you could run alongside the demo if you so chose.
+
+0:00:27.600,0:00:33.120 No one did, which was a little bit disappointing, but the repo is here, it's the KERI, right, KERIpy
+
+0:00:33.120,0:00:39.680 repo the web of trust it's a lot of the all of the networking and asynchronous
+
+0:00:41.840,0:00:49.840 I/O is based on co-routines in a library Sam Smith created called 'hio' right now
+
+0:00:49.840,0:00:54.000 what I'll be running today requires Python 3.9.7 but we're now up to 3.10.3
+
+0:00:55.200,0:00:58.960 and these are the instructions if you wanted to follow along let me get clone
+
+0:01:00.000,0:01:04.320 the repo itself check out the future 'iiw' branch and then just run a `pip install`
+
+0:01:05.120,0:01:12.960 of the requirements file, to get all of the dependencies. So most of actually everything
+
+0:01:12.960,0:01:18.720 that we'll be showing today, starts with the KERI command line interface that we call 'kli'.
+
+0:01:18.720,0:01:26.080 It has commands and sub commands much like, if you're familiar with Kubernetes' "kubectl" command line,
+
+0:01:26.080,0:01:29.840 so that for example if you were doing some something with verifiable credentials you would
+
+0:01:29.840,0:01:36.080 start 'kli vc' and then there would be a sub command following after the 'vc' for example 'issue' or 'revoke'
+
+0:01:38.320,0:01:46.640 And then we do have Docker containers that have all of the code pushed and configured
+
+0:01:46.640,0:01:53.440 ready to run so you can pull one of those and do a 'docker run', running a sub shell
+
+0:01:53.440,0:02:00.960 and you can use the kli to perform tasks so the basic structure for the commands in the kli
+
+0:02:01.840,0:02:07.840 the groups that we have, pardon me, the agent group for running our cloud agent which is also run
+
+0:02:09.200,0:02:16.800 in the distributable desktop application we're building using Py installer and
+
+0:02:16.800,0:02:23.200 Electron to bundle KERIpy behind a web-U/I that web-U/I uses the agent
+
+0:02:24.880,0:02:29.600 if you want to perform some delegation commands there's a couple of sub commands under delegate
+
+0:02:29.600,0:02:34.320 if you want to create a distributed multi-sig identifier you would use the multisig commands
+
+0:02:34.320,0:02:38.560 and then the verifiable credentials I mentioned the wallet commands are simply for listing the
+
+0:02:38.560,0:02:44.560 contents of your wallet and by "wallet" I mean verifiable credential wallet and then
+
+0:02:44.560,0:02:50.320 to start witnesses or watchers you would use the watcher group with sub cmnds like 'start'&'demo'
+
+0:02:51.200,0:02:58.640 Steven: So, Phil, all these ..., well everything on this page, is there documentation as to
+
+0:02:58.640,0:03:06.240 what exactly an 'agent' means like do you have the terminology somewhere? Phil: No, there isn't, (Now there is!, ed.)
+
+0:03:06.240,0:03:13.440 but that would be a good thing to add to a getting started I guess. Steven: yeah absolutely, so I mean could
+
+0:03:13.440,0:03:20.880 certainly create like a vocabulary dictionary and then maybe a one-liner description
+
+0:03:20.880,0:03:28.400 of what each like "run cloud agent" does, what delegation means. Phil: yeah that would be great.
+
+0:03:28.400,0:03:30.720 (Available! See the glossary in the Youtube description)
+
+0:03:30.720,0:03:46.800 Look at command line, if you run just 'help' from the top level,   it does list... Steven: can you share the screen?
+
+0:03:47.440,0:03:53.360 Phil: I'm sharing just this spreadsheet, I mean just the presentation on there, let me show that desktop
+
+0:03:56.000,0:03:59.200 there we go, okay can you see the command line now? Steven: yeah
+
+0:03:59.200,0:04:04.480 Phil: OK, so if you run 'kli --help' you get a list of the commands and sub commands and they do have
+
+0:04:05.440,0:04:10.000 one liners not all of them are accurate at this moment but that's something that...
+
+0:04:10.000,0:04:15.840 Steven: doesn't matter, it'll be a placeholder in the worst case scenario.
+
+0:04:16.400,0:04:21.360 okay, so for key management the top level commands the the very first thing you almost always do
+
+0:04:21.360,0:04:27.920 is do an 'init' which initializes both your data store and your encrypted key store, 'incept' for
+
+0:04:27.920,0:04:32.960 creating a single-sig identifier, technically you can create multi-sig identifiers with that as well,
+
+0:04:33.600,0:04:37.120 but they're not all that interesting. Because all the keys are stored in the same key store
+
+0:04:39.440,0:04:44.400 the different key events that you can create an interaction event or a rotation event
+
+0:04:45.040,0:04:48.480 are handled with the next two commands 'interact' and 'rotate' and they each take
+
+0:04:48.480,0:04:54.160 parameters, 'rotation' for example, specifying your signing thresholds number of keys rotating in
+
+0:04:54.160,0:05:00.000 and out witnesses all the things that you can do when rotating and 'purge' just deletes your key store
+
+0:05:01.600,0:05:09.040 so then the miscellaneous commands querying for creating witnesses for a KEL. Sending your
+
+0:05:09.040,0:05:14.240 KEL to another agent; we don't use that very much anymore because we use OOBIs to accomplish that now.
+
+0:05:15.120,0:05:23.120 Signing, pardon me, you can just sign our arbitrary data and it will return the signatures based on
+
+0:05:23.120,0:05:27.520 the identifier that you used and we'll be done I'll be demoing that in a little bit. Verifying
+
+0:05:27.520,0:05:32.000 those signatures and if you're you know if you're just exchanging signed data with someone via an
+
+0:05:32.000,0:05:36.800 e-mail this will accomplish that for you. Then 'list'ing the identifiers that
+
+0:05:36.800,0:05:42.880 you're creating and giving a 'status' of a single identifier. So it's important to point out that
+
+0:05:44.240,0:05:51.840 with the most recent updates to KERIpy, we now have first class support (ringing silenced)
+
+0:05:57.040,0:06:02.480 We now have first class support for multiple identifiers multiple local identifiers,
+
+0:06:03.760,0:06:07.040 so that's why we have the 'list' command so you can create in you can run
+
+0:06:07.040,0:06:10.560 'init' once create a single data store and key store and then run 'incept' as
+
+0:06:10.560,0:06:13.600 many times you want to create other identifiers and you use those for
+
+0:06:13.600,0:06:20.320 like peer-to-peer communications and things like that, so that you can't be correlated. All right
+
+0:06:22.640,0:06:29.120 so each of the three top level runnable components an agent a witness or a watcher each have
+
+0:06:31.280,0:06:39.520 various startup commands. You have the 'bootstrap' command to start an empty agent or to run a single
+
+0:06:39.520,0:06:44.800 agent against one that's already been started. You can run 'start' and then both for witnesses and for
+
+0:06:44.800,0:06:50.480 agents we have these 'demo' commands which we make heavy use of for local testing. So, for example
+
+0:06:50.480,0:06:55.920 under the witness this starts up three well-known witnesses and by "well-known" I mean we use salts
+
+0:06:55.920,0:07:02.720 to initialize their key stores so that the you can predict what identifiers will be created and
+
+0:07:02.720,0:07:09.760 again that's not anything that you'd want to do in a production environment,
+
+0:07:09.760,0:07:14.240 but for running tests, and we'll be using particularly the 'demo' witness command later on
+
+0:07:15.120,0:07:19.200 to start witnesses so that other commands that need witnesses know where to find them.
+
+0:07:20.320,0:07:26.720 And then we have similar commands for watchers. Part of the demo today is running through a
+
+0:07:26.720,0:07:31.920 series of scripts that we've created in the demo directory located in keripy/scripts/demo
+
+0:07:33.360,0:07:38.960 and the most basic one is just 'demo-script' which starts off and runs all the really basic commands
+
+0:07:39.520,0:07:43.840 'demo-witness-script' runs through some of the same commands but requiring witnesses to be running
+
+0:07:44.720,0:07:50.160 and then we get into the more interesting stuff: delegation and multi-sig
+
+0:07:50.160,0:07:54.800 multi-sig delegation where both parties of the delegation are a multi-sig identifier
+
+0:07:54.800,0:07:59.920 and then credential issuance and multi-issuance. During the demo at IIW we did not get to these.
+
+0:08:00.720,0:08:05.360 We only got this far and in an hour. I'm not sure we'll even get to these, but we will see.
+
+0:08:08.320,0:08:15.760 Oh, I forgot to point out the all of the sample JSON files are also located in keripy/tests/app/cli,
+
+0:08:15.760,0:08:25.360 which contains the ..., when you do a 'kli incept' command, it takes a file for all the properties
+
+0:08:25.360,0:08:30.560 that you want to pass in for the creation of that identifier, for example how many signature or how
+
+0:08:30.560,0:08:34.880 many public keys to create, what's your signing thresholds, how many / what witnesses to use, whether
+
+0:08:34.880,0:08:39.840 it's transferable or not, et cetera and I'll show these as we go through them today
+
+0:08:42.320,0:08:47.360 and then finally another big enhancement in this most recent round of changes to KERIpy
+
+0:08:47.920,0:08:53.840 was the addition of out-of-band introductions or OOBIs. They are files,
+
+0:08:54.560,0:09:00.400 these are startup files that contain bootstrap OOBIs. So for example when we use the 'demo'
+
+0:09:00.400,0:09:04.800 command for witnesses, like I said: they're well-known identifiers, they also start up
+
+0:09:04.800,0:09:08.720 on well-known ports and they publish those ports via a series of OOBIs. This is a
+
+0:09:08.720,0:09:14.880 configuration file that any other agent can run and know exactly how to contact those witnesses
+
+0:09:16.000,0:09:19.120 and this is the configuration file for those witnesses, so we'll get to those in a minute.
+
+0:09:20.000,0:09:26.080 So that's it for the, pardon me, that's it for the presentation there's not slides anyway
+
+0:09:26.080,0:09:30.240 there's not that much in terms of slides, here's just enough to get this kick-started.
+
+0:09:32.720,0:09:38.560 So now we'll go over to our first script today. Oh, one thing I didn't point out, but I wanted to
+
+0:09:38.560,0:09:44.000 make clear: because we have the kli which you can do everything you need to do with KERI
+
+0:09:44.640,0:09:48.640 in KERIpy with the kli on a command line and that's for running in a mode where you're
+
+0:09:48.640,0:09:54.640 not always on the internet. But as I pointed out also, we have an agent that can run.
+
+0:09:54.640,0:09:58.800 That could be a continuous or persistent connection to the internet. So a cloud agent for example.
+
+0:10:00.240,0:10:05.760 And in that case the cloud agent exposes a series of REST APIs that perform the exact same
+
+0:10:05.760,0:10:11.680 functionality as all the kli things that we'll be going through today. And in the demo scripts
+
+0:10:11.680,0:10:17.440 that you see here for every script starting with 'delegate', there is a sister script next to it,
+
+0:10:17.440,0:10:22.320 '-agent', that is the exact same command but with a series of CURL POSTs, I'm sorry, the
+
+0:10:22.320,0:10:28.560 exact same functionality, but executed as a series of CURL POSTs against an agent, or PUTs
+
+0:10:31.600,0:10:35.440 (and I'll show when we launch) the agent we also expose a swagger U/I,
+
+0:10:35.440,0:10:42.000 which allows you, if you wanted, to execute commands against it. I'll show that towards the end.
+
+0:10:44.880,0:10:47.280 So let's start with the basic 'demo' script.
+
+0:10:49.840,0:10:55.920 I'll zoom in here a little bit, is that legible for you? Steven: yeah, I'm much better now.
+
+0:10:57.760,0:11:05.760 Okay so, the very first thing this does is create a key store within it. Currently KERI now supports
+
+0:11:06.560,0:11:11.360 the ability to create a key store and data store for that matter with a passcode and when you
+
+0:11:11.360,0:11:16.400 do that, it becomes an encryption key. like it's stretched into an encryption key that is used for
+
+0:11:17.440,0:11:24.160 encrypting the key store so that no one else can gain access to your private keys
+
+0:11:24.800,0:11:29.040 that passcode is never stored anywhere within KERIpy or the agent
+
+0:11:29.040,0:11:33.520 so it has to be protected by the user because otherwise you can't get access to your keys
+
+0:11:34.400,0:11:41.840 Steven: Sorry Phil give me one sec there's just something going on in here, one second
+
+0:11:45.000,0:11:55.000 (What a perfect break for a small quiz!:) (How many new terms has Phil introduced so far?)
+
+0:11:55.500,0:12:05.520 (The answer is: 55 terms that need explanation!) (Most of which are available; see description.)
+
+0:12:07.520,0:12:08.960 Steven: sorry about that! Phil: no worries
+
+0:12:15.840,0:12:20.240 Okay so, for all of the commands that we're gonna be running today, we just pass in the
+
+0:12:20.240,0:12:23.200 flag '--nopasscode' so the keystore isn't encrypted. And that's just to make things
+
+0:12:23.200,0:12:27.120 easier, so we're not passing passcodes around to every other command but anywhere where you
+
+0:12:27.680,0:12:32.640 run a subsequent command after 'init' you can pass in '--passcode' and it'll unlock
+
+0:12:32.640,0:12:38.400 the keystore if it's indeed locked so the very first thing that this does is create a database
+
+0:12:38.400,0:12:43.680 and key storage you can see from the comments the name of the database, the name of this
+
+0:12:44.480,0:12:48.240 instance that you're creating, is called 'test' and that is used to create
+
+0:12:48.240,0:12:53.440 the directory structure for the databases that support both the wallet and the key store.
+
+0:12:55.520,0:13:00.800 Those databases can go in one of three places. When configured properly you can
+
+0:13:00.800,0:13:06.640 create a database and key store in '/temp' which obviously is used just for testing and
+
+0:13:06.640,0:13:13.360 we use that heavily when running all of our unit tests. If you have a directory called
+
+0:13:14.080,0:13:18.720 '/user/local/var/keri', and the current user has write access to that directory it'll create
+
+0:13:18.720,0:13:22.480 all the databases under there. And then they're prefixed with the name that you give it here.
+
+0:13:23.680,0:13:28.720 If you don't have that directory the last place that KERIpy attempts to create the data stores
+
+0:13:28.720,0:13:34.960 is in your 'home directory.keri' and then it would begin with 'test' for this one after that.
+
+0:13:35.600,0:13:38.160 So those are the three places you want to go look for your key stores
+
+0:13:41.280,0:13:44.240 So after it creates the key store, we're creating... Steven: Sorry, can you, when you
+
+0:13:45.760,0:13:51.280 would you define which one of those three places to look for here? Phil: No. Steven: or it's just the way
+
+0:13:51.280,0:13:56.320 you're installed, you're just, you're set up Phil: that's correct, it's the way your system is set up
+
+0:13:56.320,0:14:01.760 there. we don't support the creation of temporary from the command line. We could add it as a flag,
+
+0:14:01.760,0:14:06.400 I guess, but we don't currently support that. So this will ...,from the command line, this will
+
+0:14:06.400,0:14:09.920 create the key stored in either '/user/local/var/keri', if it exists and you have
+
+0:14:09.920,0:14:16.720 write access to it, or under '.keri' in your own directory if you don't have that other one.
+
+0:14:20.080,0:14:20.580 Uhm...
+
+0:14:23.600,0:14:28.240 Yeah, we could we could definitely add the ability to create a 'temp'(orary ed.) from here but that would
+
+0:14:28.240,0:14:32.960 just be another flag so the first thing we create is a non-transferable identifier after you give
+
+0:14:32.960,0:14:37.520 the name of the data stored you give a local human readable alias to this identifier and as
+
+0:14:37.520,0:14:41.360 i mentioned you can support you can create multiple identifiers so you would give them
+
+0:14:41.360,0:14:43.920 per a single key store so you can give them whatever aliases you want
+
+0:14:43.920,0:14:47.600 So that you can remember what you're using that particular identifier for
+
+0:14:48.880,0:14:52.480 So this is creating a non-transferable identifier. We'll start by opening that
+
+0:14:56.560,0:15:04.320 So, 'transferable=false' obviously and a transferable identifier ( ) okay, if I'm instructing clients who want to build
+
+0:29:42.240,0:29:46.400 SSI infrastructure, do I tell him "he is KERI" do I tell him "he's a ledger" what do I tell him?
+
+0:29:48.160,0:29:51.280 And it was great to clear up a lot of misconceptions because people think:
+
+0:29:52.000,0:29:56.400 "oh, you can't use a ledger with KERI". No that's not true, you don't have to use a ledger with KERI. We
+
+0:29:56.400,0:30:01.200 don't think it's, we don't think it's needed at all, but as Sam as what Sam pointed out during
+
+0:30:01.200,0:30:05.920 the talk, is if you already have an investment in ledger infrastructure for other reasons,
+
+0:30:06.640,0:30:10.720 you can then leverage that ledger as an additional trust threshold,
+
+0:30:10.720,0:30:14.640 or security threshold for your identifiers instead of using witnesses.
+
+0:30:17.200,0:30:22.800 So no, we're not, I mean the vLEI won't be using anything to do, with cryptocurrencies or tokens but
+
+0:30:22.800,0:30:29.280 if you, you know, if for example a lot of people are using SSI systems based on Indy networks, right,
+
+0:30:29.280,0:30:34.320 now if you want to transition to using KERI, you could do that by anchoring your KERI identifiers
+
+0:30:34.320,0:30:39.040 in your Indy ledger. And then you, and the neat thing about it is, you could then transfer them
+
+0:30:39.040,0:30:43.600 off, off the ledger and have non-ledger based identifiers, so that's what's great about
+
+0:30:43.600,0:30:47.760 KERI: it's portable, you can be anchored to any one ledger at a time, or you could move it to a
+
+0:30:47.760,0:30:53.040 different ledger, or you could move to using just witnesses, all with the same identifier by just
+
+0:30:53.040,0:30:58.880 doing rotation events and changing your anchor, your backers here. Steven: but could you also do, if
+
+0:31:02.080,0:31:09.520 could you be anchored, let's say to multiple Indies or Ethereum? Phil: you could be only anchored in one at a
+
+0:31:09.520,0:31:16.160 time, because that's the source of truth for that identifier at that given point in time.
+
+0:31:16.160,0:31:21.440 You can then rotate to a different one, but you you can't have two ledgers at the same time.
+
+0:31:23.200,0:31:30.320 Steven: So when people, well what maybe they misunderstood, so I understood that
+
+0:31:30.320,0:31:33.360 okay one of the problems in blockchain is that you're all you have to be committed to all use
+
+0:31:33.360,0:31:39.120 the same network which is not practical unless you're running an ICO scam, so
+
+0:31:40.960,0:31:46.880 I understand KERI is digital ledger technology agnostic. And that you could
+
+0:31:46.880,0:31:52.080 use it..., it could interoperate with existing ledgers like Aries or Indy whatever it's called,
+
+0:31:54.800,0:31:57.760 but it's only that one network. You couldn't, you couldn't connect
+
+0:31:59.280,0:32:07.520 Ethereum and Indy to the KERI ledger ( ) This is the identifier, because there's an inception event, the SAID of this is the same,
+
+0:49:49.680,0:49:57.840 so these are the two, and here's a sequence number '0'. So now, if we take a look at the delegator
+
+0:50:02.400,0:50:09.280 you can see his rotation event here, this is the approval and that 'EY7'
+
+0:50:09.280,0:50:15.040 is the identifier as well as the SAID or digest of the event that he approved and
+
+0:50:15.040,0:50:20.640 he has anchored that data; thus approving the delegation request from the other guy.
+
+0:50:24.240,0:50:29.520 All right so that makes sense? Steven: Maybe one day, yeah, that's what I'm feeding,
+
+0:50:31.200,0:50:35.200 it's so inspiring. Phil (laughing): "yes there's a lot, there's a lot here.
+
+0:50:37.040,0:50:41.360 All right we have eight minutes I will try and get through multisig actually you know what no
+
+0:50:41.360,0:50:45.920 Steven: No rushing in my account, I mean, I understand you're on vacation here, but don't worry
+
+0:50:45.920,0:50:51.440 about my time. Phil: Yeah, I know, I have another meeting, I have to get to. Steven: Oh okay, not only
+
+0:50:51.440,0:50:57.120 for visiting the family? Phil: yeah exactly, yeah but not only that, but I'm out here buying a house,
+
+0:50:57.120,0:51:08.240 because we're moving out here, so all that, as well as work, it's been very very busy.
+
+0:51:08.240,0:51:09.920 All right, so let me show you the agent really quickly.
+
+0:51:12.640,0:51:21.840 So here we start actually. I don't need the witnesses but anyway so we will run 'kli'
+
+0:51:25.760,0:51:31.200 So I'm running 'kli agent demo', just like the demo command down here, he starts,
+
+0:51:32.480,0:51:37.040 except in this case, he starts four well-known agents and that's because, well I needed to test
+
+0:51:37.040,0:51:43.440 multi-sig delegation with two participants in the delegator, and two participants in the delegatee.
+
+0:51:44.320,0:51:52.960 delegation coordination I start him with a ... (that's not gonna work) Well that's fine, I
+
+0:51:52.960,0:51:59.840 started him with a configuration file that tells him where these three witnesses are and he starts
+
+0:51:59.840,0:52:05.200 four agents on these well-known ports again with actually he doesn't have well-known salts because
+
+0:52:05.840,0:52:12.720 you do those via the CURL commands so once you start those agents, let's see, here we go,
+
+0:52:14.960,0:52:22.640 you get on each of those ports a Swagger U/I which contains the available API calls.
+
+0:52:22.640,0:52:29.200 For the agent depending on his state. Every agent initially starts off in a locked state.
+
+0:52:29.200,0:52:33.280 so think of a ..., remember when we did the 'kli init' commands and created the data store
+
+0:52:34.880,0:52:38.160 that data store is now encrypted and locked, if you gave it a passcode.
+
+0:52:38.720,0:52:43.200 So in this case we don't have any data stores yet, so you can start an agent with no data stores
+
+0:52:43.200,0:52:51.840 around and that's when you end up in this state. So in order our passcode requirement for creating an
+
+0:52:51.840,0:52:56.800 encrypted key store is a 22 character passcode we give you just a little helper function. This isn't
+
+0:52:56.800,0:53:01.600 really part of KERI, but we give you a little helper function for, (my grandson is really unhappy),
+
+0:53:04.320,0:53:09.520 for just generating random passcodes if you need that, you can also use "OnePass" or whatever to
+
+0:53:09.520,0:53:16.640 create them and then store them in OnePass, so now just like 'kli init' that creates a key store
+
+0:53:16.640,0:53:23.600 we have a POST to '/boot' which will create a key store for you, you call it, let's try it
+
+0:53:23.600,0:53:29.920 out, let's not type into the sample I did that during the demo too, 'Agent0', and spell agent right
+
+0:53:32.320,0:53:35.440 and give it the passcode, that you saved and execute,
+
+0:53:36.720,0:53:44.160 and you can see the 'agent0' and key store created and he resolved a whole bunch
+
+0:53:44.160,0:53:47.920 of OOBIs, that's part of the configuration file, I guess I do have running the ...,
+
+0:53:48.720,0:53:54.800 So, one thing to note about here, is several of the OOBIs are actually data OOBIs. And we can also
+
+0:53:54.800,0:53:59.440 use OOBIs to resolve things like credential schema. So that's a whole separate topic.
+
+0:54:01.520,0:54:06.880 So, now that we've created the key store the next step is to unlock it, and so this is like
+
+0:54:07.600,0:54:12.560 if you ..., so we ran this demo at IIW after doing our demo hour where we demo-ed the U/I
+
+0:54:12.560,0:54:15.680 that we have sitting on top of this to Keep, and so when you get into the Keep,
+
+0:54:15.680,0:54:19.280 you get a nice screen that says "hey, create your passcode", which is that first API call.
+
+0:54:19.280,0:54:23.840 And it uses the top API called to generate random keystore keys for people who want samples
+
+0:54:24.480,0:54:29.040 to use and then we do a PUT against '/boot' for unlocking. And that's the next
+
+0:54:29.040,0:54:33.040 nice block in the U/I that says "now unlock your key store" Every time you come back into the agent,
+
+0:54:33.040,0:54:37.840 because you already have a key store, you just have to unlock, right, because you've already created it
+
+0:54:41.680,0:54:46.240 So we're going to try it out, here we called him 'agent0',
+
+0:54:48.400,0:54:53.600 and there's the passcode that we use, and we're going to execute this and he says "'agent0' is
+
+0:54:53.600,0:54:58.560 now unlocked", and the cool thing about unlocking an agent, is you just reload and you now have a
+
+0:54:58.560,0:55:03.360 whole new set of APIs for doing all the things you would want to do with an agent, and these all
+
+0:55:03.360,0:55:09.520 marry up very nicely with the 'kli' commands that we've been running. Get your list of identifiers,
+
+0:55:11.360,0:55:15.280 get information about a specific identifier, you can create a new identifier, this would be
+
+0:55:15.280,0:55:23.600 like 'kli incept', you can update, so again not part of KERI but to support a user interface, a wallet
+
+0:55:23.600,0:55:26.960 for example, where you're going to have a ton of different identifiers, you need to associate
+
+0:55:26.960,0:55:32.160 metadata with those. You give yourself context to remember, you know what organization, who ...,
+
+0:55:32.160,0:55:36.560 Just think of a standard contact book; that's what this API is for us; for updating that.
+
+0:55:37.600,0:55:42.160 And because we're "zero trust", all that data is signed at REST, so that if you lose control of
+
+0:55:42.160,0:55:47.680 your database, people can't put in like, you know, change the name of the contact and fake you out,
+
+0:55:47.680,0:55:52.960 because we verify the data when we reload it, and then you can do a rotation or an interaction event.
+
+0:55:53.840,0:55:58.400 This is for creating and listing your credential registries so the public transaction event logs
+
+0:55:58.400,0:56:03.520 for anchoring issuance and revocation events a presentation request, you can generate
+
+0:56:03.520,0:56:07.520 your own OOBI or resolve other people's OOBIs. This is like the 'kli oobi' commands
+
+0:56:08.400,0:56:13.360 these are the this is challenge response so one of the requirements of the Keep is that you do a
+
+0:56:13.360,0:56:18.160 two-factor auth, so this is for generating like a list of challenge words, that's what this guy does.
+
+0:56:18.160,0:56:23.040 Which is just randomly generated challenge words. You would then take those, send them to another
+
+0:56:23.040,0:56:29.280 person using this command. They would then get a notification that someone has challenged them.
+
+0:56:29.280,0:56:33.040 They sign it with that identifier and send it back and now you have proven that they have
+
+0:56:33.040,0:56:38.000 control of your identifier, and that was actually a big part of the demo, that we did during demo hour.
+
+0:56:41.360,0:56:45.600 This is more information about getting, about getting an updating contact information.
+
+0:56:45.600,0:56:49.680 We also support images. We don't sign those yet and Samuel (Smith, ed.) says to me that we have to sign them.
+
+0:56:49.680,0:56:54.720 ( some domestic situation itemised :) ) And then this is for getting the schema, that we loaded via the
+
+0:56:54.720,0:56:59.200 OOBIs, that I showed you at the beginning, this is diagnostics we're taking a look at, the escrow
+
+0:56:59.200,0:57:03.120 status, because all events are asynchronous, passing events around, you can get them out
+
+0:57:03.120,0:57:06.560 of order, you can get them without full signatures, without full witness receipts, and we have a whole
+
+0:57:06.560,0:57:12.560 series of escrows, that the events just sit in, that we constantly check for any other event to come in,
+
+0:57:12.560,0:57:19.920 to resolve them out of their current state, this is for mailbox notifications, so this is a 'server-
+
+0:57:19.920,0:57:26.400 sent events', streaming service for the agent U/I,   to get notifications from the KERI system itself,
+
+0:57:28.320,0:57:33.680 these are all the APIs for performing multisig and these are APIs for doing credentialing with
+
+0:57:33.680,0:57:37.040 a multi-sig identifier. And the reason why these have to be different, is because there's
+
+0:57:37.040,0:57:43.120 communication involved. Someone leads the process that would be with a POST, and then others call PUT
+
+0:57:43.120,0:57:48.720 to participate in the process. And so, for example if I have an identifier, if you and I are sharing
+
+0:57:48.720,0:57:54.480 an identifier, where you have a private key and I have a private key, I would initiate it and then
+
+0:57:54.480,0:57:58.400 send, the system would send the credential to you, you would look at the credentials, say "Yep, this is
+
+0:57:58.400,0:58:03.120 the one we agreed to issue". You would then do a PUT with that credential and your signature, and then
+
+0:58:03.120,0:58:08.240 it would become a valid credential. And we do have scripts, and all that, we can go through that
+
+0:58:08.240,0:58:13.120 Maybe you and I can schedule something next week, and we can go forward and do the multi-sig stuff
+
+0:58:13.920,0:58:21.200 Okay, all right, so that's most of what I did. We had an hour and a half, when I was at
+
+0:58:21.200,0:58:27.920 at IIW. Because I did it over the working lunch session (which meant I didn't get to eat) and we
+
+0:58:27.920,0:58:32.800 went on through the next set of scripts, which is multi-sig and then multi-sig delegation on both
+
+0:58:32.800,0:58:36.560 the delegator and the delegatee. And that was fun because you get four windows running, and they're
+
+0:58:36.560,0:58:40.880 all waiting for each other. And when you're to finally fire off the final one, they all just resolve,
+
+0:58:40.880,0:58:45.440 with signed events everywhere, It's really cool so maybe we can do that sometime next week. Steven: okay
+
+
+
+
+---
+title: 2024-03-24 KERI dev call
+description: Why Zoom to KERISSE?
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/video/2024-03-24-KERI-dev-call/index
+  md: https://weboftrust.github.io/keridoc/docs/video/2024-03-24-KERI-dev-call/index.md
+---
+
+# 2024-03-24 KERI dev call
+
+We combined the delivery of a Zoom Meeting recording link and a KERISSE test to investigate how this would work in practise:
+
+-   the editing with ffmpeg commandline tool
+-   uploading and documenting on Youtube and finally
+-   delivery of a big mp4 file hosted on Youtube.
+```
+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
+```
+
+
+
+
+---
+title: One doc tagged with "KERI"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/tags/keri/index
+  md: https://weboftrust.github.io/keridoc/docs/tags/keri/index.md
+---
+
+# One doc tagged with "KERI"
+
+[
+
+## UNIVERSAL IDENTIFIER THEORY
+
+](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/IdentifierTheory-ssmith-uidt.md)
+
+Samuel M. Smith Ph.D.\\
+
+
+
+
+---
+title: One doc tagged with "ACDC"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/tags/acdc/index
+  md: https://weboftrust.github.io/keridoc/docs/tags/acdc/index.md
+---
+
+# One doc tagged with "ACDC"
+
+[
+
+## UNIVERSAL IDENTIFIER THEORY
+
+](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/IdentifierTheory-ssmith-uidt.md)
+
+Samuel M. Smith Ph.D.\\
+
+
+
+
+---
+title: keri.one-labeled
+description: Primary Resources
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/keri.one-labeled/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/keri.one-labeled/index.md
+---
+
+# keri.one-labeled
+
+-   **Title:** [KERI White Paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
+
+    -   **Description:** The foundational paper on the Key Event Receipt Infrastructure.
+    -   **Target group:** General Public, Researchers
+    -   **Level:** 1
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Keri White Paper Slide Deck](https://github.com/SmithSamuelM/Papers/blob/master/presentations/KERI_Overview.web.pdf)
+
+    -   **Description:** Slide deck providing a visual and concise overview of KERI.
+    -   **Target Group:** General Audience, Developers
+    -   **Level:** 2
+    -   **Type:** Slide Presentation
+    -   **Category:** KERI
+-   **Title:** [Secure Privacy Authenticity Confidentiality (SPAC)](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/SPAC_Message.md)
+
+    -   **Description:** Detailed paper on the SPAC concept as it applies to KERI.
+    -   **Target Group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [SPAC Presentation](https://github.com/SmithSamuelM/Papers/blob/master/presentations/SPAC_Overview.web.pdf)
+
+    -   **Description:** A slide deck offering an overview of the SPAC concept.
+    -   **Target Group:** General Audience, Developers
+    -   **Level:** 2
+    -   **Type:** Slide Presentation
+    -   **Category:** KERI, SAID
+
+-   **Title:** [Community](https://github.com/WebOfTrust/keri)
+
+    -   **Description:** Engage with an active community of developers around KERI.
+    -   **Target group:** Developers
+    -   **Level:** 2
+    -   **Type:** Community
+    -   **Category:** KERI
+-   **Title:** [Open Source Implementation](https://github.com/WebOfTrust)
+
+    -   **Description:** Access open-source implementations for KERI.
+    -   **Target group:** Developers
+    -   **Level:** 3
+    -   **Type:** Implementation
+    -   **Category:** KERI
+
+-   **Title:** [KERI Q&A Slides IIW 2021 Spring](https://blockchainbird.org/downloads/KERI-QA-introduction.pdf)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [Other Related White Papers](https://github.com/SmithSamuelM/Papers)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [Other Related Slide Decks](https://github.com/SmithSamuelM/Papers/tree/master/presentations)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [How KERI Tackles the Problem of Trust](https://jolocom.io/blog/how-keri-tackles-the-problem-of-trust/)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [DID Method Discussion for KERI](https://docs.google.com/presentation/d/161wlX-UtZCYlVRoEOJ8KwIu7h79gQ0U64kW63SArZkw/edit#slide=id.p)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [On KERI: A Way Not to Reveal More Personal Info Than You Need To](https://blogs.harvard.edu/doc/2020/10/22/keri/)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [Thinking of DID? KERI On](https://humancolossus.foundation/blog/thinking-of-did-keri-on)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [KERI MOOC (Massive Online Opensource Course) Github Repo](https://github.com/henkvancann/keri-1/blob/main/docs/keri-mooc.md)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [KERIdemilia DHT for Discovery](https://github.com/ryanwwest/papers/blob/master/whitepapers/keridemlia.pdf)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+-   **Title:** [SSI can do just fine, blockchain-less](https://lnkd.in/erEcX25H)
+
+    -   **Description:** Slide deck for KERI Q&A session held in spring 2021.
+    -   **Target group:** General Public, Developers, Researchers
+    -   **Level:** 2
+    -   **Type:** Slides
+    -   **Category:** KERI, SAID
+
+-   **Title:** [Definitely Identity: Episode 12 with Samuel Smith](https://soundcloud.com/tim-bouma-1/definitely-identity-e1pisode-14-with-sam-smith)
+
+    -   **Description:** A podcast episode featuring Samuel Smith discussing identity.
+    -   **Target group:** General Public
+    -   **Level:** 1
+    -   **Type:** Podcast
+    -   **Category:** KERI, SAID
+-   **Title:** [E4: SSI vs Federation, with Steve Wilson](https://digitaltrust.vc/ssi-vs-federation-with-steve-wilson/)
+
+    -   **Description:** A podcast episode featuring Samuel Smith discussing identity.
+    -   **Target group:** General Public
+    -   **Level:** 1
+    -   **Type:** Podcast
+    -   **Category:** KERI, SAID
+
+-   **Title:** [The Architecture of Identity Systems](https://www.windley.com/archives/2020/09/the_architecture_of_identity_systems.shtml)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [The Architecture of Identity Systems](https://www.windley.com/archives/2020/09/the_architecture_of_identity_systems.shtml)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [GLEIF vLEI KERI Implementation](https://github.com/SmithSamuelM/Papers/blob/master/presentations/GLEIF_with_KERI.web.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Presentation to HyperLedger Identity WG](https://wiki.hyperledger.org/display/IWG/2021-01-20)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Nonconformist Keynote Address](https://youtu.be/L82O9nqHjRE)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Slides from Nonconformist Keynote](https://github.com/SmithSamuelM/Papers/blob/master/presentations/NonconformistKeynoteWeb20200702.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Dynamic Data Economy Webinar](https://vimeo.com/459348260)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Slides from DDE Presentation](https://github.com/SmithSamuelM/Papers/blob/master/presentations/DDEPresentation_20200910.web.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [KERI: A More Performant Ledger for Trust Identities](https://medium.com/spherity/introducing-keri-8f50ed1d8ed7)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Quantum Secure DIDs (RWOT X)](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/quantum-secure-dids.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Decentralized Identity as a Meta-platform: How Cooperation Beats Aggregation (RWOT IX)](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/CooperationBeatsAggregation.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Meta-Platforms and Cooperative Network-of-Networks Effects](https://medium.com/selfrule/meta-platforms-and-cooperative-network-of-networks-effects-6e61eb15c586)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [A DID for Everything (RWOT VII)](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/A_DID_for_everything.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Decentralized Autonomic Data (DAD) and the three R’s of Key Management (RWOT VI)](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Identity System Essentials](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Open Reputation Framework](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/open-reputation-low-level-whitepaper.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+-   **Title:** [Open Reputation](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/open-reputation-high-level-whitepaper.pdf)
+
+    -   **Description:** An in-depth look into the architecture of identity systems.
+    -   **Target group:** Researchers, Developers
+    -   **Level:** 3
+    -   **Type:** White Paper
+    -   **Category:** KERI, SAID
+
+-   **Title:** [GLEIF vLEI in Production](https://www.gleif.org/en/newsroom/press-releases/first-suite-of-vlei-services-to-enable-digital-signing-and-automated-verification-of-corporate-caller-ids)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+
+-   **Title:** [GLEIF Ecosystem Governance Framework for vLEI](https://www.gleif.org/en/newsroom/press-releases/gleif-and-trust-over-ip-foundation-publish-ecosystem-governance-framework-for-digitally-verifiable-lei)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [The Birth of the vLEI](https://www.gleif.org/en/newsroom/blog/the-birth-of-the-vlei-a-new-dawn-in-digital-id-for-legal-entities-everywhere)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [Digital Identity: It’s All About Authenticity](https://www.gleif.org/en/newsroom/gleif-podcasts/digital-identity-its-all-about-authenticity)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [GLEIF Unveils Issuance and Infrastructure Models for Verifiable LEI](https://www.gleif.org/en/newsroom/press-releases/gleif-unveils-issuance-and-infrastructure-models-for-verifiable-lei)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [GLEIF’s Digital Strategy for the LEI](https://www.gleif.org/en/lei-solutions/gleifs-digital-strategy-for-the-lei)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [GLEIF vLEI schema and credentials](https://github.com/WebOfTrust/vLEI)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [Annual Report vLEI Signing Demo](https://www.gleif.org/assets/components/xbrl-viewer/gleif-annual-report-2021/ixbrl-report-2021-viewer.html)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [Annual Report vLEI Signing Press Release](https://www.gleif.org/en/newsroom/press-releases/gleif-showcases-one-digital-id-for-every-business-globally-with-first-verifiable-lei-deployment)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [vLEIs for Cross-Border Payments](https://www.fsb.org/wp-content/uploads/P070722.pdf)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [GLEIF Newsroom](https://www.gleif.org/en/newsroom/blog/the-birth-of-the-vlei-a-new-dawn-in-digital-id-for-legal-entities-everywhere)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [Digital Identity: It’s All About Authenticity](https://www.gleif.org/en/newsroom/gleif-podcasts/digital-identity-its-all-about-authenticity)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+-   **Title:** [Simplifying legal entity identification in the digital age](https://www.helpnetsecurity.com/2022/07/08/modern-digital-identity-challenges-video/)
+    -   **Description:** An example of GLEIF vLEI implemented in a production environment.
+    -   **Target group:** Developers, Researchers
+    -   **Level:** 3
+    -   **Type:** Use Case
+    -   **Category:** GLEIF, KERI, SAID
+
+
+
+
+---
+title: Delving into the WOT Knowledge Repository
+description: Welcome to our comprehensive knowledge base – a dynamic compendium of whitepapers, slide presentations, video content, HackMD files, and much more. This repository isn't just a store of information; it's a meticulously curated and enhanced platform designed to augment your understanding of WOT and serve as your springboard for deep exploration and learning.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/intro/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/intro/index.md
+---
+
+# Delving into the WOT Knowledge Repository
+
+Welcome to our comprehensive knowledge base – a dynamic compendium of **whitepapers, slide presentations, video content, HackMD files**, and much more. This repository isn't just a store of information; it's a meticulously curated and enhanced platform designed to augment your understanding of WOT and serve as your springboard for deep exploration and learning.
+
+Our strategic decision to house copies of these resources, rather than merely linking or directing to them, is guided by several critical objectives:
+
+1.  **Adaptability** – Our user interface is powered by `React`, often necessitating resources in plain markdown or PDF formats. By hosting these resources ourselves, we ensure their full compatibility with our system.
+
+2.  **Searchability** – Our integration with `Typesense` provides a seamless and efficient search experience, enabling you to navigate effortlessly through our expansive repository.
+
+3.  **Enhanced Comprehension** – For contextual understanding, we dynamically add hyperlinks and hover texts to terms within the text, enabling immediate inline explanations and offering additional information at your fingertips.
+
+4.  **Chatbot Integration** – The information in these documents also enhances the capabilities of our sophisticated chatbot (Powered By [Chatbase.co](http://chatbase.co)), improving its ability to assist and engage with users.
+
+
+Dive into the directory structure presented in the left menu to explore our vast collection of resources. Among these, you will discover select material from [keri.one](http://keri.one), maintained by Samuel Smith – the founding father of KERI.
+
+While [keri.one](http://keri.one) is an invaluable resource in its own right, we've taken the added step of carefully cataloging and integrating these resources into our platform for your convenience. To make these resources even more accessible, we've
+
+-   meticulously labeled them with metadata,
+-   assigned user levels, and
+-   organized them into intuitive categories. This comprehensive enhancement allows for a more personalized and seamless learning experience, enabling you to delve into the depths of KERI right here on our platform.
+
+Stay, explore, and continue your journey of discovery with us. We're committed to continually refining KERISSE to enhance your learning experience.
+
+
+
+
+---
+title: All images found
+description: Total unique images found: 152
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/all-images/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/all-images/index.md
+---
+
+# All images found
+
+Total unique images found: 152
+
+Images can hold anything: photo’s, diagrams, charts etc.
+
+![Image](https://0.gravatar.com/avatar/30517076d19f96095541f692a953a7e13e47392b6316d23238c7753d14a91340?s=100&d=identicon&r=G)
+
+|  |  |
+| --- | --- |
+
+| Count | 3 |
+| Size (kB) | 21.392578125 |
+| SHA256 | 4305b8da4fcf6b5085d8631a3c6e6a8ce6154b21eeb9e124344764fcafd18b95 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-component-graph-1.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 2 |
+| Size (kB) | 185.2685546875 |
+| SHA256 | a0b9a6187cd01709a6cdd9cb118cd08aba0dfb1de5c59ea471c4620c940727a2 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-credential-graph.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 2 |
+| Size (kB) | 313.158203125 |
+| SHA256 | f2e2dcbcf1bb2a4406efb9ea532279e8508a80edf48f860c268da84ae466e750 |
+
+![Image](https://essif-lab.github.io/framework/images/essif-lab-all-models-are-wrong.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 2 |
+| Size (kB) | 56.5712890625 |
+| SHA256 | d7249a87013f73a31db69d2281da956606f9d349b20cbe14fba67b61b43fe4c4 |
+
+![Image](https://www.gleif.org/assets/build/img/icons/ui-badge.svg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://ksoeteman.nl/wp-content/uploads/2022/08/1-pUZTWzKsYeEk4c1mYH6AGQ-1024x410.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 102.3486328125 |
+| SHA256 | a172c2c1dc73fefa05259c29e52c46392b4761c2476927c2b5bf69c31830336d |
+
+![Image](https://kentbullcom.files.wordpress.com/2022/09/keri-reading-1.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 201.7958984375 |
+| SHA256 | e26bcef53869be634f8aea79cdb056cc9d30b70b56c4ef36b86a9c7e9d336d08 |
+
+![Image](https://keri.one/wp-content/uploads/2020/09/KERI-Samuel-Smith.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 185.7373046875 |
+| SHA256 | c2cc74d7bd9b3c4244ebed2f603d89248696b14f2b14a120e98488eb9bba46a0 |
+
+![Image](https://kentbullcom.files.wordpress.com/2022/06/iiw-dog-logo.png?w=80)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 7.0087890625 |
+| SHA256 | 2f981ff058c900cf1fe892acdcea40db3cbebd0edcfa501f74d6e412ae3c4961 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/05_allie_wrote.jpeg?w=300)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 17.5166015625 |
+| SHA256 | e1bf091aedea270511638bdbf1a62009eac12f825cd3e9cfe746a522deb501ad |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/13-allie-brett.jpeg?w=615)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 16.75390625 |
+| SHA256 | 988d8553d318ab3dc471b6384b74e6bd90f6e9cf7395bfcfce8f93ed56126d32 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-08_love_reply-edited.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 164.8271484375 |
+| SHA256 | 1fa7a1421f1c5d0b4894ae542a35ddadbf3e60eb17e0e4c11a1f289c76fbc1d7 |
+
+![Image](https://images.squarespace-cdn.com/content/v1/5ead4c8660689c348c80958e/1610801736283-XDH8JBZNOQXUA8LWDRMO/image-asset.jpeg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 694.953125 |
+| SHA256 | 33f836e5faefc76287ac0fdb7b02f2a93b46b0337a45c219ca566f626b0fecbf |
+
+![Image](https://images.squarespace-cdn.com/content/v1/5ead4c8660689c348c80958e/1610797386275-1SYUDPPZCL0SC4O27U32/did.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 19.322265625 |
+| SHA256 | 64dc04a525a4111a65b1cbddc65f0824496e8760bb133f78f0ee6fcd79e5bf98 |
+
+![Image](https://images.squarespace-cdn.com/content/v1/5ead4c8660689c348c80958e/1610797499404-PC102RVHHQV7BLZ1NLF7/did-+magic-box.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 33.0986328125 |
+| SHA256 | a93432b2d4de949776e9d81383b4794b1e9053d740fcb92b457e9cd238806231 |
+
+![Image](https://images.squarespace-cdn.com/content/v1/5ead4c8660689c348c80958e/1610797629508-3UP2Q5C0631FWHOY36ET/did-document.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 25.025390625 |
+| SHA256 | 1ec72b3a98907de035d82d4ddae1a1104b7a21f1dc1e3e7aff84d5f2a62c9410 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/e005a-abydos2.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 307.5322265625 |
+| SHA256 | 69c33998716359d61b3cb82acce6da36ea0f218f0b7f76934a63d084b791b486 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/10/warning-construction-sign.jpeg?w=278)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 16.265625 |
+| SHA256 | ccce3763fd014de8ec23aa2a6bec3314ccb37dd0ec38912edf89d0835f963cb2 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/iiwlogo.png?w=250)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 9.8359375 |
+| SHA256 | d1f3cd1dfb0739430150ca10702f69182e7251e52f3ad3fb9d392e405e50ee7d |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/keri-logo-1.png?w=338)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 3.630859375 |
+| SHA256 | 5240906c595550b55b695d8354971bd9efd66cb2c2dc9bd94df950b634a5f6d8 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/richard.png?w=150)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 20.7294921875 |
+| SHA256 | 7b2b073be01caced70da4856484de5048c3875bd7c0246cc1596af4a7ad6383f |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/elayne.png?w=93)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 13.453125 |
+| SHA256 | 566739a69a462a95bca73fb64bf21527c41fbea4d4fc92ad924976029f30d81f |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/ramiel.png?w=150)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 30.1005859375 |
+| SHA256 | 29e426e47dd959e757d8d74ef611ade84dc6ce7cabd313017dcf3b9ebed92b21 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/zaqiel.png?w=65)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 10.54296875 |
+| SHA256 | 99641fba4bacd537c50498e38da7c896a24c095540d12b07a01f0eceefb4fe0d |
+
+![Image](https://essif-lab.github.io/framework/images/essif-lab-functional-architecture.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 254.3447265625 |
+| SHA256 | 5e6652e79dd12e64153aab17157c98449256f266481f78fc8634b1eb23d70589 |
+
+![Image](https://essif-lab.github.io/framework/images/essif-lab-functional-architecture-infra.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 117.9140625 |
+| SHA256 | d0a969a8e48f5f9643a04faf79d27d87cb9de2bd828225676d305219db868718 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/osireion.jpeg?w=512)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 82.5654296875 |
+| SHA256 | 8ecdc7d54a4d98e02bfc5233765d1f4c122bee5bf4bfd792800189402c62f530 |
+
+![Image](https://www.gleif.org/assets/build/img/icons/ui-information.svg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 0.2529296875 |
+| SHA256 | deef65b80607537da1d4c43c05fe2aa0b19baac80a356852e8b8d837081d9f92 |
+
+![Image](https://www.gleif.org/assets/build/img/icons/ui-communication.svg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-00_foundation.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 31.1103515625 |
+| SHA256 | 680b87ece0b7f5388637b490e292a23a9b17d0ef2bcf496f7f031b0ae6181d14 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-01_witnesses.png?w=852)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 10.595703125 |
+| SHA256 | c2e1a67e774dd32231017e9a0fb1bd7f36a28e2127ecb9e88c50a7c80f6e4006 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-01_keystores-1.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 44.5625 |
+| SHA256 | 74a45c630c47990da627c5457e9c02968a97107a5c47a9096ad9df13a9d0ff9b |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-02_incept_w.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 150.52734375 |
+| SHA256 | 7471bb095c96f349c5ab0cc6e8ae5a8d622525bcb96f2a6ff8dd43b98819a052 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-04_allie_oobi.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 170.212890625 |
+| SHA256 | 785776aa90e0fa3caf81a5b7fe573c59c7a4307e540d56552e0fa72a34de3acb |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-03_brett_oobis.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 189.0078125 |
+| SHA256 | 9a119f085dd1a1241668631de4be1326f373cfb9c2ecb1c77503b12030df43dd |
+
+![Image](https://www.gleif.org/assets/build/img/icons/ui-reload.svg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://essif-lab.github.io/framework/images/essif-lab-high-level-trx-overview.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 209.623046875 |
+| SHA256 | da5deab85447fea2d4ba5670899c3e5d3e9a38e4449f9be187efe8c257c7d956 |
+
+![Image](https://essif-lab.github.io/framework/images/essif-lab-high-level-trx-negotiation.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 206.6826171875 |
+| SHA256 | 0706ef04df818b3be21e7234985654180670512e21f8932444486589cc24deb3 |
+
+![Image](https://essif-lab.github.io/framework/images/generic-verification-with-ssi-service.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 52.5830078125 |
+| SHA256 | c28d304e8b25e86fc0f8a61ca6639f53ee24ea058ae26dc149bb4c7d647c1101 |
+
+![Image](https://essif-lab.github.io/framework/images/generic-issuing-with-ssi-service.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 67.9130859375 |
+| SHA256 | 4f6c1136e685eebcee6a076eb88c0999b56a5fbd200c39d247735d88dda81042 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-06_allie_challenge-1.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 207.41015625 |
+| SHA256 | f8d5e4a15939dda70ebef974b6d5321b1f4b62cce105e0f03a87ce6595bd4798 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-05_challenges-1.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 218.2568359375 |
+| SHA256 | 663f59fe9a10d6735b91dc78b67001389fa7aa69a5075b74c37a3ae3e8d22e6c |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-07_love_letter_w.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 230.4248046875 |
+| SHA256 | b8740d55744e81390cfbd373becfab8771b72ef4d047f8f4fc13290c27ace443 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/hn-08_love_reply-1.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 239.8271484375 |
+| SHA256 | 5fbdabcd2a10688c251c948dc4330154d46d7ed85378dc671cf6d43dbec14e21 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/01/14-couple-in-love.jpeg?w=615)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 24.2783203125 |
+| SHA256 | 8eee9bfb6626922acca4e629fa8d27354ad20cf1eca80cfcbb24aee6c5bf2e1c |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-whattowhom-thj.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 64.880859375 |
+| SHA256 | 3a7062c46e684f4b7f0d4a4cd9db799ddc046251647f20374954b04816b29e7e |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-whattowhom-jmr.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 69.40625 |
+| SHA256 | af351762e25a90fa7e207dfef2f24d91b285b023f28970d5f69e8ad10c73707b |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-whattowhom-jm.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 61.5439453125 |
+| SHA256 | 42cee553ad36c3ecc673a386f8e0dd0e9bc65384d2d32ef1f0ada702fbc4ee95 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-whattowhom-jc.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 64.2041015625 |
+| SHA256 | 022d1432e6323874c39999630479354beaed9fea0cd89ddae6e86b78f9132937 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-whattowhom-present.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 78.21875 |
+| SHA256 | 5abb0d0de6742d9609bb93d629d3ebf783647b8033128e7067272e37f935d8fa |
+
+![Image](https://www.gleif.org/about/gleif-services/service-reports/gleif-service-report-january-2024/2024-02-14_gleif_service_report_v1.0.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-services/iso-20000-certification/itms_707855.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://essif-lab.github.io/framework/images/essif-lab-funcarch-ssi-basic-capabilities.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 872.64453125 |
+| SHA256 | 16914dc96bffd86f5ada117ef6ad36e298ae6a3923f503058091a736a424b550 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/thj-schema-collapsed-1.png?w=601)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 45.6416015625 |
+| SHA256 | bcda6391bafbd0c80ef2f4d5e4f300637eeb51bad82fd01ea94ffccbb33f6486 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/thj-properties-collapsed.png?w=570)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 23.4912109375 |
+| SHA256 | c7905306b6845995c0530bbacc2552c424178c2d5fb3c156624ad1f0eefabfb1 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-3.png?w=584)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 38.1337890625 |
+| SHA256 | 5dad3c0a090b99656b8d71eae5cf120c0fcef3729e240dc596573d6a9dc17f19 |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/carboncall.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/edm-council-rgb.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/ewc-logo-1-alt.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/eurofiling-logo.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/icc-full-color.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 39.4873046875 |
+| SHA256 | d97bf5a85ee6e133f5387c1eb857a3a7557455a401b12115cadde11fa7748d90 |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/icc_germany_black_rgb_72dpi.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/iso-logo-registered-trademark.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/mef_logo_rgb_black.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/owf.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 17.900390625 |
+| SHA256 | 1603cb3af02064568ddfc641b5d96284902f54579dccd9c1aee199d916bba2dd |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/osc-logo_version2_cmyk_full-color.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/trust-over-ip-foundation.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/w3c-member.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://essif-lab.github.io/framework/images/essif-lab-funcarch-ssi-aware.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1847.4462890625 |
+| SHA256 | ec331c417752d8ac70fa02eca0f50b18c2b7646377959d12a9246a7267a97448 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-12.png?w=595)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 48.625 |
+| SHA256 | b3c660c7f9bd8e51d887ac7e7a81032850abf5edf9c8294cef501f148d413576 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-13.png?w=609)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 27.380859375 |
+| SHA256 | a7a29f161cd5752658fd43bfcc567522d37237c824058d2a2ac41347706444c7 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-14.png?w=744)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 37.0439453125 |
+| SHA256 | ca10b6faae33fc9125bd8eec3d4b153bb10624af5acb57359c04168ae6bf0d79 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-15.png?w=639)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 42.1708984375 |
+| SHA256 | 2ba76ad6d80dea763b8b84fc49e43f41d1d318c90700f4ffc9ee7c81be9d979b |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-16.png?w=743)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 37.09765625 |
+| SHA256 | dc0e8ca1e83676b78216c869f8eced254904b958b76152b727f1a8558a83f743 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-17.png?w=649)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 35.326171875 |
+| SHA256 | e915e18e214b1d3e4f5d5c31bd6506b0c735a06ef09ab171562f4fcfebe2f383 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-18.png?w=740)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 62.45703125 |
+| SHA256 | 8d5be469d0d957fabc39555e1e34f8e9523f068d897f754b30843c80b0735bdf |
+
+![Image](https://www.gleif.org/about/gleif-engagement/organization-and-committee-engagement/xbrl-member-logo-final.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/bloomberg_logo.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/bvd_logo_final_rgb_artwork.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/swiftref_logo_powered_by_swift.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/alveo-rgb_colour.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/tr_tac_h_lg_rgb_ps.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/regtech-logo.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/rimes-logo-blue-cmyk.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/six_logo.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/goldensource.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/rdu-logo_black.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 55.48046875 |
+| SHA256 | 1fb2f95f2041cd4825a7e53908f5c3c2268937d06762dd3e67f06d1cd5be2da9 |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/spg_bar_rgb_pos.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/ma_rgb_blue.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/kompany_logo.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/infront_logo_color.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/monetago_logo.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/edi-logo-red_blue.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/regtek-beijing-technologies-co.-ltd.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/open_corporates_logo.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/surecomp-rgb-master-logos-text-enlarged-01.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/aegis-logo.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/rubix-logo.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 36.3984375 |
+| SHA256 | 4817fec8224e52fd2cb99bdca6914a43e98101440eaeb8e0b32c43f86800c4dd |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/encompass-logo-tagline-_full-colour.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/diligencia_high_res.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/crif.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/numeraclelogo-purple.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/element22logo_black@3x.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/quichacha_logo.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/nth-exception-logo.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-component-graph.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 185.2685546875 |
+| SHA256 | a0b9a6187cd01709a6cdd9cb118cd08aba0dfb1de5c59ea471c4620c940727a2 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-component-graph-caching-server.png?w=975)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 19.232421875 |
+| SHA256 | 6ab6b401cf718a1b86ce3c7cfa80c365830c5d197eda4454b4d36f73fa544591 |
+
+![Image](https://www.gleif.org/media/pages/about/management/stephan-wolf/4e07e6e0ff-1708953130/dsc-2239-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/sneha-malschok/a0cc91a1c9-1708953130/dsc-2424-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/annette-both/de561618f4-1708953130/dsc-2362-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/antonia-christifordi/6e2611ca3a-1708953130/received-568906626932412-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 0.2919921875 |
+| SHA256 | 5764fed31b533e202f88d735a531f70a4ee3f66bb856afa4277872a758e6b578 |
+
+![Image](https://www.gleif.org/media/pages/about/management/ines-gensinger/af82937558-1708953130/dsc-2162-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/karla-mckenna/729a57f616-1708953130/karlam-feb2023-14-gleif-green-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/anja-lechner/9a7718ed21-1708953130/dsc-2382-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/zornitsa-manolova/582e8ea53e-1708953130/dsc-2314-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/hiroshi-nakatake/6b1941b825-1708953130/hiroshi-nakatake-gleif-green-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/clare-rowley/fb85620ed6-1708953130/clare-rowley-gleif-green-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/christoph-schneider/d05addca4f-1708953130/dsc-2214-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 0.2919921875 |
+| SHA256 | 5764fed31b533e202f88d735a531f70a4ee3f66bb856afa4277872a758e6b578 |
+
+![Image](https://www.gleif.org/media/pages/about/management/sven-schumacher/fd07fa6f46-1708953130/dsc-2450-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/management/xue-tan/117d9bf731-1708953130/dsc-2288-gleif-look-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 0.2919921875 |
+| SHA256 | 5764fed31b533e202f88d735a531f70a4ee3f66bb856afa4277872a758e6b578 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-component-graph-witconfig.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 106.1982421875 |
+| SHA256 | 608e37e6006952a6ba0e92dcd637a201d5396eccc2da82d8e92bdb9f2cec314b |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-4.png?w=137)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.5126953125 |
+| SHA256 | ab763ea6a036150947d813636ffec8edb479b692628402463e4712d4ce1b2556 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-component-graph-witkeystores.png?w=1019)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 91.408203125 |
+| SHA256 | 881a372a39d42e7566bf681639467d3b289303cab29d7153f7fb61f080455abd |
+
+![Image](https://www.gleif.org/about/governance/benefits-of-global-lei-adoption.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/governance/financial-stability-board-fsb/gleif-fsb.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/gleif-roc.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/t-dessa-glasser/7cac4ff0af-1708953131/d-glasser-headshot-color-11-17-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/vivienne-artz/d38c7ac4c5-1708953131/photo-vivienne-arzt-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/amy-a-kabia/3c738daccf-1708953131/amy-kabia-headshot-2020-05-25-2-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/folarin-alayande-ph-d/a4e1018f2b-1708953131/photo-folarin-alayande-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 0.2919921875 |
+| SHA256 | 5764fed31b533e202f88d735a531f70a4ee3f66bb856afa4277872a758e6b578 |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/hany-choueiri/b4c7e0b9c0-1708953131/hany-choueiri-colour-photo-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/changmin-chun/1c922e964b-1708953131/180904-changmin-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/jacques-demael/dcbc8f01b6-1708953131/photo-jacques-demael-2021-final-2-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-component-graph-ctlr-net.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 77.9443359375 |
+| SHA256 | 8f9e3f004cbf151e7acc484510914fdae4babaa0a85b76ad276e5b59af25d66c |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/salil-kumar-jha/f01b880a31-1708953131/300-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/angela-kyerematen-jimoh/b8398334d4-1708953132/photo-angela-kyerematen-jimoh-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/kaoru-mochizuki/328720faf8-1708953131/photo-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/luis-felipe-salin-monterio/3ee34a1767-1708953131/photo-luis-monterio-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/javier-santamaria/ac43c4152f-1708953131/javier-santamaria-photograph-2-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/gabriela-styf-sjoman/8f90d6a475-1708953131/gabriel-styf-200x-q88.png)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/katia-walsh/74c0073097-1708953131/katia-walsh-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/zaiyue-xu/3039cd0fd0-1708953131/photo-zaiyue-xu-berab-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/board-of-directors/nicola-dearden/1bd081d885-1708953131/photo-nicola-dearden-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/roc-observers/mike-willis/e66144aff8-1708953132/mike-willis-photo-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/roc-observers/emomotimi-agama/80fd6ffd87-1708953132/emomotimi-agama-photo-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 166.03515625 |
+| SHA256 | 30c52c8731c02f7b386afea028db3f2af78aaa2ec867436e2c317f9c7452287e |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/image-5.png?w=589)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 21.4755859375 |
+| SHA256 | 8c0f9564e70e4f8e1b89fbb06846d621584bb27acfe6a551f64be170eafc9f50 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-agent.png?w=900)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 4.572265625 |
+| SHA256 | a9480632f10b4d7ef8289add96e698ebbd7875b0c33c6ca5360c13ebbace4b09 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-agents.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 88.515625 |
+| SHA256 | 717ed2aa003e4377fa41b103142db43996a5ec85d0a6512ee64dc5fcce080990 |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-component-graph-ctlr-keystores-1.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 48.6640625 |
+| SHA256 | f44ed593b64dc87bdb71d9e0acd9f044e90606dadd0aaa116de39e91809f414d |
+
+![Image](https://www.gleif.org/media/pages/about/governance/roc-observers/fabrizio-planta/a49a952442-1708953132/fabrizio-planta-photo-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://www.gleif.org/media/pages/about/governance/roc-observers/fuyu-yang/1e2693348c-1708953132/fuyu-yang-photo-200x-q88.jpg)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 1.33984375 |
+| SHA256 | 4ee1fa62b35f542ba5d3239e3c36983b3e25831a80e891bc97f9f319cf777aba |
+
+![Image](https://kentbullcom.files.wordpress.com/2023/03/abydos-athena-component-graph-ctlr-incept.png?w=1024)
+
+|  |  |
+| --- | --- |
+
+| Count | 1 |
+| Size (kB) | 58.578125 |
+| SHA256 | 48e4e05230c911d97d3192a1e00adf037aec77a675be6cee53c4a1029f20a7c1 |
+
+
+
+
+---
+title: overview-and-context
+description: Overview and context
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/overview/overview-and-context/index
+  md: https://weboftrust.github.io/keridoc/docs/overview/overview-and-context/index.md
+---
+
+# overview-and-context
+
+# Overview and context
+
+ Sort by Key Sort by Type Sort by Level Sort by Cat\_CESR
+
+| Key | Type | Form | ToIP\_Fkey | Philvid\_Fkey | Term | text | link | Philvid\_start | level | Cat\_PTEL | Cat\_IPEX | Cat\_OOBI | Cat\_CESR | Cat\_ACDC | Cat\_KERI | Cat\_SAID | Cat\_GLEIF | Shortened version | @dropdown | Shortened version static copy |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+
+| 1 | K | n | ACDC |  | ACDC | type of data as issuance concretely defined by the authentic-chained-data-container specification | [Link](https://github.com/weboftrust/WOT-terms/wiki/ACDC) | Link | 3 |  |  |  | #REF! | 1 |  |  |  | #NAME? |  | Data type defined by Authentic Chained Data Container Spec. |
+| 2 | K | n | ADC |  | ADC | an authentic data container conveys data that allows the authenticity of its content to be proved. | [Link](https://github.com/weboftrust/WOT-terms/wiki/ADC) | Link | 3 |  |  |  | #REF! | 1 |  |  |  |  |  | An authentic data container proves the authenticity of its content. |
+| 3 | S | n | AID |  | AID | an identifier that is self-certifying and self-sovereign. | [Link](https://github.com/weboftrust/WOT-terms/wiki/AID) | Link | 3 |  |  |  | #REF! | 1 |  | 1 |  |  |  | A self-certifying and self-sovereign identifier. |
+| 4 | S | n | AN |  | AN | a namespace that is truly self-sovereign. | [Link](https://github.com/weboftrust/WOT-terms/wiki/AN) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | A self-sovereign namespace. |
+| 5 | K | r | APC |  | APC | authentic provenance chain; evidence of data to be verfiably tracked back to its origin | [Link](https://github.com/weboftrust/WOT-terms/wiki/APC) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Verified provenance chain; evidence of data can be tracked back to its origin. |
+| 6 | K | r | BADA |  | BADA | best available data acceptance, mechanism that provides a degree of replay attack protection | [Link](https://github.com/weboftrust/WOT-terms/wiki/BADA) | Link | 3 |  |  | 1 | #REF! |  |  |  |  |  |  | best data acceptance mechanism with replay attack protection. |
+| 7 | G | n | BFT |  | BFT | Byzantine Fault Tollerance | [Link](https://github.com/weboftrust/WOT-terms/wiki/BFT) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Byzantine Fault Tolerance |
+| 8 | K | n | CESR |  | CESR | composable event streaming representation | [Link](https://github.com/weboftrust/WOT-terms/wiki/CESR) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Event streaming representation |
+| 9 | G | n | CT |  | CT | certificate transparency; internet security standard for digital certificates | [Link](https://github.com/weboftrust/WOT-terms/wiki/CT) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Certificate Transparency is an internet security standard for digital certificates. |
+| 10 | G | n | DAG |  | DAG | directed acyclic graph, mathematical construct, no cycles in it | [Link](https://github.com/weboftrust/WOT-terms/wiki/DAG) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Directed acyclic graph is a mathematical construct without any cycles. |
+| 11 | K | n | DEL |  | DEL | duplicitous event log | [Link](https://github.com/weboftrust/WOT-terms/wiki/DEL) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Event log |
+| 12 | G | n | DHT |  | DHT | distributed hash table | [Link](https://github.com/weboftrust/WOT-terms/wiki/DHT) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | distributed hash table |
+| 13 | S | n | DKMI |  | DKMI | decentralized key management infrastructure; ensure no single third-party can compromise the integrity and security of a system | [Link](https://github.com/weboftrust/WOT-terms/wiki/DKMI) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | decentralized key management system; prevents any single third-party from compromising system integrity and security. |
+| 14 | S | n | DPKI |  | DPKI | decentralized public key infrastructure; ensure no single third-party can compromise the integrity and security of a system | [Link](https://github.com/weboftrust/WOT-terms/wiki/DPKI) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Decentralized PKI; guarantee no third-party compromise system integrity and security. |
+| 15 | G | n | GPG |  | GPG | Gnu Privacy Guard, a free-software replacement for Symantec's PGP cryptographic software suite | [Link](https://github.com/weboftrust/WOT-terms/wiki/GPG) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Gnu Privacy Guard is a free-software alternative to Symantec's PGP suite. |
+| 16 | G | n | I-O |  | I-O | Input / Output | [Link](https://github.com/weboftrust/WOT-terms/wiki/I-O) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Input/Output |
+| 17 | G | n | IANA |  | IANA | Internet assigned numbers authority; oversees the allocation of IP addresses to internet service providers (ISPs) | [Link](https://github.com/weboftrust/WOT-terms/wiki/IANA) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | The Internet Assigned Numbers Authority (IANA) oversees IP address allocation to ISPs. |
+| 18 | K | r | IPEX |  | IPEX | issuance and presentation exchange protocol; mechanism for the issuance and presentation of ACDCs | [Link](https://github.com/weboftrust/WOT-terms/wiki/IPEX) | Link | 3 |  | 1 |  | #REF! |  | 1 |  |  |  |  | ACDC issuance and presentation protocol; mechanism for issuing and presenting ACDCs. |
+| 19 | G | r | JOSE |  | JOSE | Javascript object signing and encryption; method to securely transfer claims between parties | [Link](https://github.com/weboftrust/WOT-terms/wiki/JOSE) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | JavaScript object signing and encryption is a secure method for transferring claims between parties. |
+| 20 | K | n | KA2CE |  | KA2CE | KERI agreement algorithm for control establishment | [Link](https://github.com/weboftrust/WOT-terms/wiki/KA2CE) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | KERI control establishment algorithm |
+| 21 | K | n | KAACE |  | KAACE | KERI agreement algorithm for control establishment | [Link](https://github.com/weboftrust/WOT-terms/wiki/KAACE) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | KERI control establishment algorithm |
+| 22 | K | n | KEL |  | KEL | Key Event Log | [Link](https://github.com/weboftrust/WOT-terms/wiki/KEL) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Event Log |
+| 23 | K | n | KERI |  | KERI | Key Event Receipt Infrastructure | [Link](https://github.com/weboftrust/WOT-terms/wiki/KERI) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Receipt Infrastructure |
+| 24 | K | n | KERL |  | KERL | Key Event Receipt Log | [Link](https://github.com/weboftrust/WOT-terms/wiki/KERL) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Event Receipt Log |
+| 25 | K | n | KID |  | KID | KERI improvement doc | [Link](https://github.com/weboftrust/WOT-terms/wiki/KID) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Keri Improvement Document |
+| 26 | G | n | LoA |  | LoA | any time a judgement is not a binary Yes or No, you have levels of assurance | [Link](https://github.com/weboftrust/WOT-terms/wiki/LoA) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Whenever a judgement is not simply a "Yes" or "No," there are varying levels of assurance. |
+| 27 | G | n | LoC |  | LoC | Locus of Control | [Link](https://github.com/weboftrust/WOT-terms/wiki/LoC) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Locus of Control refers to the extent to which individuals believe they have control over events in their lives. |
+| 28 | G | n | NFT |  | NFT | Non-fungible token | [Link](https://github.com/weboftrust/WOT-terms/wiki/NFT) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Non-fungible token |
+| 29 | K | v | OOBI |  | OOBI | Out of band introduction | [Link](https://github.com/weboftrust/WOT-terms/wiki/OOBI) | Link | 3 |  |  | 1 | #REF! |  |  |  |  |  |  | Introduction |
+| 30 | G | r | P2P |  | P2P | Peer to peer | [Link](https://github.com/weboftrust/WOT-terms/wiki/P2P) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Peer-to-peer |
+| 31 | G | r | PGP |  | PGP | Pretty Good Privacy | [Link](https://github.com/weboftrust/WOT-terms/wiki/PGP) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Pretty Good Privacy (PGP) |
+| 32 | G | n | PKI |  | PKI | Public Key Infrastructure | [Link](https://github.com/weboftrust/WOT-terms/wiki/PKI) | Link | 2 |  |  |  | #REF! | 1 | 1 | 1 |  |  |  | Public Key Infrastructure (PKI) |
+| 33 | K | n | PTEL |  | PTEL | is a public transaction event log that can be used to securely track state anchored to a KEL | [Link](https://github.com/weboftrust/WOT-terms/wiki/PTEL) | Link | 3 | 1 |  |  | #REF! |  |  |  |  |  |  | is a secure public event log for tracking state anchored to a KEL. |
+| 34 | K | n | SAD |  | SAD | Self-Adressing Data | [Link](https://github.com/weboftrust/WOT-terms/wiki/SAD) | Link | 3 |  |  |  | #REF! | 1 |  |  |  |  |  | Self-Addressing Data. |
+| 35 | K | n | SAID |  | SAID | Self-Adressing Identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/SAID) | Link | 3 |  |  |  | #REF! | 1 |  | 1 |  |  |  | Self-Addressing Identifier |
+| 36 | G | n | SATP |  | SATP | secure asset transfer protocol; IETF protocol (and working group) in the making (as of mid 2022) for moving assets between blockchains | [Link](https://github.com/weboftrust/WOT-terms/wiki/SATP) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Secure asset transfer protocol: IETF protocol (and working group) currently being developed (mid-2022) to transfer assets between blockchains. |
+| 37 | S | v | SCID |  | SCID | Self-Certifying Identifier, cryptographically binds an identifier to a public and private key pair. | [Link](https://github.com/weboftrust/WOT-terms/wiki/SCID) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | A Self-Certifying Identifier cryptographically binds an identifier to a key pair. |
+| 38 | S | r | SSI |  | SSI | Self-Sovereign Identity | [Link](https://github.com/weboftrust/WOT-terms/wiki/SSI) | Link | 1 |  |  |  | #REF! | 1 | 1 |  | 1 |  |  | Self-Sovereign Identity (SSI) |
+| 39 | G | n | TCP |  | TCP | transmission control protocol, one of the main protocols of the Internet protocol suite. | [Link](https://github.com/weboftrust/WOT-terms/wiki/TCP) | Link | 2 |  |  | 1 | #REF! | 1 | 1 |  |  |  |  | Transmission Control Protocol (TCP) is a key protocol in the Internet protocol suite. |
+| 40 | K | n | TEL |  | TEL | provides a cryptographic proof of registry state by reference to the corresponding controlling KEL. | [Link](https://github.com/weboftrust/WOT-terms/wiki/TEL) | Link | 3 | 1 |  |  | #REF! | 1 | 1 |  |  |  |  | provides cryptographic proof of registry state via the corresponding controlling KEL. |
+| 41 | G | r | UI |  | UI | the space where interactions between humans and machines occur. | [Link](https://github.com/weboftrust/WOT-terms/wiki/UI) | Link | 1 | 1 | 1 | 1 | #REF! | 1 | 1 | 1 | 1 |  |  | The area where humans and machines interact. |
+| 42 | G | n | URL |  | URL | uniform resource locator or 'web address', is a reference to a web resource that specifies its location on a computer network | [Link](https://github.com/weboftrust/WOT-terms/wiki/URL) | Link | 1 | 1 | 1 | 1 | #REF! | 1 | 1 | 1 | 1 |  |  | A URL, known as a web address, is a reference to a web resource that specifies its location on a computer network. |
+| 43 | K | n | VC-TEL |  | VC-TEL | virtual credential transaction event log | [Link](https://github.com/weboftrust/WOT-terms/wiki/VC-TEL) | Link | 3 | 1 |  |  | #REF! |  |  |  |  |  |  | Virtual credential transaction log |
+| 44 | G | n | VC |  | VC | virtual credential | [Link](https://github.com/weboftrust/WOT-terms/wiki/VC) | Link | 1 |  |  |  | #REF! | 1 |  |  | 1 |  |  | Virtual credential |
+| 45 | G | n | VDS |  | VDS | verifiable data structure | [Link](https://github.com/weboftrust/WOT-terms/wiki/VDS) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Verifiable data structure. |
+| 46 | G | v | agency |  | agency | a service that a representative for an identity (agent) offers | [Link](https://github.com/weboftrust/WOT-terms/wiki/agency) | Link | 2 |  |  |  | #REF! | 1 |  | 1 | 1 |  |  | A service offered by an identity representative (agent). |
+| 47 | K | v | ambient-verifiability |  | ambient-verifiability | Verifiable by anyone, anywhere, at anytime. | [Link](https://github.com/weboftrust/WOT-terms/wiki/ambient-verifiability) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Verifiable by anyone, anywhere, at any time. |
+| 48 | G | n | append-only-event-logs |  | append-only-event-logs | is a property of computer data storage such that new data can be appended to the storage, but where existing data is immutable | [Link](https://github.com/weboftrust/WOT-terms/wiki/append-only-event-logs) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Mutable data storage allows new data to be added, but existing data cannot be changed. |
+| 49 | K | n | authentic-chained-data-container |  | authentic-chained-data-container | data structure that proves digital data consistency and authenticity in one go test 1 | [Link](https://github.com/weboftrust/WOT-terms/wiki/authentic-chained-data-container) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | A data structure that ensures both the consistency and authenticity of digital data. |
+| 50 | K | n | authentic-data-container |  | authentic-data-container | data structure that proves digital data consistency and authenticity in one go test 2 | [Link](https://github.com/weboftrust/WOT-terms/wiki/authentic-data-container) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | A data structure that ensures both the consistency and authenticity of digital data. |
+| 51 | K | v | authentic-provenance-chain |  | authentic-provenance-chain | evidence of data to be tracked back to its origin in an verifiable way | [Link](https://github.com/weboftrust/WOT-terms/wiki/authentic-provenance-chain) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Evidence of data can be tracked back to its origin in a verifiable manner. |
+| 52 | G | a | authenticity |  | authenticity | the quality of having an objectively verifiable origin | [Link](https://github.com/weboftrust/WOT-terms/wiki/authenticity) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | The quality of having an objectively verifiable origin. |
+| 53 | G | n | autonomic-computing-systems |  | autonomic-computing-systems | self-managing computing systems using algorithmic governance | [Link](https://github.com/weboftrust/WOT-terms/wiki/autonomic-computing-systems) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Self-managing computing systems with algorithmic governance. |
+| 54 | S | n | autonomic-identity-system |  | autonomic-identity-system | identity systems where you can verify (establishment of) the authenticity all the way back to the root-of-trust | [Link](https://github.com/weboftrust/WOT-terms/wiki/autonomic-identity-system) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Identity systems can verify authenticity all the way back to the root of trust. |
+| 55 | S | n | autonomic-namespace |  | autonomic-namespace | namespace that is self-certifying and hence self-administrating, is truly self-sovereign | [Link](https://github.com/weboftrust/WOT-terms/wiki/autonomic-namespace) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | A self-certifying and self-administrating namespace is truly self-sovereign. |
+| 56 | K | n | best-available-data-acceptance-mechanism |  | best-available-data-acceptance-mechanism | BADA, mechanism that provides a degree of replay attack protection | [Link](https://github.com/weboftrust/WOT-terms/wiki/best-available-data-acceptance-mechanism) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | BADA is a mechanism that offers replay attack protection. |
+| 57 | S | v | binding |  | binding | the association of data or an identifier with another identifier or a subject (a person, organization or machine) | [Link](https://github.com/weboftrust/WOT-terms/wiki/binding) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Associating data or an identifier with another identifier or subject (person, organization, or machine). |
+| 58 | G | r | byzantine-agreement |  | byzantine-agreement | is Byzantine fault tolerance of distributed computing system coming to consensus despite arbitrary behavior from a fraction of the network | [Link](https://github.com/weboftrust/WOT-terms/wiki/byzantine-agreement) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Byzantine fault tolerance allows distributed computing systems to reach consensus despite arbitrary behavior from some network participants. |
+| 59 | G | n | byzantine-fault-tolerance |  | byzantine-fault-tolerance | is a condition of a (distributed) computer system, where components may fail and there is imperfect information on whether a component has failed | [Link](https://github.com/weboftrust/WOT-terms/wiki/byzantine-fault-tolerance) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Distributed computer systems can experience failures and uncertainty regarding component statuses. |
+| 60 | G | n | certificate-transparency |  | certificate-transparency | internet security standard and framework for digital certificates | [Link](https://github.com/weboftrust/WOT-terms/wiki/certificate-transparency) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Internet security standard and framework for digital certificates. |
+| 61 | K | n | cesr-proof-signatures |  | cesr-proof-signatures | An extension to CESR that provides signature attachments | [Link](https://github.com/weboftrust/WOT-terms/wiki/cesr-proof-signatures) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 62 | G | v | chain-of-custody |  | chain-of-custody | legal chronological documentation or paper trail that records the sequence of custody of materials | [Link](https://github.com/weboftrust/WOT-terms/wiki/chain-of-custody) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | A legal record that documents the sequence of material custody. |
+| 63 | G | v | claim |  | claim | assertion of the truth of something, typically one which is disputed or in doubt | [Link](https://github.com/weboftrust/WOT-terms/wiki/claim) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | assertion of disputed or doubtful truth. |
+| 64 | K | n | composable-event-streaming-representation |  | composable-event-streaming-representation | Also 'CESR'. An encoding scheme of interchangeable textual and binary streaming applications of attached crypto material. | [Link](https://github.com/weboftrust/WOT-terms/wiki/composable-event-streaming-representation) | Link | 3 |  |  |  | #REF! |  |  |  |  | #NAME? |  | NO INPUT |
+| 65 | G | v | consensus-mechanism |  | consensus-mechanism | How groups of entitities come to decisions. | [Link](https://github.com/weboftrust/WOT-terms/wiki/consensus-mechanism) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 66 | G | n | content-addressable-hash |  | content-addressable-hash | Finding content by a hash of this content, generated by a one-way hash function applied to the content. | [Link](https://github.com/weboftrust/WOT-terms/wiki/content-addressable-hash) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 67 | S | r | control-authority |  | control-authority | Is 'who controls what?' and that is the primary factor in determining the basis for trust in them | [Link](https://github.com/weboftrust/WOT-terms/wiki/control-authority) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 68 | G | n | controller |  | controller | the entity that has the ability to make changes to an identity, cryptocurrency or verifiable credential. | [Link](https://github.com/weboftrust/WOT-terms/wiki/controller) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | The entity capable of modifying an identity, cryptocurrency, or verifiable credential. |
+| 69 | G | v | correlation |  | correlation | an identifier used to indicate that external parties have observed how wallet contents are related. | [Link](https://github.com/weboftrust/WOT-terms/wiki/correlation) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | An identifier indicating external parties have observed the relationship between wallet contents. |
+| 70 | G | n | credential |  | credential | evidence of authority, status, rights, entitlement to privileges, or the like. | [Link](https://github.com/weboftrust/WOT-terms/wiki/credential) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Evidence of authority, status, rights, entitlements, or similar privileges. |
+| 71 | G | n | crypto-libraries |  | crypto-libraries | deal with cryptography algorithms and have API function calls to each of the supported features | [Link](https://github.com/weboftrust/WOT-terms/wiki/crypto-libraries) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | This deals with cryptography algorithms and has API functions for each supported feature. |
+| 72 | G | n | cryptocurrency |  | cryptocurrency | a digital asset designed to work as a medium of exchange wherein individual coin ownership records are stored in a digital ledger. | [Link](https://github.com/weboftrust/WOT-terms/wiki/cryptocurrency) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | A digital asset that serves as a medium of exchange, with individual coin ownership records stored in a digital ledger. |
+| 73 | G | n | cryptographic-commitment-scheme |  | cryptographic-commitment-scheme | is a cryptographic primitive that allows one to commit to a value while keeping it hidden to others; you can reveal the committed value later. | [Link](https://github.com/weboftrust/WOT-terms/wiki/cryptographic-commitment-scheme) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 74 | G | n | cryptographic-strength |  | cryptographic-strength | used to describe greater resistance to attack of an encryption algorithm in comparison to some other (which is thus cryptographically weaker) | [Link](https://github.com/weboftrust/WOT-terms/wiki/cryptographic-strength) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 75 | G | n | cryptonym |  | cryptonym | a code word or name used to refer to another name, word, project, or person | [Link](https://github.com/weboftrust/WOT-terms/wiki/cryptonym) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 76 | S | n | decentralized-identity |  | decentralized-identity | is a technology that uses cryptography to allow individuals to create and control their own digital identifiers | [Link](https://github.com/weboftrust/WOT-terms/wiki/decentralized-identity) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 77 | G | n | decentralized-key-management-infrastructure |  | decentralized-key-management-infrastructure | an infrastructure ensure that no single third-party can compromise the integrity and security of the system as as whole. | [Link](https://github.com/weboftrust/WOT-terms/wiki/decentralized-key-management-infrastructure) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 78 | S | n | delegated-identifier |  | delegated-identifier | Matches the act of delagation with the appropriate digital twin. | [Link](https://github.com/weboftrust/WOT-terms/wiki/delegated-identifier) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 79 | G | n | digital-signature |  | digital-signature | a mathematical scheme for verifying the authenticity of digital messages or documents | [Link](https://github.com/weboftrust/WOT-terms/wiki/digital-signature) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Mathematical scheme to verify authenticity of digital messages or documents. |
+| 80 | G | n | directed-acyclic-graph |  | directed-acyclic-graph | DAG, a mathematical construct, particularly graph theory, the acyclic property stems from a directed graph with no cycles | [Link](https://github.com/weboftrust/WOT-terms/wiki/directed-acyclic-graph) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | A DAG, a mathematical construct in graph theory, is a directed graph with no cycles, giving it the acyclic property. |
+| 81 | G | n | distributed-hash-table |  | distributed-hash-table | any participant can retrieve the value associated with a given key | [Link](https://github.com/weboftrust/WOT-terms/wiki/distributed-hash-table) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Any participant can get the value for a specific key. |
+| 82 | K | n | dual-text-binary-encoding-format |  | dual-text-binary-encoding-format | An encoding format that allows for both text and binary encoding format, which is fully interchangeable | [Link](https://github.com/weboftrust/WOT-terms/wiki/dual-text-binary-encoding-format) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 83 | K | n | duplicitous-event-log |  | duplicitous-event-log | record of inconsistent event messages produced by a given controller or witness | [Link](https://github.com/weboftrust/WOT-terms/wiki/duplicitous-event-log) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | log of inconsistent event messages from a controller or witness |
+| 84 | G | n | duplicity |  | duplicity | external inconsistency; which stems from publication of two or more versions of a (by itself consistent) key event log | [Link](https://github.com/weboftrust/WOT-terms/wiki/duplicity) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | External inconsistency occurs when multiple versions of a key event log are published, even though the log itself is consistent. |
+| 85 | G | v | electronic-signature |  | electronic-signature |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/electronic-signature) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 86 | G | a | end-verifiable |  | end-verifiable |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/end-verifiable) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 87 | G | v | entropy |  | entropy |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/entropy) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 88 | G | a | ephemeral |  | ephemeral |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/ephemeral) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 89 | K | a | first-seen |  | first-seen |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/first-seen) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 90 | G | n | gnu-privacy-guard |  | gnu-privacy-guard | GPG is a free-software replacement for Symantec's PGP cryptographic software suite | [Link](https://github.com/weboftrust/WOT-terms/wiki/gnu-privacy-guard) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | GPG replaces Symantec's PGP software suite for free. |
+| 91 | K | n | habery |  | habery |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/habery) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 92 | G | r | hierarchical-asynchronous-coroutines-and-input-output |  | hierarchical-asynchronous-coroutines-and-input-output |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/hierarchical-asynchronous-coroutines-and-input-output) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 93 | G | n | identifier |  | identifier | Something to uniquely identify (public) identities; pointing to something or someone else. | [Link](https://github.com/weboftrust/WOT-terms/wiki/identifier) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Something to uniquely identify public identities, pointing to someone or something else. |
+| 94 | G | n | identity |  | identity | a unique entity. Typically represented by a unique identifier. | [Link](https://github.com/weboftrust/WOT-terms/wiki/identity) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | A distinct entity typically represented by a unique identifier. |
+| 95 | K | n | inception-event |  | inception-event | the first event in KERI that establishes an identifier. | [Link](https://github.com/weboftrust/WOT-terms/wiki/inception-event) | Link | 3 | 1 |  |  | #REF! |  | 1 |  |  |  |  | The initial event in KERI that establishes an identifier. |
+| 96 | G | v | inception |  | inception | operation creating an AID by binding it to the initial set of authoritative keypairs and any other associated information. | [Link](https://github.com/weboftrust/WOT-terms/wiki/inception) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Create an AID by binding it to the initial set of authoritative keypairs and any relevant information. |
+| 97 | G | r | inconsistency |  | inconsistency | different parts of a reason, idea or opinion do not agree, or it does not agree with something else. | [Link](https://github.com/weboftrust/WOT-terms/wiki/inconsistency) | Link | 1 |  |  |  | #REF! |  | 1 |  |  |  |  | When different parts of a reason, idea, or opinion do not agree, or it is in disagreement with something else. |
+| 98 | K | n | indexed-signature |  | indexed-signature | an index telling which public key is used when signing anything with a multi-key autonomic identifier. | [Link](https://github.com/weboftrust/WOT-terms/wiki/indexed-signature) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | An index indicating the public key used for signing with a multi-key autonomic identifier. |
+| 99 | G | r | internal-inconsistency |  | internal-inconsistency | A status that exists within an entity where different parts of a reason, idea or opinion disagree. | [Link](https://github.com/weboftrust/WOT-terms/wiki/internal-inconsistency) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | A disagreement within an entity where different parts have conflicting reasons, ideas, or opinions. |
+| 100 | G | n | internet-assigned-numbers-authority |  | internet-assigned-numbers-authority | Also IANA; the organization that oversees the allocation of IP addresses to internet service providers (ISPs) | [Link](https://github.com/weboftrust/WOT-terms/wiki/internet-assigned-numbers-authority) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | IANA oversees IP address allocation to ISPs. |
+| 101 | K | r | issuance-and-presentation-exchange-protocol |  | issuance-and-presentation-exchange-protocol | provides a uniform mechanism for the issuance and presentation of ACDCs in a securely attributable manner | [Link](https://github.com/weboftrust/WOT-terms/wiki/issuance-and-presentation-exchange-protocol) | Link | 3 |  |  |  | #REF! | 1 |  |  |  |  |  | provides a secure and standardized way to issue and present ACDCs. |
+| 102 | G | r | javascript-object-signing-and-encryption |  | javascript-object-signing-and-encryption | Javascript object signing and encryption; method to securely transfer claims between parties | [Link](https://github.com/weboftrust/WOT-terms/wiki/javascript-object-signing-and-encryption) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | JavaScript object signing and encryption is a secure method for transferring claims between parties. |
+| 103 | K | n | judge |  | judge |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/judge) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 104 | K | r | keri-agreement-algorithm-for-control-establishment |  | keri-agreement-algorithm-for-control-establishment |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/keri-agreement-algorithm-for-control-establishment) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 105 | K | n | keri-command-line-interface |  | keri-command-line-interface |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/keri-command-line-interface) | Link | 3 |  |  |  | #REF! | 1 | 1 |  |  |  |  | NO INPUT |
+| 106 | K | n | keri-improvement-doc |  | keri-improvement-doc |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/keri-improvement-doc) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 107 | K | n | keridemlia |  | keridemlia | distributed database of Witness IP-addresses | [Link](https://github.com/weboftrust/WOT-terms/wiki/keridemlia) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Database of Witness IP addresses. |
+| 108 | G | v | key-compromise |  | key-compromise |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-compromise) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 109 | K | n | key-event-message |  | key-event-message |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-event-message) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 110 | K | n | key-event-receipt-infrastructure |  | key-event-receipt-infrastructure | approach to decentralized identifiers and decentralized key management that promises significant benefits for self-sovereign identity and Trust over IP infrastructure | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-event-receipt-infrastructure) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | An approach to decentralized identifiers and key management that offers significant benefits for self-sovereign identity and Trust over IP infrastructure. |
+| 111 | K | n | key-event-receipt-log |  | key-event-receipt-log |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-event-receipt-log) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 112 | K | n | key-event-receipt |  | key-event-receipt |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-event-receipt) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 113 | G | n | key-state |  | key-state |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-state) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 114 | G | n | key-transparency |  | key-transparency | lookup service for generic records and a public, tamper-proof audit log of all record changes | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-transparency) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | lookup service for generic records and a publicly accessible, tamper-proof audit log of all record modifications |
+| 115 | G | n | key |  | key |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/key) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | NO INPUT |
+| 116 | G | n | levels-of-assurance |  | levels-of-assurance | LoA, any time a judgement is not a binary Yes or No, you have levels of assurance | [Link](https://github.com/weboftrust/WOT-terms/wiki/levels-of-assurance) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | In LoA, when a judgment isn't a simple Yes or No, there are various levels of assurance. |
+| 117 | G | n | liveness |  | liveness |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/liveness) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 118 | G | r | loci-of-control |  | loci-of-control |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/loci-of-control) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 119 | K | n | management-transaction-event-log |  | management-transaction-event-log |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/management-transaction-event-log) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 120 | G | n | message |  | message |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/message) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 121 | G | n | multicodec |  | multicodec |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/multicodec) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 122 | G | n | namespace |  | namespace |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/namespace) | Link | 1 | 1 |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 123 | K | n | nested-cooperative-delegated-identifiers |  | nested-cooperative-delegated-identifiers |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/nested-cooperative-delegated-identifiers) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 124 | K | n | non-establishment-event |  | non-establishment-event |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/non-establishment-event) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 125 | G | n | non-fungible-token |  | non-fungible-token |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/non-fungible-token) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 126 | G | a | non-normative |  | non-normative | the purpose of non-normative theories is not to give answers, but rather to describe possibilities or predict results of certain actions | [Link](https://github.com/weboftrust/WOT-terms/wiki/non-normative) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Non-normative theories do not provide answers but describe possibilities or predict outcomes of specific actions. |
+| 127 | S | a | non-repudiable |  | non-repudiable | a statement's author cannot successfully dispute its authorship or the validity of an associated contract, signature or commitment. | [Link](https://github.com/weboftrust/WOT-terms/wiki/non-repudiable) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | The author of a statement cannot dispute its authorship or the validity of an associated contract, signature, or commitment. |
+| 128 | G | a | non-transferable |  | non-transferable | No capacity to transfer (the control over) a certain digital asset in an unobstructed or loss-less manner. | [Link](https://github.com/weboftrust/WOT-terms/wiki/non-transferable) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | No ability to transfer a digital asset without any obstruction or loss. |
+| 129 | G | a | normative |  | normative | a theory that tells you what you should do - what action you should take | [Link](https://github.com/weboftrust/WOT-terms/wiki/normative) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | A theory that explains the appropriate action to take. |
+| 130 | G | r | one-way-function |  | one-way-function | 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 | [Link](https://github.com/weboftrust/WOT-terms/wiki/one-way-function) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | A one-way function is easy to compute on all inputs but difficult to reverse given the image of a random input. |
+| 131 | G | n | payload |  | payload | the payload of an item in KERI is a specific cryptographic building block | [Link](https://github.com/weboftrust/WOT-terms/wiki/payload) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | The payload of an item in KERI is a cryptographic building block. |
+| 132 | G | n | pretty-good-privacy |  | pretty-good-privacy |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/pretty-good-privacy) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 133 | K | n | primary-root-of-trust |  | primary-root-of-trust |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/primary-root-of-trust) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 134 | G | n | primitive |  | primitive |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/primitive) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 135 | G | n | proof-of-authority |  | proof-of-authority | proof that somebody or something has certain rights or permissions on data | [Link](https://github.com/weboftrust/WOT-terms/wiki/proof-of-authority) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | proof of rights or permissions on data |
+| 136 | K | n | proof-of-authorship |  | proof-of-authorship | proof that somebody or something has originally created certain content | [Link](https://github.com/weboftrust/WOT-terms/wiki/proof-of-authorship) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Evidence that someone or something has created specific content. |
+| 137 | G | n | provenance |  | provenance | historic documentation of cryptographic verifiable key states , data consistency and cedentials | [Link](https://github.com/weboftrust/WOT-terms/wiki/provenance) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Historical documentation of cryptographic key states, data consistency, and credentials. |
+| 138 | G | n | public-key-infrastructure |  | public-key-infrastructure | set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates | [Link](https://github.com/weboftrust/WOT-terms/wiki/public-key-infrastructure) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Set of roles, policies, hardware, software, and procedures required for creating, managing, distributing, utilizing, storing, and revoking digital certificates. |
+| 139 | K | n | public-verifiable-credential-registry |  | public-verifiable-credential-registry | a Verifiable Data Registry that tracks the issuance/revocation state of credentials | [Link](https://github.com/weboftrust/WOT-terms/wiki/public-verifiable-credential-registry) | Link | 3 | 1 |  |  | #REF! |  |  |  |  |  |  | A Verifiable Data Registry tracks the issuing and revoking of credentials. |
+| 140 | G | n | race-condition |  | race-condition | the condition where a system's substantive behavior is dependent on the sequence or timing of external uncontrollable events | [Link](https://github.com/weboftrust/WOT-terms/wiki/race-condition) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | The condition where a system's behavior depends on external uncontrollable events' sequence or timing. |
+| 141 | K | n | receipt-log |  | receipt-log | ordered record of all key event receipts for a given set of witnesses | [Link](https://github.com/weboftrust/WOT-terms/wiki/receipt-log) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | A record of key event receipts for witnesses. |
+| 142 | G | n | receipt |  | receipt | event message or reference with one or more witness signatures | [Link](https://github.com/weboftrust/WOT-terms/wiki/receipt) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | event message with witness signatures |
+| 143 | K | n | registrar |  | registrar | identifiers that serve as backers for each transaction event log under its provenance | [Link](https://github.com/weboftrust/WOT-terms/wiki/registrar) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Identifiers back each transaction event log to establish its provenance. |
+| 144 | G | n | root-of-trust |  | root-of-trust | trust in end-verifiable digital signatures from asymmetric key cryptography, replaces human basis-of-trust | [Link](https://github.com/weboftrust/WOT-terms/wiki/root-of-trust) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | End-verifiable digital signatures from asymmetric key cryptography replace human basis-of-trust. |
+| 145 | K | v | rotation |  | rotation | the operation of revoking and replacing the set of authoritative key pairs for an AID | [Link](https://github.com/weboftrust/WOT-terms/wiki/rotation) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | revoking and replacing authoritative key pairs for an AID |
+| 146 | K | r | secondary-root-of-trust |  | secondary-root-of-trust | a root-of-trust that, for its secure attribution, depends on another primary root-of-trust | [Link](https://github.com/weboftrust/WOT-terms/wiki/secondary-root-of-trust) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | A root-of-trust depends on a primary root-of-trust for secure attribution. |
+| 147 | S | r | secure-asset-transfer-protocol |  | secure-asset-transfer-protocol | an IETF protocol for moving assets between blockchains | [Link](https://github.com/weboftrust/WOT-terms/wiki/secure-asset-transfer-protocol) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | An IETF protocol for transferring assets across blockchains. |
+| 148 | S | v | secure-attribution |  | secure-attribution | is 'whodunit?!' in cyberspace | [Link](https://github.com/weboftrust/WOT-terms/wiki/secure-attribution) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Whodunit in cyberspace! |
+| 149 | G | n | seed |  | seed | a pseudorandomly generated number, often expressed in representation of a series of words | [Link](https://github.com/weboftrust/WOT-terms/wiki/seed) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | A randomly generated number, usually expressed as a series of words. |
+| 150 | S | r | self-addressing-data |  | self-addressing-data | an encryption program that provides cryptographic privacy and authentication for data communication | [Link](https://github.com/weboftrust/WOT-terms/wiki/self-addressing-data) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | An encryption program that ensures data communication's cryptographic privacy and authentication. |
+| 151 | S | r | self-certifying-identifier |  | self-certifying-identifier | cryptographically binds an identifier to a public and private key pair | [Link](https://github.com/weboftrust/WOT-terms/wiki/self-certifying-identifier) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | Cryptographically binds an identifier to a key pair. |
+| 152 | K | a | self-framing |  | self-framing | A textual encoding that includes type, size, and value is self-framing; and thus parseable without needing any additional delimiting characters. | [Link](https://github.com/weboftrust/WOT-terms/wiki/self-framing) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | A self-framing textual encoding includes type, size, and value, making it parseable without any extra delimiting characters. |
+| 153 | S | n | self-sovereign-identity |  | self-sovereign-identity |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/self-sovereign-identity) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 154 | G | n | signed-digest |  | signed-digest |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/signed-digest) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 155 | G | n | spanning-layer |  | spanning-layer |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/spanning-layer) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 156 | K | r | text-binary-concatenation-composability |  | text-binary-concatenation-composability | When any set of self-framing 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. | [Link](https://github.com/weboftrust/WOT-terms/wiki/text-binary-concatenation-composability) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | When a group of self-framing concatenated primitives can be converted from one domain (text or binary) to the other and vice versa without any loss. |
+| 157 | K | n | transaction-event-log |  | transaction-event-log | The set of transactions that determine registry state form a log called a Transaction Event Log (TEL) and is cryptographically linked to corresponding controlling KEL. | [Link](https://github.com/weboftrust/WOT-terms/wiki/transaction-event-log) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | The transactions that determine the registry state form a log called Transaction Event Log (TEL) and are cryptographically linked to the corresponding controlling KEL. |
+| 158 | G | r | transmission-control-protocol |  | transmission-control-protocol | TCP is one of the main protocols of the Internet protocol suite | [Link](https://github.com/weboftrust/WOT-terms/wiki/transmission-control-protocol) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | TCP is a key protocol in the Internet protocol suite. |
+| 159 | S | r | trust-domain |  | 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. | [Link](https://github.com/weboftrust/WOT-terms/wiki/trust-domain) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | A trust domain is an ecosystem of interactions relying on trust. It binds controllers, identifiers, and key pairs. |
+| 160 | G | v | validator |  | validator | the capability to determine whether or not (verified) data is valid to be used for some specific purpose(s). | [Link](https://github.com/weboftrust/WOT-terms/wiki/validator) | Link | 2 | 1 |  |  | #REF! |  |  |  |  |  |  | the ability to verify data's validity for a specific purpose. |
+| 161 | G | r | veracity |  | veracity | the quest for the truth | [Link](https://github.com/weboftrust/WOT-terms/wiki/veracity) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | The Truth Quest |
+| 162 | G | n | verifiable-data-structure |  | verifiable-data-structure | a verifiable data structure is a data structure that incorporates cryptographic techniques to ensure the integrity and authenticity of its contents | [Link](https://github.com/weboftrust/WOT-terms/wiki/verifiable-data-structure) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | A verifiable data structure is a structure that uses cryptographic techniques to guarantee the integrity and authenticity of its contents. |
+| 163 | G | a | verifiable |  | verifiable | able to cryptographically verify a certain data structure on its consistency and its authenticity. | [Link](https://github.com/weboftrust/WOT-terms/wiki/verifiable) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | Capable of cryptographically verifying a specific data structure for consistency and authenticity. |
+| 164 | G | n | verifier |  | verifier | the entity that (cryptogrpahically) verifies data received from peers (check structure, signatures, dates) | [Link](https://github.com/weboftrust/WOT-terms/wiki/verifier) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | The entity verifies received data from peers by checking its structure, signatures, and dates using cryptography. |
+| 165 | G | n | version |  | version | is a class of systems responsible for managing changes to computer programs, documents, large web sites, or other collections of information | [Link](https://github.com/weboftrust/WOT-terms/wiki/version) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | Version: Version control is responsible for managing changes to computer programs, documents, web sites, or other collections of information. |
+| 166 | K | n | virtual-credential-transaction-event-log |  | virtual-credential-transaction-event-log | will track the issued or revoked state of each virtual credential (VC) | [Link](https://github.com/weboftrust/WOT-terms/wiki/virtual-credential-transaction-event-log) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 167 | G | r | web-of-trust |  | web-of-trust | In cryptography, a web of trust is a concept to establish the authenticity of the binding between a public key and its owner. | [Link](https://github.com/weboftrust/WOT-terms/wiki/web-of-trust) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 168 | K | n | well-known-witnesses |  | well-known witnesses | Predictable witness identifier creation by using known salts to initialize their key stores. For testing purposes only! | [Link](https://github.com/weboftrust/WOT-terms/wiki/well-known-witnesses) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 171 | G | n | repo | repo | repo | Software repository | [Link](https://github.com/weboftrust/WOT-terms/wiki/repo) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m27s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | Software Repo |
+| 173 | G | n | coroutines | coroutines | coroutines | Computer programs that can be suspended and resumed at will. | [Link](https://github.com/weboftrust/WOT-terms/wiki/coroutines) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | Suspend and resume computer programs at will. |
+| 174 | G | r | input-output | I/O | input-output | Input / output | [Link](https://github.com/weboftrust/WOT-terms/wiki/input-output) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | Input/Output |
+| 175 | G | n | hio | hio | hio | Hierarchical asynchronous coroutines and I/O in Python | [Link](https://github.com/weboftrust/WOT-terms/wiki/hio) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Hierarchical async coroutines and I/O in Python. |
+| 178 | G | n | clone | clone | clone | A copy of a system that is - and works exactly as the original | [Link](https://github.com/weboftrust/WOT-terms/wiki/clone) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m55s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | A replica system that is functioning exactly like the original. |
+| 179 | G | n | branch | branch | branch | A duplicate of an object under version control for further separate modification | [Link](https://github.com/weboftrust/WOT-terms/wiki/branch) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m00s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | A duplicate object under version control for separate modifications. |
+| 180 | K | n | kli | kli | kli | KERI command line interface | [Link](https://github.com/weboftrust/WOT-terms/wiki/kli) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m12s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Keri CLI |
+| 183 | S | n | verifiable-credential | verifiable credentials | verifiable-credential | the digital variant of our daily live's credentials (ike passport, driver's license), but in a machine-verifiable way | [Link](https://github.com/weboftrust/WOT-terms/wiki/verifiable-credential) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m26s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | The digital version of our daily life credentials, such as passports and driver's licenses, but in a machine-verifiable format. |
+| 185 | G | n | sub-shell | sub shell | sub-shell | a child shell started up from - and contained in another parent shell | [Link](https://github.com/weboftrust/WOT-terms/wiki/sub-shell) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m46s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | A child shell started from and contained within a parent shell. |
+| 186 | S | n | agent | agent | agent | a representative for an identity | [Link](https://github.com/weboftrust/WOT-terms/wiki/agent) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m01s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | identity representative |
+| 187 | G | n | cloud-agent | cloud agent | cloud-agent | is software installed on the cloud server instances for security, monitoring, and analysis | [Link](https://github.com/weboftrust/WOT-terms/wiki/cloud-agent) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m01s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | The software is installed on cloud server instances for security, monitoring, and analysis. |
+| 190 | G | n | user-interface | U/I | user-interface | A user interface (UI) is the space where interactions between humans and machines occur. | [Link](https://github.com/weboftrust/WOT-terms/wiki/user-interface) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m16s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | A user interface (UI) is where humans and machines interact. |
+| 191 | G | r | multisig | multi-sig | multisig | A digital signature scheme which allows a group of users to sign a single piece of digital data. | [Link](https://github.com/weboftrust/WOT-terms/wiki/multisig) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m29s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | A digital signature scheme enables a group of users to sign a single piece of digital data. |
+| 192 | G | n | identifier-system | identifier | identifier-system | Something to uniquely identify (public) identities, pointing to something or someone else. | [Link](https://github.com/weboftrust/WOT-terms/wiki/identifier-system) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m29s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | A unique identifier for public identities, referring to something or someone else. |
+| 193 | G | n | wallet | wallet | wallet | A wallet is a collection of data stores, made up of a keystore, local and remote key event log database and credential database. | [Link](https://github.com/weboftrust/WOT-terms/wiki/wallet) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m34s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A wallet includes a keystore, local and remote key event log database, and a credential database. |
+| 195 | K | n | witness | witnesses | witness | Entity that may receive, verify, and store key events for an identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/witness) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m44s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Entity that receives, verifies, and stores key events for an identifier. |
+| 196 | K | n | watcher | watchers | watcher | Guarantee that KERI logs are immutable | [Link](https://github.com/weboftrust/WOT-terms/wiki/watcher) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m44s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Ensure KERI logs are immutable. |
+| 197 | G | v | key-management | key management | key-management | Management of cryptographic keys in a crypto-system. | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-management) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m16s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Managing cryptographic keys in a crypto-system. |
+| 199 | S | n | single-signature-identifier | single sig identifier | single-signature-identifier | An identifier that is controlled by a one-of-one signing keypair | [Link](https://github.com/weboftrust/WOT-terms/wiki/single-signature-identifier) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m27s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | An identifier controlled by a unique signing keypair. |
+| 200 | G | n | keystore | key store | keystore | A keystore in KERI is the encrypted data store that hold the private keys for a collection of AIDs. | [Link](https://github.com/weboftrust/WOT-terms/wiki/keystore) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m33s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A keystore in KERI is an encrypted data store that holds the private keys for a collection of AIDs. |
+| 201 | S | r | key-event | key events | key-event | Events happening to controlling keys of an identifier recorded in a Key Event Log (KEL). | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-event) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s) | 2 | 1 |  |  | #REF! |  |  |  |  |  |  | Events happening to control keys of an identifier are recorded in a Key Event Log (KEL). |
+| 202 | S | r | interaction-event | interaction event | interaction-event | Anchors external data to the key-state as established by the most recent prior establishment event | [Link](https://github.com/weboftrust/WOT-terms/wiki/interaction-event) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Anchoring external data to the key-state established by the most recent establishment event. |
+| 203 | S | r | rotation-event | rotation event | rotation-event | Changes the key-state which includes a change to the set of authoritative keypairs for an AID | [Link](https://github.com/weboftrust/WOT-terms/wiki/rotation-event) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Changes the key-state, including a change to the set of authoritative keypairs for an AID. |
+| 204 | G | n | signing-threshold | signing thresholds | signing-threshold | Minimum number of valid signatures to satisfy the requirement for successful validation | [Link](https://github.com/weboftrust/WOT-terms/wiki/signing-threshold) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m48s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Minimum number of valid signatures for successful validation requirement. |
+| 205 | K | n | key-event-log | KEL | key-event-log | Key Event Log is the native KERI verifiable data structure | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-event-log) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=05m01s) | 3 | 1 |  |  | #REF! |  |  |  |  |  |  | Key Event Log is the KERI's native verifiable data structure. |
+| 206 | G | v | verify-signature | verify signatures | verify-signature | Applying an algorithm that either accepts or rejects the message's claim to authenticity; when you can succesfully verify a signature | [Link](https://github.com/weboftrust/WOT-terms/wiki/verify-signature) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=05m32s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | Applying an algorithm to verify the authenticity of a message by accepting or rejecting its claim when a signature can be successfully verified. |
+| 207 | G | r | peer-to-peer | peer-to-peer communications | peer-to-peer | Peers are equally privileged, equipotent participants in a network | [Link](https://github.com/weboftrust/WOT-terms/wiki/peer-to-peer) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=06m13s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | Peers are equally privileged and equipotent participants in a network. |
+| 209 | G | n | salt | salts | salt | Random data that is used as an additional input to a cryptographic one-way function | [Link](https://github.com/weboftrust/WOT-terms/wiki/salt) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=06m50s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Random data used as an additional input for a cryptographic one-way function. |
+| 210 | K | v | delegation | delegation | delegation | Delegation can be defined as “the act of empowering to act for another” | [Link](https://github.com/weboftrust/WOT-terms/wiki/delegation) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=07m44s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Delegation is the act of empowering someone to act on behalf of another. |
+| 211 | K | r | multi-sig-delegation | multi-sig delegation | multi-sig-delegation | delegated identifiers under multi-signature control | [Link](https://github.com/weboftrust/WOT-terms/wiki/multi-sig-delegation) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=07m44s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Multi-signature control for delegated identifiers. |
+| 213 | S | n | transferable-identifier | transferable | transferable-identifier | Control over identifier can be transferred by rotating keys | [Link](https://github.com/weboftrust/WOT-terms/wiki/transferable-identifier) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=08m34s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Keys can transfer control over identifiers by rotating them. |
+| 215 | G | n | configuration-files | configuration file | configuration-files | File used to configure the parameters and initial settings for some computer programs | [Link](https://github.com/weboftrust/WOT-terms/wiki/configuration-files) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=09m16s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | This file configures parameters and initial settings for computer programs. |
+| 219 | G | r | transfer\_Protocol | post and put | transfer\_Protocol | HTTP request methods to indicate the desired action to be performed on the identified resource | [Link](https://github.com/weboftrust/WOT-terms/wiki/transfer_Protocol) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m17s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | HTTP request methods indicate the desired action on the identified resource. |
+| 221 | G | n | passcode | passcode | passcode | Secret data, typically a string of characters, usually used to confirm a user's identity | [Link](https://github.com/weboftrust/WOT-terms/wiki/passcode) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=11m06s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | Secret data, often a string of characters, commonly utilized for user identity verification. |
+| 222 | G | v | key-stretching | stretched into an encryption key | key-stretching | make a possibly weak key, typically a password or passphrase, more secure against a brute-force attack by increasing the resources | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-stretching) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=11m11s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Enhance the security of a potentially weak key, such as a password or passphrase, against brute-force attacks by increasing available resources. |
+| 224 | K | n | non-transferable-identitifer | non-transferable identifier | non-transferable-identitifer | Controlling keys over this identifier cannot be rotated and therefore this identifier is non-transferable to other control | [Link](https://github.com/weboftrust/WOT-terms/wiki/non-transferable-identitifer) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=14m28s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Keys cannot be rotated for this identifier, making it non-transferable for control elsewhere. |
+| 226 | K | n | threshold-signature-scheme | witness threshold | threshold-signature-scheme | The minimum number of valid witness signatures required | [Link](https://github.com/weboftrust/WOT-terms/wiki/threshold-signature-scheme) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=15m37s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Minimum required witness signatures. |
+| 227 | K | v | pre-rotation | pre-rotation | pre-rotation | commitment to next rotated key set in previous rotation or inception event | [Link](https://github.com/weboftrust/WOT-terms/wiki/pre-rotation) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=15m54s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | commitment to the next key set rotated in the previous rotation or inception event. |
+| 228 | K | n | prefix | prefixes | 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 | [Link](https://github.com/weboftrust/WOT-terms/wiki/prefix) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m47s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | The prefix is a combination of a Base-64 derivation code and the Base-64 encoding of a public digital signing key. |
+| 229 | G | n | base64 | base64 | base64 | A group of binary-to-text encoding schemes that represent binary data | [Link](https://github.com/weboftrust/WOT-terms/wiki/base64) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Binary-to-text encoding schemes represent binary data. |
+| 230 | K | a | qualified | qualified | qualified | when qualified, a cryptographic primitive includes a prepended derivation code | [Link](https://github.com/weboftrust/WOT-terms/wiki/qualified) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | When qualified, a cryptographic primitive includes a derived code prepended. |
+| 231 | K | n | derivation-code | derivation code | derivation-code | A special character that encodes the derivation process, pre-pended to the identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/derivation-code) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A special character that encodes the derivation process, added to the identifier. |
+| 232 | G | n | blake3 | Blake3 hash | blake3 | BLAKE3 is a relatively young (2020) cryptographic hash function based on Bao and BLAKE2. | [Link](https://github.com/weboftrust/WOT-terms/wiki/blake3) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m57s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | BLAKE3 is a new cryptographic hash function, released in 2020, that builds upon Bao and BLAKE2. |
+| 233 | G | n | data-anchor | anchor data into | data-anchor | Data anchors are digests of digital data, that uniquely identify this data | [Link](https://github.com/weboftrust/WOT-terms/wiki/data-anchor) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m14s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Data anchors are digital data digests that uniquely identify the data. |
+| 234 | S | n | autonomic-identifier | AID | autonomic-identifier | An identifier that is self-certifying and self-sovereign | [Link](https://github.com/weboftrust/WOT-terms/wiki/autonomic-identifier) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m50s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A self-certifying and self-sovereign identifier. |
+| 236 | G | n | digest | digest | digest | Verifiable cryptographic commitment. It's a collision resistant hash of content | [Link](https://github.com/weboftrust/WOT-terms/wiki/digest) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m57s) | 2 | 1 |  |  | #REF! |  |  |  |  |  |  | Verifiable cryptographic commitment is a collision-resistant content hash. |
+| 237 | K | r | issuance-event | issuance event | issuance-event | The inception event of a verifiable credential | [Link](https://github.com/weboftrust/WOT-terms/wiki/issuance-event) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=18m02s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | The inception event of a verifiable credential. |
+| 238 | K | n | public-transaction-event-log | public transaction event log | public-transaction-event-log | Is a hash linked data structure of transactions that can be used to track state | [Link](https://github.com/weboftrust/WOT-terms/wiki/public-transaction-event-log) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=18m05s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A hash linked data structure is used to track state in transactions. |
+| 239 | G | n | Rust |  | Rust | programming language | [Link](https://github.com/weboftrust/WOT-terms/wiki/Rust) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=19m34s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Programming Language |
+| 240 | K | r | establishment-event | establishment | establishment-event | An event that establishes control authority | [Link](https://github.com/weboftrust/WOT-terms/wiki/establishment-event) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=19m39s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A control authority event |
+| 241 | G | n | memory-Mapped\_Database | lmdb databases | memory-Mapped\_Database | Lightning Memory-Mapped Database | [Link](https://github.com/weboftrust/WOT-terms/wiki/memory-Mapped_Database) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=21m42s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Lightning Memory-Mapped DB |
+| 242 | K | r | indexed-signature | indexed signatures | indexed-signature | Used when signing anything with a multi-key autonomic identifier, a verifier knows which of the multiple public keys was used | [Link](https://github.com/weboftrust/WOT-terms/wiki/indexed-signature) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=23m46s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | When signing with a multi-key autonomic identifier, a verifier can determine which specific public key was used. |
+| 245 | K | n | self-addressing-identifier | self-addressing identifiers | self-addressing-identifier | An identifier that is deterministically generated from and embedded in the content it identifies, making it and its data mutually tamper-evident | [Link](https://github.com/weboftrust/WOT-terms/wiki/self-addressing-identifier) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=25m29s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | An identifier is deterministically generated from and embedded in the content it identifies, making it and its data tamper-evident. |
+| 247 | K | n | ledger-backer | ledger backer | ledger-backer | A witness in KERI that is ledger-registered | [Link](https://github.com/weboftrust/WOT-terms/wiki/ledger-backer) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=27m55s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A registered witness in KERI. |
+| 248 | K | n | witness | witness backer | witness | A native KERI witness whose control authority is established in a KEL | [Link](https://github.com/weboftrust/WOT-terms/wiki/witness) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=27m55s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A KERI witness, native to KEL, has established control authority. |
+| 249 | K | n | verifiable-legal-entity-identifier | vLEI | verifiable-legal-entity-identifier | Digital verifiable credentials issued by (delegates) of GLEIF to prove that information about a legel entity is verifiably authentic | [Link](https://github.com/weboftrust/WOT-terms/wiki/verifiable-legal-entity-identifier) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m17s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Digital verifiable credentials issued by GLEIF delegates to verify the authenticity of information about a legal entity. |
+| 250 | S | n | ssi-system | SSI system | ssi-system | SSI Infrastructure consisting of the technological components that are deployed all over the world | [Link](https://github.com/weboftrust/WOT-terms/wiki/ssi-system) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m22s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | SSI Infrastructure consists of technological components deployed worldwide. |
+| 252 | K | v | transfer-off-ledger | transfer off a ledger | transfer-off-ledger | The act of transferring control authority over an identifier from a ledger (or blockchain) to the native verifiable KERI data structure KEL | [Link](https://github.com/weboftrust/WOT-terms/wiki/transfer-off-ledger) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m39s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Transferring control authority of an identifier from a ledger or blockchain to the KEL data structure in KERI. |
+| 255 | G | n | service-endpoint | service endpoints | service-endpoint | A web service endpoint which is a URL at which clients of specific service can get access to the service. | [Link](https://github.com/weboftrust/WOT-terms/wiki/service-endpoint) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=32m54s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | A web service endpoint is a URL where clients can access a specific service. |
+| 256 | G | n | uniform-resource-locator | URLs | uniform-resource-locator | A reference to a web resource that specifies its location on a computer network and a mechanism for retrieving it | [Link](https://github.com/weboftrust/WOT-terms/wiki/uniform-resource-locator) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=33m00s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | A web resource reference that specifies its location on a computer network and a retrieval mechanism. |
+| 257 | G | n | ip-address | ip-address | ip-address | A numerical label such as '192.0.2.1' that is connected to a computer network that uses the Internet Protocol for communication | [Link](https://github.com/weboftrust/WOT-terms/wiki/ip-address) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=33m42s) | 1 |  |  |  | #REF! |  |  |  |  |  |  | A numerical label, like '192.0.2.1', connected to a computer network using the Internet Protocol for communication. |
+| 258 | G | n | tcp-endpoint | TCP endpoint | tcp-endpoint | This is a service endpoint of the web transmission control protocol | [Link](https://github.com/weboftrust/WOT-terms/wiki/tcp-endpoint) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=34m00s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | This is a web transmission control protocol endpoint. |
+| 259 | K | n | inquisitor | inquisitor | inquisitor | Someone (in a validating role) that launches an inquiry at some KERI witness | [Link](https://github.com/weboftrust/WOT-terms/wiki/inquisitor) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=37m19s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | A person (in a validating role) who questions a KERI witness. |
+| 260 | G | v | replay-attack |  | replay-attack | intercept and then fraudulently delays or resend a message to misdirect the receiver into doing what the attacker wants | [Link](https://github.com/weboftrust/WOT-terms/wiki/replay-attack) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=49m13s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Intercepting a message and fraudulently delaying or resending it to misdirect the receiver into complying with the attacker's desires. |
+| 261 | G | n | XBRL |  | XBRL | extensible business reporting language, standard for digital business reporting | [Link](https://github.com/weboftrust/WOT-terms/wiki/XBRL) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Extensible Business Reporting Language (XBRL), a digital standard for business reporting. |
+| 262 | G | n | extensible-business-reporting-language |  | extensible-business-reporting-language | XBRL, standard for digital business reporting | [Link](https://github.com/weboftrust/WOT-terms/wiki/extensible-business-reporting-language) | Link | 1 |  |  |  |  |  |  |  |  |  |  | XBRL is the standard for digital business reporting. |
+| 263 | K | n | locked-state | locked state | locked-state | default state of an encrypted KERI data store with a passcode | [Link](https://github.com/weboftrust/WOT-terms/wiki/locked-state) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=52m22s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | The default state of an encrypted KERI data store with a passcode. |
+| 265 | K | r | out-of-band-introduction | data OOBIs | out-of-band-introduction | data out-of-band introductions | [Link](https://github.com/weboftrust/WOT-terms/wiki/out-of-band-introduction) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=53m48s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Data out-of-band intros |
+| 266 | K | r | out-of-band-introduction | credential schema OOBIs | out-of-band-introduction | credential schema out-of-band introductions | [Link](https://github.com/weboftrust/WOT-terms/wiki/out-of-band-introduction) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=53m54s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Credentials schema introductions outside of the main channel. |
+| 267 | K | n | keep | keep | keep | is KERI's and ACDC's depreciated crypto wallet, a task orientated application for managing AIDs in ecosystems, e.g. the vLEI Ecosystem | [Link](https://github.com/weboftrust/WOT-terms/wiki/keep) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=54m12s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | This is a deprecated crypto wallet by KERI and ACDC. It is a task-oriented app for managing AIDs in ecosystems such as the vLEI Ecosystem. |
+| 268 | G | r | zero-trust | zero trust | zero-trust | a Zero Trust approach trusts no one | [Link](https://github.com/weboftrust/WOT-terms/wiki/zero-trust) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=55m37s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | In a Zero Trust approach, no one is trusted. |
+| 270 | K | r | revocation-event | revocation events | revocation-event | An event that revokes control authority over an identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/revocation-event) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=55m58s) | 2 |  |  |  | #REF! |  |  |  |  |  |  | An event revoking control authority over an identifier. |
+| 272 | K | n | escrow-state | escrow states | 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. | [Link](https://github.com/weboftrust/WOT-terms/wiki/escrow-state) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=56m59s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | The current state of all temporary storage locations that the KERI protocol needs to keep track of, due to its fully asynchronous nature (events waiting for other information). |
+| 273 | K | r | server-sent-event | server-sent events | server-sent-event | Mailbox notifications, a streaming service for the agent U/I, to get notifications from the KERI system itself | [Link](https://github.com/weboftrust/WOT-terms/wiki/server-sent-event) | [Link](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=57m19s) | 3 |  |  |  | #REF! |  |  |  |  |  |  | Mailbox notifications is a streaming service for the agent U/I, providing notifications directly from the KERI system. |
+| 274 | G | n | seal |  | seal | cryptographic proof in a secondary root-of-trust that is anchored in a primary-root-of-trust | [Link](https://github.com/weboftrust/WOT-terms/wiki/seal) | Link | 2 | 1 |  |  | #REF! |  |  |  |  |  |  | cryptographic proof in a secondary root-of-trust anchored in a primary root-of-trust |
+| 275 | S | a | authoritative |  | authoritative | (control over) an identifier is 'authoritative' because it can be considered accurate, renowned, honourable and / or respected | [Link](https://github.com/weboftrust/WOT-terms/wiki/authoritative) | Link | 3 | 1 |  |  | #REF! |  |  |  |  |  |  | An identifier has control and is considered authoritative when it is accurate, renowned, honorable, and respected. |
+| 276 | K | n | QVI |  | QVI | qualified vlei issuer, contracting party qualified by GLEIF | [Link](https://github.com/weboftrust/WOT-terms/wiki/QVI) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | Qualified vlei issuer, contracting party qualified by GLEIF. |
+| 277 | K | n | qualified-vlei-issuer |  | qualified-vlei-issuer | QVI, contracting party qualified by GLEIF | [Link](https://github.com/weboftrust/WOT-terms/wiki/qualified-vlei-issuer) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | QVI, a contracting party qualified by GLEIF. |
+| 278 | K | n | ghost-credential |  | ghost-credential | a valid credential within in a 90 days grace period | [Link](https://github.com/weboftrust/WOT-terms/wiki/ghost-credential) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | a valid credential within a 90-day grace period |
+| 279 | K | n | redundant-credential |  | redundant-credential | multiple -, independently valid credentials issued by the same issuer | [Link](https://github.com/weboftrust/WOT-terms/wiki/redundant-credential) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | Multiple independently valid credentials issued by the same issuer. |
+| 280 | K | r | engagement-context-role |  | engagement-context-role | A person that represents the Legal Entity in a context role and is issued an ECR vLEI Credential. | [Link](https://github.com/weboftrust/WOT-terms/wiki/engagement-context-role) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | A person represents the Legal Entity in a role and is issued an ECR vLEI Credential. |
+| 281 | K | r | ECR |  | ECR | A person that represents the Legal Entity in a context role and is issued an ECR vLEI Credential. | [Link](https://github.com/weboftrust/WOT-terms/wiki/ECR) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | A person represents the Legal Entity in a role and is issued an ECR vLEI Credential. |
+| 282 | K | n | gleif-authorized-representative |  | gleif authorized representative | A GLEIF representative authorized to perform verification needed to issue the QVI vLEI Credential. | [Link](https://github.com/weboftrust/WOT-terms/wiki/gleif-authorized-representative) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | A GLEIF representative authorized to verify and issue the QVI vLEI Credential. |
+| 283 | K | n | GAR |  | GAR | A GLEIF representative authorized to perform verification needed to issue the QVI vLEI Credential. | [Link](https://github.com/weboftrust/WOT-terms/wiki/GAR) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | A GLEIF representative authorized to verify and issue the QVI vLEI Credential. |
+| 284 | G | n | GLEIF |  | GLEIF | Global Legal Entity Identifier Foundation | [Link](https://github.com/weboftrust/WOT-terms/wiki/GLEIF) | Link | 1 |  |  |  | #REF! |  |  |  | 1 |  |  | Global LEI Foundation. |
+| 285 | K | n | DAR |  | DAR | A representative of a Legal Entity authorized by the Legal Entity to act officially on behalf of the Legal Entity. | [Link](https://github.com/weboftrust/WOT-terms/wiki/DAR) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | A representative authorized by a Legal Entity to act on its behalf officially. |
+| 286 | K | n | designated-authorized-representative |  | designated-authorized-representative | A representative of a Legal Entity authorized by the Legal Entity to act officially on behalf of the Legal Entity. | [Link](https://github.com/weboftrust/WOT-terms/wiki/designated-authorized-representative) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | A representative authorized by a Legal Entity to act on its behalf officially. |
+| 287 | K | n | AVR |  | AVR | authorized vlei representative | [Link](https://github.com/weboftrust/WOT-terms/wiki/AVR) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | Authorized Vlei representative. |
+| 288 | K | n | authorized-vlei-representative |  | authorized-vlei-representative | a representative of a Legal Entity that's authorized to request issuance and revocation of credentials | [Link](https://github.com/weboftrust/WOT-terms/wiki/authorized-vlei-representative) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | a representative of a legal entity authorized to request issuance and revocation of credentials |
+| 289 | G | n | LEI |  | LEI | Legal Entity Institute | [Link](https://github.com/weboftrust/WOT-terms/wiki/LEI) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | Legal Entity Institute. |
+| 290 | G | n | legal-entity |  | legal-entity | unique parties that are legally or financially responsible for financial transactions or have the legal right to enter into legal contracts | [Link](https://github.com/weboftrust/WOT-terms/wiki/legal-entity) | Link | 2 |  |  |  | #REF! |  |  |  | 1 | #NAME? |  | parties legally or financially responsible for transactions or with the legal right to enter contracts |
+| 291 | K | r | OOR |  | OOR | official organizational role, a person holding a vLEI credential person and representing the Legal Entity | [Link](https://github.com/weboftrust/WOT-terms/wiki/OOR) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | official organizational role, a person holding a vLEI credential and representing the Legal Entity |
+| 292 | K | r | official-organizational-role |  | official-organizational-role | OOR, a person holding a vLEI credential person and representing the Legal Entity | [Link](https://github.com/weboftrust/WOT-terms/wiki/official-organizational-role) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | OOR, a person holding a vLEI credential and representing the Legal Entity |
+| 293 | K | n | qvi-authorized-representative |  | qvi-authorized-representative | QAR, conducts QVI operations with GLEIF and Legal Entities | [Link](https://github.com/weboftrust/WOT-terms/wiki/qvi-authorized-representative) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | QAR conducts QVI operations in collaboration with GLEIF and Legal Entities. |
+| 294 | K | n | QAR |  | QAR | qvi authorized representative, conducts QVI operations with GLEIF and Legal Entities | [Link](https://github.com/weboftrust/WOT-terms/wiki/QAR) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | Authorized representative conducts QVI operations with GLEIF and legal entities. |
+| 295 | K | n | vlei-ecosystem-governance-framework |  | vlei-ecosystem-governance-framework | a document that defines the information security, privacy, availability, confidentiality and processing integrity policies that apply | [Link](https://github.com/weboftrust/WOT-terms/wiki/vlei-ecosystem-governance-framework) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | This document defines the policies for information security, privacy, availability, confidentiality, and processing integrity. |
+| 296 | K | v | solicited-issuance |  | solicited-issuance | issuance of Legal Entity vLEI / OOR / ECR Credentials upon receipt by the QAR | [Link](https://github.com/weboftrust/WOT-terms/wiki/solicited-issuance) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | issuing vLEI/OOR/ECR Credentials upon QAR's receipt. |
+| 297 | K | v | unsolicited-issuance |  | unsolicited-issuance | issuance of a Legal Entity vLEI Credential upon notice by a QAR to its AVR(s) | [Link](https://github.com/weboftrust/WOT-terms/wiki/unsolicited-issuance) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | QAR notifies AVR(s) to issue a vLEI Credential to Legal Entity. |
+| 298 | G | n | governance-framework |  | governance-framework | a set of rules how to apply technology | [Link](https://github.com/weboftrust/WOT-terms/wiki/governance-framework) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | A set of rules on how to apply technology. |
+| 299 | K | n | GLEIS |  | GLEIS | Global Legal Entity Identifier System | [Link](https://github.com/weboftrust/WOT-terms/wiki/GLEIS) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | Global LEI System |
+| 300 | K | n | vlei-credential |  | vlei-credential | verifiable Legal Entity Identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/vlei-credential) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | Verifiable LEI |
+| 301 | K | r | legal-entity-engagement-context-role-vlei-credential-governance-framework |  | legal-entity-engagement-context-role-vlei-credential-governance-framework | A document that details the requirements for vLEI Role Credentials issued to representatives of a Legal Entity in functional - or other context of engagement. | [Link](https://github.com/weboftrust/WOT-terms/wiki/legal-entity-engagement-context-role-vlei-credential-governance-framework) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | NO INPUT |
+| 302 | K | n | vlei-role-credential |  | vlei-role-credential | A vLEI credential that attests a role. | [Link](https://github.com/weboftrust/WOT-terms/wiki/vlei-role-credential) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | NO INPUT |
+| 303 | K | n | legal-entity-official-organizational-role-vlei-credential-governance-framework |  | legal-entity-official-organizational-role-vlei-credential-governance-framework | A document that details the requirements for vLEI Role Credentials issued to official representatives of a Legal Entity. | [Link](https://github.com/weboftrust/WOT-terms/wiki/legal-entity-official-organizational-role-vlei-credential-governance-framework) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | NO INPUT |
+| 304 | K | n | legal-entity-vlei-credential-governance-framework |  | legal-entity-vlei-credential-governance-framework | A document that details the requirements for vLEI Credential issued by a Qualified vLEI Issuer to a Legal Entity | [Link](https://github.com/weboftrust/WOT-terms/wiki/legal-entity-vlei-credential-governance-framework) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | NO INPUT |
+| 305 | K | n | qualified-vlei-issuer-vlei-credential-governance-framework |  | qualified-vlei-issuer-vlei-credential-governance-framework | A document that details the requirements to enable this Credential to be issued by GLEIF to Qualified vLEI Issuers | [Link](https://github.com/weboftrust/WOT-terms/wiki/qualified-vlei-issuer-vlei-credential-governance-framework) | Link | 2 |  |  |  | #REF! |  |  |  | 1 |  |  | NO INPUT |
+| 306 | S | n | DID |  | DID | Decentralized Identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/DID) | Link | 2 |  |  |  | #REF! |  |  |  |  |  |  | DID |
+| 307 | S | n | decentralized-identifier |  | decentralized-identifier | Decentralized identifiers (DIDs) enable verifiable, decentralized digital identity, refering to a person, organization, thing, data model, abstract entity, etc. | [Link](https://github.com/weboftrust/WOT-terms/wiki/decentralized-identifier) | Link | 1 |  |  |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 308 | K | v | partial-pre-rotation |  | partial-pre-rotation | change of control but partially keep some keys unexposed while exposing others as needed. | [Link](https://github.com/weboftrust/WOT-terms/wiki/partial-pre-rotation) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Change control but partially keep certain keys undisclosed while exposing others as required. |
+| 309 | K | v | partial-rotation |  | partial-rotation | change of control but partially keep some keys unexposed while exposing others as needed. | [Link](https://github.com/weboftrust/WOT-terms/wiki/partial-rotation) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Change control but partially keep certain keys undisclosed while exposing others as required. |
+| 310 | K | v | custodial-rotation |  | custodial-rotation | change of control that is split between two key sets | [Link](https://github.com/weboftrust/WOT-terms/wiki/custodial-rotation) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Change of control split between two key sets. |
+| 311 | K | v | reserve-rotation |  | reserve-rotation | preparatory key pairs being held in reserve and not exposed | [Link](https://github.com/weboftrust/WOT-terms/wiki/reserve-rotation) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | Preparation key pairs reserved and not exposed. |
+| 312 | K | n | custodial-agent |  | custodial-agent | a custodian who has been granted signing authority and usually also being the host of the running agent software. | [Link](https://github.com/weboftrust/WOT-terms/wiki/custodial-agent) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | A custodian typically granted signing authority and also acts as the host for the running agent software. |
+| 313 | S | r | signing-authority |  | signing-authority | the authority to sign on behalf of the controller of an identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/signing-authority) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | the authority to sign for the controller of an identifier |
+| 314 | S | r | rotation-authority |  | rotation-authority | the (exclusive) right to change control over an identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/rotation-authority) | Link | 3 |  |  |  | #REF! |  | 1 |  |  |  |  | The exclusive right to change control of an identifier. |
+| 315 | G | n | trans-contextual-value |  | trans-contextual-value | value that is transferrable between contexts | [Link](https://github.com/weboftrust/WOT-terms/wiki/trans-contextual-value) | Link | 1 |  |  |  | #REF! |  | 1 |  |  |  |  | Transferable value across contexts. |
+| 316 | G | r | source-of-truth |  | source-of-truth | a trusted data source that gives a complete picture of the truth about a data object. | [Link](https://github.com/weboftrust/WOT-terms/wiki/source-of-truth) | Link | 1 |  |  |  | #REF! |  | 1 |  |  |  |  | a reliable data source providing a comprehensive view of the truth about a data object. |
+| 317 | G | v | authorization |  | authorization | specifying access rights or privileges to resources | [Link](https://github.com/weboftrust/WOT-terms/wiki/authorization) | Link | 1 |  |  | 1 | #REF! | 1 | 1 |  |  |  |  | specifying access rights to resources |
+| 318 | G | r | application-programming-interface |  | application-programming-interface | a way for two or more computer programs to communicate with each other. | [Link](https://github.com/weboftrust/WOT-terms/wiki/application-programming-interface) | Link | 1 |  |  |  | #REF! | 1 | 1 |  |  |  |  | A method for multiple computer programs to communicate with each other. |
+| 319 | G | n | API |  | API | an application Programming Interface, a way for two or more computer programs to communicate with each other. | [Link](https://github.com/weboftrust/WOT-terms/wiki/API) | Link | 1 |  |  |  | #REF! | 1 | 1 |  |  |  |  | An API is a way for computer programs to communicate with each other. |
+| 320 | G | n | key-pair |  | key-pair | a public key and its corresponding private key. | [Link](https://github.com/weboftrust/WOT-terms/wiki/key-pair) | Link | 1 |  |  | 1 | #REF! | 1 | 1 |  |  |  |  | a public key and its corresponding private key. |
+| 321 | G | n | owner |  | owner | a role that exercizes its legal, rightful or natural title to control something. | [Link](https://github.com/weboftrust/WOT-terms/wiki/owner) | Link | 1 |  |  |  | #REF! | 1 | 1 | 1 | 1 |  |  | A role that exercises its legal, rightful, or natural authority to control something. |
+| 322 | G | r | ownership |  | ownership | a relationship between two, one of these (the owner) is entitled to enjoy, dispose of, and control the other sovereignly. | [Link](https://github.com/weboftrust/WOT-terms/wiki/ownership) | Link | 1 |  |  |  | #REF! | 1 | 1 | 1 | 1 |  |  | In a relationship between two individuals, one (the owner) has the entitlement to enjoy, dispose of, and control the other entirely. |
+| 323 | G | n | self-sovereignty |  | self-sovereignty | the characteristic of every party that it is autonomous in managing and operating its own knowledge | [Link](https://github.com/weboftrust/WOT-terms/wiki/self-sovereignty) | Link | 1 |  |  |  | #REF! | 1 | 1 |  | 1 |  |  | Every party is autonomous in managing and operating its own knowledge. |
+| 324 | K | r | presentation-exchange |  | presentation-exchange | an exchange that provides disclosure of one or more ACDCs between a Discloser and a Disclosee. | [Link](https://github.com/weboftrust/WOT-terms/wiki/presentation-exchange) | Link | 3 |  | 1 |  | #REF! |  |  |  |  |  |  | an exchange that discloses one or more ACDCs between a Discloser and a Disclosee. |
+| 325 | G | n | discloser |  | discloser | an ACDC in a disclosure is disclosed by the Discloser. | [Link](https://github.com/trustoverip/acdc/wiki/discloser) | Link | 1 |  | 1 |  | #REF! |  |  |  |  |  |  | The Discloser discloses an ACDC in a disclosure. |
+| 326 | G | n | disclosee |  | disclosee | an ACDC in a disclosure is disclosed to the Disclosee. | [Link](https://github.com/trustoverip/acdc/wiki/disclosee) | Link | 1 |  | 1 |  | #REF! |  |  |  |  |  |  | An ACDC in a disclosure is revealed to the Disclosee. |
+| 327 | G | n | issuer |  | issuer | an ACDC is issued by the Issuer. The Issuer identifier (AID) appears in the top level of the ACDC. | [Link](https://github.com/trustoverip/acdc/wiki/issuer) | Link | 1 |  | 1 |  | #REF! |  |  |  |  |  |  | An ACDC is issued by the Issuer and contains the Issuer identifier (AID) in the top level. |
+| 328 | G | n | issuee |  | issuee | an ACDC is optionally issued to the Issuee. | [Link](https://github.com/trustoverip/acdc/wiki/issuee) | Link | 1 |  | 1 |  | #REF! |  |  |  |  |  |  | An ACDC can be optionally issued to the recipient. |
+| 329 | K | r | issuance-exchange |  | issuance-exchange | a special case of a presentation exchange where the Discloser is the Issuer of the origin (Primary) ACDC | [Link](https://github.com/trustoverip/acdc/wiki/issuance-exchange) | Link | 3 |  | 1 |  | #REF! |  |  |  |  |  |  | This is a special case of a presentation exchange where the Discloser is the Issuer of the origin (Primary) ACDC. |
+| 330 | K | r | chain-link-confidentiality |  | chain-link-confidentiality | chains together a sequence of Disclosees. Each Disclosee in the sequence in turn is the Discloser to the next Disclosee. | [Link](https://github.com/trustoverip/acdc/wiki/chain-link-confidentiality) | Link | 3 |  | 1 |  | #REF! |  |  |  |  |  |  | This text chains a sequence of Disclosees, where each Disclosee becomes the Discloser to the next. |
+| 331 | K | v | graduated-disclosure |  | graduated-disclosure | disclosure performed by a presentation exchange that has cross-variant Issuer commitment verifiability as an essential property. | [Link](https://github.com/trustoverip/acdc/wiki/graduated-disclosure) | Link | 3 |  | 1 |  | #REF! |  |  |  |  |  |  | Disclosure is performed by a presentation exchange with cross-variant Issuer commitment verifiability as an essential property. |
+| 332 | K | n | top-level-section |  | top-level-section | are the fields of an ACDC compact variant. | [Link](https://github.com/trustoverip/acdc/wiki/top-level-section) | Link | 2 |  | 1 |  | #REF! |  |  |  |  |  |  | These fields are part of an ACDC compact variant. |
+| 333 | K | r | compact-variant |  | compact-variant | an Issuer commitment via a signature to any variant of ACDC | [Link](https://github.com/trustoverip/acdc/wiki/compact-variant) | Link | 3 |  | 1 |  | #REF! |  |  |  |  |  |  | an Issuer signs a commitment to any variant of ACDC. |
+| 334 | K | v | contractually-protected-disclosure |  | contractually-protected-disclosure | the most elaborate form of disclosure by an IPEX. Contractually protected disclosure includes both chain-link confidential and contingent disclosure. | [Link](https://github.com/trustoverip/acdc/wiki/contractually-protected-disclosure) | Link | 3 |  | 1 |  | #REF! |  |  |  |  |  |  | The most detailed form of disclosure by an IPEX includes contractually protected disclosure, which encompasses both chain-link confidential and contingent disclosure. |
+| 335 | G | n | ricardian-contract |  | ricardian-contract | a method of recording a document as a contract at law, and linking it securely to other systems | [Link](https://github.com/trustoverip/acdc/wiki/ricardian-contract) | Link | 2 |  | 1 |  | #REF! |  |  |  |  |  |  | A way to record a document as a secure contract and link it to other systems. |
+| 336 | K | v | contingent-disclosure |  | contingent-disclosure |  | [Link](https://github.com/trustoverip/acdc/wiki/contingent-disclosure) | Link | 3 |  | 1 |  | #REF! |  |  |  |  |  |  | NO INPUT |
+| 337 | G | v | eclipse-attack |  | eclipse-attack | an eclipse attack is a P2P network-based attack, an attacker tries to isolate a node from the rest of the network | [Link](https://github.com/weboftrust/WOT-terms/wiki/eclipse-attack) | Link | 2 |  |  |  | #REF! |  | 1 |  |  |  |  | An eclipse attack is a P2P network attack where the attacker attempts to isolate a node from the network. |
+| 338 | K | n | promiscuous-mode |  | promiscuous-mode | the indiscriminate mode a watcher (network) runs in. | [Link](https://github.com/weboftrust/WOT-terms/wiki/promiscuous-mode) | Link | 3 |  |  |  | #REF! |  |  |  |  |  |  | The mode of a watcher in a network. |
+| 339 | G | n | protocol |  | protocol | a code of correct conduct, in our case specifically communication protocols, cryptographic protocols, and decentralized network protocols | [Link](https://github.com/weboftrust/WOT-terms/wiki/protocol) | Link | 1 | 1 | 1 | 1 | #REF! | 1 | 1 |  |  |  |  | Our code of conduct includes communication, cryptographic, and decentralized network protocols. |
+| 340 | G | n | pseudo-random-number |  | pseudo-random-number | a value that is statistically random, but it is (repeatedly) derived from a known starting point | [Link](https://github.com/weboftrust/WOT-terms/wiki/pseudo-random-number) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A randomly derived value from a known starting point. |
+| 341 | G | v | validate |  | validate | a decision to accept an outcome | [Link](https://github.com/weboftrust/WOT-terms/wiki/validate) | Link | 1 |  |  |  |  |  |  |  |  |  |  | deciding to accept an outcome |
+| 342 | S | v | verify |  | verify | the act, by or on behalf of a party, of determining whether that data is authentic, not expired, and conforms to other specifications. | [Link](https://github.com/weboftrust/WOT-terms/wiki/verify) | Link | 2 |
+| 343 | S | n | persistent-identifier |  | persistent-identifier | Control over this type of long-living identifier can be transferred by rotating keys. | [Link](https://github.com/weboftrust/WOT-terms/wiki/persistent-identifier) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Keys can rotate to transfer control of long-living identifiers. |
+| 344 | K | r | interleaved-serializations |  | interleaved-serializations | Serializations of different types interleaved in an overarching format | [Link](https://github.com/weboftrust/WOT-terms/wiki/interleaved-serializations) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Different types of serializations are interleaved in an overarching format. |
+| 345 | S | r | collective-signature |  | collective-signature | Multisignature scheme for a single resulting pubic key | [Link](https://github.com/weboftrust/WOT-terms/wiki/collective-signature) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Multisignature scheme for a single public key. |
+| 346 | G | n | graph-fragment |  | graph-fragment | an ACDC is a verifiable data structure and part of a graph consisting of a node fragment and edge fragments | [Link](https://github.com/weboftrust/WOT-terms/wiki/graph-fragment) | Link | 2 |  |  |  |  |  |  |  |  |  |  | ACDC is a verifiable data structure that forms part of a graph, including a node fragment and edge fragments. |
+| 347 | G | r | persistent-datastructure |  | persistent-datastructure | an append only verifiable data structure. Hence, making them immutable means distributable and concurrency-friendly. What we sign may not change. | [Link](https://github.com/weboftrust/WOT-terms/wiki/persistent-data-structure) | Link | 2 |  |  |  |  |  |  |  |  |  |  | An append-only, verifiable data structure makes them immutable, which enables distribution and concurrency. What we sign cannot be changed. |
+| 348 | G | r | collision |  | collision | a circumstance where two or more identifiers in a given namespace or a given scope cannot be unambiguously resolved | [Link](https://github.com/weboftrust/WOT-terms/wiki/collision) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A situation where two or more identifiers in a namespace or scope cannot be resolved unambiguously. |
+| 349 | G | n | schema-namespace-registry |  | schema-namespace-registry | a centrally managed schema registry where corporations or individuals reserve schemas within a specific namespace in order to have an interoperable schema that is labeled with a corporation-specific or individual-specific namespace | [Link](https://github.com/weboftrust/WOT-terms/wiki/schema-namespace-registry) | Link | 2 |  |  |  |  |  |  |  |  |  |  | A centrally managed schema registry allows corporations or individuals to reserve interoperable schemas within a specific namespace. These labeled schemas are assigned a corporation-specific or individual-specific namespace. |
+| 350 | G | n | schema-registry |  | schema-registry | registry for credential schemas based on namespaces | [Link](https://github.com/weboftrust/WOT-terms/wiki/schema-registry) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Registry for schemas based on namespaces. |
+| 351 | G | n | domain-name |  | domain-name | is a string that identifies a realm of administrative autonomy on the internet | [Link](https://github.com/weboftrust/WOT-terms/wiki/domain-name) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A string that identifies an internet administrative realm. |
+| 352 | G | n | domain |  | domain | general term for (an identifier of) an autonomous space | [Link](https://github.com/weboftrust/WOT-terms/wiki/domain) | Link | 1 |  |  |  |  |  |  |  |  |  |  | General term for an autonomous space identifier. |
+| 353 | G | n | registry |  | registry | an official digital record book, usually refering to one means to a specific instance, within a multi-tenant registry. | [Link](https://github.com/weboftrust/WOT-terms/wiki/registry) | Link | 1 |  |  |  |  |  |  |  |  |  |  | An official digital record book typically refers to a specific instance within a multi-tenant registry. |
+| 354 | G | r | composability |  | composability | When any set of self-framing 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. | [Link](https://github.com/weboftrust/WOT-terms/wiki/composability) | Link | 2 |  |  |  |  |  |  |  |  |  |  | When a group of self-framing concatenated primitives can be converted from one domain (text or binary) to the other and vice versa without any loss. |
+| 356 | G | a | interoperable |  | interoperable | Interoperability is a characteristic of a product or system to work with other products or systems. | [Link](https://github.com/weboftrust/WOT-terms/wiki/interoperable) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Interoperability is the ability of a product or system to work with others. |
+| 357 | G | r | interoperability |  | interoperability | Interoperability is a characteristic of a product or system to work with other products or systems. | [Link](https://github.com/weboftrust/WOT-terms/wiki/interoperability) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Interoperability is the ability of a product or system to work with others. |
+| 358 | G | n | cryptographic-primitive |  | cryptographic-primitive | Well-established, low-level cryptographic algorithm that is frequently used to build cryptographic protocols for computer security systems; e.g. one-way hash functions and encryption functions. | [Link](https://github.com/weboftrust/WOT-terms/wiki/cryptographic-primitive) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A well-known cryptographic algorithm commonly used in computer security systems for creating cryptographic protocols such as one-way hash functions and encryption functions. |
+| 359 | G | v | concatenation |  | concatenation | the operation of joining character strings end-to-end. E.g. 'snow' and 'ball' becomes 'snowball' | [Link](https://github.com/weboftrust/WOT-terms/wiki/concatenation) | Link | 1 |  |  |  |  |  |  |  |  |  |  | The process of combining character strings to create a single string. For example, 'snow' and 'ball' combine to form 'snowball'. |
+| 360 | G | v | multiplexing |  | multiplexing | is a method by which multiple analog or digital signals are combined into one signal over a shared medium. The aim is to share a scarce resource. | [Link](https://github.com/weboftrust/WOT-terms/wiki/multiplexing) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Signal combining is a method to merge multiple analog or digital signals into a single shared signal. It aims to efficiently distribute limited resources. |
+| 361 | G | v | pipelining |  | pipelining | a set of data processing elements connected in series, where the output of one element is the input of the next one. | [Link](https://github.com/weboftrust/WOT-terms/wiki/pipelining) | Link | 2 |  |  |  |  |  |  |  |  |  |  | A series of connected data processing elements, where the output of one element becomes the input for the next. |
+| 362 | K | n | group-framing-code |  | group-framing-code | codes that can be specified to support groups of primitives. Grouping enables pipelining. | [Link](https://github.com/weboftrust/WOT-terms/wiki/group-framing-code) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Codes can be specified to support primitive groups, enabling pipelining. |
+| 363 | K | r | hierarchical-composition |  | hierarchical-composition | encoding protocol that is composable in a hierarchy and enables pipelining of complex streams in either text or compact binary | [Link](https://github.com/weboftrust/WOT-terms/wiki/hierarchical-composition) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Composable and hierarchical encoding protocol enables pipelining of complex streams in text or binary formats. |
+| 364 | K | n | frame-code |  | frame-code | codes that can be specified to support groups of primitives. Grouping enables pipelining. | [Link](https://github.com/weboftrust/WOT-terms/wiki/frame-code) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Codes can be specified to support primitive groups, enabling pipelining. |
+| 365 | K | n | count-code |  | count-code | codes that can be specified to support groups of primitives. Grouping enables pipelining. | [Link](https://github.com/weboftrust/WOT-terms/wiki/count-code) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Codes can be specified to support primitive groups, enabling pipelining. |
+| 366 | K | n | group-code |  | group-code | codes that can be specified to support groups of primitives. Grouping enables pipelining. | [Link](https://github.com/weboftrust/WOT-terms/wiki/group-code) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Codes can be specified to support primitive groups, enabling pipelining. |
+| 367 | S | a | transferable |  | transferable | capable of loss-less transfer of control over identifiers, private keys, etc. | [Link](https://github.com/weboftrust/WOT-terms/wiki/transferable) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Capable of lossless transfer of control for identifiers, private keys, etc. |
+| 368 | G | v | post-pad |  | 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. | [Link](https://github.com/weboftrust/WOT-terms/wiki/post-pad) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Extending a string with pad characters to align it to a specific length in bits or bytes is the act or outcome. |
+| 369 | G | v | pre-pad |  | 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. | [Link](https://github.com/weboftrust/WOT-terms/wiki/pre-pad) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Prepending a string with leading pad characters is the act of aligning it to a specific length in bits or bytes. |
+| 370 | K | v | naive-conversion |  | naive-conversion | a text to binary conversion or vice versa that doesn't anticipate on either composability and / or on the concatenation capability of the result of such an operation. | [Link](https://github.com/weboftrust/WOT-terms/wiki/naive-conversion) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A text to binary conversion that does not consider composability or concatenation capabilities of the output. |
+| 371 | G | n | pad |  | pad | is a character used to fill empty space | [Link](https://github.com/weboftrust/WOT-terms/wiki/pad) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Is a character used to fill empty space. |
+| 372 | G | n | lead-bytes |  | lead-bytes | pre-conversion added characters in a pre-padded way, used to fill empty space | [Link](https://github.com/weboftrust/WOT-terms/wiki/lead-bytes) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Pre-conversion characters were added to fill empty space in a pre-padded manner. |
+| 373 | G | n | code-table |  | code-table | a code table is the Internet's most comprehensive yet simple resource for browsing and searching for various codes. | [Link](https://github.com/weboftrust/WOT-terms/wiki/code-table) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A code table is the Internet's most comprehensive and user-friendly resource for browsing and searching various codes. |
+| 374 | K | n | code-table-selector |  | code-table-selector | the first character in the text code of CESR stream that determines which code table to use. | [Link](https://github.com/weboftrust/WOT-terms/wiki/code-table-selector) | Link | 3 |  |  |  |  |  |  |  |  |  |  | The first character in the text code of CESR stream determines the code table to use. |
+| 375 | K | n | sally |  | sally | a vLEI Audit Reporting Agent that receives presentations of credentials and notices of revocation. | [Link](https://github.com/weboftrust/WOT-terms/wiki/sally) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A vLEI Audit Reporting Agent that receives credential presentations and revocation notices. |
+| 376 | K | n | signify |  | signify | is a web client (key) event signing - and key pair creation app that minimizes the use of KERI on the client. | [Link](https://github.com/weboftrust/WOT-terms/wiki/signify) | Link | 3 |  |  |  |  |  |  |  |  |  |  | This is a web client app for event signing and key pair creation. It reduces the need for using KERI on the client. |
+| 377 | G | n | escrow |  | escrow | a third party temporarily holds money or property until a particular condition has been met. The verb refers to handling out of order events in KERI. | [Link](https://github.com/weboftrust/WOT-terms/wiki/escrow) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A third party temporarily holds funds or assets until a specific condition is met. The verb refers to managing out-of-sequence events in KERI. |
+| 378 | K | n | keri-suite-search-engine |  | keri-suite-search-engine | the Docusaurus self-education site of Web-of-Trust GitHub repo with Typesense search facilities | [Link](https://github.com/trustoverip/acdc/wiki/keri-suite-search-engine) | Link | 1 |  |  |  |  |  |  |  |  |  |  | The Docusaurus self-education site for the Web-of-Trust GitHub repo now includes Typesense search capabilities. |
+| 379 | K | n | field-map |  | field-map | a traditional key:value pair renamed to avoid confusing with the cryptographic use of the term 'key' | [Link](https://github.com/weboftrust/WOT-terms/wiki/field-map) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A traditional key:value pair is renamed to avoid confusion with the cryptographic meaning of the term 'key'. |
+| 380 | K | r | CLC |  | CLC | chain-link confidential, a disclosure mechnism of credentials | [Link](https://github.com/weboftrust/WOT-terms/wiki/CLC) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Chain-link confidential is a mechanism for disclosing credentials. |
+| 381 | K | v | cold-start-stream-parsing |  | cold-start-stream-parsing | After a reboot a stream processor looks for framing information to know how to parse groups of elements in the stream. | [Link](https://github.com/weboftrust/WOT-terms/wiki/cold-start-stream-parsing) | Link | 3 |  |  |  |  |  |  |  |  |  |  | After a reboot, a stream processor searches for framing information to determine how to parse element groups in the stream. |
+| 382 | K | a | fully-compact |  | fully-compact | the intermediate variant of a ACDC credential -> signed and its proofs anchored in key event logs. | [Link](https://github.com/weboftrust/WOT-terms/wiki/fully-compact) | Link | 3 |  |  |  |  |  |  |  |  |  |  | The intermediate ACDC credential variant is signed and its proofs are anchored in key event logs. |
+| 383 | K | a | most-compact |  | most-compact | the most brief least disclosing version of an ACDC based credential. | [Link](https://github.com/weboftrust/WOT-terms/wiki/most-compact) | Link | 3 |  |  |  |  |  |  |  |  |  |  | The shortest and least revealing ACDC credential version. |
+| 384 | K | a | fully-expanded |  | fully-expanded | the most extensive most disclosing and most user-friendly version of an ACDC based credential. | [Link](https://github.com/weboftrust/WOT-terms/wiki/fully-expanded) | Link | 3 |  |  |  |  |  |  |  |  |  |  | the most comprehensive, revealing, and user-friendly ACDC-based credential. |
+| 385 | G | v | RUN |  | RUN | read, update, nullify -> the new peer-to-peer end-verifiable monotonic update policy | [Link](https://github.com/weboftrust/WOT-terms/wiki/RUN) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Read, update, nullify - the new P2P EV monotonic update policy. |
+| 386 | G | v | CRUD |  | CRUD | create, read, update, delete -> the traditional client-server database update policy | [Link](https://github.com/weboftrust/WOT-terms/wiki/CRUD) | Link | 1 |  |  |  |  |  |  |  |  |  |  | The traditional client-server database update policy includes CRUD (Create, Read, Update, Delete) operations. |
+| 387 | G | n | authentic-web |  | authentic-web | a mental model in which the whole internet is considered as a one giant verifiable data structure | [Link](https://github.com/weboftrust/WOT-terms/wiki/authentic-web) | Link | 1 |  |  |  |  |  |  |  |  |  |  | The internet is viewed as one giant, verifiable data structure. |
+| 388 | K | v | run-off-the-crud |  | run-off-the-crud | a decentralised controlling peer does not create records in the traditional sense of a server | [Link](https://github.com/weboftrust/WOT-terms/wiki/run-off-the-crud) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A decentralized controlling peer does not create traditional server records. |
+| 389 | G | n | integrity |  | integrity | the information is whole, complete, sound, in good order and unimpaired (not necessarily correct) | [Link](https://github.com/weboftrust/WOT-terms/wiki/integrity) | Link | 1 |  |  |  |  |  |  |  |  |  |  | The information is complete, accurate, organized, and intact (not necessarily correct). |
+| 390 | G | n | verified-integrity |  | verified-integrity | a proof of unambiguous assessment whether the information is/continues to be whole, sound and unimpaired | [Link](https://github.com/weboftrust/WOT-terms/wiki/verified-integrity) | Link | 2 |  |  |  |  |  |  |  |  |  |  | A proof of clear assessment of whether the information remains intact, reliable, and undamaged. |
+| 391 | G | v | complementary-integrity-verification |  | 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 | [Link](https://github.com/weboftrust/WOT-terms/wiki/complementary-integrity-verification) | Link | 3 |  |  |  |  |  |  |  |  |  |  | a mechanism that can independently verify integrity without needing access to a previous instance or reference version for comparison. |
+| 392 | K | n | prior-next-threshold |  | prior-next-threshold |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/prior-next-threshold) | Link | 3 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 393 | K | n | current-signing-threshold |  | current-signing-threshold |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/current-signing-threshold) | Link | 2 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 394 | K | n | dual-indexed-codes |  | dual-indexed-codes | a context-specific coding scheme, for the common use case of thresholded multi-signature schemes in CESR | [Link](https://github.com/weboftrust/WOT-terms/wiki/dual-indexed-codes) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A specific coding scheme for thresholded multi-signature schemes in CESR. |
+| 395 | K | n | keripy |  | keripy | Python implementation of KERI | [Link](https://github.com/weboftrust/WOT-terms/wiki/keripy) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Python implementation of KERI |
+| 396 | K | n | keri-ox |  | keri-ox | RUST implementation of KERI | [Link](https://github.com/weboftrust/WOT-terms/wiki/keri-ox) | Link | 2 |  |  |  |  |  |  |  |  |  |  | RUST KERI Implementation |
+| 397 | S | n | pii |  | pii | personally identifiable information | [Link](https://github.com/weboftrust/WOT-terms/wiki/pii) | Link | 1 |  |  |  |  |  |  |  |  |  |  | PII |
+| 398 | S | r | contextual-linkability |  | contextual-linkability | when data capture points provide enough context to be able to use statistical correlation to link existing data sets describing a person to that same person's disclosed attributes | [Link](https://github.com/trustoverip/acdc/wiki/contextual-linkability) | Link | 3 |  |  |  |  |  |  |  |  |  |  | When data capture points give enough context to use statistical correlation in linking existing data sets describing a person to that person's disclosed attributes. |
+| 399 | K | r | blinded-revocation-registry |  | blinded-revocation-registry | a transaction event log hidden or blinded; the only way a verifier can observe the state is when the AID controller discloses it at presentation time | [Link](https://github.com/weboftrust/WOT-terms/wiki/blinded-revocation-registry) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A hidden or blinded transaction event log; the verifier can only observe the state when the AID controller discloses it during presentation. |
+| 400 | G | v | rainbow-table-attack |  | rainbow-table-attack | a password cracking method that uses a special table (a “rainbow table”) to crack the password hashes in a database | [Link](https://github.com/weboftrust/WOT-terms/wiki/rainbow-table-attack) | Link | 1 |  |  |  |  |  |  |  |  |  |  | The method uses a special table, known as a "rainbow table," to crack password hashes in a database. |
+| 401 | K | r | SKWA |  | SKWA | Simple KERI for Web Auth | [Link](https://github.com/weboftrust/WOT-terms/wiki/skwa) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Simple KERI for Web Authentication. |
+| 402 | K | n | simple-keri-for-web-auth |  | simple-keri-for-web-auth | A KERI implementation that sacrifices performance or other non-security feature for usability. | [Link](https://github.com/weboftrust/WOT-terms/wiki/simple-keri-for-web-auth) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A KERI implementation sacrificing performance or other non-security features for usability. |
+| 403 | K | r | KRAM |  | KRAM | KERI Request Authentication Method for replay protection | [Link](https://github.com/weboftrust/WOT-terms/wiki/KRAM) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Keri requests an authentication method for replay protection. |
+| 404 | K | r | keri-request-authentication-method |  | keri-request-authentication-method | KERI Request Authentication Method for replay protection | [Link](https://github.com/weboftrust/WOT-terms/wiki/keri-request-authentication-method) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Keri requests an authentication method for replay protection. |
+| 405 | K | n | juror |  | juror | performs duplicity detection on events and event receipts | [Link](https://github.com/weboftrust/WOT-terms/wiki/juror) | Link | 3 |  |  |  |  |  |  |  |  |  |  | performs duplicate detection on events and event receipts |
+| 406 | K | n | jury |  | jury | set of entities or components acting as jurors | [Link](https://github.com/weboftrust/WOT-terms/wiki/jury) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A group of entities or components that act as jurors. |
+| 407 | K | n | opcode |  | opcode | provide stream processing instructions that are more general and flexible | [Link](https://github.com/trustoverip/acdc/wiki/opcode) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Provide more general and flexible stream processing instructions. |
+| 408 | K | n | version-code |  | version-code | tells you which set of tables to load and it tells the table state. | [Link](https://github.com/weboftrust/WOT-terms/wiki/version-code) | Link | 3 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 409 | K | n | strip-parameter |  | strip-parameter | tells us what part of the CESR stream will be parsed by which code | [Link](https://github.com/weboftrust/WOT-terms/wiki/strip-parameter) | Link | 3 |  |  |  |  |  |  |  |  |  |  | This text shows which code will parse each part of the CESR stream. |
+| 410 | K | n | parside |  | parside | parser library for Composable Event Streaming Representation (CESR) | [Link](https://github.com/weboftrust/WOT-terms/wiki/parside) | Link | 3 |  |  |  |  |  |  |  |  |  |  | CESR parser library |
+| 411 | K | n | version-string |  | version-string | a workaround to make JSON, CBOR and MGPK self-framing in CESR | [Link](https://github.com/weboftrust/WOT-terms/wiki/version-string) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A workaround to make JSON, CBOR, and MGPK self-framing in CESR. |
+| 412 | K | n | cesride |  | cesride | cryptographic primitives for use with Composable Event Streaming Representation (CESR) | [Link](https://github.com/weboftrust/WOT-terms/wiki/cesride) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Cryptographic primitives for CESR. |
+| 413 | K | n | sniffer |  | sniffer | the sniffer is part of Parside and detects if the CESR stream contains CESR binary, CESR Text, JSON, CBOR, MGPK | [Link](https://github.com/weboftrust/WOT-terms/wiki/sniffer) | Link | 3 |  |  |  |  |  |  |  |  |  |  | The sniffer, which is part of Parside, detects CESR binary, CESR Text, JSON, CBOR, and MGPK in the CESR stream. |
+| 414 | G | n | PRNG |  | PRNG | Pseudorandom Number Generator | [Link](https://github.com/trustoverip/acdc/wiki/PRNG) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Pseudorandom Number Generator |
+| 415 | G | n | CSPRNG |  | CSPRNG | Cryptographically Secure Pseudorandom Number Generator | [Link](https://github.com/trustoverip/acdc/wiki/CSPRNG) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Cryptographically Secure PRNG |
+| 416 | G | n | FFI |  | FFI | Foreign Function Interface | [Link](https://github.com/weboftrust/WOT-terms/wiki/FFI) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Foreign Function Interface (FFI) |
+| 417 | G | n | foreign-function-interface |  | foreign-function-interface | Is a mechanism by which a program written in one programming language that can call routines or make use of services written or compiled in another one | [Link](https://github.com/weboftrust/WOT-terms/wiki/foreign-function-interface) | Link | 2 |  |  |  |  |  |  |  |  |  |  | It is a way for a program in one programming language to call routines or utilize services from another language. |
+| 418 | G | n | HDK |  | HDK | hierchical deterministic key | [Link](https://github.com/trustoverip/acdc/wiki/HDK) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Hierarchical deterministic key. |
+| 419 | G | n | HSM |  | HSM | hardware security module | [Link](https://github.com/trustoverip/acdc/wiki/HSM) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Hardware security module |
+| 420 | K | v | partial-disclosure |  | partial-disclosure | an ACDC attribute section that can disclosed (a nested branch in a tree), you can either decide to disclose or not | [Link](https://github.com/trustoverip/acdc/wiki/partial-disclosure) | Link | 3 |  |  |  |  |  |  |  |  |  |  | ACDC attribute section can be disclosed, like a nested branch in a tree. You have the option to disclose or not. |
+| 421 | K | v | selective-disclosure |  | selective-disclosure | selective disclosure is a list of field maps, that you can choose to blind and publish, however all are disclosured. | [Link](https://github.com/trustoverip/acdc/wiki/selective-disclosure) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Selective disclosure is a list of field maps that you can choose to blind and publish. However, all of them are disclosed. |
+| 422 | K | v | full-disclosure |  | full-disclosure | a disclosure of data in all its details | [Link](https://github.com/trustoverip/acdc/wiki/full-disclosure) | Link | 1 |  |  |  |  |  |  |  |  |  |  | data disclosure |
+| 423 | K | r | threshold-of-accountable-duplicity |  | threshold-of-accountable-duplicity | Controller provides itself with any degree of protection by giving a minimum number of confirming witnesses sufficient given a certain accountability. | [Link](https://github.com/weboftrust/WOT-terms/wiki/threshold-of-accountable-duplicity) | Link | 3 |  |  |  |  |  |  |  |  |  |  | The controller protects itself by having a few confirming witnesses to ensure accountability. |
+| 424 | K | n | TOAD |  | TOAD | threshold of accountable duplicity; provided by controller concerning witnesses | [Link](https://github.com/weboftrust/WOT-terms/wiki/KERIA) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Accountable duplicity threshold provided by controller for witnesses. |
+| 425 | K | n | keride |  | keride | Rust library for Key Event Receipt Infrastructure | [Link](https://github.com/weboftrust/WOT-terms/wiki/keride) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Rust lib for Key Event Receipt |
+| 426 | K | n | KERIA |  | KERIA | KERI agent in the cloud | Link | Link | 3 |  |  |  |  |  |  |  |  |  |  | KERI cloud agent |
+| 427 | K | r | Signifide |  | Signifide | signing at the edge | [Link](https://github.com/weboftrust/WOT-terms/wiki/Signifide) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Signing on the edge. |
+| 428 | K | n | kiwi |  | kiwi | UI tooling for working with KERI | [Link](https://github.com/weboftrust/WOT-terms/wiki/kiwi) | Link | 3 |  |  |  |  |  |  |  |  |  |  | UI tooling for KERI |
+| 429 | G | n | hardware-security-module |  | hardware-security-module | a physical computing device that safeguards and manages secrets (most importantly digital keys) | [Link](https://github.com/weboftrust/WOT-terms/wiki/hardware-security-module) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A device that safeguards and manages secrets, specifically digital keys. |
+| 430 | G | n | hierchical-deterministic-keys |  | hierchical-deterministic-keys | a type of deterministic bitcoin wallet derived from a known seed, that allow for the creation of child keys from the parent key | [Link](https://github.com/weboftrust/WOT-terms/wiki/hierchical-deterministic-keys) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A deterministic bitcoin wallet can be created from a known seed, allowing for the generation of child keys from the parent key. |
+| 431 | K | r | SKRAP |  | SKRAP | Signify/KERIA Request Authentication Protocol | [Link](https://github.com/weboftrust/WOT-terms/wiki/SKRAP) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Signify/KERIA Authentication Protocol Request |
+| 432 | K | r | signify-keria-request-authentication-protocol |  | signify-keria-request-authentication-protocol | The KERIA service will expose 3 separate HTTP endpoints on 3 separate network interfaces | [Link](https://github.com/weboftrust/WOT-terms/wiki/signify-keria-request-authentication-protocol) | Link | 3 |  |  |  |  |  |  |  |  |  |  | The KERIA service will have 3 HTTP endpoints on 3 network interfaces. |
+| 433 | S | n | dead-attack |  | dead-attack | an attack on an establishment event that occurs after the Key-state for that event has become stale | [Link](https://github.com/weboftrust/WOT-terms/wiki/dead-attack) | Link |  |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 434 | K | v | prefixing |  | prefixing | prefixing | [Link](https://github.com/weboftrust/WOT-terms/wiki/prefixing) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Prefixing |
+| 435 | K | v | pathing |  | pathing | enables sending portions of a credential | [Link](https://github.com/weboftrust/WOT-terms/wiki/pathing) | Link | 3 |  |  |  |  |  |  |  |  |  |  | enables sending parts of a credential |
+| 436 | K | v | parsing |  | parsing | parsing | [Link](https://github.com/weboftrust/WOT-terms/wiki/parsing) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Parsing |
+| 437 | K | r | bespoke-credential |  | bespoke-credential | It's a custom issuance of the presentation of other ACDCs, it serves as an on-the-fly contract with the issuee; it's a self-referencing and self-contained contract | [Link](https://github.com/trustoverip/acdc/wiki/bespoke-credential) | Link | 3 |  |  |  |  |  |  |  |  |  |  | It is a customized presentation of other ACDCs. It serves as a contract with the issuee on-the-fly. It is a self-referencing and self-contained contract. |
+| 438 | K | n | KERIMask |  | KERIMask | A wallet similar to MetaMask that will connect to KERIA servers in order for a person to control AIDs from their browser. | [Link](https://github.com/weboftrust/WOT-terms/wiki/KERIMask) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A MetaMask-like wallet to connect to KERIA servers, enabling browser-based control of AIDs. |
+| 439 | K | n | KERISSE |  | KERISSE | KERI Suite Search Engine | [Link](https://github.com/weboftrust/WOT-terms/wiki/KERISSE) | Link | 1 |  |  |  |  |  |  |  |  |  |  | KERI Search Engine |
+| 440 | K | n | keri-suite |  | keri-suite | is the set of inter-related developments (KERI, ACDC, OOBI, CESR, IPEX, etc) under the Web-of -Trust user on Github | [Link](https://github.com/weboftrust/WOT-terms/wiki/keri-suite) | Link | 1 |  |  |  |  |  |  |  |  |  |  | This is a collection of interconnected developments (KERI, ACDC, OOBI, CESR, IPEX, etc.) used by the Web-of-Trust user on Github. |
+| 441 | K | n | ndigs |  | ndigs | Digests of keys, used to prove control over keys or to hide keys | [Link](https://github.com/weboftrust/WOT-terms/wiki/ndigs) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Key digests are used to prove control over keys or conceal them. |
+| 442 | K | n | verfer |  | verfer | a primitive that represents a public key | [Link](https://github.com/weboftrust/WOT-terms/wiki/verfer) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A public key primitive. |
+| 443 | K | n | diger |  | diger | a primitive that represents a digest | [Link](https://github.com/weboftrust/WOT-terms/wiki/diger) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A primitive representing a digest. |
+| 444 | K | n | cigar |  | cigar | an unindexed signature | [Link](https://github.com/weboftrust/WOT-terms/wiki/cigar) | Link | 3 |  |  |  |  |  |  |  |  |  |  | an unindexed signature. |
+| 445 | K | n | siger |  | siger | an indexed signature used within KERI when there are multiple current keys to an identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/siger) | Link | 3 |  |  |  |  |  |  |  |  |  |  | An indexed signature is used in KERI when there are multiple current keys for an identifier. |
+| 446 | K | n | signer |  | signer | a primitive that represents a private key | [Link](https://github.com/weboftrust/WOT-terms/wiki/signer) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A primitive representing a private key. |
+| 447 | K | n | salter |  | salter | a primitive that represents a seed that has the ability to generate new Signers | [Link](https://github.com/weboftrust/WOT-terms/wiki/salter) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A seed that can generate new Signers. |
+| 448 | G | n | LLM |  | LLM | Large Language Model | [Link](https://github.com/weboftrust/WOT-terms/wiki/LLM) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Language Model |
+| 449 | G | n | large-language-model |  | large-language-model | Is a language model consisting of a neural network with many parameters | [Link](https://github.com/weboftrust/WOT-terms/wiki/large-language-model) | Link | 2 |  |  |  |  |  |  |  |  |  |  | The language model is a neural network with numerous parameters. |
+| 450 | K | n | ixn |  | ixn | Field name for Interaction Event; its content contains a hash pointer | [Link](https://github.com/weboftrust/WOT-terms/wiki/ixn) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Interaction Event Field: Contains a hash pointer. |
+| 451 | K | n | rot |  | rot | Field name for Rotation Event; its content contains a hash pointer | [Link](https://github.com/weboftrust/WOT-terms/wiki/rot) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Field name: Rotation Event Content: Contains a hash pointer |
+| 452 | G | n | JSON |  | JSON | JavaScript Object Notation | [Link](https://github.com/weboftrust/WOT-terms/wiki/JSON) | Link | 1 |  |  |  |  |  |  |  |  |  |  | JavaScript Object Notation |
+| 453 | K | v | icp |  | icp | incept, inception | [Link](https://github.com/weboftrust/WOT-terms/wiki/icp) | Link | 3 |  |  |  |  |  |  |  |  |  |  | inception |
+| 454 | K | v | vcp |  | vcp | vdr incept, verifiable data registry inception | [Link](https://github.com/weboftrust/WOT-terms/wiki/vcp) | Link | 3 |  |  |  |  |  |  |  |  |  |  | VDR, Verifiable Data Registry, inception |
+| 455 | K | v | bis |  | bis | backed vc issue, registry-backed transaction event log credential issuance | [Link](https://github.com/weboftrust/WOT-terms/wiki/bis) | Link | 3 |  |  |  |  |  |  |  |  |  |  | VC issuance, registry-backed transaction log for credential issuance. |
+| 456 | G | n | concise-binary-object-representation |  | concise-binary-object-representation | It is a binary data serialization format loosely based on JSON | [Link](https://github.com/weboftrust/WOT-terms/wiki/concise-binary-object-representation) | Link | 3 |  |  |  |  |  |  |  |  |  |  | It's a binary data serialization format loosely based on JSON. |
+| 457 | K | v | brv |  | brv | backed vc revoke, registry-backed transaction event log credential revocation | [Link](https://github.com/weboftrust/WOT-terms/wiki/brv) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Revoked VC, registry-backed transaction event log for credential revocation. |
+| 458 | K | v | vrt |  | vrt | vdr rotate, verifiable data registry rotation | [Link](https://github.com/weboftrust/WOT-terms/wiki/vrt) | Link | 3 |  |  |  |  |  |  |  |  |  |  | VDR Rotate: Verifiable Data Registry Rotation. |
+| 459 | K | r | secure-private-authentic-confidentiality |  | secure-private-authentic-confidentiality |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/secure-private-authentic-confidentiality) | Link | 3 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 460 | K | r | SPAC |  | SPAC | secure private authentic confidentiality | [Link](https://github.com/weboftrust/WOT-terms/wiki/SPAC) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Secured, private, authentic, confidential. |
+| 461 | K | r | dead-drop |  | dead-drop | a presenter controls the disclosure so you can't re-identify the data | [Link](https://github.com/weboftrust/WOT-terms/wiki/dead-drop) | Link | 3 |  |  |  |  |  |  |  |  |  |  | The presenter controls the disclosure, preventing data re-identification. |
+| 462 | K | n | ample |  | ample | minimum required number of participants in an event to have a supermajority in the consensus agreement algorithm (KAACE) in KERI | [Link](https://github.com/weboftrust/WOT-terms/wiki/ample) | Link | 3 |  |  |  |  |  |  |  |  |  |  | The minimum number of participants needed for a supermajority in the consensus agreement algorithm (KAACE) in KERI. |
+| 463 | G | r | supermajority |  | supermajority | Sufficient majority immune to certain kinds of attacks or faults | [Link](https://github.com/weboftrust/WOT-terms/wiki/supemajority) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Sufficient majority immune to certain attacks or faults. |
+| 464 | G | n | CBOR |  | CBOR | concise binary object representation | [Link](https://github.com/weboftrust/WOT-terms/wiki/CBOR) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Concise binary object rep |
+| 465 | K | n | tholder |  | tholder | t-holder object that supports fractionally-weighted thresholds | [Link](https://github.com/weboftrust/WOT-terms/wiki/tholder) | Link | 3 |  |  |  |  |  |  |  |  |  |  | T-holder object supporting fractional-weighted thresholds |
+| 466 | K | n | bexter |  | bexter | A class (programming code) in CESR that preserves its integrity in a round-trip conversion even though it offers variable length text | [Link](https://github.com/weboftrust/WOT-terms/wiki/bexter) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A class in CESR that maintains its integrity in a round-trip conversion despite variable length text. |
+| 467 | K | r | moobi |  | moobi | to share a bunch of different end-points (oobis) all at once | [Link](https://github.com/weboftrust/WOT-terms/wiki/moobi) | Link | 3 |  |  |  |  |  |  |  |  |  |  | to share multiple end-points (oobis) simultaneously |
+| 468 | G | n | ts-node |  | ts-node | npm package that lets you run typescript from a shell | [Link](https://github.com/weboftrust/WOT-terms/wiki/ts-node) | Link | 3 |  |  |  |  |  |  |  |  |  |  | npm package for running TypeScript from a shell. |
+| 469 | K | n | interceptor |  | interceptor | a keria class that allows to push events happening inside the cloud agent to other backend processes | [Link](https://github.com/weboftrust/WOT-terms/wiki/interceptor) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A Keria class enables pushing cloud agent events to other backend processes. |
+| 470 | K | n | salty-nonce-blinding-factor |  | salty-nonce-blinding-factor | Selectively share a secret and hide information with this secret | [Link](https://github.com/weboftrust/WOT-terms/wiki/salty-nonce-blinding-factor) | Link | 3 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 471 | K | n | ilk |  | ilk | short for message type | [Link](https://github.com/weboftrust/WOT-terms/wiki/ilk) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Short for message type. |
+| 472 | K | v | dip |  | dip | delcept, delegated inception | [Link](https://github.com/weboftrust/WOT-terms/wiki/dip) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Delcept, Delegated Inception. |
+| 473 | K | v | drt |  | drt | deltate, delegated rotation | [Link](https://github.com/weboftrust/WOT-terms/wiki/drt) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Deltate: delegated rotation. |
+| 474 | K | n | rct |  | rct | receipt | [Link](https://github.com/weboftrust/WOT-terms/wiki/rct) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Receipt. |
+| 475 | K | n | ksn |  | ksn | sate, key state notice | [Link](https://github.com/weboftrust/WOT-terms/wiki/ksn) | Link | 3 |  |  |  |  |  |  |  |  |  |  | State key notice |
+| 476 | K | v | qry |  | qry | query | [Link](https://github.com/weboftrust/WOT-terms/wiki/qry) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Query. |
+| 477 | K | v | rpy |  | rpy | reply | [Link](https://github.com/weboftrust/WOT-terms/wiki/rpy) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Reply. |
+| 478 | K | v | exn |  | exn | exchange | [Link](https://github.com/weboftrust/WOT-terms/wiki/exn) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Exchange. |
+| 479 | K | v | exp |  | exp | expose, sealed data exposition | [Link](https://github.com/weboftrust/WOT-terms/wiki/exp) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Data exposure. |
+| 480 | K | v | iss |  | iss | vc issue, verifiable credential issuance | [Link](https://github.com/weboftrust/WOT-terms/wiki/iss) | Link | 3 |  |  |  |  |  |  |  |  |  |  | VC issuance: verifiable credential issuance. |
+| 481 | K | v | rev |  | rev | vc revoke, verifiable credential revocation | [Link](https://github.com/weboftrust/WOT-terms/wiki/rev) | Link | 3 |  |  |  |  |  |  |  |  |  |  | VC revocation, or verifiable credential revocation. |
+| 482 | K | n | vdr |  | vdr | verifiable data registry | [Link](https://github.com/weboftrust/WOT-terms/wiki/vdr) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Verifiable data registry. |
+| 483 | K | r | KATE |  | KATE | Kate = KERI at the Edge | [Link](https://github.com/weboftrust/WOT-terms/wiki/KATE) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Kate at the Edge = KERI |
+| 484 | K | v | spurn |  | spurn | Reject | [Link](https://github.com/weboftrust/WOT-terms/wiki/spurn) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Reject. |
+| 485 | G | v | dnd |  | dnd | do not delegate | [Link](https://github.com/WebOfTrust/WOT-terms/wiki/dnd) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Don't delegate. |
+| 486 | G | v | revocation |  | revocation | The act of recall or annulment. It is the cancelling of an act, the recalling of a grant or privilege. | [Link](https://github.com/weboftrust/WOT-terms/wiki/revocation) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Recall or annulment is the act of canceling or recalling an act, grant, or privilege. |
+| 487 | G | n | verifiable-data-registry |  | verifiable-data-registry | a Verifiable Data Structure that actually holds content | [Link](https://github.com/weboftrust/WOT-terms/wiki/verifiable-data-registry) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A verifiable data structure that holds content securely. |
+| 488 | G | n | VDR |  | VDR | Verifiable Data Registry, a Verifiable Data Structure that actually holds content | [Link](https://github.com/weboftrust/WOT-terms/wiki/VDR) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Verifiable Data Registry, a structure that holds content and is verifiable. |
+| 489 | G | r | E2E |  | E2E | end-to-end | [Link](https://github.com/weboftrust/WOT-terms/wiki/E2E) | Link | 1 |  |  |  |  |  |  |  |  |  |  | End-to-end. |
+| 490 | G | r | end-to-end |  | end-to-end | Inter-host communication and data flow transformations, considered in motion and at rest | [Link](https://github.com/weboftrust/WOT-terms/wiki/end-to-end) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Inter-host communication and data flow transformations, both in motion and at rest. |
+| 491 | K | v | duplicity-detection |  | duplicity-detection | A mechanism to detect duplicity in cryptographically secured event log | [Link](https://github.com/weboftrust/WOT-terms/wiki/duplicity-detection) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Detecting duplicity in cryptographically secured event log |
+| 492 | G | r | double-spend-proof |  | double-spend-proof | Total global ordering of transactions so that you can't spend value twice | [Link](https://github.com/weboftrust/WOT-terms/wiki/double-spend-proof) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Global ordering prevents double spending. |
+| 493 | G | v | MFA |  | MFA | multi-factor authentication | [Link](https://github.com/weboftrust/WOT-terms/wiki/MFA) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Multi-factor authentication. |
+| 494 | G | v | multi-factor-authentication |  | multi-factor-authentication | Authentication by combining multiple security factors, e.g. what you know, what you have and what you are. | [Link](https://github.com/weboftrust/WOT-terms/wiki/multi-factor-authentication) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Authentication by combining multiple security factors, such as knowledge, possession, and identity. |
+| 495 | G | r | threshold-structure-security |  | threshold-structure-security | Allows for weaker key management or execution environment infrastructure individually, but achieves greater overall security by multiplying the number of attack surfaces | [Link](https://github.com/weboftrust/WOT-terms/wiki/threshold-structure-security) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Allows for weaker management or execution environment, but improves overall security by increasing attack surfaces. |
+| 496 | G | n | TEE |  | TEE | trusted-execution-environment; protected hardware/software/firmware security system | [Link](https://github.com/weboftrust/WOT-terms/wiki/TEE) | Link | 2 |  |  |  |  |  |  |  |  |  |  | trusted execution environment: secure hardware/software/firmware system |
+| 497 | G | n | trusted-execution-environment |  | trusted-execution-environment | Protected hardware/software/firmware security system | [Link](https://github.com/weboftrust/WOT-terms/wiki/trusted-execution-environment) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Protected hardware and software security system |
+| 498 | G | r | security-overlay-properties-trillema |  | security-overlay-properties-trillema | an identifier system has some degree of any combination of the three properties authenticity, privacy and confidentiality, but not all three completely | [Link](https://github.com/weboftrust/WOT-terms/wiki/security-overlay-properties-trillema) | Link | 3 |  |  |  |  |  |  |  |  |  |  | An identifier system possesses some combination of the three properties: authenticity, privacy, and confidentiality, but never all three to their fullest extent. |
+| 499 | S | r | autonomic-trust-basis |  | autonomic-trust-basis | to form this we use an AID as the root-of-trust | [Link](https://github.com/weboftrust/WOT-terms/wiki/autonomic-trust-basis) | Link | 3 |  |  |  |  |  |  |  |  |  |  | To create this, we utilize an AID as the root of trust. |
+| 500 | S | n | autonomic-identifier |  | autonomic-identifier | self-managing self-certifying identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/autonomic-identifier) | Link | 2 |  |  |  |  |  |  |  |  |  |  | self-managing, self-certifying identifier. |
+| 501 | S | n | legitimized-human-meaningful-identifier |  | legitimized-human-meaningful-identifier | identifier authorised through its autonomic identifier couplet | [Link](https://github.com/weboftrust/WOT-terms/wiki/legitimized-human-meaningful-identifier) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Authorized identifier through an autonomous identifier couplet. |
+| 502 | S | n | LID |  | LID | Legitimized (or authorised) human meaningful identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/LID) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Human meaningful ID |
+| 503 | S | n | security |  | security | in identifier systems it means secure from exploit or compromise | [Link](https://github.com/weboftrust/WOT-terms/wiki/security) | Link | 1 |  |  |  |  |  |  |  |  |  |  | In identifier systems, it refers to being secure against exploits or compromises. |
+| 504 | S | a | secure |  | secure | in identifier systems it means secure from exploit or compromise | [Link](https://github.com/weboftrust/WOT-terms/wiki/secure) | Link | 1 |  |  |  |  |  |  |  |  |  |  | In identifier systems, it refers to being secure against exploits or compromises. |
+| 505 | K | r | univalent |  | univalent | having a unique and non-ambiguous identifier for each entity or resource | [Link](https://github.com/weboftrust/WOT-terms/wiki/univalent) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Each entity or resource should have a unique and unambiguous identifier. |
+| 506 | K | r | multi-valent |  | multi-valent | A situation in which a delegator may have multiple delegates thereby enabling elastic horizontal scalability. | [Link](https://github.com/weboftrust/WOT-terms/wiki/multi-valent) | Link | 2 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 507 | S | r | security-cost-performance-architecture-trade-off |  | security-cost-performance-architecture-trade-off |  | [Link](https://github.com/weboftrust/WOT-terms/wiki/security-cost-performance-architecture-trade-off) | Link | 3 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 508 | K | r | cooperative-delegation |  | cooperative-delegation | A type of delegation that needs both a delegator and a delegate to be established | [Link](https://github.com/weboftrust/WOT-terms/wiki/cooperative-delegation) | Link | 3 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 509 | G | n | TPM |  | TPM | trusted platform module; a device that enhances the security and privacy by providing hardware-based cryptographic functions | [Link](https://github.com/weboftrust/WOT-terms/wiki/TPM) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Trusted Platform Module (TPM) is a device that enhances security and privacy through hardware-based cryptographic functions. |
+| 510 | G | n | trusted-platform-module |  | trusted-platform-module | A device that enhances the security and privacy by providing hardware-based cryptographic functions | [Link](https://github.com/weboftrust/WOT-terms/wiki/trusted-platform-module) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A device that enhances security and privacy using hardware-based cryptographic functions. |
+| 511 | K | r | bivalent |  | bivalent | Two independent key management infrastructures with no movement of private keys between the two. | [Link](https://github.com/weboftrust/WOT-terms/wiki/bivalent) | Link | 2 |  |  |  |  |  |  |  |  |  |  | NO INPUT |
+| 512 | S | n | keri‐event‐stream |  | keri‐event‐stream | A stream of verifiable KERI data, consisting of the key event log and other data such as a transaction event log | [Link](https://github.com/weboftrust/WOT-terms/wiki/keri‐event‐stream) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A verifiable stream of KERI data, including the key event log and other transaction event logs. |
+| 513 | S | n | stale-key |  | stale-key | A stale key is an outdated or expired encryption key that should no longer be used for securing data | [Link](https://github.com/weboftrust/WOT-terms/wiki/stale-key) | Link | 2 |  |  |  |  |  |  |  |  |  |  | A stale key is an outdated or expired encryption key that shouldn't be used for securing data anymore. |
+| 514 | S | n | stale-event |  | stale-event | An outdated or irrelevant (key) event involving an expired encryption key that may compromise security | [Link](https://github.com/weboftrust/WOT-terms/wiki/stale-event) | Link | 2 |  |  |  |  |  |  |  |  |  |  | An obsolete or irrelevant event related to an expired encryption key that could jeopardize security. |
+| 515 | G | r | privacy |  | privacy | Privacy is the ability of an individual or group to seclude themselves or information about themselves | [Link](https://github.com/weboftrust/WOT-terms/wiki/privacy) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Privacy is the ability for individuals or groups to hide themselves or their personal information. |
+| 516 | G | n | confidentiality |  | confidentiality | a set of rules or a promise that limits the access or places restrictions on certain types of information | [Link](https://github.com/weboftrust/WOT-terms/wiki/confidentiality) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Rules or promises that limit access or place restrictions on certain information. |
+| 517 | K | n | RID |  | RID | Root autonomic identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/RID) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Root identifier |
+| 518 | K | n | root-autonomic-identifier |  | root-autonomic-identifier | An entity may provide the root-of-trust for some ecosystem (with delegations) via its root autonomic identier (AID). | [Link](https://github.com/weboftrust/WOT-terms/wiki/root-autonomic-identifier) | Link | 3 |  |  |  |  |  |  |  |  |  |  | An entity can offer the root-of-trust for an ecosystem through its root autonomic identifier (AID) and delegations. |
+| 519 | K | a | provenanced |  | provenanced | The act of verifying authenticity or quality of documented history or origin of something | [Link](https://github.com/weboftrust/WOT-terms/wiki/provenanced) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Verifying the authenticity or origin of something. |
+| 520 | K | r | non-interactive-authentication-design |  | non-interactive-authentication-design | Non-interactive Authentication Design | [Link](https://github.com/weboftrust/WOT-terms/wiki/non-interactive-authentication-design) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Non-interactive Authentication Design, shortened and with grammar corrected |
+| 521 | K | r | interactive-authentication-design |  | interactive-authentication-design | secure authentication through an interactive mechanism that requires a set of requests and responses or challenge responses with challenge response replies | [Link](https://github.com/weboftrust/WOT-terms/wiki/interactive-authentication-design) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Secure authentication is achieved through an interactive mechanism that involves requesting and responding with challenge responses. |
+| 522 | S | r | ESSR |  | ESSR | Encrypt Sender, Sign the Receiver | [Link](https://github.com/weboftrust/WOT-terms/wiki/ESSR) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Encrypt sender, sign receiver. |
+| 523 | S | n | VID |  | VID | Verifiable Identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/VID) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Verifiable ID |
+| 524 | S | r | encrypt‐sender‐sign‐receiver |  | encrypt‐sender‐sign‐receiver | Encrypt Sender, Sign the Receiver | [Link](https://github.com/weboftrust/WOT-terms/wiki/encrypt‐sender‐sign‐receiver) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Encrypt sender, sign receiver. |
+| 525 | S | n | verifiable-identifier |  | verifiable-identifier | Cryptographically verifiable authentic identifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/verifiable-identifier) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Cryptographically verifiable identifier |
+| 526 | S | n | trust-spanning-protocol |  | trust-spanning-protocol | Protocol using VIDs that signs every single message on the internet. | [Link](https://github.com/weboftrust/WOT-terms/wiki/trust-spanning-protocol) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Protocol using VIDs that signs every internet message. |
+| 527 | S | n | TSP |  | TSP | Trust spanning protocol, using VIDs that signs every single message on the internet. | [Link](https://github.com/weboftrust/WOT-terms/wiki/TSP) | Link | 2 |  |  |  |  |  |  |  |  |  |  | TrustSpan protocol, utilizing VIDs to sign every internet message. |
+| 528 | S | v | privacy-washing |  | privacy-washing | De-identification so that it provides a personal data safe harbour and could be legally acceptable forwarded | [Link](https://github.com/weboftrust/WOT-terms/wiki/privacy-washing) | Link | 1 |  |  |  |  |  |  |  |  |  |  | De-identification provides a safe harbor for personal data and can be legally acceptable when forwarded. |
+| 529 | S | n | DKR |  | DKR | Did:keri resolver | [Link](https://github.com/weboftrust/WOT-terms/wiki/DKR) | Link | 2 |  |  |  |  |  |  |  |  |  |  | Did Keri resolve? |
+| 530 | S | n | reputation |  | reputation | Consistent behaviour over time on the basis of which anyone else makes near-future decisions | [Link](https://github.com/weboftrust/WOT-terms/wiki/reputation) | Link | 1 |  |  |  |  |  |  |  |  |  |  | Consistent behavior over time on which others base near-future decisions. |
+| 531 | S | r | discovery |  | discovery | a discovery mechanism helps to locate and verify digital identities without relying on a central authority | [Link](https://github.com/weboftrust/WOT-terms/wiki/discovery) | Link | 1 |  |  |  |  |  |  |  |  |  |  | A discovery mechanism allows locating and validating digital identities without relying on a central authority. |
+| 532 | S | r | broken-object-level-authorization |  | broken-object-level-authorization | or BOLA, refers to security flaws where users can access data they shouldn't | [Link](https://github.com/weboftrust/WOT-terms/wiki/broken-object-level-authorization) | Link | 3 |  |  |  |  |  |  |  |  |  |  | BOLA stands for security flaws allowing unauthorized data access. |
+| 533 | S | n | BOLA |  | BOLA | Broken Object Level Authorization | [Link](https://github.com/weboftrust/WOT-terms/wiki/BOLA) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Broken Object-Level Authorization |
+| 534 | K | v | read-update-nullify |  | read-update-nullify | or "RUN"; Read, update, nullify are actions you can take on data, no create or delete | [Link](https://github.com/weboftrust/WOT-terms/wiki/read-update-nullify) | Link | 3 |  |  |  |  |  |  |  |  |  |  | "RUN": Read, update, and nullify are actions for data manipulation, without the ability to create or delete. |
+| 535 | K | v | RUN |  | RUN | read-update-nullify, actions you can take on data, no create or delete. | [Link](https://github.com/weboftrust/WOT-terms/wiki/RUN) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Read, update, and nullify data - these are the actions you can take. No creating or deleting is allowed. |
+| 536 | K | r | direct-mode |  | direct-mode | (one-to-one) trust mode in KERI, in which the identity controller establishes control via verified signatures of the controlling key-pair. | [Link](https://github.com/weboftrust/WOT-terms/wiki/direct-mode) | Link | 3 |  |  |  |  |  |  |  |  |  |  | KREI employs a one-to-one trust mode where the identity controller gains control through verified signatures of the controlling key-pair. |
+| 537 | K | r | indirect-mode |  | indirect-mode | (one-to-many) trust mode in KERI, which extends the direct trust basis with witnessed key event receipt logs (KERL) for validating events. | [Link](https://github.com/weboftrust/WOT-terms/wiki/indirect-mode) | Link | 3 |  |  |  |  |  |  |  |  |  |  | In KERI, there is a trust mode called one-to-many that adds witnessed key event receipt logs (KERL) to validate events. |
+| 538 | K | r | end-role |  | end-role | An end role is an authorization for one AID to serve in a role for another AID. | [Link](https://github.com/weboftrust/WOT-terms/wiki/end-role) | Link | 3 |  |  |  |  |  |  |  |  |  |  | An end role authorizes one AID to serve in another AID's role. |
+| 539 | K | n | hab |  | hab | A Hab is a keystore for one identifier. | [Link](https://github.com/weboftrust/WOT-terms/wiki/hab) | Link | 3 |  |  |  |  |  |  |  |  |  |  | A Hab is a store for one identifier. |
+| 540 | S | r | identity-assurance |  | identity-assurance | The heavy-lifting to be done to establish reputational trust, KERI is for attributional trust | [Link](https://github.com/weboftrust/WOT-terms/wiki/identity-assurance) | Link | 3 |  |  |  |  |  |  |  |  |  |  | Establishing reputational trust requires significant effort, while KERI is aimed at achieving attributional trust. |
+| 541 | S | r | attributional-trust |  | attributional-trust | You can't have reputation without attributional trust, KERI offers cryptographic root-of-trust | [Link](https://github.com/weboftrust/WOT-terms/wiki/attributional-trust) | Link | 2 |
+| 542 | S | r | reputational-trust |  | reputational-trust | identity-assurance by a trusted party | [Link](https://github.com/weboftrust/WOT-terms/wiki/reputational-trust) | Link | 2 |
+| 543 | G | n | ADR |  | ADR | Architectural Decision Records | [Link](https://github.com/weboftrust/WOT-terms/wiki/ADR) | Link | 2 |
+| 544 | G | n | architectural-decision-record |  | architectural-decision-record | justified software design choice that addresses an architectural requirement | [Link](https://github.com/weboftrust/WOT-terms/wiki/architectural-decision-record) | Link | 2 |
+| 545 | G | n | MIME-type |  | MIME-type | Also 'media type'; a standard way to indicate the nature and format of a file, like 'image/jpeg' for JPEG images, used on the internet. | [Link](https://github.com/weboftrust/WOT-terms/wiki/MIME-type) | Link | 1 |
+| 546 | G | n | media-type |  | media-type | Also 'MIME type'; a standard way to indicate the nature and format of a file, like 'image/jpeg' for JPEG images, used on the internet. | [Link](https://github.com/weboftrust/WOT-terms/wiki/media-type) | Link | 1 |
+| 547 | K | n | listed-identifier |  | listed-identifier | a list in an ACDC of authorised did:webs identifier + method | [Link](https://github.com/weboftrust/WOT-terms/wiki/listed-identifier) | Link | 3 |
+| 548 | S | r | designated-aliases |  | designated-aliases | An AID controller can designate aliases which are AID controlled identifiers such as a did:keri, did:webs, etc | [Link](https://github.com/weboftrust/WOT-terms/wiki/designated-aliases) | Link | 2 |
+| 549 | K | a | sniffable |  | sniffable | A stream is sniffable as soon as it starts with a CESR group code or field map | [Link](https://github.com/weboftrust/WOT-terms/wiki/sniffable) | Link | 3 |
+| 550 | K | n | reconciliation |  | reconciliation | Reconciliation is the process in which you decide to accept a fork of the KEL or not. | [Link](https://github.com/weboftrust/WOT-terms/wiki/reconciliation) | Link | 2 |
+| 551 | S | n | party |  | party | an entity who participates or is concerned in an action, proceeding, plan, etc. | [Link](https://github.com/weboftrust/WOT-terms/wiki/party) | Link | 1 |
+| 553 | S | n | verification |  | verfication | An action an agent (of a principal) performs to determine the authenticity of a claim or other digital object using a cryptographic key. | [Link](https://github.com/weboftrust/WOT-terms/wiki/verification) | Link | 2 |
+| 554 | K | n | kever |  | kever | Kever is a key event verifier | [Link](https://github.com/weboftrust/WOT-terms/wiki/kever) | Link | 3 |
+| 555 | S | n | kerific |  | kerific | kerific is a front plugin or extension for Chrome and Brave, that matches words in text on the web that offers buttons to various SSI glossaries and definitions. | [Link](https://github.com/weboftrust/WOT-terms/wiki/kerific) | Link | 1 |
+| 556 | K | r | access-controlled-interaction |  | access-controlled-interaction | Access controlled actions like submitting a report | [Link](https://github.com/weboftrust/WOT-terms/wiki/access-controlled-interaction) | Link | 3 |
+| 557 | K | r | registration-interaction |  | registration-interaction | Setup/Registration interaction, new AID and authorization to establish access control | [Link](https://github.com/weboftrust/WOT-terms/wiki/registration-interaction) | Link | 3 |
+| 559 | K | n | xip |  | xip | A message that allows a transaction set to become duplicity evident | [Link](https://github.com/weboftrust/WOT-terms/wiki/xip) | Link | 2 |
+| 560 | K | n | KAPI |  | KAPI | KERI API | [Link](https://github.com/weboftrust/WOT-terms/wiki/KAPI) | Link | 1 |
+| 561 | S | a | self-authenticating |  | self-authenticating | self-certifying | [Link](https://github.com/weboftrust/WOT-terms/wiki/self-authenticating) |
+| 562 | K | n | configuration-traits |  | configuration-traits | A list of specially defined strings representing a configuration of a KEL | [Link](https://github.com/weboftrust/WOT-terms/wiki/configuration-traits) | Link | 3 |
+| 563 | K | a | abandoned-identifier |  | abandoned-identifier | An AID is abandoned when there is no further possibility to register any next key event in a KEL | [Link](https://github.com/WebOfTrust/WOT-terms/wiki/abandoned-identifier) |
+| 564 | K | n | streamer |  | streamer | A convenience class for supporting stream parsing, including nested CESR streams | [Link](https://github.com/WebOfTrust/WOT-terms/wiki/streamer) |
+| 565 | G | n | canonicalization |  | canonicalization | A process for converting data that has more than one possible representation into a "standard" form | [Link](https://github.com/WebOfTrust/WOT-terms/wiki/canonicalization) |
+
+
+
+
+---
+title: Indexed in KERISSE
+description: Indexed at 02 April 2024 1740
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/overview/indexed-in-KERISSE/index
+  md: https://weboftrust.github.io/keridoc/docs/overview/indexed-in-KERISSE/index.md
+---
+
+# Indexed in KERISSE
+
+Indexed at 02 April 2024 17:21:40
+
+Number of indexed pages: 119
+
+1.  [](https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf)[https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif\_acceptedjurisdictions\_v1.4.pdf](https://www.gleif.org/about-lei/code-lists/gleif-accepted-legal-jurisdictions-code-list/gleif_acceptedjurisdictions_v1.4.pdf)
+2.  [](https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_overview_changes_ra_list_v1.0_to_v1.7.pdf)[https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23\_overview\_changes\_ra\_list\_v1.0\_to\_v1.7.pdf](https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_overview_changes_ra_list_v1.0_to_v1.7.pdf)
+3.  [](https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf)[https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23\_ra\_list\_v1.7.pdf](https://www.gleif.org/about-lei/code-lists/gleif-registration-authorities-list/2022-03-23_ra_list_v1.7.pdf)
+4.  [](https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf)[https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf](https://www.gleif.org/about-lei/code-lists/iso-20275-entity-legal-forms-code-list/2021-10-21-elf-code-list-v1.4.1.pdf)
+5.  [](https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf)[https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf](https://www.gleif.org/about-lei/code-lists/iso-5009-official-organizational-roles-code-list/official-organizational-roles-code-list-version-1.0.pdf)
+6.  [](https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf)[https://www.gleif.org/about-lei/common-data-file-format/2022-02-22\_cdf\_questions\_and\_answers\_v2.4.pdf](https://www.gleif.org/about-lei/common-data-file-format/2022-02-22_cdf_questions_and_answers_v2.4.pdf)
+7.  [](https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf)[https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07\_state-transition-validation-rules\_v2.7.1\_final.pdf](https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-1-data-lei-cdf-3-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf)
+8.  [](https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf)[https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07\_state-transition-validation-rules\_v2.7.1\_final.pdf](https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-relationship-record-rr-cdf-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf)
+9.  [](https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf)[https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07\_state-transition-validation-rules\_v2.7.1\_final.pdf](https://www.gleif.org/about-lei/common-data-file-format/current-versions/level-2-data-reporting-exceptions-2-1-format/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf)
+10.  [](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf)[https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30\_guiding\_document\_for\_the\_transition\_period\_v1.1-final.pdf](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_guiding_document_for_the_transition_period_v1.1-final.pdf)
+11.  [](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf)[https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30\_xslt-documentation\_v1.1-final.pdf](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-09-30_xslt-documentation_v1.1-final.pdf)
+12.  [](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf)[https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23\_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description\_v1.2-final.pdf](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2021-11-23_lei-cdf-3.1-and-rr-cdf-2.1-and-repex-cdf-2.1-samples-description_v1.2-final.pdf)
+13.  [](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf)[https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09\_upcoming-cdf-xml-comprehensive-example-description\_v1.0-final.pdf](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/2022-02-09_upcoming-cdf-xml-comprehensive-example-description_v1.0-final.pdf)
+14.  [](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf)[https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf](https://www.gleif.org/about-lei/common-data-file-format/current-versions/supporting-documents/gleif-data-consumers-quick-guide.pdf)
+15.  [](https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf)[https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16\_reporting-exceptions-format-v1-1.pdf](https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_reporting-exceptions-format-v1-1.pdf)
+16.  [](https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf)[https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16\_rr-cdf-v1-1.pdf](https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-16_rr-cdf-v1-1.pdf)
+17.  [](https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf)[https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21\_lei-cdf-v2-1.pdf](https://www.gleif.org/about-lei/common-data-file-format/previous-versions/2017-03-21_lei-cdf-v2-1.pdf)
+18.  [](https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/how_to_identify_your_new_lou_after_the_termination_of_business_entity_data_b_v.pdf)[https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/how\_to\_identify\_your\_new\_lou\_after\_the\_termination\_of\_business\_entity\_data\_b\_v.pdf](https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/how_to_identify_your_new_lou_after_the_termination_of_business_entity_data_b_v.pdf)
+19.  [](https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf)[https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023\_03\_28\_registration-agents-governance-framework\_1.0.pdf](https://www.gleif.org/about-lei/get-an-lei-find-lei-issuing-organizations/registration-agents/2023_03_28_registration-agents-governance-framework_1.0.pdf)
+20.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties_final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties\_final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-08-ancillary-duties_final.pdf)
+21.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act\_final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-11-swiss-data-protection-act_final.pdf)
+22.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-13-individual-deviations-from-the-ma_final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-13-individual-deviations-from-the-ma\_final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2016-02-01-ma-appendix-13-individual-deviations-from-the-ma_final.pdf)
+23.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement\_final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-01-non-disclosure-agreement_final.pdf)
+24.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif\_final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2017-09-01-ma-appendix-09a-terms-of-use-gleif_final.pdf)
+25.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08_ma-appendix-05-lou-contract-requirements.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08\_ma-appendix-05-lou-contract-requirements.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2018-02-08_ma-appendix-05-lou-contract-requirements.pdf)
+26.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2020-06-01-ma-master-agreement-1.3-final.pdf)
+27.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist\_final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-05-31-ma-appendix-02-accreditation-checklist_final.pdf)
+28.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30\_ma-appendix-07-payments\_v1.4-final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2021-11-30_ma-appendix-07-payments_v1.4-final.pdf)
+29.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla\_2.1.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-03-31-ma-appendix-06-sla_2.1.pdf)
+30.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11_ma-appendix-10-accreditation-verification_1.4final.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11\_ma-appendix-10-accreditation-verification\_1.4final.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-05-11_ma-appendix-10-accreditation-verification_1.4final.pdf)
+31.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2022-6-30-ma-appendix-02-accreditation-manual.pdf)
+32.  [](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2023-03-28-ma-appendix-14-third-party-services-v1.3.pdf)[https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2023-03-28-ma-appendix-14-third-party-services-v1.3.pdf](https://www.gleif.org/about-lei/the-lifecycle-of-a-lei-issuer/gleif-accreditation-of-lei-issuers/required-documents/2023-03-28-ma-appendix-14-third-party-services-v1.3.pdf)
+33.  [](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05_gleif_gifi-relationship-group-charter_v1.pdf)[https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05\_gleif\_gifi-relationship-group-charter\_v1.pdf](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-gifi-relationship-group/2018-11-05_gleif_gifi-relationship-group-charter_v1.pdf)
+34.  [](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf)[https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06\_gleif-vendor-services-relationship-group-charter\_v1.4.pdf](https://www.gleif.org/about/gleif-engagement/gleif-stakeholder-groups/gleif-vendor-relationship-group/2022-09-06_gleif-vendor-services-relationship-group-charter_v1.4.pdf)
+35.  [](https://www.gleif.org/about/gleif-services/iso-20000-certification/itms_707855.pdf)[https://www.gleif.org/about/gleif-services/iso-20000-certification/itms\_707855.pdf](https://www.gleif.org/about/gleif-services/iso-20000-certification/itms_707855.pdf)
+36.  [](https://www.gleif.org/about/gleif-services/service-reports/gleif-service-report-june-2023/2023-07-14_gleif_service_report_v1.0.pdf)[https://www.gleif.org/about/gleif-services/service-reports/gleif-service-report-june-2023/2023-07-14\_gleif\_service\_report\_v1.0.pdf](https://www.gleif.org/about/gleif-services/service-reports/gleif-service-report-june-2023/2023-07-14_gleif_service_report_v1.0.pdf)
+37.  [](https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf)[https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf](https://www.gleif.org/about/governance/by-laws/gleif-by-laws-final-27-october-2016.pdf)
+38.  [](https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf)[https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf](https://www.gleif.org/about/governance/mou-between-gleif-and-roc/20150923-ROC-GLEIF-MOU-final-signed.pdf)
+39.  [](https://www.gleif.org/about/governance/policies/16-09-16_General_Accounting_FIN007_v.1_final.pdf)[https://www.gleif.org/about/governance/policies/16-09-16\_General\_Accounting\_FIN007\_v.1\_final.pdf](https://www.gleif.org/about/governance/policies/16-09-16_General_Accounting_FIN007_v.1_final.pdf)
+40.  [](https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf)[https://www.gleif.org/about/governance/policies/16-09-16\_IA\_Charter\_v.1\_final.pdf](https://www.gleif.org/about/governance/policies/16-09-16_IA_Charter_v.1_final.pdf)
+41.  [](https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf)[https://www.gleif.org/about/governance/policies/2017-03-01\_board-code-of-conduct\_v1.0-final-approved.pdf](https://www.gleif.org/about/governance/policies/2017-03-01_board-code-of-conduct_v1.0-final-approved.pdf)
+42.  [](https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf)[https://www.gleif.org/about/governance/policies/2020-01-24\_whistleblowingpolicy\_v1.0-final-approved.pdf](https://www.gleif.org/about/governance/policies/2020-01-24_whistleblowingpolicy_v1.0-final-approved.pdf)
+43.  [](https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf)[https://www.gleif.org/about/governance/policies/2020-02-05\_bod\_travelandexpense\_policy\_v2.0-final-approved.pdf](https://www.gleif.org/about/governance/policies/2020-02-05_bod_travelandexpense_policy_v2.0-final-approved.pdf)
+44.  [](https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf)[https://www.gleif.org/about/governance/policies/2023-02-03\_conflict\_of\_interest\_policy\_1.1final.pdf](https://www.gleif.org/about/governance/policies/2023-02-03_conflict_of_interest_policy_1.1final.pdf)
+45.  [](https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf)[https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc\_20201001-1.pdf](https://www.gleif.org/about/governance/regulatory-oversight-committee-roc/roc_20201001-1.pdf)
+46.  [](https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf)[https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf](https://www.gleif.org/about/governance/statutes/gleif-20180807.pdf)
+47.  [](https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf)[https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05\_gleif-concatenated-file\_v2-4\_final.pdf](https://www.gleif.org/lei-data/gleif-concatenated-file/about-the-concatenated-file/2017-02-05_gleif-concatenated-file_v2-4_final.pdf)
+48.  [](https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf)[https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10\_checkforduplicatedictionary\_v1.2-final.pdf](https://www.gleif.org/lei-data/gleif-data-quality-management/proactive-management/2021-11-10_checkforduplicatedictionary_v1.2-final.pdf)
+49.  [](https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf)[https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07\_state-transition-validation-rules\_v2.7.1\_final.pdf](https://www.gleif.org/lei-data/gleif-data-quality-management/xml-schema/2023-03-07_state-transition-validation-rules_v2.7.1_final.pdf)
+50.  [](https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf)[https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23\_gleif-golden-copy-and-delta-files\_v2.2-final.pdf](https://www.gleif.org/lei-data/gleif-golden-copy/2022-02-23_gleif-golden-copy-and-delta-files_v2.2-final.pdf)
+51.  [](https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf)[https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19\_background\_information\_on\_global\_lei\_system\_report\_v1.2.pdf](https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_background_information_on_global_lei_system_report_v1.2.pdf)
+52.  [](https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf)[https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19\_business-report-dictionary\_v1.5.pdf](https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/2022-07-19_business-report-dictionary_v1.5.pdf)
+53.  [](https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf)[https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly\_business\_report.pdf](https://www.gleif.org/lei-data/global-lei-index/download-global-lei-system-business-reports/download-global-lei-system-business-report-q2-2023/2023-07-18-quarterly_business_report.pdf)
+54.  [](https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf)[https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19\_lei\_statistics\_dashboard-dictionary\_v1.1.pdf](https://www.gleif.org/lei-data/global-lei-index/lei-statistics/2022-07-19_lei_statistics_dashboard-dictionary_v1.1.pdf)
+55.  [](https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2017-12-21_annex-2_bic-to-lei-mapping-table-license-agreement_final.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2017-12-21\_annex-2\_bic-to-lei-mapping-table-license-agreement\_final.pdf](https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2017-12-21_annex-2_bic-to-lei-mapping-table-license-agreement_final.pdf)
+56.  [](https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01\_csv\_import\_guide\_v1.1.pdf](https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf)
+57.  [](https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23_bic-to-lei-factsheet_v1.3-final.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23\_bic-to-lei-factsheet\_v1.3-final.pdf](https://www.gleif.org/lei-data/lei-mapping/download-bic-to-lei-relationship-files/2023-03-23_bic-to-lei-factsheet_v1.3-final.pdf)
+58.  [](https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01\_csv\_import\_guide\_v1.1.pdf](https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf)
+59.  [](https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08_isin-to-lei_factsheet_v1.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08\_isin-to-lei\_factsheet\_v1.pdf](https://www.gleif.org/lei-data/lei-mapping/download-isin-to-lei-relationship-files/2021-06-08_isin-to-lei_factsheet_v1.pdf)
+60.  [](https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01\_csv\_import\_guide\_v1.1.pdf](https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf)
+61.  [](https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2022-09-02_mic_to_lei_mapping_table_license_agreement_v1.0.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2022-09-02\_mic\_to\_lei\_mapping\_table\_license\_agreement\_v1.0.pdf](https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/2022-09-02_mic_to_lei_mapping_table_license_agreement_v1.0.pdf)
+62.  [](https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902\_mic\_to\_lei\_factsheet\_v1.0.pdf](https://www.gleif.org/lei-data/lei-mapping/download-mic-to-lei-relationship-files/20220902_mic_to_lei_factsheet_v1.0.pdf)
+63.  [](https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01\_csv\_import\_guide\_v1.1.pdf](https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2018-03-01_csv_import_guide_v1.1.pdf)
+64.  [](https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf)[https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29\_opencorporatesid-to-lei-factsheet\_v1.1-final.pdf](https://www.gleif.org/lei-data/lei-mapping/download-oc-to-lei-relationship-files/2023-06-29_opencorporatesid-to-lei-factsheet_v1.1-final.pdf)
+65.  [](https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf)[https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03\_nda\_gleif\_template\_v1.1.pdf](https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2018-04-03_nda_gleif_template_v1.1.pdf)
+66.  [](https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf)[https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13\_internal-controls-checklist\_v2.0-final.pdf](https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2020-02-13_internal-controls-checklist_v2.0-final.pdf)
+67.  [](https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf)[https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02\_lei\_mapping\_cooperation\_agreement\_v1.pdf](https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-02_lei_mapping_cooperation_agreement_v1.pdf)
+68.  [](https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-10-appendix-2-contact-details.pdf)[https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-10-appendix-2-contact-details.pdf](https://www.gleif.org/lei-data/lei-mapping/gleif-certification-process/2021-09-10-appendix-2-contact-details.pdf)
+69.  [](https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10_s_p_global_company_id-to-lei_factsheet_v1.0.pdf)[https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10\_s\_p\_global\_company\_id-to-lei\_factsheet\_v1.0.pdf](https://www.gleif.org/lei-data/lei-mapping/s-p-global-company-id-to-lei-relationship/2022-10-10_s_p_global_company_id-to-lei_factsheet_v1.0.pdf)
+70.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-01_gleif_bloomberg_sanctions_screening_v1.0_bloomberg_approved_final.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-01\_gleif\_bloomberg\_sanctions\_screening\_v1.0\_bloomberg\_approved\_final.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-01_gleif_bloomberg_sanctions_screening_v1.0_bloomberg_approved_final.pdf)
+71.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-06_gleif_element-22_sanctions_screening_v1_approved_final.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-06\_gleif\_element-22\_sanctions\_screening\_v1\_approved\_final.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-06_gleif_element-22_sanctions_screening_v1_approved_final.pdf)
+72.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-08_moodys_sanctions_screening_gleif_v1.0_approved.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-08\_moodys\_sanctions\_screening\_gleif\_v1.0\_approved.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-08_moodys_sanctions_screening_gleif_v1.0_approved.pdf)
+73.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-09_gleif_ceviant_kyc_onboarding_v1.0_approved_final.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-09\_gleif\_ceviant\_kyc\_onboarding\_v1.0\_approved\_final.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-09_gleif_ceviant_kyc_onboarding_v1.0_approved_final.pdf)
+74.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-22_gleif_wmd_sanctions_screening_v1.0_final_approved.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-22\_gleif\_wmd\_sanctions\_screening\_v1.0\_final\_approved.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-22_gleif_wmd_sanctions_screening_v1.0_final_approved.pdf)
+75.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-28_moodys_kyc-onboarding_gleif_v1.0_approved_final.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-28\_moodys\_kyc-onboarding\_gleif\_v1.0\_approved\_final.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-28_moodys_kyc-onboarding_gleif_v1.0_approved_final.pdf)
+76.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-5_gleif_lse_sanctions_screening_v1.0_approved_final.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-5\_gleif\_lse\_sanctions\_screening\_v1.0\_approved\_final.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-06-5_gleif_lse_sanctions_screening_v1.0_approved_final.pdf)
+77.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-07-04_japan-eseal_gleif_v1.0_approved-final.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-07-04\_japan-eseal\_gleif\_v1.0\_approved-final.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/2023-07-04_japan-eseal_gleif_v1.0_approved-final.pdf)
+78.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/p070722.pdf)
+79.  [](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf)[https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift\_global\_adoption\_of\_the\_lei\_finaldraftv1.pdf](https://www.gleif.org/lei-solutions/featuring-the-lei/1-cross-border-payments/swift_global_adoption_of_the_lei_finaldraftv1.pdf)
+80.  [](https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf)[https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23\_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities\_final\_public.pdf](https://www.gleif.org/lei-solutions/gleifs-digital-strategy-for-the-lei/gleif-idc-research-creating-agile-resilient-global-trade-with-the-lei-and-vlei/2023-03-23_driving-business-with-trust-the-sustaining-role-of-secure-and-reliable-identities_final_public.pdf)
+81.  [](https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf)[https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings\_challenges-onboarding-client-organizations-in-banking-sector\_v1.0-final.pdf](https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-findings_challenges-onboarding-client-organizations-in-banking-sector_v1.0-final.pdf)
+82.  [](https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf)[https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report\_a-new-future-for-legal-entity-identification\_final.pdf](https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-report_a-new-future-for-legal-entity-identification_final.pdf)
+83.  [](https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-the-pitfalls-of-onboarding/gleif-infographic_the-future-of-legal-entity-identification_final.pdf)[https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-the-pitfalls-of-onboarding/gleif-infographic\_the-future-of-legal-entity-identification\_final.pdf](https://www.gleif.org/lei-solutions/lei-in-kyc-a-new-future-for-legal-entity-identification/gleif-research-the-pitfalls-of-onboarding/gleif-infographic_the-future-of-legal-entity-identification_final.pdf)
+84.  [](https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf)[https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29\_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf](https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/2019-10-29_gleif-ebook-leis-and-client-lifecycle-management-in-banking-a-u.s-4-billion-v1.0-approved-public.pdf)
+85.  [](https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/gleif-infographic-leis-transforming-banks-client-lifecycle-management/2019-10-29_gleif-infographic-leis-transforming-banks-client-lifecycle-management_v1.0-approved-public.pdf)[https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/gleif-infographic-leis-transforming-banks-client-lifecycle-management/2019-10-29\_gleif-infographic-leis-transforming-banks-client-lifecycle-management\_v1.0-approved-public.pdf](https://www.gleif.org/lei-solutions/mckinsey-company-and-gleif-leis-and-client-lifecycle-management-in-banking-a-u-s-4-billion-beginning/gleif-infographic-leis-transforming-banks-client-lifecycle-management/2019-10-29_gleif-infographic-leis-transforming-banks-client-lifecycle-management_v1.0-approved-public.pdf)
+86.  [](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf)[https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet\_v.1.1-final.pdf](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-foerderung-finanzieller-inklusion-von-unternehmen-in-afrika-globale-initiative-zur-digitalen-identifizierung-von-unternehmen-gestartet_v.1.1-final.pdf)
+87.  [](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf)[https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses\_v.1.1-final.pdf](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-global-digital-business-identity-initiative-launches-to-boost-financial-inclusion-for-african-businesses_v.1.1-final.pdf)
+88.  [](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf)[https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines\_v.1.1-final.pdf](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/2021-08-10-lancement-de-initiative-identite-numerique-mondiale-de-l-entreprise-en-soutien-a-l-inclusion-financiere-des-entreprises-africaines_v.1.1-final.pdf)
+89.  [](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf)[https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei\_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement\_v1.2-final.pdf](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/le-lei_la-cle-qui-deverrouillera-linclusion-financiere-dans-les-pays-en-developpement_v1.2-final.pdf)
+90.  [](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf)[https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies\_v1.2-final.pdf](https://www.gleif.org/lei-solutions/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies/the-lei-the-key-to-unlocking-financial-inclusion-in-developing-economies_v1.2-final.pdf)
+91.  [](https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf)[https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03\_gleif-validation-agent-trial-ebook\_v1.0-approved-public.pdf](https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-a-closer-look-at-the-validation-agent-trial-process/2021-03-03_gleif-validation-agent-trial-ebook_v1.0-approved-public.pdf)
+92.  [](https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-announces-new-va-role-for-fis_v1.0-final-clean.pdf)[https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29\_gleif-announces-new-va-role-for-fis\_v1.0-final-clean.pdf](https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-announces-new-va-role-for-fis_v1.0-final-clean.pdf)
+93.  [](https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf)[https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29\_gleif-ebook-lei-validation-agent-framework\_v1.1-final.pdf](https://www.gleif.org/lei-solutions/validation-agents/gleif-ebook-introducing-the-lei-validation-agent/2020-09-29_gleif-ebook-lei-validation-agent-framework_v1.1-final.pdf)
+94.  [](https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf)[https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03\_vlei-q-a-updated\_v1.1\_final.pdf](https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/2023-04-03_vlei-q-a-updated_v1.1_final.pdf)
+95.  [](https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf)[https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif\_introduction-to-the-vlei\_redesign\_v2.2.pdf](https://www.gleif.org/vlei/introducing-the-verifiable-lei-vlei/gleif-ebook-the-vlei-introducing-digital-i-d-for-organizations-everywhere/01-06-2023-gleif_introduction-to-the-vlei_redesign_v2.2.pdf)
+96.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-business-requirements_v1.0_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-business-requirements\_v1.0\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-business-requirements_v1.0_final.pdf)
+97.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-gleif-identifier-governance-framework\_v1.0\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-gleif-identifier-governance-framework_v1.0_final.pdf)
+98.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-governance-requirements_v1.0_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-governance-requirements\_v1.0\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-governance-requirements_v1.0_final.pdf)
+99.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework\_v.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-engagement-context-role-vlei-credential-framework_v.pdf)
+100.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-official-organizational-role-vlei-credential-govern.pdf)
+101.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework\_v1.0\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-legal-entity-vlei-credential-governance-framework_v1.0_final.pdf)
+102.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-primary-document\_v1.0\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-primary-document_v1.0_final.pdf)
+103.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework\_v1.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-qualified-vlei-issuer-authorization-vlei-credential-framework_v1.pdf)
+104.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials\_v1.0\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part2-vlei-credentials_v1.0_final.pdf)
+105.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-technical-requirements-part\_3-vlei-credential-schema-registry\_v1.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-technical-requirements-part_3-vlei-credential-schema-registry_v1.pdf)
+106.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16\_verifiable-lei-\_vlei\_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies\_v1.0\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2022-12-16_verifiable-lei-_vlei_-ecosystem-governance-framework-vlei-ecosystem-information-trust-policies_v1.0_final.pdf)
+107.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03\_verifiable-lei-vlei-ecosystem-governance-framework-glossary\_v1.1\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-glossary_v1.1_final.pdf)
+108.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03\_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-qualified-vlei-issuer-identifer-vlei-credential-governance-framewo.pdf)
+109.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03\_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment\_v1.1\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-risk-assessment_v1.1_final.pdf)
+110.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03\_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure\_v1.1\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-technical-requirements-part1-keri-infrastructure_v1.1_final.pdf)
+111.  [](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf)[https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03\_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework\_v1.1\_final.pdf](https://www.gleif.org/vlei/introducing-the-vlei-ecosystem-governance-framework/2023-04-03_verifiable-lei-vlei-ecosystem-governance-framework-trust-assurance-framework_v1.1_final.pdf)
+112.  [](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final.pdf)[https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06\_appendix-4-vlei-issuer-contact-details\_v1.0\_final.pdf](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-4-vlei-issuer-contact-details_v1.0_final.pdf)
+113.  [](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf)[https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06\_appendix-5-qualified-vlei-issuer-service-level-agreement\_v1.2\_final.pdf](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-5-qualified-vlei-issuer-service-level-agreement_v1.2_final.pdf)
+114.  [](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_v1.0_final.pdf)[https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06\_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark\_v1.0\_final.pdf](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-6-terms-of-use-qualified-vlei-issuer-trustmark_v1.0_final.pdf)
+115.  [](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms_v1.0_final.pdf)[https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06\_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms\_v1.0\_final.pdf](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_appendix-7-qualified-vlei-issuer-legal-entity-contract-terms_v1.0_final.pdf)
+116.  [](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf)[https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06\_vlei-issuer-qualification-agreement\_v1.0\_final.pdf](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2022-12-06_vlei-issuer-qualification-agreement_v1.0_final.pdf)
+117.  [](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf)[https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03\_appendix-1-non-disclosure-agreement\_v1.1\_final.pdf](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-1-non-disclosure-agreement_v1.1_final.pdf)
+118.  [](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf)[https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03\_appendix-2-vlei-issuer-qualification-program-manual\_v1.1\_final.pdf](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-2-vlei-issuer-qualification-program-manual_v1.1_final.pdf)
+119.  [](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf)[https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03\_appendix-3-vlei-issuer-qualification-program-checklist\_v1.2\_final.pdf](https://www.gleif.org/vlei/the-lifecycle-of-a-vlei-issuer/gleif-qualification-of-vlei-issuers/required-documents/2023-04-03_appendix-3-vlei-issuer-qualification-program-checklist_v1.2_final.pdf)
+
+
+
+
+---
+title: KERIDoc
+description: We aim to document everything related to KERI, ACDC and CESR and alike. To let autonomic identifiers florish.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/intro/intro/index
+  md: https://weboftrust.github.io/keridoc/docs/intro/intro/index.md
+---
+
+# KERIDoc
+
+We aim to document everything related to **KERI, ACDC and CESR** and alike. To let autonomic identifiers florish.
+
+AND HENK TESTED GITHUB.COM FRONT-END EDITING FOR CARLY
+
+[WebofTrust WOT-terms](https://github.com/WebOfTrustkeridoc/)
+The README of the main WebofTrust WOT-terms repo is [here](https://github.com/WebOfTrustkeridoc/blob/main/README.md).
+
+The table below lists the key deliverables of the KERI Community:
+
+| Acronym | Full Name of Deliverable | Link to Deliverable | Lead Authors | Status / Notes |
+| --- | --- | --- | --- | --- |
+
+| KERI | Attributable (Autonomic) Identifiers (KERI) | [IETF KERI Draft](https://github.com/WebOfTrust/ietf-keri) | Samuel Smith |  |
+| CESR | Composable Event Streaming Representation | [IETF CESR Draft](https://github.com/WebOfTrust/ietf-cesr) | Samuel Smith | [Active Draft](https://datatracker.ietf.org/doc/draft-ssmith-cesr/) |
+| ACDC | Authentic Chained Data Containers | [IETF ACDC Draft](https://github.com/trustoverip/tswg-acdc-specification) | Samuel Smith | [Active Draft](https://datatracker.ietf.org/doc/draft-ssmith-acdc/) |
+| OOBI | Out-Of-Band-Introduction | [IETF OOBI Draft](https://github.com/WebOfTrust/ietf-oobi) | Sam Smith | [Active Draft](https://datatracker.ietf.org/doc/draft-ssmith-oobi/) |
+
+**How will KERI (secure attribution) and ACDC (veracity) be adopted?**
+
+Anyone can set up and offer a technical tool and proponents could explain perceived use-cases, technology applications, even their general advantages and face-value features, but it's what the recipient **_believes_** that might or might not lead to adoption. Subsequently, according to the level of belief it's a choice to either study and use the tool or (completely) ignore it.
+
+Ignoring could be reciprocal. Designers and creators of the (KERI / ACDC) technology have the freedom to not be bothered by the lack of practical use cases at all. Or they might still thrive well in the presence of misunderstanding and undervaluation of the tooling and the concepts behind them.
+```
+"KERI doesn't care"
+```
+is an often used phrase. Not to intimidate or to be condescending, but to stress criteria that decide whether a certain perceived 'situation' is relevant within the constraints of KERI or ACDC or not. Especially experts from the blockchain world and DID world have a hard time to get their head around KERI and ACDC. That's a statistical fact, and again, hopefully not a way to put people off but to create a sort of awareness that the road to understanding KERI / ACDC could be a bumpy one.
+
+> Without understanding our peers, we won't be able to help them understand the KERI /ACDC concepts, without understanding and belief, there won't be adoption.
+
+1.  On-line education is important. We think it's an endless effort to improve the **understandability** of highly technical on-line resources and dedication is needed to achieve this value.
+2.  **Static sites** have value. A few relevant advantages:
+    -   after creation it's fixed in a directory structure, make it read-only and it's safe
+    -   working on continuously harvested copies of external resources (independence, improving UX, etc.)
+    -   a static site works off-line as a charm
+    -   inclusion by low-bandwidth requirements.
+3.  **Continuous Development Continuous Integration** (CDCI) - Github actions keeps things up to date (as few human hands as possible).
+
+That said, we consider there's given a wish to mutually understand each-other (this includes the awareness of being understood). If so, we could serve the interested recipient of information about this great innovation by:
+
+1.  **Explaining the concepts** that introduce terminology, explain the terminology at various levels of understanding and in certain domains (e.g. in certain use-cases)
+2.  **Asking questions** about how this explanation is received and offer next steps to dive deeper into the resources available
+
+Then what might magically happen is that somewhere in this process the recipients concludes that the tool has **meaning** for them! He/she believes it has unique characteristics, value, practical application etc. There might even be someone that _sees_ it's the next big thing on the web, like the KERI / ACDC tends to believe.
+
+So this is why we explain our concepts in various levels of understanding and link it to terminology spun in a interrelated glossary. Here you can find the KERI, OOBI, CESR and ACDC concepts, starting points and principles: [Concepts.md](https://weboftrust.github.io/keridoc/docs/concepts/concepts.md)
+
+(EXplain IETF, ToIP, eSSIF-Lab)
+
+So far we've used a star system that indicates the suitability of questions, answers, concepts and terminology (and glossary) respecting the knowledge-level of the reader / recipient.
+
+-   '\* beginner
+-   '\*\* advanced
+-   '\*\*\* expert
+
+_Mind you, a 'beginner' is still an expert in the field of identity! Target groups like friends, family, and other laymen are out of scope._
+
+"We need use cases for adoption" is a claim based on strong beliefs among the participant of the WOT-terms (Zoom) group.
+
+We could investigate the **correlation between levels of understanding** (beginner, advanced, expert) **and how use cases could be approached**. To illustrate this presumed correlation, we sketch the _adoption of cars_ in hindsight:
+
+'\* beginner -> a newbie might be triggered by meaning and practical advantages (transportation, entertainment, etc.)
+'**advanced -> an advanced person is a skilled power user of the car (she knows about refuelling, starting, shifting, steering, braking, maintenance, etc.)
+'\*** expert -> this is the car mechanic: technically skilled and very knowledgeable (mastering everything under the bonnet, and comparisons from the top of his head.)
+
+(TBW prio 2: how to investigate whether this correlation is present and if so how it could work with the one, two, three star model.)
+
+Within the KERI scope, a search for criteria and consciously, on the basis of objectives, switching from one frame of reference to another, for example from KERI  ToIP  eSSIF-Lab  KERI
+
+(Explain transformations and criteria as the basis to make decisions and understand each other)
+
+An _example_ transformation KERI  eSSIF-Lab
+
+(DRAFT!! ->)
+
+-   Two stars (\*\*) Verification "yes, the passport is valid".
+-   One star (\*) Validation "no, you can't use it in China, because less than 6 months to expiry date")
+-   Three stars (\*\*\*) Validation and verification are synonymous under the bonnet of KERI, with the criterion that everything must be cryptographically verifiable to the root-of-trust as soon as it comes to yes/no derivations, Veracity ("is it true what is said?") covers under the bonnet the grey area where VCs do their work.
+
+(END DRAFT)
+
+The reference implementation for KERI is the keripy implementation. This is hosted here by the WebOfTrust project. The repository may be found here:
+
+-   [keripy](https://github.com/WebOfTrust/keripy) – under development
+
+The keripy implementation is Apache2 licensed as are all repositories in the WebOfTrust project.
+
+There is also an Apache2 licensed Rust implementation of KERI hosted by the WebOfTrust project which may be found here:
+
+-   [keriox](https://github.com/WebOfTrust/keriox) – under development
+
+The primary contributors to keriox have since moved their efforts to a [repository](https://github.com/THCLab/keriox) with a non Apache2 license. As a result the WebOfTrust keriox implementation above is somewhat behind the keripy implementation in terms of feature support. We encourage the community to step forward and continue development of the Apache2 licensed Rust implementation.
+
+We also encourage creation of Educational material and resources for KERI, CESR, OOBI and ACDC in other appearances. We are happy to host other activities here in the WebOfTrust project as long as they are Apache2 licensed.
+
+
+
+
+---
+title: Intro
+description: This is a source directory that explains how this site came to be and how it can be maintained.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/intro/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/intro/index.md
+---
+
+# Intro
+
+This is a source directory that explains how this site came to be and how it can be maintained.
+
+In _how-we-did_ we document 'the making of' this site that consists of
+
+-   data; which we call WOT-terminology or **WOT-terms**
+-   functionality; which we call **KERISSE**
+
+Is the data part of this site and consists of:
+
+-   whitepapers
+-   code of the KERI Suite
+-   Glossary
+-   Q-and-A's
+-   Concepts behind the KERI Suite
+-   blogs
+-   etc
+
+-   Typesense Search Engine
+-   Artificial Intelligence chatBot; ONHOLD 2023
+-   Docusaurus static site functionality
+
+...answers questions like:
+
+-   why did we make these things listed above
+-   how to create the result step by step
+-   how to update the result step by step
+-   how to use the result step by step after that
+-   why do we have this component (and not something else)
+-   who does benefit from the component or process
+-   what's the precedence, the workflow, the triggers, what comes after this
+
+![](https://weboftrust.github.io/keridoc/assets/images/kerisse-25eb16a2332e8ca0a4d2fc30c28794f5.md)
+
+
+
+
+---
+title: External W3C DID Glossary
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-w3cdid/index
+  md: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-w3cdid/index.md
+---
+
+# External W3C DID Glossary
+
+\[ [A](#amplificationattack) | [B](#undefined) | [C](#cryptographicsuite) | [D](#decentralizedidentifier\(DID\)) | [E](#undefined) | [F](#undefined) | [G](#undefined) | [H](#undefined) | [I](#undefined) | [J](#undefined) | [K](#undefined) | [L](#undefined) | [M](#undefined) | [N](#undefined) | [O](#undefined) | [P](#publickeydescription) | [Q](#undefined) | [R](#resource) | [S](#services) | [T](#undefined) | [U](#UniformResourceIdentifier\(URI\)) | [V](#verifiablecredential) | [W](#undefined) | [X](#undefined) | [Y](#undefined) | [Z](#undefined) \]
+
+amplification attack
+
+A class of attack where the attacker attempts to exhaust a target system'sCPU, storage, network, or other resources by providing small, valid inputs intothe system that result in damaging effects that can be exponentially more costlyto process than the inputs themselves.
+
+authenticate
+
+Authentication is a process by which an entity can prove it has a specificattribute or controls a specific secret using one or more verificationmethods. With DIDs, a common example would be proving control of thecryptographic private key associated with a public key published in a DIDdocument.
+
+cryptographic suite
+
+A specification defining the usage of specific cryptographic primitives inorder to achieve a particular security goal. These documents are often usedto specify verification methods, digital signature types,their identifiers, and other related properties.
+
+decentralized identifier (DID)
+
+A globally unique persistent identifier that does not require a centralizedregistration authority and is often generated and/or registeredcryptographically. The generic format of a DID is defined in 3.1 DID Syntax. A specific DID scheme is defined in a DIDmethod specification. Manybut not allDID methods make use ofdistributed ledger technology (DLT) or some other form of decentralizednetwork.
+
+decentralized identity management
+
+Identitymanagement that is based on the use of decentralized identifiers.Decentralized identity management extends authority for identifier generation,registration, and assignment beyond traditional roots of trust such asX.500 directory services,the Domain Name System,and most national ID systems.
+
+DID controller
+
+An entity that has the capability to make changes to a DID document. ADID might have more than one DID controller. The DID controller(s)can be denoted by the optional controller property at the top level of theDID document. Note that a DID controller might be the DIDsubject.
+
+DID delegate
+
+An entity to whom a DID controller has granted permission to use averification method associated with a DID via a DIDdocument. For example, a parent who controls a child's DID documentmight permit the child to use their personal device in order toauthenticate. In this case, the child is the DID delegate. Thechild's personal device would contain the private cryptographic materialenabling the child to authenticate using the DID. However, the childmight not be permitted to add other personal devices without the parent'spermission.
+
+DID document
+
+A set of data describing the DID subject, including mechanisms, such ascryptographic public keys, that the DID subject or a DID delegatecan use to authenticate itself and prove its association with theDID. A DID document might have one or more differentrepresentations as defined in 6. Representations or in theW3C DID Specification Registries \[DID-SPEC-REGISTRIES\].
+
+DID fragment
+
+The portion of a DID URL that follows the first hash sign character(#). DID fragment syntax is identical to URI fragment syntax.
+
+DID method
+
+A definition of how a specific DID method scheme is implemented. A DID method isdefined by a DID method specification, which specifies the precise operations bywhich DIDs and DID documents are created, resolved, updated,and deactivated. See 8. Methods.
+
+DID path
+
+The portion of a DID URL that begins with and includes the first forwardslash (/) character and ends with either a question mark(?) character, a fragment hash sign (#) character,or the end of the DID URL. DID path syntax is identical to URI path syntax.See Path.
+
+DID query
+
+The portion of a DID URL that follows and includes the first questionmark character (?). DID query syntax is identical to URI querysyntax. See Query.
+
+DID resolution
+
+The process that takes as its input a DID and a set of resolutionoptions and returns a DID document in a conforming representationplus additional metadata. This process relies on the "Read" operation of theapplicable DID method. The inputs and outputs of this process aredefined in 7.1 DID Resolution.
+
+DID resolver
+
+A DID resolver is a software and/or hardware component that performs theDID resolution function by taking a DID as input and producing aconforming DID document as output.
+
+DID scheme
+
+The formal syntax of a decentralized identifier. The generic DID schemebegins with the prefix did: as defined in 3.1 DID Syntax. Each DID method specification defines a specificDID method scheme that works with that specific DID method. In a specific DIDmethod scheme, the DID method name follows the first colon and terminates withthe second colon, e.g., did:example:
+
+DID subject
+
+The entity identified by a DID and described by a DID document.Anything can be a DID subject: person, group, organization, physical thing,digital thing, logical thing, etc.
+
+DID URL
+
+A DID plus any additional syntactic component that conforms to thedefinition in 3.2 DID URL Syntax. This includes an optional DIDpath (with its leading / character), optional DID query(with its leading ? character), and optional DID fragment(with its leading # character).
+
+DID URL dereferencing
+
+The process that takes as its input a DID URL and a set of inputmetadata, and returns a resource. This resource might be a DIDdocument plus additional metadata, a secondary resourcecontained within the DID document, or a resource entirelyexternal to the DID document. The process uses DID resolution tofetch a DID document indicated by the DID contained within theDID URL. The dereferencing process can then perform additional processingon the DID document to return the dereferenced resource indicated by theDID URL. The inputs and outputs of this process are defined in7.2 DID URL Dereferencing.
+
+DID URL dereferencer
+
+A software and/or hardware system that performs the DID URL dereferencingfunction for a given DID URL or DID document.
+
+distributed ledger (DLT)
+
+A non-centralized system for recording events. These systems establishsufficient confidence for participants to rely upon the data recorded by othersto make operational decisions. They typically use distributed databases wheredifferent nodes use a consensus protocol to confirm the ordering ofcryptographically signed transactions. The linking of digitally signedtransactions over time often makes the history of the ledger effectivelyimmutable.
+
+public key description
+
+A data object contained inside a DID document that contains all themetadata necessary to use a public key or a verification key.
+
+resource
+
+As defined by \[RFC3986\]: "...the term 'resource' is used in a general sensefor whatever might be identified by a URI." Similarly, any resource might serveas a DID subject identified by a DID.
+
+representation
+
+As defined for HTTP by \[RFC7231\]: "information that is intended to reflect apast, current, or desired state of a given resource, in a format that can bereadily communicated via the protocol, and that consists of a set ofrepresentation metadata and a potentially unbounded stream of representationdata." A DID document is a representation of information describing aDID subject. See 6. Representations.
+
+representation-specific entries
+
+Entries in a DID document whose meaning is particular to a specificrepresentation. Defined in 4. Data Model and6. Representations. For example, @context inthe JSON-LD representation is arepresentation-specific entry.
+
+services
+
+Means of communicating or interacting with the DID subject orassociated entities via one or more service endpoints.Examples include discovery services, agent services, social networkingservices, file storage services, and verifiable credential repository services.
+
+service endpoint
+
+A network address, such as an HTTP URL, at which services operate onbehalf of a DID subject.
+
+Uniform Resource Identifier (URI)
+
+The standard identifier format for all resources on the World Wide Web asdefined by \[RFC3986\]. A DID is a type of URI scheme.
+
+verifiable credential
+
+A standard data model and representation format for cryptographically-verifiabledigital credentials as defined by the W3C Verifiable Credentials specification\[VC-DATA-MODEL\].
+
+verifiable data registry
+
+A system that facilitates the creation, verification, updating, and/ordeactivation of decentralized identifiers and DID documents. Averifiable data registry might also be used for othercryptographically-verifiable data structures such as verifiablecredentials. For more information, see the W3C Verifiable Credentialsspecification \[VC-DATA-MODEL\].
+
+verifiable timestamp
+
+A verifiable timestamp enables a third-party to verify that a data objectexisted at a specific moment in time and that it has not been modified orcorrupted since that moment in time.If the data integrity could reasonably havebeen modified or corrupted since that moment in time, the timestamp is notverifiable.
+
+verification method
+
+A set of parameters that can be used together with a process to independentlyverify a proof. For example, a cryptographic public key can be used as averification method with respect to a digital signature; in such usage, itverifies that the signer possessed the associated cryptographic private key. "Verification" and "proof" in this definition are intended to apply broadly. Forexample, a cryptographic public key might be used during Diffie-Hellman keyexchange to negotiate a shared symmetric key for encryption. This guarantees theintegrity of the key agreement process. It is thus another type of verificationmethod, even though descriptions of the process might not use the words"verification" or "proof."
+
+verification relationship
+
+An expression of the relationship between the DID subject and averification method. An example of a verification relationship is5.3.1 Authentication.
+
+Universally Unique Identifier (UUID)
+
+A type of globally unique identifier defined by \[RFC4122\]. UUIDs are similarto DIDs in that they do not require a centralized registration authority. UUIDsdiffer from DIDs in that they are not resolvable orcryptographically-verifiable.
+
+
+
+
+---
+title: External ToIP did:webs Glossary
+description: w
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-toipdidweb/index
+  md: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-toipdidweb/index.md
+---
+
+# External ToIP did:webs Glossary
+
+\[ [A](#AIDcontrolledidentifiers) | [B](#BADARUN) | [C](#compacteventstreamingrepresentation\(CESR\)) | [D](#decentralizedidentifier\(DID\)) | [E](#undefined) | [F](#undefined) | [G](#undefined) | [H](#host) | [I](#inceptionevent) | [J](#undefined) | [K](#keyevent) | [L](#undefined) | [M](#methodspecificidentifier) | [N](#undefined) | [O](#outofbandintroduction\(OOBI\)) | [P](#prerotation) | [Q](#undefined) | [R](#rotationevent) | [S](#selfaddressingidentifier\(SAID\)) | [T](#transactioneventlog\(TEL\)) | [U](#undefined) | [V](#verifier) | [W](#watcher) | [X](#undefined) | [Y](#undefined) | [Z](#undefined) \]
+
+AID controlled identifiers
+
+Any identifier, including did:webs DIDs, that have the same AID are by definition referencing the same identity. As defined in the KERI specification
+
+authentic chained data container (ACDC)
+
+a variant of the Verifiable Credential (VC) specification that inherits the security model derived from KERI, as defined by the ACDC specification. See WebOfTrust glossary for more detail.
+
+autonomic identifier (AID)
+
+A self-certifying identifier (SCID) that is cryptographically bound cryptographically bound to a key event log (KEL), as defined by the KERI specification. An AID is either non-transferable or transferable. A non-transferable AID does not support key rotation while a transferable AID supports key rotation using a key pre-rotation mechanism that enables the AID to persist in spite of the evolution of its key state. See WebOfTrust glossary for more detail.
+
+BADA-RUN
+
+Best available data acceptance - Read/Update/Nullify provides a medium level of security because events are ordered in a consistent way, using a combination of date-time and a key state. The latest event is the one with the latest date-time for the latest key state. See The KERI spec for more detail.
+
+compact event streaming representation (CESR)
+
+An encoding format that enables round-trip text-binary conversion of concatenated cryptographic primitives and general data types, as defined by the CESR specification and CESR Proof Signature specification. See WebOfTrust glossary for more detail.
+
+controller
+
+A controlling entity that can cryptographically prove the control authority (signing and rotation) over an AID as well as make changes on the associated KEL. A controller may consist of multiple controlling entities in a multi-signature scheme. See WebOfTrust glossary for more detail.
+
+decentralized identifier (DID)
+
+A globally unique persistent identifier, as defined by DID Core.
+
+designated aliases
+
+An array of AID controlled identifiers that have been designated by the AID controller to be used as aliases for equivalentId and alsoKnownAs DID document metadata and to foster verification of redirection to different did:webs identifiers. See WebOfTrust glossary for more detail.
+
+DID document
+
+A set of data describing the subject of a DID, as defined by DID Core. See also section DID Documents.
+
+DID resolution metadata
+
+DID resolution metadata is metadata about the DID Resolution process that was performed in order to obtain the DID document for a given DID. See also DID Resolution Metadata in the DID Core specification.
+
+DID document metadata
+
+DID document metadata is metadata about the DID and the DID document that is the result of the DID Resolution process. See also DID Document Metadata in the DID Core specification.
+
+direct mode
+
+an operational mode of the KERI protocol where a controller and a verifier of an AID exchange the KEL of the AID directly, as defined by the KERI whitepaper. See WebOfTrust glossary for more detail.
+
+host
+
+The part of a URL that can be either a domain name or an IP address. This component specifies the server that the client needs to communicate with in order to access the desired resource on the web.
+
+inception event
+
+A key event that provides the incepting information needed to derive an AID and establish its initial key state, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+indirect mode
+
+An operational mode of the KERI protocol where the KEL of an AID is discovered by a verifier via witnesses, as defined by the KERI whitepaper. See WebOfTrust glossary for more detail.
+
+interaction event
+
+A key event that anchors external data to an AID, as defined by the KERI specification. An interaction event does not change the key state of the AID. See WebOfTrust glossary for more detail.
+
+key event
+
+A serialized data structure of an entry in the key event log(KEL) for an AID, as defined by the KERI specification. There are three types of key events, namely inception event, rotation event, and interaction event. See WebOfTrust glossary for more detail.
+
+key event log (KEL)
+
+A verifiable append-only log of key events for an AID that is both backward and forward-chained, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+KEL backed data
+
+KEL backed data in did:webs provides the highest level of data security assurance and such data can be found either in the KEL or anchored to an event in the KEL. This means that the signatures on the events in the KEL are strongly bound to the key state at the time the events are entered in the KEL, that is the data. This provides strong guarantees of non-duplicity to any verifiers receiving a presentation as the KELs are protected and can be watched by agents (watcher) of the verifiers. The information is end-verifiable and any evidence of duplicity in the events is evidence that the data or presentation should not be trusted. See WebOfTrust glossary for more detail.
+
+key event receipt
+
+A message whose body references a key event of an AID and includes one or more signatures on that key event, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+key event receipt log (KERL)
+
+A verifiable append-only log that includes all the consistent key event receipt messages, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+key event receipt infrastructure (KERI)
+
+A protocol that provides an identity system-based secure overlay for the internet and uses AIDs as the primary roots of trust, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+KERI event stream
+
+A stream of verifiable KERI data, consisting of the key event log (KEL) and other data such as a transaction event log (TEL). This data is a CESR event stream, with media type application/cesr, and may be serialized in a file using CESR encoding. We refer to these CESR stream resources as KERI event streams to simplify the vocabulary. See WebOfTrust glossary for more detail.
+
+key state
+
+The set of currently authoritative key pairs (current keys) for an AID and any other information necessary to secure or establish control authority over the AID. See WebOfTrust glossary for more detail.
+
+KERI Request Authentication Mechanism
+
+A non-interactive replay attack protection algorithm that uses a sliding window of date-time stamps and key state (similar to the tuple in BADA-RUN) but the date-time is the repliers not the queriers. KRAM is meant to protect a host. See the WebOfTrust glossary for more detail.
+
+method-specific identifier
+
+The method-specific-id part of DID Syntax, as defined in DID Core. See section Method-Specific Identifier.
+
+multi-signature
+
+A mechanism that enables multiple parties to sign a message, as defined by the KERI specification. See Controller Application in the KERI spec for more detail.
+
+out-of-band introduction (OOBI)
+
+A protocol for discovering verifiable information on an AID or a SAID, as defined by the KERI specification. The OOBI by itself is insecure, and the information discovered by the OOBI must be verified. See WebOfTrust glossary for more detail.
+
+pre-rotation
+
+A key rotation mechanism whereby a set of rotation keys are pre-commited using cryptographic digests, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+rotation event
+
+A key event that provides the information needed to change the key state for an AID using pre-rotation, as defined by the KERI specification. See WebOfTrust glossary for more detail.
+
+self-addressing identifier (SAID)
+
+An identifier that is uniquely and cryptographically bound to a serialization of data (content-addressable) while also being included as a component in that serialization (self-referential), as defined by the CESR specification. See WebOfTrust glossary for more detail.
+
+transaction event log (TEL)
+
+A verifiable append-only log of transaction data that are cryptographically anchored to a KEL. The transaction events of a TEL may be used to establish the issuance or revocation state of ACDCs. See WebOfTrust glossary for more detail.
+
+verifier
+
+An entity or component that cryptographically verifies the signature(s) on an event message. See WebOfTrust glossary for more detail.
+
+watcher
+
+An entity that keeps a copy of a KERL of an AID to detect duplicity of key events, as defined by the KERI whitepaper. See WebOfTrust glossary for more detail.
+
+witness
+
+An entity that is designated by the controller of an AID to verify, sign, and keep the key events associated with the AID, as defined by the KERI whitepaper. See WebOfTrust glossary for more detail.
+
+w
+
+
+
+
+---
+title: External ToIP Glossary
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-toip/index
+  md: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-toip/index.md
+---
+
+# External ToIP Glossary
+
+\[ [A](#h.l6kidod3jk1m) | [B](#h.grifxl8vyuuu) | [C](#h.ad62zphsbkd8) | [D](#h.u6zclym3wpbs) | [E](#h.6lbj6fqiooii) | [F](#h.88wfh0m6wbd6) | [G](#h.x6n84riqc6ll) | [H](#h.vs7ugzdzujtz) | [I](#h.llbw3xojtkuj) | [J](#h.uw2s3y6sjzjf) | [K](#h.m06ht5n5sabj) | [L](#h.mxikvsxmz83w) | [M](#h.8s3s84fzcfi3) | [N](#h.yx4qb6dcjdvj) | [O](#h.k0v6ir8wmcav) | [P](#h.a3dqs23tcmn0) | [Q](#h.6qi3agm0afv3) | [R](#h.9pd74syajps6) | [S](#h.rwxa1n5inr2e) | [T](#h.hpl12if94wa6) | [U](#h.o11assyhncpl) | [V](#h.rbp41an0omv6) | [W](#h.mitd3elf05tf) | [X](#undefined) | [Y](#undefined) | [Z](#h.zc9pf8eexjs) \]
+
+AAL
+
+See: [authenticator assurance level](#h.a7560ebfrt4m).
+
+ABAC
+
+See: [attribute-based access control](#h.ckr2atznm0o).
+
+access control
+
+The process of granting or denying specific requests for obtaining and using information and related information processing services.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/access_control&sa=D&source=editors&ust=1718703186568494&usg=AOvVaw02RGKmN9heCmnpzGUgnzBE).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Access_control&sa=D&source=editors&ust=1718703186568970&usg=AOvVaw326ZY5cVjD13BsU0qZguen): In [physical security](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Physical_security&sa=D&source=editors&ust=1718703186569181&usg=AOvVaw0Ol4CFpD64FW-u3vfnnFP4) and [information security](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Information_security&sa=D&source=editors&ust=1718703186569400&usg=AOvVaw0Fz4LdlyBdd8ePZaC_kTug), access control (AC) is the selective restriction of access to a place or other resource, while access management describes the process. The act of accessing may mean consuming, entering, or using. Permission to access a resource is called [authorization](#h.576ssfpt348i).
+
+accreditation (of an entity)
+
+The independent, [third-party](#h.zu2vj8151tr) evaluation of an [entity,](#h.5imtbzl1f4xo) by a conformity assessment body (such as [certification body](#h.noh9fchc9jx), inspection body or laboratory) against recognised standards, conveying formal demonstration of its impartiality and competence to carry out specific conformity assessment tasks (such as [certification](#h.ytzysnyu57ec), inspection and testing).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Accreditation&sa=D&source=editors&ust=1718703186570253&usg=AOvVaw1GgA2DnKm2wZbqyTpF5LSk).
+
+accreditation body
+
+A [legal entity](#h.5328bxxk02sb) that performs [accreditation](#h.so5aazavq41d).
+
+See also: [certification body](#h.noh9fchc9jx).
+
+ACDC
+
+See: [Authentic Chained Data Container](#h.1yn1ii2u6xtt).
+
+action
+
+Something that is actually done (a 'unit of work' that is executed) by a single [actor](#h.gzdfngxkp0ip) (on behalf of a given [party](#h.cn6bno48fomj)), as a single operation, in a specific context.
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23action&sa=D&source=editors&ust=1718703186571656&usg=AOvVaw2gC3qmEzDm8AgmATqaC4yD).
+
+actor
+
+An [entity](#h.5imtbzl1f4xo) that can act (do things/execute [actions](#h.l54nzmooy631)), e.g. people, machines, but not [organizations](#h.z27mp1358pi9). A [digital agent](#h.z3ugzt4hgdf6) can serve as an actor acting on behalf of its [principal](#h.sydbe7rk6244).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186572643&usg=AOvVaw0AY_fsx6wg0BL8LJHQsO-o).
+
+address
+
+See: [network address](#h.v9gosdu5b7z5).
+
+administering authority
+
+See: [administering body](#h.w8r6jg7mkdaj).
+
+administering body
+
+A [legal entity](#h.5328bxxk02sb) [delegated](#h.l7p0oyq4rvsz) by a [governing body](#h.1wptecwzvuvz) to administer the operation of a [governance framework](#h.2x05z0r097mn) and governed infrastructure for a [digital trust ecosystem](#h.h47f86smlz4y), such as one or more [trust registries](#h.5kzln6m5e8j5).
+
+Also known as: [administering authority](#h.7bgku6bcbjmq).
+
+agency
+
+In the context of decentralized digital trust infrastructure, the empowering of a [party](#h.cn6bno48fomj) to act independently of its own accord, and in particular to empower the party to employ an [agent](#h.6xkhfkjpo6xg) to act on the [party’s](#h.cn6bno48fomj) behalf.
+
+agent
+
+An [actor](#h.gzdfngxkp0ip) that is executing an [action](#h.l54nzmooy631) on behalf of a [party](#h.cn6bno48fomj) (called the [principal](#h.sydbe7rk6244) of that [actor](#h.gzdfngxkp0ip)). In the context of decentralized digital trust infrastructure, the term “agent” is most frequently used to mean a [digital agent](#h.z3ugzt4hgdf6).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23agent&sa=D&source=editors&ust=1718703186575067&usg=AOvVaw0Ti533d-l34TH_OEA5AlYq).
+
+See also: [wallet](#h.mh27630t20d).
+
+Note: In a ToIP context, an agent is frequently assumed to have privileged access to the [wallet](#h.mh27630t20d)(s) of its principal. In market parlance, a mobile app performing the [actions](#h.l54nzmooy631) of an agent is often simply called a [wallet](#h.mh27630t20d) or a [digital wallet](#h.sxnvf3f5v156).
+
+AID
+
+See [autonomic identifier](#h.bz098kwwc559).
+
+anonymous
+
+An adjective describing when the [identity](#h.z1gairv0pej5) of a [natural person](#h.yx4qb6dcjdvj) or other [actor](#h.gzdfngxkp0ip) is unknown.
+
+See also: [pseudonym](#h.tgbgt5tqzl4m).
+
+anycast
+
+Anycast is a network [addressing](#h.tv1389o42vzp) and [routing](#h.tbxetxt0mdlp) methodology in which a single [IP address](#h.a8c3q7adyz7c) is shared by devices (generally servers) in multiple locations. [Routers](#h.oqbqyf914pln) direct packets addressed to this destination to the location nearest the sender, using their normal decision-making algorithms, typically the lowest number of BGP network hops. Anycast [routing](#h.tbxetxt0mdlp) is widely used by [content deliv](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Content_delivery_network&sa=D&source=editors&ust=1718703186576871&usg=AOvVaw1K-35RI9OYmc0RNt5TnWIy)e[ry networks](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Content_delivery_network&sa=D&source=editors&ust=1718703186577067&usg=AOvVaw1vUmNkGdR46g54M8gSItNH) such as web and name servers, to bring their content closer to end users.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Anycast&sa=D&source=editors&ust=1718703186577320&usg=AOvVaw0l60-mwZYJaygD4t1c45Nl).
+
+See also: [broadcast](#h.s1uti8f9ufsv), [multicast](#h.nopxfdr8qtr6), [unicast](#h.bqegn99wxkdi).
+
+anycast address
+
+A [network address](#h.v9gosdu5b7z5) (especially an [IP address](#h.a8c3q7adyz7c)) used for [anycast](#h.adr8osyk2zcx) routing of network transmissions.
+
+appraisability (of a communications endpoint)
+
+The ability for a [communication endpoint](#h.qstkv072p5tx) identified with a [verifiable identifier](#h.wyda231qefe) to be appraised for the set of its [properties](#h.c8vs1xa4uwn) that enable a [relying party](#h.61sr3qnr1eci) or a [verifier](#h.xfewd7t01hu0) to make a [trust decision](#h.m8c86ccqis9r) about communicating with that [endpoint](#h.yodlnk353mx).
+
+See also: [trust basis](#h.hwb3cttekok1), [verifiability](#h.v9dou4wg2h9d).
+
+appropriate friction
+
+A user-experience design principle for information systems (such as digital wallets) specifying that the level of attention required of the [holder](#h.64mptmm24w7u) for a particular transaction should provide a reasonable opportunity for an informed choice by the [holder](#h.64mptmm24w7u).
+
+Source: [PEMC IGR](https://www.google.com/url?q=https://kantarainitiative.org/download/pemc-implementors-guidance-report/&sa=D&source=editors&ust=1718703186579110&usg=AOvVaw0yeDeyAykKPgU7ui8ISfyN).
+
+attestation
+
+The issue of a statement, based on a decision, that fulfillment of specified [requirements](#h.ajxlw8r3dvcc) has been demonstrated. In the context of decentralized digital trust infrastructure, an attestation usually has a [digital signature](#h.s93np0i5rcne) so that it is [cryptographically verifiable](#h.422iwwfur12).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/attestation&sa=D&source=editors&ust=1718703186579678&usg=AOvVaw2FilfhASEGB9nm1zpHx0pP).
+
+attribute
+
+An identifiable set of data that describes an [entity](#h.5imtbzl1f4xo), which is the [subject](#h.voca6uuv1a4) of the attribute.
+
+See also: [property](#h.c8vs1xa4uwn).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23attribute&sa=D&source=editors&ust=1718703186580390&usg=AOvVaw2TIPmlM5liVH-mpbXlpMXA): [Data](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/data&sa=D&source=editors&ust=1718703186580583&usg=AOvVaw1XNG-vjV4TpbK061nv5nL2) that represents a characteristic that a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186580833&usg=AOvVaw09JwhXedtNKkI3yOHz-wTE) (the [owner](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/owner&sa=D&source=editors&ust=1718703186581004&usg=AOvVaw2PAgjZSHuYHFP_80jNoffU) of the [attribute](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/attribute&sa=D&source=editors&ust=1718703186581211&usg=AOvVaw0wC9nadaVSoNpNHSW7Q82p)) has attributed to an [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186581439&usg=AOvVaw0EJGlbOCpwgrP8UaEpHWZ0) (which is the [subject](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/subject&sa=D&source=editors&ust=1718703186581608&usg=AOvVaw38X7MyfxPP9j4x37JhiUzX) of that attribute).
+
+Note: An [identifier](#h.u3bfehmj4ed3) is an attribute that uniquely identifies an [entity](#h.5imtbzl1f4xo) within some context.
+
+attribute-based access control
+
+An [access control](#h.lmk4gqobt99b) approach in which access is mediated based on [attributes](#h.ky5nh3yri7ak) associated with [subjects](#h.voca6uuv1a4) (requesters) and the objects to be accessed. Each object and [subject](#h.voca6uuv1a4) has a set of associated [attributes](#h.ky5nh3yri7ak), such as location, time of creation, access rights, etc. Access to an object is [authorized](#h.576ssfpt348i) or denied depending upon whether the required (e.g., policy-defined) correlation can be made between the [attributes](#h.ky5nh3yri7ak) of that object and of the requesting [subject](#h.voca6uuv1a4).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/attribute_based_access_control&sa=D&source=editors&ust=1718703186582598&usg=AOvVaw3LiKlM91tb7d6UypLqk9ct).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Attribute-based_access_control&sa=D&source=editors&ust=1718703186582857&usg=AOvVaw3dpsUD7Thf94nQr-CJDZnH): Attribute-based access control (ABAC), also known as policy-based access control for [IAM](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Identity_management&sa=D&source=editors&ust=1718703186583016&usg=AOvVaw3iRf5JLfwx77zgEqgYMVma), defines an access control paradigm whereby a subject's authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment attributes.
+
+audit (of system controls)
+
+Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established [policies](#h.udts41hso4w4) and operational procedures.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/audit&sa=D&source=editors&ust=1718703186583421&usg=AOvVaw28_0FIZJOFGxirs1KJWEiy).
+
+audit log
+
+An audit log is a security-relevant chronological [record](#h.y4ybzkfe6yzv), set of [records](#h.y4ybzkfe6yzv), and/or destination and source of [records](#h.y4ybzkfe6yzv) that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Audit_trail&sa=D&source=editors&ust=1718703186583886&usg=AOvVaw3dZs1Tm7kvkGvttzINf7Ge).
+
+Also known as: audit trail.
+
+See also: [key event log](#h.6jhhyjh47h).
+
+auditor (of an entity)
+
+The [party](#h.cn6bno48fomj) responsible for performing an [audit](#h.3gz7xw796mvp). Typically an auditor must be [accredited](#h.so5aazavq41d).
+
+See also: [human auditable](#h.22bo41j3q290).
+
+assurance level
+
+A level of confidence in a [claim](#h.akieli6njkk5) that may be relied on by others. Different types of assurance levels are defined for different types of trust assurance mechanisms. Examples include [authenticator assurance level](#h.a7560ebfrt4m), [federation assurance level](#h.8fhj7rpnpjy3), and [identity assurance level](#h.udr0qmo2ubln).
+
+authentication (of a user, process, or device)
+
+Verifying the [identity](#h.z1gairv0pej5) of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authentication&sa=D&source=editors&ust=1718703186584961&usg=AOvVaw2XCY26WFB-FaCYqMMU4Rn6).
+
+See also: [authenticator](#h.ej596duqqmnb), [verifiable message](#h.7zrsx7mki2fr).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Authentication&sa=D&source=editors&ust=1718703186585448&usg=AOvVaw3dM0Hnrcxha8UHy4HZVymu): The act of proving an [assertion](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Logical_assertion&sa=D&source=editors&ust=1718703186585626&usg=AOvVaw01KB6TC9x03v-a_x_8sEF0), such as the [identity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_identity&sa=D&source=editors&ust=1718703186585764&usg=AOvVaw1_PCfFG6X3G1_zyB8qkV-6) of a computer system user.
+
+authenticator (of an entity)
+
+Something the claimant possesses and controls (typically a cryptographic module or password) that is used to [authenticate](#h.gp553sxzbmv1) the claimant’s [identity](#h.z1gairv0pej5).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authenticator&sa=D&source=editors&ust=1718703186586186&usg=AOvVaw1p3p1yMLrUuUUebBdmSkVT).
+
+authenticator assurance level
+
+A measure of the strength of an [authentication](#h.gp553sxzbmv1) mechanism and, therefore, the confidence in it.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authenticator_assurance_level&sa=D&source=editors&ust=1718703186586640&usg=AOvVaw0gZCj0xRd3v7FYwZuQaMaJ).
+
+See also: [federation assurance level](#h.8fhj7rpnpjy3), [identity assurance level](#h.udr0qmo2ubln), [identity binding](#h.kwudvu8h2zex).
+
+Note: In [NIST SP 800-63-3](https://www.google.com/url?q=https://pages.nist.gov/800-63-3/sp800-63-3.html&sa=D&source=editors&ust=1718703186587091&usg=AOvVaw3VMIT-pTrDFSmAcKYF1WS0), AAL is defined in terms of three levels: AAL1 (Some confidence), AAL2 (High confidence), AAL3 (Very high confidence).
+
+Authentic Chained Data Container
+
+A digital [data](#h.o783ayrrkc6g) structure designed for both cryptographic [verification](#h.2bnb6g8na7cu) and [chaining](#h.kgtwd73pdfae) of data containers. ACDC may be used for [digital credentials](#h.ddna9lucn4k6).
+
+For more information, see: [ToIP ACDC Task Force](https://www.google.com/url?q=https://wiki.trustoverip.org/display/HOME/ACDC%2B%2528Authentic%2BChained%2BData%2BContainer%2529%2BTask%2BForce&sa=D&source=editors&ust=1718703186587727&usg=AOvVaw2-WTCW8gNZEYtSILgPq8f6).
+
+authenticity
+
+The [property](#h.c8vs1xa4uwn) of being genuine and being able to be [verified](#h.k2qmzn3tjzsl) and trusted; confidence in the [validity](#h.rbp41an0omv6) of a transmission, a [message](#h.bge7ubygwk2q), or message originator.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authenticity&sa=D&source=editors&ust=1718703186588270&usg=AOvVaw2BF-37XWwAhukJ2ZKlmwD5).
+
+See also: [confidentiality](#h.445sv27j3c2m), [correlation privacy](#h.7a6p0irhnbh5), [cryptographic verifiability](#h.lbqfpvfmcmoq).
+
+authorization
+
+The process of [verifying](#h.xfewd7t01hu0) that a requested [action](#h.l54nzmooy631) or service is approved for a specific [entity](#h.5imtbzl1f4xo).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/authorization&sa=D&source=editors&ust=1718703186589082&usg=AOvVaw0h1k7PuVzCrS2l8WGhMoV2).
+
+See also: [permission](#h.mnqlrmrkqb9).
+
+authorized organizational representative
+
+A [person](#h.yx4qb6dcjdvj) who has the authority to make [claims](#h.akieli6njkk5), sign documents or otherwise commit resources on behalf of an [organization](#h.z27mp1358pi9).
+
+Source: [Law Insider](https://www.google.com/url?q=https://www.lawinsider.com/dictionary/authorized-organizational-representative%23:~:text%3DAuthorized%2520Organizational%2520Representative%2520means%2520the,the%2520resources%2520of%2520the%2520organization.&sa=D&source=editors&ust=1718703186589822&usg=AOvVaw3l0HKtZgF4Ilo7RhnkgOh3)
+
+authorization graph
+
+A graph of the [authorization](#h.576ssfpt348i) relationships between different entities in a [trust community](#h.a9l3odcb1s29). In a [digital trust ecosystem](#h.h47f86smlz4y), the [governing body](#h.1wptecwzvuvz) is typically the [trust root](#h.vfnyletkzjv5) of an authorization graph. In some cases, an authorization graph can be traversed by making queries to one or more [trust registries](#h.5kzln6m5e8j5).
+
+See also: [governance graph](#h.u9xnz96ecf5x), [reputation graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.4wwkekt1wrs7&sa=D&source=editors&ust=1718703186590578&usg=AOvVaw08xfTXgPY0_DWgvZM_8DqP), [trust graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.eqx98nkqjzsv&sa=D&source=editors&ust=1718703186590782&usg=AOvVaw3Z5RhHKcsyLA8dVqSl4s_a).
+
+authoritative source
+
+A source of information that a [relying party](#h.61sr3qnr1eci) considers to be [authoritative](#h.gln5i78kxlfh) for that information. In ToIP architecture, the [trust registry](#h.5kzln6m5e8j5) authorized by the [governance framework](#h.2x05z0r097mn) for a [trust community](#h.a9l3odcb1s29) is typically considered an authoritative source by the members of that [trust community](#h.a9l3odcb1s29). A [system of record](#h.ceh3cl4l0xnp) is an authoritative source for the data records it holds. A [trust root](#h.vfnyletkzjv5) is an authoritative source for the beginning of a [trust chain](#h.xsqvwmepvctc).
+
+authority
+
+A [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186591524&usg=AOvVaw3bE93LTsr3IaDtWDyCpZGT) of which certain decisions, ideas, [rules](#h.v7s575ulon74) etc. are followed by other [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186591748&usg=AOvVaw0tzEpT0XBXPEBLljOuUsIH).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/authority&sa=D&source=editors&ust=1718703186591943&usg=AOvVaw1cKo_K6CCUhtXdXEyrVjGP).
+
+autonomic identifier
+
+The specific type of [self-certifying identifier](#h.hub48c59i8wj) specified by the [KERI](#h.7pp65h7qs9lu) specifications.
+
+Also known as: [AID](#h.15sa9rrid2f).
+
+biometric
+
+A measurable physical characteristic or personal behavioral trait used to recognize the [identity](#h.z1gairv0pej5), or verify the [claimed](#h.akieli6njkk5) [identity](#h.z1gairv0pej5), of an applicant. Facial images, fingerprints, and iris scan samples are all examples of biometrics.
+
+Source: [NIST](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/biometric&sa=D&source=editors&ust=1718703186592701&usg=AOvVaw2eYT1YOC0_pmawPFfkLuE3)
+
+blockchain
+
+A [distributed digital ledger](#h.eoh04mpatko3) of cryptographically-signed transactions that are grouped into blocks. Each block is cryptographically linked to the previous one (making it tamper evident) after [validation](#h.rbp41an0omv6) and undergoing a consensus decision. As new blocks are added, older blocks become more difficult to modify (creating [tamper resistance](#h.hpl12if94wa6)). New blocks are replicated across copies of the ledger within the network, and any conflicts are resolved automatically using established rules.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/blockchain&sa=D&source=editors&ust=1718703186593146&usg=AOvVaw14aaKdKV1SIFOAIIfyroJV)
+
+Supporting definitions:
+
+[Wikipedia:](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Blockchain&sa=D&source=editors&ust=1718703186593440&usg=AOvVaw1tu4bB1HV_2AKLC6MwNYM-) A [distributed ledger](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Distributed_ledger&sa=D&source=editors&ust=1718703186593587&usg=AOvVaw1oDytPyrpBRIntEu_7uwyo) with growing lists of [records](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Record_\(computer_science\)&sa=D&source=editors&ust=1718703186593740&usg=AOvVaw2f0K_rlHaS7xBZExpy6THK) (blocks) that are securely linked together via [cryptographic hashes](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Cryptographic_hash_function&sa=D&source=editors&ust=1718703186593885&usg=AOvVaw0Ya70gDrQtHy79owcgA1gO). Each block contains a cryptographic hash of the previous block, a [timestamp](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Trusted_timestamping&sa=D&source=editors&ust=1718703186594044&usg=AOvVaw35zctcldPDIbNIFcK3K9D1), and transaction data (generally represented as a [Merkle tree](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Merkle_tree&sa=D&source=editors&ust=1718703186594182&usg=AOvVaw1vxopUk95qXMXln8yJltq8), where [data nodes](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Node_\(computer_science\)&sa=D&source=editors&ust=1718703186594323&usg=AOvVaw14HvA36v2NMVPnfVtGj0Ih) are represented by leaves). Since each block contains information about the previous block, they effectively form a chain (compare [linked list](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Linked_list&sa=D&source=editors&ust=1718703186594472&usg=AOvVaw0re8R1iojwYvWERpByhccK) data structure), with each additional block linking to the ones before it. Consequently, blockchain transactions are irreversible in that, once they are recorded, the data in any given block cannot be altered retroactively without altering all subsequent blocks.
+
+broadcast
+
+In computer networking, telecommunication and information theory, broadcasting is a method of transferring a [message](#h.bge7ubygwk2q) to all recipients simultaneously. Broadcast delivers a message to all [nodes](#h.w1aty8c036fp) in the network using a one-to-all association; a single [datagram](#h.mxq90rincwo) (or [packet](#h.9hc1adgu2nrx)) from one sender is routed to all of the possibly multiple endpoints associated with the [broadcast address](#h.7gok5zmnh6an). The network automatically replicates [datagrams](#h.mxq90rincwo) as needed to reach all the recipients within the scope of the broadcast, which is generally an entire network subnet.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Broadcasting_\(networking\)&sa=D&source=editors&ust=1718703186595471&usg=AOvVaw2WbVj4Els0QLJ84ZuVOOCg).
+
+See also: [anycast](#h.adr8osyk2zcx), [multicast](#h.nopxfdr8qtr6), [unicast](#h.bqegn99wxkdi).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/broadcast&sa=D&source=editors&ust=1718703186595998&usg=AOvVaw1DOFmqtIyR5FrPD8PeESlc): Transmission to all devices in a network without any acknowledgment by the receivers.
+
+broadcast address
+
+A broadcast address is a [network address](#h.v9gosdu5b7z5) used to transmit to all devices connected to a multiple-access [communications](#h.w02a6srdng3j) network. A [message](#h.bge7ubygwk2q) sent to a broadcast address may be received by all network-attached [hosts](#h.3f5tvermqc9k). In contrast, a [multicast address](#h.obmynoe7gkec) is used to address a specific group of devices, and a [unicast address](#h.2p49ftuui3ug) is used to address a single device. For network layer communications, a broadcast address may be a specific [IP address](#h.a8c3q7adyz7c).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Network_address&sa=D&source=editors&ust=1718703186596885&usg=AOvVaw3Bmq_tPzQ-KXOWpCJNJZoe).
+
+C2PA
+
+See: [Coalition for Content Provenance and Authenticity](#h.38i7kn574fiz).
+
+CA
+
+See: [certificate authority](#h.dm6pt5kg2uim).
+
+CAI
+
+See: [Content Authenticity Initiative](#h.9jxxi75k6blt).
+
+certification authority
+
+See: [certificate authority](#h.dm6pt5kg2uim).
+
+certificate authority
+
+The entity in a [public key infrastructure](#h.mdxu5kpbdo4x) (PKI) that is responsible for issuing [public key certificates](#h.anf8g7aq0gk5) and exacting compliance to a PKI policy.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/certificate_authority&sa=D&source=editors&ust=1718703186598103&usg=AOvVaw2Zthh1-oJH-jBmn9ieIKdZ).
+
+Also known as: [certification authority](#h.lubcv4tm2i7r).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Certificate_authority&sa=D&source=editors&ust=1718703186598432&usg=AOvVaw2929yQoKs4ZFLoXiXmLJJ5): In [cryptography](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Cryptography&sa=D&source=editors&ust=1718703186598602&usg=AOvVaw3ugxuJcrBgi3fyfnPgNZu_), a certificate authority or certification authority (CA) is an entity that stores, signs, and issues [digital certificates](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public_key_certificate&sa=D&source=editors&ust=1718703186598760&usg=AOvVaw237WzCaEnqhixqwMKJCwXt). A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.[\[1\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Certificate_authority%23cite_note-1&sa=D&source=editors&ust=1718703186599013&usg=AOvVaw1tIh3kyp4Wce2NsyL-tsJf) The format of these certificates is specified by the [X.509](https://www.google.com/url?q=https://en.wikipedia.org/wiki/X.509&sa=D&source=editors&ust=1718703186599186&usg=AOvVaw123XmjygU4cjwqIJQn41mF) or [EMV](https://www.google.com/url?q=https://en.wikipedia.org/wiki/EMV&sa=D&source=editors&ust=1718703186599332&usg=AOvVaw0F21XPmhhoB8Ezc07S1fDe) standard.
+
+certification (of a party)
+
+A comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security [accreditation](#h.so5aazavq41d), to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security [requirements](#h.ajxlw8r3dvcc) for the system.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/certification&sa=D&source=editors&ust=1718703186600025&usg=AOvVaw3H6z_qy9K8uY3ausvbixCO).
+
+certification body
+
+A [legal entity](#h.5328bxxk02sb) that performs [certification](#h.ytzysnyu57ec).
+
+For more information: [https://en.wikipedia.org/wiki/Professional\_certification](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Professional_certification&sa=D&source=editors&ust=1718703186600654&usg=AOvVaw2CxBOAUtu5vxbR3CsEyRW2) 
+
+chain of trust
+
+See: [trust chain](#h.xsqvwmepvctc).
+
+chained credentials
+
+Two or more [credentials](#h.kcj6iw2vib1v) linked together to create a [trust chain](#h.xsqvwmepvctc) between the credentials that is [cryptographically verifiable](#h.422iwwfur12).
+
+Note: [ACDCs](#h.8qlmnalwgxgy) are a type of [digital credential](#h.ddna9lucn4k6) that explicitly supports [chaining](#h.kgtwd73pdfae).
+
+chaining
+
+See: [trust chain](#h.xsqvwmepvctc).
+
+channel
+
+See: [communication channel](#h.oc2pelzel246).
+
+ciphertext
+
+[Encrypted](#h.iyq318f2vg61) (enciphered) [data](#h.o783ayrrkc6g). The [confidential](#h.445sv27j3c2m) form of the [plaintext](#h.ylf3pqlex968) that is the output of the [encryption](#h.iyq318f2vg61) function.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/ciphertext&sa=D&source=editors&ust=1718703186602446&usg=AOvVaw0KwzRGO5BqHWmEijGfupsc).
+
+claim
+
+An assertion about a [subject](#h.voca6uuv1a4), typically expressed as an [attribute](#h.ky5nh3yri7ak) or [property](#h.c8vs1xa4uwn) of the [subject](#h.voca6uuv1a4). It is called a “claim” because the assertion is always made by some [party](#h.cn6bno48fomj), called the [issuer](#h.xyrplzbvtffq) of the claim, and the [validity](#h.rbp41an0omv6) of the claim must be judged by the [verifier](#h.xfewd7t01hu0). 
+
+Supporting definitions:
+
+[W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186603230&usg=AOvVaw19sqjo7N3V96ThNaPVibgF): An assertion made about a [subject](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-subjects&sa=D&source=editors&ust=1718703186603403&usg=AOvVaw1Ow97tXakwKWcSnuu9vs7C).
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Claims-based_identity&sa=D&source=editors&ust=1718703186603610&usg=AOvVaw3uK9PAUdOisDBGtq2G5al7): A claim is a statement that one subject, such as a person or organization, makes about itself or another subject. For example, the statement can be about a name, group, buying preference, ethnicity, privilege, association or capability.
+
+Note: If the [issuer](#h.xyrplzbvtffq) of the claim is also the [subject](#h.voca6uuv1a4) of the claim, the claim is [self-asserted](#h.yg81kearf9rl).
+
+Coalition for Content Provenance and Authenticity
+
+C2PA is a Joint Development Foundation project of the Linux Foundation that addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content.
+
+Also known as: [C2PA](#h.ad62zphsbkd8).
+
+See also: [Content Authenticity Initiative](#h.9jxxi75k6blt).
+
+communication
+
+The transmission of information.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Communication&sa=D&source=editors&ust=1718703186604647&usg=AOvVaw1XXR_sWpw9bILtYIFrqJlq).
+
+See also: [ToIP communication](#h.mqkudtdvvqw9).
+
+communication endpoint
+
+A type of communication network node. It is an interface exposed by a communicating party or by a [communication channel](#h.oc2pelzel246). An example of the latter type of a communication endpoint is a publish-subscribe topic or a group in group communication systems.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Communication_endpoint&sa=D&source=editors&ust=1718703186605385&usg=AOvVaw1lu4Q8V6vRnZBV4-oyurs2).
+
+See also: [ToIP endpoint](#h.e787fzjepk60).
+
+communication channel
+
+A communication channel refers either to a physical transmission medium such as a wire, or to a logical [connection](#h.thbpewq1px8x) over a multiplexed medium such as a radio channel in telecommunications and computer networking. A channel is used for information transfer of, for example, a digital bit stream, from one or several senders to one or several receivers.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Communication_channel&sa=D&source=editors&ust=1718703186606136&usg=AOvVaw3VVOtz0XGDiOkXbvIhUvcH).
+
+See also: [ToIP channel](#h.rp39gncihzvx).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/communication-channel&sa=D&source=editors&ust=1718703186606503&usg=AOvVaw15ZOp3wBFdLvJKei2KRQog): a (digital or non-digital) means by which two [actors](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186606721&usg=AOvVaw1gQwpO-gZ2APlatjJRHQyW) can exchange messages with one another.
+
+communication metadata
+
+[Metadata](#h.t63bf0ssndfd) that describes the sender, receiver, [routing](#h.tbxetxt0mdlp), handling, or contents of a [communication](#h.w02a6srdng3j). Communication metadata is often observable even if the contents of the [communication](#h.w02a6srdng3j) are encrypted.
+
+See also: [correlation privacy](#h.7a6p0irhnbh5).
+
+communication session
+
+A finite period for which a [communication channel](#h.oc2pelzel246) is instantiated and maintained, during which certain [properties](#h.c8vs1xa4uwn) of that channel, such as authentication of the participants, are in effect. A session has a beginning, called the session initiation, and an ending, called the session termination.
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/session&sa=D&source=editors&ust=1718703186607621&usg=AOvVaw3RvPdFayjsRLfjCObaYEQ7): A persistent interaction between a subscriber and an end point, either a relying party or a Credential Service Provider. A session begins with an authentication event and ends with a session termination event. A session is bound by use of a session secret that the subscriber’s software (a browser, application, or operating system) can present to the relying party or the Credential Service Provider in lieu of the subscriber’s authentication credentials.
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Session_\(computer_science\)&sa=D&source=editors&ust=1718703186607859&usg=AOvVaw2ey_VfYWrB1dw6pYtu2K1V): In [computer science](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_science&sa=D&source=editors&ust=1718703186608028&usg=AOvVaw3HS7hL-cTpG0xUoWKV5SAC) and [networking](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_network&sa=D&source=editors&ust=1718703186608216&usg=AOvVaw2YKDeON_MZTnYU0CEd0czv) in particular, a session is a time-delimited two-way link, a practical (relatively high) layer in the [TCP/IP protocol](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_protocol_suite&sa=D&source=editors&ust=1718703186608399&usg=AOvVaw2XqVUG1KjKJpdMLJ4blb8G) enabling interactive expression and information exchange between two or more communication devices or ends – be they computers, [automated systems](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Automation&sa=D&source=editors&ust=1718703186608553&usg=AOvVaw0fOFBrTYzA9iu99aj8-Cwc), or live active users (see [login session](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Login_session&sa=D&source=editors&ust=1718703186608728&usg=AOvVaw3oHycynihFUzg9W5KD3RrN)). A session is established at a certain point in time, and then ‘torn down’ - brought to an end - at some later point. An established communication session may involve more than one message in each direction. A session is typically [stateful](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Stateful&sa=D&source=editors&ust=1718703186608897&usg=AOvVaw0_s4IqbtOR2FAfYZ6kJvyx), meaning that at least one of the communicating parties needs to hold current state information and save information about the session history to be able to communicate, as opposed to [stateless](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Stateless_server&sa=D&source=editors&ust=1718703186609052&usg=AOvVaw0ujlbIvp9JbkaehpRFIrAV) communication, where the communication consists of independent [requests](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Request-response&sa=D&source=editors&ust=1718703186609242&usg=AOvVaw0Snz-mdV9kN8ndGrZ0_ra3) with responses. An established session is the basic requirement to perform a [connection-oriented communication](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Connection-oriented_communication&sa=D&source=editors&ust=1718703186609412&usg=AOvVaw2i8Od65bRit6KyxqyNpgz3). A session also is the basic step to transmit in [connectionless communication](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Connectionless_communication&sa=D&source=editors&ust=1718703186609635&usg=AOvVaw2LpvVtlhA5xh-VAV6cj9w4) modes. However, any unidirectional transmission does not define a session.
+
+complex password
+
+A [password](#h.5u3l7bhbpjno) that meets certain security requirements, such as minimum length, inclusion of different character types, non-repetition of characters, and so on.
+
+Supporting definitions:
+
+[Science Direct](https://www.google.com/url?q=https://www.sciencedirect.com/topics/computer-science/complex-password&sa=D&source=editors&ust=1718703186610218&usg=AOvVaw1OmcCJdBdTWSe3VvgtbY7m): According to Microsoft, complex passwords consist of at least seven characters, including three of the following four character types: uppercase letters, lowercase letters, numeric digits, and non-alphanumeric characters such as & $ \* and !
+
+compliance
+
+In the context of decentralized digital trust infrastructure, the extent to which a system, [actor](#h.gzdfngxkp0ip), or [party](#h.cn6bno48fomj) conforms to the requirements of a [governance framework](#h.2x05z0r097mn) or [trust framework](#h.2r5mn949idq) that pertains to that particular [entity](#h.5imtbzl1f4xo).
+
+See also: [Governance, Risk Management, and Compliance](#h.qo8q5iquhh9u).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23compliance&sa=D&source=editors&ust=1718703186611117&usg=AOvVaw3E_CW9kQkyI74iCqQWRhdK): The state of realization of a set of conformance criteria or normative framework of a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186611320&usg=AOvVaw3mVpp8fbOy6UxOXjRLVbu6).
+
+concept
+
+An abstract idea that enables the classification of [entities](#h.5imtbzl1f4xo), i.e., a mental construct that enables an instance of a class of [entities](#h.5imtbzl1f4xo) to be distinguished from [entities](#h.5imtbzl1f4xo) that are not an instance of that class. A concept can be [identified](#h.u3bfehmj4ed3) with a [term](#h.ojn7uxdcaf7u).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23concept&sa=D&source=editors&ust=1718703186612000&usg=AOvVaw3irPtehydfd1GY4FF8Xr7G): the ideas/thoughts behind a classification of [entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186612167&usg=AOvVaw2k_GD_VA-RRQDheq1bE71A) (what makes [entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186612375&usg=AOvVaw3IhjMuDaYqmEJCli5DmH4B) in that class 'the same').
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Concept&sa=D&source=editors&ust=1718703186612593&usg=AOvVaw1atiwMVF0BBFFdORyydef-): A concept is defined as an [abstract](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Abstraction&sa=D&source=editors&ust=1718703186612779&usg=AOvVaw3_zXWuO4qE5Z5OJEa7qkW5) [idea](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Idea&sa=D&source=editors&ust=1718703186612933&usg=AOvVaw1dBorw6YrdbH8IpesFxQKI). It is understood to be a fundamental building block underlying principles, [thoughts](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Thought&sa=D&source=editors&ust=1718703186613074&usg=AOvVaw2Kxkuxi2IMbq36QMjBHCjQ) and [beliefs](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Belief&sa=D&source=editors&ust=1718703186613201&usg=AOvVaw3cD5gsKSu5ynk1Nkc9FlsK). Concepts play an important role in all aspects of [cognition](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Cognition&sa=D&source=editors&ust=1718703186613342&usg=AOvVaw0xBAfqtmMNpQiW-JKQ-dKD).
+
+confidential computing
+
+Hardware-enabled features that isolate and process [encrypted](#h.iyq318f2vg61) [data](#h.o783ayrrkc6g) in memory so that the [data](#h.o783ayrrkc6g) is at less risk of exposure and compromise from concurrent workloads or the underlying system and platform.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/confidential_computing&sa=D&source=editors&ust=1718703186613956&usg=AOvVaw2xb-kwlg1XViJuGscwhIuP).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Confidential_computing&sa=D&source=editors&ust=1718703186614184&usg=AOvVaw30BgMR8CCuvFL5IyFWkjg2): Confidential computing is a security and [privacy-enhancing computational technique](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Privacy-enhancing_technologies&sa=D&source=editors&ust=1718703186614347&usg=AOvVaw1g9rCiCuCjKYXXbRxt7MYd) focused on protecting [data in use](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data_in_use&sa=D&source=editors&ust=1718703186614484&usg=AOvVaw33xJjaY-5gCe9VK510fsrw). Confidential computing can be used in conjunction with storage and network encryption, which protect [data at rest](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data_at_rest&sa=D&source=editors&ust=1718703186614770&usg=AOvVaw1fbAXPbtxTlQliRtPgOgKa) and [data in transit](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data_in_transit&sa=D&source=editors&ust=1718703186614952&usg=AOvVaw1HIFV1QGNkirs_hJhuRrET) respectively. It is designed to address software, protocol, cryptographic, and basic physical and supply-chain attacks, although some critics have demonstrated architectural and [side-channel attacks](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Side-channel_attack&sa=D&source=editors&ust=1718703186615128&usg=AOvVaw0Dm_mb18NcgPzi-CK-eJtq) effective against the technology.
+
+confidentiality
+
+In a [communications](#h.w02a6srdng3j) context, a type of privacy protection in which [messages](#h.bge7ubygwk2q) use [encryption](#h.iyq318f2vg61) or other privacy-preserving technologies so that only [authorized](#h.576ssfpt348i) [parties](#h.cn6bno48fomj) have access.
+
+See also: [authenticity](#h.pitlm5jn3v6u), [correlation privacy](#h.7a6p0irhnbh5).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/confidentiality&sa=D&source=editors&ust=1718703186615901&usg=AOvVaw2FfQ9y-tIBLV1mo5wqcbEy): Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Confidentiality&sa=D&source=editors&ust=1718703186616095&usg=AOvVaw1PoHEbxMjsPHS7kazW--Gk): Confidentiality involves a set of rules or a promise usually executed through [confidentiality agreements](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Confidentiality_agreements&sa=D&source=editors&ust=1718703186616278&usg=AOvVaw20jGSVNN0UD55jb5hKAF0d) that limits the access or places restrictions on certain types of [information](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Information&sa=D&source=editors&ust=1718703186616456&usg=AOvVaw107moUB5Qyc4xPxTHOFJ95).
+
+connection
+
+A [communication channel](#h.oc2pelzel246) established between two [communication endpoints](#h.qstkv072p5tx). A connection may be [ephemeral](#h.5xjtv29e8z6i) or [persistent](#h.ccf1vkxvhh1l).
+
+See also: [ToIP connection](#h.5i1yn2scvzvz).
+
+Content Authenticity Initiative
+
+The Content Authenticity Initiative (CAI) is an association founded in November 2019 by Adobe, the New York Times and [Tw](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Twitter&sa=D&source=editors&ust=1718703186617117&usg=AOvVaw3SdwI2M7lGKb1kYssr9h77)i[tter](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Twitter&sa=D&source=editors&ust=1718703186617276&usg=AOvVaw0cuZ5rwCKPM4uvQ-mw7VJ-). The CAI promotes an industry standard for provenance [metadata](#h.t63bf0ssndfd) defined by the [C2PA](#h.ad62zphsbkd8). The CAI cites curbing disinformation as one motivation for its activities.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Content_Authenticity_Initiative&sa=D&source=editors&ust=1718703186617591&usg=AOvVaw0sQC-CvuHrBH_AI0pOU-p_).
+
+Also known as: [CAI](#h.m7kywkkniutc).
+
+controller (of a key, vault, wallet, agent, or device)
+
+In the context of digital [communications](#h.w02a6srdng3j), the [entity](#h.5imtbzl1f4xo) in control of sending and receiving digital [communications](#h.w02a6srdng3j). In the context of decentralized digital trust infrastructure, the [entity](#h.5imtbzl1f4xo) in control of the [cryptographic keys](#h.53rzpn1yn6q7) necessary to perform [cryptographically verifiable](#h.422iwwfur12) [actions](#h.l54nzmooy631) using a [digital agent](#h.z3ugzt4hgdf6) and [digital wallet](#h.sxnvf3f5v156). In a ToIP context, the [entity](#h.5imtbzl1f4xo) in control of a [ToIP endpoint](#h.e787fzjepk60).
+
+See also: [device controller](#h.tf0m8u61wh87), [DID controller](#h.4yr00jpenf4z), [ToIP controller](#h.x1z2vxghptdm).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23controller&sa=D&source=editors&ust=1718703186618764&usg=AOvVaw2GAYo9fRsbw5ey5ZnG7gJp): the role that an [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186618940&usg=AOvVaw3vsMZ2je8q0ZcRad1zMhed) performs as it is executing actions on that [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186619092&usg=AOvVaw0rPUebWNfbMv5uCJ76yssH) for the purpose of ensuring that the [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186619237&usg=AOvVaw0QjFe8DV9aQTsfXMCzdXIz) will act/behave, or be used, in a particular way.
+
+consent management
+
+A system, process or set of policies under which a [person](#h.yx4qb6dcjdvj) agrees to share [personal data](#h.rpiib2ml3s9c) for specific usages. A consent management system will typically create a [record](#h.y4ybzkfe6yzv) of such consent.
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Consent_management&sa=D&source=editors&ust=1718703186619770&usg=AOvVaw1F_DY8OBhGPKbdiP0ff33W): Consent management is a system, process or set of policies for allowing consumers and patients to determine what health information they are willing to permit their various care providers to access. It enables patients and consumers to affirm their participation in e-health initiatives and to establish consent directives to determine who will have access to their protected health information (PHI), for what purpose and under what circumstances. Consent management supports the dynamic creation, management and enforcement of consumer, organizational and jurisdictional privacy policies.
+
+controlled document
+
+A [governance document](#h.c8fvvxachz5h) whose authority is derived from a primary document.
+
+correlation privacy
+
+In a [communications](#h.w02a6srdng3j) context, a type of privacy protection in which [messages](#h.bge7ubygwk2q) use [encryption](#h.iyq318f2vg61), [hashes](#h.otz98gjrt2s), or other privacy-preserving technologies to avoid the use of [identifiers](#h.u3bfehmj4ed3) or other content that [unauthorized](#h.576ssfpt348i) [parties](#h.cn6bno48fomj) may use to correlate the sender and/or receiver(s).
+
+See also: [authenticity](#h.pitlm5jn3v6u), [confidentiality](#h.445sv27j3c2m).
+
+counterparty
+
+From the perspective of one [party](#h.cn6bno48fomj), the other [party](#h.cn6bno48fomj) in a [transaction](#h.92pu88ke4p7k), such as a financial transaction.
+
+See also: [first party](#h.uxx5bjam20ag), [second party](#h.hk94wskqnzri), [third party](#h.zu2vj8151tr).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Counterparty&sa=D&source=editors&ust=1718703186621117&usg=AOvVaw2jWRCvbkMnZaFHnRJ0qPB7): A counterparty (sometimes contraparty) is a [legal entity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Juristic_person&sa=D&source=editors&ust=1718703186621328&usg=AOvVaw3SVOcAXR2zYlSGBdgxQm4u), [unincorporated entity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Unincorporated_entity&sa=D&source=editors&ust=1718703186621509&usg=AOvVaw0Rh9Wp-RE1KukBCeh4p9WP), or collection of entities to which an exposure of [financial risk](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Financial_risk&sa=D&source=editors&ust=1718703186621722&usg=AOvVaw20JtoaXHMZCRjYOSTMVnce) may exist.
+
+credential
+
+A container of [claims](#h.akieli6njkk5) describing one or more [subjects](#h.voca6uuv1a4). A credential is generated by the [issuer](#h.xyrplzbvtffq) of the credential and given to the [holder](#h.64mptmm24w7u) of the credential. A credential typically includes a signature or some other means of proving its [authenticity](#h.pitlm5jn3v6u). A credential may be either a [physical credential](#h.xnlz1vfx60mn) or a [digital credential](#h.ddna9lucn4k6).
+
+See also: [verifiable credential](#h.co5algna3zkh).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186622446&usg=AOvVaw0KHeLhBIsRiObGHGgaED19): data, representing a set of [assertions](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/assertion&sa=D&source=editors&ust=1718703186622607&usg=AOvVaw0saxIsXZ_RrXFW9hDuTT7Q) (claims, statements), authored and signed by, or on behalf of, a specific [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186622758&usg=AOvVaw10_m6Rq6lTo5yyqYPNO_Qe).
+
+[W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186622975&usg=AOvVaw2J9XD_8aUQIAFCiRJmGRZZ): A set of one or more [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186623155&usg=AOvVaw32hUWVhy1KyZgWoOyYzaIl) made by an [issuer](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-issuers&sa=D&source=editors&ust=1718703186623345&usg=AOvVaw0eNKMi75ILGrTyFxvRlCo_).
+
+credential family
+
+A set of related [digital credentials](#h.ddna9lucn4k6) defined by a [governing body](#h.1wptecwzvuvz) (typically in a [governance framework](#h.2x05z0r097mn)) to empower [transitive trust decisions](#h.syc9o7x61rkm) among the participants in a [digital trust ecosystem](#h.h47f86smlz4y).
+
+credential governance framework
+
+A [governance framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2x05z0r097mn&sa=D&source=editors&ust=1718703186624047&usg=AOvVaw3ZK6MUQtg-ht_dWXLUXpSm) for a [credential family](#h.z0q6zr8y239c). A credential governance framework may be included within or referenced by an [ecosystem governance framework](#h.dkge5gglsmk3).
+
+credential offer
+
+A protocol request invoked by an [issuer](#h.xyrplzbvtffq) to offer to [issue](#h.zfdojht594xv) a [digital credential](#h.ddna9lucn4k6) to the  [holder](#h.64mptmm24w7u) of a [digital wallet](#h.sxnvf3f5v156). If the request is invoked by the [holder](#h.64mptmm24w7u), it is called an [issuance request](#h.tt253lgfp4hz).
+
+credential request
+
+See: [issuance request](#h.tt253lgfp4hz).
+
+credential schema
+
+A [data schema](#h.nia930avy74i) describing the structure of a [digital credential](#h.ddna9lucn4k6). The [W3C Verifiable Credentials Data Model Specification](#h.mitd3elf05tf) defines a set of requirements for credential schemas.
+
+criterion
+
+In the context of [terminology](#h.189fachpwy1a), a written description of a [concept](#h.6hyxh4mxxbu2) that anyone can evaluate to determine whether or not an [entity](#h.5imtbzl1f4xo) is an instance or example of that [concept](#h.6hyxh4mxxbu2). Evaluation leads to a yes/no result.
+
+cryptographic binding
+
+Associating two or more related elements of information using cryptographic techniques.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/cryptographic_binding&sa=D&source=editors&ust=1718703186625944&usg=AOvVaw3ad3i2p7_q_xMIjNQoaZRL).
+
+cryptographic key
+
+A key in cryptography is a piece of information, usually a string of numbers or letters that are stored in a file, which, when processed through a cryptographic algorithm, can encode or decode cryptographic [data](#h.o783ayrrkc6g). Symmetric cryptography refers to the practice of the same [key](#h.53rzpn1yn6q7) being used for both [encryption](#h.iyq318f2vg61) and [decryption](#h.fuc05ut9lwmq). Asymmetric cryptography has separate [keys](#h.53rzpn1yn6q7) for [encrypting](#h.iyq318f2vg61) and [decrypting](#h.fuc05ut9lwmq). These keys are known as the [public keys](#h.hohpk6z1qk4f) and [private keys](#h.74y9dvxzg24c), respectively.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Key_\(cryptography\)&sa=D&source=editors&ust=1718703186627046&usg=AOvVaw2MbObh-xAld-jF2OnVTiNm).
+
+See also: [controller](#h.gemoqe2m303z).
+
+cryptographic trust
+
+A specialized type of [technical trust](#h.7vxscxecc0g) that is achieved using cryptographic algorithms.
+
+Contrast with: [human trust](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.a4jfn38wd17o&sa=D&source=editors&ust=1718703186627701&usg=AOvVaw2BZh3ysUM_2qfeWecgRZin).
+
+cryptographic verifiability
+
+The [property](#h.c8vs1xa4uwn) of being [cryptographically verifiable](#h.422iwwfur12).
+
+Contrast with: [human auditability](#h.g4qotp7yir9x).
+
+cryptographically verifiable
+
+A property of a data structure that has been digitally signed using a [private key](#h.74y9dvxzg24c) such that the [digital signature](#h.s93np0i5rcne) can be verified using the [public key](#h.hohpk6z1qk4f). [Verifiable data](#h.7n80iyjxkofu), [verifiable messages](#h.7zrsx7mki2fr), [verifiable credentials](#h.co5algna3zkh), and [verifiable data registries](#h.q1dr1v2lltfe) are all cryptographically verifiable. Cryptographic verifiability is a primary goal of the [ToIP Technology Stack](#h.9looruc0w4ac).
+
+Contrast with: [human auditable](#h.22bo41j3q290).
+
+cryptographically bound
+
+A state in which two or more elements of information have a [cryptographic binding](#h.kj56ogm6q6b3).
+
+custodial wallet
+
+A [digital wallet](#h.sxnvf3f5v156) that is directly in the custody of a [principal](#h.sydbe7rk6244), i.e., under the principal’s direct personal or organizational control. A [digital wallet](#h.sxnvf3f5v156) that is in the custody of a [third party](#h.zu2vj8151tr) is called a [non-custodial wallet](#h.ridlo7ub9haf).
+
+custodian
+
+A [third party](#h.zu2vj8151tr) that has been assigned rights and duties in a [custodianship arrangement](#h.4hh9dvbp6177) for the purpose of hosting and safeguarding a [principal’s](#h.sydbe7rk6244) [private keys](#h.74y9dvxzg24c), [digital wallet](#h.sxnvf3f5v156) and [digital assets](#h.emffux4xw3th) on the [principal’s](#h.sydbe7rk6244) behalf. Depending on the [custodianship](#h.4hh9dvbp6177) [arrangement](#h.4hh9dvbp6177), the custodian may act as an exchange and provide additional services, such as staking, lending, account recovery, or security features.
+
+Contrast with: [guardian](#h.y3s9f56kpets), [zero-knowledge service provider](#h.qhfq42vp7l55).
+
+See also: [custodial wallet](#h.5qanwm5930bp).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/custodian&sa=D&source=editors&ust=1718703186630760&usg=AOvVaw2oSYiig3FQbOSVLaorJ2dT): A third-party [entity](#h.5imtbzl1f4xo) that holds and safeguards a user’s [private keys](#h.74y9dvxzg24c) or digital assets on their behalf. Depending on the system, a custodian may act as an exchange and provide additional services, such as staking, lending, account recovery, or security features.
+
+Note: While a custodian technically has the necessary access to in theory [impersonate](#h.rifdelabky9n) the [principal](#h.sydbe7rk6244), in most cases a custodian is expressly prohibited from taking any action on the [principal’s](#h.sydbe7rk6244) account unless explicitly [authorized](#h.gln5i78kxlfh) by the [principal](#h.sydbe7rk6244). This is what distinguishes custodianship from [guardianship](#h.y3s9f56kpets).
+
+custodianship arrangement
+
+The informal terms or formal legal agreement under which a [custodian](#h.8kx1mv7y64ps) agrees to provide service to a [principal](#h.sydbe7rk6244).
+
+dark pattern
+
+A design pattern, mainly in user interfaces, that has the effect of deceiving individuals into making choices that are advantageous to the designer.
+
+Source: Kantara PEMC Implementors Guidance Report
+
+Also known as: [deceptive pattern](#h.rxt5u3tqdfny).
+
+data
+
+In the pursuit of [knowledge](#h.k96lktyswxnb), data is a collection of discrete values that convey information, describing quantity, quality, fact, statistics, other basic units of meaning, or simply sequences of symbols that may be further interpreted. A datum is an individual value in a collection of data.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data&sa=D&source=editors&ust=1718703186632423&usg=AOvVaw1Ft9yUMVjzF7xZjcFg74DP).
+
+See also: [verifiable data](#h.7n80iyjxkofu).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23data&sa=D&source=editors&ust=1718703186632835&usg=AOvVaw0Mguik6I8QKPjWxfa8j7de): something (tangible) that can be used to communicate a meaning (which is intangible/information).
+
+datagram
+
+See: [data packet](#h.9hc1adgu2nrx).
+
+data packet
+
+In telecommunications and computer networking, a network packet is a formatted unit of [data](#h.o783ayrrkc6g) carried by a packet-switched network such as the Internet. A packet consists of control information and user [data](#h.o783ayrrkc6g); the latter is also known as the payload. Control information provides data for delivering the payload (e.g., source and destination network addresses, error detection codes, or sequencing information). Typically, control information is found in packet headers and trailers.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Network_packet&sa=D&source=editors&ust=1718703186633666&usg=AOvVaw23BpfBClAhEQ2EUJB6U6US).
+
+data schema
+
+A description of the structure of a digital document or object, typically expressed in a [machine-readable](#h.8s3s84fzcfi3) language in terms of constraints on the structure and content of documents or objects of that type. A credential schema is a particular type of data schema.
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/XML_schema&sa=D&source=editors&ust=1718703186634158&usg=AOvVaw2cb8uHt_U1WT1ZRZcvQmT-): An XML schema is a description of a type of [XML](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Extensible_Markup_Language&sa=D&source=editors&ust=1718703186634343&usg=AOvVaw2XV29COXzSCr-D3mYHAuFK) document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself. These constraints are generally expressed using some combination of grammatical rules governing the order of elements, [Boolean predicates](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Boolean_predicates&sa=D&source=editors&ust=1718703186634516&usg=AOvVaw0HRa-_OeddpN3S1-pJOGp3) that the content must satisfy, data types governing the content of elements and attributes, and more specialized rules such as [uniqueness](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Uniqueness_quantification&sa=D&source=editors&ust=1718703186634678&usg=AOvVaw26vAk5skYnZG_L-D2caMRY) and [referential integrity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Referential_integrity&sa=D&source=editors&ust=1718703186634819&usg=AOvVaw2-_PXkbSYFKv1ROV3pWb1Y) constraints.
+
+data subject
+
+The [natural person](#h.yx4qb6dcjdvj) that is described by [personal data](#h.rpiib2ml3s9c). Data subject is the term used by the EU [General Data Protection Regulation](#h.tks8sagp6iy0).
+
+data vault
+
+See: [digital vault](#h.cz29glapo2tg).
+
+decentralized identifier
+
+A globally unique persistent [identifier](#h.u3bfehmj4ed3) that does not require a centralized [registration](#h.scqeh7q9ln83) [authority](#h.gln5i78kxlfh) and is often generated and/or registered cryptographically. The generic format of a DID is defined in section [3.1 DID Syntax](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23did-syntax&sa=D&source=editors&ust=1718703186635704&usg=AOvVaw12cGHZBrqgqP1Oz-F85DiR) of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.google.com/url?q=https://www.w3.org/TR/did-core/&sa=D&source=editors&ust=1718703186635864&usg=AOvVaw2lfTzZ31TSWUx-6t5L-0Ot) specification. A specific DID scheme is defined in a [DID method](#h.fuy2eub1xls) specification.
+
+Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186636252&usg=AOvVaw2yDrxoekGFLhxf2XFSEZ-C).
+
+Also known as: [DID](#h.zh539v9ul471).
+
+See also: [DID method](#h.fuy2eub1xls), [DID URL](#h.2lqom8dcqvzy).
+
+decentralized identity
+
+A [digital identity](#h.r5y8zwxvzyd3) architecture in which a [digital identity](#h.r5y8zwxvzyd3) is established via the control of a set of [cryptographic keys](#h.53rzpn1yn6q7) in a [digital wallet](#h.sxnvf3f5v156) so that the [controller](#h.gemoqe2m303z) is not dependent on any external [identity provider](#h.m9zmriuoidyt) or other [third party](#h.zu2vj8151tr).
+
+See also: [federated identity](#h.cb1le64hx6h5), [self-sovereign identity](#h.wdojy63bltd4).
+
+Decentralized Identity Foundation
+
+A non-profit project of the [Linux Foundation](https://www.google.com/url?q=https://www.linuxfoundation.org/&sa=D&source=editors&ust=1718703186637612&usg=AOvVaw1NBi3BR3Js9frDbrox4gGQ) chartered to develop the foundational components of an open, standards-based, [decentralized identity](#h.xodo7ytn4cx2) [ecosystem](#h.edgw5dskp7an) for people, [organizations](#h.z27mp1358pi9), apps, and devices.
+
+See also: [OpenWallet Foundation](#h.271hay7m0g55), [ToIP Foundation](#h.500jynxuxkms).
+
+For more information, see: [http://identity.foundation/](https://www.google.com/url?q=http://identity.foundation/&sa=D&source=editors&ust=1718703186638237&usg=AOvVaw1cq_xhR1TVsRIaK4RU8Thc) 
+
+Decentralized Web Node
+
+A decentralized personal and application data storage and message relay node, as defined in the DIF Decentralized Web Node specification. Users may have multiple nodes that replicate their data between them.
+
+Source: [DIF DWN Specification](https://www.google.com/url?q=https://identity.foundation/decentralized-web-node/spec/&sa=D&source=editors&ust=1718703186638640&usg=AOvVaw2M_gpxeLr_Tx56O1dOKrOl).
+
+Also known as: DWN.
+
+For more information, see: [https://identity.foundation/decentralized-web-node/spec/](https://www.google.com/url?q=https://identity.foundation/decentralized-web-node/spec/&sa=D&source=editors&ust=1718703186638940&usg=AOvVaw0pW-Ck6-0ypO9ydKK4SCqz) 
+
+deceptive pattern
+
+See: [dark pattern](#h.u6zclym3wpbs).
+
+decryption
+
+The process of changing [ciphertext](#h.9ripqbaz7egw) into [plaintext](#h.ylf3pqlex968) using a cryptographic algorithm and [key](#h.53rzpn1yn6q7). The opposite of [encryption](#h.iyq318f2vg61).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/decryption&sa=D&source=editors&ust=1718703186639696&usg=AOvVaw0Dd0ejgKOo7P9pyHCBZF7U).
+
+deep link
+
+In the context of the World Wide Web, deep linking is the use of a hyperlink that links to a specific, generally searchable or indexed, piece of web content on a website (e.g. "https://example.com/path/page"), rather than the website's home page (e.g., "https://example.com"). The URL contains all the information needed to point to a particular item. Deep linking is different from [mobile deep linking](#h.le2xkm9qaw28), which refers to directly linking to in-app content using a non-HTTP URI.
+
+See also: [out-of-band introduction](#h.tsslu4lnog0s).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Deep_linking&sa=D&source=editors&ust=1718703186640301&usg=AOvVaw2fl5jSPTiLAXFuq8kbODYI).
+
+definition
+
+A textual statement defining the meaning of a [term](#h.ojn7uxdcaf7u) by specifying [criterion](#h.1db3bhbgm7ba) that enable the [concept](#h.6hyxh4mxxbu2) identified by the [term](#h.ojn7uxdcaf7u) to be distinguished from all other [concepts](#h.6hyxh4mxxbu2) within the intended [scope](#h.5cfb6xokygh4).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23definition&sa=D&source=editors&ust=1718703186641149&usg=AOvVaw0ivqDDbpxRfX25ZHBP6xhx): a text that helps [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186641361&usg=AOvVaw3lOMT0dF1PiXJWzOE456lN) to have the same understanding about the meaning of (and [concept](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186641549&usg=AOvVaw3OsC8MiDBGgkbTqBE8Yh5g) behind) a [term](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186641721&usg=AOvVaw2NuGNseNEK90QRPuLZiH2y), ideally in such a way that these [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186641938&usg=AOvVaw0Dld6tmqqHfaAArxc4cfb-) can determine whether or not they make the same distinction.
+
+Wikipedia: A definition is a statement of the meaning of a term (a [word](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Word&sa=D&source=editors&ust=1718703186642164&usg=AOvVaw3gP_6gYiqg6AiKsqbvNT5E), [phrase](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Phrase&sa=D&source=editors&ust=1718703186642311&usg=AOvVaw25x3KqFrhr7dnh4YousIkn), or other set of [symbols](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Symbol&sa=D&source=editors&ust=1718703186642445&usg=AOvVaw1FHLdYA6IFOU2VuEDIxz0f)). Definitions can be classified into two large categories: [intensional definitions](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Intensional_definition&sa=D&source=editors&ust=1718703186642594&usg=AOvVaw0zkQba6jhDkQouChTepErN) (which try to give the sense of a term), and [extensional definitions](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Extensional_definition&sa=D&source=editors&ust=1718703186642743&usg=AOvVaw2pC25ZoGKf6ES2zxlEFNpU) (which try to list the objects that a term describes). Another important category of definitions is the class of [ostensive definitions](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Ostensive_definition&sa=D&source=editors&ust=1718703186642889&usg=AOvVaw1QFV7bu7sc76qz-B8Y1NIM), which convey the meaning of a term by pointing out examples. A term may have many different senses and multiple meanings, and thus require multiple definitions.
+
+delegation
+
+TODO
+
+delegation credential
+
+TODO
+
+dependent
+
+An [entity](#h.5imtbzl1f4xo) for the caring for and/or protecting/guarding/defending of which a [guardianship arrangement](#h.tc250ixnd67w) has been established with a [guardian](#h.y3s9f56kpets).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23dependent&sa=D&source=editors&ust=1718703186643621&usg=AOvVaw0GMTD9YGRXkr6EdRalhpHW)
+
+See also: [custodian](#h.8kx1mv7y64ps).
+
+Mental Model: [eSSIF-Lab Guardianship](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/pattern-guardianship&sa=D&source=editors&ust=1718703186643938&usg=AOvVaw3SXr6OskPXZg9H5uVtNAuP)
+
+device controller
+
+The [controller](#h.gemoqe2m303z) of a device capable of digital [communications](#h.w02a6srdng3j), e.g., a smartphone, tablet, laptop, IoT device, etc.
+
+dictionary
+
+A dictionary is a listing of lexemes (words or [terms](#h.ojn7uxdcaf7u)) from the lexicon of one or more specific languages, often arranged alphabetically, which may include information on [definitions](#h.beph188xy39q), usage, etymologies, pronunciations, translation, etc. It is a lexicographical reference that shows inter-relationships among the [data](#h.o783ayrrkc6g). Unlike a [glossary](#h.z1he49173rzw), a dictionary may provide multiple [definitions](#h.beph188xy39q) of a [term](#h.ojn7uxdcaf7u) depending on its [scope](#h.5cfb6xokygh4) or context.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Dictionary&sa=D&source=editors&ust=1718703186645118&usg=AOvVaw3j_sHHgLJBDfHjDY_O4tSb).
+
+DID
+
+See: [decentralized identifier](#h.x1jp59hgbk2l).
+
+DID controller
+
+An [entity](#h.5imtbzl1f4xo) that has the capability to make changes to a [DID document](#h.yjwocacp570p). A [DID](#h.zh539v9ul471) might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the [DID document](#h.yjwocacp570p). Note that a DID controller might be the [DID subject](#h.486g323w9jsf).
+
+Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186646023&usg=AOvVaw1f53u6vss7TVjsp5QRIGqs).
+
+See also: [controller](#h.gemoqe2m303z).
+
+DID document
+
+A set of data describing the [DID subject](#h.486g323w9jsf), including mechanisms, such as cryptographic public keys, that the [DID subject](#h.486g323w9jsf) or a DID delegate can use to [authenticate](#h.gp553sxzbmv1) itself and prove its association with the [DID](#h.zh539v9ul471). A DID document might have one or more different representations as defined in section 6 of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.google.com/url?q=https://www.w3.org/TR/did-core/&sa=D&source=editors&ust=1718703186646649&usg=AOvVaw3-xXcWUxmbYaKwaUmlIyDG) specification.
+
+Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186646894&usg=AOvVaw0mWmFJ9wZ8e3kS6Sa9hKGt).
+
+DID method
+
+A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which [DIDs](#h.zh539v9ul471) and [DID documents](#h.yjwocacp570p) are created, resolved, updated, and deactivated.
+
+Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23dfn-did-methods&sa=D&source=editors&ust=1718703186647497&usg=AOvVaw1vdVhC_YEVLy6Ie7URbBD_).
+
+For more information: [https://www.w3.org/TR/did-core/#methods](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23methods&sa=D&source=editors&ust=1718703186647803&usg=AOvVaw1sy56E2s8fPDepYzRzKQqm) 
+
+DID subject
+
+The [entity](#h.5imtbzl1f4xo) identified by a [DID](#h.zh539v9ul471) and described by a [DID document](#h.yjwocacp570p). Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.
+
+Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23dfn-did-subjects&sa=D&source=editors&ust=1718703186648301&usg=AOvVaw2PJKnozNU1z_FVlS-oQFnI).
+
+See also: [subject](#h.voca6uuv1a4).
+
+DID URL
+
+A [DID](#h.zh539v9ul471) plus any additional syntactic component that conforms to the definition in section 3.2 of the [W3C Decentralized Identifiers (DIDs) 1.0](https://www.google.com/url?q=https://www.w3.org/TR/did-core/&sa=D&source=editors&ust=1718703186648719&usg=AOvVaw0mnda0S_lxDlwrGp2Ip0Jr) specification. This includes an optional DID path (with its leading / character), optional DID query (with its leading ? character), and optional DID fragment (with its leading # character).
+
+Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23dfn-did-urls&sa=D&source=editors&ust=1718703186649133&usg=AOvVaw0EaEzL0r-feVdq05848E3A).
+
+digital agent
+
+In the context of ​​decentralized digital trust infrastructure, an [agent](#h.6xkhfkjpo6xg) (specifically a type of [software agent](#h.qv9e403ohhxe)) that operates in conjunction with a [digital wallet](#h.sxnvf3f5v156).
+
+Note: In a ToIP context, a digital agent is frequently assumed to have privileged access to the [digital wallet](#h.sxnvf3f5v156)(s) of its principal. In market parlance, a mobile app that performs the [actions](#h.l54nzmooy631) of a digital agent is often simply called a [wallet](#h.mh27630t20d) or a [digital wallet](#h.sxnvf3f5v156).
+
+digital asset
+
+A digital asset is anything that exists only in digital form and comes with a distinct usage right. [Data](#h.o783ayrrkc6g) that do not possess that right are not considered assets.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_asset&sa=D&source=editors&ust=1718703186650250&usg=AOvVaw25uMZiNUOb714myiHO_xs7).
+
+See also: [digital credential](#h.ddna9lucn4k6).
+
+digital certificate
+
+See: [public key certificate](#h.anf8g7aq0gk5).
+
+digital credential
+
+A [credential](#h.kcj6iw2vib1v) in digital form that is signed with a [digital signature](#h.s93np0i5rcne) and held in a [digital wallet](#h.sxnvf3f5v156). A digital credential is issued to a [holder](#h.64mptmm24w7u) by an [issuer](#h.xyrplzbvtffq); a [proof](#h.r2qw6757lopw) of the credential is [presented](#h.h5d1xfsxbbr0) by the [holder](#h.64mptmm24w7u) to a [verifier](#h.xfewd7t01hu0).
+
+See also: [issuance request](#h.tt253lgfp4hz), [presentation request](#h.onnn49cjzreh), [verifiable credential](#h.co5algna3zkh).
+
+Contrast with: [physical credential](#h.xnlz1vfx60mn).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_credential&sa=D&source=editors&ust=1718703186651879&usg=AOvVaw2TnU3thde7MSmOlVvfJRRS): Digital credentials are the digital equivalent of paper-based [credentials](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Credentials&sa=D&source=editors&ust=1718703186652129&usg=AOvVaw2gK2zwzOPrUoNc-nIbivgE). Just as a paper-based credential could be a [passport](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Passport&sa=D&source=editors&ust=1718703186652294&usg=AOvVaw1DHIT6qLt3xQZwncITQqL4), a [driver's license](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Driver%2527s_license&sa=D&source=editors&ust=1718703186652452&usg=AOvVaw2YGcWkDOoI5EXju3t9iI5Z), a membership certificate or some kind of ticket to obtain some service, such as a cinema ticket or a public transport ticket, a digital credential is a proof of qualification, competence, or clearance that is attached to a person.
+
+digital ecosystem
+
+A digital ecosystem is a distributed, adaptive, open socio-technical system with properties of self-organization, scalability and sustainability inspired from natural ecosystems. Digital ecosystem models are informed by knowledge of natural ecosystems, especially for aspects related to competition and collaboration among diverse [entities](#h.5imtbzl1f4xo).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_ecosystem&sa=D&source=editors&ust=1718703186653056&usg=AOvVaw24Bgtp-FZTqpU-3ESvI_QX).
+
+See also: [digital trust ecosystem](#h.h47f86smlz4y), [trust community](#h.a9l3odcb1s29).
+
+digital identity
+
+An [identity](#h.z1gairv0pej5) expressed in a digital form for the purpose representing the identified [entity](#h.5imtbzl1f4xo) within a computer system or digital network.
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary&sa=D&source=editors&ust=1718703186653665&usg=AOvVaw3H3O1mvGsCv5K5aWjNoerY): [Digital data](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23data&sa=D&source=editors&ust=1718703186653844&usg=AOvVaw182PR81TdrnULE1pFF-F2I) that enables a specific [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23entity&sa=D&source=editors&ust=1718703186654027&usg=AOvVaw3hlrvcRJbkFhz1c3GJsgHW) to be distinguished from all others in a specific context.
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_identity&sa=D&source=editors&ust=1718703186654250&usg=AOvVaw19ZGTDnk15WW_JPoclQqgh): Digital identity refers to the information utilized by [computer systems](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_systems&sa=D&source=editors&ust=1718703186654403&usg=AOvVaw3MoK6DkwJmvsCLi8ySPkE6) to represent external entities, including a person, organization, application, or device. When used to describe an individual, it encompasses a person's compiled information and plays a crucial role in automating access to computer-based services, verifying identity online, and enabling computers to mediate relationships between entities.
+
+digital rights management
+
+Digital rights management (DRM) is the management of legal access to digital content. Various tools or technological protection measures (TPM) like [access control](#h.lmk4gqobt99b) technologies, can restrict the use of proprietary hardware and copyrighted works. DRM technologies govern the use, modification and distribution of copyrighted works (e.g. software, multimedia content) and of systems that enforce these policies within devices.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_rights_management&sa=D&source=editors&ust=1718703186654970&usg=AOvVaw2VLnTYAQMRy-DLI8fmleZM).
+
+Also known as: [DRM](#h.m9um65bhu37).
+
+digital trust ecosystem
+
+A [digital ecosystem](#h.edgw5dskp7an) in which the participants are one or more interoperating [trust communities](#h.a9l3odcb1s29). Governance of the various [roles](#h.sf54cyuamo6x) of [governed parties](#h.c1jlj376y5m3) within a digital trust ecosystem (e.g., [issuers](#h.xyrplzbvtffq), [holders](#h.64mptmm24w7u), [verifiers](#h.xfewd7t01hu0), [certification bodies](#h.noh9fchc9jx), [auditors](#h.g2w6uyjqzrr)) is typically managed by a [governing body](#h.1wptecwzvuvz) using a [governance framework](#h.2x05z0r097mn) as recommended in the [ToIP Governance Stack](#h.ciwa0pidrb2e). Many digital trust ecosystems will also maintain one or more [trust lists](#h.f1feh0fmucqd) and/or [trust registries](#h.5kzln6m5e8j5).
+
+digital trust utility
+
+An information system, network, distributed database, or [blockchain](#h.bxz57auzxstx) designed to provide one or more supporting services to higher level components of decentralized digital trust infrastructure. In the [ToIP stack](#h.wms58fgdch9m), digital trust utilities are at [Layer 1](#h.v1hjglhanrdl). A [verifiable data registry](#h.q1dr1v2lltfe) is one type of digital trust utility.
+
+digital signature
+
+A digital signature is a mathematical scheme for verifying the authenticity of digital [messages](#h.bge7ubygwk2q) or documents. A valid digital signature, where the prerequisites are satisfied, gives a recipient very high confidence that the [message](#h.bge7ubygwk2q) was created by a known sender ([authenticity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Authentication&sa=D&source=editors&ust=1718703186656384&usg=AOvVaw3Fx7ketDNkjM1l0foH4lmh)), and that the message was not altered in transit ([integrity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data_integrity&sa=D&source=editors&ust=1718703186656566&usg=AOvVaw0tH5Rth6P1Z7Nfe3Ur8hWK)).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_signature&sa=D&source=editors&ust=1718703186656777&usg=AOvVaw2RSHDvq1eKSGR1EK9XhveE).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/digital_signature&sa=D&source=editors&ust=1718703186657033&usg=AOvVaw2DxFBA1CvHVeY4Q2aO0fwn): The result of a cryptographic transformation of data which, when properly implemented, provides the services of: 1. origin authentication, 2. data integrity, and 3. signer non-repudiation.
+
+digital vault
+
+A secure container for [data](#h.o783ayrrkc6g) whose [controller](#h.gemoqe2m303z) is the [principal](#h.sydbe7rk6244). A digital vault is most commonly used in conjunction with a [digital wallet](#h.sxnvf3f5v156) and a [digital agent](#h.z3ugzt4hgdf6). A digital vault may be implemented on a local device or in the cloud; multiple digital vaults may be used by the same [principal](#h.sydbe7rk6244) across different devices and/or the cloud; if so they may use some type of synchronization. If the capability is supported, [data](#h.o783ayrrkc6g) may flow into or out of the digital vault automatically based on [subscriptions](#h.59sxmlru2xqb) approved by the [controller](#h.gemoqe2m303z).
+
+Also known as: [data vault](#h.r86ltcrr5evr), [encrypted data vault](#h.x4ayv74r9gbs).
+
+See also: [enterprise data vault](#h.3una07qf7p4u), [personal data vault](#h.9b2ram5w4omg), [virtual vault](#h.7dcabufiu2bo).
+
+For more information, see: [https://en.wikipedia.org/wiki/Personal\_data\_service](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Personal_data_service&sa=D&source=editors&ust=1718703186658182&usg=AOvVaw2Z1K2se_1d2wFJZsA_4tqm), [https://digitalbazaar.github.io/encrypted-data-vaults/](https://www.google.com/url?q=https://digitalbazaar.github.io/encrypted-data-vaults/&sa=D&source=editors&ust=1718703186658428&usg=AOvVaw0aJk85N9Tc7pAL1EMp77V0)
+
+digital wallet
+
+A [user agent](#h.jb61co23rlut), optionally including a hardware component, capable of securely storing and processing [cryptographic keys](#h.53rzpn1yn6q7), [digital credentials](#h.ddna9lucn4k6), [digital assets](#h.emffux4xw3th) and other sensitive private [data](#h.o783ayrrkc6g) that enables the [controller](#h.gemoqe2m303z) to perform [cryptographically verifiable](#h.422iwwfur12) operations. A [non-custodial wallet](#h.ridlo7ub9haf) is directly in the custody of a [principal](#h.sydbe7rk6244). A [custodial wallet](#h.5qanwm5930bp) is in the [custody](#h.8kx1mv7y64ps) of a [third party](#h.zu2vj8151tr). [Personal wallets](#h.1qe7g02c5t4p) are held by individual persons; [enterprise wallets](#h.lwbrzpnzaqth) are held by [organizations](#h.z27mp1358pi9) or other [legal entities](#h.5328bxxk02sb).
+
+See also: [digital agent](#h.z3ugzt4hgdf6), [key management system](#h.q0w3jq78va39), [wallet engine](#h.jsmi4264di2s).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23wallet&sa=D&source=editors&ust=1718703186659930&usg=AOvVaw35Qs_vv2EcDTKPht9wePgV): a component that implements the [capability](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/capability&sa=D&source=editors&ust=1718703186660122&usg=AOvVaw0aod1TundJ62xxXa4Xo-34) to securely store data as requested by [colleague agents](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/colleague&sa=D&source=editors&ust=1718703186660279&usg=AOvVaw0CSFja5fdzGwQIE3K-ShSP), and to provide stored data to [colleague agents](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/colleague&sa=D&source=editors&ust=1718703186660424&usg=AOvVaw0WyEhP8cJ0PWgxWikeZqBP) or [peer agents](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/peer-agent&sa=D&source=editors&ust=1718703186660598&usg=AOvVaw1WvaBzrA7jsVxafZErln6v), all in [compliance](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/compliance&sa=D&source=editors&ust=1718703186660746&usg=AOvVaw3CYSL6ilG8bi49BdYX5DnM) with the rules of its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186660896&usg=AOvVaw2oNKODgcKOS09JfUO6RORR)'s [wallet policy](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/wallet-policy&sa=D&source=editors&ust=1718703186661055&usg=AOvVaw0cL7lLHsyX18MHADWffuA8).
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_wallet&sa=D&source=editors&ust=1718703186661250&usg=AOvVaw1dT-0Km4FWHyjjOJAMeB-N): A digital wallet, also known as an e-wallet, is an [electronic device](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Consumer_electronics&sa=D&source=editors&ust=1718703186661401&usg=AOvVaw2G73RRSafu7c4xx6iE6URV), [online service](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Online_service_provider&sa=D&source=editors&ust=1718703186661554&usg=AOvVaw3wYxAJEw-hPjYR4L4RWNZN), or [software program](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_program&sa=D&source=editors&ust=1718703186661705&usg=AOvVaw21GWC9FflhOXEfqfgZW7U1) that allows one party to make [electronic transactions](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_transaction&sa=D&source=editors&ust=1718703186661847&usg=AOvVaw1i4cmKH8Q8i6WHWSc2iruQ) with another party bartering [digital currency](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_currency&sa=D&source=editors&ust=1718703186661999&usg=AOvVaw2kyBJmoxSR45TmyiEUx81J) units for [goods and services](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Goods_and_services&sa=D&source=editors&ust=1718703186662140&usg=AOvVaw0oJYK1i6-YrsIC1o19aRyn). This can include purchasing items either [online](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Online_and_offline&sa=D&source=editors&ust=1718703186662306&usg=AOvVaw1Of-9a_c4dmYRvTlYwejIu) or at the [point of sale](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Point_of_sale&sa=D&source=editors&ust=1718703186662514&usg=AOvVaw0LxWFgYflg4pei_7ZIbG3x) in a [brick and mortar](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Brick_and_mortar&sa=D&source=editors&ust=1718703186662659&usg=AOvVaw1_tKY3bKdiXLIMtxsFN3fi) store, using either [mobile payment](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mobile_payment&sa=D&source=editors&ust=1718703186662796&usg=AOvVaw3nizWzMu1nodlW9P9iTLrr) (on a [smartphone](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Smartphone&sa=D&source=editors&ust=1718703186662925&usg=AOvVaw2pgz95IcLTKBoCROYB8IaZ) or other [mobile device](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mobile_device&sa=D&source=editors&ust=1718703186663060&usg=AOvVaw3C9ehhYf1Kl00VbiQcT-kQ)) or (for online buying only) using a [laptop](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Laptop&sa=D&source=editors&ust=1718703186663194&usg=AOvVaw2wcvLMum9Hrf4CKduPzM-L) or other [personal computer](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Personal_computer&sa=D&source=editors&ust=1718703186663376&usg=AOvVaw0aNWXkxebZySu2EgJDJJU8). Money can be deposited in the digital wallet prior to any transactions or, in other cases, an individual's bank account can be linked to the digital wallet. Users might also have their [driver's license](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Driver%2527s_license&sa=D&source=editors&ust=1718703186663543&usg=AOvVaw08ZnaUOiR7X_TMV52vkcsy), [health card](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Health_Care_Card&sa=D&source=editors&ust=1718703186663741&usg=AOvVaw1zmdq_hhLoaRGSlpVEpYFM), loyalty card(s) and other ID documents stored within the wallet. The credentials can be passed to a merchant's terminal wirelessly via [near field communication](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Near_field_communication&sa=D&source=editors&ust=1718703186663901&usg=AOvVaw3-PqXWexCF9GXJBgmZC8Ds) (NFC).
+
+Note: In market parlance, a mobile app that performs the [actions](#h.l54nzmooy631) of a [digital agent](#h.z3ugzt4hgdf6) and has access to a set of [cryptographic keys](#h.53rzpn1yn6q7) is often simply called a [wallet](#h.mh27630t20d) or a digital wallet.
+
+distributed ledger
+
+A distributed ledger (also called a shared ledger or distributed ledger technology or DLT) is the consensus of replicated, shared, and synchronized digital [data](#h.o783ayrrkc6g) that is geographically spread (distributed) across many sites, countries, or institutions. In contrast to a centralized database, a distributed ledger does not require a central administrator, and consequently does not have a single (central) point-of-failure. In general, a distributed ledger requires a [peer-to-peer](#h.ikjsqxobvozv) (P2P) computer network and consensus algorithms so that the ledger is reliably replicated across distributed computer [nodes](#h.w1aty8c036fp) (servers, clients, etc.). The most common form of distributed ledger technology is the [blockchain](#h.bxz57auzxstx), which can either be on a public or private network.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Distributed_ledger&sa=D&source=editors&ust=1718703186665039&usg=AOvVaw2HXsEotMWsLtEyXEtD-aIL).
+
+domain
+
+See: [security domain](#h.d7ry9j100f36).
+
+See also: [trust domain](#h.60miqe21hd5h).
+
+DRM
+
+See: [digital rights management](#h.d6exis1ya9fd).
+
+DWN
+
+See: [Decentralized Web Node](#h.ygukfig9m4mn).
+
+ecosystem
+
+See: [digital ecosystem](#h.edgw5dskp7an).
+
+ecosystem governance framework
+
+A [governance framework](#h.2x05z0r097mn) for a [digital trust ecosystem](#h.h47f86smlz4y). An ecosystem governance framework may incorporate, aggregate, or reference other types of governance frameworks such as a [credential governance framework](#h.tlmucrcg1d6g) or a [utility governance framework](#h.n08ql59sgrtn).
+
+eIDAS
+
+eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation with the stated purpose of governing "electronic identification and [trust services](#h.lob8zt6w1hh) for electronic transactions". It passed in 2014 and its provisions came into effect between 2016-2018.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/EIDAS&sa=D&source=editors&ust=1718703186666543&usg=AOvVaw0CBeB68r9Ja_zlWzsU17tT).
+
+encrypted data vault
+
+See: [digital vault](#h.cz29glapo2tg).
+
+encryption
+
+Cryptographic transformation of [data](#h.o783ayrrkc6g) (called [plaintext](#h.ylf3pqlex968)) into a form (called [ciphertext](#h.9ripqbaz7egw)) that conceals the [data’s](#h.o783ayrrkc6g) original meaning to prevent it from being known or used. If the transformation is reversible, the corresponding reversal process is called [decryption](#h.fuc05ut9lwmq), which is a transformation that restores encrypted [data](#h.o783ayrrkc6g) to its original state.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/encryption&sa=D&source=editors&ust=1718703186667381&usg=AOvVaw0xeaceME-sZGIK6QtMO1kQ).
+
+end-to-end encryption
+
+[Encryption](#h.iyq318f2vg61) that is applied to a [communication](#h.w02a6srdng3j) before it is transmitted from the sender’s [communication endpoint](#h.qstkv072p5tx) and cannot be [decrypted](#h.fuc05ut9lwmq) until after it is received at the receiver’s [communication endpoint](#h.qstkv072p5tx). When end-to-end encryption is used, the [communication](#h.w02a6srdng3j) cannot be [decrypted](#h.fuc05ut9lwmq) in transit no matter how many [intermediary systems](#h.i4pfys3yiku) are involved in the [routing](#h.tbxetxt0mdlp) process.
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/End-to-end_encryption&sa=D&source=editors&ust=1718703186668207&usg=AOvVaw0dC1_2oMsihnDwtY9rDKCN): End-to-end encryption (E2EE) is a private communication system in which only communicating users can participate. As such, no one, including the communication system provider, [telecom providers](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Telecommunications_service_providers&sa=D&source=editors&ust=1718703186668402&usg=AOvVaw22A-aRjwLrWzLN2bC4QBKY), [Internet providers](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_providers&sa=D&source=editors&ust=1718703186668552&usg=AOvVaw2PRFvoTEmUjerPd1Gnt4wc) or malicious actors, can access the [cryptographic keys](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Key_\(cryptography\)&sa=D&source=editors&ust=1718703186668699&usg=AOvVaw10Qf53r4NTDWEwCFgsHBBf) needed to converse. End-to-end [encryption](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Encryption&sa=D&source=editors&ust=1718703186668875&usg=AOvVaw2ijLrOUUGzDhNQUZzq-zoR) is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves.
+
+End-to-End Principle
+
+The end-to-end principle is a design framework in computer networking. In networks designed according to this principle, guaranteeing certain application-specific features, such as reliability and security, requires that they reside in the communicating end [nodes](#h.w1aty8c036fp) of the network. [Intermediary](#h.p89mgcb8dbec) nodes, such as [gateways](#h.x6n84riqc6ll) and [routers](#h.oqbqyf914pln), that exist to establish the network, may implement these to improve efficiency but cannot guarantee end-to-end correctness.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/End-to-end_principle&sa=D&source=editors&ust=1718703186669641&usg=AOvVaw1g64gTffvO6PdeNc7usH-Y).
+
+For more information, see: [https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf](https://www.google.com/url?q=https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf&sa=D&source=editors&ust=1718703186669859&usg=AOvVaw20lJ9vohjlIvPN17cIhYxl) 
+
+endpoint
+
+See: [communication endpoint](#h.qstkv072p5tx).
+
+See also: [ToIP endpoint](#h.2ahqabymbkn3).
+
+endpoint system
+
+The system that operates a [communications](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.w02a6srdng3j&sa=D&source=editors&ust=1718703186670436&usg=AOvVaw2xvNokdBbHJ97hL1bfXBUq) [endpoint](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.yodlnk353mx&sa=D&source=editors&ust=1718703186670696&usg=AOvVaw0Ykbq76esIt0v5iTIYTekI). In the context of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186670926&usg=AOvVaw2fZ7KYFu5SRQHm8weaMvgk), an endpoint system is one of three types of systems defined in the [ToIP Technology Architecture Specification](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.bjv9ltwjbiqm&sa=D&source=editors&ust=1718703186671174&usg=AOvVaw1k-4nMgTP4IAgZtJZSVr4B).
+
+See also: [intermediary system](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.i4pfys3yiku&sa=D&source=editors&ust=1718703186671490&usg=AOvVaw2w8kCvcKIAIh_MahjKZRhm), [supporting system](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.nqtdtghyfspz&sa=D&source=editors&ust=1718703186671707&usg=AOvVaw3KPDimzc9fVX8um5h1g6PC).
+
+enterprise data vault
+
+A [digital vault](#h.cz29glapo2tg) whose [controller](#h.gemoqe2m303z) is an [organization](#h.z27mp1358pi9).
+
+enterprise wallet
+
+A [digital wallet](#h.sxnvf3f5v156) whose [holder](#h.64mptmm24w7u) is an [organization](#h.z27mp1358pi9).
+
+Contrast with: [personal wallet](#h.1qe7g02c5t4p).
+
+entity
+
+Someone or something that is known to exist.
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary&sa=D&source=editors&ust=1718703186672621&usg=AOvVaw2kh7HUuctRkQmUxOwa2rqV).
+
+ephemeral connection
+
+A [connection](#h.thbpewq1px8x) that only exists for the duration of a single [communication session](#h.i82tgrmxy0d8) or [transaction](#h.92pu88ke4p7k).
+
+Contrast with: [persistent connection](#h.ccf1vkxvhh1l).
+
+expression language
+
+A language for creating a computer-interpretable ([machine-readable](#h.8s3s84fzcfi3)) representation of specific [knowledge](#h.k96lktyswxnb).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Expression_language&sa=D&source=editors&ust=1718703186673561&usg=AOvVaw2iuUQfrnbdCGQw09L8JkIx).
+
+FAL
+
+See: [federation assurance level](#h.8fhj7rpnpjy3).
+
+federated identity
+
+A [digital identity](#h.r5y8zwxvzyd3) architecture in which a [digital identity](#h.r5y8zwxvzyd3) established on one computer system, network, or [trust domain](#h.60miqe21hd5h) is linked to other computer systems, networks, or [trust domains](#h.60miqe21hd5h) for the purpose of identifying the same [entity](#h.5imtbzl1f4xo) across those domains.
+
+See also: [decentralized identity](#h.xodo7ytn4cx2), [self-sovereign identity](#h.wdojy63bltd4).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/federated_identity_management&sa=D&source=editors&ust=1718703186674567&usg=AOvVaw03588NDUaj1uHtocuLGFYg); A process that allows for the conveyance of identity and authentication information across a set of networked systems.
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Federated_identity&sa=D&source=editors&ust=1718703186674784&usg=AOvVaw2DYBFB-uuGfNCUaSrD1Gor): A federated identity in [information technology](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Information_technology&sa=D&source=editors&ust=1718703186674964&usg=AOvVaw1Wvy8Yhph3o9igtchfyyyq) is the means of linking a person's [electronic identity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_identity&sa=D&source=editors&ust=1718703186675113&usg=AOvVaw31bRR2JjwYwVH6vqEBjIk-) and attributes, stored across multiple distinct [identity management](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Identity_management&sa=D&source=editors&ust=1718703186675529&usg=AOvVaw03SOCXGH7PaCL2M9DylN96) systems.
+
+federation
+
+A group of [organizations](#h.z27mp1358pi9) that collaborate to establish a common [trust framework](#h.2r5mn949idq) or [governance framework](#h.2x05z0r097mn) for the exchange of [identity data](#h.t3ho4tago38u) in a [federated identity](#h.cb1le64hx6h5) system.
+
+See also: [trust community](#h.a9l3odcb1s29)
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/federation&sa=D&source=editors&ust=1718703186676170&usg=AOvVaw0y-nqiCjU5eFmhORdTMogU): A collection of realms (domains) that have established trust among themselves. The level of trust may vary, but typically includes authentication and may include authorization.
+
+federation assurance level
+
+A category that describes the [federation](#h.7ph0icfh463b) protocol used to communicate an assertion containing [authentication](#h.ej596duqqmnb) and [attribute](#h.ky5nh3yri7ak) information (if applicable) to a [relying party](#h.61sr3qnr1eci), as defined in [NIST SP 800-63-3](https://www.google.com/url?q=https://pages.nist.gov/800-63-3/&sa=D&source=editors&ust=1718703186676668&usg=AOvVaw1Rqq9sCCCpSS0Hb9l7523p) in terms of three levels: FAL 1 (Some confidence), FAL 2 (High confidence), FAL 3 (Very high confidence).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/federation_assurance_level&sa=D&source=editors&ust=1718703186676887&usg=AOvVaw0KnpTCf7cQYIcoWCsowPN1).
+
+See also: [authenticator assurance level](#h.a7560ebfrt4m), [identity assurance level](#h.udr0qmo2ubln).
+
+fiduciary
+
+A fiduciary is a person who holds a legal or ethical relationship of trust with one or more other [parties](#h.cn6bno48fomj) (person or group of persons). Typically, a fiduciary prudently takes care of money or other [assets](#h.emffux4xw3th) for another person. One [party](#h.cn6bno48fomj), for example, a corporate trust company or the trust department of a bank, acts in a fiduciary capacity to another [party](#h.cn6bno48fomj), who, for example, has entrusted funds to the fiduciary for safekeeping or investment. In a fiduciary relationship, one person, in a position of vulnerability, justifiably vests confidence, good faith, reliance, and trust in another whose aid, advice, or protection is sought in some matter.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Fiduciary&sa=D&source=editors&ust=1718703186677639&usg=AOvVaw1c7pYb56LNZ7hrGEAeEZe4).
+
+first party
+
+The [party](#h.cn6bno48fomj) who initiates a [trust relationship](#h.pu2asd79bqzo), [connection](#h.thbpewq1px8x), or [transaction](#h.92pu88ke4p7k) with a [second party](#h.hk94wskqnzri).
+
+See also: [third party](#h.zu2vj8151tr), [fourth party](#h.ur40pjfb49t1).
+
+foundational identity
+
+A set of [identity data](#h.t3ho4tago38u), such as a [credential](#h.kcj6iw2vib1v), [issued](#h.xyrplzbvtffq) by an [authoritative source](#h.9tt1qpgdfnxs) for the [legal identity](#h.s0f760qh7yij) of the [subject](#h.voca6uuv1a4). Birth certificates, passports, driving licenses, and other forms of government ID documents are considered foundational [identity documents](#h.k7034pvtr21k). Foundational identities are often used to provide [identity binding](#h.kwudvu8h2zex) for [functional identities](#h.tk5si1lqyz9q).
+
+Contrast with: [functional identity](#h.tk5si1lqyz9q).
+
+fourth party
+
+A [party](#h.cn6bno48fomj) that is not directly involved in the trust relationship between a [first party](#h.uxx5bjam20ag) and a [second party](#h.hk94wskqnzri), but provides supporting services exclusively to the [first party](#h.uxx5bjam20ag) (in contrast with a [third party](#h.zu2vj8151tr), who in most cases provides supporting services to the [second party](#h.hk94wskqnzri)). In its strongest form, a [fourth party](#h.ur40pjfb49t1) has a [fiduciary](#h.5w05xlh4j8ms) relationship with the [first party](#h.uxx5bjam20ag).
+
+functional identity
+
+A set of [identity data](#h.t3ho4tago38u), such as a [credential](#h.kcj6iw2vib1v), that is [issued](#h.xyrplzbvtffq) not for the purpose of establishing a [foundational identity](#h.ig62zx2lc56o) for the subject, but for the purpose of establishing other attributes, qualifications, or capabilities of the subject. Loyalty cards, library cards, and employee IDs are all examples of functional identities. [Foundational identities](#h.ig62zx2lc56o) are often used to provide [identity binding](#h.kwudvu8h2zex) for functional identities.
+
+gateway
+
+A gateway is a piece of networking hardware or software used in telecommunications networks that allows [data](#h.o783ayrrkc6g) to flow from one discrete network to another. Gateways are distinct from [routers](#h.oqbqyf914pln) or switches in that they communicate using more than one protocol to connect multiple networks[\[1\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Gateway_\(telecommunications\)%23cite_note-1&sa=D&source=editors&ust=1718703186680622&usg=AOvVaw2SCSBdvdoEN26XC0TMnfYG)[\[2\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Gateway_\(telecommunications\)%23cite_note-2&sa=D&source=editors&ust=1718703186680842&usg=AOvVaw0tZeeETG0WZZFqXaavKvYl) and can operate at any of the seven layers of the open systems interconnection model (OSI).
+
+See also: [intermediary](#h.p89mgcb8dbec).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Gateway_\(telecommunications\)&sa=D&source=editors&ust=1718703186681147&usg=AOvVaw3F2E3tpXb6JhbSPvyBeIyU).
+
+GDPR
+
+See: [General Data Protection Regulation](#h.tks8sagp6iy0).
+
+General Data Protection Regulation
+
+The General Data Protection Regulation (Regulation (EU) 2016/679, abbreviated GDPR) is a European Union regulation on information privacy in the European Union (EU) and the European Economic Area (EEA). The GDPR is an important component of EU privacy law and human rights law, in particular Article 8(1) of the Charter of Fundamental Rights of the European Union. It also governs the transfer of [personal data](#h.rpiib2ml3s9c) outside the EU and EEA. The GDPR's goals are to enhance individuals' control and rights over their personal information and to simplify the regulations for international business.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/General_Data_Protection_Regulation&sa=D&source=editors&ust=1718703186681950&usg=AOvVaw3c3DJfeK4c6lgnqWiaG__l).
+
+Also known as: [GDPR](#h.5oxryjdg8s9w).
+
+glossary
+
+A glossary (from Ancient Greek: γλῶσσα, glossa; language, speech, wording), also known as a vocabulary or clavis, is an alphabetical list of [terms](#h.ojn7uxdcaf7u) in a particular domain of [knowledge](#h.k96lktyswxnb) ([scope](#h.5cfb6xokygh4)) together with the [definitions](#h.beph188xy39q) for those terms. Unlike a [dictionary](#h.ajluzjr0e4sa), a glossary has only one [definition](#h.beph188xy39q) for each term.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Glossary&sa=D&source=editors&ust=1718703186682877&usg=AOvVaw1KEPBsT5C6tjp_NNDBZ1TA).
+
+governance
+
+The [act](#h.gzdfngxkp0ip) or process of governing or overseeing the realization of (the results associated with) a set of [objectives](#h.k0v6ir8wmcav) by the [owner](#h.y450rpi0zmuu) of these [objectives](#h.k0v6ir8wmcav), in order to ensure they will be fit for the purposes that this [owner](#h.y450rpi0zmuu) intends to use them for.
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23governance&sa=D&source=editors&ust=1718703186683542&usg=AOvVaw2KItVEp2stATVuSXZLIpDb).
+
+Governance, Risk Management, and Compliance
+
+[Governance](#h.mu68tj5xpknp), [risk management](#h.8i5edrs9npxn), and [compliance](#h.r0iiayz1za1i) (GRC) are three related facets that aim to assure an [organization](#h.z27mp1358pi9) reliably achieves [objectives](#h.k0v6ir8wmcav), addresses uncertainty and acts with integrity. [Governance](#h.mu68tj5xpknp) is the combination of processes established and executed by the directors (or the board of directors) that are reflected in the [organization's](#h.z27mp1358pi9) structure and how it is managed and led toward achieving goals. [Risk management](#h.8i5edrs9npxn) is predicting and managing risks that could hinder the [organization](#h.z27mp1358pi9) from reliably achieving its [objectives](#h.k0v6ir8wmcav) under uncertainty. [Compliance](#h.r0iiayz1za1i) refers to adhering with the mandated boundaries (laws and regulations) and voluntary boundaries (company's policies, procedures, etc.)
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Governance,_risk_management,_and_compliance&sa=D&source=editors&ust=1718703186684422&usg=AOvVaw3ACgI_g0tD8c6xBllHqEz0).
+
+Also known as: [GRC](#h.jdf5ep893jgd).
+
+governance diamond
+
+A term that refers to the addition of a [governing body](#h.1wptecwzvuvz) to the standard [trust triangle](#h.n29niebkxky7) of [issuers](#h.xyrplzbvtffq), [holders](#h.64mptmm24w7u), and [verifiers](#h.xfewd7t01hu0) of [credentials](#h.kcj6iw2vib1v). The resulting combination of four [parties](#h.cn6bno48fomj) represents the basic structure of a [digital trust ecosystem](#h.h47f86smlz4y).
+
+governance document
+
+A document with at least one [identifier](#h.u3bfehmj4ed3) that specifies [governance requirements](#h.j4z5czk0dk8t) for a [trust community](#h.a9l3odcb1s29).
+
+Note: A governance document is a component of a [governance framework](#h.2x05z0r097mn).
+
+governance framework
+
+A collection of one or more [governance documents](#h.c8fvvxachz5h) published by the [governing body](#h.1wptecwzvuvz) of a [trust community](#h.a9l3odcb1s29).
+
+Also known as: [trust framework](#h.2r5mn949idq).
+
+Note: In the [digital identity](#h.r5y8zwxvzyd3) industry specifically, a governance framework is better known as a [trust framework](#h.2r5mn949idq). ToIP-conformant governance frameworks conform to the [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3) and follow the [ToIP Governance Metamodel](#h.rgnaglzbhy9v).
+
+governance graph
+
+A graph of the [governance](#h.mu68tj5xpknp) relationships between [entities](#h.5imtbzl1f4xo) with a [trust community](#h.a9l3odcb1s29). A governance graph shows which [nodes](#h.w1aty8c036fp) are the [governing bodies](#h.1wptecwzvuvz) and which are the [governed parties](#h.c1jlj376y5m3). In some cases, a governance graph can be traversed by making queries to one or more [trust registries](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5kzln6m5e8j5&sa=D&source=editors&ust=1718703186686341&usg=AOvVaw2EHKAygpru6gduxqrXsD0G).Note: a [party](#h.cn6bno48fomj) can play both [roles](#h.sf54cyuamo6x) and also be a participant in multiple [governance frameworks](#h.2x05z0r097mn).
+
+See also: [authorization graph](#h.5tvkchqqqka8), [reputation graph](#h.4wwkekt1wrs7), [trust graph](#h.eqx98nkqjzsv).
+
+governance requirement
+
+A [requirement](#h.ajxlw8r3dvcc) such as a [policy](#h.udts41hso4w4), [rule](#h.v7s575ulon74), or [technical specification](#h.u62ak0cgfdb1) specified in a [governance document](#h.c8fvvxachz5h).
+
+See also: [technical requirement](#h.l7t266ck3tjw).
+
+governed use case
+
+A use case specified in a [governance document](#h.c8fvvxachz5h) that results in specific [governance requirements](#h.j4z5czk0dk8t) within that [governance framework](#h.2x05z0r097mn). Governed use cases may optionally be discovered via a [trust registry](#h.5kzln6m5e8j5) authorized by the relevant [governance framework](#h.2x05z0r097mn).
+
+governed party
+
+A [party](#h.cn6bno48fomj) whose [role(s)](#h.sf54cyuamo6x) in a [trust community](#h.a9l3odcb1s29) is governed by the [governance requirements](#h.j4z5czk0dk8t) in a [governance framework](#h.2x05z0r097mn).
+
+governed information
+
+Any information published under the authority of a [governing body](#h.1wptecwzvuvz) for the purpose of governing a [trust community](#h.a9l3odcb1s29). This includes its [governance framework](#h.2x05z0r097mn) and any information available via an authorized [trust registry](#h.5kzln6m5e8j5).
+
+governing authority
+
+See: [governing body](#h.1wptecwzvuvz).
+
+governing body
+
+The [party](#h.cn6bno48fomj) (or set of [parties](#h.cn6bno48fomj)) authoritative for governing a [trust community](#h.a9l3odcb1s29), usually (but not always) by developing, publishing, maintaining, and enforcing a [governance framework](#h.2x05z0r097mn). A governing body may be a government, a formal legal entity of any kind, an informal group of any kind, or an individual. A governing body may also delegate operational responsibilities to an [administering body](#h.w8r6jg7mkdaj).
+
+Also known as: [governing authority](#h.hhkhnnadzpo1).
+
+GRC
+
+See: [Governance, Risk Management, and Compliance](#h.qo8q5iquhh9u).
+
+guardian
+
+A [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186689289&usg=AOvVaw0Qr1YU-9fd4agGK19qlIVC) that has been assigned rights and duties in a [guardianship arrangement](#h.tc250ixnd67w) for the purpose of caring for, protecting, guarding, and defending the [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186689578&usg=AOvVaw10l-CAhS2Nn7A1VLBA_pEq) that is the [dependent](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/dependent&sa=D&source=editors&ust=1718703186689787&usg=AOvVaw1IN-LXZb8T2t3_AyqiUfVo) in that [guardianship arrangement](#h.tc250ixnd67w). In the context of decentralized digital trust infrastructure, a guardian is issued [guardianship credentials](#h.mjrnala919ld) into their own [digital wallet](#h.sxnvf3f5v156) in order to perform such [actions](#h.l54nzmooy631) on behalf of the [dependent](#h.qvhbv3ov9zmy) as are required by this [role](#h.sf54cyuamo6x).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23guardian&sa=D&source=editors&ust=1718703186690285&usg=AOvVaw0apt2EiH0rZVERiDi6EoLK)
+
+See also: [custodian](#h.8kx1mv7y64ps), [zero-knowledge service provider](#h.qhfq42vp7l55).
+
+Mental Model: [eSSIF-Lab Guardianship](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/pattern-guardianship&sa=D&source=editors&ust=1718703186690665&usg=AOvVaw0ADOU217b-pX6O-6VfharF)
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_guardian&sa=D&source=editors&ust=1718703186690970&usg=AOvVaw0GKORujHmWNmnvrUTyqmiD): A legal guardian is a person who has been appointed by a court or otherwise has the legal authority (and the corresponding [duty](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Duty&sa=D&source=editors&ust=1718703186691172&usg=AOvVaw2Le1apnR4F6vtR9hQ7C9Ex)) to make decisions relevant to the personal and [property](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Property&sa=D&source=editors&ust=1718703186691394&usg=AOvVaw3r1MnLoeF-UybfLYT0OdeU) interests of another person who is deemed incompetent, called a [ward](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Ward_\(law\)&sa=D&source=editors&ust=1718703186691597&usg=AOvVaw1zRp3QLw7DNONg8dxHK6lx).
+
+For more information, see: [On Guardianship in Self-Sovereign Identity V2.0](https://www.google.com/url?q=https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf&sa=D&source=editors&ust=1718703186691823&usg=AOvVaw3jfhBDorL-ZgeqzQ8BwA4e) (April, 2023).
+
+Note: A guardian is a very different role than a [custodian](#h.8kx1mv7y64ps), who does not take any [actions](#h.l54nzmooy631) on behalf of a [principal](#h.sydbe7rk6244) unless explicitly [authorized](#h.gln5i78kxlfh).
+
+guardianship arrangement
+
+A guardianship arrangement (in a [jurisdiction](#h.uw2s3y6sjzjf)) is the specification of a set of rights and duties between [legal entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/legal-entity&sa=D&source=editors&ust=1718703186692447&usg=AOvVaw0rLDryxbsdJmvxNszHcwAG) of the [jurisdiction](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/jurisdiction&sa=D&source=editors&ust=1718703186692611&usg=AOvVaw0T82Us93E6rZ7i4wfV_d9o) that enforces these rights and duties, for the purpose of caring for, protecting, guarding, and defending one or more of these [entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/legal-entity&sa=D&source=editors&ust=1718703186692766&usg=AOvVaw1gF8qnBKk79OTuKvMdY9VH). At a minimum, the entities participating in a guardianship arrangement are the [guardian](#h.y3s9f56kpets) and the [dependent](#h.qvhbv3ov9zmy).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23guardian&sa=D&source=editors&ust=1718703186693069&usg=AOvVaw34TWEwIEOhBxH0ZopN1CSz)
+
+See also: [custodianship arrangement](#h.4hh9dvbp6177).
+
+Mental Model: [eSSIF-Lab Guardianship](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/pattern-guardianship&sa=D&source=editors&ust=1718703186693382&usg=AOvVaw1R7NnFXHnmjTL8ty54F0jW)
+
+For more information, see: [On Guardianship in Self-Sovereign Identity V2.0](https://www.google.com/url?q=https://sovrin.org/wp-content/uploads/Guardianship-Whitepaper-V2.0.pdf&sa=D&source=editors&ust=1718703186693672&usg=AOvVaw1NNFISQUbhcEqly5ttxxvz) (April, 2023).
+
+guardianship credential
+
+A [digital credential](#h.ddna9lucn4k6) [issued](#h.xyrplzbvtffq) by a [governing body](#h.1wptecwzvuvz) to a [guardian](#h.y3s9f56kpets) to empower the [guardian](#h.y3s9f56kpets) to undertake the rights and duties of a [guardianship arrangement](#h.tc250ixnd67w) on behalf of a [dependent](#h.qvhbv3ov9zmy).
+
+hardware security module
+
+A physical computing device that provides tamper-evident and intrusion-resistant safeguarding and management of digital [keys](#h.53rzpn1yn6q7) and other secrets, as well as crypto-processing.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/hardware_security_module_hsm&sa=D&source=editors&ust=1718703186694601&usg=AOvVaw1OvO8id3fDQS_8fTkEFEbv).
+
+Also known as: [HSM](#h.jj97g1z2zrr8).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/hardware_security_module_hsm&sa=D&source=editors&ust=1718703186695020&usg=AOvVaw2-0IIUzwh-pnnF8OPv6LU-): A physical computing device that provides tamper-evident and intrusion-resistant safeguarding and management of digital keys and other secrets, as well as crypto-processing. FIPS 140-2 specifies requirements for HSMs.
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Hardware_security_module&sa=D&source=editors&ust=1718703186695308&usg=AOvVaw3M_GSdcKE0_33SwGB9mKP7): A physical computing device that safeguards and manages secrets (most importantly [digital keys](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_keys&sa=D&source=editors&ust=1718703186695472&usg=AOvVaw3WMIKkKcgSEtG7bFwbfiOW)), performs [encryption](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Encryption&sa=D&source=editors&ust=1718703186695662&usg=AOvVaw0gMNB6ORVYBatjSCxJe2MP) and decryption functions for [digital signatures](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_signature&sa=D&source=editors&ust=1718703186695862&usg=AOvVaw2e9NhEjuecyO78r0u5y_vY), [strong authentication](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Strong_authentication&sa=D&source=editors&ust=1718703186696034&usg=AOvVaw0QbifaDKgN4KslutZS6aNb) and other cryptographic functions. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a [computer](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer&sa=D&source=editors&ust=1718703186696187&usg=AOvVaw37IVC14EjH0VCLlm8P1IN_) or [network server](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Server_\(computing\)&sa=D&source=editors&ust=1718703186696363&usg=AOvVaw3BtqNNWp4E9PP7tRZKeDHF). A hardware security module contains one or more [secure cryptoprocessor](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Secure_cryptoprocessor&sa=D&source=editors&ust=1718703186696511&usg=AOvVaw1u98tFu4TRraMh29uxkOwS) [chips](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Integrated_circuit&sa=D&source=editors&ust=1718703186696650&usg=AOvVaw2wpNG4_MG912rZ0qlx9OrW).
+
+hash
+
+The result of applying a [hash function](#h.q2vi1qb2i4z) to a [message](#h.bge7ubygwk2q).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/hash_value&sa=D&source=editors&ust=1718703186697163&usg=AOvVaw3Zx9D54llQewyys5LCv-NT).
+
+Also known as: hash output, hash result, hash value.
+
+hash function
+
+An algorithm that computes a numerical value (called the [hash value](#h.otz98gjrt2s)) on a [data](#h.o783ayrrkc6g) file or electronic [message](#h.bge7ubygwk2q) that is used to represent that file or message, and depends on the entire contents of the file or message. A hash function can be considered to be a fingerprint of the file or message. Approved hash functions satisfy the following properties: one-way (it is computationally infeasible to find any input that maps to any pre-specified output); and collision resistant (it is computationally infeasible to find any two distinct inputs that map to the same output).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/hash_function&sa=D&source=editors&ust=1718703186697908&usg=AOvVaw3HDpwive2IH4ItGFAcZhEm).
+
+holder (of a claim or credential)
+
+A [role](#h.sf54cyuamo6x) an [agent](#h.6xkhfkjpo6xg) performs by serving as the [controller](#h.gemoqe2m303z) of the [cryptographic keys](#h.53rzpn1yn6q7) and [digital](#h.ddna9lucn4k6) [credentials](#h.ddna9lucn4k6) in a [digital wallet](#h.sxnvf3f5v156). The holder makes [issuance requests](#h.tt253lgfp4hz) for [credentials](#h.kcj6iw2vib1v) and responds to [presentation requests](#h.onnn49cjzreh) for [credentials](#h.kcj6iw2vib1v). A holder is usually, but not always, a [subject](#h.voca6uuv1a4) of the [credentials](#h.kcj6iw2vib1v) they are holding.
+
+See also: [issuer](#h.xyrplzbvtffq), [verifier](#h.xfewd7t01hu0).
+
+Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186699012&usg=AOvVaw36lfrdGNtzdzeXTFRtKyfU)
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/holder&sa=D&source=editors&ust=1718703186699345&usg=AOvVaw0iKDhH3rj1sXzi6MlBv0hW): a component that implements the [capability](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/capability&sa=D&source=editors&ust=1718703186699570&usg=AOvVaw1aSsFU8iyMNbsbxNqfosAc) to handle [presentation requests](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/presentation-request&sa=D&source=editors&ust=1718703186699768&usg=AOvVaw1V7qwAUoRQBFq9J0Zc7-ia) from a [peer agent](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/peer-agent&sa=D&source=editors&ust=1718703186699923&usg=AOvVaw2tvMvWoYBi8hS5KORm_-SA), produce the requested data (a presentation) according to its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186700080&usg=AOvVaw00DGEPQeHjwPcS2ibCCMeU)'s [holder-policy](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/holder-policy&sa=D&source=editors&ust=1718703186700273&usg=AOvVaw0kgntv62GRx7PUurx3DISN), and send that in response to the request.
+
+[W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-holders&sa=D&source=editors&ust=1718703186700461&usg=AOvVaw1UwDt1ej0MsLzVXA-zOemJ): A role an [entity](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-entities&sa=D&source=editors&ust=1718703186700657&usg=AOvVaw3lJq3C2jTFhPY3QYXWjXes) might perform by possessing one or more [verifiable credentials](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186700816&usg=AOvVaw1QVJm6LbUsjf25M0H1egX6) and generating [presentations](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-presentations&sa=D&source=editors&ust=1718703186700958&usg=AOvVaw0PFu2nFZlXm-rjR-JX9XZC) from them. A holder is usually, but not always, a [subject](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-subjects&sa=D&source=editors&ust=1718703186701137&usg=AOvVaw3M1YqtMel9pKUGD60ib40M) of the [verifiable credentials](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186701329&usg=AOvVaw2m0K8RovojAaGWUjn2yeD8) they are holding. Holders store their [credentials](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-credential&sa=D&source=editors&ust=1718703186701490&usg=AOvVaw0KfCb_-KvqGfywrLm18huM) in [credential repositories](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-credential-repository&sa=D&source=editors&ust=1718703186701677&usg=AOvVaw0MQSRkD7TD4xhdoKtUunSq).
+
+holder binding
+
+The process of creating and verifying a relationship between the [holder](#h.64mptmm24w7u) of a [digital wallet](#h.sxnvf3f5v156) and the wallet itself. Holder binding is related to but NOT the same as subject binding.
+
+host
+
+A host is any hardware device that has the capability of permitting access to a network via a user interface, specialized software, [network address](#h.v9gosdu5b7z5), [protocol stack](#h.6ik2cef0ipsr), or any other means. Some examples include, but are not limited to, computers, personal electronic devices, thin clients, and multi-functional devices.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/host&sa=D&source=editors&ust=1718703186702427&usg=AOvVaw2mZe-r6ziul1y8LYWGOGle).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Host_\(network\)&sa=D&source=editors&ust=1718703186702656&usg=AOvVaw1QZ54xHiY7Mb8dQDGA-nUO): A network host is a [computer](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer&sa=D&source=editors&ust=1718703186702790&usg=AOvVaw2MbLiZ0ZZx4OzFtZoIO8Yk) or other device connected to a [computer network](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Computer_network&sa=D&source=editors&ust=1718703186702938&usg=AOvVaw0u2Usa7MUnmz0EmxdYMtgI). A host may work as a [server](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Server_\(computing\)&sa=D&source=editors&ust=1718703186703132&usg=AOvVaw3TlO0R3iWhyUBwkQrocmbc) offering information resources, services, and applications to users or other hosts on the network. Hosts are assigned at least one [network address](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Network_address&sa=D&source=editors&ust=1718703186703290&usg=AOvVaw0FTkjxbo3fgHwKiteI-HG5). A computer participating in networks that use the [Internet protocol suite](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_protocol_suite&sa=D&source=editors&ust=1718703186703438&usg=AOvVaw3d22hYZQe7jcYgSS9cEVQb) may also be called an IP host. Specifically, computers participating in the [Internet](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet&sa=D&source=editors&ust=1718703186703598&usg=AOvVaw1XdyLAtdTfkUVJrs-mGqzl) are called Internet hosts. Internet hosts and other IP hosts have one or more [IP addresses](https://www.google.com/url?q=https://en.wikipedia.org/wiki/IP_address&sa=D&source=editors&ust=1718703186703735&usg=AOvVaw2hryOFkmVLRB1Mksd1_iTT) assigned to their network interfaces.
+
+hourglass model
+
+An architectural model for layered systems—and specifically for the [protocol layers](#h.pe8dekl2dtq0) in a [protocol stack](#h.6ik2cef0ipsr)—in which a diversity of supporting protocols and services at the lower layers are able to support a great diversity of protocols and applications at the higher layers through the use of a single protocol in the [spanning layer](#h.wf49e15shob9) in the middle—the “neck” of the hourglass.
+
+See also: [trust spanning protocol](#h.fnuaao3a1j25).
+
+For more information, see: [https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf](https://www.google.com/url?q=https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf&sa=D&source=editors&ust=1718703186704312&usg=AOvVaw1rLPgu0c2r-q6-RWGwgQ6i) and [https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/abstract](https://www.google.com/url?q=https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/abstract&sa=D&source=editors&ust=1718703186704488&usg=AOvVaw29G-gqCzyU4nwKRKT6_prd) 
+
+Note: The Internet’s [TCP/IP stack](#h.txn6vkany9z9) follows the hourglass model, and it is the design model for the [ToIP stack](#h.wms58fgdch9m).
+
+HSM
+
+See: [hardware security module](#h.vs7ugzdzujtz).
+
+human auditability
+
+See: [human auditable](#h.22bo41j3q290).
+
+Contrast with: [cryptographic verifiability](#h.lbqfpvfmcmoq).
+
+human auditable
+
+A process or procedure whose [compliance](#h.r0iiayz1za1i) with the [policies](#h.udts41hso4w4) in a [trust framework](#h.2r5mn949idq) or [governance framework](#h.2x05z0r097mn) can only be [verified](#h.k2qmzn3tjzsl) by a human performing an [audit](#h.3gz7xw796mvp). Human auditability is a primary goal of the [ToIP Governance Stack](#h.ciwa0pidrb2e).
+
+Contrast with: [cryptographically verifiable](#h.422iwwfur12).
+
+human experience
+
+The processes, patterns and rituals of acquiring [knowledge](#h.k96lktyswxnb) or skill from doing, seeing, or feeling things as a [natural person.](#h.yx4qb6dcjdvj) In the context of decentralized digital trust infrastructure, the direct experience of a [natural person](#h.yx4qb6dcjdvj) using [trust applications](#h.3pfn27y1gu2o) to make [trust decisions](#h.m8c86ccqis9r) within one or more [digital trust ecosystems](#h.h47f86smlz4y).
+
+Note: Human experience includes social experiences (e.g., rituals, behaviors, ceremonies and rites of passage), as well as customer experience, worker or employee experience, and user experience.
+
+human-readable
+
+Information that can be processed by a human but that is not intended to be [machine-readable](#h.8s3s84fzcfi3).
+
+human trust
+
+A [level of assurance](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.qseghs6dqcd&sa=D&source=editors&ust=1718703186706977&usg=AOvVaw01wRN6cKieimrFCcIh8gAy) in a [trust relationship](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.pu2asd79bqzo&sa=D&source=editors&ust=1718703186707327&usg=AOvVaw3J-DXT0-JWLTjc8nWcLUkM) that can be achieved only via human evaluation of applicable [trust](#h.sdrgtm7bwb51) factors.
+
+Contrast with: [technical](#h.7vxscxecc0g) [trust](#h.7vxscxecc0g).
+
+IAL
+
+See: [identity assurance level](#h.udr0qmo2ubln).
+
+identification
+
+The [action](#h.l54nzmooy631) of a [party](#h.cn6bno48fomj) obtaining the set of [identity data](#h.t3ho4tago38u) necessary to serve as that [party’s](#h.cn6bno48fomj) [identity](#h.z1gairv0pej5) for a specific [entity](#h.5imtbzl1f4xo).
+
+Note: The act of identification of a specific [entity](#h.5imtbzl1f4xo) is relational to each [party](#h.cn6bno48fomj) that needs to perform that action. Therefore each party may end up with their own set of [identity data](#h.t3ho4tago38u) that meets their specific [requirements](#h.ajxlw8r3dvcc) for their specific [scope](#h.5cfb6xokygh4).
+
+identifier
+
+A single [attribute](#h.ky5nh3yri7ak)—typically a character string—that uniquely identifies an [entity](#h.5imtbzl1f4xo) within a specific context (which may be a global context). Examples include the name of a [party,](#h.cn6bno48fomj) the URL of an [organization](#h.z27mp1358pi9), or a serial number for a [man-made thing](#h.98jmqz1068vj).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23identifier&sa=D&source=editors&ust=1718703186708955&usg=AOvVaw1q1icZ0GOaGmcY87McCq5F): a character string that is being used for the identification of some [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186709188&usg=AOvVaw3EkN-jN5soZH6OtSH3iOtc) (yet may refer to 0, 1, or more [entities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186709395&usg=AOvVaw0e1ol5KrbHXw_0I8f4IB0-), depending on the context within which it is being used).
+
+identity
+
+A collection of [attributes](#h.ky5nh3yri7ak) or other [identity data](#h.t3ho4tago38u) that describe an [entity](#h.5imtbzl1f4xo) and enable it to be distinguished from all other [entities](#h.5imtbzl1f4xo) within a specific [scope](#h.5cfb6xokygh4) of [identification](#h.fslz9gxdlb84). Identity attributes may include one or more [identifiers](#h.u3bfehmj4ed3) for an [entity](#h.5imtbzl1f4xo), however it is possible to establish an identity without using [identifiers](#h.u3bfehmj4ed3).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23identity&sa=D&source=editors&ust=1718703186710132&usg=AOvVaw0H5ENOWIImaCNw8HDPAbRy): the combined [knowledge](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/knowledge&sa=D&source=editors&ust=1718703186710329&usg=AOvVaw1-XYPGzz_bPPB6ME7YkE6L) about that [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186710477&usg=AOvVaw1-J5cmK82VByApdvfSibqf) of all [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186710626&usg=AOvVaw10-MGxjt_0ovgcoYbfxAsZ), i.e. the union of all [partial identities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/partial-identity&sa=D&source=editors&ust=1718703186710781&usg=AOvVaw1b_BUEZz6Am9OOMqepKEK4) of which that [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186710930&usg=AOvVaw3ZE8wkmfvuNgGcMJpVoW9-) is the [subject](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/subject&sa=D&source=editors&ust=1718703186711086&usg=AOvVaw0BmaiJx2PPtx8sI8AFM1Ti).
+
+Note: Identity is relational to the [party](#h.cn6bno48fomj) performing the identification. For example, if 100 different [parties](#h.cn6bno48fomj) have an identity for the same [entity](#h.5imtbzl1f4xo), each of them may hold a different set of [identity data](#h.t3ho4tago38u) enabling identification of that [entity](#h.5imtbzl1f4xo).
+
+identity assurance level
+
+A category that conveys the degree of confidence that a person’s claimed [identity](#h.z1gairv0pej5) is their real [identity](#h.z1gairv0pej5), for example as defined in [NIST SP 800-63-3](https://www.google.com/url?q=https://pages.nist.gov/800-63-3/sp800-63-3.html&sa=D&source=editors&ust=1718703186711847&usg=AOvVaw22RQ2oq0cKO0BNkz5oXjOF) in terms of three levels: IAL 1 (Some confidence), IAL 2 (High confidence), IAL 3 (Very high confidence).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/identity_assurance_level&sa=D&source=editors&ust=1718703186712148&usg=AOvVaw1FHhgJfsv2Gym7v2nZUFHe).
+
+See also: [authenticator assurance level](#h.a7560ebfrt4m), [federation assurance level](#h.8fhj7rpnpjy3).
+
+identity binding
+
+The process of associating a set of [identity data](#h.t3ho4tago38u), such as a [credential](#h.kcj6iw2vib1v), with its [subject](#h.voca6uuv1a4), such as a [natural person](#h.yx4qb6dcjdvj). The strength of an identity binding is one factor in determining an [authenticator assurance level](#h.a7560ebfrt4m).
+
+See also: [identity assurance level](#h.udr0qmo2ubln), [identity proofing](#h.8o667cv8194w).
+
+identity data
+
+The set of [data](#h.o783ayrrkc6g) held by a [party](#h.cn6bno48fomj) in order to provide an [identity](#h.z1gairv0pej5) for a specific [entity](#h.5imtbzl1f4xo).
+
+identity document
+
+A physical or digital document containing [identity data](#h.t3ho4tago38u). A [credential](#h.kcj6iw2vib1v) is a specialized form of identity document. Birth certificates, bank statements, and utility bills can all be considered identity documents.
+
+identity proofing
+
+The process of a [party](#h.cn6bno48fomj) gathering sufficient [identity data](#h.t3ho4tago38u) to establish an [identity](#h.z1gairv0pej5) for a particular [subject](#h.voca6uuv1a4) at a particular [identity assurance level](#h.udr0qmo2ubln).
+
+See also: [identity binding](#h.kwudvu8h2zex).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/identity_proofing&sa=D&source=editors&ust=1718703186714697&usg=AOvVaw3hYVBEnFJimCcDBNUyG7vi): The process of providing sufficient information (e.g., identity history, credentials, documents) to establish an identity.
+
+identity provider
+
+An identity provider (abbreviated IdP or IDP) is a system [entity](#h.5imtbzl1f4xo) that creates, maintains, and manages [identity](#h.z1gairv0pej5) information for [principals](#h.sydbe7rk6244) and also provides [authentication](#h.gp553sxzbmv1) services to relying applications within a [federation](#h.7ph0icfh463b) or distributed network.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Identity_provider&sa=D&source=editors&ust=1718703186715254&usg=AOvVaw29kbcz0D5tUAJLC4M8slQm).
+
+Note: The term “identity provider” is used in [federated identity](#h.cb1le64hx6h5) systems because it is a required component of their architecture. By contrast, [decentralized identity](#h.xodo7ytn4cx2) and [self-sovereign identity](#h.wdojy63bltd4) systems do not use the term because they are architected to enable [entities](#h.5imtbzl1f4xo) to create and control their own [digital identities](#h.r5y8zwxvzyd3) without the need to depend on an external provider.
+
+IDP
+
+See: [identity provider](#h.m9zmriuoidyt).
+
+impersonation
+
+In the context of cybersecurity, impersonation is when an attacker pretends to be another person in order to commit fraud or some other digital crime.
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Impersonator&sa=D&source=editors&ust=1718703186716010&usg=AOvVaw36rFjuuiZYvKFPPmMc2xyR): An impersonator is someone who imitates or copies the behavior or actions of another. As part of a [criminal act](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Crime&sa=D&source=editors&ust=1718703186716158&usg=AOvVaw2SHh7LeBDlV6AvWOmNkgRT) such as [identity theft](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Identity_theft&sa=D&source=editors&ust=1718703186716303&usg=AOvVaw045WR2A1JHRT5pkoXEEUl8), the criminal is trying to assume the identity of another, in order to commit [fraud](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Fraud&sa=D&source=editors&ust=1718703186716455&usg=AOvVaw12AHcSoiwoR7qp9H-HTvuy), such as accessing confidential information, or to gain property not belonging to them. Also known as [social engineering](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Social_engineering_\(security\)&sa=D&source=editors&ust=1718703186716662&usg=AOvVaw3JMRy0z8BslQ-4YVbB9saw) and [impostors](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Impostor&sa=D&source=editors&ust=1718703186716831&usg=AOvVaw0gh729IrOV-BPW4yMHeH91).
+
+integrity (of a data structure)
+
+In IT security, data integrity means maintaining and assuring the accuracy and completeness of [data](#h.o783ayrrkc6g) over its entire lifecycle. This means that [data](#h.o783ayrrkc6g) cannot be modified in an [unauthorized](#h.576ssfpt348i) or undetected manner.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Information_security%23Integrity&sa=D&source=editors&ust=1718703186717432&usg=AOvVaw0V3dDyUSdSxv6cE2UuP9YG).
+
+intermediary system
+
+A system that operates at [ToIP Layer 2](#h.ikqr9hyt133k), the [trust spanning layer](#h.k9uiol17u620) of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186717875&usg=AOvVaw08jEHtvtRXJ_fFRlrb4Vch), in order to route [ToIP messages](#h.5th2gmjr7ij) between [endpoint systems](#h.scy14dobg777). A supporting system is one of three types of systems defined in the [ToIP Technology Architecture Specification](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.bjv9ltwjbiqm&sa=D&source=editors&ust=1718703186718192&usg=AOvVaw0wXAJ3-one5-nACCfOvHhO).
+
+See also: [endpoint system](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.scy14dobg777&sa=D&source=editors&ust=1718703186718484&usg=AOvVaw059YKQRWKkM-_kGdQh9aOg), [supporting system](#h.nqtdtghyfspz).
+
+Internet Protocol
+
+The Internet Protocol (IP) is the network layer [communications](#h.w02a6srdng3j) protocol in the Internet protocol suite (also known as the [TCP/IP](#h.txn6vkany9z9) suite) for relaying [datagrams](#h.mxq90rincwo) across network boundaries. Its [routing](#h.tbxetxt0mdlp) function enables internetworking, and essentially establishes the Internet.
+
+IP has the task of delivering [packets](#h.9hc1adgu2nrx) from the source host to the destination host solely based on the [IP addresses](#h.a8c3q7adyz7c) in the packet headers. For this purpose, IP defines [packet](#h.9hc1adgu2nrx) structures that encapsulate the data to be delivered. It also defines addressing methods that are used to label the datagram with source and destination information.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_Protocol&sa=D&source=editors&ust=1718703186719640&usg=AOvVaw1rUWR-HemJ5T6gJxQ7C8o5).
+
+Also known as: [IP](#h.oh0hm0ivunoz).
+
+See also: Transmission Control Protocol, User Datagram Protocol.
+
+Internet protocol suite
+
+The Internet protocol suite, commonly known as [TCP/IP](#h.txn6vkany9z9), is a framework for organizing the set of [communication](#h.w02a6srdng3j) protocols used in the Internet and similar computer networks according to functional criteria. The foundational protocols in the suite are the [Transmission Control Protocol](#h.4wb0yz8sizvi) (TCP), the User Datagram Protocol (UDP), and the [Internet Protocol](#h.jmao5ngtvqnm) (IP).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet_protocol_suite&sa=D&source=editors&ust=1718703186720328&usg=AOvVaw3IYTGCRVfB9FiJEu52X6xQ)
+
+Also known as: [TCP/IP](#h.txn6vkany9z9).
+
+See also: [protocol stack](#h.6ik2cef0ipsr).
+
+IP
+
+See: [Internet Protocol](#h.jmao5ngtvqnm).
+
+IP address
+
+An [Internet Protocol](#h.jmao5ngtvqnm) 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](#h.jmao5ngtvqnm) for [communication](#h.w02a6srdng3j). An IP address serves two main functions: network interface [identification](#h.fslz9gxdlb84), and location [addressing](#h.tv1389o42vzp).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/IP_address&sa=D&source=editors&ust=1718703186721471&usg=AOvVaw1HTCqf8CSWF6Lh599Dr3e5).
+
+issuance
+
+The [action](#h.l54nzmooy631) of an [issuer](#h.xyrplzbvtffq) producing and transmitting a [digital credential](#h.ddna9lucn4k6) to a [holder](#h.64mptmm24w7u). A [holder](#h.64mptmm24w7u) may request issuance by submitting an [issuance request](#h.tt253lgfp4hz).
+
+See also: [presentation](#h.h5d1xfsxbbr0), [revocation](#h.ilt4dj4huwza).
+
+issuance request
+
+A protocol request invoked by the [holder](#h.64mptmm24w7u) of a [digital wallet](#h.sxnvf3f5v156) to obtain a [digital credential](#h.ddna9lucn4k6) from an [issuer](#h.xyrplzbvtffq).
+
+See also: [presentation request](#h.onnn49cjzreh).
+
+issuer (of a claim or credential)
+
+A [role](#h.sf54cyuamo6x) an [agent](#h.6xkhfkjpo6xg) performs to package and [digitally sign](#h.s93np0i5rcne) a set of [claims](#h.akieli6njkk5), typically in the form of a [digital credential](#h.ddna9lucn4k6), and transmit them to a [holder](#h.64mptmm24w7u).
+
+See also: [verifier](#h.xfewd7t01hu0), [holder](#h.64mptmm24w7u).
+
+Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186723213&usg=AOvVaw0_AGwri4srsp2cEQpDWp_H)
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23issuer&sa=D&source=editors&ust=1718703186723485&usg=AOvVaw2d5GevHFNc1NqGpQUuyhi5): a component that implements the [capability](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/capability&sa=D&source=editors&ust=1718703186723660&usg=AOvVaw36xi0UzmcGBFdxxLnEetmI) to construct [credentials](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186723855&usg=AOvVaw2AEP8x0PmwP2UZ_5DG655e) from data objects, according to the content of its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186724029&usg=AOvVaw2qBLXUcsdIBU3llXBN3U9M)'s [issuer](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/issuer&sa=D&source=editors&ust=1718703186724184&usg=AOvVaw1DczPHb6yigSR3oGD83UwT)\-Policy (specifically regarding the way in which the [credential](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186724356&usg=AOvVaw2q1W1MOpikVAYlsSkxEYhD) is to be digitally signed), and pass it to the [wallet](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/wallet&sa=D&source=editors&ust=1718703186724522&usg=AOvVaw00xrIw65dqouvjxVT-p0pa)\-component of its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186724676&usg=AOvVaw2GMpcomki3Iu_E_WuEPg85) allowing it to be issued.
+
+[W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186724878&usg=AOvVaw3FqBy5R09jGmSC-6Xh7tQi): A role an [entity](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-entities&sa=D&source=editors&ust=1718703186725033&usg=AOvVaw2NOSPMHqR8d4F84lJ-LOht) can perform by asserting [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186725190&usg=AOvVaw1a5q-fwDYznCZbxu_jcNJi) about one or more [subjects](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-subjects&sa=D&source=editors&ust=1718703186725335&usg=AOvVaw0jpsFDBhwn0UuuHwlVxYHg), creating a [verifiable credential](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186725500&usg=AOvVaw32UZO7oT58-l_Peacm-Twc) from these [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186725680&usg=AOvVaw1X1X_Xrq8oe0p099tW1wYi), and transmitting the [verifiable credential](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186725824&usg=AOvVaw3O1MrBYho_wa1qKvTsYcLm) to a [holder](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-holders&sa=D&source=editors&ust=1718703186725960&usg=AOvVaw1zuRGtoteHbNNcU3FKjN2E).
+
+jurisdiction
+
+The composition of: a) a [legal system](#h.5eaw7wimeo81) (legislation, enforcement thereof, and conflict resolution), b) a [party](#h.cn6bno48fomj) that governs that [legal system](#h.5eaw7wimeo81), c) a scope within which that [legal system](#h.5eaw7wimeo81) is operational, and d) one or more [objectives](#h.k0v6ir8wmcav) for the purpose of which the [legal system](#h.5eaw7wimeo81) is operated.
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23jurisdiction&sa=D&source=editors&ust=1718703186726633&usg=AOvVaw20ccpxEG7k1cvzSbbxtOzE)
+
+Mental model: [eSSIF-Lab Jurisdictions](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/pattern-jurisdiction&sa=D&source=editors&ust=1718703186726910&usg=AOvVaw0y4Pnl1q7C1AkhNqbtSUw9)
+
+KATE
+
+See: [keys-at-the-edge](#h.41san6iwsd69).
+
+KERI
+
+See: [Key Event Receipt Infrastructure](#h.nivehnhovlik).
+
+key
+
+See: [cryptographic key](#h.53rzpn1yn6q7).
+
+key establishment
+
+A process that results in the sharing of a key between two or more entities, either by transporting a key from one entity to another (key transport) or generating a key from information shared by the entities (key agreement).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/key_establishment&sa=D&source=editors&ust=1718703186727884&usg=AOvVaw1M3z4HwWHMAHboWXgOrMxY).
+
+key event
+
+An event in the history of the usage of a [cryptographic key pair](#h.53rzpn1yn6q7). There are multiple types of key events. The inception event is when the key pair is first generated. A rotation event is when the key pair is changed to a new key pair. In some [key management systems](#h.q0w3jq78va39) (such as [KERI](#h.7pp65h7qs9lu)), key events are tracked in a [key event log](#h.6jhhyjh47h).
+
+key event log
+
+An ordered sequence of [records](#h.y4ybzkfe6yzv) of [key events](#h.w6skxxfqgbqp).
+
+Note: Key event logs are a fundamental data structure in [KERI](#h.7pp65h7qs9lu).
+
+Key Event Receipt Infrastructure
+
+A decentralized permissionless [key management](#h.q0w3jq78va39) architecture.
+
+Also known as: KERI.
+
+For more information, see: [https://keri.one/](https://www.google.com/url?q=https://keri.one/&sa=D&source=editors&ust=1718703186729075&usg=AOvVaw3GffNWuLlxTAgiMSkgFO5O), [ToIP ACDC Task Force](https://www.google.com/url?q=https://wiki.trustoverip.org/display/HOME/ACDC%2B%2528Authentic%2BChained%2BData%2BContainer%2529%2BTask%2BForce&sa=D&source=editors&ust=1718703186729294&usg=AOvVaw1G8CAvkNEHsjMuK_JkyAb4)
+
+key management system
+
+A system for the management of [cryptographic keys](#h.53rzpn1yn6q7) and their [metadata](#h.t63bf0ssndfd) (e.g., generation, distribution, storage, backup, archive, recovery, use, [revocation](#h.ilt4dj4huwza), and destruction). An automated key management system may be used to oversee, automate, and secure the key management process. A key management is often protected by implementing it within the [trusted execution environment](#h.rsly6bxjqeg5) (TEE) of a device. An example is the [Secure Enclave](#h.lf0txjgjs67z) on Apple iOS devices.
+
+Also known as: [KMS](#h.wcbd8vhwq6z1).
+
+Source: [NIST-CRSC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/key_management_system&sa=D&source=editors&ust=1718703186730303&usg=AOvVaw3xcm-_c9qKTN_Fuf3cbNfz).
+
+keys-at-the-edge
+
+A [key management](#h.q0w3jq78va39) architecture in which [keys](#h.bk8tq6m7ylyl) are stored on a user’s local edge devices, such as a smartphone, tablet, or laptop, and then used in conjunction with a secure protocol to unlock a [key management system](#h.q0w3jq78va39) (KMS) and/or a [digital vault](#h.cz29glapo2tg) in the cloud. This approach can enable the storage and sharing of large [data](#h.o783ayrrkc6g) structures that are not feasible on edge devices. This architecture can also be used in conjunction with [confidential computing](#h.w12e1nuzy65z) to enable cloud-based [digital agents](#h.z3ugzt4hgdf6) to safely carry out “user not present” operations.
+
+Also known as: [KATE](#h.m06ht5n5sabj).
+
+KMS
+
+See: [key management system](#h.q0w3jq78va39).
+
+knowledge
+
+The (intangible) sum of what is known by a specific [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186731755&usg=AOvVaw1AnZwxcHhjcBeT4jp9Xh1t), as well as the familiarity, awareness or understanding of someone or something by that [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186731935&usg=AOvVaw0NeyacND9fzb62lst7gsqO).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23knowledge&sa=D&source=editors&ust=1718703186732141&usg=AOvVaw3dJ0C-ca2HXlyi-X1v10Jt).
+
+Laws of Identity
+
+A set of seven “laws” written by Kim Cameron, former Chief Identity Architect of Microsoft (1941-2021), to describe the dynamics that cause digital identity systems to succeed or fail in various contexts. His goal was to define the requirements for a unifying identity metasystem that can offer the Internet the identity layer it needs.
+
+For more information, see: [https://www.identityblog.com/?p=352](https://www.google.com/url?q=https://www.identityblog.com/?p%3D352&sa=D&source=editors&ust=1718703186732501&usg=AOvVaw0DVEsYxisLWEVheHw5sabs).
+
+Layer 1
+
+See: [ToIP Layer 1](#h.24ggrl8oz4ma).
+
+Layer 2
+
+See: [ToIP Layer 2](#h.ikqr9hyt133k).
+
+Layer 3
+
+See: [ToIP Layer 3](#h.7rbvlbpp8vwp).
+
+Layer 4
+
+See: [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+legal entity
+
+An [entity](#h.5imtbzl1f4xo) that is not a [natural person](#h.yx4qb6dcjdvj) but is recognized as having legal rights and responsibilities. Examples include corporations, partnerships, sole proprietorships, non-profit [organizations](#h.z27mp1358pi9), associations, and governments. (In some cases even natural systems such as rivers are treated as legal entities.)
+
+See also: [Legal Entity Identifier](#h.tvqq4mlccuun), [legal person](#h.a2q7i8my0jte), [organization](#h.z27mp1358pi9).
+
+Legal Entity Identifier
+
+The Legal Entity Identifier (LEI) is a unique global [identifier](#h.u3bfehmj4ed3) for [legal entities](#h.5328bxxk02sb) participating in financial transactions. Also known as an LEI code or LEI number, its purpose is to help identify [legal entities](#h.5328bxxk02sb) on a globally accessible database. Legal entities are [organisations](#h.z27mp1358pi9) such as companies or government entities that participate in financial transactions.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_Entity_Identifier&sa=D&source=editors&ust=1718703186734167&usg=AOvVaw2QxgRRsZGaVhWp1teZkTMi).
+
+Note: LEIs are administered by the [Global Legal Entity Identifier Foundation](https://www.google.com/url?q=https://www.gleif.org/&sa=D&source=editors&ust=1718703186734406&usg=AOvVaw1dP6cd-BmZVaU1RbNIbCIC) (GLEIF).
+
+legal identity
+
+A set of [identity data](#h.t3ho4tago38u) considered [authoritative](#h.9tt1qpgdfnxs) to identify a [party](#h.cn6bno48fomj) for purposes of legal accountability under one or more [jurisdictions](#h.uw2s3y6sjzjf).
+
+See also: [foundational identity](#h.ig62zx2lc56o), [functional identity](#h.tk5si1lqyz9q).
+
+legal person
+
+In law, a legal person is any person or 'thing' that can do the things a human person is usually able to do in law – such as enter into contracts, sue and be sued, own property, and so on.[\[3\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_person%23cite_note-3&sa=D&source=editors&ust=1718703186735422&usg=AOvVaw3cBimnI41SjF3nkzhqx_U2)[\[4\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_person%23cite_note-oxdic-4&sa=D&source=editors&ust=1718703186735610&usg=AOvVaw33CWh1pmoT1yFZzFW14wLP)[\[5\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_person%23cite_note-5&sa=D&source=editors&ust=1718703186735776&usg=AOvVaw1oCSXIjM-0M8EgmCGRmD98) The reason for the term "legal person" is that some legal persons are not people: companies and corporations are "persons" legally speaking (they can legally do most of the things an ordinary person can do), but they are not people in a literal sense (human beings).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Legal_person&sa=D&source=editors&ust=1718703186736152&usg=AOvVaw3STdUCmJ8ai9y3DjRQBTgW).
+
+Contrast with: [natural person](#h.yx4qb6dcjdvj).
+
+See also: [legal entity](#h.5328bxxk02sb), [organization](#h.z27mp1358pi9).
+
+legal system
+
+A system in which [policies](#h.udts41hso4w4) and [rules](#h.v7s575ulon74) are defined, and mechanisms for their enforcement and conflict resolution are (implicitly or explicitly) specified. Legal systems are not just defined by governments; they can also be defined by a [governance framework](#h.2x05z0r097mn).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23legal-system&sa=D&source=editors&ust=1718703186736926&usg=AOvVaw1FHzk-9IbKoVXaaXd5jbjC)
+
+LEI
+
+See: [Legal Entity Identifier](#h.tvqq4mlccuun).
+
+level of assurance
+
+See: [assurance level](#h.hsktvoq15zz7).
+
+liveness detection
+
+Any technique used to detect a [presentation attack](#h.p0f7ugeoyf0l) by determining whether the source of a biometric sample is a live human being or a fake representation. This is typically accomplished using algorithms that analyze biometric sensor data to detect whether the source is live or reproduced.
+
+Also known as: [proof of presence](#h.gmumid2hix8v).
+
+locus of control
+
+The set of computing systems under a [party’s](#h.cn6bno48fomj) direct control, where [messages](#h.bge7ubygwk2q) and [data](#h.o783ayrrkc6g) do not cross [trust boundaries](#h.91w031j2r3g).
+
+machine-readable
+
+Information written in a computer language or [expression language](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.21tvck8eyp4o&sa=D&source=editors&ust=1718703186738297&usg=AOvVaw1iBCnU_GvKujE41pmpSVfh) so that it can be read and processed by a computing device.
+
+Contrast with: [human-readable](#h.ywyofmy4do4t).
+
+man-made thing
+
+A [thing](#h.yyvwb9txkdzw) generated by human activity of some kind. Man-made things include both active things, such as cars or drones, and passive things, such as chairs or trousers.
+
+Source: [Sovrin Foundation Glossary V3](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit&sa=D&source=editors&ust=1718703186738805&usg=AOvVaw14RTMIusm1lzBmHKskUEEu)
+
+Contrast with: [natural thing](#h.njbtirxy3jvo).
+
+Note: Active things are the equivalent of non-human [actors](#h.gzdfngxkp0ip) in the eSSIF-Lab mental model [Parties, Actors, Actions](https://www.google.com/url?q=https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-party-actor-action&sa=D&source=editors&ust=1718703186739151&usg=AOvVaw3fLuXbYNrTYSOjmibUVKi7). Also see [Appendix B](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit%23heading%3Dh.mq7pzglc1j96&sa=D&source=editors&ust=1718703186739338&usg=AOvVaw0wFv48EqS-oJH-WpaKss8y) and [Appendix C](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit%23heading%3Dh.uiq9py7xnmxd&sa=D&source=editors&ust=1718703186739518&usg=AOvVaw3F9A6bwsvh88cmf2mL9kNg) of the Sovrin Glossary.
+
+mandatory
+
+A [requirement](#h.ajxlw8r3dvcc) that must be implemented in order for an implementer to be in [compliance](#h.r0iiayz1za1i). In [ToIP governance frameworks](#h.ns22ebn9xjun), a mandatory [requirement](#h.ajxlw8r3dvcc) is expressed using a MUST or REQUIRED keyword as defined in IETF RFC 2119.
+
+See also: [recommended](#h.db3a5yf4o7iu), [optional](#h.9411lfbb9qf2).
+
+For more information, see: [https://www.rfc-editor.org/rfc/rfc2119](https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc2119&sa=D&source=editors&ust=1718703186740197&usg=AOvVaw19Ap9K04kbJH6xriGWVIDW).
+
+metadata
+
+Information describing the characteristics of [data](#h.o783ayrrkc6g) including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/metadata&sa=D&source=editors&ust=1718703186740622&usg=AOvVaw3S1oP4ihYOTYxTIgpZDrhb).
+
+See also: [communication metadata](#h.jvfwgs8vd2rd).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Metadata&sa=D&source=editors&ust=1718703186740976&usg=AOvVaw36T1iVJ4CoFTPYV7Z8z1Oz): Metadata (or metainformation) is "[data](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Data&sa=D&source=editors&ust=1718703186741117&usg=AOvVaw1-IPo8AtiOTn1fWmif1p3c) that provides information about other data", but not the content of the data itself, such as the text of a message or the image itself.
+
+message
+
+A discrete unit of [communication](#h.w02a6srdng3j) intended by the source for consumption by some recipient or group of recipients.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Message&sa=D&source=editors&ust=1718703186741650&usg=AOvVaw3lD9WqlDsU0rLcatxD3nyW).
+
+See also: [ToIP message](#h.5th2gmjr7ij), [verifiable message](#h.7zrsx7mki2fr).
+
+mobile deep link
+
+In the context of mobile apps, [deep linking](#h.ubxk9l39j7w) consists of using a uniform resource identifier (URI) that links to a specific location within a mobile app rather than simply launching the app. Deferred deep linking allows users to deep link to content even if the app is not already installed. Depending on the mobile device platform, the URI required to trigger the app may be different.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mobile_deep_linking&sa=D&source=editors&ust=1718703186742397&usg=AOvVaw31qqHEvEU8AKTyPSU4b9Pa).
+
+MPC
+
+See: [multi-party computation](#h.2x62jfcai7ch).
+
+multicast
+
+In computer networking, multicast is group [communication](#h.w02a6srdng3j) where [data](#h.o783ayrrkc6g) transmission is addressed (using a [multicast address](#h.obmynoe7gkec)) to a group of destination computers simultaneously. Multicast can be one-to-many or many-to-many distribution. Multicast should not be confused with physical layer point-to-multipoint communication.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Multicast&sa=D&source=editors&ust=1718703186743391&usg=AOvVaw018ZPAcDxaSMp56nz9OhE2).
+
+See also: [anycast](#h.adr8osyk2zcx), [broadcast](#h.s1uti8f9ufsv), [unicast](#h.bqegn99wxkdi).
+
+multicast address
+
+A multicast address is a logical [identifier](#h.u3bfehmj4ed3) for a group of [hosts](#h.3f5tvermqc9k) in a computer network that are available to process [datagrams](#h.mxq90rincwo) or frames intended to be [multicast](#h.nopxfdr8qtr6) for a designated network service.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Multicast_address&sa=D&source=editors&ust=1718703186744309&usg=AOvVaw2-Ny7K8_VsPNypQZI6fEEq).
+
+See also: [broadcast address](#h.7gok5zmnh6an), unicast address.
+
+multi-party computation
+
+Secure multi-party computation (also known as secure computation, multi-party computation (MPC) or privacy-preserving computation) is a subfield of cryptography with the goal of creating methods for [parties](#h.cn6bno48fomj) to jointly compute a function over their inputs while keeping those inputs private. Unlike traditional cryptographic tasks, where cryptography assures security and [integrity](#h.n34avr5qvr0j) of [communication](#h.w02a6srdng3j) or storage and the adversary is outside the system of participants (an eavesdropper on the sender and receiver), the cryptography in this model protects participants' privacy from each other.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Secure_multi-party_computation&sa=D&source=editors&ust=1718703186744947&usg=AOvVaw3gvXhGAIMLKHZepYux4V8f).
+
+Also known as: [MPC](#h.ck8vxbqkll6d), [secure multi-party computation](#h.w5uvxlcshb5o).
+
+multi-party control
+
+A variant of [multi-party computation](#h.2x62jfcai7ch) where multiple parties must act in concert to meet a control requirement without revealing each other’s data. All parties are privy to the output of the control, but no party learns anything about the others.
+
+multi-signature
+
+A cryptographic [signature](#h.s93np0i5rcne) scheme where the process of signing information (e.g., a transaction) is distributed among multiple [private keys](#h.74y9dvxzg24c).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/multi_signature&sa=D&source=editors&ust=1718703186745612&usg=AOvVaw0bWzufZjvgAg-XJk7DYXMr).
+
+natural person
+
+A person (in legal meaning, i.e., one who has its own legal personality) that is an individual human being, distinguished from the broader category of a [legal person](#h.a2q7i8my0jte), which may be a private (i.e., business entity or non-governmental [organization](#h.z27mp1358pi9)) or public (i.e., government) [organization](#h.z27mp1358pi9).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Natural_person&sa=D&source=editors&ust=1718703186746189&usg=AOvVaw1BIsXe85EnFKFojKKZ8HhV).
+
+See also: [legal entity](#h.5328bxxk02sb), [party](#h.cn6bno48fomj).
+
+Contrast with: [legal person](#h.a2q7i8my0jte)
+
+natural thing
+
+A [thing](#h.yyvwb9txkdzw) that exists in the natural world independently of humans. Although natural things may form part of a [man-made thing](https://www.google.com/url?q=https://trustoverip.github.io/hxwg/glossary.html%23man-made-thing&sa=D&source=editors&ust=1718703186746925&usg=AOvVaw2CM-vKIF0oZB5Y43OkFCz0), natural things are mutually exclusive with [man-made things](https://www.google.com/url?q=https://trustoverip.github.io/hxwg/glossary.html%23man-made-thing&sa=D&source=editors&ust=1718703186747151&usg=AOvVaw13pz3QfeWR-CUoVptpj5J0).
+
+Source: [Sovrin Foundation Glossary V3](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit&sa=D&source=editors&ust=1718703186747382&usg=AOvVaw0tcwPUCiCBoAoIzF1A6wmc).
+
+Contrast with: [man-made thing](#h.98jmqz1068vj).
+
+For more information see: [Appendix B](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit%23heading%3Dh.mq7pzglc1j96&sa=D&source=editors&ust=1718703186747764&usg=AOvVaw3st-pLsZulQxeiDFW3n55U) and [Appendix C](https://www.google.com/url?q=https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit%23heading%3Dh.uiq9py7xnmxd&sa=D&source=editors&ust=1718703186748011&usg=AOvVaw1Ik3KT0Jy-9EoqGMbS0HFw) of the Sovrin Glossary
+
+Note: Natural things (those recognized to have legal rights) can be [parties](#h.cn6bno48fomj) but never [actors](#h.gzdfngxkp0ip) in the eSSIF-Lab mental model [Parties, Actors, Actions](https://www.google.com/url?q=https://essif-lab.pages.grnet.gr/framework/docs/terms/pattern-party-actor-action&sa=D&source=editors&ust=1718703186748362&usg=AOvVaw1a8IRlaYd2U4XSaDW3ASYa).
+
+network address
+
+A network address is an [identifier](#h.u3bfehmj4ed3) for a [node](#h.w1aty8c036fp) or [host](#h.3f5tvermqc9k) on a telecommunications network. Network addresses are designed to be unique [identifiers](#h.u3bfehmj4ed3) across the network, although some networks allow for local, private addresses, or locally administered addresses that may not be unique. Special network addresses are allocated as [broadcast](#h.7gok5zmnh6an) or [multicast](#h.nopxfdr8qtr6) addresses. A network address designed to address a single device is called a [unicast address](#h.2p49ftuui3ug).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Network_address&sa=D&source=editors&ust=1718703186749243&usg=AOvVaw3E0sK96TT4lsgPwUpwJgBz).
+
+node
+
+In telecommunications networks, a node (Latin: nodus, ‘knot’) is either a redistribution point or a [communication endpoint](#h.qstkv072p5tx). The definition of a node depends on the network and [protocol layer](#h.pe8dekl2dtq0) referred to. A physical network node is an electronic device that is attached to a network, and is capable of creating, receiving, or transmitting information over a [communication channel](#h.oc2pelzel246).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Node_\(networking\)&sa=D&source=editors&ust=1718703186749847&usg=AOvVaw2_ovrIidQLWOrg_T64vO63).
+
+non-custodial wallet
+
+A [digital wallet](#h.sxnvf3f5v156) that is directly in the control of the [holder](#h.64mptmm24w7u), usually because the holder is the [device controller](#h.tf0m8u61wh87) of the device hosting the [digital wallet](#h.sxnvf3f5v156) (smartcard, smartphone, tablet, laptop, desktop, car, etc.) A [digital wallet](#h.sxnvf3f5v156) that is in the custody of a [third party](#h.zu2vj8151tr) is called a [custodial wallet](#h.5qanwm5930bp).
+
+objective
+
+Something toward which a [party](#h.cn6bno48fomj) (its [owner](#h.y450rpi0zmuu)) directs effort (an aim, goal, or end of [action](#h.l54nzmooy631)).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/objective&sa=D&source=editors&ust=1718703186750843&usg=AOvVaw2bFGtC12sbKk-auVXoAoDj).
+
+OOBI
+
+See: [out-of-band introduction](#h.tsslu4lnog0s).
+
+OpenWallet Foundation
+
+A non-profit project of the [Linux Foundation](https://www.google.com/url?q=https://www.linuxfoundation.org/&sa=D&source=editors&ust=1718703186751387&usg=AOvVaw15ETg-sNsLdDiJxWrdZv_L) chartered to build a world-class open source [wallet engine](#h.jsmi4264di2s).
+
+See also: [Decentralized Identity Foundation](#h.w2py1eklfcb), [ToIP Foundation](#h.500jynxuxkms).
+
+For more information, see: [https://openwallet.foundation/](https://www.google.com/url?q=https://openwallet.foundation/&sa=D&source=editors&ust=1718703186751885&usg=AOvVaw0NU5itzzXE_LYwmo0Y0zyG) 
+
+operational circumstances
+
+In the context of privacy protection, this term denotes the context in which privacy trade-off decisions are made. It includes the regulatory environment and other non-technical factors that bear on what reasonable privacy expectations might be.
+
+Source: [PEMC IGR](https://www.google.com/url?q=https://kantarainitiative.org/download/pemc-implementors-guidance-report/&sa=D&source=editors&ust=1718703186752237&usg=AOvVaw22dK8Lx5ed1XbWW5pKosm8)
+
+optional
+
+A [requirement](#h.ajxlw8r3dvcc) that is not [mandatory](#h.n3iynmuwwbf8) or [recommended](#h.db3a5yf4o7iu) to implement in order for an implementer to be in [compliance](#h.r0iiayz1za1i), but which is left to the implementer’s choice. In [ToIP governance frameworks](#h.ns22ebn9xjun), an optional [requirement](#h.ajxlw8r3dvcc) is expressed using a MAY or OPTIONAL keyword as defined in IETF RFC 2119.
+
+See also: [mandatory](#h.n3iynmuwwbf8), [recommended](#h.db3a5yf4o7iu).
+
+For more information, see: [https://www.rfc-editor.org/rfc/rfc2119](https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc2119&sa=D&source=editors&ust=1718703186753055&usg=AOvVaw1GhL5Xgf1E8Z2muS1c7JnU).
+
+organization
+
+A [party](#h.cn6bno48fomj) that consists of a group of [parties](#h.cn6bno48fomj) who agree to be organized into a specific form in order to better achieve a common set of [objectives](#h.k0v6ir8wmcav). Examples include corporations, partnerships, sole proprietorships, non-profit organizations, associations, and governments.
+
+See also: [legal entity](#h.5328bxxk02sb), [legal person](#h.a2q7i8my0jte).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23organization&sa=D&source=editors&ust=1718703186753771&usg=AOvVaw1rrk5I1LAI02hqJ_aBdOv2): a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186753960&usg=AOvVaw1gqvitpp9zsDL-FVRnucFg) that is capable of setting [objectives](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/objective&sa=D&source=editors&ust=1718703186754134&usg=AOvVaw023rei-ALvTQsWJRQYOmMb) and making sure these are realized by [actors](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186754352&usg=AOvVaw3nuKa3fd5e1k8CBOlFweY9) that it has [onboarded](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/onboarding&sa=D&source=editors&ust=1718703186754587&usg=AOvVaw3Va3rr5DFre0orcVhtIAfX) and/or by (vetted) [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186754822&usg=AOvVaw3Cpn0T5JeXlyI6s0FQsGBd) that are committed to contribute to these [objectives](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/objective&sa=D&source=editors&ust=1718703186754995&usg=AOvVaw1ZWAyfHjXLWlHuXewBie5o).
+
+organizational authority
+
+A type of [authority](#h.gln5i78kxlfh) where the [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186755369&usg=AOvVaw0ykDdPNJbVYpMaz2b0mPOm) asserting its right is an [organization](#h.z27mp1358pi9).
+
+out-of-band introduction
+
+A process by which two or more [entities](#h.5imtbzl1f4xo) exchange [VIDs](#h.qr5qljyd3se) in order to form a [cryptographically verifiable](#h.422iwwfur12) [connection](#h.thbpewq1px8x) (e.g., a [ToIP connection](#h.5i1yn2scvzvz)), such as by scanning a [QR code](#h.6qi3agm0afv3) (in person or remotely) or clicking a [deep link](#h.ubxk9l39j7w).
+
+Also known as: [OOBI](#h.1168y6n7c8w).
+
+owner (of an entity)
+
+The [role](#h.sf54cyuamo6x) that a [party](#h.cn6bno48fomj) performs when it is exercising its legal, rightful or natural title to control a specific [entity](#h.5imtbzl1f4xo).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23owner&sa=D&source=editors&ust=1718703186756640&usg=AOvVaw3Epr1YjPTgCUZ2BUDdSjZR).
+
+See also: [controller](#h.gemoqe2m303z).
+
+P2P
+
+See: [peer-to-peer](#h.ikjsqxobvozv).
+
+party
+
+An [entity](#h.5imtbzl1f4xo) that sets its [objectives](#h.k0v6ir8wmcav), maintains its [knowledge](#h.k96lktyswxnb), and uses that [knowledge](#h.k96lktyswxnb) to pursue its [objectives](#h.k0v6ir8wmcav) in an autonomous (sovereign) manner. Humans and [organizations](#h.z27mp1358pi9) are the typical examples.
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary&sa=D&source=editors&ust=1718703186757677&usg=AOvVaw0az_jqwASyCHdiLgYipcoU).
+
+See also: [first party](#h.uxx5bjam20ag), [second party](#h.hk94wskqnzri), [third party](#h.zu2vj8151tr), [natural person](#h.yx4qb6dcjdvj)
+
+password
+
+A string of characters (letters, numbers and other symbols) that are used to authenticate an identity, verify access authorization or derive cryptographic keys.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/password&sa=D&source=editors&ust=1718703186758265&usg=AOvVaw1FLPlPJtOGBkKOL0ts8pHn).
+
+See also: [complex password](#h.ydm2hpca9zws).
+
+peer
+
+In the context of digital networks, an [actor](#h.gzdfngxkp0ip) on the network that has the same status, privileges, and communications options as the other actors on the network.
+
+See also: [peer-to-peer](#h.ikjsqxobvozv).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23peer-actor&sa=D&source=editors&ust=1718703186758889&usg=AOvVaw2IVYxSDN3oh4I16qDCLbFH): the [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186759060&usg=AOvVaw10hS7yCa28ummRFI62kSfv) with whom/which this other [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186759268&usg=AOvVaw3Kw-uBRZTZMSoOB4usxjzs) is communicating in that [communication session](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/communication-session&sa=D&source=editors&ust=1718703186759436&usg=AOvVaw1FFxgptVJ8fyBaues7GhvJ).
+
+peer-to-peer
+
+Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or workloads between [peers](#h.269t7i1hwzp). [Peers](#h.269t7i1hwzp) are equally privileged, equipotent participants in the network. This forms a peer-to-peer network of [nodes](#h.w1aty8c036fp).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Peer-to-peer&sa=D&source=editors&ust=1718703186760063&usg=AOvVaw28vmmTkpYHqeObUEwFbzEM).
+
+permission
+
+[Authorization](#h.576ssfpt348i) to perform some [action](#h.l54nzmooy631) on a system.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/permission&sa=D&source=editors&ust=1718703186760459&usg=AOvVaw0kHZGG5-k--phXAXYxqqIw).
+
+persistent connection
+
+A [connection](#h.thbpewq1px8x) that is able to persist across multiple [communication sessions](#h.i82tgrmxy0d8). In a ToIP context, a persistent connection is established when two [ToIP endpoints](#h.e787fzjepk60) exchange [verifiable identifiers](#h.wyda231qefe) that they can use to re-establish the [connection](#h.thbpewq1px8x) with each other whenever it is needed.
+
+Contrast with: [ephemeral connection](#h.5xjtv29e8z6i).
+
+personal data
+
+Any information relating to an identified or identifiable [natural person](#h.yx4qb6dcjdvj) (called a [data subject](#h.3r9gd9iy7a6e) under [GDPR](#h.5oxryjdg8s9w)).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/personal_data&sa=D&source=editors&ust=1718703186761568&usg=AOvVaw3PIrDM3z5RqmvLZkliBpSh).
+
+personal data store
+
+See: [personal data vault](#h.9b2ram5w4omg).
+
+Note: In the market, the term “personal data store” has also been used to generally mean a combination of the functions of a personal [digital agent](#h.z3ugzt4hgdf6), [personal wallet](#h.1qe7g02c5t4p), and [personal data vault](#h.9b2ram5w4omg).
+
+personal data vault
+
+A [digital vault](#h.cz29glapo2tg) whose [controller](#h.gemoqe2m303z) is a [natural person](#h.yx4qb6dcjdvj).
+
+personal wallet
+
+A [digital wallet](#h.sxnvf3f5v156) whose [holder](#h.64mptmm24w7u) is a [natural person](#h.yx4qb6dcjdvj).
+
+Contrast with: [enterprise wallet](#h.lwbrzpnzaqth).
+
+personally identifiable information
+
+Information (any form of [data](#h.o783ayrrkc6g)) that can be used to directly or indirectly [identify](#h.z1gairv0pej5) or re-identify an individual person either singly or in combination within a single [record](#h.y4ybzkfe6yzv) or in correlation with other [records](#h.y4ybzkfe6yzv). This information can be one or more [attributes](#h.ky5nh3yri7ak)/fields/[properties](#h.c8vs1xa4uwn) in a [record](#h.y4ybzkfe6yzv) (e.g., date-of-birth) or one or more [records](#h.y4ybzkfe6yzv) (e.g., medical records).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/personally_identifiable_information&sa=D&source=editors&ust=1718703186763575&usg=AOvVaw3ExgKzkykN0bKp4ozv8zcV)
+
+Also known as: [PII](#h.pumw0ocr1xf2).
+
+See also: [personal data](#h.rpiib2ml3s9c), [sensitive data](#h.l8f0y0lobzpi).
+
+physical credential
+
+A [credential](#h.kcj6iw2vib1v) in a physical form such as paper, plastic, or metal.
+
+Contrast with: [digital credential](#h.ddna9lucn4k6).
+
+PII
+
+See: [personally identifiable information](#h.yww9djvhorxc).
+
+PKI
+
+See: [public key infrastructure](#h.mdxu5kpbdo4x).
+
+plaintext
+
+Unencrypted information that may be input to an [encryption](#h.iyq318f2vg61) operation. Once encrypted, it becomes [ciphertext](#h.9ripqbaz7egw).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/plaintext&sa=D&source=editors&ust=1718703186765040&usg=AOvVaw30yQYBDyMWv1OQjELWUPjN).
+
+policy
+
+Statements, rules or assertions that specify the correct or expected behavior of an entity. For example, an [authorization](#h.576ssfpt348i) policy might specify the correct [access control](#h.lmk4gqobt99b) rules for a software component. Policies may be [human-readable](#h.ywyofmy4do4t) or [machine-readable](#h.8s3s84fzcfi3) or both.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/policy&sa=D&source=editors&ust=1718703186765725&usg=AOvVaw16tYnYfJd365qHHc4BZuQ_)
+
+See also: [governance framework](#h.2x05z0r097mn), [governance requirement](#h.j4z5czk0dk8t), [rule](#h.v7s575ulon74).
+
+PoP
+
+See: [proof of personhood](#h.1686ws2z2rnl).
+
+presentation
+
+A [verifiable](#h.k2qmzn3tjzsl) [message](#h.bge7ubygwk2q) that a [holder](#h.64mptmm24w7u) may send to a [verifier](#h.xfewd7t01hu0) containing [proofs](#h.r2qw6757lopw) of one or more [claims](#h.akieli6njkk5) derived from one or more [digital credentials](#h.ddna9lucn4k6) from one or more [issuers](#h.xyrplzbvtffq) as a response to a specific [presentation request](#h.onnn49cjzreh) from a  [verifier](#h.xfewd7t01hu0).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/presentation&sa=D&source=editors&ust=1718703186766870&usg=AOvVaw1ATMkFlPhQVh8YjO9QxPNv): A (signed) digital [message](#h.bge7ubygwk2q) that a [holder](#h.64mptmm24w7u) component may send to a [verifier](#h.xfewd7t01hu0) component that contains [data](#h.o783ayrrkc6g) derived from one or more [verifiable credentials](#h.co5algna3zkh) (that (a [colleague](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/colleague&sa=D&source=editors&ust=1718703186767309&usg=AOvVaw2OrZX9ePtlyuBba1pXweeL) component of) the [holder](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/holder&sa=D&source=editors&ust=1718703186767532&usg=AOvVaw31z476nRraFxAe2sW7IGI9) component has received from [issuer](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/issuer&sa=D&source=editors&ust=1718703186767704&usg=AOvVaw3YtP_7nFgctoFUaVoFNNmm) components of one or more [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186767852&usg=AOvVaw1QMWXwl2j9ju3me8cIub9e)), as a response to a specific [presentation request](#h.onnn49cjzreh) of a  [verifier](#h.xfewd7t01hu0) component.
+
+presentation attack
+
+A type of cybersecurity attack in which the attacker attempts to defeat a [biometric](#h.grifxl8vyuuu) [liveness detection](#h.v2edf5qj0ig4) system by providing false inputs.
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/presentation_attack&sa=D&source=editors&ust=1718703186768505&usg=AOvVaw0Cqoyfk5N2_JvfeXLEO-M1): Presentation to the biometric data capture subsystem with the goal of interfering with the operation of the biometric system.
+
+presentation request
+
+A protocol request sent by the [verifier](#h.xfewd7t01hu0) to the [holder](#h.64mptmm24w7u) of a [digital wallet](#h.sxnvf3f5v156) to request a [presentation](#h.h5d1xfsxbbr0).
+
+See also: [issuance request](#h.tt253lgfp4hz).
+
+primary document
+
+The [governance document](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.c8fvvxachz5h&sa=D&source=editors&ust=1718703186769299&usg=AOvVaw0InhOrkcy7yq4yFNIL-ywn) at the root of a [governance framework](#h.2x05z0r097mn). The primary document specifies the other [controlled documents](#h.t0afqk7h7n97) in the governance framework.
+
+principal
+
+The [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186769680&usg=AOvVaw3KeJ0LqZgaP3DvhwhBeGcg) for whom, or on behalf of whom, an [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186769836&usg=AOvVaw2qJpot1jbco7WdRLNQ7pLi) is executing an [action](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/action&sa=D&source=editors&ust=1718703186769989&usg=AOvVaw1VG1y4-WDr30gQM0Rr2CDa) (this [actor](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/actor&sa=D&source=editors&ust=1718703186770160&usg=AOvVaw0NIPogQlJIuKyAbYSlnlJP) is then called an [agent](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/agent&sa=D&source=editors&ust=1718703186770324&usg=AOvVaw0hqtrxB8W4FDBzyyNoWn8Q) of that [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186770464&usg=AOvVaw2NUu6TFnYGdtRT_12oXous)).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23principal&sa=D&source=editors&ust=1718703186770753&usg=AOvVaw0F-q9_u-7KaugC43Tl2Oct)
+
+Principles of SSI
+
+A set of principles for [self-sovereign identity](#h.wdojy63bltd4) systems originally defined by the Sovrin Foundation and republished by the [ToIP Foundation](#h.500jynxuxkms).
+
+For more information, see: [https://sovrin.org/principles-of-ssi/](https://www.google.com/url?q=https://sovrin.org/principles-of-ssi/&sa=D&source=editors&ust=1718703186771205&usg=AOvVaw1XTS-F4SEcuTTCW-BO-FHQ) and [https://trustoverip.org/wp-content/uploads/2021/10/ToIP-Principles-of-SSI.pdf](https://www.google.com/url?q=https://trustoverip.org/wp-content/uploads/2021/10/ToIP-Principles-of-SSI.pdf&sa=D&source=editors&ust=1718703186771389&usg=AOvVaw08o_bhDpWOM0uyLg0GIuiC) 
+
+privacy policy
+
+A statement or legal document (in privacy law) that discloses some or all of the ways a [party](#h.cn6bno48fomj) gathers, uses, discloses, and manages a customer or client's [data.](#h.o783ayrrkc6g)
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Privacy_policy&sa=D&source=editors&ust=1718703186771822&usg=AOvVaw2jW9bYEkDKLYcJwURk0Kut)
+
+See also: [security policy](#h.2fcbwog0w43a).
+
+private key
+
+In [public key cryptography](#h.jhvr6rbo5z3q), the [cryptographic key](#h.53rzpn1yn6q7) which must be kept secret by the [controller](#h.gemoqe2m303z) in order to maintain security.
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/private_key&sa=D&source=editors&ust=1718703186772368&usg=AOvVaw2wRK0zcfNeRCvWM29wOBa_): The secret part of an asymmetric key pair that is typically used to digitally sign or decrypt data.
+
+proof
+
+A digital object that enables [cryptographic verification](#h.lbqfpvfmcmoq) of either: a) the [claims](#h.akieli6njkk5) from one or more [digital credentials](#h.ddna9lucn4k6), or b) facts about [claims](#h.akieli6njkk5) that do not reveal the [data](#h.o783ayrrkc6g)  itself (e.g., proof of the [subject](#h.voca6uuv1a4) being over/under a specific age without revealing a birthdate).
+
+See also: [zero-knowledge proof](#h.zc9pf8eexjs).
+
+proof of control
+
+See: [proof of possession](#h.s0sx91peii5f).
+
+proof of personhood
+
+Proof of personhood (PoP) is a means of resisting malicious attacks on [peer-to-peer](#h.ikjsqxobvozv) networks, particularly, attacks that utilize multiple fake [identities](#h.z1gairv0pej5), otherwise known as a [Sybil attack](#h.jkl5esndzhl8). Decentralized online platforms are particularly vulnerable to such attacks by their very nature, as notionally democratic and responsive to large voting blocks. In PoP, each unique human participant obtains one equal unit of voting power, and any associated rewards.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Proof_of_personhood&sa=D&source=editors&ust=1718703186773574&usg=AOvVaw3JM8VlhKlv1iSL8KDRl6yi).
+
+Also known as: [PoP](#h.3u71l1o5j9qt).
+
+proof of possession
+
+A [verification](#h.2bnb6g8na7cu) process whereby a [level of assurance](#h.qseghs6dqcd) is obtained that the owner of a [key pair](#h.53rzpn1yn6q7) actually controls the [private key](#h.74y9dvxzg24c) associated with the [public key](#h.hohpk6z1qk4f).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/proof_of_possession&sa=D&source=editors&ust=1718703186774136&usg=AOvVaw0LhLfZtFf3n1ZeFaEKTE-Q).
+
+proof of presence
+
+See: [liveness detection](#h.v2edf5qj0ig4).
+
+property
+
+In the context of digital communication, an [attribute](#h.ky5nh3yri7ak) of a digital object or [data](#h.o783ayrrkc6g) structure, such as a [DID document](#h.yjwocacp570p) or a [schema](#h.rwxa1n5inr2e).
+
+See also: [attribute](#h.ky5nh3yri7ak), [claim](#h.akieli6njkk5).
+
+protected data
+
+[Data](#h.o783ayrrkc6g) that is not publicly available but requires some type of [access control](#h.lmk4gqobt99b) to gain access.
+
+protocol layer
+
+In modern protocol design, protocols are layered to form a [protocol stack](#h.6ik2cef0ipsr). Layering is a design principle that divides the protocol design task into smaller steps, each of which accomplishes a specific part, interacting with the other parts of the protocol only in a small number of well-defined ways. Layering allows the parts of a protocol to be designed and tested without a combinatorial explosion of cases, keeping each design relatively simple.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Communication_protocol%23Layering&sa=D&source=editors&ust=1718703186775370&usg=AOvVaw0cou_2Dgnl_3E1r84FDzqn).
+
+See also: [hourglass model](#h.u8d1rxc2o86), [ToIP stack](#h.wms58fgdch9m).
+
+protocol stack
+
+The protocol stack or network stack is an implementation of a computer networking protocol suite or protocol family. Some of these terms are used interchangeably but strictly speaking, the suite is the definition of the communication protocols, and the stack is the software implementation of them.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Protocol_stack&sa=D&source=editors&ust=1718703186775979&usg=AOvVaw0Ujzwopa-O9rJ3JawUlAAa)
+
+See also: [protocol layer](#h.pe8dekl2dtq0).
+
+pseudonym
+
+A pseudonym is a fictitious name that a [person](#h.yx4qb6dcjdvj) assumes for a particular purpose, which differs from their original or true name (orthonym). This also differs from a new name that entirely or legally replaces an individual's own. Many pseudonym [holders](#h.64mptmm24w7u) use pseudonyms because they wish to remain [anonymous](#h.95pnj4tchl4m), but anonymity is difficult to achieve and often fraught with legal issues.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Pseudonym&sa=D&source=editors&ust=1718703186776556&usg=AOvVaw34RNN02hz32mjST2FnFx9c).
+
+public key
+
+[Drummond Reed](mailto:drummond.reed@avast.com): In [public key cryptography](#h.jhvr6rbo5z3q), the [cryptographic key](#h.53rzpn1yn6q7) that can be freely shared with anyone by the [controller](#h.gemoqe2m303z) without compromising security. A [party’s](#h.cn6bno48fomj) public key must be verified as [authoritative](#h.gln5i78kxlfh) in order to verify their [digital signature](#h.s93np0i5rcne).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/public_key&sa=D&source=editors&ust=1718703186777286&usg=AOvVaw0k9y9xFKwd5gK_dHKSv1wM): The public part of an asymmetric key pair that is typically used to verify signatures or encrypt data.
+
+public key certificate
+
+A set of [data](#h.o783ayrrkc6g) that uniquely identifies a [public key](#h.hohpk6z1qk4f) (which has a corresponding [private key](#h.74y9dvxzg24c)) and an [owner](#h.y450rpi0zmuu) that is authorized to use the [key pair](#h.53rzpn1yn6q7). The certificate contains the owner’s [public key](#h.hohpk6z1qk4f) and possibly other information and is [digitally signed](#h.s93np0i5rcne) by a [certification authority](#h.lubcv4tm2i7r) (i.e., a trusted [party](#h.cn6bno48fomj)), thereby binding the [public key](#h.hohpk6z1qk4f) to the [owner](#h.y450rpi0zmuu).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/public_key_certificate&sa=D&source=editors&ust=1718703186778260&usg=AOvVaw3-8ps0cAuyQI5ac1hpLVq4).
+
+See also: [public key infrastructure](#h.mdxu5kpbdo4x).
+
+Supporting definitions:
+
+Wikipedia : In [cryptography](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Cryptography&sa=D&source=editors&ust=1718703186778604&usg=AOvVaw1ANfGrWhNqdWt-Bg0WL9J8), a public key certificate, also known as a digital certificate or identity certificate, is an [electronic document](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_document&sa=D&source=editors&ust=1718703186778754&usg=AOvVaw1qujl7s2qcBdSPSEFtdpBU) used to prove the validity of a [public key](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Key_authentication&sa=D&source=editors&ust=1718703186778923&usg=AOvVaw1_uR-yE95PaqgL9DGrIeDJ). The certificate includes information about the key, information about the identity of its owner (called the subject), and the [digital signature](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_signature&sa=D&source=editors&ust=1718703186779153&usg=AOvVaw2Tkh-TVqFV-ENpnetekSyC) of an entity that has verified the certificate's contents (called the issuer). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In [email encryption](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Email_encryption&sa=D&source=editors&ust=1718703186779319&usg=AOvVaw0h-SX3JgMwFPpxwopqzqx-), [code signing](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Code_signing&sa=D&source=editors&ust=1718703186779460&usg=AOvVaw3CD4zGTOX16McAGeZvrgKI), and [e-signature](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_signature&sa=D&source=editors&ust=1718703186779612&usg=AOvVaw0GAcEwTCzvqZUCTxF8pC9A) systems, a certificate's subject is typically a person or organization. However, in [Transport Layer Security](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Transport_Layer_Security&sa=D&source=editors&ust=1718703186779762&usg=AOvVaw0u2Tc8sSZkV9HIgcEtexRQ) (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices.
+
+public key cryptography
+
+Public key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related [keys](#h.53rzpn1yn6q7). Each key pair consists of a [public key](#h.hohpk6z1qk4f) and a corresponding [private key](#h.74y9dvxzg24c). [Key pairs](#h.53rzpn1yn6q7) are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public key cryptography depends on keeping the [private key](#h.74y9dvxzg24c) secret; the [public key](#h.hohpk6z1qk4f) can be openly distributed without compromising security.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public-key_cryptography&sa=D&source=editors&ust=1718703186780533&usg=AOvVaw0idv5Jtfy1Xar81749nqm8).
+
+See also: [public key infrastructure](#h.mdxu5kpbdo4x).
+
+public key infrastructure
+
+A set of policies, processes, server platforms, software and workstations used for the purpose of administering [certificates](#h.anf8g7aq0gk5) and [public-private key pairs](#h.jhvr6rbo5z3q), including the ability to [issue](#h.xyrplzbvtffq), maintain, and [revoke](#h.ilt4dj4huwza) [public key certificates](#h.anf8g7aq0gk5). The PKI includes the hierarchy of [certificate authorities](#h.dm6pt5kg2uim) that allow for the deployment of [digital certificates](#h.vpsiiv68xxwc) that support [encryption](#h.iyq318f2vg61), [digital signature](#h.s93np0i5rcne) and [authentication](#h.gp553sxzbmv1) to meet business and security requirements.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/public_key_infrastructure&sa=D&source=editors&ust=1718703186781472&usg=AOvVaw3ei6FjkA2XTeptjzTZR-q0).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public_key_infrastructure&sa=D&source=editors&ust=1718703186781707&usg=AOvVaw1X_fFIXLAYBvxacWgvfKx4): A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke [digital certificates](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public_key_certificate&sa=D&source=editors&ust=1718703186781923&usg=AOvVaw3N9v-5SzKjmjOaQupK3xpZ) and manage [public-key encryption](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Public-key_cryptography&sa=D&source=editors&ust=1718703186782111&usg=AOvVaw0xLzeVDbz89E5LQTlJbwzk). The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email.
+
+QR code
+
+A QR code (short for "quick-response code") is a type of two-dimensional matrix barcode—a [machine-readable](#h.8s3s84fzcfi3) optical image that contains information specific to the identified item. In practice, QR codes contain data for a locator, an identifier, and web tracking.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/QR_code&sa=D&source=editors&ust=1718703186782665&usg=AOvVaw11TQ0r927bq5411Z8AOf1f).
+
+See also: [out-of-band introduction](#h.tsslu4lnog0s).
+
+RBAC
+
+See: [role-based access control](#h.isj9yeecvwmw).
+
+real world identity
+
+A term used to describe the opposite of [digital identity](#h.r5y8zwxvzyd3), i.e., an identity (typically for a person) in the physical instead of the digital world.
+
+Also known as: [RWI](#h.rzufdn5u9c1c).
+
+See also: [legal identity](#h.s0f760qh7yij).
+
+recommended
+
+A [requirement](#h.ajxlw8r3dvcc) that is not [mandatory](#h.n3iynmuwwbf8) to implement in order for an implementer to be in [compliance](#h.r0iiayz1za1i), but which should be implemented unless the implementer has a good reason. In [ToIP governance frameworks](#h.ns22ebn9xjun), a recommendation is expressed using a SHOULD or RECOMMENDED keyword as defined in IETF RFC 2119.
+
+See also: [mandatory](#h.n3iynmuwwbf8), [optional](#h.9411lfbb9qf2).
+
+For more information, see: [https://www.rfc-editor.org/rfc/rfc2119](https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc2119&sa=D&source=editors&ust=1718703186784192&usg=AOvVaw3vphCZaLd_IF2yNFdLhVUw).
+
+record
+
+A uniquely identifiable entry or listing in a database or [registry](#h.farjhbxfa3lh).
+
+registrant
+
+The [party](#h.cn6bno48fomj) submitting a [registration](#h.scqeh7q9ln83) [record](#h.y4ybzkfe6yzv) to a [registry](#h.farjhbxfa3lh).
+
+registrar
+
+The [party](#h.cn6bno48fomj) who performs [registration](#h.scqeh7q9ln83) on behalf of a [registrant](#h.60ettadb44j).
+
+registration
+
+The process by which a [registrant](#h.60ettadb44j) submits a [record](#h.y4ybzkfe6yzv) to a [registry](#h.farjhbxfa3lh).
+
+registration agent
+
+A [party](#h.cn6bno48fomj) responsible for accepting [registration](#h.scqeh7q9ln83) requests and [authenticating](#h.gp553sxzbmv1) the [entity](#h.5imtbzl1f4xo) making the request. The term may also apply to a [party](#h.cn6bno48fomj) accepting [issuance](#h.zfdojht594xv) requests for [digital credentials](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.ddna9lucn4k6&sa=D&source=editors&ust=1718703186786011&usg=AOvVaw1sljogAgKIa28MyaOWX8lU).
+
+registry
+
+A specialized database of [records](#h.y4ybzkfe6yzv) that serves as an [authoritative source](#h.9tt1qpgdfnxs) of information about [entities](#h.5imtbzl1f4xo).
+
+See also: [trust registry](#h.5kzln6m5e8j5).
+
+relationship context
+
+A context established within the boundary of a [trust relationship](#h.pu2asd79bqzo).
+
+relying party
+
+A [party](#h.cn6bno48fomj) who consumes [claims](#h.akieli6njkk5) or [trust graphs](#h.eqx98nkqjzsv) from other [parties](#h.cn6bno48fomj) (such as [issuers](#h.xyrplzbvtffq), [holders](#h.64mptmm24w7u), and [trust registries](#h.5kzln6m5e8j5)) in order to make a [trust decision](#h.m8c86ccqis9r).
+
+See also: [verifier](#h.xfewd7t01hu0).
+
+Note: The term “relying party” is more commonly used in [federated identity](#h.cb1le64hx6h5) architecture; the term “verifier” is more commonly used with [decentralized identity](#h.xodo7ytn4cx2) architecture and [verifiable credentials](#h.co5algna3zkh).
+
+reputation
+
+The reputation or prestige of a social entity (a [person](#h.yx4qb6dcjdvj), a social group, an [organization](#h.z27mp1358pi9), or a place) is an opinion about that entity – typically developed as a result of social evaluation on a set of criteria, such as behavior or performance.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Reputation&sa=D&source=editors&ust=1718703186788027&usg=AOvVaw1KclBDIhqH5R3k3uVg1IV9).
+
+reputation graph
+
+A graph of the [reputation](#h.4q9bmbf922ui) relationships between different entities in a [trust community](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.a9l3odcb1s29&sa=D&source=editors&ust=1718703186788466&usg=AOvVaw1bWcKoLRhFw-k1UqoKgagQ). In a [digital trust ecosystem](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.h47f86smlz4y&sa=D&source=editors&ust=1718703186788667&usg=AOvVaw1N2po-dergjyomUNbPDiVT), the [governing body](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.1wptecwzvuvz&sa=D&source=editors&ust=1718703186788859&usg=AOvVaw3C_wXKXb3aXbGpa0jXXsm5) may be one [trust root](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.vfnyletkzjv5&sa=D&source=editors&ust=1718703186789040&usg=AOvVaw15P1K4h-O2x-6rFk_cUDMC) of a reputation graph. In some cases, a reputation graph can be traversed by making queries to one or more [trust registries](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5kzln6m5e8j5&sa=D&source=editors&ust=1718703186789236&usg=AOvVaw0wvSkCXTzH8ooTdSUQJ1wB).
+
+See also: [authorization graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5tvkchqqqka8&sa=D&source=editors&ust=1718703186789480&usg=AOvVaw2djy9uableVBP0SSqx4N4M), [governance graph](#h.u9xnz96ecf5x), [trust graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.eqx98nkqjzsv&sa=D&source=editors&ust=1718703186789767&usg=AOvVaw2TsHI07RFau-g9kG0b7nOu).
+
+reputation system
+
+Reputation systems are programs or algorithms that allow users to rate each other in online communities in order to build [trust](#h.sdrgtm7bwb51) through [reputation](#h.4q9bmbf922ui). Some common uses of these systems can be found on e\-commerce websites such as eBay, Amazon.com, and Etsy as well as online advice communities such as Stack Exchange.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Reputation_system&sa=D&source=editors&ust=1718703186790448&usg=AOvVaw2zE_OnD-jkYiP2cqwm0vmo).
+
+requirement
+
+A specified condition or behavior to which a system needs to [comply](#h.r0iiayz1za1i). [Technical requirements](#h.l7t266ck3tjw) are defined in [technical specifications](#h.u62ak0cgfdb1) and implemented in computer systems to be executed by software [actors](#h.gzdfngxkp0ip). [Governance requirements](#h.j4z5czk0dk8t) are defined in [governance documents](#h.c8fvvxachz5h) that specify [policies](#h.udts41hso4w4) and procedures to be executed by human [actors](#h.gzdfngxkp0ip). In ToIP architecture, requirements are expressed using the keywords defined in Internet RFC 2119.
+
+See also: [mandatory](#h.n3iynmuwwbf8), [recommended](#h.db3a5yf4o7iu), [optional](#h.9411lfbb9qf2).
+
+For more information, see: [https://www.rfc-editor.org/rfc/rfc2119](https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc2119&sa=D&source=editors&ust=1718703186791314&usg=AOvVaw0zQYrwe30wP74lCfGXbKDi).
+
+revocation
+
+In the context of [digital credentials](#h.ddna9lucn4k6), revocation is an event signifying that the [issuer](#h.xyrplzbvtffq) no longer attests to the [validity](#h.rbp41an0omv6) of a [credential](#h.ddna9lucn4k6) they have [issued](#h.xyrplzbvtffq). In the context of cryptographic keys, revocation is an event signifying that the [controller](#h.gemoqe2m303z) no longer attests to the [validity](#h.rbp41an0omv6) of a public/private key pair for which the [controller](#h.gemoqe2m303z) is [authoritative](#h.gln5i78kxlfh).
+
+See also: [issuance](#h.zfdojht594xv), [presentation](#h.h5d1xfsxbbr0).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23revokerevocation&sa=D&source=editors&ust=1718703186792318&usg=AOvVaw1tqNJJNHLkMok0XI_SckWM): the act, by or on behalf of the [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186792547&usg=AOvVaw2oTju9Kcwp7o06i9o6xztN) that has issued the [credential](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186792714&usg=AOvVaw0LA17m8dj7snDn7SDzKWnb), of no longer vouching for the correctness or any other qualification of (arbitrary parts of) that [credential](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/credential&sa=D&source=editors&ust=1718703186792870&usg=AOvVaw2M-_J3NW0WQAwxsqfM6C4G).
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/revocation&sa=D&source=editors&ust=1718703186793107&usg=AOvVaw2q8v6ZPUuRhYyBqGGrqEAL): ​​For digital certificates: The process of permanently ending the binding between a certificate and the identity asserted in the certificate from a specified time forward. For cryptographic keys: A process whereby a notice is made available to affected entities that keys should be removed from operational use prior to the end of the established cryptoperiod of those keys.
+
+risk
+
+The effects that uncertainty (i.e. a lack of information, understanding or [knowledge](#h.k96lktyswxnb) of events, their consequences or likelihoods) can have on the intended realization of an [objective](#h.k0v6ir8wmcav) of a [party](#h.cn6bno48fomj).
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary&sa=D&source=editors&ust=1718703186794187&usg=AOvVaw1mVSvBbBNO81Py-zO6bgs8)
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/risk&sa=D&source=editors&ust=1718703186794600&usg=AOvVaw2lBVnu0LSrJZmL2XYVoFc0): A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.
+
+risk assessment
+
+The process of identifying [risks](#h.qzpr4qua4ble) to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other [organizations](#h.z27mp1358pi9), and the overall [ecosystem](#h.h47f86smlz4y), resulting from the operation of an information system. Risk assessment is part of [risk management](#h.8i5edrs9npxn), incorporates threat and vulnerability analyses, and considers [risk mitigations](#h.lmnt77k1l43b) provided by security controls planned or in place.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/risk_assessment&sa=D&source=editors&ust=1718703186795237&usg=AOvVaw1-B4ekP7xP4f7R6EsNeE4t).
+
+Also known as: risk analysis.
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk_assessment&sa=D&source=editors&ust=1718703186795527&usg=AOvVaw1AUNHVwmUE1TLRQkiIl0DO): Risk assessment determines possible mishaps, their likelihood and consequences, and the [tolerances](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Engineering_tolerance&sa=D&source=editors&ust=1718703186795693&usg=AOvVaw0gYoSVROmF8yD8P4wR45T3) for such events.[\[1\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk_assessment%23cite_note-RausandRisk13-1&sa=D&source=editors&ust=1718703186795856&usg=AOvVaw0nWTZ7HyXdvdK46A1hkIVX) The results of this process may be expressed in a [quantitative](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Quantitative_property&sa=D&source=editors&ust=1718703186796013&usg=AOvVaw128PDpF-zbmu_kCD37t6Dz) or [qualitative](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Qualitative_data&sa=D&source=editors&ust=1718703186796151&usg=AOvVaw2-W3jsfOKDaK2LpdojQceq) fashion. Risk assessment is an inherent part of a broader [risk management](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk_management&sa=D&source=editors&ust=1718703186796356&usg=AOvVaw1WzD5Egg24hFIWf2BSrh8w) strategy to help reduce any potential risk-related consequences. More precisely, risk assessment identifies and analyses potential (future) events that may negatively impact individuals, assets, and/or the environment (i.e. [hazard analysis](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Hazard_analysis&sa=D&source=editors&ust=1718703186796567&usg=AOvVaw1X1qwhaGdnInItlw5E2Ebl)). It also makes judgments "on the [tolerability](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Tolerability&sa=D&source=editors&ust=1718703186796744&usg=AOvVaw1Ik2srg0uZ60YQOQOwzQLH) of the risk on the basis of a risk analysis" while considering influencing factors (i.e. risk evaluation).
+
+risk decision
+
+See: [trust decision](#h.m8c86ccqis9r).
+
+risk management
+
+The process of managing [risks](#h.qzpr4qua4ble) to organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals resulting from the operation of an information system, and includes: (i) the conduct of a [risk assessment](#h.91ipsr7y3vb6); (ii) the implementation of a [risk mitigation](#h.lmnt77k1l43b) strategy; and (iii) employment of techniques and procedures for the continuous monitoring of the security state of the information system.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/risk_management&sa=D&source=editors&ust=1718703186797394&usg=AOvVaw12Zlr6UHi0D7llf_DXrRo7).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23risk-management&sa=D&source=editors&ust=1718703186797718&usg=AOvVaw0vYKxl4VrMQ8OSK8fKOSU9): a process that is run by (or on behalf of) a specific [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186797974&usg=AOvVaw0hmg_XAeKQr9XfzlYjm5pe) for the purpose of [managing](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/management&sa=D&source=editors&ust=1718703186798159&usg=AOvVaw2l3GgULfT-usWCJqLlDbRO) the [risks](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/risk&sa=D&source=editors&ust=1718703186798335&usg=AOvVaw2rznCSvbbISs0WWi6zPDJo) that it [owns](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/owner&sa=D&source=editors&ust=1718703186798513&usg=AOvVaw00KIpGByvuwqWjlGVh45Vw) (thereby realizing specific [risk objectives](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/risk-objective&sa=D&source=editors&ust=1718703186798709&usg=AOvVaw0Y-Sb8CJbfvj5EsxtyB3cS)).
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk_management&sa=D&source=editors&ust=1718703186799018&usg=AOvVaw0CE-2i6uc3bqQKOn9Eu3DB): Risk management is the identification, evaluation, and prioritization of [risks](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Risk&sa=D&source=editors&ust=1718703186799168&usg=AOvVaw3PxwYKvPgIqng9OUzDXGg5) (defined in [ISO 31000](https://www.google.com/url?q=https://en.wikipedia.org/wiki/ISO_31000&sa=D&source=editors&ust=1718703186799345&usg=AOvVaw1e0gPr_R12HlnINFwHkG2j) as the effect of uncertainty on objectives) followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.
+
+risk mitigation
+
+Prioritizing, evaluating, and implementing the appropriate [risk](#h.qzpr4qua4ble)\-reducing controls/countermeasures recommended from the [risk management](#h.8i5edrs9npxn) process.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/risk_mitigation&sa=D&source=editors&ust=1718703186799837&usg=AOvVaw1jjAEHYk-SP2DnhAQUgta6).
+
+role
+
+A defined set of characteristics that an [entity](#h.5imtbzl1f4xo) has in some context, such as responsibilities it may have, [actions](#h.l54nzmooy631) (behaviors) it may execute, or pieces of [knowledge](#h.k96lktyswxnb) that it is expected to have in that context, which are referenced by a specific role name.
+
+Source: [eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23role&sa=D&source=editors&ust=1718703186800341&usg=AOvVaw0SmSdYG4klE9C_V3ln1WAL).
+
+See also: [role credential](#h.q15w534tm34t).
+
+role-based access control
+
+[Access control](#h.lmk4gqobt99b) based on user [roles](#h.sf54cyuamo6x) (i.e., a collection of access [authorizations](#h.576ssfpt348i) a user receives based on an explicit or implicit assumption of a given [role](#h.sf54cyuamo6x)). [Role](#h.sf54cyuamo6x) [permissions](#h.mnqlrmrkqb9) may be inherited through a [role](#h.sf54cyuamo6x) hierarchy and typically reflect the [permissions](#h.mnqlrmrkqb9) needed to perform defined functions within an [organization](#h.z27mp1358pi9). A given [role](#h.sf54cyuamo6x) may apply to a single individual or to several individuals.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/role_based_access_control&sa=D&source=editors&ust=1718703186801128&usg=AOvVaw1JeraP70Rnwb7d1XMB7E1P).
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Role-based_access_control&sa=D&source=editors&ust=1718703186801379&usg=AOvVaw1H_ZhqvR91IGkAnRj_5BYN): In computer systems security, role-based access control (RBAC) or role-based security is an approach to restricting system access to authorized users, and to implementing [mandatory access control](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mandatory_access_control&sa=D&source=editors&ust=1718703186801617&usg=AOvVaw1sqNGZfKldBbqRPLG8YTPz) (MAC) or [discretionary access control](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Discretionary_access_control&sa=D&source=editors&ust=1718703186801795&usg=AOvVaw0BCCrT0Zj1Bo7S3muVVgxE) (DAC).
+
+role credential
+
+A [credential](#h.kcj6iw2vib1v) [claiming](#h.akieli6njkk5) that the [subject](#h.voca6uuv1a4) has a specific [role](#h.sf54cyuamo6x).
+
+router
+
+A router is a networking device that forwards [data packets](#h.9hc1adgu2nrx) between computer networks. Routers perform the traffic directing functions between networks and on the global Internet. Data sent through a network, such as a web page or email, is in the form of [data packets](#h.9hc1adgu2nrx). A packet is typically forwarded from one router to another router through the networks that constitute an internetwork (e.g. the Internet) until it reaches its destination [node](#h.w1aty8c036fp). This process is called [routing](#h.tbxetxt0mdlp).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Router_\(computing\)&sa=D&source=editors&ust=1718703186802728&usg=AOvVaw3d6RsAQHtrgq_OVmL5BZOI).
+
+routing
+
+Routing is the process of selecting a path for traffic in a network or between or across multiple networks. Broadly, routing is performed in many types of networks, including circuit-switched networks, such as the public switched telephone network (PSTN), and computer networks, such as the Internet. A [router](#h.oqbqyf914pln) is a computing device that specializes in performing routing.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Routing&sa=D&source=editors&ust=1718703186803372&usg=AOvVaw2SsUxgHtkg6DTWKsBXlpMp).
+
+rule
+
+A prescribed guide for conduct, process or [action](#h.l54nzmooy631) to achieve a defined result or [objective](#h.k0v6ir8wmcav). Rules may be [human-readable](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.ywyofmy4do4t&sa=D&source=editors&ust=1718703186803875&usg=AOvVaw20aTtmDHPKbdwq317Vw7af) or [machine-readable](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.8s3s84fzcfi3&sa=D&source=editors&ust=1718703186804112&usg=AOvVaw34zAFPqYjUtHkzdZtM03dL) or both.
+
+See also: [governance framework](#h.2x05z0r097mn), [policy](#h.udts41hso4w4).
+
+RWI
+
+See: [real world identity](#h.x0sst0y7375w).
+
+schema
+
+A framework, pattern, or set of [rules](#h.v7s575ulon74) for enforcing a specific structure on a digital object or a set of digital [data](#h.o783ayrrkc6g). There are many types of schemas, e.g., data schema, credential verification schema, database schema.
+
+For more information, see: W3C [Data Schemas](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23data-schemas&sa=D&source=editors&ust=1718703186805038&usg=AOvVaw1IygqRd64Hh0OmnMUaoPC6).
+
+Note: credentialSchema is a Property Definition in the [W3C VC Data Model, see 3.2.1](https://www.google.com/url?q=https://www.w3.org/2018/credentials/%23credentialSchema&sa=D&source=editors&ust=1718703186805394&usg=AOvVaw3rCeU1r6uCHrF2YjgJIyzd)
+
+scope
+
+In the context of [terminology](#h.189fachpwy1a), scope refers to the set of possible [concepts](#h.6hyxh4mxxbu2) within which: a) a specific [term](#h.ojn7uxdcaf7u) is intended to uniquely identify a [concept](#h.6hyxh4mxxbu2), or b) a specific [glossary](#h.z1he49173rzw) is intended to identify a set of [concepts](#h.6hyxh4mxxbu2). In the context of [identification](#h.fslz9gxdlb84), scope refers to the set of possible entities within which a specific entity must be uniquely identified. In the context of [specifications](#h.dst3g25dh97g), scope refers to the set of problems (the problem space) within which the specification is intended to specify solutions.
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23scope&sa=D&source=editors&ust=1718703186806303&usg=AOvVaw0EHnxLqIeqX_0-FzdgsWcZ): the extent of the area or subject matter (which we use, e.g., to define [pattern](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186806545&usg=AOvVaw19SHJvAcrks69uWvfXIUya), [concept](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186806695&usg=AOvVaw1uhQarOfqlK3W0mMLq756D), [term](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186806871&usg=AOvVaw0kBeTVRJ6jyPl1HNzTdNAE) and [glossaries](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/@&sa=D&source=editors&ust=1718703186807015&usg=AOvVaw0lHGGz93RULsPa-r6VLJAz) in, but it serves other purposes as well).
+
+SCID
+
+See: [self-certifying identifier](#h.hub48c59i8wj).
+
+second party
+
+The [party](#h.cn6bno48fomj) with whom a [first party](#h.uxx5bjam20ag) engages to form a [trust relationship](#h.pu2asd79bqzo), establish a [connection](#h.thbpewq1px8x), or execute a [transaction](#h.92pu88ke4p7k).
+
+See also: [third party](#h.zu2vj8151tr).
+
+Secure Enclave
+
+A coprocessor on Apple iOS devices that serves as a [trusted execution environment](#h.rsly6bxjqeg5).
+
+secure multi-party computation
+
+See: [multi-party computation](#h.2x62jfcai7ch).
+
+Secure Sockets Layer
+
+The original transport layer security protocol developed by Netscape and partners. Now deprecated in favor of [Transport Layer Security](#h.6hbp4j6qy89) (TLS).
+
+Also known as: [SSL](#h.y0pexeg8ynlg).
+
+security domain
+
+An environment or context that includes a set of system resources and a set of system entities that have the right to access the resources as defined by a common [security policy](#h.2fcbwog0w43a), security model, or security architecture.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/domain&sa=D&source=editors&ust=1718703186808890&usg=AOvVaw1y8xkkn-oBdZEHCGTsSnzN)
+
+See also: [trust domain](#h.60miqe21hd5h).
+
+security policy
+
+A set of [policies](#h.udts41hso4w4) and [rules](#h.v7s575ulon74) that governs all aspects of security-relevant system and system element behavior.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/security_policy&sa=D&source=editors&ust=1718703186809478&usg=AOvVaw3gApqOsTQLcaPaftO1rkko)
+
+See also: [privacy policy](#h.xbjzswct9aqi).
+
+self-asserted
+
+A term used to describe a [claim](#h.akieli6njkk5) or a [credential](#h.kcj6iw2vib1v) whose [subject](#h.voca6uuv1a4) is also the [issuer](#h.xyrplzbvtffq).
+
+self-certified
+
+When a [party](#h.cn6bno48fomj) provides its own [certification](#h.ytzysnyu57ec) that it is [compliant](#h.r0iiayz1za1i) with a set of [requirements](#h.ajxlw8r3dvcc), such as a [governance framework](#h.2x05z0r097mn).
+
+self-certifying identifier
+
+A subclass of [verifiable identifier](#h.wyda231qefe) that is [cryptographically verifiable](#h.422iwwfur12) without the need to rely on any [third party](#h.zu2vj8151tr) for [verification](#h.2bnb6g8na7cu) because the [identifier](#h.u3bfehmj4ed3) is cryptographically bound to the [cryptographic keys](#h.53rzpn1yn6q7) from which it was generated.
+
+See also: [autonomic identifier](#h.bz098kwwc559).
+
+Also known as: [SCID](#h.1hgjtlg27gg4).
+
+self-sovereign identity
+
+A [decentralized identity](#h.xodo7ytn4cx2) architecture that implements the [Principles of SSI](#h.dk15fkyq7xn5).
+
+See also: [federated identity](#h.cb1le64hx6h5).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23ssi-self-sovereign-identity&sa=D&source=editors&ust=1718703186811735&usg=AOvVaw2W75NBll8qRqzuSL11ZbAK): SSI (Self-Sovereign Identity) is a term that has many different interpretations, and that we use to refer to concepts/ideas, architectures, processes and technologies that aim to support (autonomous) [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186811969&usg=AOvVaw1wMTJBa7dvDPEDaxlSmIB7) as they negotiate and execute electronic [transactions](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/transaction&sa=D&source=editors&ust=1718703186812159&usg=AOvVaw0kDfN3l400_x8TePXHhCLM) with one another.
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Self-sovereign_identity&sa=D&source=editors&ust=1718703186812402&usg=AOvVaw3acR3RaITPwf-bTpfyoQ3D): Self-sovereign identity (SSI) is an approach to [digital identity](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_identity&sa=D&source=editors&ust=1718703186812558&usg=AOvVaw2Ml4wMadmrKiuXym838EHg) that gives individuals control over the information they use to prove who they are to [websites](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Website&sa=D&source=editors&ust=1718703186812695&usg=AOvVaw3qfYsQz-I1UyS8-0jlJeZN), services, and [applications](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Application_software&sa=D&source=editors&ust=1718703186812861&usg=AOvVaw3Vxhas3LjyscZwP1h7OE_e) across the web. Without SSI, individuals with persistent accounts (identities) across the [internet](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Internet&sa=D&source=editors&ust=1718703186813046&usg=AOvVaw3i59GcI5ik_xUnopvhJxjf) must rely on a number of large identity providers, such as [Facebook](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Facebook&sa=D&source=editors&ust=1718703186813219&usg=AOvVaw1daNtdIzoeEr9v0v5v0kE4) (Facebook Connect) and [Google](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Google&sa=D&source=editors&ust=1718703186813417&usg=AOvVaw0u7d21VL9mSqVom9ZVgbkP) (Google Sign-In), that have control of the information associated with their identity.
+
+sensitive data
+
+[Personal data](#h.rpiib2ml3s9c) that a reasonable [person](#h.yx4qb6dcjdvj) would view from a privacy protection standpoint as requiring special care above and beyond other [personal data](#h.rpiib2ml3s9c).
+
+Supporting definitions:
+
+[PEMC IGR](https://www.google.com/url?q=https://kantarainitiative.org/download/pemc-implementors-guidance-report/&sa=D&source=editors&ust=1718703186814007&usg=AOvVaw35aHMJq2Yxp0liMCjBRUls): While all Personal Information may be regarded as sensitive in that an unauthorized processing of an individual’s data may be offensive to that person, we use the term here to denote information that a reasonable person would view as requiring special care above and beyond other personal data. For reference see [GDPR Recital #51](https://www.google.com/url?q=https://www.privacy-regulation.eu/en/recital-51-GDPR.htm&sa=D&source=editors&ust=1718703186814255&usg=AOvVaw3ATU0uyr5WziSy4RHoEedQ) or [Sensitive Personal Data](https://www.google.com/url?q=https://w3c.github.io/dpv/dpv/%23SensitivePersonalData&sa=D&source=editors&ust=1718703186814404&usg=AOvVaw05GbtIjLhE5rQNY76lrxNg) in the W3C [Data Privacy Vocabulary](https://www.google.com/url?q=https://w3id.org/dpv&sa=D&source=editors&ust=1718703186814569&usg=AOvVaw2vgkX9g99Yb1MLXd1LHavX).
+
+session
+
+See: [communication session](#h.i82tgrmxy0d8).
+
+sociotechnical system
+
+An approach to complex organizational work design that recognizes the interaction between people and technology in workplaces. The term also refers to coherent systems of human relations, technical objects, and cybernetic processes that inhere to large, complex infrastructures. Social society, and its constituent substructures, qualify as complex sociotechnical systems.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Sociotechnical_system&sa=D&source=editors&ust=1718703186815186&usg=AOvVaw3o4zuDDUVm3FoM_6eKPbeu)
+
+software agent
+
+In computer science, a software agent is a computer program that acts for a user or other program in a relationship of [agency](#h.7q79v9jnqhrr), which derives from the Latin agere (to do): an agreement to act on one's behalf. A [user agent](#h.jb61co23rlut) is a specific type of software agent that is used directly by an end-user as the [principal](#h.sydbe7rk6244).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Software_agent&sa=D&source=editors&ust=1718703186815707&usg=AOvVaw0DvGJaBV24dKxVKmZe1LPt).
+
+See also: [digital agent](#h.z3ugzt4hgdf6).
+
+Sovrin Foundation
+
+A 501 (c)(4) nonprofit organization established to administer the [governance framework](#h.2x05z0r097mn) governing the Sovrin Network, a public service utility enabling [self-sovereign identity](#h.wdojy63bltd4) on the internet. The Sovrin Foundation is an independent [organization](#h.z27mp1358pi9) that is responsible for ensuring the Sovrin [identity](#h.z1gairv0pej5) system is public and globally accessible.
+
+For more information, see: [https://sovrin.org/](https://www.google.com/url?q=https://sovrin.org/&sa=D&source=editors&ust=1718703186816403&usg=AOvVaw2dI7ngMiRRzs8IH6qkY984) 
+
+spanning layer
+
+A specific layer within a [protocol stack](#h.6ik2cef0ipsr) that consists of a single protocol explicitly designed to provide interoperability between the [protocols layers](#h.pe8dekl2dtq0) above it and below it.
+
+See also: [hourglass model](#h.u8d1rxc2o86), [trust spanning layer](#h.k9uiol17u620).
+
+For more information, see: [https://www.isi.edu/newarch/iDOCS/final.finalreport.pdf](https://www.google.com/url?q=https://www.isi.edu/newarch/iDOCS/final.finalreport.pdf&sa=D&source=editors&ust=1718703186817017&usg=AOvVaw13qUrg0ao-pJeJ2EP_QqYZ), National Academies of Sciences, Engineering, and Medicine. 1997. The Unpredictable Certainty: White Papers. Washington, DC: The National Academies Press. [https://doi.org/10.17226/6062](https://www.google.com/url?q=https://doi.org/10.17226/6062&sa=D&source=editors&ust=1718703186817184&usg=AOvVaw3cdEgwCk_gfPKSLVgOnp1B).
+
+specification
+
+See: [technical specification](#h.u62ak0cgfdb1).
+
+SSI
+
+See: [self-sovereign identity](#h.wdojy63bltd4).
+
+Note: In some contexts, such as academic papers or industry conferences, this acronym has started to replace the term it represents.
+
+SSL
+
+See: [Secure Sockets Layer](#h.gxktv8f54wc8).
+
+stream
+
+In the context of digital [communications](#h.w02a6srdng3j), and in particular [streaming media](#h.a9wzp42pgiac), a flow of [data](#h.o783ayrrkc6g) delivered in a continuous manner from a server to a client rather than in discrete [messages](#h.bge7ubygwk2q).
+
+streaming media
+
+Streaming media is multimedia for playback using an offline or online media player. Technically, the stream is delivered and consumed in a continuous manner from a client, with little or no intermediate storage in network elements. Streaming refers to the delivery method of content, rather than the content itself.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Streaming_media&sa=D&source=editors&ust=1718703186818760&usg=AOvVaw1-F5O6ENDyNBlN3e2WhLG6).
+
+subject
+
+The [entity](#h.5imtbzl1f4xo) described by one or more [claims](#h.akieli6njkk5), particularly in the context of [digital credentials](#h.ddna9lucn4k6).
+
+Supporting definitions:
+
+[W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186819270&usg=AOvVaw3ucr8wM7ZUoXzk1cPgbUsG): A thing about which [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186819489&usg=AOvVaw2HiAuRd6ISylHyNYeyLmSj) are made.
+
+[eSSIF-Lab:](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23subject&sa=D&source=editors&ust=1718703186819694&usg=AOvVaw2VfxeqfQpLbsV7SEyoe1-I) the (single) [entity](#h.5imtbzl1f4xo) to which a given set of coherent [data](#h.o783ayrrkc6g) relates/pertains. Examples of such sets include attributes, [Claims](#h.akieli6njkk5)/Assertions, files/dossiers, [(verifiable) credentials](#h.co5algna3zkh), [(partial) identities](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/partial-identity&sa=D&source=editors&ust=1718703186820033&usg=AOvVaw04DcZC4RJtsZ3fI4Xr7hNJ), [employment contracts](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/employment-contract&sa=D&source=editors&ust=1718703186820190&usg=AOvVaw34SVY7KR1wdf6FYj1d9mKl), etc.
+
+subscription
+
+In the context of decentralized digital trust infrastructure, a subscription is an agreement between a first [digital agent](#h.z3ugzt4hgdf6)—the publisher—to automatically send a second [digital agent](#h.z3ugzt4hgdf6)—the subscriber—a [message](#h.bge7ubygwk2q) when a specific type of event happens in the [wallet](#h.mh27630t20d) or [vault](#h.cz29glapo2tg) managed by the first [digital agent](#h.z3ugzt4hgdf6).
+
+supporting system
+
+A system that operates at [ToIP Layer 1](#h.24ggrl8oz4ma), the [trust support](#h.lk120yblym61) [layer](#h.lk120yblym61) of the [ToIP stack](#h.wms58fgdch9m). A supporting system is one of three types of systems defined in the [ToIP Technology Architecture Specification](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.bjv9ltwjbiqm&sa=D&source=editors&ust=1718703186821069&usg=AOvVaw0I568P-KSjeay-cZ6F0aoz).
+
+See also: [endpoint system](#h.scy14dobg777), [intermediary system](#h.hcobm4uk16ff).
+
+Sybil attack
+
+A Sybil attack is a type of attack on a computer network service in which an attacker subverts the service's [reputation system](#h.yzq3axr0dh87) by creating a large number of [pseudonymous](#h.tgbgt5tqzl4m) [identities](#h.z1gairv0pej5) and uses them to gain a disproportionately large influence. It is named after the subject of the book Sybil, a case study of a woman diagnosed with dissociative identity disorder.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Sybil_attack&sa=D&source=editors&ust=1718703186821728&usg=AOvVaw1E48ZkJZc3hYHGLIJFYaZt).
+
+system of record
+
+A system of record (SOR) or source system of record (SSoR) is a data management term for an information storage system (commonly implemented on a computer system running a database management system) that is the [authoritative data source](#h.9tt1qpgdfnxs) for a given data element or piece of information.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/System_of_record&sa=D&source=editors&ust=1718703186822106&usg=AOvVaw0xgC48auE4Vhy-G9m6aBmC)
+
+See also: [authoritative source](#h.9tt1qpgdfnxs), [trust registry](#h.5kzln6m5e8j5), [verifiable data registry](#h.q1dr1v2lltfe).
+
+tamper resistant
+
+A process which makes alterations to the [data](#h.o783ayrrkc6g) difficult (hard to perform), costly (expensive to perform), or both.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/tamper_resistant&sa=D&source=editors&ust=1718703186822672&usg=AOvVaw0s1TG3HV1tzc9MuO-XPNW2).
+
+TCP
+
+See: [Transmission Control Protocol](#h.4wb0yz8sizvi).
+
+TCP/IP
+
+See: [Internet Protocol Suite](#h.oj5ut8qopq0w).
+
+TCP/IP stack
+
+The [protocol stack](#h.6ik2cef0ipsr) implementing the [TCP/IP](#h.txn6vkany9z9) suite.
+
+technical requirement
+
+A [requirement](#h.ajxlw8r3dvcc) for a hardware or software component or system. In the context of decentralized digital trust infrastructure, technical requirements are a subset of [governance requirements](#h.j4z5czk0dk8t). Technical requirements are often specified in a [technical specification](#h.u62ak0cgfdb1).
+
+For more information, see: [https://datatracker.ietf.org/doc/html/rfc2119](https://www.google.com/url?q=https://datatracker.ietf.org/doc/html/rfc2119&sa=D&source=editors&ust=1718703186823845&usg=AOvVaw1VOl17XM400y9Dr1JBMXWo) 
+
+Note: In ToIP architecture, both technical requirements and [governance requirements](#h.j4z5czk0dk8t) are expressed using the keywords defined in IETF RFC 2119.
+
+technical specification
+
+A document that specifies, in a complete, precise, verifiable manner, the [requirements](#h.ajxlw8r3dvcc), design, behavior, or other characteristics of a system or component and often the procedures for determining whether these provisions have been satisfied.
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/specification&sa=D&source=editors&ust=1718703186824419&usg=AOvVaw1XCUzYsmUW3j9NBGM6u8YM)
+
+See also: [governance framework](#h.2x05z0r097mn), [governance requirement](#h.j4z5czk0dk8t), [policy](#h.udts41hso4w4), [rule](#h.v7s575ulon74).
+
+technical trust
+
+A [level of assurance](#h.qseghs6dqcd) in a [trust relationship](#h.pu2asd79bqzo) that can be achieved only via technical means such as hardware, software, network [protocols](#h.pe8dekl2dtq0), and cryptography. Cryptographic trust is a specialized type of technical trust.
+
+Contrast with: [human trust](#h.a4jfn38wd17o).
+
+TEE
+
+See: [trusted execution environment](#h.rsly6bxjqeg5).
+
+term
+
+A unit of text (i.e., a word or phrase) that is used in a particular context or scope to refer to a [concept](#h.6hyxh4mxxbu2) (or a relation between [concepts](#h.6hyxh4mxxbu2), or a [property](#h.c8vs1xa4uwn) of a [concept](#h.6hyxh4mxxbu2)).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23term&sa=D&source=editors&ust=1718703186826144&usg=AOvVaw1idD3SYP2uJgd5uR6IoBTO): a word or phrase (i.e.: text) that is used in at least one [scope](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/scope&sa=D&source=editors&ust=1718703186826444&usg=AOvVaw0WISY_gsrax47VJEsjxiD9)/context to represent a specific [concept](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/concept&sa=D&source=editors&ust=1718703186826605&usg=AOvVaw1y-wu4xdZ6aiAOlqznnrQy).
+
+[Merriam Webster:](https://www.google.com/url?q=https://www.merriam-webster.com/dictionary/term&sa=D&source=editors&ust=1718703186826794&usg=AOvVaw1JBTpOHHx8Velq8V4ODnQ5) a word or expression that has a precise meaning in some uses or is peculiar to a science, art, profession, or subject.
+
+Note: A term MUST NOT be confused with the concept it refers to.
+
+terminology
+
+Terminology is a group of specialized words and respective meanings in a particular field, and also the study of such [terms](#h.ojn7uxdcaf7u) and their use; the latter meaning is also known as terminology science. A term is a word, compound word, or multi-word expressions that in specific contexts is given specific meanings—these may deviate from the meanings the same words have in other contexts and in everyday language.[\[2\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Terminology%23cite_note-2&sa=D&source=editors&ust=1718703186827359&usg=AOvVaw0MUvJWIOjgrVgDAwCvieAb) Terminology is a discipline that studies, among other things, the development of such [terms](#h.ojn7uxdcaf7u) and their interrelationships within a specialized domain. Terminology differs from lexicography, as it involves the study of [concepts](#h.6hyxh4mxxbu2), conceptual systems and their labels (terms), whereas lexicography studies words and their meanings.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Terminology&sa=D&source=editors&ust=1718703186827744&usg=AOvVaw3aRS61gBUAF5kMB2CJmPYN).
+
+terms community
+
+A group of [parties](#h.cn6bno48fomj) who share the need for a common [terminology](#h.189fachpwy1a).
+
+See also: [trust community](#h.a9l3odcb1s29).
+
+terms wiki
+
+A wiki website used by a [terms community](#h.lm4sxza2a80c) to input, maintain, and publish its [terminology](#h.189fachpwy1a). The ToIP Foundation Concepts and Terminology Working Group has established a simple template for GitHub-based terms wikis.
+
+thing
+
+An [entity](#h.5imtbzl1f4xo) that is neither a [natural person](#h.yx4qb6dcjdvj) nor an [organization](#h.z27mp1358pi9) and thus cannot be a [party](#h.cn6bno48fomj). A thing may be a [natural thing](#h.njbtirxy3jvo) or a [man-made thing](#h.98jmqz1068vj).
+
+third party
+
+A [party](#h.cn6bno48fomj) that is not directly involved in the trust relationship between a [first party](#h.uxx5bjam20ag) and a [second party](#h.hk94wskqnzri), but provides supporting services to either or both of them.
+
+three party model
+
+The issuer—holder—verifier model used by all types of [physical credentials](#h.xnlz1vfx60mn) and [digital credentials](#h.ddna9lucn4k6) to enable [transitive trust decisions](#h.syc9o7x61rkm).
+
+Also known as: [trust triangle](#h.n29niebkxky7).
+
+timestamp
+
+A token or packet of information that is used to provide assurance of timeliness; the timestamp contains timestamped data, including a time, and a signature generated by a [t](#h.ryrs51vhrwny)[rusted timestamp authority](#h.ryrs51vhrwny) (TTA).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/timestamp&sa=D&source=editors&ust=1718703186830490&usg=AOvVaw1gaKlvRnromkRohLEz7SjN).
+
+Supporting definitions:
+
+[TechTarget](https://www.google.com/url?q=https://www.techtarget.com/whatis/definition/timestamp%23:~:text%3DA%2520timestamp%2520is%2520the%2520current,minute%2520fractions%2520of%2520a%2520second.&sa=D&source=editors&ust=1718703186830923&usg=AOvVaw1eorsetDTlyYtvTpcQ_xPe): A timestamp is the current time of an event that a computer records. Through mechanisms, such as the [Network Time Protocol](https://www.google.com/url?q=https://www.techtarget.com/searchnetworking/definition/Network-Time-Protocol&sa=D&source=editors&ust=1718703186831144&usg=AOvVaw3TgZn7W84yJYRJo0nrUP7w), a computer maintains accurate current time, calibrated to minute fractions of a second. Such precision makes it possible for networked computers and applications to communicate effectively.
+
+TLS
+
+See: [Transport Layer Security](#h.6hbp4j6qy89).
+
+ToIP
+
+See: Trust Over IP
+
+ToIP application
+
+A [trust application](#h.3pfn27y1gu2o) that runs at [ToIP Layer 4](#h.ym4v87xpn7gq), the [trust application layer](#h.z9t23rwrm0qi).
+
+ToIP channel
+
+See: [VID relationship](#h.b3tilu21ql66).[\[c\]](#cmnt3)
+
+ToIP communication
+
+[Communication](#h.w02a6srdng3j) that uses the [ToIP stack](#h.wms58fgdch9m) to deliver [ToIP messages](#h.5th2gmjr7ij) between [ToIP endpoints](#h.2ahqabymbkn3), optionally using [intermediary systems](#h.i4pfys3yiku)[\[d\]](#cmnt4)[\[e\]](#cmnt5), to provide [authenticity](#h.pitlm5jn3v6u), [confidentiality](#h.445sv27j3c2m), and [correlation privacy](#h.7a6p0irhnbh5).
+
+ToIP connection
+
+A [connection](#h.thbpewq1px8x) formed using the [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl) between two [ToIP endpoints](#h.e787fzjepk60) identified with [verifiable identifiers](#h.wyda231qefe). A ToIP connection is instantiated as one or more [VID relationships](#h.b3tilu21ql66).
+
+ToIP controller
+
+The [controller](#h.gemoqe2m303z) of a [ToIP identifier](#h.xtyidw4bnytz).
+
+ToIP Foundation
+
+A non-profit project of the [Linux Foundation](https://www.google.com/url?q=https://www.linuxfoundation.org/&sa=D&source=editors&ust=1718703186833392&usg=AOvVaw3WNAWEqQp8-1b0Nzxws4OT) chartered to define an overall architecture for decentralized digital trust infrastructure known as the [ToIP stack](#h.wms58fgdch9m).
+
+See also: [Decentralized Identity Foundation](#h.w2py1eklfcb), [OpenWallet Foundation](#h.271hay7m0g55).
+
+For more information, see: [https://trustoverip.org/](https://www.google.com/url?q=https://trustoverip.org/&sa=D&source=editors&ust=1718703186833944&usg=AOvVaw2DpnPzT5cEJ4iG9FN9Jsng).
+
+ToIP endpoint
+
+An [endpoint](#h.yodlnk353mx) that communicates via the [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl) as described in the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+ToIP Governance Architecture Specification
+
+The specification defining the [requirements](#h.ajxlw8r3dvcc) for the [ToIP Governance Stack](#h.ciwa0pidrb2e) published by the [ToIP Foundation](#h.500jynxuxkms).
+
+For more information, see: [https://trustoverip.org/our-work/deliverables/](https://www.google.com/url?q=https://trustoverip.org/our-work/deliverables/&sa=D&source=editors&ust=1718703186834705&usg=AOvVaw22Anwp25y09yG2brigajtn).
+
+ToIP governance framework
+
+A [governance framework](#h.2x05z0r097mn) that conforms to the requirements of the [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3).
+
+ToIP Governance Metamodel
+
+A structural model for [ToIP governance frameworks](#h.ns22ebn9xjun) that specifies the recommended [governance documents](#h.c8fvvxachz5h) that should be included depending on the [objectives](#h.k0v6ir8wmcav) of the [trust community](#h.a9l3odcb1s29).
+
+ToIP Governance Stack
+
+The governance half of the four layer [ToIP stack](#h.wms58fgdch9m) as defined by the [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3).
+
+See also: [ToIP Technology Stack](#h.9looruc0w4ac).
+
+ToIP identifier
+
+A [verifiable identifier](#h.wyda231qefe) for an [entity](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/entity&sa=D&source=editors&ust=1718703186836307&usg=AOvVaw3YTdFNIU09N86o6Z_aoRKj) that is addressable using the [ToIP stack](#h.wms58fgdch9m).
+
+See also: [autonomous identifier](#h.bz098kwwc559), [decentralized identifier](#h.x1jp59hgbk2l).
+
+For more information, see: [Section 6.4](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2364-toip-identifiers&sa=D&source=editors&ust=1718703186836781&usg=AOvVaw2uPOrR_GopOna1LXDBQWy3) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+ToIP intermediary
+
+See: [intermediary system](#h.i4pfys3yiku).
+
+ToIP layer
+
+One of four [protocol layers](#h.pe8dekl2dtq0) in the [ToIP stack](#h.wms58fgdch9m). The four layers are [ToIP Layer 1](#h.24ggrl8oz4ma), [ToIP Layer 2](#h.ikqr9hyt133k), [ToIP Layer 3](#h.7rbvlbpp8vwp), and [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+For more information, see: [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm), [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3).
+
+ToIP Layer 1
+
+The [trust support](#h.451usstmcuuk) layer of the [ToIP stack](#h.wms58fgdch9m), responsible for supporting the [trust spanning protocol](#h.fnuaao3a1j25) at [ToIP Layer 2](#h.ikqr9hyt133k).
+
+ToIP Layer 2
+
+The [trust spanning layer](#h.k9uiol17u620) of the [ToIP stack](#h.wms58fgdch9m), responsible for enabling the [trust task protocols](#h.uo2gx58kwj2o) at [ToIP Layer 3](#h.7rbvlbpp8vwp).
+
+ToIP Layer 3
+
+The [trust task](#h.vzu8kc1yz84q) layer of the [ToIP stack](#h.wms58fgdch9m), responsible for enabling [trust applications](#h.3pfn27y1gu2o) at [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+ToIP Layer 4
+
+The [trust application](#h.3pfn27y1gu2o) layer of the [ToIP stack](#h.wms58fgdch9m), where end users have the direct [human experience](#h.p2mpipjsl834) of using applications that call [trust task protocols](#h.uo2gx58kwj2o) to engage in [trust relationships](#h.pu2asd79bqzo) and make [trust decisions](#h.m8c86ccqis9r) using ToIP decentralized digital trust infrastructure.
+
+ToIP message
+
+A [message](#h.bge7ubygwk2q) communicated between [ToIP endpoints](#h.e787fzjepk60) using the [ToIP stack](#h.wms58fgdch9m).
+
+ToIP stack
+
+The layered architecture for decentralized digital trust infrastructure defined by the [ToIP Foundation](#h.500jynxuxkms). The ToIP stack is a dual stack consisting of two halves: the [ToIP Technology Stack](#h.9looruc0w4ac) and the [ToIP Governance Stack](#h.ciwa0pidrb2e). The four layers in the ToIP stack are [ToIP Layer 1](#h.24ggrl8oz4ma), [ToIP Layer 2](#h.ikqr9hyt133k), [ToIP Layer 3](#h.7rbvlbpp8vwp), and [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+For more information, see: [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm), [ToIP Governance Architecture Specification](#h.1aa10hjxxqo3).
+
+ToIP system
+
+A computing system that participates in the [ToIP Technology Stack](#h.9looruc0w4ac). There are three types of ToIP systems: [endpoint systems](#h.scy14dobg777), [intermediary systems](#h.i4pfys3yiku), and [supporting systems](#h.nqtdtghyfspz).
+
+For more information, see: [Section 6.3](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2363-high-level-system-architecture&sa=D&source=editors&ust=1718703186841331&usg=AOvVaw3QjJFkhLaKImWzycwIG8cH) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+ToIP trust network
+
+A [trust network](#h.iy4t4brzsjkb) implemented using the [ToIP stack](#h.wms58fgdch9m).
+
+ToIP Technology Architecture Specification
+
+The [technical specification](#h.u62ak0cgfdb1) defining the [requirements](#h.ajxlw8r3dvcc) for the [ToIP Technology Stack](#h.9looruc0w4ac) published by the [ToIP Foundation](#h.500jynxuxkms).
+
+For more information: [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+ToIP Technology Stack
+
+The technology half of the four layer [ToIP stack](#h.wms58fgdch9m) as defined by the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+See also: [ToIP Governance Stack](#h.ciwa0pidrb2e), [ToIP layer](#h.k5gg61txum2c).
+
+ToIP trust community
+
+A [trust community](#h.a9l3odcb1s29) governed by a [ToIP governance framework](#h.ns22ebn9xjun).
+
+ToIP Trust Registry Protocol
+
+The open standard [trust task protocol](#h.uo2gx58kwj2o) defined by the [ToIP Foundation](#h.500jynxuxkms) to perform the [trust task](#h.vzu8kc1yz84q) of querying a [trust registry](#h.5kzln6m5e8j5). The ToIP Trust Registry Protocol operates at [Layer 3](#h.b72avxgmeyfo) of the [ToIP stack](#h.wms58fgdch9m).
+
+ToIP Trust Spanning Protocol
+
+The ToIP Layer 2 protocol for [verifiable messaging](#h.7zrsx7mki2fr) that implements the [trust spanning layer](#h.k9uiol17u620) of the [ToIP stack](#h.wms58fgdch9m).  The ToIP Trust Spanning Protocol enables [actors](#h.gzdfngxkp0ip) in different digital [trust domains](#h.60miqe21hd5h) to interact in a similar way to how the Internet Protocol (IP) enables devices on different local area networks to exchange data.
+
+Mental model: [hourglass model,](#h.u8d1rxc2o86) see the [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf&sa=D&source=editors&ust=1718703186845093&usg=AOvVaw2OdtZNJIngp7qyOGhwsAqf).
+
+For more information, see: [Section 7.3](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2373-layer-2-trust-spanning&sa=D&source=editors&ust=1718703186845538&usg=AOvVaw1hU_wKPSeewSeBGelbHYl5) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm) and the [Trust Spanning Protocol Task Force](https://www.google.com/url?q=https://wiki.trustoverip.org/display/HOME/ToIP%2BTrust%2BSpanning%2BProtocol%2BSpecification&sa=D&source=editors&ust=1718703186845871&usg=AOvVaw073rjCIFI_izeotXCMg_Q6).
+
+transaction
+
+A discrete event between a user and a system that supports a business or programmatic purpose. A digital system may have multiple categories or types of transactions, which may require separate analysis within the overall digital identity [risk assessment](#h.91ipsr7y3vb6).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/transaction&sa=D&source=editors&ust=1718703186846516&usg=AOvVaw08URSpX_9ifyEw-nrM-c6t).
+
+See also: [connection](#h.thbpewq1px8x).
+
+Supporting definitions:
+
+eSSIF-Lab: the exchange of goods, services, funds, or data between some [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186847031&usg=AOvVaw1SO0tdAmUM4Ug6YIbcTF9Z) (called [participants](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/participant&sa=D&source=editors&ust=1718703186847274&usg=AOvVaw1ujfn9Cx1HlddOLY79dMG3) of the [transaction](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/transaction&sa=D&source=editors&ust=1718703186847491&usg=AOvVaw04hyNXMO3_G5GGzZFl0bol)).
+
+transitive trust decision
+
+A [trust decision](#h.m8c86ccqis9r) made by a [first party](#h.uxx5bjam20ag) about a [second party](#h.hk94wskqnzri) or another [entity](#h.5imtbzl1f4xo) based on information about the [second party](#h.hk94wskqnzri) or the other [entity](#h.5imtbzl1f4xo) that is obtained from one or more [third parties](#h.zu2vj8151tr).
+
+Note: A primary purpose of [digital credentials](#h.ddna9lucn4k6), [chained credentials](#h.wjc1hh3dzgc7), and [trust registries](#h.5kzln6m5e8j5) is to facilitate transitive trust decisions.
+
+For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186848741&usg=AOvVaw0x4Pvc3qqGt7AKofI7sV78).
+
+Transmission Control Protocol
+
+The Transmission Control Protocol (TCP) is one of the main protocols of the [Internet protocol suite](#h.oj5ut8qopq0w). It originated in the initial network implementation in which it complemented the [Internet Protocol](#h.jmao5ngtvqnm) (IP). Therefore, the entire suite is commonly referred to as [TCP/IP](#h.txn6vkany9z9). TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. [SSL/TLS](#h.6hbp4j6qy89) often runs on top of TCP.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Transmission_Control_Protocol&sa=D&source=editors&ust=1718703186850002&usg=AOvVaw14as7a3Oa3YEBMnrdflgyI).
+
+Also known as: [TCP](#h.6ztn6qj1hrax).
+
+See also: [User Datagram Protocol](#h.di36optpv6sl).
+
+Transport Layer Security
+
+Transport Layer Security (TLS) is a cryptographic protocol designed to provide [communications](#h.w02a6srdng3j) security over a computer network. The protocol is widely used in applications such as email, instant messaging, and [Voice over IP](#h.k9c3o28fbg3b), but its use in securing HTTPS remains the most publicly visible. The TLS protocol aims primarily to provide security, including privacy ([confidentiality](#h.445sv27j3c2m)), integrity, and [authenticity](#h.pitlm5jn3v6u) through the use of cryptography, such as the use of [certificates](#h.vpsiiv68xxwc), between two or more communicating computer applications.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Transport_Layer_Security&sa=D&source=editors&ust=1718703186851595&usg=AOvVaw0uQxJzuq2uMY30-61wpmnF).
+
+Also known as: [TLS](#h.edtto4e17uc0).
+
+Note: TLS replaced the deprecated [Secure Sockets Layer](#h.gxktv8f54wc8) (SSL) protocol.
+
+tribal knowledge
+
+[Knowledge](#h.k96lktyswxnb) that is known within an “in-group” of people but unknown outside of it. A [tribe](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Tribe&sa=D&source=editors&ust=1718703186852516&usg=AOvVaw0ARx3otjHHXraMj5to1xCh), in this sense, is a group of people that share such a common [knowledge](#h.k96lktyswxnb).
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Tribal_knowledge&sa=D&source=editors&ust=1718703186852909&usg=AOvVaw2SZ26pLXdzmd9zOnt6V0Bk)
+
+trust
+
+A belief that an [entity](#h.5imtbzl1f4xo) will behave in a predictable manner in specified circumstances. The entity may be a person, process, object or any combination of such components. The entity can be of any size from a single hardware component or software module, to a piece of equipment identified by make and model, to a site or location, to an organization, to a nation-state. Trust, while inherently a subjective determination, can be based on objective evidence and subjective elements. The objective grounds for trust can include for example, the results of information technology product testing and evaluation. Subjective belief, level of comfort, and experience may supplement (or even replace) objective evidence, or substitute for such evidence when it is unavailable. Trust is usually relative to a specific circumstance or situation (e.g., the amount of money involved in a transaction, the sensitivity or criticality of information, or whether safety is an issue with human lives at stake). Trust is generally not transitive (e.g., you trust a friend but not necessarily a friend of a friend). Finally, trust is generally earned, based on experience or measurement.
+
+Source: [NIST Special Publication 800-39](https://www.google.com/url?q=https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf&sa=D&source=editors&ust=1718703186853623&usg=AOvVaw3pynzcDpzNF_6mmuJSYyqi) p.24
+
+See also: [transitive trust decision](#h.syc9o7x61rkm).
+
+For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186854119&usg=AOvVaw3kfUSaa0Dr-slVXeIOkkQS).
+
+trust anchor
+
+See: [trust root](#h.vfnyletkzjv5).
+
+Note: The term “trust anchor” is most commonly used in cryptography and [public key infrastructure](#h.mdxu5kpbdo4x).
+
+trust application
+
+An application that runs at [ToIP Layer 4](#h.ym4v87xpn7gq) in order to perform [trust tasks](#h.vzu8kc1yz84q) or engage in other [verifiable messaging](#h.7zrsx7mki2fr) using the [ToIP stack](#h.wms58fgdch9m).
+
+trust application layer
+
+In the context of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186855394&usg=AOvVaw26n_m9uRYzJMW6TXU2HuHp), the [trust application](#h.3pfn27y1gu2o) layer is [ToIP Layer 4](#h.ym4v87xpn7gq). Applications running at this layer call [trust task protocols](#h.uo2gx58kwj2o) at [ToIP Layer 3](#h.7rbvlbpp8vwp).
+
+trust assurance
+
+A process that provides a [level of assurance](#h.qseghs6dqcd) sufficient to make a particular [trust decision](#h.m8c86ccqis9r).
+
+trust basis
+
+The [properties](#h.c8vs1xa4uwn) of a [verifiable identifier](#h.wyda231qefe) or a [ToIP system](#h.jxcr1cndl4co) that enable a [party](#h.cn6bno48fomj) to [appraise](#h.wtzlm8ocwx7a) it to determine a [trust limit](#h.bceor3akx4ko).
+
+See also: [appraisability](#h.wtzlm8ocwx7a).
+
+trust boundary
+
+The border of a [trust domain](#h.60miqe21hd5h).
+
+trust chain
+
+A set of [cryptographically verifiable](#h.422iwwfur12) links between [digital credentials](#h.ddna9lucn4k6) or other [data](#h.o783ayrrkc6g) containers that enable [transitive trust decisions](#h.syc9o7x61rkm).
+
+See also: [chained credentials](#h.wjc1hh3dzgc7), [trust graph](#h.eqx98nkqjzsv).
+
+For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186857350&usg=AOvVaw0aO9AEwXL5ArJGUP9X7Twv).
+
+trust community
+
+A set of [parties](#h.cn6bno48fomj) who collaborate to achieve a mutual set of [trust objectives](#h.jxinqtx7eiev).
+
+See also: [digital trust ecosystem](#h.h47f86smlz4y), [ToIP trust community](#h.psztqwnbl6o7).
+
+Note: A trust community may be large or small, formal or informal. In a formal trust community, the set of [policies](#h.udts41hso4w4) and [rules](#h.v7s575ulon74) governing behavior of members are usually published in a [governance framework](#h.2x05z0r097mn) or [trust framework](#h.2r5mn949idq). In an informal trust community, the policies or rules governing the behavior of members may be [tribal knowledge](#h.musmuniitirr).
+
+trust context
+
+The context in which a specific [party](#h.cn6bno48fomj) makes a specific [trust decision](#h.m8c86ccqis9r). Many different factors may be involved in establishing a trust context, such as: the relevant interaction or transaction; the presence or absence of existing [trust relationships](#h.pu2asd79bqzo); the applicability of one or more [governance frameworks](#h.2x05z0r097mn); and the location, time, network, and/or devices involved. A trust context may be implicit or explicit; if explicit, it may be identified using an [identifier](#h.u3bfehmj4ed3). A [ToIP governance framework](#h.ns22ebn9xjun) an example of an explicit trust context identified by a [ToIP identifier](#h.xtyidw4bnytz).
+
+See also: [trust domain](#h.60miqe21hd5h).
+
+For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186859065&usg=AOvVaw25UfQhXCANoYHMedq0uI-j).
+
+trust decision
+
+A decision that a [party](#h.cn6bno48fomj) needs to make about whether to engage in a specific interaction or [transaction](#h.92pu88ke4p7k) with another [entity](#h.5imtbzl1f4xo) that involves real or perceived [risks](#h.qzpr4qua4ble).
+
+See also: [transitive trust decision](#h.syc9o7x61rkm).
+
+For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186859782&usg=AOvVaw3tX38JsIUaLnXn1kFV9gvK).
+
+trust domain
+
+A [security domain](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.d7ry9j100f36&sa=D&source=editors&ust=1718703186860091&usg=AOvVaw1bBvm_wnDReJKGsNQuFwKf) defined by a computer hardware or software architecture, a [security policy](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2fcbwog0w43a&sa=D&source=editors&ust=1718703186860290&usg=AOvVaw1g4Nwp50asW6f6Aewc8F4C), or a [trust community](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.a9l3odcb1s29&sa=D&source=editors&ust=1718703186860460&usg=AOvVaw2Wn1aWOZ-5TMhA5pUMV5Y-), typically via a [trust framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2r5mn949idq&sa=D&source=editors&ust=1718703186860639&usg=AOvVaw2nQ7qkp4lO37V1XOSo2wM9) or [governance framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2x05z0r097mn&sa=D&source=editors&ust=1718703186860882&usg=AOvVaw1QpAmZuJ3ggW1lsIa-PVS2).
+
+See also: [trust context](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.xc1hsb1i8vdu&sa=D&source=editors&ust=1718703186861139&usg=AOvVaw2gDLV4K0G6q2ss6zUhdrpN), [digital trust ecosystem](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.h47f86smlz4y&sa=D&source=editors&ust=1718703186861342&usg=AOvVaw1EiGJFviUEkKlHbwma9l4n).
+
+trust ecosystem
+
+See [digital trust ecosystem](#h.h47f86smlz4y).
+
+trust establishment
+
+The process two or more [parties](#h.cn6bno48fomj) go through to establish a [trust relationship](#h.pu2asd79bqzo). In the context of decentralized digital trust infrastructure, trust establishment takes place at two levels. At the [technical trust](#h.7vxscxecc0g) level, it includes some form of [key establishment](#h.pkh9vfulrizg). At the [human trust](#h.a4jfn38wd17o) level, it may be accomplished via an [out-of-band introduction](#h.tsslu4lnog0s), the exchange of [digital credentials](#h.ddna9lucn4k6), queries to one or more [trust registries](#h.5kzln6m5e8j5), or evaluation of some combination of [human-readable](#h.ywyofmy4do4t) and [machine-readable](#h.8s3s84fzcfi3) [governance frameworks](#h.2x05z0r097mn).
+
+trust framework
+
+A term (most frequently used in the [digital identity](#h.r5y8zwxvzyd3) industry) to describe a [governance framework](#h.2x05z0r097mn) for a [digital identity](#h.r5y8zwxvzyd3) system, especially a [federation](#h.7ph0icfh463b).
+
+trust graph
+
+A [data](#h.o783ayrrkc6g) structure describing the [trust relationship](#h.pu2asd79bqzo) between two or more [entities](#h.5imtbzl1f4xo). A simple trust graph may be expressed as a [trust list](#h.f1feh0fmucqd). More complex trust graphs can be recorded or registered in and queried from a [trust registry](#h.5kzln6m5e8j5). Trust graphs can also be expressed via [trust chains](#h.xsqvwmepvctc) and [chained credentials](#h.wjc1hh3dzgc7). Trust graphs can enable [verifiers](#h.xfewd7t01hu0) to make [transitive trust decisions](#h.syc9o7x61rkm).
+
+See also: [authorization graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5tvkchqqqka8&sa=D&source=editors&ust=1718703186863358&usg=AOvVaw0Kq3a5UjwCqTBzdK4KkD7P), [governance graph](#h.u9xnz96ecf5x), [reputation graph](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.4wwkekt1wrs7&sa=D&source=editors&ust=1718703186863848&usg=AOvVaw3mR5tfs8cGPVGuXoRU46yg).
+
+trust limit
+
+A limit to the degree a [party](#h.cn6bno48fomj) is willing to trust an [entity](#h.5imtbzl1f4xo) in a specific [trust relationship](#h.pu2asd79bqzo) within a specific [trust context](#h.xc1hsb1i8vdu).
+
+For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186864695&usg=AOvVaw2oW-t5tUx1C3rN4m1LVVud).
+
+trust list
+
+A one-dimensional [trust graph](#h.eqx98nkqjzsv) in which an [authoritative source](#h.9tt1qpgdfnxs) publishes a list of [entities](#h.5imtbzl1f4xo) that are trusted in a specific [trust context](#h.xc1hsb1i8vdu). A trust list can be considered a simplified form of a [trust registry](#h.5kzln6m5e8j5).
+
+trust network
+
+A network of parties who are connected via [trust relationships](#h.pu2asd79bqzo) conforming to [requirements](#h.ajxlw8r3dvcc) defined in a legal regulation, [trust framework](#h.2r5mn949idq) or [governance framework](#h.2x05z0r097mn). A trust network is more formal than a [digital trust ecosystem](#h.h47f86smlz4y); the latter may connect parties more loosely via transitive trust relationships and/or across multiple trust networks.
+
+See also: [ToIP trust network](#h.xomvclbue1bi).
+
+trust objective
+
+An [objective](#h.k0v6ir8wmcav) shared by the [parties](#h.cn6bno48fomj) in a [trust community](#h.a9l3odcb1s29) to establish and maintain [trust relationships](#h.pu2asd79bqzo).
+
+Trust over IP
+
+A term coined by John Jordan to describe the decentralized digital trust infrastructure made possible by the [ToIP stack](#h.wms58fgdch9m). A play on the term Voice over IP (abbreviated VoIP).
+
+Also known as: [ToIP](#h.c9o3btot3dtb).
+
+trust registry
+
+A [registry](#h.farjhbxfa3lh) that serves as an [authoritative source](#h.9tt1qpgdfnxs) for [trust graphs](#h.eqx98nkqjzsv) or other [governed information](#h.g58y5pmth1sb) describing one or more [trust communities](#h.a9l3odcb1s29). A trust registry is typically [authorized](#h.gln5i78kxlfh) by a [governance framework](#h.2x05z0r097mn).
+
+See also: [trust list](#h.f1feh0fmucqd), [verifiable data registry](#h.q1dr1v2lltfe).
+
+trust registry protocol
+
+See: [ToIP Trust Registry Protocol](#h.1ma9v3f1h53f).
+
+trust relationship
+
+A relationship between a [party](#h.cn6bno48fomj) and an [entity](#h.5imtbzl1f4xo) in which the [party](#h.cn6bno48fomj) has decided to trust the [entity](#h.5imtbzl1f4xo) in one or more [trust contexts](#h.xc1hsb1i8vdu) up to a [trust limit](#h.bceor3akx4ko).
+
+Supporting definitions:
+
+[NIST](https://www.google.com/url?q=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf&sa=D&source=editors&ust=1718703186867386&usg=AOvVaw1khpSNxR4srFGgg8HHut4Z): An agreed upon relationship between two or more system elements that is governed by criteria for secure interaction, behavior, and outcomes relative to the protection of assets.
+
+For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186867753&usg=AOvVaw1aJOshXxHz_1NQSmnHG-vN).
+
+trust root
+
+The [authoritative source](#h.9tt1qpgdfnxs) that serves as the origin of a [trust chain](#h.xsqvwmepvctc).
+
+For more information, see: [Design Principles for the ToIP Stack](https://www.google.com/url?q=https://trustoverip.org/our-work/design-principles/&sa=D&source=editors&ust=1718703186868340&usg=AOvVaw3nEFuNNQ7nL_MA1LblhihR).
+
+trust service provider
+
+In the context of specific [digital trust ecosystems](#h.h47f86smlz4y), such as the European Union’s eIDAS regulations, a trust service provider (TSP) is a legal entity that provides specific [trust support](#h.451usstmcuuk) services as required by legal regulations, [trust frameworks](#h.2r5mn949idq), or [governance frameworks](#h.2x05z0r097mn). In the larger context of [ToIP](#h.nkx8p3tuemz) infrastructure, a TSP is a provider of services based on the [ToIP stack](#h.wms58fgdch9m). Most generally, a TSP is to the trust layer for the Internet what an Internet service provider (ISP) is to the Internet layer.
+
+Also known as: [TSP](#h.vlopzkfv2l6j).
+
+Supporting definitions:
+
+Wikipedia: A trust service provider (TSP) is a person or legal entity providing and preserving [digital certificates](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Digital_certificate&sa=D&source=editors&ust=1718703186869112&usg=AOvVaw0yKT2WH0yP7WL4uOzScMuh) to create and validate [electronic signatures](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_signature&sa=D&source=editors&ust=1718703186869284&usg=AOvVaw1XtLEkk9jhwffFzFvUTcnB) and to authenticate their signatories as well as websites in general. Trust service providers are qualified [certificate authorities](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Certificate_authority&sa=D&source=editors&ust=1718703186869459&usg=AOvVaw2Li-ZIRMYaiVH57OSAgL17) required in the [European Union](https://www.google.com/url?q=https://en.wikipedia.org/wiki/European_Union&sa=D&source=editors&ust=1718703186869614&usg=AOvVaw1Y790qcWQDS5vbpSroFo1E) and in Switzerland in the context of regulated [electronic signing](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Electronic_signature&sa=D&source=editors&ust=1718703186869767&usg=AOvVaw3GLECngygmR-eD-B2iVqTm) procedures.
+
+trust support
+
+A system, protocol, or other infrastructure whose function is to facilitate the establishment and maintenance of [trust relationships](#h.pu2asd79bqzo) at higher [protocol layers](#h.pe8dekl2dtq0). In the [ToIP stack](#h.wms58fgdch9m), the [trust support layer](#h.lk120yblym61) is [Layer 1](#h.v1hjglhanrdl).
+
+trust support layer
+
+In the context of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186870677&usg=AOvVaw04ulPHTfEl42uGmP65aj1e), the [trust support](#h.451usstmcuuk) layer is [ToIP Layer 1](#h.24ggrl8oz4ma). It supports the operations of the ToIP Trust Spanning Protocol at [ToIP Layer 2](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.ikqr9hyt133k&sa=D&source=editors&ust=1718703186871007&usg=AOvVaw054OXHrARD7c6_jy9_EzOv).
+
+trust spanning layer
+
+A [spanning layer](#h.wf49e15shob9) designed to span between different digital [trust domains](#h.60miqe21hd5h). In the [ToIP stack](#h.wms58fgdch9m), [ToIP Layer 2](#h.ikqr9hyt133k) is the trust spanning layer.
+
+See also: [ToIP layer](#h.k5gg61txum2c).
+
+Mental model: [hourglass model,](#h.u8d1rxc2o86) see [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm)
+
+For more information, see: [Section 7.3](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2373-layer-2-trust-spanning&sa=D&source=editors&ust=1718703186871868&usg=AOvVaw27wgRgYCypAUZN6-yocuzE) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+trust spanning protocol
+
+See: [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl).
+
+trust task
+
+A specific task that involves establishing, verifying, or maintaining [trust relationships](#h.pu2asd79bqzo) or exchanging [verifiable messages](#h.7zrsx7mki2fr) or [verifiable data](#h.7n80iyjxkofu) that can be performed on behalf of a [trust application](#h.3pfn27y1gu2o) by a [trust task protocol](#h.uo2gx58kwj2o) at [Layer 3](#h.7rbvlbpp8vwp) of the [ToIP stack](#h.wms58fgdch9m).
+
+For more information, see [Section 7.4](https://www.google.com/url?q=https://github.com/trustoverip/TechArch/blob/main/spec.md%2374-layer-3-trust-tasks&sa=D&source=editors&ust=1718703186872857&usg=AOvVaw1BZ0EhYn8xwMCrnfA79bxG) of the [ToIP Technology Architecture Specification](#h.bjv9ltwjbiqm).
+
+trust task layer
+
+In the context of the [ToIP stack](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.wms58fgdch9m&sa=D&source=editors&ust=1718703186873319&usg=AOvVaw2VFpNJ2ILRklH-8H6HAxnO), the [trust task](#h.vzu8kc1yz84q) layer is [ToIP Layer 3](#h.7rbvlbpp8vwp). It supports [trust applications](#h.3pfn27y1gu2o) operating at [ToIP Layer 4](#h.ym4v87xpn7gq).
+
+trust task protocol
+
+A [ToIP Layer 3](#h.7rbvlbpp8vwp) protocol that implements a specific [trust task](#h.vzu8kc1yz84q) on behalf of a [ToIP Layer 4](#h.ym4v87xpn7gq) [trust application](#h.3pfn27y1gu2o).
+
+trust triangle
+
+See: [three-party model](#h.2afq075qllho).
+
+trusted execution environment
+
+A trusted execution environment (TEE) is a secure area of a main processor. It helps code and data loaded inside it to be protected with respect to [confidentiality](#h.445sv27j3c2m) and [integrity](#h.n34avr5qvr0j). Data [integrity](#h.n34avr5qvr0j) prevents [unauthorized](#h.576ssfpt348i) [entities](#h.5imtbzl1f4xo) from outside the TEE from altering [data](#h.o783ayrrkc6g), while code integrity prevents code in the TEE from being replaced or modified by [unauthorized](#h.576ssfpt348i) [entities](#h.5imtbzl1f4xo), which may also be the computer [owner](#h.y450rpi0zmuu) itself as in certain [DRM](#h.m9um65bhu37) schemes.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Trusted_execution_environment&sa=D&source=editors&ust=1718703186874943&usg=AOvVaw11hnfqI2Ke3l2R26XibNoq).
+
+Also known as: [TEE](#h.4y1nwu52qx7g).
+
+See also: [Secure Enclave](#h.lf0txjgjs67z).
+
+trusted role
+
+A [role](https://www.google.com/url?q=http://role&sa=D&source=editors&ust=1718703186875423&usg=AOvVaw0eVbleRrk7b_Lue5xoW0Ju) that performs restricted activities for an [organization](#h.z27mp1358pi9) after meeting competence, security and background [verification](#h.2bnb6g8na7cu) [requirements](#h.ajxlw8r3dvcc) for that [role](#h.sf54cyuamo6x).
+
+trusted third party
+
+In [cryptography](#h.jhvr6rbo5z3q), a trusted [third party](#h.zu2vj8151tr) (TTP) is an entity which facilitates interactions between two [parties](#h.cn6bno48fomj) who both trust the third party; the third party reviews all critical transaction communications between the parties, based on the ease of creating fraudulent digital content. In TTP models, the [relying parties](#h.61sr3qnr1eci) use this trust to secure their own interactions. TTPs are common in any number of commercial transactions and in cryptographic digital transactions as well as cryptographic protocols, for example, a [certificate authority](#h.dm6pt5kg2uim) (CA) would issue a [digital certificate](#h.vpsiiv68xxwc) to one of the two parties in the next example. The CA then becomes the TTP to that certificate's issuance. Likewise transactions that need a third party recordation would also need a third-party repository service of some kind.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Trusted_third_party&sa=D&source=editors&ust=1718703186876246&usg=AOvVaw2M5cZs6ZnaxfZVghYOcSiW).
+
+Also known as: [TTP](#h.v0r7skqmr47v).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/trusted_third_party&sa=D&source=editors&ust=1718703186876602&usg=AOvVaw0_KAyVYHnDRuPPpLItufzn): A third party, such as a CA, that is trusted by its clients to perform certain services. (By contrast, the two participants in a key-establishment transaction are considered to be the first and second parties.)
+
+trusted timestamp authority
+
+An [authority](#h.gln5i78kxlfh) that is trusted to provide accurate time information in the form of a [timestamp](#h.7l3etghzasqf).
+
+Source: [NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/trusted_timestamp_authority&sa=D&source=editors&ust=1718703186877017&usg=AOvVaw1CMKnpTMTMmhLO6YEBeyh0).
+
+Also known as: [TTA](#h.xeindhl0hc8h).
+
+trustworthy
+
+A [property](#h.c8vs1xa4uwn) of an [entity](#h.5imtbzl1f4xo) that has the [attribute](#h.ky5nh3yri7ak) of [trustworthiness](#h.tnso3xyimmee).
+
+trustworthiness
+
+An [attribute](#h.ky5nh3yri7ak) of a [person](#h.yx4qb6dcjdvj) or [organization](#h.z27mp1358pi9) that provides confidence to others of the qualifications, capabilities, and reliability of that [entity](#h.5imtbzl1f4xo) to perform specific tasks and fulfill assigned responsibilities. Trustworthiness is also a characteristic of information technology products and systems. The attribute of trustworthiness, whether applied to people, processes, or technologies, can be measured, at least in relative terms if not quantitatively. The determination of trustworthiness plays a key role in establishing [trust relationships](#h.pu2asd79bqzo) among [persons](#h.yx4qb6dcjdvj) and [organizations](#h.z27mp1358pi9). The [trust relationships](#h.pu2asd79bqzo) are key factors in [risk decisions](#h.9g76xvrtlnqp) made by senior leaders/executives.
+
+Source: [NIST Special Publication 800-39](https://www.google.com/url?q=https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf&sa=D&source=editors&ust=1718703186878275&usg=AOvVaw1xs6G6xptG_tG4jD8ZWJwu) p.24
+
+TSP
+
+See: [trust service provider](#h.lob8zt6w1hh), [trust spanning protocol](#h.fnuaao3a1j25).
+
+TTA
+
+See: [trusted timestamp authority](#h.ryrs51vhrwny).
+
+TTP
+
+See: [trusted third party](#h.gzkj2oe82fof).
+
+UDP
+
+See: [User Datagram Protocol](#h.di36optpv6sl).
+
+unicast
+
+In computer networking, unicast is a one-to-one transmission from one point in the network to another point; that is, one sender and one receiver, each identified by a [network address](#h.v9gosdu5b7z5) (a [unicast address](#h.2p49ftuui3ug)). Unicast is in contrast to [multicast](#h.nopxfdr8qtr6) and [broadcast](#h.s1uti8f9ufsv) which are one-to-many transmissions. [Internet Protocol](#h.jmao5ngtvqnm) unicast delivery methods such as [Transmission Control Protocol](#h.4wb0yz8sizvi) (TCP) and [User Datagram Protocol](#h.di36optpv6sl) (UDP) are typically used.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Unicast&sa=D&source=editors&ust=1718703186879667&usg=AOvVaw1gW3_34PbJ1RGSQJATfysZ).
+
+See also: [anycast](#h.adr8osyk2zcx).
+
+unicast address
+
+A [network address](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.v9gosdu5b7z5&sa=D&source=editors&ust=1718703186880080&usg=AOvVaw13IOrY9iVIkwDpIJzxS23P) used for a [unicast](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.bqegn99wxkdi&sa=D&source=editors&ust=1718703186880320&usg=AOvVaw2d3AeF7SGUm0C9ydYMvPMg).
+
+user agent
+
+A [software agent](#h.qv9e403ohhxe) that is used directly by the end-user as the [principal](#h.sydbe7rk6244). Browsers, email clients, and [digital wallets](#h.sxnvf3f5v156) are all examples of user agents.
+
+Supporting definitions:
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User_agent&sa=D&source=editors&ust=1718703186880838&usg=AOvVaw0uNCIwfDgbiZzQAwt6opKv): On the [Web](https://www.google.com/url?q=https://en.wikipedia.org/wiki/World_Wide_Web&sa=D&source=editors&ust=1718703186881026&usg=AOvVaw2hQbjA12rIZ_7CMDLPmUNk), a user agent is a [software agent](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Software_agent&sa=D&source=editors&ust=1718703186881252&usg=AOvVaw1afT_WcB8GU36-ZrNHIcfv) capable of and responsible for retrieving and facilitating [end user](https://www.google.com/url?q=https://en.wikipedia.org/wiki/End_user&sa=D&source=editors&ust=1718703186881439&usg=AOvVaw3Sfas8dCU4__5OkNgmxsdz) interaction with Web content.[\[1\]](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User_agent%23cite_note-1&sa=D&source=editors&ust=1718703186881622&usg=AOvVaw3wDff_o701U63NMiK0lx-9) This includes all common [web browsers](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Web_browser&sa=D&source=editors&ust=1718703186881775&usg=AOvVaw29DVPm7q2h0clzIu9Tcby2), such as [Google Chrome](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Google_Chrome&sa=D&source=editors&ust=1718703186881954&usg=AOvVaw1nAe56OCiamvjvzl_Dlkfq), [Mozilla Firefox](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Mozilla_Firefox&sa=D&source=editors&ust=1718703186882142&usg=AOvVaw0dw0cODKFd9S2cJAuYUREa), and [Safari](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Safari_\(web_browser\)&sa=D&source=editors&ust=1718703186882339&usg=AOvVaw14uHb6Kvs248Iv3LsgK1cX), some [email clients](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Email_client&sa=D&source=editors&ust=1718703186882488&usg=AOvVaw2UzPxzSiemSYkiKlvxmMIr), standalone [download managers](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Download_manager&sa=D&source=editors&ust=1718703186882624&usg=AOvVaw1V5fENuaKMPip2U-Qa_kAI) like [youtube-dl](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Youtube-dl&sa=D&source=editors&ust=1718703186882762&usg=AOvVaw1dYGy0YHPxhcq_9CUCoz7i), other [command-line](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Command-line&sa=D&source=editors&ust=1718703186882966&usg=AOvVaw2ozTLryzvAvt8TvTNbcD_m) utilities like [cURL](https://www.google.com/url?q=https://en.wikipedia.org/wiki/CURL&sa=D&source=editors&ust=1718703186883167&usg=AOvVaw2X7NCoCCa3fV_05AYEd1cV), and arguably [headless](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Headless_software&sa=D&source=editors&ust=1718703186883376&usg=AOvVaw3nYeCW52FqlsdlGAoGglwT) [services](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Service_\(systems_architecture\)&sa=D&source=editors&ust=1718703186883569&usg=AOvVaw1ycBlYyxTG8dk4LUal69Rr) that power part of a larger application, such as a [web crawler](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Web_crawler&sa=D&source=editors&ust=1718703186883709&usg=AOvVaw3KYwsBW7XramXPoGABbc5W).
+
+The user agent plays the role of the [client](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Client_\(computing\)&sa=D&source=editors&ust=1718703186883938&usg=AOvVaw3W-es0kUNu-dfkHTdDRypC) in a [client–server system](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Client%25E2%2580%2593server_model&sa=D&source=editors&ust=1718703186884141&usg=AOvVaw2NWimbWNLAbw6qiiEgDP2w). The [HTTP](https://www.google.com/url?q=https://en.wikipedia.org/wiki/HTTP&sa=D&source=editors&ust=1718703186884346&usg=AOvVaw28eTdcVpdI1prdCCx_ae1m) [User-Agent header](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User-Agent_header&sa=D&source=editors&ust=1718703186884549&usg=AOvVaw1L_F3f8QNHsLL4nzB7CHvx) is intended to clearly identify the agent to the server. However, this header can be omitted or [spoofed](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User_agent_spoofing&sa=D&source=editors&ust=1718703186884741&usg=AOvVaw3JBY567x8Gg1Jzt53gCS_n), so some websites use [other agent detection methods](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Browser_sniffing&sa=D&source=editors&ust=1718703186884928&usg=AOvVaw0uAKVEpCqe3f1UZrR6hmup).
+
+User Datagram Protocol
+
+In computer networking, the User Datagram Protocol (UDP) is one of the core [communication](#h.w02a6srdng3j) protocols of the [Internet protocol suite](#h.oj5ut8qopq0w) used to send [messages](#h.bge7ubygwk2q) (transported as [datagrams](#h.mxq90rincwo) in [packets](#h.9hc1adgu2nrx)) to other hosts on an [Internet Protocol](#h.jmao5ngtvqnm) (IP) network. Within an IP network, UDP does not require prior communication to set up [communication channels](#h.oc2pelzel246) or data paths.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/User_Datagram_Protocol&sa=D&source=editors&ust=1718703186885768&usg=AOvVaw0gZAT2QNpuEZ-pmLgjgcd8).
+
+Also known as: [UDP](#h.o11assyhncpl).
+
+utility governance framework
+
+A [governance framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2x05z0r097mn&sa=D&source=editors&ust=1718703186886280&usg=AOvVaw1VdNcukdDikwBGz49HC7YX) for a [digital trust utility](#h.ou8opzfswu3c). A utility governance framework may be a component of or referenced by an [ecosystem governance framework](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.dkge5gglsmk3&sa=D&source=editors&ust=1718703186886518&usg=AOvVaw166evFLOs04YX3b8H5e8m1) or a [credential governance framework](#h.tlmucrcg1d6g).
+
+validation
+
+An [action](#h.l54nzmooy631) an [agent](#h.6xkhfkjpo6xg) (of a [principal](#h.sydbe7rk6244)) performs to determine whether a digital object or set of [data](#h.o783ayrrkc6g) meets the [requirements](#h.ajxlw8r3dvcc) of a specific [party](#h.cn6bno48fomj).
+
+See also: [verification](#h.2bnb6g8na7cu).
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23validate&sa=D&source=editors&ust=1718703186887405&usg=AOvVaw2MQCrM0n4yPW9voLhIvjkA): The act, by or on behalf of a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186887571&usg=AOvVaw3pZLMjtT9abLXyRFxP67Av), of determining whether or not that data is valid to be used for some specific purpose(s) of that [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186887775&usg=AOvVaw1ThMFpbnZbFSeJM65Z3XPK).
+
+[NIST:](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/validation&sa=D&source=editors&ust=1718703186887983&usg=AOvVaw1G5jbinLyqRJax-6HW7DZZ) Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled.
+
+vault
+
+See: [digital vault](#h.cz29glapo2tg).
+
+VC
+
+See: [verifiable credential](#h.co5algna3zkh).
+
+verifiability (of a digital object, claim, or assertion)
+
+The [property](#h.c8vs1xa4uwn) of a digital object, assertion, [claim](#h.akieli6njkk5), or [communication](#h.w02a6srdng3j), being [verifiable](#h.k2qmzn3tjzsl).
+
+See also:  [appraisability](#h.wtzlm8ocwx7a).
+
+verifiable
+
+In the context of digital [communications](#h.w02a6srdng3j) infrastructure, the ability to determine the [authenticity](#h.pitlm5jn3v6u) of a [communication](#h.w02a6srdng3j) (e.g., sender, contents, [claims](#h.akieli6njkk5), [metadata](#h.t63bf0ssndfd), provenance), or the underlying [sociotechnical](#h.wjui8ufitkkx) infrastructure (e.g., [governance](#h.2x05z0r097mn), [roles](#h.sf54cyuamo6x), [policies](#h.udts41hso4w4), [authorizations](#h.576ssfpt348i), [certifications](#h.ytzysnyu57ec)).
+
+See also: [appraisability (of a communications end-point)](#h.wtzlm8ocwx7a); [digital signature](#h.s93np0i5rcne).
+
+verifiable credential
+
+A standard data model and representation format for [cryptographically-verifiable](#h.422iwwfur12) [digital credentials](#h.ddna9lucn4k6) as defined by the [W3C Verifiable Credentials Data Model specification](#h.mitd3elf05tf).
+
+Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186889932&usg=AOvVaw0gHUoDqAMMiCoCAwbCZfJV)
+
+See also: [digital credential](#h.ddna9lucn4k6).
+
+Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186890311&usg=AOvVaw25djW09DwroeV0JBgb0RY1)
+
+Supporting definitions:
+
+[W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186890629&usg=AOvVaw3Gg9njWUHBD3NDC3v91csY): A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Verifiable credentials can be used to build [verifiable presentations](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-presentations&sa=D&source=editors&ust=1718703186890821&usg=AOvVaw3C_1dYcyfPRUj6fqfMJdyN), which can also be cryptographically verified. The [claims](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-claims&sa=D&source=editors&ust=1718703186890977&usg=AOvVaw04cJR9Co5od7ii8CwJIqN8) in a credential can be about different [subjects](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-subjects&sa=D&source=editors&ust=1718703186891144&usg=AOvVaw208udn9WqLk1kDfqcI1vy1).
+
+verifiable data
+
+Any digital [data](#h.o783ayrrkc6g) or object that is [digitally signed](#h.s93np0i5rcne) in such a manner that it can be [cryptographically verified](#h.422iwwfur12).
+
+Note: In the context of ToIP architecture, verifiable data is signed with the [cryptographic keys](#h.53rzpn1yn6q7) associated with the [ToIP identifier](#h.xtyidw4bnytz) of the data [controller](#h.gemoqe2m303z).
+
+verifiable data registry
+
+A [registry](#h.farjhbxfa3lh) that facilitates the creation, [verification](#h.2bnb6g8na7cu), updating, and/or deactivation of [decentralized identifiers](#h.x1jp59hgbk2l) and [DID documents](#h.yjwocacp570p). A verifiable data registry may also be used for other [cryptographically-verifiable](#h.422iwwfur12) data structures such as [verifiable credentials](#h.co5algna3zkh).
+
+Source: [W3C DID](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23terminology&sa=D&source=editors&ust=1718703186892259&usg=AOvVaw37-SgicwdzMu11510XCGRw)
+
+Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186892559&usg=AOvVaw1eoubEprJas4Ki3xXqizsb)
+
+See also: [authoritative source](#h.9tt1qpgdfnxs), [trust registry](#h.5kzln6m5e8j5), [system of record](#h.ceh3cl4l0xnp).
+
+For more information, see: the W3C Verifiable Credentials specification \[[VC-DATA-MODEL](https://www.google.com/url?q=https://www.w3.org/TR/did-core/%23bib-vc-data-model&sa=D&source=editors&ust=1718703186893012&usg=AOvVaw3nrsy8udZFRpYUa3mWVZeN)\].
+
+Note: There is an [earlier definition in the W3C VC 1.1. glossary](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186893264&usg=AOvVaw3za3qdlw9ok1JAwwD5HLvD) that is not as mature (it is not clear about the use of cryptographically verifiable data structures). We do not recommend that definition.
+
+verifiable identifier
+
+An [identifier](#h.u3bfehmj4ed3) over which the [controller](#h.gemoqe2m303z) can provide cryptographic [proof of control](#h.3ss2tnb5pf4s).
+
+See also: [decentralized identifier](#h.x1jp59hgbk2l), [autonomous identifier](#h.bz098kwwc559).
+
+verifiable message
+
+A [message](#h.bge7ubygwk2q) communicated as [verifiable data](#h.7n80iyjxkofu).
+
+See also: [ToIP messages](#h.5th2gmjr7ij) 
+
+verification
+
+An [action](#h.l54nzmooy631) an [agent](#h.6xkhfkjpo6xg) (of a [principal](#h.sydbe7rk6244)) performs to determine the [authenticity](#h.pitlm5jn3v6u) of a [claim](#h.akieli6njkk5) or other digital object using a [cryptographic key](#h.53rzpn1yn6q7).
+
+See also: [validation](#h.rbp41an0omv6).
+
+Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186895260&usg=AOvVaw3dblWGu-RF-_Xip41iQNBQ)
+
+Supporting definitions:
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23verify&sa=D&source=editors&ust=1718703186895660&usg=AOvVaw3Pzl9624fkDXgrOQimeIwc): The act, by or on behalf of a [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186895820&usg=AOvVaw096L_7J8dc0HUcLXKpTTHd), of determining whether that data is authentic (i.e. originates from the [party](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186895969&usg=AOvVaw0lAy_Qg2iwxGvCsxaUVt5T) that authored it), timely (i.e. has not expired), and conforms to other specifications that apply to its structure.
+
+verifier (of a claim or credential)
+
+A [role](#h.sf54cyuamo6x) an [agent](#h.6xkhfkjpo6xg) performs to perform [verification](#h.2bnb6g8na7cu) of one or more [proofs](#h.r2qw6757lopw) of the [claims](#h.akieli6njkk5) in a [digital credential](#h.ddna9lucn4k6).
+
+See also: [relying party](#h.61sr3qnr1eci); [issuer](#h.xyrplzbvtffq), [holder](#h.64mptmm24w7u).
+
+Mental model: [W3C Verifiable Credentials Data Model Roles & Information Flows](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23roles&sa=D&source=editors&ust=1718703186896852&usg=AOvVaw3ie9r_SPYWvX_tZbKKpf0Z)
+
+Supporting definitions:
+
+[W3C VC](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23terminology&sa=D&source=editors&ust=1718703186897262&usg=AOvVaw2UhFrxaWWtu7MitO1jhtXZ): A role an [entity](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-entities&sa=D&source=editors&ust=1718703186897490&usg=AOvVaw3XAB0NklqH3s5GVK7CUDff) performs by receiving one or more [verifiable credentials](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-credentials&sa=D&source=editors&ust=1718703186897705&usg=AOvVaw2X9Ge-WXRVee-8bRWOa4TV), optionally inside a [verifiable presentation](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/%23dfn-verifiable-presentations&sa=D&source=editors&ust=1718703186897932&usg=AOvVaw0VpqwC-jAo7BqkqUEXbHSO) for processing. Other specifications might refer to this concept as a [relying party](#h.61sr3qnr1eci).
+
+[eSSIF-Lab](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/essifLab-glossary%23verifier&sa=D&source=editors&ust=1718703186898364&usg=AOvVaw11fmOJ_Op-0h_8liBERMnW): a component that implements the [capability](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/capability&sa=D&source=editors&ust=1718703186898604&usg=AOvVaw1nviRRLhq2EOtulDHcWuEq) to request [peer agents](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/peer-agent&sa=D&source=editors&ust=1718703186898825&usg=AOvVaw1i_kbndpQnJCRIAqRcH9cD) to present (provide) data from credentials (of a specified kind, issued by specified [parties](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/party&sa=D&source=editors&ust=1718703186898994&usg=AOvVaw1GHulzONww2lHfFuTheBID)), and to verify such responses (check structure, signatures, dates), according to its [principal](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/principal&sa=D&source=editors&ust=1718703186899154&usg=AOvVaw2BUSgJW77W904G60g7K10_)'s [verifier policy](https://www.google.com/url?q=https://essif-lab.github.io/framework/docs/terms/verifier-policy&sa=D&source=editors&ust=1718703186899384&usg=AOvVaw2Z0AR7HxcG1ykKV2f4m-U-).
+
+[NIST:](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/verifier&sa=D&source=editors&ust=1718703186899614&usg=AOvVaw1HjEAyddvM4C-hF_Ti9akM) The entity that verifies the authenticity of a digital signature using the public key.
+
+VID
+
+See [​​verifiable identifier](#h.wyda231qefe).
+
+VID relationship
+
+The [communications](#h.w02a6srdng3j) relationship formed between two [VIDs](#h.qr5qljyd3se) using the [ToIP Trust Spanning Protocol](#h.6kyv8gxdd4sl). A particular feature of this protocol is its ability to establish as many VID relationships as needed to establish different [relationship contexts](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.2j6x3j2tgc4t&sa=D&source=editors&ust=1718703186900519&usg=AOvVaw0YNkhJfoy0tl8aWYrhgY9-) between the communicating [entities](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.5imtbzl1f4xo&sa=D&source=editors&ust=1718703186900766&usg=AOvVaw2XMxnN1gK__Fr3uuGi-TUC).
+
+VID-to-VID
+
+The specialized type of [peer-to-peer](#h.ikjsqxobvozv) [communications](#h.w02a6srdng3j) enabled by the [ToIP Trust Spanning Protocol](https://www.google.com/url?q=https://docs.google.com/document/d/1fZByfuSOwszDRkE7ARQLeElSYmVznoOyJK4sxRvJpyM/edit?pli%3D1%23heading%3Dh.6kyv8gxdd4sl&sa=D&source=editors&ust=1718703186901214&usg=AOvVaw2rDfSE4QUmX5LVdZ75ydZ8). Each pair of VIDs creates a unique [VID relationship](#h.b3tilu21ql66).
+
+virtual vault
+
+A [digital](#h.cz29glapo2tg) [vault](#h.cz29glapo2tg) enclosed inside another [digital vault](#h.cz29glapo2tg) by virtue of having its own [verifiable identifier](#h.wyda231qefe) (VID) and its own set of [encryption](#h.iyq318f2vg61) [keys](#h.bk8tq6m7ylyl) that are separate from those used to unlock the enclosing vault.
+
+Voice over IP
+
+Voice over Internet Protocol (VoIP), also called IP telephony, is a method and group of technologies for voice calls for the delivery of voice [communication](#h.w02a6srdng3j) sessions over [Internet Protocol](#h.jmao5ngtvqnm) (IP) networks, such as the Internet.
+
+Also known as: [VoIP](#h.uc1cvjmqqq0u).
+
+VoIP
+
+See: [Voice over IP](#h.k9c3o28fbg3b).
+
+W3C Verifiable Credentials Data Model Specification
+
+A W3C Recommendation defining a standard data model and representation format for [cryptographically-verifiable](#h.422iwwfur12) [digital credentials](#h.ddna9lucn4k6). Version 1.1 was published on 03 March 2022.
+
+For more information, see: [https://www.w3.org/TR/vc-data-model/](https://www.google.com/url?q=https://www.w3.org/TR/vc-data-model/&sa=D&source=editors&ust=1718703186902762&usg=AOvVaw3f-vj70MyrOBmHgFL0kz7Q) 
+
+wallet
+
+See: [digital wallet](#h.sxnvf3f5v156).
+
+wallet engine
+
+The set of software components that form the core of a [digital wallet](#h.sxnvf3f5v156), but which by themselves are not sufficient to deliver a fully functional wallet for use by a [digital agent](#h.z3ugzt4hgdf6) (of a [principal](#h.sydbe7rk6244)). A wallet engine is to a [digital wallet](#h.sxnvf3f5v156) what a [browser engine](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Browser_engine&sa=D&source=editors&ust=1718703186903414&usg=AOvVaw0rj8PbDRldoIBFi2iV8K7E) is to a web browser.
+
+For more information: The charter of the [OpenWallet Foundation](#h.271hay7m0g55) is to produce an open source [digital wallet](#h.sxnvf3f5v156) engine.
+
+witness
+
+A computer system that receives, [verifies](#h.xfewd7t01hu0), and stores [proofs](#h.r2qw6757lopw) of [key events](#h.w6skxxfqgbqp) for a [verifiable identifier](#h.wyda231qefe) (especially an [autonomous identifier](#h.bz098kwwc559)). Each witness controls its own [verifiable identifier](#h.wyda231qefe) used to sign [key event](#h.w6skxxfqgbqp) messages stored by the witness. A witness may use any suitable computer system or database architecture, including a file, centralized database, distributed database, [distributed ledger](#h.eoh04mpatko3), or [blockchain](#h.bxz57auzxstx).
+
+Note: [KERI](#h.7pp65h7qs9lu) is an example of a [key management system](#h.q0w3jq78va39) that uses witnesses.
+
+zero-knowledge proof
+
+A specific kind of cryptographic [proof](#h.r2qw6757lopw) that proves facts about [data](#h.o783ayrrkc6g) to a [verifier](#h.xfewd7t01hu0) without revealing the underlying [data](#h.o783ayrrkc6g) itself. A common example is proving that a person is over or under a specific age without revealing the person’s exact birthdate.
+
+Also known as: zero-knowledge protocol.
+
+Supporting definitions:
+
+[Ethereum:](https://www.google.com/url?q=https://ethereum.org/en/zero-knowledge-proofs/&sa=D&source=editors&ust=1718703186904889&usg=AOvVaw1HGIxXCnaOWvdwxNDLU5F-) A zero-knowledge proof is a way of proving the validity of a statement without revealing the statement itself.
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Zero-knowledge_proof&sa=D&source=editors&ust=1718703186905130&usg=AOvVaw15YjypJZ8t5MboU3IyXmrt): a method by which one [party](#h.cn6bno48fomj) (the prover) can prove to another party (the verifier) that a given statement is true, while avoiding conveying to the [verifier](#h.xfewd7t01hu0) any information beyond the mere fact of the statement's truth.
+
+zero-knowledge service
+
+In cloud computing, the term “zero-knowledge” refers to an online service that stores, transfers or manipulates [data](#h.o783ayrrkc6g) in a way that maintains a high level of [confidentiality](#h.445sv27j3c2m), where the data is only accessible to the [data's](#h.o783ayrrkc6g) [owner](#h.y450rpi0zmuu) (the client), and not to the service provider. This is achieved by [encrypting](#h.iyq318f2vg61) the raw data at the client's side or [end-to-end](#h.q2kyp3tnhmic) (in case there is more than one client), without disclosing the password to the service provider. This means that neither the service provider, nor any [third party](#h.zu2vj8151tr) that might intercept the [data](#h.o783ayrrkc6g), can [decrypt](#h.fuc05ut9lwmq) and access the [data](#h.o783ayrrkc6g) without prior permission, allowing the client a higher degree of privacy than would otherwise be possible. In addition, zero-knowledge services often strive to hold as little [metadata](#h.t63bf0ssndfd) as possible, holding only that [data](#h.o783ayrrkc6g) that is functionally needed by the service.
+
+Source: [Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Zero-knowledge_service&sa=D&source=editors&ust=1718703186906478&usg=AOvVaw0AR-0F29RWRL7COnn5EosR).
+
+Also known as: no knowledge, zero access.
+
+zero-knowledge service provider
+
+The provider of a [zero-knowledge service](#h.lwi61cg5ym5c) that hosts [encrypted](#h.iyq318f2vg61) [data](#h.o783ayrrkc6g) on behalf of the [principal](#h.sydbe7rk6244) but does not have access to the [private keys](#h.74y9dvxzg24c) in order to be able to [decrypt](#h.fuc05ut9lwmq) it.
+
+zero-trust architecture
+
+A network security architecture based on the core design principle “never trust, always verify”, so that all [actors](#h.gzdfngxkp0ip) are denied access to resources pending [verification.](#h.2bnb6g8na7cu)
+
+Also known as: zero-trust security, perimeterless security.
+
+Contrast with: [attribute-based access control](#h.ckr2atznm0o), [role-based access control](#h.isj9yeecvwmw).
+
+Supporting definitions:
+
+[NIST-CSRC](https://www.google.com/url?q=https://csrc.nist.gov/glossary/term/zero_trust_architecture&sa=D&source=editors&ust=1718703186907573&usg=AOvVaw1cUreVMcJJt1iegQ0qgOoH): A security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The zero trust security model eliminates implicit trust in any one element, component, node, or service and instead requires continuous verification of the operational picture via real-time information from multiple sources to determine access and other system responses.
+
+[Wikipedia](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Zero_trust_security_model&sa=D&source=editors&ust=1718703186907834&usg=AOvVaw3K8uSSwQ9HUWp70rHUQxCQ): The zero trust security model, also known as zero trust architecture (ZTA), and sometimes known as perimeterless security, describes an approach to the strategy, design and implementation of [IT systems](https://www.google.com/url?q=https://en.wikipedia.org/wiki/IT_system&sa=D&source=editors&ust=1718703186908028&usg=AOvVaw0Qti3Ur_bJE-xEyDmcHh6O). The main concept behind the zero trust security model is "never trust, always verify," which means that users and devices should not be trusted by default, even if they are connected to a permissioned network such as a corporate [LAN](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Local_area_network&sa=D&source=editors&ust=1718703186908216&usg=AOvVaw39wg7oQ_ZLGPSPk5zPEKe0) and even if they were previously verified.
+
+ZKP
+
+See: [zero-knowledge proof](#h.zc9pf8eexjs).
+
+[\[a\]](#cmnt_ref1)@christine.martin@continuumloop.com you're good to go - start moving this to a 
+
+https://github.com/trustoverip/ctwg-main-glossary
+
+put the content in specs/terms\_and\_definitions.md
+
+ping me with questions.
+
+\_Assigned to christine.martin@continuumloop.com\_
+
+[\[b\]](#cmnt_ref2)focus on the terms - do \[\[def: first, then see how many \[\[ref: you can get done.
+
+[\[c\]](#cmnt_ref3)Christine, I had forgotten this link. Just added it now.
+
+[\[d\]](#cmnt_ref4)definition no longer in document
+
+[\[e\]](#cmnt_ref5)My bad. As you can tell, aligning terms with the ToIP Technology Architecture Specification was the last step I took, and when I did that, I didn't check to see where I had used the old terms. I fixed this.
+
+
+
+
+---
+title: External Nist Glossary
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-nist/index
+  md: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-nist/index.md
+---
+
+# External Nist Glossary
+
+\[ [A](#ADC) | [B](#BFT) | [C](#CBOR) | [D](#DAG) | [E](#undefined) | [F](#undefined) | [G](#undefined) | [H](#HSM) | [I](#IANA) | [J](#JOSE) | [K](#key) | [L](#undefined) | [M](#MFA) | [N](#NFT) | [O](#undefined) | [P](#P2P) | [Q](#undefined) | [R](#revocation) | [S](#SAD) | [T](#TCP) | [U](#UI) | [V](#VC) | [W](#witness) | [X](#undefined) | [Y](#undefined) | [Z](#undefined) \]
+
+ADC
+
+Term found but the definition does not exist yet.
+
+agency
+
+Any executive department, military department, government corporation, government controlled corporation, or other establishment in the executive branch of the government (including the Executive Office of the President), or any independent regulatory agency, but does not include: (i) the Government Accountability Office; (ii) the Federal Election Commission; (iii) the governments of the District of Columbia and of the territories and possessions of the United States, and their various subdivisions; or (iv) government-owned contractor-operated facilities, including laboratories engaged in national defense research and production activities.
+
+AID
+
+A globally unique identifier of a card application as defined in ISO/IEC 7816-4.
+
+API
+
+A system access point or library function that has a well-defined syntax and is accessible from application programs or user code to provide well-defined functionality.
+
+authenticity
+
+The property of being genuine and being able to be verified and trusted; confidence in the validity of a transmission, a message, or message originator
+
+BFT
+
+Term found but the definition does not exist yet.
+
+binding
+
+Process of associating two related elements of information.
+
+CBOR
+
+Term found but the definition does not exist yet.
+
+claim
+
+A true-false statement about the limitations on the values of an unambiguously defined property called the claims property; and limitations on the uncertainty of the propertys values falling within these limitations during the claims duration of applicability under stated conditions.
+
+collision
+
+An event in which two different messages have the same message digest.
+
+credential
+
+Evidence attesting to ones right to credit or authority. In this Standard, it is the PIV Card or derived PIV credential associated with an individual that authoritatively binds an identity (and, optionally, additional attributes) to that individual.
+
+CRUD
+
+Term found but the definition does not exist yet.
+
+CT
+
+A framework for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed in a manner that allows anyone to audit CA activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. (Experimental RFC 6962)
+
+DAG
+
+Term found but the definition does not exist yet.
+
+DAR
+
+Term found but the definition does not exist yet.
+
+DID
+
+Term found but the definition does not exist yet.
+
+domain
+
+A set of elements, data, resources, and functions that share a commonality in combinations of (1) roles supported, (2) rules governing their use, and (3) protection needs.
+
+HSM
+
+Term found but the definition does not exist yet.
+
+IANA
+
+Term found but the definition does not exist yet.
+
+identity
+
+Unique group element \\(0\\) for which \\(x+0=x\\) for each group element \\(x\\), relative to the binary group operator \\(+\\).
+
+issuer
+
+The organization that is issuing the PIV Card to an applicant. Typically, this is an organization for which the applicant is working.
+
+JOSE
+
+Term found but the definition does not exist yet.
+
+JSON
+
+Term found but the definition does not exist yet.
+
+key
+
+A parameter used in conjunction with a cryptographic algorithm that determines the specific operation of that algorithm.
+
+MFA
+
+Authentication using two or more factors to achieve authentication. Factors include: (i) something you know (e.g., password/personal identification number \[PIN\]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric).
+
+NFT
+
+An owned, transferable, and indivisible data record that is a digital representation of a physical or virtual linked asset. The data record is created and managed by a smart contract on a blockchain.
+
+P2P
+
+Term found but the definition does not exist yet.
+
+party
+
+An individual (person), organization, device, or a combination thereof. In this Recommendation, an entity may be a functional unit that executes certain processes.
+
+PGP
+
+Term found but the definition does not exist yet.
+
+PKI
+
+The architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a certificate-based public key cryptographic system. Framework established to issue, maintain, and revoke public key certificates.
+
+PRNG
+
+A deterministic computational process that has one or more inputs called "seeds", and it outputs a sequence of values that appears to be random according to specified statistical tests. A cryptographic PRNG has the additional property that the output is unpredictable, given that the seed is not known.
+
+revocation
+
+The process of permanently ending the binding between a certificate and the identity asserted in the certificate from a specified time forward.
+
+RID
+
+Term found but the definition does not exist yet.
+
+SAD
+
+Term found but the definition does not exist yet.
+
+salt
+
+As used in this Recommendation, a byte string (which may be secret or non-secret) that is used as a MAC key by either: 1) a MAC-based auxiliary function H employed in one-step key derivation or 2) a MAC employed in the randomness-extraction step during two-step key derivation.
+
+security
+
+A condition that results from the establishment and maintenance of protective measures that enable an organization to perform its mission or critical functions despite risks posed by threats to its use of systems. Protective measures may involve a combination of deterrence, avoidance, prevention, detection, recovery, and correction that should form part of the organizations risk management approach.
+
+sniffer
+
+See packet sniffer and passive wiretapping.
+
+SSI
+
+Term found but the definition does not exist yet.
+
+TCP
+
+TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees the delivery of data and also guarantees that packets will be delivered in the same order in which they were sent. 
+
+TEE
+
+An area or enclave protected by a system processor.
+
+TPM
+
+Term found but the definition does not exist yet.
+
+TSP
+
+Term found but the definition does not exist yet.
+
+UI
+
+The physical or logical means by which users interact with a system, device or process.
+
+URL
+
+A uniform resource locator, or URL, is a short string containing an address which refers to an object in the "web." URLs are a subset of URIs.
+
+VC
+
+Term found but the definition does not exist yet.
+
+VDS
+
+Term found but the definition does not exist yet.
+
+verifier
+
+An entity that verifies the claimants identity by verifying the claimants possession and control of a token using an authentication protocol. To do this, the Verifier may also need to validate credentials that link the token and identity and check their status.
+
+witness
+
+An appropriately cleared (if applicable) and designated individual, other than the COMSEC Account Manager, who observes and testifies to the inventory or destruction of COMSEC material.
+
+
+
+
+---
+title: External eSSIF-Lab Glossary
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-essiflab/index
+  md: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-essiflab/index.md
+---
+
+# External eSSIF-Lab Glossary
+
+\[ [A](#action) | [B](#undefined) | [C](#capability-of-an-actor) | [D](#data) | [E](#ecosystem) | [F](#framework-conceptual) | [G](#glossary) | [H](#holder-policy) | [I](#identification-pattern) | [J](#jurisdiction) | [K](#knowledge) | [L](#legal-entity) | [M](#management) | [N](#normative-framework) | [O](#objective) | [P](#partial-identity) | [Q](#qualified-data) | [R](#relation-between-concepts) | [S](#scope-essiflabterminology) | [T](#term-scoped) | [U](#undefined) | [V](#validate) | [W](#wallet-policy) | [X](#undefined) | [Y](#undefined) | [Z](#undefined) \]
+
+Action
+
+something that is actually done (a 'unit of work' that is executed) by a single [actor](https://essif-lab.github.io/framework/docs/terms/actor) (on behalf of a given [party](https://essif-lab.github.io/framework/docs/terms/party)), as a single operation, in a specific context.
+
+Actor
+
+entity that can act (do things/execute [action](https://essif-lab.github.io/framework/docs/terms/action)), e.g. people, machines, but not [organization](https://essif-lab.github.io/framework/docs/terms/organization).
+
+Advertisement
+
+an offer by a specific [party](https://essif-lab.github.io/framework/docs/terms/party) to provide a (type of) [credential](https://essif-lab.github.io/framework/docs/terms/credential), where the offer includes (a reference to) the syntax and semantics specifications of that [credential](https://essif-lab.github.io/framework/docs/terms/credential), and also lists various other characteristics that enable other [parties](https://essif-lab.github.io/framework/docs/terms/party) to decide whether or not a [credential](https://essif-lab.github.io/framework/docs/terms/credential) that the advertising [party](https://essif-lab.github.io/framework/docs/terms/party) has issued under this offer, is [valid](https://essif-lab.github.io/framework/docs/terms/validate) to be processed in one or more of its [information processes](https://essif-lab.github.io/framework/docs/terms/information-process).
+
+Agent
+
+an [actor](https://essif-lab.github.io/framework/docs/terms/actor) that is executing an [action](https://essif-lab.github.io/framework/docs/terms/action) on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party) (called the [principal](https://essif-lab.github.io/framework/docs/terms/principal) of that [actor](https://essif-lab.github.io/framework/docs/terms/actor)).
+
+Assertion
+
+a declaration/statement, made by a specific [party](https://essif-lab.github.io/framework/docs/terms/party), that something is the case.
+
+Assessment Framework
+
+the combination of a set of criteria that an auditor can assess by applying them to an [entity](https://essif-lab.github.io/framework/docs/terms/entity) (of a specific kind), and the procedures that this auditor will follow for doing so, for the purpose of establishing the extent in which that [entity](https://essif-lab.github.io/framework/docs/terms/entity) conforms to a stated set of requirements.
+
+Attribute
+
+[data](https://essif-lab.github.io/framework/docs/terms/data), that represents a characteristic that a [party](https://essif-lab.github.io/framework/docs/terms/party) (the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of the [attribute](https://essif-lab.github.io/framework/docs/terms/attribute)) has attributed to an [entity](https://essif-lab.github.io/framework/docs/terms/entity) (which is the [subject](https://essif-lab.github.io/framework/docs/terms/subject) of that attribute).
+
+Authority (Centralized or Decentralized)
+
+a [party](https://essif-lab.github.io/framework/docs/terms/party) of which certain decisions, ideas, rules etc. are followed by other [parties](https://essif-lab.github.io/framework/docs/terms/party).
+
+Capability (of an Actor)
+
+the potential of an [actor](https://essif-lab.github.io/framework/docs/terms/actor) to execute a (named) coherent set of [action](https://essif-lab.github.io/framework/docs/terms/action) (a 'function', or 'task') on behalf of some [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Capability (of a Party)
+
+the (named) combination of (a) the means of a specific [party](https://essif-lab.github.io/framework/docs/terms/party) to get something done, (b) the [party](https://essif-lab.github.io/framework/docs/terms/party) [governance](https://essif-lab.github.io/framework/docs/terms/governance) process that ensures that its (business) [policies](https://essif-lab.github.io/framework/docs/terms/policy) for getting that something done are being created and maintained, and (c) the [party](https://essif-lab.github.io/framework/docs/terms/party) [management](https://essif-lab.github.io/framework/docs/terms/management) process that creates and maintains the (operational) [policies](https://essif-lab.github.io/framework/docs/terms/policy), such that every [employee](https://essif-lab.github.io/framework/docs/terms/employee) that has a task in getting this something done can find and interpret a [policy](https://essif-lab.github.io/framework/docs/terms/policy) and use it as it executes [action](https://essif-lab.github.io/framework/docs/terms/action) in such tasks.
+
+Colleague
+
+two or more (digital or non-digital) [agent](https://essif-lab.github.io/framework/docs/terms/agent) that have the same [principal](https://essif-lab.github.io/framework/docs/terms/principal) (i.e. [party](https://essif-lab.github.io/framework/docs/terms/party) on whose behalf they are executing an [action](https://essif-lab.github.io/framework/docs/terms/action)).
+
+Commitment Decision
+
+the decision of that [party](https://essif-lab.github.io/framework/docs/terms/party) whether or not to commit to that [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction), i.e. (promise) to fulfill the [obligation](https://essif-lab.github.io/framework/docs/terms/obligation) that the associated [transaction agreement proposal](https://essif-lab.github.io/framework/docs/terms/transaction-proposal) would impose on that [party](https://essif-lab.github.io/framework/docs/terms/party) once it were signed.
+
+Communication Channel
+
+a (digital or non-digital) means by which two [actor](https://essif-lab.github.io/framework/docs/terms/actor) can exchange messages with one another.
+
+Communication Session
+
+a time interval during which two [actor](https://essif-lab.github.io/framework/docs/terms/actor) have an established [communication channel](https://essif-lab.github.io/framework/docs/terms/communication-channel) that does not exist outside of that time interval.
+
+Community
+
+a [party](https://essif-lab.github.io/framework/docs/terms/party), consisting of at least two different [parties](https://essif-lab.github.io/framework/docs/terms/party) (the members of the [community](https://essif-lab.github.io/framework/docs/terms/community)) that seek to collaborate with each other so that each of them can achieve its individual [objective](https://essif-lab.github.io/framework/docs/terms/objective) more efficiently and/or effectively.
+
+Compliance level
+
+a measure for stating how well an [entity](https://essif-lab.github.io/framework/docs/terms/entity) conforms with a stated (set of) requirement(s).
+
+Compliance management
+
+the process that is run by (or on behalf of) a specific [party](https://essif-lab.github.io/framework/docs/terms/party) for the purpose of [managing](https://essif-lab.github.io/framework/docs/terms/management) its [compliance objectives](https://essif-lab.github.io/framework/docs/terms/compliance-objective).
+
+Compliance Objective
+
+an [objective](https://essif-lab.github.io/framework/docs/terms/objective), owned by a [party](https://essif-lab.github.io/framework/docs/terms/party), that aims to reach and maintain a state of affairs in which a specific set of [entities](https://essif-lab.github.io/framework/docs/terms/entity) that this [party](https://essif-lab.github.io/framework/docs/terms/party) controls are in accordance with a specific set of requirements (e.g., laws, regulations, standards, etc.).
+
+Compliance
+
+the state of realization of a set of conformance criteria or normative framework of a [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Concept
+
+the ideas/thoughts behind a classification of [entities](https://essif-lab.github.io/framework/docs/terms/entity) (what makes [entities](https://essif-lab.github.io/framework/docs/terms/entity) in that class 'the same').
+
+Control level
+
+a measure for the efficiency and effectiveness in which a [control](https://essif-lab.github.io/framework/docs/terms/controller) produces the results specified by its [control objective](https://essif-lab.github.io/framework/docs/terms/control-objective)
+
+Control Objective
+
+an [objective](https://essif-lab.github.io/framework/docs/terms/objective), owned by a [party](https://essif-lab.github.io/framework/docs/terms/party), that aims to contribute to the realization of another (set of) [objective](https://essif-lab.github.io/framework/docs/terms/objective) of that [party](https://essif-lab.github.io/framework/docs/terms/party), by producing results that this [party](https://essif-lab.github.io/framework/docs/terms/party) needs to realize these other [objective](https://essif-lab.github.io/framework/docs/terms/objective).
+
+Control Process
+
+a process, [owned](https://essif-lab.github.io/framework/docs/terms/owned) and run by a [party](https://essif-lab.github.io/framework/docs/terms/party), to ensure that a specific subset of its control [objective](https://essif-lab.github.io/framework/docs/terms/objective) are realized.
+
+Control
+
+the combination of resources (e.g. people, tools, budgets, time) and processes that are tasked to realize a specific [control objective](https://essif-lab.github.io/framework/docs/terms/control-objective) of a particular [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Controller
+
+the role that an [actor](https://essif-lab.github.io/framework/docs/terms/actor) performs as it is executing actions on that [entity](https://essif-lab.github.io/framework/docs/terms/entity) for the purpose of ensuring that the [entity](https://essif-lab.github.io/framework/docs/terms/entity) will act/behave, or be used, in a particular way.
+
+Controllership
+
+the [capability](https://essif-lab.github.io/framework/docs/terms/capability) of an [actor](https://essif-lab.github.io/framework/docs/terms/actor) to execute [action](https://essif-lab.github.io/framework/docs/terms/action) on a specific [entity](https://essif-lab.github.io/framework/docs/terms/entity) for the purpose of ensuring that this [entity](https://essif-lab.github.io/framework/docs/terms/entity) will act/behave, or be used, in a particular way.
+
+Corpus of Terminology
+
+the documentation that describes the [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) around a set of [term](https://essif-lab.github.io/framework/docs/terms/term) and [concept](https://essif-lab.github.io/framework/docs/terms/concept).
+
+Credential Catalogue
+
+a functional component that has the [capability](https://essif-lab.github.io/framework/docs/terms/capability-of-an-actor) to register and advertise the information about [credential types](https://essif-lab.github.io/framework/docs/terms/credential-type) that their respective [governing parties](https://essif-lab.github.io/framework/docs/terms/governance) have decided to disclose so as to enable other [parties](https://essif-lab.github.io/framework/docs/terms/party) to decide whether or not it is beneficial for them to use [credential](https://essif-lab.github.io/framework/docs/terms/credential) of such types.
+
+Credential Type
+
+the specification of the contents, properties, constraints etc. that [credential](https://essif-lab.github.io/framework/docs/terms/credential) of this type must have/comply with.
+
+Credential
+
+data, representing a set of [assertion](https://essif-lab.github.io/framework/docs/terms/assertion) (claims, statements), authored and signed by, or on behalf of, a specific [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Data
+
+something (tangible) that can be used to communicate a meaning (which is intangible/information).
+
+Decentralized GRC Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain one's thinking about topics related to Governance, Risk management and Compliance (GRC) in a decentralized context, i.e., a context in which [parties](https://essif-lab.github.io/framework/docs/terms/party) all autonomously do their own GRC.
+
+Decentralized Risk Management Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how individual [parties](https://essif-lab.github.io/framework/docs/terms/party) can efficiently and effectively perform their own [risk management](https://essif-lab.github.io/framework/docs/terms/risk-management) processes, while taking into account that there are other [parties](https://essif-lab.github.io/framework/docs/terms/party) that have [expectations](https://essif-lab.github.io/framework/docs/terms/expectation) towards them.
+
+Decision Making Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [parties](https://essif-lab.github.io/framework/docs/terms/party) would, could, or should reason in order to reach good conclusions and make good decisions. This can be used as a basis for understanding the information needs of [parties](https://essif-lab.github.io/framework/docs/terms/party) as they need to decide e.g. whether or not to commit to a [Transaction](https://essif-lab.github.io/framework/docs/terms/transaction) proposal, or whether or not data is [valid](https://essif-lab.github.io/framework/docs/terms/validate) for some purpose. This pattern is based on [Toulmin's use of arguments](https://www.cambridge.org/core/books/uses-of-argument/26CF801BC12004587B66778297D5567C) (of which a pragmatical text can be found [here](https://owl.purdue.edu/owl/general_writing/academic_writing/historical_perspectives_on_argumentation/toulmin_argument.html))
+
+Decision
+
+the conclusion that a [party](https://essif-lab.github.io/framework/docs/terms/party) inferences from a set of [data](https://essif-lab.github.io/framework/docs/terms/data) that it considers to be facts.
+
+Define
+
+to provide a criterion and a [term](https://essif-lab.github.io/framework/docs/terms/term), where the criterion can be used by people to determine whether or not something is an instance/example of a [concept](https://essif-lab.github.io/framework/docs/terms/concept) (or other [semantic unit](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit)), and the [term](https://essif-lab.github.io/framework/docs/terms/term) is used to refer to that [concept](https://essif-lab.github.io/framework/docs/terms/concept), or an arbitrary instance thereof.
+
+Definition
+
+a text that helps [parties](https://essif-lab.github.io/framework/docs/terms/party) to have the same understanding about the meaning of (and [concept](https://essif-lab.github.io/framework/docs/terms/concept) behind) a [term](https://essif-lab.github.io/framework/docs/terms/term), ideally in such a way that these [parties](https://essif-lab.github.io/framework/docs/terms/party) can determine whether or not they make the same distinction.
+
+Definition Pattern
+
+a [mental model](https://essif-lab.github.io/framework/docs/terms/mental-model) that describes the relations between a [concept](https://essif-lab.github.io/framework/docs/terms/concept) (or any other [semantic unit](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit)), the [term(s)](https://essif-lab.github.io/framework/docs/terms/term) that are used to refer to it, and the criteria to use for determining whether or not something is an instance (example) of that [semantic unit](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit).
+
+Delegate
+
+the transferral of [ownership](https://essif-lab.github.io/framework/docs/terms/ownership) of one or more [obligation](https://essif-lab.github.io/framework/docs/terms/obligation) of a [party](https://essif-lab.github.io/framework/docs/terms/party) (the [delegator](https://essif-lab.github.io/framework/docs/terms/delegate)), including the associated accountability, to another [party](https://essif-lab.github.io/framework/docs/terms/party) (the [delegatee](https://essif-lab.github.io/framework/docs/terms/delegate))), which implies that the [delegatee](https://essif-lab.github.io/framework/docs/terms/delegate) can realize such [obligation](https://essif-lab.github.io/framework/docs/terms/obligation) as it sees fit.
+
+Dependent
+
+an [entity](https://essif-lab.github.io/framework/docs/terms/entity) for the caring for and/or protecting/guarding/defending of which a [guardianship arrangement](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement) has been established.
+
+Dictionary
+
+an alphabetically sorted list of [term](https://essif-lab.github.io/framework/docs/terms/term) with various meanings they may have in different contexts.
+
+Documentation Interoperability
+
+the property that a documentation system of making its content comprehensible for a variety of people that come from different backgrounds.
+
+Duties and Rights Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain what a generic duties and rights consists of (based on [Hofeld's theories](https://plato.stanford.edu/entries/rights/#FormRighHohfAnalSyst)), and relates it to [jurisdictions](https://essif-lab.github.io/framework/docs/terms/jurisdiction), [parties](https://essif-lab.github.io/framework/docs/terms/party) and [legal entities](https://essif-lab.github.io/framework/docs/terms/legal-entity).
+
+Ecosystem
+
+a set of at least two (autonomous) [parties](https://essif-lab.github.io/framework/docs/terms/party) (its 'members') whose individual work complements that of other members, and is of benefit to the set as a whole.
+
+Employee
+
+a (human or non-human (digital)) [actor](https://essif-lab.github.io/framework/docs/terms/actor) for whom/which it is realistic that it might execute [action](https://essif-lab.github.io/framework/docs/terms/action) on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party) (called the [employer](https://essif-lab.github.io/framework/docs/terms/employer) of that [actor](https://essif-lab.github.io/framework/docs/terms/actor)).
+
+Employer
+
+a [party](https://essif-lab.github.io/framework/docs/terms/party) on whose behalf a (human or non-human) [actor](https://essif-lab.github.io/framework/docs/terms/actor) (called an [employee](https://essif-lab.github.io/framework/docs/terms/employee) of that [party](https://essif-lab.github.io/framework/docs/terms/party)) might execute [action](https://essif-lab.github.io/framework/docs/terms/action).
+
+Employment Contract
+
+an agreement/contract between two [parties](https://essif-lab.github.io/framework/docs/terms/party), one of which controls a set of [actor](https://essif-lab.github.io/framework/docs/terms/actor) (the [subject](https://essif-lab.github.io/framework/docs/terms/subject) of the contract), that states (or refers to) all (sets of) rights and duties under which these [actor](https://essif-lab.github.io/framework/docs/terms/actor) can and/or must work for the other [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Entity
+
+someone or something that is known to exist.
+
+Scope: essifLabTerminology
+
+specification of the eSSIF-Lab scope.
+
+Expectation
+
+an [objective](https://essif-lab.github.io/framework/docs/terms/objective) that is [owned](https://essif-lab.github.io/framework/docs/terms/owned) by a [party](https://essif-lab.github.io/framework/docs/terms/party) for having a specific (set of) result(s) produced, where the actual production thereof is (going to be) outsourced to another [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Framework (Conceptual)
+
+a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality.
+
+Glossary
+
+an alphabetically sorted list of [term](https://essif-lab.github.io/framework/docs/terms/term) with the (single) meaning it has in (at least) one context.
+
+Governance and Management Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [parties](https://essif-lab.github.io/framework/docs/terms/party) organize that their [objectives](https://essif-lab.github.io/framework/docs/terms/objective) are realized, either by doing the associated work themselves, or by arranging for other [parties](https://essif-lab.github.io/framework/docs/terms/party) to do that.
+
+Governance
+
+the [act](https://essif-lab.github.io/framework/docs/terms/action) or process of governing or overseeing the realization of (the results associated with) a set of [objective](https://essif-lab.github.io/framework/docs/terms/objective) by the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of these [objective](https://essif-lab.github.io/framework/docs/terms/objective), in order to ensure they will be fit for the purposes that this [owner](https://essif-lab.github.io/framework/docs/terms/owner) intends to use them for.
+
+Governor
+
+a [role](https://essif-lab.github.io/framework/docs/terms/role) that a [party](https://essif-lab.github.io/framework/docs/terms/party) (better: [employee](https://essif-lab.github.io/framework/docs/terms/employee) of a specific [party](https://essif-lab.github.io/framework/docs/terms/party)) performs as it [governs](https://essif-lab.github.io/framework/docs/terms/governance) a (coherent) set of [expectation](https://essif-lab.github.io/framework/docs/terms/expectation) of that [party](https://essif-lab.github.io/framework/docs/terms/party), within a particular focus.
+
+Guardian
+
+a [party](https://essif-lab.github.io/framework/docs/terms/party) that has been assigned rights and duties in a [Guardianship Arrangement](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement) for the purpose of caring for and/or protecting/guarding/defending the [entity](https://essif-lab.github.io/framework/docs/terms/entity) that is the [dependent](https://essif-lab.github.io/framework/docs/terms/dependent) in that Guardianship Arrangement.
+
+Guardianship Arrangement
+
+guardianship Arrangement (in a Jurisdiction): the specification of a set of rights and duties between [legal entities](https://essif-lab.github.io/framework/docs/terms/legal-entity) of the [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) that enforces these rights and duties, for the purpose of caring for and/or protecting/guarding/defending one or more of these [entities](https://essif-lab.github.io/framework/docs/terms/legal-entity).
+
+Guardianship-type
+
+a class of [guardianship arrangements](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement) within the [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) that governs and manages them.
+
+Guardianship (in a Jurisdiction)
+
+the specification of a set of rights and duties between [legal entities](https://essif-lab.github.io/framework/docs/terms/legal-entity) of the [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) that enforces these rights and duties, for the purpose of caring for and/or protecting/guarding/defending one or more of these [entities](https://essif-lab.github.io/framework/docs/terms/legal-entity). (Synonym of [Guardianship Arrangement](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement))
+
+Guardianship Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain what a generic [guardianship](https://essif-lab.github.io/framework/docs/terms/guardianship-arrangement) consists of, and how it relates to [guardians](https://essif-lab.github.io/framework/docs/terms/guardian), [dependents](https://essif-lab.github.io/framework/docs/terms/dependent), [jurisdictions](https://essif-lab.github.io/framework/docs/terms/jurisdiction), etc.
+
+Holder Policy
+
+a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [holder](https://essif-lab.github.io/framework/docs/terms/holder) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+Holder
+
+a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to handle [presentation requests](https://essif-lab.github.io/framework/docs/terms/presentation-request) from a [peer agent](https://essif-lab.github.io/framework/docs/terms/peer-agent), produce the requested data (a presentation) according to its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [holder-policy](https://essif-lab.github.io/framework/docs/terms/holder-policy), and send that in response to the request.
+
+Human Being
+
+a person of flesh and blood (homo sapiens), that we classify both as a [party](https://essif-lab.github.io/framework/docs/terms/party),an [actor](https://essif-lab.github.io/framework/docs/terms/actor), and a [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction).
+
+Identification Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain the mechanisms that [parties](https://essif-lab.github.io/framework/docs/terms/party) may use to [identify](https://essif-lab.github.io/framework/docs/terms/identify) [entities](https://essif-lab.github.io/framework/docs/terms/entity), and mechanisms for communicating with another [parties](https://essif-lab.github.io/framework/docs/terms/party) such that both [parties](https://essif-lab.github.io/framework/docs/terms/party) can [identify](https://essif-lab.github.io/framework/docs/terms/identify) an [entity](https://essif-lab.github.io/framework/docs/terms/entity) and know whether or not they [identify](https://essif-lab.github.io/framework/docs/terms/identify) the same [entity](https://essif-lab.github.io/framework/docs/terms/entity).
+
+Identifier
+
+a character string that is being used for the identification of some [entity](https://essif-lab.github.io/framework/docs/terms/entity) (yet may refer to 0, 1, or more [entities](https://essif-lab.github.io/framework/docs/terms/entity), depending on the context within which it is being used).
+
+Identifier Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [identifiers](https://essif-lab.github.io/framework/docs/terms/identifier) are defined and used for [identification](https://essif-lab.github.io/framework/docs/terms/pattern-identification) purposes.
+
+Identify
+
+an [act](https://essif-lab.github.io/framework/docs/terms/action), by or on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party), that results in the selection of either
+
+Identity
+
+the combined [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) about that [entity](https://essif-lab.github.io/framework/docs/terms/entity) of all [parties](https://essif-lab.github.io/framework/docs/terms/party), i.e. the union of all [partial identities](https://essif-lab.github.io/framework/docs/terms/partial-identity) of which that [entity](https://essif-lab.github.io/framework/docs/terms/entity) is the [subject](https://essif-lab.github.io/framework/docs/terms/subject).
+
+Identity Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [digital identities](https://essif-lab.github.io/framework/docs/terms/identity) work, how this relates to (attributes in) [credentials](https://essif-lab.github.io/framework/docs/terms/credential), and how all this can be made to work in [SSI](https://essif-lab.github.io/framework/docs/terms/ssi) contexts.
+
+Information Process
+
+a coherent set of \[actions@\] that are (to be) performed by a single \[party@\], in which [data](https://essif-lab.github.io/framework/docs/terms/data) (that is controlled by this [party](https://essif-lab.github.io/framework/docs/terms/party) is created, read, updated and/or deleted.
+
+Isuer Policy
+
+a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [issuer](https://essif-lab.github.io/framework/docs/terms/issuer) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+Issuer
+
+a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to construct [credential](https://essif-lab.github.io/framework/docs/terms/credential) from data objects, according to the content of its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [issuer](https://essif-lab.github.io/framework/docs/terms/issuer)\-Policy (specifically regarding the way in which the [credential](https://essif-lab.github.io/framework/docs/terms/credential) is to be digitally signed), and pass it to the [wallet](https://essif-lab.github.io/framework/docs/terms/wallet)\-component of its [principal](https://essif-lab.github.io/framework/docs/terms/principal) allowing it to be issued.
+
+Jurisdiction
+
+the composition of a [legal system](https://essif-lab.github.io/framework/docs/terms/legal-system) (legislation, enforcement thereof, and conflict resolution), a [party](https://essif-lab.github.io/framework/docs/terms/party) that governs that [legal system](https://essif-lab.github.io/framework/docs/terms/legal-system), a scope within which that [legal system](https://essif-lab.github.io/framework/docs/terms/legal-system) is operational, and one or more [objective](https://essif-lab.github.io/framework/docs/terms/objective) for the purpose of which the [legal system](https://essif-lab.github.io/framework/docs/terms/legal-system) is operated. See also the [Jurisdictions pattern](https://essif-lab.github.io/framework/docs/terms/pattern-jurisdiction).
+
+Jurisdiction Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain what a generic [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) consists of, and relates it to [parties](https://essif-lab.github.io/framework/docs/terms/party) and [legal entities](https://essif-lab.github.io/framework/docs/terms/legal-entity).
+
+Knowledge
+
+the (intangible) sum of what is known by a specific [party](https://essif-lab.github.io/framework/docs/terms/party), as well as the familiarity, awareness or understanding of someone or something by that [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Legal Entity
+
+an [entity](https://essif-lab.github.io/framework/docs/terms/entity) that is known by, recognized to exist, and registered in that [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction).
+
+Legal Jurisdiction
+
+a [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction) that is governed/operated by a governmental body.
+
+Legal System
+
+a system in which rules are defined, and mechanisms for their enforcement and conflict resolution are (implicitly or explicitly) specified.
+
+Management
+
+the [act](https://essif-lab.github.io/framework/docs/terms/action) or process of managing or actually realizing of (the results associated with) a set of [objective](https://essif-lab.github.io/framework/docs/terms/objective) by the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of these [objective](https://essif-lab.github.io/framework/docs/terms/objective).
+
+Mandate
+
+a right or duty that one [party](https://essif-lab.github.io/framework/docs/terms/party) (the [mandator](https://essif-lab.github.io/framework/docs/terms/mandate)) has granted to another [party](https://essif-lab.github.io/framework/docs/terms/party) or [employee](https://essif-lab.github.io/framework/docs/terms/employee) (the [mandatee](https://essif-lab.github.io/framework/docs/terms/mandate)) for executing a specific (set of) [action](https://essif-lab.github.io/framework/docs/terms/action) in the name of, and under responsibility/accountability of, this (first) [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Mandates, Delegation and Hiring Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain the ideas behind Mandating, Delegating, Hiring and their relations.
+
+Mental Model
+
+a description, both casual and formal, of a set of [concept](https://essif-lab.github.io/framework/docs/terms/concept) (ideas), relations between them, and constraints, that together form a coherent and consistent 'viewpoint', or 'way of thinking' about a certain topic.
+
+Mental Model Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how to create, maintain and use (decentralized) [vocabularies](https://essif-lab.github.io/framework/docs/terms/vocabulary) ([terminologies](https://essif-lab.github.io/framework/docs/terms/terminology)) that groups of people can use for the specific purposes they pursue.
+
+Mission
+
+an [objective](https://essif-lab.github.io/framework/docs/terms/objective) of a [party](https://essif-lab.github.io/framework/docs/terms/party) that provides an answer to the question why that [party](https://essif-lab.github.io/framework/docs/terms/party) exists - i.e. its 'raison d'tre'.
+
+Normative framework
+
+a set of rules that are followed and/or criteria that remain fulfilled by (a specific kind of) [entities](https://essif-lab.github.io/framework/docs/terms/entity) whose behavior and/or properties are characterized as 'normal'.
+
+Objective
+
+something toward which a [party](https://essif-lab.github.io/framework/docs/terms/party) (its [owner](https://essif-lab.github.io/framework/docs/terms/owner)) directs effort (an aim, goal, or end of action).
+
+Obligation
+
+an [objective](https://essif-lab.github.io/framework/docs/terms/objective) that is [owned](https://essif-lab.github.io/framework/docs/terms/owned) by the [party](https://essif-lab.github.io/framework/docs/terms/party) for producing a specific (set of) result(s) that are to be used (consumed) by that [party](https://essif-lab.github.io/framework/docs/terms/party) and/or other [parties](https://essif-lab.github.io/framework/docs/terms/party).
+
+Onboarding
+
+a process that is run for a specific (set of) [actor](https://essif-lab.github.io/framework/docs/terms/actor) on behalf of a specific [party](https://essif-lab.github.io/framework/docs/terms/party), that terminates successfully if and only if the [party](https://essif-lab.github.io/framework/docs/terms/party) has (a) established the suitability of the [actor](https://essif-lab.github.io/framework/docs/terms/actor) for executing certain kinds of [action](https://essif-lab.github.io/framework/docs/terms/action) on its behalf, (b) ensured that their mutual rights and duties are properly specified and will be appropriately enforced, and (c) provided the circumstances/contexts within which the [actor](https://essif-lab.github.io/framework/docs/terms/actor) is enabled to do so.
+
+Organization
+
+a [party](https://essif-lab.github.io/framework/docs/terms/party) that is capable of setting [objective](https://essif-lab.github.io/framework/docs/terms/objective) and making sure these are realized by [actor](https://essif-lab.github.io/framework/docs/terms/actor) that it has [onboarded](https://essif-lab.github.io/framework/docs/terms/onboarding) and/or by (vetted) [parties](https://essif-lab.github.io/framework/docs/terms/party) that are committed to contribute to these [objective](https://essif-lab.github.io/framework/docs/terms/objective).
+
+Outsourcing
+
+the state of affairs in which a [party](https://essif-lab.github.io/framework/docs/terms/party) has an [objective](https://essif-lab.github.io/framework/docs/terms/objective) (better: an [expectation](https://essif-lab.github.io/framework/docs/terms/expectation)) for the realization of a (set of) result(s), where the actual production of these results is expected to be done by a [party](https://essif-lab.github.io/framework/docs/terms/party) other than itself.
+
+Owned
+
+an [entity](https://essif-lab.github.io/framework/docs/terms/entity) over which another [entity](https://essif-lab.github.io/framework/docs/terms/entity) (its [owner](https://essif-lab.github.io/framework/docs/terms/owner)) has the power (duty, right) to enjoy it, dispose of it and control it; that power is limited to (the scope of) that [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction), and by its rules.
+
+Owner
+
+the role that a [party](https://essif-lab.github.io/framework/docs/terms/party) performs when it is exercising its legal, rightful or natural title to control that [entity](https://essif-lab.github.io/framework/docs/terms/entity).
+
+Ownership
+
+a relationship between two [entities](https://essif-lab.github.io/framework/docs/terms/entity) that exists within the [scope of control](https://essif-lab.github.io/framework/docs/terms/scope-of-control) of a [jurisdiction](https://essif-lab.github.io/framework/docs/terms/jurisdiction), in which one of them (called the [owner](https://essif-lab.github.io/framework/docs/terms/owner)) has legal, rightful or natural rights and/or duties to enjoy, dispose of, and control the other (called the [owned](https://essif-lab.github.io/framework/docs/terms/owned)).
+
+Partial identity
+
+all [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) that a specific [party](https://essif-lab.github.io/framework/docs/terms/party) (= the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of the partial identity) has about that [entity](https://essif-lab.github.io/framework/docs/terms/entity) (= the '[subject](https://essif-lab.github.io/framework/docs/terms/subject)' of the partial identity).
+
+Participant
+
+a [party](https://essif-lab.github.io/framework/docs/terms/party) is negotiating (or has negotiated) a [transaction agreement](https://essif-lab.github.io/framework/docs/terms/transaction-agreement).
+
+Party, Actor and Actions Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how things get done. It answers questions such as: 'Who/what does things?', 'How are their actions being guided/controlled?', 'Who controls whom/what?', 'Who/what may be held accountable?'.
+
+Party Representation Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how [parties](https://essif-lab.github.io/framework/docs/terms/party) can be represented in various circumstances.
+
+Party
+
+an [entity](https://essif-lab.github.io/framework/docs/terms/entity) that sets its [objective](https://essif-lab.github.io/framework/docs/terms/objective), maintains its [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge), and uses that [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) to pursue its [objective](https://essif-lab.github.io/framework/docs/terms/objective) in an autonomous (sovereign) manner. Humans and [organization](https://essif-lab.github.io/framework/docs/terms/organization) are the typical examples.
+
+Pattern
+
+a description, both casual and formal, of a set of [concept](https://essif-lab.github.io/framework/docs/terms/concept) (ideas), relations between them, and constraints, that together form a coherent and consistent 'viewpoint', or 'way of thinking' about a certain topic.
+
+Peer Actor
+
+the [actor](https://essif-lab.github.io/framework/docs/terms/actor) with whom/which this other [actor](https://essif-lab.github.io/framework/docs/terms/actor) is communicating in that [communication session](https://essif-lab.github.io/framework/docs/terms/communication-session).
+
+Peer-agent
+
+the [agent](https://essif-lab.github.io/framework/docs/terms/agent) with whom/which this other [agent](https://essif-lab.github.io/framework/docs/terms/agent) is communicating in that [communication session](https://essif-lab.github.io/framework/docs/terms/communication-session).
+
+Peer Party
+
+a [party](https://essif-lab.github.io/framework/docs/terms/party) that also participates in that [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction).
+
+Policy
+
+a (set of) rules, working-instructions, preferences and other guidance for the execution of one or more kinds of [action](https://essif-lab.github.io/framework/docs/terms/action), that [agent](https://essif-lab.github.io/framework/docs/terms/agent) of the [party](https://essif-lab.github.io/framework/docs/terms/party) that [governs](https://essif-lab.github.io/framework/docs/terms/governance) the policy have access to and can interpret such that this results in these [action](https://essif-lab.github.io/framework/docs/terms/action) being executed as intended by that [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Presentation Request
+
+a (signed) digital message that a [verifier](https://essif-lab.github.io/framework/docs/terms/verifier) component sends to a [holder](https://essif-lab.github.io/framework/docs/terms/holder) component asking for specific data from one or more [verifiable](https://essif-lab.github.io/framework/docs/terms/verify) [credential](https://essif-lab.github.io/framework/docs/terms/credential) that are issued by specific Parties.
+
+Presentation
+
+a (signed) digital message that a [holder](https://essif-lab.github.io/framework/docs/terms/holder) component may send to a [verifier](https://essif-lab.github.io/framework/docs/terms/verifier) component that contains data derived from one or more [verifiable](https://essif-lab.github.io/framework/docs/terms/verify) [credential](https://essif-lab.github.io/framework/docs/terms/credential) (that (a [colleague](https://essif-lab.github.io/framework/docs/terms/colleague) component of) the [holder](https://essif-lab.github.io/framework/docs/terms/holder) component has received from [issuer](https://essif-lab.github.io/framework/docs/terms/issuer) components of one or more [parties](https://essif-lab.github.io/framework/docs/terms/party)), as a response to a specific [presentation request](https://essif-lab.github.io/framework/docs/terms/presentation-request) of a [Verifier](https://essif-lab.github.io/framework/docs/terms/verifier) component.
+
+Principal
+
+the [party](https://essif-lab.github.io/framework/docs/terms/party) for whom, or on behalf of whom, the [actor](https://essif-lab.github.io/framework/docs/terms/actor) is executing an [action](https://essif-lab.github.io/framework/docs/terms/action) (this [actor](https://essif-lab.github.io/framework/docs/terms/actor) is then called an [agent](https://essif-lab.github.io/framework/docs/terms/agent) of that [party](https://essif-lab.github.io/framework/docs/terms/party)).
+
+Property (of a Concept)
+
+a connection or association between a [concept](https://essif-lab.github.io/framework/docs/terms/concept) and a primitive data element, such as a text or a number, that represents some characteristic that instances of the [concept](https://essif-lab.github.io/framework/docs/terms/concept) may have.
+
+Qualified Data
+
+[data](https://essif-lab.github.io/framework/docs/terms/data) that comes with assurances, at least regarding its provenance and integrity (immutability), that make this data valid to be used for specific purposes of individual [parties](https://essif-lab.github.io/framework/docs/terms/party).
+
+Relation (between Concepts)
+
+a (significant) connection or association between two or more [concepts](https://essif-lab.github.io/framework/docs/terms/concept).
+
+Revocation component
+
+a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to [revoke](https://essif-lab.github.io/framework/docs/terms/revoke) [credential](https://essif-lab.github.io/framework/docs/terms/credential) that are issued by its [principal](https://essif-lab.github.io/framework/docs/terms/principal), according to its [principal](https://essif-lab.github.io/framework/docs/terms/principal) [revocation policy](https://essif-lab.github.io/framework/docs/terms/revocation-policy).
+
+Revocation Policy
+
+a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [revocation component](https://essif-lab.github.io/framework/docs/terms/revocation-component) to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+Revoke/Revocation
+
+the act, by or on behalf of the [party](https://essif-lab.github.io/framework/docs/terms/party) that has issued the [credential](https://essif-lab.github.io/framework/docs/terms/credential), of no longer vouching for the correctness or any other qualification of (arbitrary parts of) that [credential](https://essif-lab.github.io/framework/docs/terms/credential).
+
+Risk level
+
+a measure for the deviation of the intended realization (results) of a specific [objective](https://essif-lab.github.io/framework/docs/terms/objective) that its [owner](https://essif-lab.github.io/framework/docs/terms/owner) uses to represent the priority with which the [risk](https://essif-lab.github.io/framework/docs/terms/risk) of that [objective](https://essif-lab.github.io/framework/docs/terms/objective) should be reckoned with.
+
+Risk management
+
+a process that is run by (or on behalf of) a specific [party](https://essif-lab.github.io/framework/docs/terms/party) for the purpose of [managing](https://essif-lab.github.io/framework/docs/terms/management) the [risk](https://essif-lab.github.io/framework/docs/terms/risk) that it [owns](https://essif-lab.github.io/framework/docs/terms/owner) (thereby realizing specific [risk objectives](https://essif-lab.github.io/framework/docs/terms/risk-objective)).
+
+Risk Objective
+
+an [objective](https://essif-lab.github.io/framework/docs/terms/objective), owned by a [party](https://essif-lab.github.io/framework/docs/terms/party), that aims to reach and maintain a state of affairs in which the [risk](https://essif-lab.github.io/framework/docs/terms/risk) associated with a specific set of its [objective](https://essif-lab.github.io/framework/docs/terms/objective) become, and/or remain, acceptable.
+
+Risk Owner
+
+the [party](https://essif-lab.github.io/framework/docs/terms/party) that is the [owner](https://essif-lab.github.io/framework/docs/terms/owner) of the [objective](https://essif-lab.github.io/framework/docs/terms/objective) to which a [risk](https://essif-lab.github.io/framework/docs/terms/risk) is associated.
+
+Risk
+
+the effects that uncertainty (i.e. a lack of information, understanding or [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) of events, their consequences or likelihoods) can have on the intended realization of an [objective](https://essif-lab.github.io/framework/docs/terms/objective) of a [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Role name
+
+name (text) that refers to (and identifies) a [role](https://essif-lab.github.io/framework/docs/terms/role) in a specific context.
+
+Role
+
+a defined set of characteristics that an [entity](https://essif-lab.github.io/framework/docs/terms/entity) has in some context, such as [responsibilities](https://essif-lab.github.io/framework/docs/terms/obligation) it may have, [action](https://essif-lab.github.io/framework/docs/terms/action) (behaviors) it may execute, or pieces of [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge) that it is expected to have in that context, which are referenced to by a specific [role name](https://essif-lab.github.io/framework/docs/terms/role-name).
+
+Scope of Control
+
+the extent of the area or subject matter that a [party](https://essif-lab.github.io/framework/docs/terms/party) [controls](https://essif-lab.github.io/framework/docs/terms/controller).
+
+Scope
+
+the extent of the area or subject matter (which we use, e.g., to define [pattern](https://essif-lab.github.io/framework/docs/terms/pattern), [concept](https://essif-lab.github.io/framework/docs/terms/concept), [term](https://essif-lab.github.io/framework/docs/terms/term) and [glossaries](https://essif-lab.github.io/framework/docs/terms/glossary) in, but it serves other purposes as well).
+
+Term (Scoped)
+
+a [term](https://essif-lab.github.io/framework/docs/terms/term), the meaning of which is determined by the [definition](https://essif-lab.github.io/framework/docs/terms/definition) to which it refers in a specific [scope](https://essif-lab.github.io/framework/docs/terms/scope)/context.
+
+Self-Sovereign Identity (SSI)
+
+self-Sovereign Identity (SSI) is a term that has many different interpretations, and that we use to refer to concepts/ideas, architectures, processes and technologies that aim to support (autonomous) [parties](https://essif-lab.github.io/framework/docs/terms/party) as they negotiate and execute electronic [transaction](https://essif-lab.github.io/framework/docs/terms/transaction) with one another.
+
+Self-Sovereignty
+
+the characteristic of every [party](https://essif-lab.github.io/framework/docs/terms/party) that it is autonomous in managing and operating its [owns](https://essif-lab.github.io/framework/docs/terms/owner) [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge), particularly in making decisions and deciding how to decide.
+
+Semantic Unit
+
+a basic building block of meaning or representation that exists within the 'mind' of a [party](https://essif-lab.github.io/framework/docs/terms/party) (i.e., in its [knowledge](https://weboftrust.github.io/keridoc/framework/docs/@essif-lab.md)).
+
+Semantics
+
+a mapping between the (tangible/textual) [term](https://essif-lab.github.io/framework/docs/terms/term) and (intangible) ideas/[concept](https://essif-lab.github.io/framework/docs/terms/concept) - their meaning.
+
+Semantics Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain the relations between the (intangible) [concepts](https://essif-lab.github.io/framework/docs/terms/concept) (and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit)) that are part of a [party's](https://essif-lab.github.io/framework/docs/terms/party) [knowledge](https://essif-lab.github.io/framework/docs/terms/knowledge), and how they are (tangibly) represented by [terms](https://essif-lab.github.io/framework/docs/terms/term), [attributes](https://essif-lab.github.io/framework/docs/terms/attribute), etc.
+
+SSI Agent
+
+a [digital agent](https://essif-lab.github.io/framework/docs/terms/agent) that provides one or more of the [ssi functionalities](https://essif-lab.github.io/framework/docs/terms/ssi-agent) ([issuer](https://essif-lab.github.io/framework/docs/terms/issuer), [holder](https://essif-lab.github.io/framework/docs/terms/holder), [verifier](https://essif-lab.github.io/framework/docs/terms/verifier), [wallet](https://essif-lab.github.io/framework/docs/terms/wallet)) to its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+SSI Assurance Community (SSI-AC)
+
+a [community](https://essif-lab.github.io/framework/docs/terms/community) that supports its members as they seek to increase their confidence in the [SSI infrastructure](https://essif-lab.github.io/framework/docs/terms/ssi-infrastructure) and/or (specific) [qualifications](https://essif-lab.github.io/framework/docs/terms/qualified-data) of the data exchanged through that infrastructure.
+
+SSI Infrastructure
+
+the technological components that are (envisaged to be) all over the world for the purpose of providing, requesting and obtaining [qualified data](https://essif-lab.github.io/framework/docs/terms/qualified-data), for the purpose of negotiating and/or executing electronic [transaction](https://essif-lab.github.io/framework/docs/terms/transaction).
+
+SSI (Self-Sovereign Identity)
+
+sSI (Self-Sovereign Identity) is a term that has many different interpretations, and that we use to refer to concepts/ideas, architectures, processes and technologies that aim to support (autonomous) [parties](https://essif-lab.github.io/framework/docs/terms/party) as they negotiate and execute electronic [transaction](https://essif-lab.github.io/framework/docs/terms/transaction) with one another.
+
+Subject
+
+the (single) [entity](https://essif-lab.github.io/framework/docs/terms/entity) to which a given set of coherent data relates/pertains. Examples of such sets include attributes, [Claims/Assertions](https://essif-lab.github.io/framework/docs/terms/assertion), files/dossiers, [(verifiable) credentials](https://essif-lab.github.io/framework/docs/terms/credential), [(partial) identities](https://essif-lab.github.io/framework/docs/terms/partial-identity), [employment contracts](https://essif-lab.github.io/framework/docs/terms/employment-contract), etc.
+
+Tag
+
+an alphanumeric string that is used to identify [scope](https://essif-lab.github.io/framework/docs/terms/scope) (so called 'scopetags'), group [term](https://essif-lab.github.io/framework/docs/terms/term) (so called 'grouptags'), or identify a specific version of a [terminology](https://essif-lab.github.io/framework/docs/terms/terminology) (so called 'versiontags') from within a specific [scope](https://essif-lab.github.io/framework/docs/terms/scope).
+
+Term
+
+a word or phrase (i.e.: text) that is used in at least one [scope](https://essif-lab.github.io/framework/docs/terms/scope)/context to represent a specific [concept](https://essif-lab.github.io/framework/docs/terms/concept).
+
+Terminology Process
+
+a method for recognizing misunderstandings as such, and creating or maintaining [definition](https://essif-lab.github.io/framework/docs/terms/definition) that resolve them.
+
+Terminology
+
+the set of [term](https://essif-lab.github.io/framework/docs/terms/term) that are used within a single [scope](https://essif-lab.github.io/framework/docs/terms/scope) to refer to a single [definition](https://essif-lab.github.io/framework/docs/terms/definition), enabling [parties](https://essif-lab.github.io/framework/docs/terms/party) to reason and communicate ideas they have about one or more specific topics.
+
+Terminology Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that one can use to explain one's thinking about a certain topic, as well as to devise/design a way of thinking that members of a [community](https://essif-lab.github.io/framework/docs/terms/community) can use to align their thinking as they pursue that [community's](https://essif-lab.github.io/framework/docs/terms/community) [objectives](https://essif-lab.github.io/framework/docs/terms/objective).
+
+Terms Community
+
+a [community](https://essif-lab.github.io/framework/docs/terms/community) that maintains a [terminology](https://essif-lab.github.io/framework/docs/terms/terminology) for the purpose of avoiding misunderstandings between its members as they collaborate.
+
+Transaction Agreement
+
+the set of rules that specify the rights ([expectation](https://essif-lab.github.io/framework/docs/terms/expectation)) and duties ([obligation](https://essif-lab.github.io/framework/docs/terms/obligation)) of [participant](https://essif-lab.github.io/framework/docs/terms/participant) towards one another in the context of a specific [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction).
+
+Transaction Form
+
+the specification of the set of data that this [party](https://essif-lab.github.io/framework/docs/terms/party) needs to (a) commit to a (proposed) [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction) of that kind, (b) fulfill its duties/[obligation](https://essif-lab.github.io/framework/docs/terms/obligation) and (c) escalate if necessary.
+
+Transaction Id
+
+character string that this [participant](https://essif-lab.github.io/framework/docs/terms/participant) uses to identify, and refer to, that [business transaction](https://essif-lab.github.io/framework/docs/terms/transaction).
+
+Transaction Proposal
+
+a [transaction agreement](https://essif-lab.github.io/framework/docs/terms/transaction-agreement) that is 'in-the-making' (ranging from an empty document to a document that would be a [transaction agreement](https://essif-lab.github.io/framework/docs/terms/transaction-agreement) if it were signed by all [participant](https://essif-lab.github.io/framework/docs/terms/participant)).
+
+Transaction Request
+
+a message, send by a requesting [party](https://essif-lab.github.io/framework/docs/terms/party) to a providing [party](https://essif-lab.github.io/framework/docs/terms/party), that initiates the negotiation of a new [transaction agreement](https://essif-lab.github.io/framework/docs/terms/transaction-agreement) between these [parties](https://essif-lab.github.io/framework/docs/terms/party) for the provisioning of a specific product or service.
+
+Transaction
+
+the exchange of goods, services, funds, or data between some [parties](https://essif-lab.github.io/framework/docs/terms/party) (called [participant](https://essif-lab.github.io/framework/docs/terms/participant) of the [transaction](https://essif-lab.github.io/framework/docs/terms/transaction)).
+
+Trust level
+
+the (subjective) degree of belief or confidence that a [party](https://essif-lab.github.io/framework/docs/terms/party) has in X (someone, something, ...).
+
+Trust
+
+the (un)conscious decision by a [party](https://essif-lab.github.io/framework/docs/terms/party) to believe that X is in fact the case.
+
+Trust Pattern
+
+a set of [concepts](https://essif-lab.github.io/framework/docs/terms/concept) and other [semantic units](https://tno-terminology-design.github.io/tev2-specifications/docs/terms/semantic-unit) that can be used to explain how the concept of [trust](https://essif-lab.github.io/framework/docs/terms/trust) relates to [parties](https://essif-lab.github.io/framework/docs/terms/party) that do the trusting, and other concepts that express what it is that these [parties](https://essif-lab.github.io/framework/docs/terms/party) trust.
+
+Validate
+
+the act, by or on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party), of determining whether or not that data is valid to be used for some specific purpose(s) of that [party](https://essif-lab.github.io/framework/docs/terms/party).
+
+Validator Policy
+
+a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [validator](https://essif-lab.github.io/framework/docs/terms/validator) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+Validator
+
+a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to determine whether or not ([verified](https://essif-lab.github.io/framework/docs/terms/verify)) data is valid to be used for some specific purpose(s).
+
+Verifier Policy
+
+a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [verifier](https://essif-lab.github.io/framework/docs/terms/verifier) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+Verifier
+
+a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to request [peer agents](https://essif-lab.github.io/framework/docs/terms/peer-agent) to present (provide) data from credentials (of a specified kind, issued by specified [parties](https://essif-lab.github.io/framework/docs/terms/party)), and to verify such responses (check structure, signatures, dates), according to its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [verifier policy](https://essif-lab.github.io/framework/docs/terms/verifier-policy).
+
+Verify
+
+the act, by or on behalf of a [party](https://essif-lab.github.io/framework/docs/terms/party), of determining whether that data is authentic (i.e. originates from the [party](https://essif-lab.github.io/framework/docs/terms/party) that authored it), timely (i.e. has not expired), and conforms to other specifications that apply to its structure.
+
+Vocabulary
+
+the sum or stock of words employed by a language, group, individual, or work or in a field of knowledge.
+
+Wallet Policy
+
+a [digital policy](https://essif-lab.github.io/framework/docs/terms/policy) that enables an operational [wallet](https://essif-lab.github.io/framework/docs/terms/wallet) component to function in accordance with the [objective](https://essif-lab.github.io/framework/docs/terms/objective) of its [principal](https://essif-lab.github.io/framework/docs/terms/principal).
+
+Wallet
+
+a component that implements the [capability](https://essif-lab.github.io/framework/docs/terms/capability) to securely store data as requested by [colleague agents](https://essif-lab.github.io/framework/docs/terms/colleague), and to provide stored data to [colleague agents](https://essif-lab.github.io/framework/docs/terms/colleague) or [peer agents](https://essif-lab.github.io/framework/docs/terms/peer-agent), all in [compliance](https://essif-lab.github.io/framework/docs/terms/compliance) with the rules of its [principal](https://essif-lab.github.io/framework/docs/terms/principal)'s [wallet policy](https://essif-lab.github.io/framework/docs/terms/wallet-policy).
+
+eSSIF-Lab World Model
+
+the set of [concept](https://essif-lab.github.io/framework/docs/terms/concept), relations between them ([pattern](https://essif-lab.github.io/framework/docs/terms/pattern)), and [Principles](https://weboftrust.github.io/keridoc/framework/docs/essifLab-principles.md) (that are the starting point for eSSIF-Lab's thinking).
+
+
+
+
+---
+title: External Digital Govt NZ Glossary
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-digital.govt.nz/index
+  md: https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-digital.govt.nz/index.md
+---
+
+# External Digital Govt NZ Glossary
+
+\[ [A](#account) | [B](#binding) | [C](#challenge) | [D](#delegate~ed) | [E](#enrol~ment) | [F](#facilitate~ion) | [G](#undefined) | [H](#undefined) | [I](#identification) | [J](#undefined) | [K](#undefined) | [L](#levelofrisk) | [M](#mechanism) | [N](#undefined) | [O](#onetimepasswordOTP) | [P](#party) | [Q](#undefined) | [R](#relyingparty\(RP\)) | [S](#selfsovereign) | [T](#transaction) | [U](#undefined) | [V](#undefined) | [W](#undefined) | [X](#undefined) | [Y](#undefined) | [Z](#undefined) \]
+
+account
+
+an instance of entity information in a contextAdditional note:Note 1: A common term for the set of entity information relating to 1 entity to which an authenticator can be registered and from which credential subject information can be taken to establish a Credential.
+
+accountable
+
+responsible for some action; answerable\[Source: expanded Dictionary meaning of accountable\]Additional note:Note 1: For roles such as Credential Provider and Relying Party, it is the primary publicly accessible party.
+
+affected party
+
+a party that could be influenced; acted upon\[Source: expanded Dictionary meaning of affected\]Additional note:Note 1: For identification risk, the affected parties have been identified as:Entitled individual for example, an entitled individual applies for a service and is deemed ineligible because their identity has been used previously by someone else to claim the same service.Service provider for example, an organisations reputation suffers because of publicity that the agency has been defrauded by large numbers of individuals claiming false identities.Wider community for example, identification documents are mistakenly issued to people with false identities and are then used to commit fraud against other organisations.
+
+agent
+
+a person, firm, etc. empowered to act for another\[Source: Dictionary\]
+
+anonymous
+
+not easily distinguished from others or from one another because of a lack of individual features or character\[Source: Dictionary\]
+
+assurance
+
+a statement, assertion, etc. intended to inspire confidence or give encouragement\[Source: Dictionary\]
+
+attribute
+
+(noun) a characteristic or quality of a person or thing\[Source: Dictionary\]
+
+authentication
+
+process for establishing an authenticator is genuine or as represented\[Source: expanded Dictionary meaning of authenticate\]
+
+authenticator
+
+things known and/or possessed and controlled by an entity that are used to be recognised when they return to an organisation\[Source: Based on NIST SP 800-63-3 Digital Identity Guidelines\]
+
+authenticator holder
+
+the entity to which an authenticator was initially bound; the rightful holder\[Source: New definition\]
+
+authoritative
+
+possessing or supported by authority; official\[Source: Dictionary\]Additional note:Note 1: Indigenous peoples, society and industry communities can nominate a party as authoritative. Its possible that such a party is subject to legal controls.
+
+binding
+
+(noun) the action of a person or thing that binds\[Source: Dictionary\]
+
+challenge
+
+(verb) to order (a person) to halt and be identified or to give a password\[Source: Dictionary\]Additional note:Note 1: A challenger issues a challenge and a responder replies.
+
+comply ~ance
+
+to act in accordance with rules, wishes, etc; be obedient (to)\[Source: Dictionary\]
+
+consequence
+
+outcome of an event affecting objectives\[Source: ISO 31073:2022\]Additional notes:Note 1: A consequence can have positive or negative, direct or indirect, effects on objectives.Note 2: Consequences can be expressed qualitatively or quantitatively.Note 3: Any consequences can escalate through cascading and cumulative effects.
+
+context
+
+environment with defined boundary conditions in which entities exist and interact\[Source: ITU-T X.1252\]
+
+contiguous
+
+immediately preceding or following in time\[Source: Dictionary modified by adding immediately\]Additional note:Note 1: When applied to authentication, multiple factors are tested in such adjacent steps, that they are considered part of a single process.
+
+(risk) control
+
+(noun) measure that maintains and / or modifies risk\[Source: ISO 31073:2022 modified to add note 3\]Additional notes:Note 1: Risk controls include, but are not limited to, any process, policy, device, practice, or other conditions and / or actions which maintain and / or modify risk.Note 2: Risk controls do not always exert the intended or assumed modifying effect.Note 3: When using the Assessing identification risk guidance to calculate levels of identification process, these processes are not included as risk controls.
+
+control
+
+(verb) to command, direct, or rule\[Source: Dictionary\]Additional note:Note 1: Control is also used outside the context of risk mitigation. For example, to indicate the ability for an authenticator holder to retain use of their authenticator.
+
+correlate~ion
+
+to place or be placed in a mutual, complementary, or reciprocal relationship\[Source: Dictionary\]
+
+corroborate~ing
+
+to confirm or support (facts, opinions, etc), esp by providing fresh evidence\[Source: Dictionary\]
+
+credential
+
+an artefact created as the result of a series of processes that bind an entity with information and an authenticator, on which other parties relyAdditional note:Note 1: At a minimum a credential includes an authenticator and information to enable presentation.
+
+credential provider
+
+the party accountable for the establishment and presentation facilitation of a credentialAdditional note:Note 1: A Credential Provider may employ other parties in the carrying out of their function.
+
+delegate~ed
+
+(verb) to give or commit (duties, powers, etc) to another as agent or representative; depute\[Source: Dictionary\]
+
+delegate
+
+(noun) a person chosen or elected to act for or represent another or others\[Source: Dictionary\]Additional note:Note 1: Modified to remove reference to conference or meeting.
+
+derived value
+
+value obtained by reasoning; deduction or inference\[Source: expanded Dictionary meaning of derive\]
+
+enrol ~ment
+
+to become or cause to become a member; enlist; register\[Source: Dictionary\]
+
+entity
+
+something that has real or distinct existence from other things\[Source: Dictionary\]
+
+evidence
+
+to give proof of or evidence for\[Source: Dictionary\]
+
+facilitate~ion
+
+to make easier; assist the progress of\[Source: Dictionary\]
+
+facilitation providerFP
+
+the party accountable for the establishment and functioning of a facilitation mechanism\[Source: New definition\]Additional note:Note 1: A facilitation mechanism facilitates the presentation of 1 or more Credentials to a Relying Party.
+
+federate~d~ion
+
+united by common agreement under an authority\[Source: Dictionary modified to remove central government\]
+
+forgery
+
+the act of reproducing something for a deceitful or fraudulent purpose\[Source: Dictionary\]
+
+identification
+
+the act of identifying or the state of being identified\[Source: Dictionary\]
+
+identifier
+
+information that is enough to uniquely represent an entity in a given context\[Source: New definition\]
+
+identity theft
+
+the theft or assumption of a pre-existing identity (or significant part thereof) with or without consent, and, whether, in the case of an individual, the person is living or deceased\[Source: Australian Centre for Policing Research\]
+
+level of risk
+
+magnitude of a risk or combination of risks, expressed in terms of the combination of consequences and their likelihood\[Source: ISO 31073:2022\]
+
+likelihood
+
+chance of something happening\[Source: ISO 31073:2022\]Additional notes:Note 1: In risk management terminology, the word likelihood is used to refer to the chance of something happening, whether defined, measured or determined objectively or subjectively, qualitatively or quantitatively, and described using general terms or mathematically (such as a probability or a frequency over a given time period).Note 2: The English term likelihood does not have a direct equivalent in some languages instead, the equivalent of the term probability is often used. However, in English, probability is often narrowly interpreted as a mathematical term. Therefore, in risk management terminology, likelihood is used with the intent that it should have the same broad interpretation as the term probability has in many languages other than English.
+
+mechanism
+
+a process or technique, esp. of execution\[Source: Dictionary\]
+
+one-time password OTP
+
+a password that is valid for only 1 login session or transaction\[Source: Wikipedia\]Additional notes:Note 1: Also known as one-time pin or dynamic password.Note 2: Generation can be time-based OTP (TOTP) or event-based OTP also known as hash-based message authentication codes (HMAC) (HOTP).
+
+orphan ~ed
+
+entity information that is not bound to an entity or authenticator
+
+party
+
+an entity who participates or is concerned in an action, proceeding, plan, etc.\[Source: Dictionary modified to include non-persons\]
+
+present ~ation
+
+(verb) to offer or hand over for action or settlement\[Source: Dictionary\]
+
+pseudonymous
+
+using a pseudonym\[Source: Dictionary\]Additional note:Note 1: A pseudonym being an identifier that may relate to an individual entity but does not allow the entity to be identifiable outside the context.
+
+relying party (RP)
+
+the accountable party who relies on presented credential(s) in order to make decisionsAdditional notesNote 1: A Relying Party may employ other parties in the carrying out of their function.
+
+replication
+
+the act of repeating, duplicating, copying, or reproducing\[Source: Dictionary\]
+
+risk
+
+effect of uncertainty on objectives\[Source: ISO 31073:2022\]Additional notes:Note 1: An effect is a deviation from the expected. It can be positive, negative or both, and can address, create or result in opportunities and threats.Note 2: Objectives can have different aspects and categories and can be applied at different levels.Note 3: Risk is usually expressed in terms of risk sources, potential events, their consequences and their likelihood.
+
+role
+
+proper or customary function\[Source: Dictionary\]
+
+self-sovereign
+
+(concept) an entity having sole ownership over the ability to control their accounts and information\[Source: Based on searchsecurity.techtarget.com\]
+
+service
+
+a system or method of providing people with the use of something, as electric power, water, transportation, mail delivery.\[Source: Dictionary\]Additional notes:Note 1: Today service has a broader application than utilities, such as finance, employment and compliance services.Note 2: A service may contain 1 or more transactions.
+
+session
+
+an unbroken interactive information interchange between 2 or more entities\[Source: Wikipedia (computer science) modified\]
+
+spoofing
+
+presenting a recorded image or other biometric data sample, or an artificially derived biometric characteristic, in order to impersonate an individual\[Source: ISO/IEC TR 24714-1:2008\]
+
+subject
+
+entity that is the focus of entity information
+
+synchronise ~ous
+
+to occur or recur or cause to occur or recur at the same time or in unison\[Source: Dictionary\]
+
+transaction
+
+one or more exchanges between an individual and an organisation in a process related to a specific outcomeAdditional notes:Note 1: A single transaction may constitute a step in a segmented process or result in the completion of an end to end process.Note 2: A service is usually made up of several transactions.
+
+identity
+
+one or more attributes that allow an entity record to be unique from all others in the contextAdditional noteNote 1: Due to the contextual nature of the attributes that make up an identity and its poor interaction with other words, use of the word identity as a descriptor should be avoided wherever possible.
+
+
+
+
+---
+title: vLei issues
+description: Real-time info.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/github-latest-activity/vLei/index
+  md: https://weboftrust.github.io/keridoc/docs/github-latest-activity/vLei/index.md
+---
+
+# vLei issues
+
+Real-time info.
+
+> [!NOTE]
+> Loading…
+
+
+
+
+---
+title: Signify-ts issues
+description: Real-time info.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/github-latest-activity/signify-ts/index
+  md: https://weboftrust.github.io/keridoc/docs/github-latest-activity/signify-ts/index.md
+---
+
+# Signify-ts issues
+
+Real-time info.
+
+> [!NOTE]
+> Loading…
+
+
+
+
+---
+title: KERIPY issues
+description: Real-time info.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/github-latest-activity/keripy/index
+  md: https://weboftrust.github.io/keridoc/docs/github-latest-activity/keripy/index.md
+---
+
+# KERIPY issues
+
+Real-time info.
+
+> [!NOTE]
+> Loading…
+
+
+
+
+---
+title: KERIA issues
+description: Real-time info.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/github-latest-activity/keria/index
+  md: https://weboftrust.github.io/keridoc/docs/github-latest-activity/keria/index.md
+---
+
+# KERIA issues
+
+Real-time info.
+
+> [!NOTE]
+> Loading…
+
+
+
+
+---
+title: KERI issues
+description: Real-time info.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/github-latest-activity/keri/index
+  md: https://weboftrust.github.io/keridoc/docs/github-latest-activity/keri/index.md
+---
+
+# KERI issues
+
+Real-time info.
+
+> [!NOTE]
+> Loading…
+
+
+
+
+---
+title: Cesride issues
+description: Real-time info.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/github-latest-activity/cesride/index
+  md: https://weboftrust.github.io/keridoc/docs/github-latest-activity/cesride/index.md
+---
+
+# Cesride issues
+
+Real-time info.
+
+> [!NOTE]
+> Loading…
+
+
+
+
+---
+title: Tutorials
+description: Search through tutorials
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/education/tutorials/index
+  md: https://weboftrust.github.io/keridoc/docs/education/tutorials/index.md
+---
+
+# Tutorials
+
+[Search through tutorials](https://weboftrust.github.iokeridoc/docs/education/tutorials?Wot-terms%5BrefinementList%5D%5Bcategory%5D%5B0%5D=Tutorials&searchModalStatus=open)
+
+All tutorials by Kent Bull:
+
+-   KERI Tutorial Series: Treasure Hunting in Abydos! Issuing and Verifying a Credential (ACDC)
+
+    _March 9, 2023_
+
+    [https://kentbull.com/2023/03/09/keri-tutorial-series-treasure-hunting-in-abydos-issuing-and-verifying-a-credential-acdc/](https://kentbull.com/2023/03/09/keri-tutorial-series-treasure-hunting-in-abydos-issuing-and-verifying-a-credential-acdc/)
+
+-   KERI Tutorial Series – KLI: Sign and Verify with Heartnet
+
+    _January 27, 2023_
+
+    [https://kentbull.com/2023/01/27/keri-tutorial-series-kli-sign-and-verify-with-heartnet/](https://kentbull.com/2023/01/27/keri-tutorial-series-kli-sign-and-verify-with-heartnet/)
+
+-   Reading Mind Map: Key Event Receipt Infrastructure – KERI
+
+    _June 5, 2022_
+
+    [https://kentbull.com/2022/06/05/keri-start/](https://kentbull.com/2022/06/05/keri-start/)
+
+
+[Search through Kent Bull tutorials](https://weboftrust.github.iokeridoc/docs/education/tutorials?Wot-terms%5BrefinementList%5D%5Bcategory%5D%5B0%5D=Tutorials&Wot-terms%5BrefinementList%5D%5Bauthor%5D%5B0%5D=Kent+Bull&searchModalStatus=open)
+
+All tutorials by Nuttawut Kongsuwan:
+
+-   Minimal Disclosure of Identity with Zero-Knowledge Proof and CL-Signature
+
+    _Apr 6, 2020_
+
+    [https://medium.com/finema/minimal-disclosure-of-identity-with-zero-knowledge-proof-and-cl-signature-517ed2a61307](https://medium.com/finema/minimal-disclosure-of-identity-with-zero-knowledge-proof-and-cl-signature-517ed2a61307)
+
+-   Verifiable Credentials for Decentralized Digital Identity
+
+    _Apr 6, 2020_
+
+    [https://medium.com/finema/verifiable-credential-and-verifiable-presentation-for-decentralized-digital-identity-132d107c2d9f](https://medium.com/finema/verifiable-credential-and-verifiable-presentation-for-decentralized-digital-identity-132d107c2d9f)
+
+-   Remote Identity Proofing for Digital Identity
+
+    _May 6, 2020_
+
+    [https://medium.com/finema/remote-identity-proofing-for-digital-identity-c9a285c1b774](https://medium.com/finema/remote-identity-proofing-for-digital-identity-c9a285c1b774)
+
+-   Anonymous Credential Part 1: Brief Overview and History
+
+    _Oct 1, 2020_
+
+    [https://medium.com/finema/anonymous-credential-part-1-brief-overview-and-history-c6679034c914](https://medium.com/finema/anonymous-credential-part-1-brief-overview-and-history-c6679034c914)
+
+-   KERI jargon in a nutshell. Part 1: KERI and AID.
+
+    _Mar 22, 2023_
+
+    [https://medium.com/finema/keri-jargon-in-a-nutshell-part-1-fb554d58f9d0](https://medium.com/finema/keri-jargon-in-a-nutshell-part-1-fb554d58f9d0)
+
+-   KERI jargon in a nutshell. Part 2: SAID and ACDC.
+
+    _Jun 5, 2023_
+
+    [https://medium.com/finema/keri-jargon-in-a-nutshell-part-2-said-and-acdc-de6bc544b95e](https://medium.com/finema/keri-jargon-in-a-nutshell-part-2-said-and-acdc-de6bc544b95e)
+
+-   KERI jargon in a nutshell. Part 3: OOBI and IPEX.
+
+    _Jul 23, 2023_
+
+    [https://medium.com/finema/keri-jargon-in-a-nutshell-part-3-oobi-and-ipex-2e6b222f4b87](https://medium.com/finema/keri-jargon-in-a-nutshell-part-3-oobi-and-ipex-2e6b222f4b87)
+
+
+[Search through Nuttawut Kongsuwan tutorials](https://weboftrust.github.iokeridoc/docs/education/tutorials?Wot-terms%5BrefinementList%5D%5Bcategory%5D%5B0%5D=Tutorials&Wot-terms%5BrefinementList%5D%5Bauthor%5D%5B0%5D=Nuttawut+Kongsuwan&searchModalStatus=open)
+
+
+
+
+---
+title: Q&A about KERI's Security model and Guarantees
+description: This document is part two of Q-and-A. Both files shares a common Glossary, KERI specific and more generic decentralized Identity ones, that has:
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/education/q-and-a-security/index
+  md: https://weboftrust.github.io/keridoc/docs/education/q-and-a-security/index.md
+---
+
+# Q&A about KERI's Security model and Guarantees
+
+![KERI logo](https://weboftrust.github.io/keridoc/assets/images/Keri_logo_color_on_white-ea588f4caf977d258a44ef6377e68378.md)
+
+This document is part two of [Q-and-A](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md). Both files shares a common [Glossary](https://weboftrust.github.iokeridoc/docs/category/glossary), KERI specific and more generic decentralized Identity ones, that has:
+
+-   an alphabetically ordered list of **abbreviations**
+-   an alphabetically ordered list of **definitions**
+
+**The questions are of a varied level: basic and detailed. The answers are mostly directed towards generally interested people and newbies.**
+\*Q = one star question. Novice to KERI, advanced in DIDs
+**Q = two star question. Proficient in DIDs and advanced in KERI
+\***Q = three star question. Expert in DIDs and proficient in KERI
+
+Why should you read or step through the Q&A? To get a different angle to the same topic: KERI.
+```
+{TBW} means: to be written
+{TBW prio 1} means to be written with the highest priority,
+3 = no urgency, 2 = intermediate
+```
+-   [Q&A about KERI](#qa-about-keri)
+    -   [Disclaimer](#disclaimer)
+    -   [List of questions and definitions](#list-of-questions-and-definitions)
+    -   [Knowledge you should be confidently applying](#knowledge-you-should-be-confidently-applying)
+    -   [Actions you should be comfortable with](#actions-you-should-be-comfortable-with)
+-   [Jump table to categories](#jump-table-to-categories)
+
+Inspired by presentation given and questions asked on the [SSI webinar May 2020](https://ssimeetup.org/key-event-receipt-infrastructure-keri-secure-identifier-overlay-internet-sam-smith-webinar-58/), but also issues raised and the progress made, here on Github (Turn on 'Watch' if you want to be notified of conversations).
+
+Beware: A Q&A is always _work in progress_. Tips & help welcome.
+
+Some of the respondents in the **open** repo and presentations have been explicitly named as a source, like _Samuel M. Smith Ph.D._, _Charles Cunningham_, and _Orie Steel_. If there is no reference added to the answers, then it's a mixture of sources and edits in the question. Most of the editing is done by @henkvancann, which might have introduced omission, errors, language glitches and such. Sorry for that, feel free to correct by submitting a pull request (PR).
+For practical reasons educational images uploaded by Github members have been downloaded. We de-personalized them by giving images a new name. Under these new names these images have been uploaded to github and used in the Q&A to clarify the questions and answers.
+
+Keri's content is licensed under the [CC by SA 4.0. license](https://creativecommons.org/licenses/by-sa/4.0/). Parts of the video offered on SSI Meetup webinar 58 have been captured and uploaded to Github to support the answers to general questions about digital identity and more in depth answers to question about Keri.
+
+We've done our best to protect the privacy of the Github by investigating the images we used. We haven't come across personal identifiable information (pii). However, should we have made a mistake after all, please let us know and we'll correct this immediately.
+
+TBW
+
+-   The definitions in the [glossary](https://weboftrust.github.iokeridoc/docs/category/glossary)
+-   The Knowledge you should be confidently applying from part one of the [Q-and-A](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#knowledge-you-should-be-confidently-applying)
+-   Bitcoin Improvement Protocols: BIP32, BIP39, BIP44, BIP47, BIP49, BIP84, BIP174
+-   hierarchical deterministic derivation paths
+-   Base58
+-   Eliptic curves
+-   W3C DIDs thoroughly
+
+-   The Actions you should be comfortable with from part one of the [Q-and-A](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#actions-you-should-be-comfortable-with)
+-   Amend knowledge and keep existing knowledge up to date
+
+-   [Q&A section KERI security considerations](#qa-section-keri-security-considerations)
+-   [KERI operational security](#qa-section-keri-operational-security)
+-   [Identifiers](#qa-section-identifiers)
+-   [Event logs](#qa-section-event-logs)
+-   [Inconsistency and duplicity](#qa-inconsistency-and-duplicity)
+-   [Key rotation](#qa-key-rotation)
+-   [KEL and KERL](#qa-section-kel-and-kerl)
+-   [Witness](#qa-section-witness)
+-   [Watchers](#qa-section-watcher)
+-   [KERI and blockchain settled DIDs](#qa-keri-and-blockchain-settled-dids)
+-   [Security Guarantees](#qa-security-guarantees)
+
+-   [General](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-section-general)
+-   [Why the internet is broken](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-section-why-the-internet-is-broken)
+-   [Open source licenses](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#open-source-licences)
+-   [KERI and DIDs](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-keri-and-dids)
+-   [Wallets](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-section-wallets)
+-   [Signatures](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-section-signatures)
+-   [Proofs](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-section-proofs)
+-   [Private Key Management](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-section-private-key-management)
+-   [Blockchain](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-key-blockchain)
+-   [KERI operational](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-section-keri-operational)
+-   [Root of trust](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-section-root-of-trust)
+-   [Agencies](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#qa-key-agencies)
+-   [Virtual Credentials](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md#virtual-credentials)
+
+* * *
+
+* * *
+
+If we could sit down with every expert and walk through his concerns, it would change. Our biggest problem is that when we write technical stuff, we are writing for an _imagined technical audience_ that cares about the same things at the same technical level that we care about.
+
+In other words our default audience is ourselves (in the KERI team). It reminds us what we thought at the time of writing.
+Even if we are writing for a known audience, we can't adapt in real time, because its not interactive so we usually only get it half right, just half convincing, which is as good as nothing in internet security.
+
+But when we **talk to people one-on-one** we can _adapt_ what we say to match their level of understanding and what they care about. _In real time_. We can go as deep as needed but no deeper or a broad as needed but no broader.
+
+KERI is confusing because it is new and can' be assumed. Whole books exists and hundreds of papers on "eventual consistency" algorithms (which CouchDB uses) but they are just assumed away. Because KERI is new, I can't just assume it away. **But KERI is not magic or scary or anywhere as near as difficult as BFT** BA which is assumed away or PoW which is also assumed away. Conversely, most people make assumptions about the security guarantees of DLT that are false. There are many papers on all the known active compromises to Bitcoin that happen on a regular basis yet they assume that they can't happen.
+
+Much of Sam Smith's career he has spent working in a multidisciplinary field that used to be called Computational Intelligence (because A.I. was a hype term) which included as sub fields, Intelligent Control Systems, Automated Reasoning Systems, and Distributed Cooperative Control Systems, to name a few.
+
+All of which used some form of machine learning as a subset. Smith then branched out into IoT distributed systems that employed machine learning for self-healing routing algorithms and simultaneously spent many years working on open standard communications protocols including designing and developing two new protocols largely on my own. One was a highly scalable performant end-to-end secure internet protocol called RAET (Circa 2014). This gives him a uniquely well suited experience base to solve the problem that KERI solves.
+
+KERI solves a really really hard problem that many of the experts in the Decentralized Identity field do not have the background to easily understand. They are going to have to invest some effort to either acquire that background or be patient enough to walk through lengthy tutorials. There is no short cut. KERI creator Sam Smith: "There were a dozen people at IIW April 2021 that sat through three hours of the KERI security sessions where I patiently walked through it. But we only covered half a dozen of the meta security issues and could easily spend another three hours covering several more and many more covering the micro security issues. But most will never take that much time."
+
+Lots of experts in the Decentralized Identity field have extremely deep understanding of legacy IT tech but have a very shallow understanding of crypto, real key management, and distributed consensus. So they are not yet equipped well enough to design decentralized identity systems, despite their 30+ years of working in the identity space. The future of distributed security is based on something called `zero trust computing` and many of these same experts in the Decentralized Identity field have a best a passing familiarity with what zero trust means.
+
+Although the Decentralized Identity space is young, it's already pretty biased and sometimes narrow minded. The solutions in the DID space also have fundamental flaws. We will argue for both claims.
+
+DID expert tend to not read and re-invent what KERI is all about. [See here](https://github.com/decentralized-identity/keri/blob/master/docs/q-and-a#critical-stance-welcomed-just-dont-try-to-rewrite-history-nor-be-lazy) how the KERI community would like to be handled.
+
+Fundamental flaws:
+
+-   Any KERI user gets to decide, e.g. over transaction events. The root-of-trust and the key state is at a lower level always in KERI. You don't co-mingle those. Which is probably the biggest design flaw of most what we see in the Decentralized Identity community where they co-mingle control state and key state with transaction state with means they are locked together.
+-   The number of DID methods seems to explode all with their own security characteristics, which makes interoperability a chain as strong as the weakest link.
+-   The DID community has embraced (public) blockchains to get rid of the middle men. Apart from **the question whether that could be a successful approach** we see that for those experts it's particularly hard to wrap their heads around the KERI security concept, which is scalable to VISA speed, doesn't need a blockchain and can be used to re-design 95+% of all the DID methods by using KERI under the hood. _(@henkvancann)_
+
+We know of no general solution to the portable secure attribution problem before KERI. The DNS/CA system is a general solution to the attribution problem but its not portable and its not secure. (it was meant to be secure but failed, it was never meant to be portable) DLT based systems may provide more or less secure solutions but not portable ones. The combination of portability and security is really really hard.
+
+The KERI solution requires highly nuanced understanding of the underlying properties of distributed security systems.
+Which means broad and deep understanding of distributed systems, distributed consensus algorithms, cryptographic systems and distributed key management systems.
+
+Sam spent years doing sponsored research in a multi-disciplinary field where every meeting he went to was filled with PhDs from big name universities. He represented a small name university, in order to compete he had to study both more widely and more deeply than his competition. This penchant for deep diving every time he encounter something new has served him well throughout his career.
+Smith has built up thorough understanding of:
+
+1.  distributed systems,
+2.  distributed consensus algorithms,
+3.  cryptographic systems and
+4.  distributed key management systems. Six years ago when he started in the identity space, he already had 20+ years in the first two, a couple of years in the second two and then have spent much of the last six years deepening my understanding in the last two and innovating across all four.
+    It is comprehensible that Sam can't begin to replicate that experience/knowledge base in a few thousand pages, much less a few hundred pages of writing.
+    More on Sam Smith's career on [LinkedIN](https://www.linkedin.com/in/samuel-m-smith/)
+
+* * *
+
+* * *
+
+In KERI a root-of-trust 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_. (@henkvancann)
+
+_Is there a list of libraries that we should consider using in out projects, or a list of the ones that we should never use?_
+
+In brief: In every cryptographic system **entropy** rules, and if you don't use a good `rng` (a `csprng`) you're boned from the start. This is really important for everyone in the space to understand.
+
+Generally you want to use the one supplied by the operating system. In linux this used to be `/dev/urandom`. In Rust you typically use `OsRng` from the random crate in fashion. In **cesride** we rely on two variants due to the expectations of ed25519-dalek and k256, and we simply pass them to the libraries to generate keys. You'd need to investigate how to get random bits in whatever language you are using, and just make sure what you are reading is about a `csprng` and not just an `rng` or `prng`.
+
+This looks like it has a lot of good info: [https://crypto.stackexchange.com/questions/11345/definition-of-a-csprng](https://crypto.stackexchange.com/questions/11345/definition-of-a-csprng)
+
+And, even a good `csprng` should be seeded well - if you can get random data from measuring user input or environmental conditions that can't be easily controlled you will generally be more resistant to attack.
+
+> Think about the case for example, where a designer is tempted to use a radio receiver and noise to seed the RNG, but an attacker floods the space with a frequency that produces a deterministic result in the ADC or something.
+
+(Source: Jason Colburne, Feb 2023)
+
+In KERIpy we use libsodium through the python bindings. I've never actually looked at what their documentation says about **randomness**, but here it is: The library provides a set of functions to generate unpredictable data, suitable for creating secret keys.
+
+-   On Windows systems, the `RtlGenRandom()` function is used.
+-   On OpenBSD and Bitrig, the `arc4random()` function is used.
+-   On recent FreeBSD and Linux kernels, the `getrandom` system call is used.
+-   On other Unices, the `/dev/urandom` device is used.
+
+(Source: Philip Feairheller, Feb 2023)
+
+**Key management** is the main component, because every attack on KERI starts with `key compromise`. In KERI that is [strictly defined](https://weboftrust.github.io/WOT-terms/docs/glossary/key-compromise) and has a few caveats. There are no other attacks possible because KERI has consistent logs that are cryptographic verifiable to the `root-of-trust`, also know as the `public private key pair` used to create the identifier.\\
+
+So when we say “key compromise” in KERI we really mean compromise of **one of these three things**: Three infrastructures that are included in “key management” systems that must be protected.
+
+1.  Key pair creation and storage
+2.  Event signing
+3.  Event signature verification.
+
+The second two may be protected with threshold structures making them difficult to attack. KERI pre-rotation also protects event signing in the sense that a side channel attack on the signing keys is recoverable via the pre-rotation keys. Event signing is a form of key compromise. The third one event signature verification is the one someone is most likely to take issue with and so should be caveated. One can attack someone’s event signing infrastructure (code) and fool someone into believing that an invalid signature is a valid signature. But it is difficult to attack everyone’s event signature verification infrastructure in any general way so its not usually a very worthwhile attack. You are attacking the validator not the controller. So usually it is assumed that signature verification just works. So a really world class security expert would take exception with the additional statement “no other other attacks are possible” vs simply saying that all attacks must start with with key compromise. Usually stating that something is impossible is a bad idea. Everything is possible eventually.
+(_SamMSmith_)
+
+KERI's Key event log (KEL) is a cryptographically verifiable hash chained non-repudiably signed data structure.
+(_SamMSmith_)
+
+KERI uses plain old digital signatures from `PKI`, intentionally, so that it may be truly universally applied. KERI solves that hard problem of PKI, that is, key rotation in a standard way. Without a standard way of addressing key rotation, there is no interoperability between systems, they break when you rotate keys because no one knows how to verify the key rotation was done properly. `KERI` solves that problem.
+(_SamMSmith_)
+
+`KERI` does one thing, it establishes control authority using verifiable portable proofs that are `KEL`s.\\
+
+We want fungible trust, that is what KERI provides: _fungible trust on key management or key state_. It does not provide trust for double spend proofing.
+If you need liveliness of fungible value, like cryptocurrencies, you can't use KERI for this.
+In KERI we have compact security for the sake of liveliness, which means there is no public ledger with total ordering of state. In KERI after duplicity is detected, you don't trust that identifier anymore. (_@henkvancann_)
+
+If a controller of a public identifier has a KEL published and with the same authoritative key pair produces another KEL and does not check it's inconsistent with the first one? No, KERI does not protect against that level of stupidity. By comparison, public ledger based identity systems do protect against this stupidity. (_SamMSmith_)
+
+**\*(@OR13) argues the following:**
+
+_In order to share code / we would need shared building blocks. `Sidetree` is built on JWS / JWK. KERI is inventing its own key representation and signature format. These are the lowest level building blocks, so them being different will prevent a lot of potential code reuse._
+
+In brief these are the reasons:
+
+-   the **desire to control the entire stack**, and not use anyone else's tooling
+-   DID and VC layers are the **appropriate layers for interoperability**
+-   The **performance/security goals** of KERI drive its design which makes incompatible with Linked Data tooling
+
+**(@OR13) argues the following:**
+_There was a potential for KERI to align with Ceramic / IPFS / IPLD, but that door closed when the KERI WG decided to reinvent multi-codec._
+
+Have a look at the [Kid0001Comment](https://github.com/henkvancann/keri/blob/master/kids/kid0001Comment.md#summary) Summary for why we needed to divert from `multi-codec`. Multi-codec may not be such a stable standard to be breaking or abandoning.
+
+`Multi-codec` is a draft standard, a rather chaotic mix of binary and text-based entries in a crowd-sourced registry/table. Most implementers are doing a subset of the Multi-codec chart anyways, making it even more unstable for interoperability purposes.
+
+To go in further detail why multi-codec can't do for KERI: the length of item not included in encoding table - incompatible structure (Multi-codec assumes enveloped data structure). Moreover we need KERI's compose-ability (via concatenation) for framing events. [KID0001comment](https://github.com/decentralized-identity/keri/blob/master/kids/kid0001Comment.md) explains in detail why _compose-ability_ is so important and why Multi-codec is therefore not usable.
+
+-   streaming support > interop at signature layer?
+
+KERI can't use enveloped data formats:
+
+-   enveloped data format -> signatures have to put on/outside the payload
+-   MsgPack and CBOR-> work with block-delimited structures
+-   JWS/JWK - also enveloped, also incompatible with streaming
+-   framing events = better streaming support (@by_caballero and_@henkvancann\_)
+
+You can implement did;peer and Sidetree with KERI but we can’t implement KERI with Sidetree or did:peer.
+Because KERI operates on a lower level.
+If we were to do that, we have to tunnel KERI identifiers to create corresponding Ledger-entries.
+(_SamMSmith_)
+
+**(@OR13) argues the following:**
+Afaik this ship sailed when KERI decided to define its own event format. I don't think KERI shares any commonality with sidetree or did peer, and it's no longer possible to align them, so while you can start with the same key material, doing similar operations will very quickly result in totally different event structures.
+
+I don't see a way for KERI events to be used by anything but KERI for now, certainly not Sidetree. In the future did:peer might use KERI events directly, but then did:peer would not be Sidetree compatible
+
+...
+
+The upside is that KERI could be much better than things built on JOSE. The down side is KERI won't be possible to implement with off the shelf JOSE crypto. Having spent a lot of time with linked data, It looks like KERI is setup to feel all the same kind of pain, regarding reinventing the wheel instead of starting with compatibility with JOSE.
+
+...
+
+I predict a few years from now we will have:
+
+1.  JOSE / JWS / JWK / jose based DIDs\\
+2.  `Multicodec` / IPFS / IPLD / DAG\_CBOR / JWS / JWK / ipld based DIDs\\
+3.  Linked Data / JSON-LD / CBOR-LD / linked data based DIDs\\
+4.  KERI / KERI keys / KERI signatures / keri event log based DIDs
+
+There will be some overlap, for example KERI based DID Documents will likely support JWKs if they want to be useful with any legacy system, but internally KERI will use a different key representation. Similarly sidetree based DIDs will likely support linked data proofs but will only rely on JWS / JWK for internal operations.
+
+As far as I know, the KERI design has specifically chosen not to build on JOSE, IPLD. or JSON-LD / CBOR-LD. So there won't be any opportunity for interop with KERI below the DID Document layer. Which is true of many other systems, including Ethereum, Bitcoin, Hyperledger based DIDs. Many of which don't share event log interoperability.
+
+Imo, if KERI used IPLD / JSON-LD / CBOR-LD, it would be better. Because not using them means reinventing the parts of them that are needed... which comes with the potential for better performance at the cost of inventing a faster wheel, and failing to pull developers / tooling from those established communities. However I can understand the desire to control the entire stack, and not use anyone else's tooling.
+
+From an engineering management and interoperability perspective, I would have decided to break compatibility after the whole system was built and working, and only in the areas where JWS / JWK or IPLD performance, documentation or library support was so bad it was justified.
+
+... We should target interop between KERI and Sidetree at the DID Core and VC Data Model layer.
+**End of (@OR13)'s plea.**
+
+Linked-data is an _adoption dead end_. KERI believes that immutable JSON Schema are a better solution than mutable `schema.org` schema. And that when and if backend semantic inference is useful that Labeled Property Graphs (LPG) are a more powerful, easier to use, and more adoptable (already more adopted) alternative to RDF graphs.
+
+Linked data is a euphemism for the semantic web, which, considering how much effort went into it early on, has proven to be a failure. Encumbering VCs with linked data is a failure waiting to happen (for both technical and adoption reasons) especially when there are much better alternatives.
+
+For more detail, read the [VC Spec Enhancement Proposal](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/VC_Enhancement_Strategy.md)
+
+(_SamMSmith_)
+
+By the mechanism of availability, consistency, and duplicity.
+We have to handle `race conditions` too, just like any other distributed database or blockchain.
+(_SamMSmith_)
+
+_Safe scaling: is everything more secure as more witnesses and more watchers are added?_
+
+Watchers and witnesses have two separate effects:
+
+1.  Ambient verifiable requires even distribution (and total coverage) of **watchers** to detect duplicity; the more, the better
+2.  Enough watchers allow a lower threshold of witnesses that need to stay honest - each controller sets a ratio of witnesses that need to confirm an event, if each of the witnesses is watched enough, the security model is the same (and not improved by more witnesses total) (_SamMSmith_)
+
+These two effects have distinctive security characteristic because for 2. the added benefit of an extra witness decrements with every next witness. On the other hand adding watchers in 1. will create a fixed marginal security improvement with every extra watcher.
+_(@henkvancann)_
+
+Controllers' security increased by more witnesses; validator's assurance is increased by more watchers.
+Controllers needs to do an eclipse attack to fool a validator, which is impossibly expensive with enough watchers (_SamMSmith_)
+
+Put another way, first few witnesses are exponentially more secure than n-1, but after a few witnesses, each additional witness's security gain approaches zero asymptotically.
+(_@Chunningham_)
+
+Yes a KEL/KERL is a hash chained data structure. But not merely hash chained but also signed, so it's also a cryptographic proof of key state.
+It's not tracking balance, it's tracking key state. (_SamMSmith_)
+
+[SSI Book](https://livebook.manning.com/book/self-sovereign-identity/chapter-8/v-9/144): "As powerful as this (read KERI-like) solution appears, completely self-certifying identifiers have _one major Achilles heel_: the controller’s identifier needs to change every time the public key is rotated. As we will explain further in [chapter 10](#https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/10-ssi-key-management.pdf) on decentralized key management, key rotation—switching from one public/private key pair to a different one—is a fundamental security best practice in all types of PKI. Thus the inability for self-certifying identifiers alone to support key rotation has effectively prevented their adoption as an alternative to conventional PKI.
+| TBW prio 1 |
+
+DNS and other infrastructure generally not billed to end-user; relative cost per end-user substantially lower than traditional/first-gen DLTs and blockchains.
+An assumption we make: **Watchers** will be comparatively cheap and small communities, networks, and services will likely stand one up as a "loss leader".
+Controllers are incentivized to spin up **witnesses**. Controllers will likely buy/lease at least 1 witness if they want their AID publishized/diseminated. This is cloud-scale infra (2 orders of magnitude lower than DLT infra). (_SamMSmith_)
+
+Communities and networks will pool resources and security and service models will evolve, we assume. (_SamMSmith_)
+
+Freer market closer to blockchain market model or pay-as-you-go clouds; no real moats or lock-ins in the spec as written... Implementation guide should maybe go into how to firewall different clients (like virtual machines on a cloud server) or other security-model eccentricities. (_@Chunningham_)
+
+Maybe but that's layers above the current spec. This spec gives anchors for that kind of tracking, at least? //credit scoring based on opaque algos and unknown data stores and local identifiers - nothing portable to audit, proprietary turtles all the way down.
+
+Decentralizing REPUTATION was a core driver of decentralized identity in its early days (and core ideological thread in IIW); we could be dogfooding our own decentralized infrastructure reputation; pagerank and star-ranking systems are opaque and difficult to audit; publishing algos should still be our goal, and auditable algos is everything. (_SamMSmith_)
+
+Compared to blockchains KEL and KERL are lean and mean data structures. So pruning or chard-ing might not be necessary. KEL and KERL are chard-ed by nature: as soon as delegation comes in or key rotation.
+Every KEL is already shard-able because each root identifier could be split, combined, moved whenever (_@Chunningham_)
+
+Sharding = re-combination of P2P replication (_@bumblefudge_)
+
+You could chunk or prune huge KERLs; that's overkill unless it's really huge You can archive the old state and just keep genesis and last year's updates, for ex.
+
+WCS: high-volume millions of SIGNING events per hour is realistic corner case to worry about, however. If each transaction is sealed as a distinct event, that would make for a pretty big KEL.
+
+That might be kind of an anti-pattern though; implementation guide should probably recommend a Merkle every minute in super high-volume signing infrastructures, for example:
+
+-   WCS KELs are 500bytes per event
+-   10-30K transactions per second = "visa scale"; load balancing may be needed; horizontal scalability achieved by delegation trees; delegations allow segmentation of storage (i.e. pre-sharding); if audit logs are anchored to delegated events in a pre-shard-ed log, you achieve very good scalability
+
+The discussion of `KERI`s approach to _serializing messages and signing and digesting the full over-the-wire serialization_ is inconvenient for implementers. The motivation for this approach I am calling Zero Message Malleability as a property of `KERI`. This is a "best practices" security first approach that prevents semantic leakage over time that becomes a transaction malleability vulnerability. Indeed `KERI` approach trades off some inconvenience in serialization for better security and reduces the inconvenience of needed to have tightly specified semantics to prevent transaction malleability.
+(_SamMSmith_)
+
+_If KERI has this built-in reliance, then doesn't that contradict and defeat the whole purpose of KERI?_
+
+KERI resolver - due to the KERI architecture we get rid of the "magic box" in a way that I don't have to trust any infrastructure component. `DHT` is just example how this can be done in decentralized fashion.
+But the point is that **I don't have to trust any node or network** that the statement is correct. I can cryptographically verify that every time with KERI. Compare to current DID infrastructure where I have to trust resolution process in each DID-method because as soon as would get DID Document, I can't verify that this is the correct one. Think of it like `DID:peer` where I can always be 100% sure that the `DDO` which I have belongs to that DID. Not every DID method has this kind of properties. And I think this characteristic is crucial for adoption of DIDs. (_RobertMitwicki_)
+
+In many system unilateral delegation is a single point of failure. if a delegated key's delegator gets compromised, you have no way to recover.
+Keys are in different infrastructures in KERI. Both the delegator and the delegatee have keys they manage. If one of them get compromised or lost, we still can recover. Each level of delegation allows delegation of the level above. _(@henkvancann)_
+
+In short, no.
+
+[The Issue](https://github.com/decentralized-identity/keri/issues/146) around _simplification of Delegated Events using Hetero Attachments_ has been created in May 2021. Since delegated KELs were cross anchored, we loosened that to the same way non-delegated events do it: an `idempotent` authorization from one event log to the other. Delegated events have to go down this path too, whether they're cross anchored or not. And the cross anchoring has a dead-lock risk, so we wanted to get rid of that. The advantage of not having performance risk on blocked processes on both event logs is huge. All the attacks that we (in a validator role, ed.) could think of, were still protected by duplicity detection. So using the same duplicity detection mechanism they use for non-delegated events, they're still protected for delegated events when they're trying to validate them (the latter, ed.). Since they have to do it for non-delegated events, the additional security of a cross anchor doesn't change their code. The validators still have to going to do it the hard way for non-delegated events, so removing the extra security for a delegated event, didn't do anything. Relaxing the original cross anchoring, doesn't hurt us in any way.
+The only thing I was worried about is whether we were still able to recover pre-rotated keys in a `delegate`, that that kept working the same way as before the simplification. And after my round of testing, it did.
+So the simplification does not come at a cost, it's an outright improvement because we got rid of the cross anchoring.
+(_SamMSmith_)\\
+
+_To be `idempotent`, clients can make that same call repeatedly while producing the same result._
+
+* * *
+
+* * *
+
+More precisely put you need a Public Private key pair of which the private key is kept secret. Merely a secret key is not good enough. It must be PKI. KERI is a new take on PKI that fixes the flaws in existing PKI systems without needing blockchain as a crutch.
+(_SamMSmith_)\\
+
+_Why not? One way function(s) in PKI derive the Public key(s), so in my understanding a secret key with sufficient entropy is the start of it all. Where do I miss a point?_
+
+_SamMSmith_: Yes, you're mission a point. You can use secret keys with symmetric cryptographic operations. Both asymmetric and symmetric start with a secret key but asymmetric goes on to create a public private key pair. So its not only a secret key you need but one that results in a `SCID`. Someone who is used to symmetric cryptography would get the wrong impression.
+
+A self-sovereign identifier that is not self-certifying is dependent of infrastructure and is not fully autonomous and not fully portable. KERI uses autonomic identifiers, fully cryptographically derivable and portable. _(@henkvancann)_
+
+In the direct mode (peer to peer) KERI can be used to keep identifiers private to the peers or group involved. In the indirect mode all identifiers are public. The privacy of the individual, group or object described by the identifier is weak because anyone can bind and identifier to a subject anytime and anywhere. Fortunately, this binding is weak too, As soon as controllers and verifiers sign statements / events related to an identifier, that's when the binding gets strong and subjects publicly exposed.
+_(@henkvancann)_
+
+KERI enables support for protection against liability that could stem from gdpr’s right to be forgotten (passive approach) and the right of erasure (active approach). There are two exceptions to the general rule that you have to remove an identifier from your database, if a subject and / or controller requests so:
+
+1.  As long as you're a party in a transaction involving the identifier that has been revoked, then you can keep that identifier in your log.
+2.  For archival integrity - given that KERI’s whole reason for existence is keep track of duplicity in identity events it is important to know that an identifier has been erased before, because we don't lose that notion. Because somebody could come up with the same identifier in the future and we wouldn't know that it existed before.
+
+Within the assumption of both exceptions KERI complies with the GDPR rules:
+
+1.  block-list of “deleted” KELs: a receipt of a request for erasure must naturally hold some PII, a two-party interaction might allow this to be recorded.
+2.  a need to maintain system integrity/archival purposes can be a reason for maintaining some info right of erasure versus right to be forgotten. This active and passive approach reflects two slightly different interpretations of the same article (which one people use is a hint of their school of thought).
+
+![KERI GDPR compliance](https://weboftrust.github.io/keridoc/assets/images/keri-gdpr-compliance-muggles-0bcb84ea01b1da9346c293c970c4c2e2.md)
+
+Beware that most of GDPR rules are there to protect you from being exploited. So you're not being prosecuted or being labelled as a criminal activity. It might only be illegal and somebody could hold you liable for that. _(@henkvancann)_
+
+It is a cryptographically derived, strong binding between a controller, a key pair and an identifier. No weak bindings introduced by administration present. _(@henkvancann)_
+
+Using a content digest not only binds the inception statement to the identifier but also makes it easy to use the identifier prefix to retrieve the inception statement from a content addressable database.
+```
+Mechanism:
+**inception statement -> hashing -> #**
+
+# points to a record in a database:
+**# -> inception statement -> hashing -> # (proof of "address")**
+```
+This requires that the database store the signature with the inception data, so that a reader may cryptographically verify that the inception data is authoritative. Without the signature the digest is repudiable by the controller. This approach also enables content or document specific but self-certifying identifiers.
+```
+inception statement -> sig + derivation + public key + extra data
+Check sig with public key ->
+non-repudiable unique attribution to the content by whoever controls the private key
+```
+In brief:
+
+1.  commitment: non-repudiable unique attribution to the content creator as controller
+2.  confidentiality: a decryption key must be obtained from the controller
+
+Self-addressing identifiers provide a mechanism for a content addressable database to enforce non-repudiable unique attribution to the content creator as controller. This binds the content to the creator in the content address. Different creator means different address. This makes confidential (encrypted) content more usable as the content address is bound to the controller from whom a decryption key must be obtained.
+
+The assumption is that direct mode is meant to be private communication.
+
+1.  There is understanding when you use direct mode that it needs to stay private
+2.  There is a possibility to impose a liability, under consent at the time of issuance
+3.  There is no way to enforce the KEL from being kept private
+
+Tombstoning in Self Sov Identity and DIDs has a very different meaning than in everyday's language (where it means _'the act of jumping in a straight, upright vertical posture into the sea or other body of water from a high jumping platform, such as a cliff, bridge or harbour edge.'_)
+
+It stems from the development of ledger-based identities like Sovrin. Tombstoning means "Burry the transactions" Because Sovrin is a permission-ed ledger, the steward lets you read it - or won't let you read the transactions, depending of the situation whether the subject of the personal information has requested to be forgotten. A steward could say 'see, I've not published the personal information, so I am good.'. For other reasons, `tombstoning` has never been accepted as a viable solution to get rid of the liability issue.
+
+Tombstoning does not apply to KERI because in indirect mode KEL and KERLs will be ambient available and in direct mode their are only to parties involved. If a third party would be involved in direct mode, somebody would breach the understanding that it's private communication by design. _(@henkvancann)_
+
+To get even more security in terms of your signing scheme.
+(_SamMSmith_)
+
+To be able to horizontally scale your identifier system, that consists of a root identifier that manages a bunch of other delegated identifier. Created with a cryptographically derived strong binding, all the way through your infrastructure. Not dependent on any administration at all.
+(_SamMSmith_)
+
+Often it is an efficiency measure where the identifier includes the signature as your `content-addressable hash`.
+_(SamMSmith)_
+
+Its use is different. Many applications of self-certifying identifiers only require temporary use after which the identifier is abandoned. These are called ephemeral identifiers. Other applications may only attach a limited amount of value to the identifier such that replacing the identifier is not onerous.
+Because a non-transferable (ephemeral) identifier is not recoverable in the event of compromise, the only recourse is to replace the identifier with another identifier. In some applications this may be preferable, given the comparable simplicity of maintaining key state.
+In either of these cases a non-transferable self-certifying identifier is sufficient.
+
+This is a basic self certifying identifier (`SCI`). The identifier itself is derived from a public key that is in the identifier. Nothing is connecting that binding of the identifier to the inception statement. Someone could create an different inception statement with other fields, the only thing that need to be the same is the key list. Everything else in the inception statement could be different.
+So that means the only way to know which inception statement is the right one is duplicity detection. So `First seen` becomes the only means you have to check which inception statement is the authoritative for that identifier, in case you need an inception statement.
+
+This a self-addressing self-certifying identifier (`SASCI`) In this case the identifier itself is derived from the inception statement. Now there can only be one inception statement for this identifier. If you'd change just a single bit, other than the identifier field itself, and it's _different_ identifier. You can't have duplicitous inception statements. It's not possible. It locks down at least the inception part and that help in duplicity detection. There can only be one inception statement to start a duplicity log with. From that point on you can have duplicitous next events, but not before. But it still means the effort it takes has to engage in CreatING duplicity, becomes much harder because for example if you include witnesses in the inception statement then any duplicitous event has to publish through the witnesses, and that adds a barrier. Basically it locks down at least the inception part, You can't change it.
+In some cases it would be useful to be able to strongly bind the inception statement to the identifier and not merely rely on a cryptographically verifiable inception statement for the associated identifier.
+
+Because there are many applications where you don't want to have to depend on a KEL because a basic SCI is self-certifying without a KEL. It's more light-weight. For example the non-transferable version of a SCI you can still have an inception event so that basically any tracking anybody does there is still a nominal KEL for that identifier so you can look it up that way, discovering everything, there is always a legitimate version of an inception event for every identifier.
+
+In many cases you want identifiers that are ephemeral, that you know the only event that could be would be is the inception event. You don't need to see the inception event, if you're using it in an ephemeral context.
+E.g. witnesses use ephemeral SCIs so I don't need a key event log for a witness to verify a signature by a witness. You can do that with watchers as well. In applications like `IOT` where you need light-weight identifiers, you will mostly use SCI (1.). So you would use the basic version.
+
+Want you don't need to do with the basic identifiers is you don't have to say 'I got an identifier but I can't verify the keys before I get the KEL so I don't know the key state'. For the witness there is no key state. There is only ever one key. If the witness is ever compromised, then you get rid of the witness. You can rotate keys or rotate identifiers.
+Rotating an identifier is allowing us to change the keys for an ephemeral identifier.
+In an ephemeral context rotating the keys is the equivalent to rotating the identifier.\\
+
+> Example BTC and ETH they are ephemeral public keys, you can't rotate keys in BTC without changing the identifier. You have to move all your funds.
+
+In KERI the closest to 1. is DID:Key. Instead of having multiple DID methods, KERI unifies them all into one protocol.
+
+Look for more info in the KERI slide deck \["KERI for the DIDified"\](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security/| TBW | .md).
+
+_Identifiers are managed by systems and humans using systems. Identifiers are not actors. That sort of slippery language is the kind of meaningless hyperbole that borders on disingenuous._
+
+KERI's creator is using semantics from several different disciplines and then making _new_ semantics when there is not a good fit. So it all sound like new semantics. _But only a few are truly new to KERI._ But since we can't know what the set of new and not new is for any expert exactly, we can't know what to spend more effort on defining vs what to assume. That is why an [adaptive discussion](#q-as-an-ssi-expert-i-totally-can-get-stuck-in-the-semantics-of-keri-how-to-overcome-this) works much more efficiently.
+
+In short: A Sybil in KERI has at most the power of DDOS attack.
+
+KERI distributed hash table (DHT) is most vulnerable to Sybil attacking/corrupting a portion of a table. They can't rewrite the cache so a Sybil attack cannot invalidate KERI, but they can DDOS the pipeline of KELs with invalid KELs so the user never get a valid KEL to process. KERIdemlia would, for example, be DDOS-able if it were used to index KERI nodes; KERI verifying data before replicating it slows down DHT formation, but keeps the DHT safer from Sybil attacks via user-permission-ing or micro “reputation system”.
+Side note: user-permission-ing of watchers is where most of this verification happens at scale
+
+* * *
+
+* * *
+
+It's the basis of the source of truth for KERI identifiers. KERI enables cryptographic proof-of-control-authority (provenance) for each identifier. A proof is in the form of an identifier’s key event receipt log (KERL), after a validator verified the registered events, in the chain of events: the key event log (KEL).
+_(@henkvancann)_
+
+Without KELs, we wouldn't have a chain of registered and signed key events for an identifier. The availability and consistency of the KEL is crucial for next steps: verification of events and duplicity checks. Without verified KELs there will be no KERL for identifiers at hand.
+_(@henkvancann)_
+
+By a key [`inception event`](https://weboftrust.github.io/WOT-terms/docs/glossary/inception-event). A controller creates a key pair and binds this to his/her KERI identifier. There will be wallet software and an API available in the course of code development and also a DID scheme (DID:UN) that invokes calls to those APIs during resolution of the DID.
+_(@henkvancann)_
+
+It is secured by a `Distributed Hash Table`, so internal inconsistencies are cryptographically provable. If they they are internal consistent the first level of trust is established. Furthermore a KERL is end-verifiable to the root-of-trust. You don't need the whole KERL at all times [Read more why](https://github.com/henkvancann/keri/blob/master/docs/q-and-a.md#do-i-need-to-show-the-full-log-kel-to-anybody-i-transact-with-even-though-id-only-like-to-show-a-part-of-it-for-example-a-virtual-credential).
+KEL is considered a secondary root of trust (Whitepaper, Page 60/141, Section 7.35). _(@henkvancann)_
+
+In brief: the security of an identifier does not start with a KEL, the security starts with entropy.
+
+It is important to remember that KERI's security is based on the layering of thresholds. The whole is greater than the sum of it's parts. So while it seems that with a transferable identifier (one that can be rotated), the security of the identifier starts with its KEL, it does not.
+
+As with all identifier types (transferable and non-transferable), the security starts with entropy. The randomness used to create the private key is the absolute root of trust. Once you create the private key you retain the ability to prove control over your identifier by your ability to use the private key.
+
+With non-transferable identifiers, it ends there. With transferable identifiers, the next root-of-trust (and thus a secondary root-of-trust) is the KEL which provides the ability to rotate the keys of the identifier. Additional roots-of-trust layered on top of entropy and KELs include multi-sig support, delegation and witnesses.
+
+* * *
+
+* * *
+
+An internally inconsistent KEL, this simply won't verify. External inconsistency: two versions of the key event log (KEL).
+
+KERI takes advantage of its cryptographic root of trust with strong bindings, to get an inviable guarantee, based on both internal consistency for the cryptographic root of trust and external consistency using ambient duplicity detection.
+
+See the [definition](#duplicity). What it means is that we have a way to make judgments about trust in entities.
+_(@henkvancann)_
+
+Duplicity takes two forms. In the first form, a `controller` may be deemed duplicitous whenever it produces an event message that is inconsistent with another event message it previously produced. In the second form, a witness may be deemed duplicitous when it produces an event _receipt_ that is in- consistent with another event receipt it previously produced.
+_(SamMSmith)_
+
+Duplicity becomes a basis for distrust in a controller or its witnesses. _(SamMSmith)_
+
+Duplicity detection **buys validators protection** without the need of anything more than a duplicity detection network.
+
+* * *
+
+* * *
+
+Changing the key, i.e., replacing it by a new key. The places that use the key or keys derived from it (e.g., authorized keys derived from an identity key, legitimate copies of the identity key, or certificates granted for a key) typically need to be correspondingly updated.
+
+the main purpose of key rotation it to either prevent or recover from a successful compromise of one or more private keys by an exploiter.
+[Source](https://csrc.nist.gov/glossary/term/Key_Rotation).
+
+The primary purpose of rotating encryption keys is not to decrease the probability of a key being broken, but to reduce the amount of content encrypted with that key so that the amount of material leaked by a single key compromise is less.
+
+However, for _signing keys_ there is a concrete reason: say it takes X months of computation (expected value given your threat model) to crack a key, and you rotate your signing key every 𝑋−1 months and revoke the old one, then by the time an attacker has cracked the key, any new signatures produced by the attacker will either be A) rejected by clients because of key expiry, or B) back-dated to before the key revocation (which should also raise warning in clients).
+[Source](https://crypto.stackexchange.com/questions/41796/whats-the-purpose-of-key-rotation).
+
+KERI uses plain old digital signatures from PKI, intentionally, so that it may be truly universally applied. KERI solves that hard problem of PKI, that is, key rotation in a standard way. Without a standard way of addressing key rotation, there is no interoperability between systems, they break when you rotate keys because no one knows how to verify the key rotation was done properly. KERI solves that problem.
+
+Pre-rotation is a _cryptographic commitment (a hash)_ to the _next_ private key in the rotation-scheme. (_@henkvancann_)
+The pre-rotation scheme provides secure verifiable rotation that mitigates successful exploit of a given set of signing private keys from a set of (public, private) key-pairs when that exploit happens sometime **after** its creation _and_ its first use to issue a `self-certifying identifier`. In other words, it assumes that the private keys remains private **until after** issuance of the associated identifier.
+[Source: chapter Pre-rotation in whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
+
+I first wrote about in 2018, it's been public knowledge ever since. I guess people just don't read.
+(_SamMSmith_)
+
+![key rotation steps 1 and 2](https://weboftrust.github.io/keridoc/assets/images/key-rotation-muggles-steps1-2-88b623ce4e3328660d8f93b0d310c311.md) ![key rotation steps 3 and 4](https://weboftrust.github.io/keridoc/assets/images/key-rotation-muggles-steps3-4-922064c42aab37f10334b2f5cc14e463.md) ![key rotation steps 5 and 6](https://weboftrust.github.io/keridoc/assets/images/key-rotation-muggles-steps5-6-7bdca0f68e9255564558e70e205098a2.md) ![key rotation steps 7 and 8](https://weboftrust.github.io/keridoc/assets/images/key-rotation-muggles-steps7-8-85035989f89678b4a7b5fa00d26c5bac.md) ![key rotation steps 9 and 10](https://weboftrust.github.io/keridoc/assets/images/key-rotation-muggles-steps9-10-a9839c80847b60f0e36298d2d5dd15c9.md)
+
+* * *
+
+* * *
+
+The word 'Receipt' explains it all: the sender signs off the verification of the KEL done by the recipient. That _Receipt_ is hosted in the KERL and is the root-of-trust for KERI.\\
+
+![Direct mode: kel and kerl difference charted](https://weboftrust.github.io/keridoc/assets/images/Direct-mode-kel-kerl-ec30fcc3f6a40d973cb293455587b6f0.md)
+
+The analogy is the difference between a _two-way_ - and a _three-way handshake_: Did I, the recipient, only verify that the sender's message was valid (two-way using KEL, arrow left to right) or did the sender _sign off the receipt_ of that verification by the recipient (three-way in KERL, arrow right to left) _(@henkvancann)_
+
+In short, No, KERI has several fall-back options to deal with lingering enlargements of KELs or declining performance, if ever actual. And that is batching and horizontal scaling the issuers.
+
+Supposing we have a _big_ KEL, which means a long chain of hashed data, then there a few relevant features of KELs within KERI:
+
+-   A KEL will always be order of magnitude smaller than public blockchains, because they are more specialized structures that do not need to contain total ordering
+-   Once a KEL has been verified by a user, it can be archived by this user.
+-   The core key events in KERI like inception, rotation and delegation are worst case still irrelevant to the scale of volume of a KEL.
+-   The seals of Interaction Events don't need to be put in the KEL one by one, you could put a whole bunch of Transaction-seals in a _sparse Merkle tree_ and only register the Merkle root in the KEL.
+-   Private KEL are small per design, because in private interactions the identifier have no public value attached to them
+-   Public KEL can be associated with public entities like humans, organizations and devices and therefore accumulate value on the identifier through interactions.
+-   For security guarantee there is no difference between a big KEL and a small KEL. Both need to be internally consistent and verifiable to the root-of-trust.
+-   We have the opportunity to create delegated identifiers and delegate KELs. So a _big_ KEL is a _long_ KEL and has the features just described.
+
+1.  Create a new identifier, do a new association (or binding) to a public entity and spread the news in a reputational way. Abandon the old identifier but keep it live for future verifications of old events.
+2.  You can create a set of delegate KELs and issue verifiable credentials from those delegates. And load balance the size of your KELs by the number of delegates you introduce. And they all verify back to the same root-of-trust of the delegating identifier. Optional:
+3.  Gather all Interaction events of the _old_ KEL, which starts to grow too big, in a batch and anchor with a single Merkle-root hash to the _new_ identifier
+
+(@henkvancann) based on [IIW32](https://eu01web.zoom.us/rec/play/ymi1tW8_oy1ejYDnhtP6lw9DFSqmwWW32Vs-Savd_s-5dWuIOPOY9zZlhkoyDUQjqBA5eR12TK_8eX2m.5e_aDMp-J1c_t551?continueMode=true) recording of session _KERI: Centralized Registry with Decentralized Control (KEL & TEL ) + DEMO_\\
+
+* * *
+
+* * *
+
+_Looking at a certain identifier and controller, does the witness service, representing the controller, need to be replaced once duplicity is detected? For example after a dead key attack?_
+
+No. The service can be the same. KERI includes a cryptographic commitment to the identifiers of the nodes in the service. The compromised controller will have its own nodes and service but they are not the same as the original ones. As soon as you have a compromised controller than you also have a duplicitous service. For a validator to back up his choice of which service to choose is not hard, because it can be easily verified which service belongs to the original KEL.
+
+The [KERI slide deck](https://github.com/SmithSamuelM/Papers/blob/master/presentations/KERI2_Overview.web.pdf) has a section called the Duplicity Game. I suggest reading through that first. Or see the [part of the SSI Meetup](https://ssimeetup.org/key-event-receipt-infrastructure-keri-secure-identifier-overlay-internet-sam-smith-webinar-58/) webinar that tackles this.
+(_SamMSmith_) | TBW prio 2 |
+
+The data structures behind KERI are a special form of DHTs, but KERI is more than that (non-exhaustive list):
+
+-   a solid key management protocol
+-   verifiable DHT to the root-of-trust
+-   a direct and an indirect method of interaction about key event state
+-   duplicity detection
+-   various recovery mechanisms from duplicity, key loss or key compromise
+
+Witnesses do not make any statement about the content of what is being proved. KERI does not enable someone to proof the _veracity_ of a statement only the _authenticity_ of the statement.
+(_SamMSmith_)
+This is a very crucial concept in KERI: Authenticity first, plus the stingent division of making sure _who said it_ and _whether what was said is true or false_. The former is in KERI verifiable to the root of trust, which is a killer app compared to current the state of internet. The latter, finding out if someone speaks the truth, is not cryptographically verifiable; the veracity of a statement can only be attested (credentials) and weighed.
+(@henkvancann)
+
+It’s not **"first seen"** until it’s fully seen by the whole set of witnesses needed (threshold). In the meanwhile the witness in this instance, has to add an escrow. And wait for the witness receipts coming in. And then accept the KEL. _(@henkvancann)_
+
+Yes. It has \_complexity where as gossiping has the more "expensive"_nlogn_ complexity. However, _Round Robin_ has the characteristic of building up latency, which can be a burden in speed-sensitive use cases. A provision has been planned in KERI to offer best of both worlds.
+_(@henkvancann)_
+
+It means that the _threshold_ of the number of witnesses has been met, It doesn't mean that all witnesses have witnessed the event.
+
+| TBW, just soundbites from the meeting KERI WG April 6 2021 listed below | This is an extreme corner case. There is an additional requirement to add to the key state.
+
+In this situation a validator can't find the witnesses. Then they have to bootstrap from a new set of witnesses.
+
+The previous witness set needs to be able to (to have the add and remove list).
+
+It's a bridge, it's a forwarding service and is a temporary provision, until all the validators have seen the more recent key state. Witnesses witness an event that rotates them out. They don't sign the rotation event itself. It doesn't have to contribute to the first seen. It will be included in the key event log at the end of it.
+
+The Witness will provide meta data for how long it will keep up the forwarding service if it will become rotated out. The pull of the event by the validator has to be more frequent than that given time per witness that it will keep the forwarding service up & running.
+
+This is listed as an option in the white paper:
+
+The validator can include what he/she considers first seen: the previous set of witness _AND_ the current set of witnesses (after rotation) has to be fully signed. This makes it extremely difficult to perform a dead key attack (eclipse attack).
+
+The backside of this is that more and more controllers will become duplicitous as the requirements on _first seen_ are so strong.
+
+The primary purpose of the KA2CE 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.
+
+The witness strategy is variable by design. To which extend this disturbs depends on assertions.
+
+KERI doesn't give similar guarantees then a DLT. For an identifier system you don't need all that a DLT gives, you can do an identifier system without a DLT. All you need is what KERI gives. And then we define what KERI gives both the similarities and the dissimilarities in excruciating detail. And it is not true that a witness structure must do what a DLT does. It's much much simpler, which has been explained [here](#q-the-guarantees-stated-about-keri-are-inappropriate-without-a-particular-witness-structure). (_SamMSmith_)
+
+* * *
+
+* * *
+
+In a Public setting `duplicity detection` protects the validator from any duplicity on the part of the controller and any resources such as witness that are controlled by the controller.
+
+Since a given controller in a public setting may not know who all a given validator is using for duplicity detection (watchers etc), the controller can't ensure that they will not be detected. And once detected any value that their public identifier had is now imperiled because _any entity with both copies can proof irrefutably to any other entity that the controller is duplicitous (i.e. not trustable)_.
+(_SamMSmith_)
+
+_and introduce a centralized set of `Location Providers`, who you must trust to be nice and let you hop to another Location?_
+
+Your witnesses in KERI are _not_ under the control of any intermediary per definition. It’s a choice. And this choice is to be made by the controller. KERI is globally observable because its ambient availability. A validator gets the _signal_ from duplicity detection. And then the controller could indicate what’s going on (if the controller is not malicious of course).
+
+This how a `validator` can reconcile with a fallback mechanism (eg. key rotation). KERI does not guarantee liveness of the key state (example where you have liveliness of key compromise: a btc address and its authoritative key).
+
+Instead, KERI is a key compromise discovery mechanism. And if there is a compromise, you can send a signal. KERI is all about end verifiability of digital signatures. Digital signatures are legal contracts and it's dependent on the ecosystem governance framework how to avoid liability of the controller for the right key state. KERI does not answer that question. The liable controller can add on several layers in / with KERI to reduce the risk of the controllers liability. The risk that successful attacks can occur, can be diminished because they can add extra protection mechanisms.
+
+A verifier that gets a VC checks the issuer. with the public key.
+So it's approximately equivalent to resolving a DID in most cases.
+_(CharlesCunningham)_and_(RobertMitwicki)_
+
+_KERI has a content centric approach_: it's what we get and not where we get it. So as soon as you have the KEL (get it from anywhere, what matters is the consistency of that log. The public key is stored in the KEL.
+
+Both are validators. Jurors report duplicity, validators won’t.
+
+* * *
+
+* * *
+
+It is. Sections 2.2.3 - 2.3.1 of the [white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf) explains transferability and the "basic"-type identifier, which always represents a public key and may be either transferrable (can be updated) or non-transferrable (ephemeral/did:key style). section 14.2 actually details how these are encoded, basically check the first few chars of the identifier.
+_(CharlesCunningham)_
+
+_In many ways KERI is "better" than DIDs, especially when it comes to proof-of-control. But I think this is one thing that DIDs can do that KERI can't: verification methods which are not based on public keys or even any cryptography at all._
+
+KERI can support them, with some special event type, they use it to store CRDT ops.
+(_@OR13b_) The point of KERI is to maintain to control of key-derived identifiers. It's not intended to provide all the capabilities of DID.
+(_@\_stevetodd_)
+
+_Although some DIDs have not kept up with design goals_ of DIDs, e.g. did:web, it is too strong to state this in general. It simply depends on the DID method?
+_decentralization, persistence, cryptographic verifiability._
+
+In brief: we argue that the chain is as strong as its weakest ring.
+
+Security is not build into the protocol but indeed as the elaborate question mentions, it depends on the DID method. Which overall is a huge risk for community as people needs to know the security level which each did method brings. From that perspective without unified security model brings us to the similar situation where, me having private email server in the basement to avoid spying by google, I send out my e-mail to you having it on gmail. I have high security and privacy but other side have just security without privacy. The outcome is that security model is applied in wrong place and KERI aims to fix it.
+_(RobertMitwicki)_
+
+We would like to see some examples of verification methods that are not based on cryptographic keys and are in the scope of DID. The KERI community would like to learn more about these methods. It's true KERI is all about cryptographic commitment. But KERI can also support hashed based identifiers e.g. a fingerprint of the content as unique identifier, without the control part.
+
+_How might one build a decentralized deterministically iterable registry for such use cases where the entries are securely known to be from the matching Identifier?_
+_The reason I am asking is to get people to think about the system they'd inevitably need to create to support the 95% of use cases (given 95% of identity interactions are between personas of people, places, and things that are discoverable)_
+_Is it not a helpful exercise to game out the things required to support 95% of DID use cases with other DID system developers?_
+
+It's considered a privacy property of KERI, that you cannot enumerate all identities, in the same way that finding all minorities of certain religious preference might not be a feature.
+(_@OR13b_)
+
+Discovery is a layer on top of what KERI provides. KERI doesn't preclude DID, nor does it need to implement all of DID. KERI will participate in the DID ecosystem. (_@\_stevetodd_)
+It doesn't need/want to solve/serve that slice of the use case pie.
+```
+The vast majority of users use apps and services that are exchanges between or about the well-known,
+publicly resolvable registered persona DIDs of people, places, or things?\
+Let's list a few to see how much of human digital life it covers:
+* All social media: Twitter, Facebook, Instagram, Telegram, Signal, etc.
+* All public content creation: YouTube, SoundCloud, Spotify, etc.
+* All current registries: NPM, all app stores, all things that use those registries
+    (basically every piece of software on the planet)
+* All publicly registered objects: cars, boats, airplanes, etc.
+Put it this way: very few use cases on this planet will not directly, or within them,
+rely on publicly iterable, globally registered persona DIDs.
+But that said, I'm interested in hearing other opinions or counter arguments to the contrary.
+(_@csuwildcat_)
+```
+_There is an implicit need for the registry to track its entries as DIDs. I guess those 95% use cases will have to get other types of DIDs for that?_
+
+It's possible to make a DID doc that represents a KERI identifier. If you want to resolve it, you can put it in any number of blockchains. That just publishes it. However, they don't have to be published to work.
+(_@\_stevetodd_)
+
+Or for example TOR hidden services, these are not designed to be discoverable. In fact, the whole point of tool is to provide anonymity. Anonymity is a property of set membership, and it's destroyed by making the sets small or enumerable. (_@OR13b_)
+
+In many scenarios, what the elaborate question explains makes sense. I can understand a different design goal/priority for KERI, I think the rationale is quite clear in terms of where it stands in the DID space. (_@fimbault_)
+
+_You can't have Registry A magically just trust that a DID from Other System B, it would need to be native to it?_ _Any registry with deterministically resolvable entries requires the entry controllers' IDs and resolutions be native to it. That's an empirical computer science wall type of requirement._
+_Imagine I want to register a DID in a decentralized deterministically iterable registry - something anyone can run and deterministically know all entries registered with it, wherein the registry has no central entities or authorities that determine the bindings between entries and those who control them..._\\
+
+**_Nowhere in any paper on this planet is this a solved problem, because it's basically NP hard_**
+
+It depends on what you mean by resolve. The [white paper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf) explains the points brought up in this question. (_@\_stevetodd_)
+
+| TBW prio 1 |
+
+It's considered a privacy property of KERI, that you cannot enumerate all identities.
+_(@Or13)_
+
+* * *
+
+* * *
+
+Harm that can be done to the a `controller`: Unavailability, loss of control authority, externally forced duplicity
+Harm that can be done to a `validator`: _Inadvertent acceptance_ of verifiable - but forged or duplicitous events.
+
+Breaking the promise of global consistency by a controller is a provable liability. However, global consistency may only matter after members of that community need to interact, not before.
+(_SamMSmith_)
+
+KERI changes the discussion about security. From a discussion about the security of _infrastructure_ to a discussion about the security of your _key management infrastructure_. Most people when they think security, the think "oh, blockchain!": permission-ed or permission-less, how hard is it to get 51% attack, etc.Non of that matters for KERI. KERI is all about "are your private keys private?!" And if _yes_, that drastically slims down the security discussion to brute force attacks to public keys. And because the next public keys are in fact protected by a hash, you have to brute force the hash algorithm, that is post-quantum secure. So that is a very high level of infrastructural security.
+
+So private key management and protection is the root of your security in KERI.
+
+_Suppose I'd trust a Tangem card for generating public private key pairs at will and the NFC communication allowing to interact with a wallet app._
+
+One of the main concerns is that there is a theoretical link (a binding) between the cards and a user, via the card-ID (CID). However the CID is used only for checking the authenticity and integrity of the chip itself. Tangem publishes and anchors a list of CIDs with corresponding public addresses in a public blockchain. When checking authenticity, the verifier looks up the pub CID and corresponding pub address in the published list, and verifies that the chip controls the correct pub address by means of a challenge-response scheme. Even though for blockchain or SSI interactions, a completely new wallet with new pub/priv key pair is generated, the pub/priv key of the CID is used when the authenticity of the chip is checked by means of a challenge response scheme. Everything happens in the client app (2021: iOS or Android; and the client code is open source), where there is no communication with Tangem, so Tangem is not able to see any activity conducted by this CID in an authenticity check. The CID and corresponding key pairs are not used in any other interaction. A new wallet with new pub/private key pair is generated on chip, with these keys being used for any transactions, signing, etc.
+
+Q: With the chip firmware being proprietary, how can we be sure that the newly generated private keys for new wallets are not still linked somehow to the cards CID? A: The firmware is audited by Kudelski and can be verified with a published hash. TBD: How can it be verified, when and by whom? If the firmware is not open source, then somebody has to draw a hash from it in an authorized situation. However, Tangem cards are EAL6+ and FIDO2 certified.
+
+On the issue of Rotation: | TBW prio 2 |
+
+The immutable linear chronology is provided by the key event log (`KEL`) data structure itself. Getting a full copy is all you need. When retrieving a KEL over a network, then as you say a witness can prune some amount of the latest events, but every witness would have to be compromised for that to be undetectable.
+If parties are so concerned, they could establish a large collectivized set of witnesses that sign and distribute all key events presented to this network (this would essentially be a `Proof of Authority`/federated blockchain but would require (configurable)% compromise for undetectable pruning of recent history. Only PoA/federated because the witness sets are designated by the controllers, so you could not just use arbitrary witnesses who join and leave the network at leisure (afaik).
+
+The difference between the chain and the DHT is that not all DHT nodes act as witnesses for all KELs in the system (in the sense that they don't provide receipts for every KEL and aren't referenced in the witness sets of every KEL), but they could all (or at least the ones holding the KEL you seek) still provide availability for KELs and thus would have to all be compromised in order to hide a recent-history-pruning, only one has to transmit the new/complete version to prove all the other versions as being old/incomplete.
+_(CharlesCunningham)_
+
+The point of KERI is to encapsulate all the guarantees within `KEL`s nothing else is needed. DHT is just for resolution process to find a place from where I can get it. This place can change as you like I could even get it in p2p interaction from someone else. DHT seems to be the most reasonable way to build solid infrastructure for resolution process but none of the nodes can actually inject or tamper KELs so you don't have to trust them or get any guarantees from them. Since if the node will miss behave it is very easy to detect that.
+_(RobertMitwicki)_
+
+_...you would be fundamentally arguing that you can record a singular, immutable linear event history more securely than Bitcoin, and I see nothing in KERI that would indicate that._
+
+Read the answer to [this](#keri-is-basically-a-series-of-pay2publickeyhash-transactions) first.
+
+If you read Szabo's paper on threshold structures, you get security of the same type when ever you use a threshold structure, be it MFA, Multi-Sig, or Distributed consensus. They all are using a combination of multiple relatively weak attack surfaces that must be simultaneously compromised for a successful attack. So multiplying simultaneous weak surfaces = functional equivalent of a stronger attack surface. So when you look at KERI you see that the security is primarily due to cryptographic strength and the witnesses are not the primary source of security but merely secure one thing, that is the availability of the KEL for an identifier. Not the KEL itself. The KEL itself is secured by signatures.
+From a Validator perspective their security is due to duplicity detection. Successful attack against duplicity detection requires an eclipse attack. Ledgers such as bitcoin are also susceptible to eclipse attacks. So in an apples to apples (resistance to eclipse attack) a KERI watcher network of comparable reach (1000's of watchers) would have comparable resistance to an eclipse attack.
+
+-   Where KERI doesn't need total ordering in its logs, blockchain do need that. What KERI needs is watchers that construct string of event in the relative order of reception of the KEL | TBW please explain or improve this: what is this, why is it important? |
+-   Another characteristic is that KERI identifiers are transferable and blockchain-based identifiers are not, they are bound to their ledger.
+
+_An escrow cache of unverified out-of-order event provides an opportunity for malicious attackers to send forged event that may fill up the cache as a type of denial of service attack. For this reason escrow caches are typically FIFO (first-in-first-out) where older events are flushed to make room for newer events. \[Paragraph 11.3.1\] ([in KERI WP](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf))_
+_Question: how does FIFO prevent effective DOS attacks?_
+
+By load-balancing the incoming messages. If you don't have any load-balancing, the messages are going to be processed First In First Out. Only when an attacker has full bandwidth available to overload the buffer, they could frustrate the process to get honest messages in. As soon as you’re able to balance the receipt of messages in the buffer, you’ll be able to get the right messages (from honest senders) through. (_@henkvancann_)
+
+\*Which is not true for bitcoin. Nobody gets to alter the witness strategy of bitcoin without a HUGE amount of demonstrable proof, politicking, and advocacy. Most of my problems with innovative DLTs or other distributed systems are that I struggle to internalize **how they actually guarantee anything\***
+
+If you are very familiar with `PoW` and therefore Bitcoin and Ethereum but not _non-PoW_ `Byzantine Agreement` (`BA`), that where the cutting edge is for understanding the security model of KERI.
+_Non-PoW_ `Byzantine Agreement` (`BA`) and therefore KAACE on KERI witnesses which are a simplified variant of BA and under the hood look nothing like proof of work. Actually KERI with witnesses and KAACE looks the most like Stellar an open permission-less `Byzantine Agreement` algorithm. If these concepts are unfamiliar to you, yu might as a result have no intuition about why KERI could work because you then have little familiarity with distributed consensus mechanisms that provide PoW like guarantees, but are not `PoW`.
+Actually BA came years before PoW so its the other way around (PoW provides BA like guarantees) but thats a quibble. So anyone trying to grasp how KERI security is guaranteed should first learn how _non-PoW_ BA works before he/she could begin to believe why KERI could even work at all. Once you see this, then the dominos will start to fall.
+
+_...and then you have to evaluate the witness strategy, which means KERI on its own doesn’t have the guarantees that the KERI creator keeps claiming._
+
+A KERI witness structure never needs to provide total ordering (where total ordering is precisely defined in the literature for distributed consensus algorithms as providing one ordering for the union of transactions from multiple sets of transactions from multiple sets of clients where each set of transactions is ordered independently by each client that generates it. I.e. all the transactions from all the clients are combined into one set with one ordering = one total ordering. Most people can't define this correctly whenever asked.
+
+Byzantine fault tolerant total ordering is the hard problem of distributed consensus. **Safe agreement which is all that KERI provides is much much simpler.** So almost any witness structure is much simpler and will still work good enough. And its not the witness structure alone but the witness and watcher structure:
+
+-   Witness for controllers
+-   Watchers for validators
+
+Both are simpler consensus mechanisms compared to DLT algorithms. Distributed consensus describes a family of algorithms of which BFT Total Ordering distributed consensus is a subset. Pretty much all cloud databases that have redundant copies use some form of distributed consensus for synchronizing the copies of the database. They all use some form of authentication for securing that consensus but they are not in any real sense of the term using Byzantine Fault tolerant total ordering distributed consensus. Setting up witness pools and watcher pools in KERI is of comparable complexity to spinning up a redundant Postgres or CouchDB cluster. So KERI's guarantees come from nothing much more complicated than that. Nobody thinks that a CouchDB cluster is too complex to understand but few actually know the algorithmic details of its low level of distributed consensus.
+(_SamMSmith_)
+
+_How can I bind external key material to AIDs, such that the AID retains its own key, but picks up an association to an additional key that has meaning elsewhere?_
+
+In ascending degree of security:
+
+1.  BADA policy, you don't anchor to a KEL. It's a date-time stamp together with the keystate
+2.  Put a seal in your KEL. You can do this by creating an interaction event with the KLI.
+3.  Add a TEL for the key material and thus add additional security
+
+
+
+
+---
+title: Q&A about KERI
+description: This document is part one. Part two is Q-and-A Security. Both files shares a common Glossary that has:
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/education/q-and-a/index
+  md: https://weboftrust.github.io/keridoc/docs/education/q-and-a/index.md
+---
+
+# Q&A about KERI
+
+[![](https://hackmd.io/Ox_1L3adTdCEkcFtAzuTFA/badge)](https://hackmd.io/Ox_1L3adTdCEkcFtAzuTFA)
+
+This document is part one. Part two is [Q-and-A Security](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md). Both files shares a common [Glossary](https://weboftrust.github.iokeridoc/docs/category/glossary) that has:
+
+-   an alphabethically ordered list of **abbreviations**
+-   an alphabethically ordered list of **definitions**
+
+![Keri logo](https://weboftrust.github.io/keridoc/assets/images/Keri_logo_color_on_white-ea588f4caf977d258a44ef6377e68378.md)
+
+**The questions are of a varied level: basic and detailed. The answers are mostly directed towards generally interested people and newbies.**
+\*Q = one star question. Novice to KERI, advanced in DIDs
+**Q = two star question. Proficient in DIDs and advanced in KERI
+\***Q = three star question. Expert in DIDs and proficient in KERI
+
+To get a different angle to the same topic: KERI.
+
+KERI receives three types of scrutiny from domain experts:
+
+1.  "KERI can't do it"
+2.  "KERI doesn't do something new"
+3.  "DID:XYZ has been designed, KERI needs to explain how it's different"
+
+-   Ad 1. When respected colleagues think KERI can't keep up to its promises, we value the well-founded questions and suggestions of domain experts **after** they thoroughly read the KERI [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf). We'll happilly keep explaining KERI because we'd hate it when respected experts misunderstand the design.
+-   Ad 2. After a while some experts say 'well then KERI doesn't do something new'. That's acceptable for us, because we're able to prove the design history of KERI and that it simply hasn't been done before.
+-   Ad 3. However, we can't accept having to explain the differences to people who just "invented" something new, something similar to KERI, using the same terms and thereby spreading confusion. Let the newbees benchmark themselves against KERI. We're moving forward with CESR, ACDC, OOBI etc.
+
+May this Q&A be able to help you acquiring deep knowledge about KERI.
+
+We welcome every form of positive contribution and will certainly allow for learning time!
+
+**The questions are of a varied level: basic and detailed. The answers are mostly directed towards generally interested people and newbies.**
+\*Q = one star question. Novice to KERI, advanced in DIDs
+**Q = two star question. Proficient in DIDs and advanced in KERI
+\***Q = three star question. Expert in DIDs and proficient in KERI
+```
+| TBW | means: to be written
+| TBW prio 1 | means to be written with the highest priority, 3 = no urgency, 2 = average importance |
+```
+-   [Q&A about KERI](#qa-about-keri)
+
+    -   [Disclaimer](#disclaimer)
+    -   [List of questions and definitions](#list-of-questions-and-definitions)
+    -   [Knowledge you should be confidently applying](#knowledge-you-should-be-confidently-applying)
+    -   [Actions you should be comfortable with](#actions-you-should-be-comfortable-with)
+-   [Jump table to categories](#jump-table-to-categories)
+
+
+Inspired by presentation given and questions asked on the [SSI webinar May 2020](https://ssimeetup.org/key-event-receipt-infrastructure-KERI-secure-identifier-overlay-internet-sam-smith-webinar-58/), but also issues raised and the progress made, here on Github (Turn on 'Watch' if you want to be notified of conversations).
+
+Beware: A Q&A is always _work in progress_. Tips & help welcome.
+
+Some of the respondents in the **open** repo and presentations have been explicitly named as a source, like _Samuel M. Smith Ph.D._, _Charles Cunningham_, and _Orie Steel_. If there is no reference added to the answers, then it's a mixture of sources and edits in the question. Most of the editing is done by @henkvancann, which might have introduced omission, errors, language glitches and such. Sorry for that, feel free to correct by submitting a pull request (PR).
+For practical reasons educational images uploaded by Github members have been downloaded. We de-personalised them by giving images a new name. Under these new names these images have been uploaded to github and used in the Q&A to clarify the questions and answers.
+
+KERI's content is licensed under the [CC by SA 4.0. license](https://creativecommons.org/licenses/by-sa/4.0/). Parts of the video offered on SSI Meetup webinar 58 have been captured and uploaded to Github to support the answers to general questions about digital identity and more in depth answers to question about KERI.
+
+We've done our best to protect the privacy of Github users by investigating the images we used. We haven't come across personal identifiable information (pii). However, should we have made a mistake after all, please let us know and we'll correct this immediately.
+
+|TBW|
+
+-   The definitions in the [glossary](https://weboftrust.github.iokeridoc/docs/category/glossary)
+-   Public private key pairs
+-   Hashing and hashes
+-   Signatures
+-   W3C DIDs
+
+-   Accrue knowledge and keep existing knowledge up to date
+-   create a key pair safely and back it up safely
+-   sweep to a new wallet
+
+-   [General](#qa-section-general)
+-   [Why the internet is broken](#qa-section-why-the-internet-is-broken)
+-   [Open source licenses](#open-source-licenses)
+-   [KERI and DIDs](#qa-KERI-and-dids)
+-   [Wallets](#qa-section-wallets)
+-   [Signatures](#qa-section-signatures)
+-   [Proofs](#qa-section-proofs)
+-   [Private Key Management](#qa-section-private-key-management)
+-   [Blockchain](#qa-key-blockchain)
+-   [Root of trust](#qa-section-root-of-trust)
+-   [KERI operational](#qa-section-keri-operational)
+-   [Agencies](#qa-key-agencies)
+-   [Virtual Credentials](#virtual-credentials)
+
+-   [Q&A section KERI security considerations](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-section-keri-security-considerations)
+-   [KERI operational security](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-section-KERI-operational-security)
+-   [Identifiers](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-section-identifiers)
+-   [Event logs](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-section-event-logs)
+-   [Inconsistency and duplicity](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-inconsistency-and-duplicity)
+-   [Key rotation](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-key-rotation)
+-   [KEL and KELR](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-section-kel-and-kerl)
+-   [Witness](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-section-Witness)
+-   [Watchers](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-section-watcher)
+-   [KERI and blockchain settled DIDs](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-KERI-and-blockchain-settled-dids)
+-   [Security Guarantees](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md#qa-security-guarantees)
+
+* * *
+
+* * *
+
+Key Event Receipt Infrastructure; a **secure identifier overlay** for the internet.
+Hmm, a mouthful of terms. Let's start with the identifier. One of the basic (!) forms of KERI identifiers is this example:
+
+![identifier](https://github.com/WebOfTrust/keri/blob/main/images/basic-scid.png?raw=true)
+
+"Complexity" is relative. Compared to what is KERI and ACDC complex?
+
+Based on the constructive ideas the founder Samuel Smith has developed over time in his career plus the awareness that in the self-sovereign identity field there had been to little attention for security as the most important feature of digital identifiers, KERI had to be build from the ground up.
+
+The main design principles have a designated page "[Concepts](https://weboftrust.github.io/keridoc/docs/concepts/intro.md)" but in brief:
+
+1.  Security first, confidentiality second, privacy third
+2.  Offer a remedy for the [broken internet](#qa-section-why-the-internet-is-broken)
+3.  Minimal sufficient means
+4.  Use of proven -, seasoned -, but _dumb_ cryptography
+
+This lead to the understanding that KERI in nothing is like something else in the SSI space. It's the [Internet identifier Platypus](#keri-the-internet-identifier-platypus).
+
+Because of this many new concepts and new terms had to be specified, and always thoroughly anchored in relevant scientific resources. A new type of language emerged, not seldom lovingly addressed as a "Sam-ism" (referring to the language used by its founder). According to KERI's objective (and ACDC's follow-up on this in the Verifiable Credentials arena) the \[Universal Identity Theory\] (.md) could be completed. Hence, KERI's complexity stems from three main aspects of its current nature:
+
+-   it's a new concept
+-   it's different from anything else in the field
+-   it's all encompassing
+
+There are some reasons why KERI might be perceived as complex where instead it could involve other aspects:
+
+-   KERI is the new kid on the block who undermines reasons for existence of others with a pretty solid case. The KERI team calls this _progress_ and whoever it involves might have to reconsider their tenets. All are invited to merge efforts or contribute to KERI and move forward together. The KERI team wishes to contribute to other projects as soon as it's move forward.
+
+-   People think they could pick some ideas from KERI and then bolt this onto there own developments. This doesn't advance clarity in the field. Moreover, KERI's design principle (3. above) "Minimal sufficient means" causes that the KERI team are very much interested in what somebody think he/she could leave out and still meet all the fundamental objectives; `security` to begin with.
+
+
+Yes, KERI is perceived as being complex, we won't deny this or look away. We're working as hard as we can to create educational resources, explanatory websites and we will continue to do so. The current (fall 2022) resources listed below.
+
+[Technical Concepts](https://keri.one/keri-resources) developed by and explained by prof. Samuel M. Smith
+Direct links: All relevant [white papers](https://github.com/SmithSamuelM/Papers) and a table of [IETF-drafts](https://github.com/WebOfTrust/keri) of which the status is kept up to date.
+
+Explanatory articles from Henk van Cann about KERI, CESR, OOBI, Autonomic identifiers:
+
+-   [Medium-articles](https://medium.com/happy-blockchains) with a bit more sophisticated layout and response options. Medium is a company.
+-   [Markdown alternatives](https://henkvancann.github.io) on Github userpage of Henk van Cann
+
+[KERI](https://github.com/SmithSamuelM/Papers/blob/master/presentations/KERI_for_Muggles.pdf) and [ACDC](https://docs.google.com/presentation/d/1mO1EZa9BcjAjWEzw7DWi124uMfyNyDeM3HuajsGNoTo/edit#slide=id.ga411be7e84_0_0) for Muggles by Drummond Reed / Sam Smith
+
+[Docs](https://github.com/WebOfTrust/keri/tree/main/docs) about technical concepts behind KERI: Questions and Answers [general](https://github.com/WebOfTrust/keri/blob/main/docs/q-and-a) and focussed on [security](https://github.com/WebOfTrust/keri/blob/main/docs/q-and-a-security.md), [Glossary KERI Suite](https://weboftrust.github.iokeridoc/docs/category/glossary)
+
+Explanation of KERI development tools and techniques (preliminary link): [KERI development environment](https://github.com/henkvancann/keri-1/blob/main/docs/keri-dev-env.md)
+
+Howto's of WebofTrust documentation effort in github project page: [Howto](https://github.com/WebOfTrustkeridoc/tree/gh-pages/howto)
+
+This is most probably the form in which you might get to see KERI (just as an example!):
+```
+BDKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0
+<- this the bare bones _identifier_
+
+did:aid:BDKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0/path/to/resource?name=secure#really
+<- this is _a call to resolve_ the identifier on the web
+```
+Currently `KERI` is just code, that can be tested and executed in a terminal on the command line. Private key management of KERI will look like `wallets`.
+Key Event Logs (`KEL`) and Key Event Receipt Log (`KERL`) are files with lots of encrypted stuff in there.\\
+
+![key event log](https://github.com/WebOfTrust/keri/blob/main/images/key-event-log-muggles.png?raw=true)
+
+_(@henkvancann)_
+
+It does not require the current internet and it's protocols to change, nor Trust over IP (`ToIP`) system or current blockchains to change. KERI can be added to it and, nevertheless, KERI can function all encompassing. (_henkvancann_)
+
+Because there is no secure universal trust layer for the internet, currently (2022).
+KEI is both privacy preserving and context-independent extensible. This means KERI is interoperable across areas of application on the internet. It does so securely, with minimal sufficient means.
+
+> Sam Smith: KERI essentially repairs internet.
+
+KERI solves the _Secure Attribution_ problem, which means that we can be a 100% sure "who said what" over the internet. KERI does so by the _security and authenticity first_ adagium, signing all key-state-changing events in a hash-chained log file (`KEL`) and this log is cryptographically verifiable to the `root-of-trust`. Additionally in the _decentralized identity_ space KERI solves the **portability** of Self Sovereign Identifiers. Currently you can't move the identifiers you control from one platform or one infrastructure to another. And that makes your self-sovereign identifiers not truly self sovereign. KERI fixes this too.
+
+Because we've been reconfiguring and rethinking the security guarantees behind decentralized identity systems since 2015. To overcome the lack of _portability_ in the current decentralized identity systems, we've introduced a few new concepts that some people in the decentralized identity ecosystem have trouble to get their head around. Especially the blockchain-oriented part of the community.
+
+There is a whole section to answer this simple question that has many-sided answers: [KERI and DIDs](#qa-KERI-and-dids).
+
+To begin with KERI has no blockchain, and doesn't depend on blockchains. If an implementation of KERI depends on blockchains at all, KERI operates blockchain agnostic.
+Secondly, KERI doesn't support a crypto currency. It doesn't need a native currency because it can easily connect to one, if needed. And again, KERI is crypto currency agnostic while doing so.
+Lastly, KERI is fundamentally different from blockchains like Ripple (Permissioned PBFT consensus) or Stellar (incomplete open public, non-permissioned PBFT consensus): it doesn't need **total ordering**, time stamping and Proof of Authority consensus on transactions registered on a ledger.
+
+Blockchain and KERI is comparing apples and oranges. But we're happy to do that exercise for the hard-to-convince part of the SSI community.
+
+![Platypus](https://weboftrust.github.io/keridoc/assets/images/platypus-895aa7449c777d4e6a5c6cd9a757971c.md)
+```
+KERI is nothing like we already know of. It's a mixtures of things.
+You can't say _"Oh, KERI lays eggs, so it must be a reptile"_ It's not a reptile.
+And then you go _"I see, but it gives birth, so it must be a mammal"_.
+It's also not a mammal. It's KERI.
+It may have the characteristics you describe, but it's a species of its own.
+(*SamMSmith*)
+```
+KERI better fits the Identity space. Doing away the total ordering in blockchains is a huge performance - and throughput gain, plus less worry about governance. There's also not such a thing as consensus forks. KERI solves (or _"gets away with"_ if you wish) this by a mechanism called **duplicity detection**. Watchers are all that matter. They guarantee that logs are immutable by one very simple rule: **"first seen wins"**.
+
+There is a separate [Q&A Security](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md) to answer the extensive list of Security related questions.
+
+WASM is certainly on the road map, but for the main issue of Sidetree and did:peer interop, see the [core KERI spec repo issue](https://github.com/decentralized-identity/KERI/issues/79) for more info.
+_(CharlesCunningham)_
+
+The ToIP stack has a left side (governance) and the right side (technical)
+
+![Trust over IP stack](https://github.com/WebOfTrust/keri/blob/main/images/trust-over-ip-stack.png?raw=true)
+
+KERI is at lower levels of the ToIP. Other DID methods will add KERI to their method and that's how KERI could be present in these layers.
+
+[Trust-over-IP](#trust-over-ip):
+
+-   Its goal is to be the missing authentication layer of the internet. That's a pretty well matching objective.
+-   Layer 1 (settlement layer): Where other `DID`s use blockchains or databases to register identities and settle 'transactions' between between, `DDO`s, and `VC`s, KERI uses homegrown native structures: `KEL` and `KERL`. _(@henkvancann)_
+-   Layer 2 (communication layer): Non-existing in KERI, because KERI is end-verifiable. KERI can use any other means of communication between actors in the ecosystem
+-   Layer 3 (transaction layer): Since KERI focuses on the more fundamental part of authentication for the internet, you won't find matching functionality for usual trust-over-IP transaction like VCs or money. VCs (layer 3) relate to KERI only as content hash pointers in KELs, there are no native structures for VCs present in KERI.
+-   Layer 4 (application layer): Same: KERI is non-existing in this layer.
+
+To summarize: **Once we talk DID, we already talk about layers above KERI.**
+_(@henkvancann)_
+
+[W3C DID](https://www.w3.org/TR/did-core/):
+
+1.  The KERI developers provisionally design DID:KERI, which might become a mixture of DID:KEY, DID:PEER, and DID:WEB, combinable with more functional DIDs in the Identity spectrum DID:SOV, DID:ETHR, etc.
+2.  No verifiable credentials _(@henkvancann)_
+
+KERI solves the problem of **secure attribution to identifiers**. By using self-certifying identifiers (`SCI`s) and ambient availability of verifiable Key Event Logs (`KEL`) that prove authoritative control over identifiers' private keys. It can't be solved by other solutions known so far because those solution have not managed to span identifier interoperability over the internet and function all the same as an overlay. _(@henkvancann)_
+
+![self-certifying identifiers](https://github.com/WebOfTrust/keri/blob/main/images/sci-muggles.png?raw=true) ![key event log](https://github.com/WebOfTrust/keri/blob/main/images/key-event-log-muggles.png?raw=true)
+
+On github KERI\[^1\] is - and will become even more - a thickening bunch of repositories:
+
+1.  [KERIpy](https://github.com/weboftrust/KERIpy) Python Implementation of the KERI Core Libraries
+2.  [KERIjs](https://github.com/decentralized-identity/kerijs) JavaScript (nodes) Implementation of the KERI core library.
+3.  [KERIgo](https://github.com/decentralized-identity/kerigo) Go implementation of KERI (Key Event Receipt Infrastructure)
+4.  [KERIox](https://github.com/weboftrust/keriox) Rust Implementation of the KERI Core Library
+5.  [KERI Java](https://github.com/stevetodd/keri-java) Java implementation of KERI
+
+-   [KERI Interactive Web Interface](https://github.com/WebOfTrust/kiwi)
+-   [Wallet](https://github.com/WebOfTrust/keep)
+-   There is a variety of other tools, of we've described their main reason why the team have chosen them, why they matter to KERI, and why they were preferable above other alternatives in this [Development Environment of KERI](https://github.com/henkvancann/keri-1/blob/main/docs/keri-dev-env.md) document.
+
+-   [KERI general](https://github.com/weboftrust/KERI) Key Event Receipt Infrastructure - the spec and implementation of the KERI protocol
+-   [did:keri](https://github.com/WebOfTrust/did-keri)
+-   [Composable Event Streaming Representation (CESR)](https://github.com/WebOfTrust/ietf-cesr) Working area for the individual Internet-Draft
+-   [CESR proof signatures](https://github.com/WebOfTrust/ietf-cesr-proof)
+
+The founder of KERI is _Samuel M. Smith Ph.D._, operating from his firm [prosapien.com](https://www.prosapien.com). Other people working on KERI can be found via the Github Repos above.
+_(@henkvancann)_
+
+In Python and Rust. It was available in Java, Javascript and Go too (2021) but these projects seem to be inactive. Check the last modified dates on their repositories and/or forwards to other projects that those repos have linked. _(@henkvancann)_
+
+KERI is not primarily about self-sovereign identity. KERI is primarily about autonomic identifiers, AIDs. That is: identifiers that are self managing. KERI provides proof of control authority over the identifier. What one does with the identifier is not constrained by KERI. But because the primary root of trust of an AID is a KEL which can be hosted by any infrastructure, any identity system (SSI or otherwise) built on top of KERI may also be portable.
+So in my opinion portability of the associated identifiers is essential to any truly self-sovereign identity system.
+(_SamMSmith_)
+
+Where Christopher Allen is talking about _portability of information_ related to the identity, in KERI we take this a step further with the _portability of the identifier itself_ with respect to its supporting infrastructure (aka spanning layer). Most `DID` methods do not have portable identifiers. They are locked to a given ledger.
+(_SamMSmith_)
+
+Yes, KERI sat under the _Decentralized Identity Foundation_, [DIF](https://identity.foundation), and was part of the _Identity and Discovery_ Workgroup. In 2021 the increased activity around KERI and its specific nature needed to have an own group within DIF. There are also non-formal relation with the newly launched trust-over-ip foundation, and there's good reasons to fit KERI into trust-over-ip.
+In 2022 KERI sits mainly under [WebOfTrust](https://github.com/WebOfTrust), which is a github repository collection of _Standards Relating to a Web Of Trust Based on Autonomic Identifier Systems_
+
+The integrated work also leads to [IETF](https://datatracker.ietf.org/person/sam@prosapien.com) drafts. The value statement and organizational principles of the IETF strongly resonate with KERI. Read more about why IETF [here](https://github.com/WebOfTrust/keri/blob/main/README.md#why-ietf).
+
+The work is done together with TrustoverIP in the Task Force [ACDC](https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force). (_SamMSmith and @henkvancann_)
+
+See the [definitions](#normative) section for what both terms mean. For example, theories of ethics are generally `normative` - you should not kill, you should help that person, etc. Economics is most commonly `non-normative` - instead of asking “how should this person choose which goods to buy?”, we are often more interested in “how does this person choose which commodities they buy?”.
+
+The [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf) is the historically grown and expanded design document of `KERI`.
+
+A \[KID\] (../kids.md) used to be focussed on Implementation; "this is how we do it" We add commentary to the individual KIDs that elaborate on the why. It has been split from the _how_ to not bother implementors with the _why_.
+
+The KIDS concept has been abandoned but a remnant of them can still be found [here](https://github.com/decentralized-identity/keri/tree/master/kids). Now the first thing you should read are the `ietf-` drafts repos, for example ietf-cesr: [https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr)([https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr)) and ietf-keri: [https://github.com/WebOfTrust/ietf-keri](https://github.com/WebOfTrust/ietf-keri).
+
+_When nobody is involved or reads them, how can we be sure it's relevant and becoming a standard?_
+
+The goal of the IETF's specification or standard's path is not to drive adoption through a standard. The adoption plan for KERI is:
+
+> **to build an open source stack of libraries that once completed will largely hide the complexity from the users**
+
+Once that stack becomes a defacto standard due to usage then the IETF standard's process will remove other adoption barriers that may arise unless its an official standard of some kind.
+
+Driving adoption by first getting a standard is a very slow very expensive process. Adoption is most rapid when a library is useful and open. IETF is the **minimally sufficient standards process** that does not interfere with building the KERI stack.
+
+In 2021 "the KIDS quickly felt out of date" (source Phil Feairheller 2022) and the team abandoned the concept for doing the IETF drafts. Now the place to be for studying technical concepts and technical designs are the `ietf-` drafts repos, for example (but not exhaustively listed): [ietf-cesr](https://github.com/WebOfTrust/ietf-cesr) and [ietf-keri](https://github.com/WebOfTrust/ietf-keri).
+
+In brief these are these reasons:
+
+-   the **desire to control the entire stack**, and not use anyone else's tooling
+-   DID and VC layers are the **appropriate layers for interoperability**
+-   The **performance/security goals** of KERI drive its design and therefore KERI can't use so called _enveloped_ data formats
+
+![trade-space-limitations](https://github.com/WebOfTrust/keri/blob/main/images/trade-space-limitations.png?raw=true)
+
+Not suitable for:
+
+-   Applications where total ordering of key event is needed, like in cryptocurrencies and non-fungible tokens.
+
+However, KERI is suitable :
+
+-   to build smart contracting in a direct peer-to-peer way
+-   to build Sidetree with KERI, vice versa is not possible
+-   to implement blockchain / ledger anchored identifiers (_SamMSmith and @henkvancann_)
+
+Yes, KERI gives you the security. And by supplying secure state machines. But you have to gather the right transactions yourself.
+
+Ledgers co-mingle secure state machines into one another, Ledger are total ordering. We don’t need total ordering in KERI. The absence of a ledger gives us the ability to create totally private smart contracts between Bob and Alice.
+
+You use the KERI Duplicity detection to determine the authoritative key is used at a certain point in time.
+
+_(@henkvancann)_
+
+The concepts in KERI come from many different fields. KERI creator Sam Smith: "The problem KERI faces is that the decentralized identity community is unusually insular and narrow compared to most of the fields I am used to working in. Decentralized Identity experts focus very much on their field, which makes communications about out-of-the-box concepts hard. There also is very little standardization of terminology.
+
+Which I find odd when people complain about KERI's use of terminology. Just ask anyone to define "identity".
+
+This is exacerbated by the recent addition of many who come from the blockchain space who have either a very shallow or narrow understanding of distributed consensus algorithms in spite of spending all their time developing for that space. Its clear that many if not most have never bothered to read an introductory textbook on the subject and couldn't define `liveness` or `safety` or `total ordering` accurately.
+
+So KERI has an audience that acts as if they understand distributed consensus but have at best a less than rigorous understanding and at worst a largely erroneous understanding. "
+
+* * *
+
+* * *
+
+The Internet Protocol (IP) is broken because it has no security layer.\\
+
+![Internet stack shows omissions](https://github.com/WebOfTrust/keri/blob/main/images/internet_broken.png?raw=true)
+
+(_SamMSmith_)
+
+The security measures the internet has are \_bolt-on\*s and dependent of intermediary parties. For example the X.509 protocol for DNS. KERI offers a native end-verifiable protocol in a direct (peer-to-peer) and indirect way (duplicity detection in ambient available KERLs). The indirect KERI method removes the need for a middleman, an intermediary, like a Certification Agency for DNS.
+\*(@henkvancann)\_
+
+Establish authenticity between the key pair and the identifier of IP packet’s message payload. [See more](https://ssimeetup.org/key-event-receipt-infrastructure-KERI-secure-identifier-overlay-internet-sam-smith-webinar-58/) in an explanatory presentation.
+
+![identity system security overlay](https://github.com/WebOfTrust/keri/blob/main/images/identity_system_security_overlay.png?raw=true)
+
+(_SamMSmith_)
+
+Administrative Identifier Issuance and Binding; especially the binding between key pair and identifier based on an assertion of an intermediary administrator. This is what's weak and therefore wrong. [See more](https://ssimeetup.org/key-event-receipt-infrastructure-KERI-secure-identifier-overlay-internet-sam-smith-webinar-58/) in an explanatory presentation.
+_(@henkvancann)_
+
+A DNS hijacking wave is targeting companies at an almost unprecedented scale. Clever trick allows attackers to obtain valid TLS certificate for hijacked domains. [more](https://arstechnica.com/information-technology/2019/01/a-dns-hijacking-wave-is-targeting-companies-at-an-almost-unprecedented-scale/).
+_(@henkvancann)_
+
+The `IPv4 layer` was become a standard internet transport layers over the years. It is a very strong structure. The transport layer has no security build into it. So the trust layer has to be something higher in the stack. However in the Support Application layers that sit on top of that IPv4, no standardization has taken place yet. It is a highly segmented layer and trust is therefore _locked_ in those segments or platforms; it's not interoperable across the internet. E.g. platform `Facebook` provides an identity system that only works within their domain. That's the same with for example `Google` or any number of blockchain.
+We don't have a trustable interoperability. And that leads to the idea that the internet is broken. We want to fix that, we don't want a domain segmented internet trust map, a bifurcated internet, we want to have a single trust map. This is the motivation for `KERI`.
+(_SamMSmith_)
+
+With a waist and a neck. ![Platform locked trust](https://github.com/WebOfTrust/keri/blob/main/images/platform_locked_trust.png?raw=true)![Waist and neck](https://github.com/WebOfTrust/keri/blob/main/images/waist_neck.png?raw=true) _(@henkvancann)_
+
+Much of the operation of internet infrastructure is inherently decentralized, but control over the value transported across this infrastructure may be much less so.
+Centralized value capture systems concentrate value and power and thereby provide both strong temptations for malicious administrators to wield that concentrated power to extract value from participants.
+We believe that _decentralization of value transfer_ is essential to building trust. Consequently a key component for a decentralized foundation of trust is an interoperable decentralized identity system. [Source: whitepaper page 7](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
+
+FIDO2 could be used for authentication is witnesses - OOBI. FIDO2 is mostly to do more secure authentication factor to federated identifiers like OIDC The problem is the use of barer tokens, they are vulnerable to known attacks. KERI AID replaces FIDO2 key pairs. KERI is better with key rotation. Even the blockchain-based solution did not solve key rotation in a safe way. Source: Sam Smith, May 2024, KERI Suite Zoom Meeting
+
+* * *
+
+* * *
+
+KERI sat under the _Decentralized Identity Foundation_ until mid 2021, [DIF](https://identity.foundation), in its own working group "KERI".
+It had started off in 2020 under the _Identity and Discovery_ Workgroup of DIF.
+Due to its licensing structure, KERI isn't owned by anyone and everyone at the same time. The Intellectual Property Right of KERI was hosted with `DIF` until Mid 2021. It is an open source project. KERI find its IP hosted in `IETF` from 2021.
+
+All the repos in the [WoT project](https://github.com/WebOfTrust) where the KERI code and related standards reside, have a '_outgoing == incoming_' policy. This means that someones use (outgoing) of a contribution (incoming) is on the same basis or license. This prevents contributions from being poisoned by other contributions that have a different i.e. more restrictive outgoing license, because once contributed there is no way to separate contributions.
+
+It becomes a soup. Have a look below at the Q&A regarding DIF, W3C and KERI.
+
+_And what does KERI prefer?_
+
+By _comprehensive_ we mean all contributions of any and all kinds are covered by one license. One can have multiple comprehensive licenses where a given license takes priority for terms but allows for relaxed terms of use in some circumstance. But all contributions are still covered.
+
+In fact any organization including the W3C that has multiple mutually exclusive split licenses instead of one comprehensive license or licenses instead of a set of comprehensive licenses is disputably only viable because of the good will of the contributors.
+There just isn’t enough legal precedent to trust such constructions.
+
+So **worst case the contribution is no freer than the most restrictive license**. Stacking licenses this way is a common legal approach, but splitting is not. Splitting contributions between different licenses is problematic because of the difficulty in defining the boundary. And the worst case is that its not free at all.
+
+Under DIF license all source code contributions are apache2. So a pull request from an apache2 licensed repository should not be a problem. Unfortunately, DIF uses a combination of the W3C patent policy and the CC4 license for non-source code contributions and so that is where there is significant ambiguity especially since the W3C Patent Policy as written only provides provisions for management by the W3C, not DIF.
+Therefore you can't pull KERI code from DIF into WoT as of **June 2022** because in our perspective it's poisoned after this date.
+
+In **June of 2022** there was a determination by DIF that there were no patentable contribution to the DIF KERI repo for which the W3C patent policy would apply. So any pull requests from _code donated to DIF before June of 2022 are clean_. Anything after that we should not accept because there is ambiguity as to what is “source code” and what is not when it comes to contributions at DIF. Frankly I consider DIF’s IP policy to be broken because IMHO there is no way to unambiguously determine if a contribution is source code or not.
+
+> Example: Is javascript or python code pasted into an issue raised on DIF’s github repo count as source code and falls under apache2? Or is it text and falls under CCby4, or is it a patentable description of a process?
+
+Incoming means the license that is imposed on contributions (`git push`). Outgoing means the license adhered to code from WoT, used somewhere else (`git pull`).
+
+It is possible to have less restrictive outgoing than incoming or have multiple outgoing licenses that are of the same or less level of restriction but with different names because some consumers want to consume (outgoing) under a different license. This is OK as long as its part of the license structure known by contributors.
+
+> Example IETF requires that IETF spec language be contributed under BSD not Apache2. But BSD is no less restrictive than Apache2 for outgoing so it does not poison the apache2 contributions. A consumer can consume under apache2 or via IETF through BSD. BSD is no more restrictive than Apache2. The license for the IETF spec repos in WoT include the BSD outgoing in addition to Apache2 for this reason.
+
+* * *
+
+* * *
+
+\*AIDs are identifiers. Identity may comprise multiple identifiers. So that kind of transfer can always be enacted if the controller controls both AIDs in the trivial sense (ie sign a proof of the old AID with a new AID and rotate the old AID KEL to null keys)\_ _I mean the prefix would be generated with the use of a salt which would generate a private key, and each peer has one identifier prefix, wouldnt that generated private key become sorta a root private key?_
+
+Phil Feairheller — 14/02/2024 18:18 Keys are generated first, using any of the methods described above. So you can have one or multiple private keys and those private keys can each be generated deterministically (using a salt), randomly or contained in a TEE. Then the public keys are derived from the private keys. The same process is followed for the pre-rotated next keys (however many you want).
+
+You then take the public signing keys (first set), digests (currently Blake3) of the pre-rotated keys (second set) and combine them with configuration information into an "inception event". That inception event includes the signing and rotation thresholds, witness AIDs and witness threshold and other configuration information (do-not-delegate, establishment only) and is created as either a JSON, MsgPack or CBOR serialization. You then pad out the d and the i field of the inception event and create a digest (cryptographically agile, so your choice) of that inception event serialization. You then replace the padding of the d and i field with the digest and you have your inception event. Also, the digest (called a SAID in KERI) is your Autonomic Identifier or AID. It has the special properties that it is cryptographically bound (through the hash algorithm) to your first set of signing and rotation keys and it has an "unbounded term". That means that, because you have created pre-rotated keys, you can rotate to new keys and the identifier survives. It is not "bound" by the term of the public keys. In this way we have solved the major problems of current PKI... cryptographic binding of the AID to the keys and secure key rotation.
+
+![](https://media.discordapp.net/attachments/1149003464190480474/1207720134177849415/Screenshot_2024-02-15_at_16.07.31.png?ex=65e0ac06&is=65ce3706&hm=ad0526225142a86c5bf040744da96b55b537386c8de1a5a09244cdd0ba75c5de&=&format=webp&quality=lossless&width=716&height=1174)
+```
+flowchart TD
+%% Henk van Cann, Feb 15th 2024
+  A["entropy 🎲"];B[random];C["salt 🧂"];D["TEE 💻"];
+  E["priv key 🙈"]; F["publ key 👁️"]; G["signing 🔑"]; H["pre-rotated 🔑"]
+  I["digest 📩"]; J["config info 📝"]; K["SCI KEL"]; L["SAID"]
+  M["SAID KEL ⛓️"]
+subgraph one[Key generation]
+    A -.-> B & C & D
+    B --> |"Either"|E
+    C & D --> |"or"|E
+    E --> |derive| F
+    end
+    one -.-> G
+    one -.-> H
+subgraph muliple [Inception event]
+  subgraph two[Self certifying]
+    H --> |hash|I
+    G & I --> K
+    J --> |JSON|K
+    end
+  subgraph three[Self addressing]
+    L --> |copy in 'd' and 'i' field|M
+    K --> |pad out 'd' and 'i' field & hash|L
+    end
+    two-->three
+end
+```
+`KERI` is also the name of a `DID` method in the making [Method spec](https://identity.foundation/keri/did_methods/). The proposed related `DID` method is [`did:keri`](https://github.com/decentralized-identity/KERI/blob/master/did_methods/keri.md). A session at the recent **IIW31** presented by Jolocom’s _Charles Chunningham_ examines overlap between data models of DID documents and `KERI` identifiers [here](https://jolocom.io/blog/as-seen-at-iiw31-KERI/).
+_Drummond Reed_ (Dec 2 2020) on `did:KERI`: "at IIW we asked that question and feedback overwhelmingly favored `did:KERI`. Furthermore, I’ve proposed that the KERI namespace be reserved within the method-specific ID spaces of other DID methods as well, The Indy community has agreed to reserve the KERI namespace in the Indy DID method."
+_(@henkvancann)_
+
+_Every DID must have a method name component before the method-specific ID._
+
+The first paper mentioning the absence of the method is [Thinking of DID? KERI On](https://humancolossus.foundation/blog/thinking-of-did-keri-on) by The Human Colossus Foundation, written by Robert Mitwicki. He addressed the concern in the question (the invalidity of the DID method) and made it more clear what the Foundation meant by that: "We look into the future and with that view we think that namespace could be dropped and we could keep only identifier, as the namespace seems to be one of the major drawbacks of decentralized identifiers at the moment. In my opinion `did:KERI:`  would be just intermediate step as the issue addressed by post would still hold. We see that KERI could be a major upgraded for DID; not replacement."
+
+_But by doing this, you will also exclude a lot of existing identifier infrastructure._
+
+I am not denying existence of existing DID infrastructure, but I agree a lot of them could be obsolete if we introduce KERI. A lot of business models which are build upon current model would be obsolete. I understand that a lot of people would not like that, but that is called progress.
+_(RobertMitwicki)_
+
+* * *
+
+* * *
+
+Yes, a wallet is very much needed. A wallet holds your public private key pairs that embody the root of trust of KERI identifiers. [Universal wallet](https://w3c-ccg.github.io/universal-wallet-interop-spec/) - would do - with a thin layer on top of it.
+A wallet needs to be adapted to KERI to be able to carry KERI identifiers.
+| TBW |
+(_SamMSmith_) / _(CharlesCunningham)_ / _(@henkvancann)_
+
+Although KERI is a key management system, it not actually manages the control over and safe deposit of the private keys that control its KELs. `KEEP` is the tool that manages KERI identifiers' private keys. However, KEEP on its behalf uses an Electron wallet to ultimately store the private keys.
+| TBW prio 1 |
+(_KevinGriffin and @henkvancann_)
+
+We don't need a crypto currency embedded in the KERI system, we can use any other crypto currency system for payment. So the design of the KERI system has left crypto token control out.
+_(@henkvancann)_
+
+The KERI whitepaper has little about virtual credentials and KERI's place in the W3C SSI space for DIDs and VCs. The reason is that KERI is mainly a level 1 and level 2 solution in the trust-over-ip framework.
+_(@henkvancann)_
+
+In the following presentation of _SamMSmith_, there's a lot information about the relation between KERI and VCs: [https://github.com/SmithSamuelM/Papers/blob/master/presentations/GLEIF\_with\_KERI.web.pdf](https://github.com/SmithSamuelM/Papers/blob/master/presentations/GLEIF_with_KERI.web.pdf)
+
+* * *
+
+* * *
+
+Depends on what you mean with _proof_. KERI is content agnostic, so any cryptographic proof can be referenced and signed in a KEL, even a third party signature. As far as KERI-internal proofs are concerned a subject-controller, a delegated controller and combination of (fractioned) multi-signatures can prove authoritative control over a key and over a pre-rotated key. _(@henkvancann)_ | TBW prio 1 |
+
+In general they can proof the authoritive control over a private key at a certain point back in time. _(@henkvancann)_
+
+What is the meaning of “sid”, “wan”, and “red” in `tests/vc/test_protocoling.py` in the test : _test\_issuing_?
+
+Phil Feairheller answers in 2022:
+
+-   **ian**: issuer of cred (start with ‘i’)
+-   **sid**: signer of cred (start with ‘s’)
+-   **wan**: witnesses (start with ‘w’)
+-   **red**: receipient of cred (start with ‘r’)
+
+Yes they do. For every cause there is a different payload. The main reason why all roles sign off cryptographic references is commitment to those sources (the payload in KERI is often a digest of sources) at a certain point in time.
+_(@henkvancann)_
+
+KERI identifiers can be “delegated”, meaning one identifier can create another one that can prove its relationship with its parent. This way you can create any hierarchy of identifiers & keys.
+
+![key delegation illustration](https://github.com/WebOfTrust/keri/blob/main/images/delegation-keri-muggles.png?raw=true)
+
+Sign the SAID at issuance event.
+
+You don’t sign an ACDC, you anchor it in the KEL via the TEL. Signing the SAID is signing all the content. History: We used to sign ACDC in exchange events, but we later realised that ACDC don’t need to be explicitly signed. So you might find some ACDC signing in older code (before 2023) _(@henkvancann)_
+
+* * *
+
+* * *
+
+KERI has the ability to proof various things:
+
+-   Control over an Autonomous identifier (`AID`).
+-   Control over a pre-rotated key
+-   Commitment to an Event Log
+-   Content addressing by a hash
+-   Delegation of control over a key
+-   | TBW prio 2 |
+
+No, KERI is data agnostic. KERI does make no statement about the validity of the payload data.
+_(@henkvancann)_
+
+We may verify that the controller of a private key, made a statement but not the `validity` of the statement itself.
+(_SamMSmith_)
+
+We may build trust over time in what was said via histories of verifiably attributable (to whom) consistent statements, i.e. `reputation`.
+(_SamMSmith_)
+
+It means that the required _threshold_ of signatures has been met. It doesn't mean that all signatures have been provided.
+
+Yes, because they can't verify the root of trust. They have to have access to the full log at some point in time. Once they verified to the root of trust, once, they don't have to keep a copy of the full log. They have to keep the event they've seen and any event since, that they need to verify as they go. (_SamMSmith_)
+
+Interactive proof of authentication requires both parties interacting, it uses bandwidth, I can't batch the interactions either. So it's not scalable.
+
+Non-interactive proof of authentication -> digital signature with public private key pair.
+Non-interactive has huge advantages for scalability.
+
+The weakness is of `non-interactive` proving is replay attack ( the interactive method has built-in mechanism to prevent replay attacks ).
+Replay attack is some adversary is replaying a request for access in your name after having gained access to your private keys. Solution to replay attack is both `Uniqueness` and `Timeliness`.
+
+Uniqueness works with a `nonce`, that's being obtained by a challenge-response mechanism and the requester has to use that nonce to seal the request.
+
+Timeliness is even better because it can service both properties needed in one go. If we use a Date-time-stamp (monotonic) in time window we can be sure that the sender request is unique and has been established in an acceptable time frame.
+
+So therefore the non-interactive mechanism to replay attack prevention has been suggested in KERI implemented by Date-time-stamp (monotonic).
+The time window can be fairly large because you use monotonicity.
+
+_My e-mail address or phone number are publicly available and anyone can contact me, I'd like more privacy._
+_I you want to talk to me, you send a message to my public identifier._
+
+First use a public identifier and then set up a private pairwise connection.
+You don't need to a strong correlation of your public identifier to you as an entity, but only to your "local" reputation, expressed by the KEL itself.
+The correlation in KERI is never public, always private. _Spam_ goes away because of the provable attestation.
+(_SamMSmith_) and (_@Chunningham_)
+
+In short, it doesn't because **KERI is context free**, for a reason and that is _privacy_. So you could make double claims.
+
+KERI's purpose isn't to solve transaction state, other than key state. KERI doesn't care about the semantics about what is anchored in KERI. So if you want to solve a double claim problem in a given transaction context, then you create a transaction event log (TEL) for that context, where you could enforce priority in that TEL that you make claim then that claim has an identifier. You attach some semantics to your _transaction set_: which types of claims in this specific context. This is transaction context specific and allows to control it.
+This fits nicely in the thin layering model of KERI because the authority for making any claim in a TEL can be establish back to the KEL. (_SamMSmith_)
+
+Transaction state is a more local consideration. One layer up (TELs are where they live, and a specific context/network/cloud/etc can set up its own ordered ledger of transactions using TELs; claims to authoritative txn state limited by such opt-in/perimeter-bound txn consensus). Claims need an identifier to be assigned semantics. If claims or semantics are human readable we need case-based reasoning and very sophisticated AI with natural-language processors.
+(_@bumblefudge_)
+
+Each layer in KERI is responsible for its own duplicity detection!
+(@stevetodd)
+
+If a controller _choses_ to hash its claims, the controller choses for _hiding_ (and the ability to double claim!), which is perfectly fine with KERI because KERI is privacy preserving.
+
+Alternatively, suppose the controller choses to implement the solution mentioned above and create specific type of transaction context, and offers means of detect duplicity in statements (in this case double claims in transaction event log, also TEL), e.g. "Are you for - or against nuclear power" and the allowed options are _Yes_ or _No_. In this case especially time is relevant. Certain contradictory claims about a topic can be made within a certain time span. One could change his/her mind about about a certain topic, and anchor this change of mind in a KERI transaction event log (also TEL).
+
+It's up to verifiers to judge this softer version of duplicity at the context level within TELs, which means: how quickly can one change one's mind and still be trustworthy.
+
+If a verifier with the help of AI were to find out a controller is stretching honesty to swabbing about a topic, for example creating two TELs with semantically the same context but obfuscated by few typos and alternative formulation (example: "Like nuclear power?" Y/N) then trust is down to near zero.
+(@henkvancann)
+
+* * *
+
+* * *
+
+The first reason is that people are not interested in key management if it doesn't concern money. Only since we have crypto currencies the management of private keys has taken off. And for decentralized identities we can go with the flow of that success. Hierarchical deterministic keys are now wide spread among the early adopters of crypto currencies. They are based on 24-word so called seeds (also called 'mnemonic phrase') and password, with the aid of (hardware) wallets. And the only reason why it has been such a great success compared to the decennia old `PGP`, seems to be that loss of crypto money is much stronger felt than the loss or exposure of private personal data.
+
+A second reason is the method of verification and attestation in the PGP web-of-trust doesn't scale and it's difficult to use. The user interface of `GPG` isn't up to our beyond 2010 standards at all.
+
+In theory we could list a PGP public key in the KERI [KID0001](https://github.com/henkvancann/keri/blob/master/kids/kid0001.md) - Prefixes, Derivation and derivation reference tables.
+| TBW prio 3: Old reference to abandoned KIDs at DIF, renew |
+However it's not very practical, because PGP itself is a conglomerate format that has its own derivation codes on board for different cryptographic functions. That means the PGP public key already has protocol semantic on board and that's one layer higher up than what we need for KERI in the key data structure design. KERI has it's own derivation codes and the _minimization_ design principle dictates that it makes no sense to support PGP, because as an inception key pair for KERI it has no added value, and it has redundancy on board.
+(@henkvancann) | TBW 3 |
+
+![Autonomic Architecture](https://github.com/WebOfTrust/keri/blob/main/images/autonomic-architecture.png?raw=true)
+
+The controller uses her `private key` to authoritatively and non-repudiated sign statements about the operations on the keys and their binding to the identifier, storing those in an ordered key event log (`KEL`). One of the important realizations that make autonomic identity systems possible is that the key event log must only be ordered in the context of a single identifier, not globally. **So, a ledger is not needed for recording operations on identifiers that are not public.** The key event log can be shared with and verified by anyone who cares to see it.
+
+The controller also uses the private key to sign statements that authenticate herself and authorize use of the identifier. A digital signature also provides the means of cryptographically responding to challenges to prove her control of the identifier. These self-authentication and self-authorization capabilities make the identifier self-certifying and self-managing, meaning that there is no external third party, not even a ledger, needed for the controller to manage and use the identifier and prove to others the integrity of the bindings between herself and the identifier. Thus anyone (any entity) can create and establish control over an identifier namespace in a manner that is independent, interoperable, and portable without recourse to any central authority. Autonomic identity systems rely solely on self-sovereign authority.
+(_@windley_)
+
+More in [The Architecture of Identity Systems](https://www.windley.com/archives/2020/09/the_architecture_of_identity_systems.shtml)
+
+KERI has `univalent`, `bivalent` and `multivalent` infrastructures. Definitions from the keri whitepaper: \\
+
+> 9.5.1 Key Management Infrastructure Valence
+
+> When all storage and signing operations both administrative and not are supported by one computing device or component we call this a **univalent** architecture or infrastructure. When storage and signing operations are split between two computing devices or components, we call this a **bivalent** architecture or infrastructure. In general when storage and signing are split between two or more key computing devices or components, we call this a **multivalent** architecture or infrastructure.
+
+![Key Infrastruction Valence levels](https://github.com/WebOfTrust/keri/blob/main/images/key-infra-valence.png?raw=true)
+
+You need Key-pair Generation and Key-Event-Signing Infrastructure. And KERI doesn't care how you do it.
+From `bivalent` delegation | fill out?! | comes into play. But in fact you can have `multivalent` infrastructures, all with their own security guarantees and its own key management policies.
+It's all one KERI codebase to do all these infrastructures.
+(_SamMSmith_)
+
+No, because the derivation code allows you to use whichever format you want. So anyone that sees an identifier looks at the first byte or two bytes pre-pended, it's a derived code, and you can tell exactly what type of public-private-key format we have, e.g. ecdsa.
+
+When you rotate keys, you can always rotate to a different format.
+
+Yes, you can derive your keys from that scheme. But KERI is agnostic about it, it wouldn't know.
+
+To begin with, yes, KERI fully depends on `PKI` cryptography. KERI was built upon the assumption of unbreakable public private keys.
+
+![Public Private Key caveat to KERI](https://github.com/WebOfTrust/keri/blob/main/images/pubprivkey-caveat.png?raw=true?raw=true)
+
+By the way, in KERI we say _identifier_, because **identity** is a loaded term, lots of misunderstanding around it.
+
+Pre rotated keys are best practice to keep control of your identifiers.
+If you lose unique control of a key right after inception, before rotation, are there no guarantees to be given for KERLs via witnesses / watchers or whatever. Is the only thing you can do about it, is revoke the key in that case? | _(@henkvancann)_
+
+Currently _Universal wallet_ is aimed at to store KERI keys. The vast majority of security breaches or exposures of keys are originated by the behavior of people: the way they use wallets. Most rarely due to errors in the wallet software. | TBW prio 1 |
+
+Yes, complex fractional structures are natively possible in KERI. However only for the non-basic forms (for transferable identifiers).
+_(@henkvancann)_ | TBW prio 1 |
+
+In KERI you would never hand over control over your private keys, but always create delegated keys (a kind of "sub"keys lower in the hierarchy). Delegated keys are a secondary root-of-trust within KERI. _(@henkvancann)_ | TBW prio 3 |
+
+_And start a KERI public identifier for him. The associated identifier receives and holds value, and that nobody can control except for my son, when he's able to manage the keys._
+
+At some point in time somebody always has authoritative control of identifiers, or simply put "controls the key" or "has the private key" to the value. But one can organize Guardianship. [A Deeper Understanding of Implementing Guardianship](https://sovrin.org/a-deeper-understanding-of-implementing-guardianship/) at SovrinFoundation and [Aries RFCs](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0289-toip-stack/README.md) they’ve informed us with an overview at last IIW ([notes](https://docs.google.com/document/d/1O46cj79KGulbDrHbdHa2Ttfnohgi-IiAZITGIRo3wOM/edit)).
+
+The Sovrin Guardianship Working group site is [here](https://sovrin.org/guardianship/)
+
+_And start a KERI public identifier for her._
+
+It is a legal issue, there can only be one person holding keys. Either the parent or the child holds the key.
+The problem has to do with temporary guardianship. You need to implement an additional legal construct like the ones mentioned above. After that a set of governors have control authority.
+
+Other constructions like multi sign or sharing schemes (e.g. Shamir SSS) introduce more parties and more complexity and are not advised.
+
+A set of related, and widely supported within the DID community, ideas by TNO The Netherlands in a [whitepaper](https://www.researchgate.net/publication/348325716_Decentralized_SSI_Governance_the_missing_link_in_automating_business_decisions) 'Decentralized SSI Governance, the missing link in automating business decisions', that we collectively refer to as “decentralized SSI governance”.
+
+* * *
+
+* * *
+
+No, but KERI uses the same cryptographic building blocks as blockchains do.
+_(@henkvancann)_
+However, KERI may be augmented with distributed consensus ledgers but does not require them. [Source: section conclusion in whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
+
+`KERI` is a unordered hash-linked list of signed Key Event logs and blockchain is a timestamped ordered list of hash-linked blocks of signed transactions. What this means:
+
+1.  we don't need ordering in `KERI` and that frees us from consensus protocols in blockchains
+2.  Hash-linking is done on a lower level in `KERI` and preserves consistency and fuels revealing of duplicity.
+3.  In `KERI` proofs are cryptographically derived from the root of trust, being the autonomous controller, in blockchains the root-of-trust is a transaction on a ledger; that means the Identifier gets locked on the ledger.
+    _(@henkvancann)_
+
+Because for our purposes we don't need to. Consider two distinct identifier to totally ordered, distributed consensus ledger:
+
+1.  the access identifier that allows you to access the ledger. This one is usually a `SCI`. E.g. on bitcoin your bitcoin address is cryptographically derived from the public key from your key pair.
+2.  the register identifier that allows you to register an identifier on the ledger. The ledger transaction is validated registering of your identifier, not the cryptographic root-of-trust that the access identifier is using.
+
+The identifier is now locked to that ledger. We want identifiers to be portable across ledgers, so we don't want to use registration as the root-of-trust, we want to be self-certified all the way. (_SamMSmith_)
+
+_that you send to witnesses, who observe them and attest to the particular line of operations they see?_
+
+**In brief: for KERI that is an apples and oranges comparison.**
+
+Because total linear ordering is not needed for a given identifier's event sequencing. Only linear order of that identifier's history. The histories from other events do not have to be ordered with respect to each other. So the secure ordering of a given identifier's history is a completely different class of problem than the secure total ordering of commingled history from multiple identifiers.
+The security demands are less for the former case. So the equivalent security may be obtained in other ways. While the latter as a side effect of total ordering gives local ordering (per identifier) for free. But securing total ordering may be much harder to do. So one has to be careful, because it's no longer an apples to apples comparison. (_SamMSmith_)
+
+_At least at certain intervals to ensure my data is not erased by the central registry..._
+
+The registry is logically centralized (in that there is a consensus between participants) but there is no central registry (needed, ed.), which gate-keeps access to the data.
+(_@Chunningham_)
+
+In brief: identifier portability is significant.
+
+The key answer to _How can you control your own online identity?_ is that it must be portable. The system **must have** the property of **identifier portability**.
+
+> This is analogous to the property that mobile telephone numbers now have (but didn't have for decades) that is number portability between providers. Likewise a blockchain based identity system suffers from the lack of identifier portability.
+
+It doesn't matter that the blockchain has a decentralized governance structure, the identifier is not portable and so the user is not truly totally sovereign over their identifiers and hence their identity based on those identifiers. KERI is a system able to globally authenticate and that supports global portability.
+
+* * *
+
+* * *
+
+Primary root of trust is KEL not secondary (starts with self cert ID), but then after the first rotation, if any, you must have a KEL.
+(_SamMSmith_)
+
+A trust basis binds controllers, identifiers, and key-pairs.
+A trust domain is the ecosystem of interactions that rely on a trust basis.
+
+The `KELs` are what establishes the root of trust in `KERI`. So you have a `SCI` and a `KEL`. The `KEL` is ordered with respect to the SCI by the controller. You don't need total ordering with respect to other identifiers to establish the root of trust in `KERI`, because the controller is the one and only, who orders events.
+In blockchains you have total ordering, which you need for double spend protecting in cryptocurrencies, but not in `KERI`.
+For people in blockchain this is a bit hard to grasp, but we don’t need hash chained data structure of events on single identifier nor the _ordering_ those, I just need logs, I need _append-only logs of events_ to establish the authority.
+And so I defend myself against `duplicity`.
+(_SamMSmith_)
+
+**In brief: with end-verifiability anyone can verify anywhere at anytime, without the need to trust anyone or anything in between.**
+
+Because any copy of an `end-verifiable` record or log is sufficient, any infrastructure providing a copy is replaceable by any other infrastructure that provides a copy, that is, any infrastructure may do. Therefore the infrastructure used to maintain a log of transfer statements is merely a `secondary root-of-trust` for control establishment over the identifier. This enables the use of ambient infrastructure to provide a copy of the log. The _combination_ of end verifiable logs served by ambient infrastructure _enables_ ambient verifiability, that is, anyone can verify anywhere at anytime. This approach exhibits some of the features of certificate transparency and key transparency with end-verifiable event logs but differs in that each identifier has its own chain of events that are rooted in a self-certifying identifier.
+
+* * *
+
+* * *
+
+On (sub)page(s of) [github](https://github.com/decentralized-identity/KERI).
+
+The homepage on github \[README.md\] (../README) pretty much sums up all the possibilities to download the available code and how developers can currently engage in the development process. We welcome all help we can get.
+
+-   Its main drawback is that it's nascent. (_SamMSmith_)
+-   The field of cryptography is already complex by itself. KERI's extended complexity, combined with totally new terms and new process description make it a steep learning curve. It depends on your individual drive to want to know about KERI, to what extent the effort pays off. Maybe first try:
+    1.  \[KERI made easy\] (./KERI-made-easy.md)
+    2.  The general \[KERI Q&A\] (./q-and-a.md) _(@henkvancann)_
+-   KERI is inventing its own lowest level building blocks. That will prevent a lot of potential code reuse. (@OR13)
+
+`KERI` does one thing, it establishes control authority using verifiable portable proofs that are `KEL`s.
+(_SamMSmith_)
+
+`KEL`, `KERL` and `KAACE` might well be very lean alternatives to blockchain based solutions. The hard part is the ambient verifiable architecture.
+_(@henkvancann)_
+
+**In brief: yes, pre-rotation with hashed public keys and strong one-way hash functions are post-quantum secure.**
+
+Post-quantum cryptography deals with techniques that maintain their cryptographic strength despite attack from quantum computers. Because it is currently assumed that practical quantum computers do not yet exist, _post_\-quantum techniques are forward looking to some future time when they do exist. A one-way function that is post- quantum secure will not be any less secure (resistant to inversion) in the event that practical quantum computers suddenly or unexpectedly become available. One class of post-quantum secure one-way functions are some cryptographic strength hashes. The analysis of D.J. Bernstein with regards the collision resistance of cryptographic one-way hashing functions concludes that quantum computation provides no advantage over non-quantum techniques.
+Strong one-way hash functions, such as 256 bit (32 byte) Blake2, Blake3 and SHA3, with 128 bits of pre-quantum strength maintain that strength post-quantum.
+[Source: whitepaper page 65](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
+
+Any controller can install a Service/Agent Log, controlled by them.
+
+| TBW prio 2 |
+
+Any subject / controller can start creating KERI events in a KERI event log. Dependent of the objectives a controller has with KERI a more peer-to-peer (one-to-one) approach or contrary to that a one to many approach. In the latter case a set of witnesses and their services can emerge per controller. Subsequently one or more verifiers (and their watchers) can also enter the play. The more entities are getting used to play the different KERI specific roles the more rapid and easy will the bootstrapping / flooding of KERI on the internet evolve. | TBW prio 1 |
+
+The [SSI Meetup](https://ssimeetup.org/key-event-receipt-infrastructure-KERI-secure-identifier-overlay-internet-sam-smith-webinar-58/) webinar on KERI took place in May 2020 and is a good lesson and source of information.
+There is lots of course material available on [prosapien.com](https://www.prosapien.com).
+_(@henkvancann)_
+
+In short, KERI is three to four orders of magnitude faster than its functional equivalents.
+
+An important note is KERI is not a crypto-currency. It's a Key Event Receipt Infrastructure that operates at a lower level than most crypto currencies and Decentralized Identity systems, hence you can rebuild those systems with KERI.
+A second note is that speed and scalability is often a trade-off with several other parameters like security, decentralization, useability. Nevertheless we'll try to answer the question in general terms and correct in orders of magnitude.
+
+A public blockchain like Bitcoin or Ethereum has a transaction speed in the single digits up to the hundreds transactions per second (TPS). Permission-ed blockchains can deliver transaction speed in one to two orders of magnitudes higher.
+
+KERI is permission-less, scalable, secure and has transactions of events in order of magnitude four times higher than public blockchains (10.000 times more) and in the range of VISA credit card transactions. KERIs speed is mainly dependent of the number of controllers that have to mutually verify their KELs.
+
+The problem with blockchain based solution like Indy is that they do not offer concurrent processing in their code. They will hit a performance and scalability cieling within the range of the thousands of (event-) transactions.
+
+Based on [IIW32 recordings](https://eu01web.zoom.us/rec/play/ymi1tW8_oy1ejYDnhtP6lw9DFSqmwWW32Vs-Savd_s-5dWuIOPOY9zZlhkoyDUQjqBA5eR12TK_8eX2m.5e_aDMp-J1c_t551?continueMode=true) of session _KERI: Centralized Registry with Decentralized Control (KEL & TEL ) + DEMO_
+_(@henkvancann)_
+
+Delegation could be used. There is an [issue about IoT](https://github.com/decentralized-identity/KERI/issues/54) key and identifier management with `KERI` that answers this question profoundly.
+(_SamMSmith_)
+
+There a two sorts of issuances of credentials:
+
+-   **A public statement** (e.g. provenance of data), or
+-   **the presentation of an authorization** The former doesn't have a holder. So we focus on the main use of `VC`s: the latter: the presentation of an authorization.
+
+Usually holders don't revoke a credential, they just decide to not use them anymore. You could install a Policy and a set of Rules to give holders to exercise power to some extent over the revocation:
+
+1.  _Policy_: a holder can ask the entity that has authoritative control over the `VC`s to revoke it.
+2.  _Rules_: for a TEL , for example cooperative delegation through delegated identifiers to participate in a revocation event, where both the holder and the issuer have to participate, but you could change the rules so that either party could revoke.
+    Based on [IIW32 recordings](https://eu01web.zoom.us/rec/play/ymi1tW8_oy1ejYDnhtP6lw9DFSqmwWW32Vs-Savd_s-5dWuIOPOY9zZlhkoyDUQjqBA5eR12TK_8eX2m.5e_aDMp-J1c_t551?continueMode=true) of session _KERI: Centralized Registry with Decentralized Control (KEL & TEL ) + DEMO_
+    _(@henkvancann)_
+
+* * *
+
+# Q&A section Agencies
+
+* * *
+
+> Decentralized systems must coordinate across multiple parties, all acting independently in their own self-interest. This means that the rules of engagement and interaction must be spelled out and agreed to ahead of time, with incentives, disincentives, consequences, processes, and procedures made clear. | TBW prio 3 | DRAFT BY _(@henkvancann)_
+
+KERI is self-administered, self-governed. What aspects of KERI need governance?
+
+Purist permission-less network proponents will argue that a real decentralized network does not need a governance framework since mathematics and cryptography make sure that proper governance is in place.
+
+The Trust over IP stack includes both a governance stack and technology stack.
+
+-   Controller, Entropy hardware and software, KEL, KERL
+
+-   Governance of capabilities of digital wallets, agents, and agencies. So the need is primarily to establish baseline security, privacy, and data protection requirements, plus interoperability testing and certification programs, for the following roles:
+-   Hardware Developers: hardware security modules (HSMs)
+-   Software Developers: duplicity verification and internal consistency checks
+-   Agency: ambient availability of KELs and KERLs
+
+KERI is not an outspoken credential issuance and verification framework. Having said that:
+
+-   Controller: inception proof, revocation, delegation proof
+-   Holders: availability
+-   Verifier: external inconsistency proofs
+
+-   KERIs objective is to be the spanning trust infrastructure of the whole internet
+-   Portability of the identities and KERI interoperability between platforms is cryptographically secured
+-   Inconsistencies "reported" by meerkats -like alert governance system
+
+A. In a pair-wise setting each party only needs to be consistent with the other party. Witnesses are not used. It doesn't matter if they lie to each other as long as they lie consistently. KERI does not enable someone to proof the _veracity_ of a statement only the _authenticity_ of the statement.
+(_SamMSmith_)
+
+B. If 3 parties are involved in a transaction all they need do is query each other for the copy of the `KEL` that each is using for each other to ensure that there is no duplicity.
+(_SamMSmith_)
+
+C. To **guarantee _undetectable_ duplicity** requires a successful eclipse attack on all the parties. `KERI` merely requires that there be sufficient duplicity detection in the ecosystem.
+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.
+_Any blockchain system is also vulnerable to such an eclipse attack._
+(_SamMSmith_)
+
+* * *
+
+* * *
+
+Why do we want portable identifiers instead of the Ledger Locked IDs, since we have DIDs that can resolve a ledger locked Id uniformly? You say “We don’t want to use certification as a root of trust, we want to do it self-certified all the way” -> what about the issuance of a credential based on the ledger locking, isn’t that beneficial?
+
+_Or does (Delegated, Multi-sig) Self-Addressing do the job?_ | TBW Prio 2 |
+
+Platypus - Welcome Collection gallery (2018-03-21): [https://wellcomecollection.org/works/w3wxxrtv](https://wellcomecollection.org/works/w3wxxrtv) CC-BY-4.0
+
+
+
+
+---
+title: KERI MOOC
+description: Goal is to facilitate self-education culminating in KERI knowlegde. Level: starters, novices, beginners and alike.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/education/keri-mooc/index
+  md: https://weboftrust.github.io/keridoc/docs/education/keri-mooc/index.md
+---
+
+# KERI MOOC
+
+Goal is to facilitate self-education culminating in KERI knowlegde. Level: starters, novices, beginners and alike.
+
+KERI is ground-breaking technology. It has the potential to truly distribute and decentralize the anchoring of public digital identifiers and maintain verifiable attribution to their root of trust. It's mankind's path to personal digital freedom by keeping control over your digital self and still comply with rules of domains you live in.
+
+The content of the Massive Online Opensource Course (MOOC) should be
+
+1.  Universal Cryptography theory
+2.  Universal Identifier theory
+3.  General Key management
+4.  KERI
+5.  Specific KERI issues: CESR, KELs, TELs, KAACE, SAID, ACDC
+6.  Roots of trust and Wallet software
+7.  Delegation and Agency
+8.  Revocation, (Pre)Rotation
+9.  DIDs
+10.  Governance and Credentials
+
+![](https://hackmd.io/_uploads/SyBaKmMct.png)
+
+Source: Sam Smith 2021, [KERI.one](http://keri.one)
+
+-   Keeping your private keys private
+-   Network Security, Security related to social behavior
+-   Veracity; we need governance for this KERI solves the public secure attribution problem.
+
+My goal is to reach out for the smart young people in third world countries who own a smart phone. I focus on personal development and learning to empower individuals. The MOOC is aimed at them. If we can seduce young people to learn the fundamentals of digital key management and true autonomic identifiers while they are learning English at the same time, we might
+
+1.  train fundamental key management skills\*
+2.  spread KERI knowledge
+3.  expand KERI programming capacity Be aware that in this MOOC, that is individually focussed, we skip the more team-oriented topics, like multisig schemes, network security, verifiable credentials and governance and alike.
+
+\*including keeping your priv keys private
+
+-   Content
+    -   Current team members are busy programming. We should not disturb them too much. We might call on non-programming volunteers that have advanced fudamental knowledge.
+-   e-Learning Management System (LMS)
+    -   Moodle
+
+For Central Europeans a non-native proficient use of English could be satisfactory.
+
+Personally I think it is _not_ a good idea to have KERI theory translated into Spanish, Mandarin, etc. KERI theory sounds like English, but it's not and we'll create even more hurdles to overcome when we translate to another foreign language.
+
+Maybe a **non-native speaker is better** than native speakers from the UK, Canada or the US because native speakers in a complex technology field tend to use hard to grasp constructions?
+
+For US, Canada and UK, we might need to record a native speaker to come across more convincingly. But in that case we need to be careful that the wording is simple and understandable for laymen.
+
+-   e-learning with vids.
+    -   Presentation skills of the creators will certainly help to bring the message across smoothly.
+-   Incentive program
+-   On mobile phone
+    -   offline
+-   Asynchronous learning
+    -   practise on prototypes and test environments
+-   Synchronous learning and participation
+    -   [AMA sessions](https://hackmd.io/nuUu5S8UQjOHXw_a53LvvA#Pre-recorded-video-play-and-text-chat)
+-   Test and graduation / certification
+
+First we play a video for first timers, and **in the meanwhile we'll be available on the chat for guidance and first answers** and after this prerecorded video with text-chat option we'll go over to interactive Q&A.
+
+We could open up on Zoom with other interested Newbies who join in later (because they've already seen the pre-recorded stuff)
+
+for live discussion and Q&A, of course with a host that repeats questions posed in the chat and gives the person that has sent in the question the opportunity to repeat the question with voice & vid. We've tested this concept in the Netherlands and it went well.
+
+So the example program could be:
+```
+Wednesday 4 PM CEST Pre-recorded video play and text chat
+
+Wednesday 4:30 PM CEST Zoom Q&A and text chat, **this week's topics only!**
+```
+The whole series will be repeated and revised every 8 weeks. New tutors can be trained (train the teacher) and within 2 month play a role in teaching others.
+
+| Topic | Wk | Date | Pre | Post |
+| --- | --- | --- | --- | --- |
+
+| You get to decide | 1 | date | general knowledge of identity systems and identifiers | know three types of identifier systems and why they are important |
+| Practise Self Sov | 2 | date | Awareness of status of algoritmic and autonomic identifier systems | Knowledge and practise of pseudonymous self determining identifiers in social media: creation, binding and removal. |
+| Universal IDs | 3 | date | Knows where to draw the line between administrative identifiers and self-sovereign identifiers | Fundamental knowledge about the pre-requisites and features of a truly universal identifier |
+| Basic cryptographical one way functions | 4 | date | Cryptography: hiding, encryption and decryption minimal knowledge | Hashing, Signing, Public Private keys |
+| KERI why and basics | 5 | date | Universal identifiers, basic Internet technology expertise, "https:" and certificates, decentralization in general, basic cryptographical one way functions | KERI thin layers, KERI's unique universal objective, self-certifying and self-admin identifiers, key event logs, primairy and secondary roots of trust. |
+| Key event logs, KERI duplicity game | 6 | date | KERI basics, basic crypography, gamification: eavesdropping, hostile behaviour, etc | Fully grasp what KERI is about and what it isn't. What KERI cares about and what not. Understand the set bounderies of KERI core and its expandable thin layering. |
+| KERI and DIDs | 7 | date | Knowledgeable about what KERI is, and what DIDs comprise of | Similarities, Differences, mutual positioning, combination, challenges |
+| Key rotation and key delegation, Consensus protocols for secondary roots of trust | 8 | date | Legal identifiers in general | Understanding of the new concepts introduced by KERI and their impact on the internet and self-sovereign public identifiers |
+
+When students find our 'KERI MOOC" in the middle of an ongoing series, then there are two options:
+
+1.  work backwards in high speed
+2.  wait until the next series
+
+We will have more than one video of half an hour pre-recording of which the text-chat will also be recorded. And the Q&A will also be recorded.
+
+To facilitate catching up for students that want to hop on the bandwagon the latest series will be available publicly as Zoom recording.
+
+Every lesson will have sufficient links to Keri.one resources, but the level of abstraction should increase step by step.
+
+We can only re-use or create Open Source course material, e.g. CC by SA
+
+This example is a general introduction about the why of autonomic IDs and tries to put listeners to work at the end. We could also focus more specific on KERI in future recordings or even the relationship between KERI and DIDs, KERI and other algorithmic and autonomic ID systems.
+
+Henk van Cann's presentation about (the why of) autonomic identifiers called: "You control, therefore you are, and you get to decide" [https://vimeo.com/552459966/2586f0e23c](https://vimeo.com/552459966/2586f0e23c).
+
+It is a first-time, one-take presentation based on this article: [https://medium.com/happy-blockchains/you-control-therefore-you-are-and-you-get-to-decide-2e2e615714a9](https://medium.com/happy-blockchains/you-control-therefore-you-are-and-you-get-to-decide-2e2e615714a9).
+
+Moodle expert Peter Haasdijk, working from the Netherlands thinks along with us. His first recommendations:
+
+-   don't depend too heavily on the off-line capacities of the Moodle e-learning system
+-   two VP servers needed, one for **Moodle** (e-learning), one for **BigBluebutton** ( online video conferencing )
+-   Forget about HSP content (too heavy)
+-   It's going to be a flat MOOC, no java, no graphical highlights
+-   How's the KERI specific content currently served, like video's, articles, etc.
+
+For a first set-up he needs these parameters:
+
+-   # participants
+
+-   # concurrent participants
+
+-   content
+-   mobile adaptive content
+
+We're going to fail. To do continuous development and deployment in a Moodle stack and also alter content in a 24x7 available system that needs to serve mobile phones and authenticate users is doomed to fail. But let's fail fast and let's fail often. From what we learn by failure, we'll adjust the solution every MOOC cycle.
+
+As soon as possible, but it's done when it's done.
+
+1.  Select an e-LMS (Moodle is a good candidate)
+2.  Find experts to create the MOOC
+3.  Gather open source course material to reference for further reading
+4.  Write high abstraction level articles which have a narative flow
+5.  Practise presenting the content of the articles
+6.  Professionally record the first three half hour pre-recorded vids
+7.  Get the series started and see where we get
+
+
+
+
+---
+title: WOT Education
+description: This is a source directory that contains Q&As and other educational resources
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/education/intro/index
+  md: https://weboftrust.github.io/keridoc/docs/education/intro/index.md
+---
+
+# WOT Education
+
+This is a source directory that contains Q&As and other educational resources
+
+
+
+
+---
+title: Roadmap to know what's coming
+description: People want to know when new code will be ready, who will produce it, where it'll be and how they can rely on the code they currently use and / or create extensions or modification too. For this reason, we'ld like to know the work planning and how certain tasks are (inter)dependent of other tasks.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/roadmap/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/roadmap/index.md
+---
+
+# Roadmap to know what's coming
+
+People want to know when new code will be ready, who will produce it, where it'll be and how they can rely on the code they currently use and / or create extensions or modification too. For this reason, we'ld like to know the work planning and how certain tasks are (inter)dependent of other tasks.
+
+-   Will changes break the current code?
+-   Have black swans appeared?
+-   When will the work start and when is it ready?
+-   How do reported bugs relate to developments?
+-   Who is responsible for what in the process? Before we can answer these questions we need to step back for a moment and consider the _relationship-procedure-content_ funnel.
+
+People in the community are related to each other in a different way than between members of hierarchical organizations.
+
+The KERI development team anno 2024 isn't a big fully funded development team. Currently we have to rely on a handful of very dedicated developers and we do so happily and gratefully.
+
+You might reason
+
+> "well, no, pay them better and they can be held accountable and responsible for meeting deadlines and meet the definition of done." "Isn't there proper project management on top of this?!".
+
+**How wrong you can be** illustrates the following:
+
+-   The KERI Suite is fully open source and publicly available under the Apache2 license. Open source development is not comparable to a commercial time-based implementation project. It's done when it's done, scratch your own itch, are just two examples of adagia related to open source development. Study these and more of them; for example in the classic book 'The Cathedral and The Bazaar';
+-   Architects and developers of KERI are totally independent, they might not need your money, they need your input, you effort, your Pull Requests;
+-   Developers already have a strong sense of duty in the job they have accepted, which is in nearly all cases directly or indirectly related to KERI core development;
+-   Moreover, most core team developers additionally spend a significant amount of their free time on freely available KERI growth;
+-   Self-imposed pressure to make KERI work the way it can work is strong enough to keep us going, we don't need pushy critics on the side line to be motivated.
+
+The roles in the team may vary; one individual could have multiple roles and an individual can have different roles in different repositories:
+
+1.  Founder
+2.  Architects
+3.  Core developers
+4.  Developers and developers to be
+5.  Documenters
+6.  Facilitators
+7.  Launching partners
+8.  Governance officers
+9.  Implementers
+10.  Laymen
+
+With respect to the above-mentioned relationship in the team, and if you're in the role 4 to role 10, please mind your words and tone of voice in your claims, request and comments, because the roles 1. to 3. could be very sensitive for paternalizing ignorance. Educate yourself first, then contribute substantially. Maybe surprisingly, we value your hands-on work far more than your money. Because in the end nobody can boss the team around, but people will respect the extend and quality of your contribution.
+
+1.  Focus on repository _Keripy_, then
+2.  Feature complete to the KERI core spec and the Trust-over-IP Technological Stack, then
+3.  Versioning of the KERI core functionality.
+
+-   A. developers building on stable version and development versions of the KERI suite
+-   B. implementers that rely on stable versions of KERI.
+
+-   A. breaking changes, conflicting concepts and merge conflicts of development branches
+-   B. breaking changes to older stable versions that are already in use.
+
+To modify and update our Roadmap, we regularly go through Keripy Issues (start of 2024: 130+):
+
+1.  what is obsolete / done already (status)
+2.  what needs to preceed other issues (triggers)
+3.  Most important / most urgent:
+
+-   Important and Urgent
+-   Important not Urgent
+-   Not Important but Urgent
+-   Not Important and Not Urgent
+
+4.  When to start and lead time (week number, days or weeks)
+5.  Where does the development take place (branch)
+6.  What type of test is needed?
+
+1.  open
+2.  none in, none out
+3.  Not Important and Not Urgent
+4.  Not planned, Not specified
+5.  development
+6.  regular unit test
+
+The procedure we have in place, step by step.
+
+-   Go through the issues and change dependencies, effects, timing, importance and urgency according to the current situation
+-   Create, Update, Split Issues and Merge Issues at will, but never Delete an Issue.
+-   Launch Github Action "Roadmap" that has consistency checks
+-   Resolve inconsistencies, e.g. A trigger-issue for many other issues can be "Not Important"?!
+
+-   Look at the Roadmap document, drill down the issues
+-   Make comments to Issues
+-   Create new issues only if there's no existing issue covering the topic / bug
+
+The nature of this project, its status of implementation and the resources to move forward combined, means we can't expect the impossible from people. These are a few examples of which we are simply not able to comply with:
+
+-   backward compatibility of the codebase
+-   feature-synced codebases in several programming languages
+-   fully operational CDCI strategies
+
+Having writing this, we are still able to make some predictions about what'll be happening in the next year and there after. Mind you, garantueed to the front door and we're always happy to see PR requests coming in to smoothen the path to KERI Suite's maturity.
+
+In open source development there's a balance between speed of development and backward compatibility on one hand and a reliable codebase for production purposes on the other.
+
+Please read the sections _Relationship_ and _Procedure_ if you haven't done so before.
+
+Below we present timing and links to the actual issues in the [Keripy github repo](https://github.com/WebOfTrust/keripy).
+
+Plan: when we plan the activity, not the result. However, if we plan an activity that has a preceding trigger activity you could rightfully understand that we plan to have completed the prior activity (enough) to be able to move forward. We stack lead times.
+
+Again, mind you, no guarantees can be given, we cannot take responsibility for commitments / expectations you derive from our roadmap.
+
+| TBW: the actual roadmap in a Direct Acyclic Graph representation? |
+
+-   A github action script will automaticly update the status of the current roadmap
+-   The roadmap will rely on Issue Number for a life time
+
+
+
+
+---
+title: Mindmap
+description: hackmd-github-sync-badge
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/mindmap/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/mindmap/index.md
+---
+
+# Mindmap
+
+[![hackmd-github-sync-badge](https://hackmd.io/AvVG2cZxQJCIe_VHQR8e8Q/badge)](https://hackmd.io/AvVG2cZxQJCIe_VHQR8e8Q)
+
+This is a mindmap of the emcompassing concept of KERI and ACDC
+
+1.  the things we've designed (whitepapers, technical designs)
+2.  the things we've created (repos and code)
+3.  the terminology we use.keridoc/
+
+1.  to be better and quicker understood
+2.  anchor our wording to our objectiveskeridoc/
+3.  criteria how we distinguish importance to us
+
+1.  the newbie digital identity expertkeridoc/
+2.  the advanced SSI identity expert
+3.  SSI expert
+
+keridoc/
+
+1.  static site generated on Github
+2.  reuse resources all over the web
+3.  can be searched and commented on keridoc/
+
+1.  continuously from now
+2.  automatic deployment at changes keridoc/
+
+-   existance and persistance
+-   access and transparency
+-   privacy - consent to use
+-   confidentiality - minimal disclosure
+
+-   commitment and compliance to rules - signature
+-   freedom of speech and movement - inception of AIDkeridoc/
+-   self-sovereignty - portability, delegation and revocation
+-   Protection – users’ rights, censorship-resistant
+
+-   Self-sovereign security
+-   portable identifiers
+-   proofs verifiable to the root-of-trust
+-   break down silos of control and surveillancekeridoc/
+
+keridoc/
+
+keridoc/
+
+keridoc/
+
+1.  authentic
+2.  chained
+3.  serialized data containers
+
+1.  greater interoperability
+2.  reduced ambiguity
+3.  enhanced security
+4.  better immutablykeridoc/
+
+1.  Security first
+2.  then confidentiality
+3.  then privacy
+
+
+
+
+---
+title: Insights into the KERI Development Toolbox
+description: Discover the whys and hows of the development tools that power the KERI system.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/keri-dev-env/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/keri-dev-env/index.md
+---
+
+# Insights into the KERI Development Toolbox
+
+**Discover the whys and hows of the development tools that power the KERI system.**
+
+Please note, this document **will not** delve into:
+
+-   Cypher Libraries used across different KERI implementations.
+
+    > For more insights, visit: [CypherSuites KeriPy](https://github.com/WebOfTrust/keripy/blob/development/ref/CypherSuites.md)
+
+-   Coding Style Guides for various KERI implementations.
+
+    > For further details, visit: [Style Guide for KeriPy](https://github.com/WebOfTrust/keripy/blob/development/ref/PythonStyleGuide.md)
+
+
+The selection of development tools often aligns with a few common motivations. Typically, they possess the following characteristics:
+
+-   Open-source nature
+-   Lack of patent restrictions
+-   Best-in-class functionality
+-   Universal applicability
+-   Proven performance over time
+
+These essential attributes underpin the creation of Autonomic Identifier systems, and will not be reiterated throughout this document. Instead, our spotlight will be on the unique considerations that influenced our choices, setting them apart from other alternatives in the domain.
+
+In the following sections, we'll delve into the key tools employed in the KERI Suite. Each tool's section will answer three critical questions:
+
+1.  **What is {tool X}?** - An overview of the tool.
+2.  **Why is it relevant for the KERI Suite?** - An explanation of how the tool fits into the KERI ecosystem and enhances our operations.
+3.  **Why {tool X} and not something else?** - A rationale of why this specific tool was chosen over other alternatives in the field.
+
+Through this structured approach, we aim to provide clear insights into our development choices and their impact on the KERI Suite.
+
+A social media platform
+
+It used to be our social media platform for development (until mid 2023)
+
+WebofTrust's Slack History is [here](https://weboftrust.github.iokeridoc/slack/html/). Soon you will be able to use [KERISSE search](https://kerisse.org) (upper right corner hour glass) to search through this Archive. For the time being: if you're looking for a specific conversation in the past, you could use good-old Ctrl/command-F per channel page there.
+
+A social media platform
+
+It is our current social media platform for development
+
+We have control over our own server. Discord has sophisticated bots available and is highly adjustable to your needs as a development team.
+
+![Sphinx-logo](https://github.com/WebOfTrust/keri/blob/main/images/Sphinx.png?raw=true) Sphinx is a documentation generator or a tool that translates a set of plain text source files into various output formats, automatically producing cross-references, indices, etc. That is, if you have a directory containing a bunch of reStructuredText or Markdown documents, Sphinx can generate a series of HTML files, a PDF file (via LaTeX), man pages and much more.
+Sphinx experience is a great asset for a GNU Linux technical writer.
+
+[Source](https://www.sphinx-doc.org/en/master/)
+
+KERI's first implementation is in Python. Documenting the why of the code is human effort. Documenting _what the code does_ is easily achieved with Sphinx, in multiple output formats.
+
+Best suited for documenting Python-code as you go as a developer.
+Sphinx uses reStructuredText as its markup language, and many of its strengths come from the power and straightforwardness of reStructuredText and its parsing and translating suite, the Docutils.
+
+![swagger-logo](https://github.com/WebOfTrust/keri/blob/main/images/swagger.png?raw=true)
+
+Formerly known as Swagger, OpenAPI has a long and established history. In 2010, Swagger started as an open source specification for designing and documenting RESTful APIs. In 2015, the Swagger project was acquired by SmartBear Software. The Swagger Specification was donated to the Linux foundation and renamed the OpenAPI.
+
+[Difference](https://swagger.io/blog/api-strategy/difference-between-swagger-and-openapi/)
+
+KERI is trustless and is a multi layered identity-system generator. A full-functioning KERI install uses many different nodes to talk to (Witnesses, watchers, wallets). RESTfull APIs are best suited for this task.
+
+![openapi-logo](https://github.com/WebOfTrust/keri/blob/main/images/openapi.png?raw=true)
+
+OpenAPI (former Swagger, before version 2.0) is more important than the company Swagger to KERI, CESR and ACDC. It's open sourced and has many ready-usable extensions in JSON available.
+
+![restapi-logo](https://github.com/WebOfTrust/keri/blob/main/images/restapi.png?raw=true) There are numerous types of APIs, making it difficult for new developers to differentiate between each kind. In particular, REpresentational State Transfer (REST) is a software architectural style that developers apply to web APIs. REST APIs provide simple, uniform interfaces because they can be used to make data, content, algorithms, media, and other digital resources available through web URLs. Essentially, REST APIs are the most common APIs used across the web today
+
+To make the API service RESTful, six guiding constraints must be satisfied:
+
+1.  Use of a uniform interface (UI): To have a uniform interface, multiple architectural constraints are required to guide the behavior of components. Additionally, resources should be unique so they are identifiable through a single URL.
+2.  Client-server based: The uniform interface separates user concerns from data storage concerns. The client’s domain concerns UI and request-gathering, while the server’s domain concerns focus on data access, workload management, and security. The separation of client and server enables each to be developed and enhanced independently of the other.
+3.  Stateless operations: Request from client to server must contain all of the information necessary so that the server can understand and process it accordingly. The server can’t hold any information about the client state.
+4.  RESTful resource caching: Data within a response to a request must be labeled as cache-able or non-cache-able.
+5.  Layered system: REST allows for an architecture composed of hierarchical layers. In doing so, each component cannot see beyond the immediate layer with which they are interacting.
+6.  Code on demand: Because REST APIs download and execute code in the form of applets or scripts, there’s more client functionality. Oftentimes, a server will send back a static representation of resources in the form of XML or JSON. Servers can also send executable codes to the client when necessary.
+
+[Source](https://blog.postman.com/rest-api-examples/)
+
+KERI is multi layered and has duplicity detection as one of its main consensus mechanisms.
+
+Stateless REST APIs are vital for the implementation of the KERI design.
+
+A Wrapper Class (or the Wrapper Pattern) is where you declare a Class as a container for an sObject to extend the functionality only for display or processing purposes (i.e. you don't intend for that attribute to be persisted) - the classic example is a checkbox to select records. I would say that a DTO is a slightly dumbed down version of such a wrapper (used in conventional OOP to pass structured data between the layers) A REST Api wrapper is something slightly different. For example Salesforce exposes a REST Api and if you were to invoke that say from C#, you would have to perform a set of common steps such as login, query, etc. To make this available in C# by abstracting the innards of the actual REST calls to salesforce and exposing only the developer relevant detail, you could write a rest wrapper which performs these commonly used functions - creates requests, parses responses, etc
+
+[Source](https://salesforce.stackexchange.com/questions/5834/can-somebody-explain-what-is-a-rest-api-wrapper)
+
+KERI will be written in multiple programming languages. A wrapper is able to expose the result of API calls cross boundary (exceeding the developers direct intentions) or viewable / shareable a different programming language.
+
+It's simply the most obvious solution for the applications mentioned above.
+
+![postman-logo](https://github.com/WebOfTrust/keri/blob/main/images/postman.png?raw=true)
+
+Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster. [source](https://www.postman.com)
+
+It is a sophisticated EDI for KERI APIs.
+
+| TBW |
+
+![paw-logo](https://github.com/WebOfTrust/keri/blob/main/images/paw.png?raw=true)
+
+Paw is a full-featured HTTP client that lets you test and describe the APIs you build or consume. It has a beautiful native macOS interface to compose requests, inspect server responses, generate client code and export API definitions.
+
+[Source](https://paw.cloud)
+
+Source tracking
+
+| TBW |
+
+![XBRL-logo](https://github.com/WebOfTrust/keri/blob/main/images/XBRL.png?raw=true)
+
+XBRL is the open international standard for digital business reporting, managed by a global not for profit consortium, XBRL International. We are  committed to improving reporting in the public interest. XBRL is used around the world, in more than 50 countries. Millions of XBRL documents are created every year, replacing older, paper-based reports with more useful, more effective and more accurate digital versions. In a nutshell, 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 organizations rapidly, accurately and digitally.
+
+[Source](https://www.xbrl.org/the-standard/what/an-introduction-to-xbrl/)
+
+It's especially relevant for the GLEIF vLEI implementation of KERI and ACDC.
+
+It is _the_ open international standard for digital business reporting.
+
+![Arelle-logo](https://github.com/WebOfTrust/keri/blob/main/images/Arelle.png?raw=true)
+
+Arelle is a project to provide the XBRL community with an easy to use open source platform for XBRL. It supports XBRL and its extension features in an extensible manner. It does this in a compact yet robust framework that can be used as a desktop application and can be integrated with other applications and languages utilizing its web service.
+
+[Source](https://arelle.org/arelle/)
+
+Continuous Development Continuous Integration on Github
+
+It is most probanly the only one out there
+
+![Docker-logo](https://github.com/WebOfTrust/keri/blob/main/images/Docker.png?raw=true)
+
+Docker is an open source platform for building, deploying, and managing containerized applications. Learn about containers, how they compare to virtual machines (VM), and why Docker is so widely adopted and used.
+[Source](https://www.ibm.com/cloud/learn/docker)
+
+With Docker containerization the KERI development team is able to deliver a working stack for testing and demonstration purposes with a clear list of components and their versions in a confined environment.
+
+Docker is the most adopted and has various deployment options.
+
+![ntru-logo](https://github.com/WebOfTrust/keri/blob/main/images/ntru.png?raw=true)
+
+NTRU is an open-source public-key crypto-system that uses lattice-based cryptography to encrypt and decrypt data. It consists of two algorithms: NTRUEncrypt, which is used for encryption, and NTRUSign, which is used for digital signatures. Unlike other popular public-key crypto-systems, it is resistant to attacks using Schnorr's algorithm. NTRUEncrypt was patented, but it was placed in the public domain in 2017. NTRUSign is patented, but it can be used by software under the GPL.
+
+[Source](https://en.wikipedia.org/wiki/NTRU)
+
+It might be an alternative to our Libsodium libs. But... - Looks like NTRUSign is broken. - NTRUEncrypt is usable. - pqNTRUSign uses large signature sizes so is not immediately suitable for IOT [More info](https://csrc.nist.gov/CSRC/media/Events/Second-PQC-Standardization-Conference/documents/accepted-papers/grobschadl-lighteight-implmentation-NTRUE.pdf)
+
+It not as computational dense as alternatives. It is newer.
+
+![caxe-logo](https://github.com/WebOfTrust/keri/blob/main/images/caxe.png?raw=true)
+
+It's Credential Attribute XBRL Extraction. An XBRL with ACDCs in it.
+
+[Source](https://github.com/WebOfTrust/caxe)
+
+XBRL is the open international standard for digital business reporting. To extend the field of application of ACDC and KERI in reporting, we'd like to offer this.
+
+It's custom made for ACDC and KERI, there's nothing else.
+
+![gh-actions-logo](https://github.com/WebOfTrust/keri/blob/main/images/gh-actions.png?raw=true)
+
+GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triage-ing work the way you want.
+[Source](https://github.com/features/actions)
+
+{TBW}
+
+Hosted runners for every major OS make it easy to build and test all your projects. Run directly on a VM or inside a container. Use your own VMs, in the cloud or on-prem, with self-hosted runners.
+
+![gitflow-logo](https://github.com/WebOfTrust/keri/blob/main/images/gitflow.png?raw=true)
+
+Git flow is a popular Git branching strategy aimed at simplifying release management, and was introduced by software developer Vincent Driessen in 2010. Fundamentally, Git flow involves isolating your work into different types of Git branches.
+
+[Source](https://www.gitkraken.com/learn/git/git-flow)
+
+Multiple developers active and growing developers community needs simple but secure branching.
+
+More secure than the easier versioning [Github Flow](https://www.gitkraken.com/learn/git/git-flow#github-flow) and [GitLab Flow](https://www.gitkraken.com/learn/git/git-flow#gitlab-flow)
+
+Powerful, high-trust, self-sovereign interactions over any transport
+
+[Source](https://didcomm.org/)
+
+To build KERI Tunnels
+
+It's the intended layer two of DID technology supported by Decentralized Identity Foundation (DIF) and the Trust over IP foundation (ToIP).
+
+![Java-logo](https://github.com/WebOfTrust/keri/blob/main/images/Java_logo.png?raw=true)
+
+IT's a JavaEE library for CESR encoding
+
+[Source](https://github.com/WebOfTrust/cesr4j)
+
+CESR is the main serialization tool for KERI. To extend the field of application of CESR we'd like to offer an JavaEE library.
+
+It's custom made for CESR and KERI, there's nothing else.
+
+![bazel-logo](https://github.com/WebOfTrust/keri/blob/main/images/bazel-logo.png?raw=true)
+
+Bazel is an open-source build and test tool that scalably supports multi-language and multi-platform projects.
+
+[Source](https://bazel.build/)
+
+One tool, multiple languages: Build and test using Java, C++, Go, Android, iOS and many other languages and platforms. Bazel runs on Windows, macOS, and Linux.
+
+It replaces [Maven](https://maven.apache.org/).Rebuild only what is necessary. Fast, incremental builds with Bazel's advanced local and distributed caching, optimized dependency analysis, and parallel execution.
+
+![webauth-logo](https://github.com/WebOfTrust/keri/blob/main/images/webauth.png?raw=true)
+
+WebAuthn is a new standard for authentication, which is published by the World Wide Web Consortium and is supported by the FIDO alliance.
+
+[Source](https://www.loginradius.com/blog/identity/webauth-secures-user-login/)
+
+It's not yet relevant, it's been proposed to support it in the future.
+
+| TBW |
+
+Issuance and Exchange Protocol Specification for ACDC
+
+[Source](https://github.com/WebOfTrust/ietf-ipex)
+
+Provides a uniform mechanism for the issuance and presentation of ACDCs in a securely attributable manner.
+
+It's a greatly simplified exchange protocol. The 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.
+
+The Python Package Index (PyPI) is a repository of software for the Python programming language.
+PyPI helps you find and install software developed and shared by the Python community. Learn about installing packages. Package authors use PyPI to distribute their software. Learn how to package your Python code for PyPI.
+[Source](https://pypi.org/)
+
+The team wants to distribute KERI uniformly and as broad as possible.
+
+It's the best of breed and most commonly used in the Python community.
+
+![npm-logo](https://github.com/WebOfTrust/keri/blob/main/images/npm.png?raw=true)
+
+NPM is two things: first and foremost, it is an _online repository_ for the publishing of open-source Node.js projects; second, it is a _command-line utility_ for interacting with said repository that aids in package installation, version management, and dependency management. [Source](https://nodejs.org/en/knowledge/getting-started/npm/what-is-npm/)
+
+For the Node.js implementation of KERI it comes in handy. Also KEEP has been build in Node.js.
+
+It's the number one solution for Node.js.
+
+![dart-logo](https://github.com/WebOfTrust/keri/blob/main/images/dart.png?raw=true)
+
+Dart is a programming language designed for client development, such as for the web and mobile apps. It is developed by Google and can also be used to build server and desktop applications. It is an object-oriented, class-based, garbage-collected language with C-style syntax.It can compile to either native code or JavaScript, and supports interfaces, mixins, abstract classes, reified generics and type inference.
+
+[Source](https://en.wikipedia.org/wiki/Dart)
+
+Not yet, we might want to support it, it's been proposed in the past.
+
+| TBW |
+
+KIMI Keri Interactive Mobile Interface, pronounced “Caramel”
+
+Keep repackage Electron app to invoke python backend IIW demos (April 2022) on UX/UI
+
+It's been subject to name squating, it's pending.
+
+Weightless Hierarchical asynchronous coroutines and I/O in Python.
+Rich Flow Based Programming Hierarchical Structured Concurrency with Asynchronous IO.
+
+Choosing HIO fits the asynchronous nature of KERI. See more at Github [Repository](https://github.com/ioflo/hio)
+
+The minimal sufficient means design principle of KERI and the leading KERIpy implementation.
+
+
+
+
+---
+title: WOT Concepts
+description: All the historical and actual concepts behind KERI and its off-springs
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/intro/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/intro/index.md
+---
+
+# WOT Concepts
+
+All the historical and actual concepts behind KERI and its off-springs
+
+
+
+
+---
+title: Concepts
+description: hackmd-github-sync-badge
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/concepts/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/concepts/index.md
+---
+
+# Concepts
+
+[![hackmd-github-sync-badge](https://hackmd.io/TYKEsJ5OQy-4w78NUGRSMA/badge)](https://hackmd.io/TYKEsJ5OQy-4w78NUGRSMA)
+
+THIS IS UNDER CONSTRUCTION Would you like to contribute? Join us at the Concepts, Terminologie and Education [Repo](https://github.com/WebOfTrustkeridoc/ain/README.md)
+
+This concepts page explains the main design objectives of KERI and ACDC, which results in a scope (or context) and links them to
+
+1.  the things we've _designed_ (whitepapers, technical designs)
+2.  the things we've _created_ (repos and code)
+3.  the terminology we use
+4.  the tutorials we offer
+
+To be understood better and quicker, to be able to pick your educational material more confidently, and to learn more efficiently. These pages share and exchange our criteria to why and in which situation something is important to us. It's a way to anchor our language and words we use to our values, findings and objectives.
+
+The ultimate goal is to make sense in the perception of the proficient **technical identity expert** who'd like to learn to **code and implement (parts) the KERI suite**.
+We'll not try to reach out to laymen, newbies, and not to the advanced identity expert or not-technical expert. The reason for this is, we'd like to stay focussed.
+
+Of course we happen to also serve newcomers and more advanced people with explanation matching their level of knowledge, however, we do not aim at educating those user groups.
+
+A static site generated on Github, that uses resources all over the web and can be commented on.
+
+Also a [howto](https://github.com/WebOfTrustkeridoc/tree/main/howto) will be written along side to inform contributors how to add, link and amend resources.
+
+The intention is to have _resources_ (glossaries, videos, etc.) and _howtos_ available continuously. It'll hopefully improve over time. The resulting static **WebofTrust-site** is already here: [https://weboftrust.github.iokeridoc/](https://weboftrust.github.iokeridoc/) and will automatically be generated through Github Actions.
+All intermediate results are also **directly available** in the Github repo:
+
+-   [resources](https://github.com/WebOfTrustkeridoc/tree/main/resources)
+-   [howtos](https://github.com/WebOfTrustkeridoc/tree/main/howto)
+-   Glossaries: [TrustoverIP/ACDC](https://github.com/trustoverip/acdc/wiki) and [eSSIF-lab](https://essif-lab.github.io/framework/docs/essifLab-glossary)
+
+The [Mental Model](https://github.com/WebOfTrustkeridoc/blob/main/mental-model.md) of KERI suite gives the frame of reference for our concepts below.
+
+KERI is fully Open Source under [Apache-2 license](https://github.com/WebOfTrustkeridoc/blob/main/LICENSE). Some typical **aspects of open source software development** and their communities that we value:
+
+-   We reuse as much as possible, using open source tools
+-   We try to release quickly and often
+-   We avoid vendor locks, propietary lock-ins and censorship
+-   We scratch our own itch and expect you to do so too
+
+![CDCI design for WOT-terms](https://hackmd.io/_uploads/r1BYbPfA5.png)
+
+In the following write-up we use well-known common terminology and also introduces new terminology. It's aimed at Self-Sovereign Identity experts specifically. Specially the general terminology could create confusion between parties, because terms like this may cover a broader scope or mental model than just KERI or Self-Sovereign Identity as a field.
+
+> Example: a _witness_ in common identity - and blockchain theory most probably has a different connotation then what a 'witness' is in KERI.
+
+We explain the terminology at various [levels of understanding](https://github.com/WebOfTrustkeridoc/blob/main/README.md#levels-of-understanding), and also **our criteria** how we judge certain terms to be defined for the sake of KERI / ACDC. E.g. `multisignatures`, `validators` and `verifiers`.
+
+1.  What have we decided that they mean to us in our mental model, and if so
+2.  Have we formulated criteria and edge cases so that we can determine whether an instances of a term is in or out of the scope of the definition
+
+Understanding could vary in different domains and use-cases (e.g. a controller in finance is quite different from a controller of an identifier). We need to be sure that parties in a conversation are talking about "the same thing".
+
+KERI is a new development. CESR and OOBI are new auxilary concepts to get KERI going within its frame of reference: the trust spanning layer KERI likes to provision. As an example we therefore can't use just CBOR and had to invent a dedicated event streaming representation that is pipelineable and composable.
+
+ACDC and it's auxilary concepts IPEX, KERIA, SIGNIFY are build on top of KERI; so it's new too. Inevitably, new terminology has surfaced in the design of KERI and ACDC. In this `concepts` section we try to explain related terms in a few [levels of understanding](https://github.com/WebOfTrustkeridoc/blob/main/README.md#levels-of-understanding) but as mentioned above always focussed on the sole objective to reduce learning time of KERI developers in spé.
+Here and there we've used analogies and symbols to clear up complex and intangible concepts for those new to KERI / ACDC and even for those experts that we consider being 'advanced'. The derived goal is to try to make sense in the perception of the newbie - and the advanced identity expert "as we go" for the main objective and target group: Reduce learning time for KERI devs to be. Please bear this in mind.
+
+> An example of much heard complaints: "KERI is too complex, the 160-page KERI white paper is indigestable, let alone the hunderds of other pages that written on top of this." Our response to this is: KER, CESR and ACDC is a new and all-emcompassing theory to fix the identity flaw of the internet in a secure, confidential and privacy-preserving way. It is no more complex than it needs to be. And the KERI suite uses simple long-lived and well-tested cryptography.
+
+No meaningful identifier - and key management system without governance. Governance is targeted at practical individual use in granted roles and user groups by describing the process and juristical boundaries.
+
+More in | TBW prio 2 |
+
+Why do we urge to take note of both sides of the ToIP stack while we're focussing on developers?
+
+Not only developers have a natural tendency to forget about how important an integral approach of identity is when designing, coding and implementing system in our society. Even a well-meant system can turn our society into a dystopian state if we don't consider all aspects of them.
+
+More on this \[Sheldrake\](https://weboftrust.github.io/keridoc/docs/concepts/concepts/ | TBW prio 1 | .md)
+
+Now that we've set the stage the replay of how KERI came to be, can begin.
+
+Sam Smith the originator of KERI has set the bar for KERI and continues to do so infatiguably in nearly all Zoom sessions in our KERI space. I hope he gets to chance to look over the following list of core values KERI represents that I distilled in the past few years from those meetings, responses to questions in social media, during IIWs, in whitepapers, articles and technical designs. And correct & amend the list in the driven and direct way we're used to.
+
+**Above all: security.**
+We simply can't negotiate the highest level of security at the most fundamental level of the technical stack. You can build a less secure system on top of a 100% secure system, but not the other way around.
+
+Security, confidentiality and privacy. You can't have them all to their full extent at the same time. We sacrifice privacy for confidentiality and confidentiality for security. We don't negotiate security at the most fundamental level of the technical stack and hardly ever in the layers above.
+
+| TBW image |
+
+-   existance and persistance
+-   access and transparency
+-   privacy - consent to use
+-   confidentiality - minimal disclosure at all times
+
+-   commitment en compliance to rules - signature
+-   freedom of speech and movement - inception of AIDs, rotation
+-   self-sovereignty - delegation and revocation
+-   Protection – users’ rights, censorship-resistant
+
+Sam Smith is the creator of KERI. But one man alone, even Sam, can't pull off an all-emcompHow did these values that were inherently present in the creator of KERI become explicit over time, how did they become a group culture or a team signature. And lastly how have these shared values ignited common objectives for KERI.
+
+KERI came to be in occasional happenings, online and in-person, in which individuals voluntarily participated. It has no members, and no dues. This is how the KERI community strives to further work.
+
+Manifestation: KERI has found the IETF as a home. This is because its value statement and organizational principles strongly resonate with KERI.
+
+The KERI team maintains the following rules of thumb for all the repos in the [WoT project](https://github.com/WebOfTrust):
+
+-   '_outgoing == incoming_' policy ([Read more](#outgoing-is-incoming))
+-   No restrictions more stringent than Apache2 ([No poisoning](#no-poisoning))
+-   comprehensive licensing
+-   No splitting contributions between different licenses
+-   Possible to have less restrictive outgoing than incoming ( [Read more](##possibility-to-have-less-restrictive-outgoing-than-incoming) )
+
+All the repos in the [WoT project](https://github.com/WebOfTrust) where the KERI code and related standards reside, have a '_outgoing == incoming_' policy. This means that someones use (outgoing) of a contribution (incoming) is on the same basis or license.
+
+Prevent contributions to the code from being poisoned by other contributions that have a different i.e. more restrictive outgoing license, because once contributed there is no way to separate contributions.
+
+> Example: IETF requires that IETF spec language be contributed under BSD not Apache2. But BSD is no less restrictive than Apache2 for outgoing so it does not poison the apache2 contributions. A consumer can consume under apache2 or via IETF through BSD. BSD is no more restrictive than Apache2. The license for the IETF spec repos in WoT include the BSD outgoing in addition to Apache2 for this reason.
+
+or have multiple outgoing licenses that are of the same or less level of restriction but with different names because some consumers want to consume (outgoing) under a different license.
+
+**Manifestation:**
+**Apache2 license default**
+
+Need: Fix the limitations of the original PKI-based WebofTrust. Goal: Achieve a truly decentralized trust spanning layer for the Internet; (see [Hourglass Model](https://cacm.acm.org/magazines/2019/7/237714-on-the-hourglass-model/fulltext))
+
+Manifestation:
+security - maximum coverage (extensible prefixes) - no middle men - portability
+
+We only have one set of tools for truly secure data control! Cryptographic one-way functions! [source](https://www.youtube.com/watch?v=L82O9nqHjRE)
+
+All designs accommodate for the foreseeable future in terms of size and number of types or variations.
+
+Example in CSER:
+
+> The design aesthetic is based on the understanding that there is a minimally sufficient cryptographic strength and more cryptographic strength is just wasting computation and bandwidth. The accepted minimum for cryptographic strength is 128 bits of entropy or equivalently 2\*\*128 (2 raised to the 128th power) brute force trials. [Source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#compact-fixed-size-codes) IETF Draft CESR
+
+This is the reason why the multisig rotation scheme has been changed at the beginning
+
+See the features here : [https://github.com/trustoverip/acdc/wiki/transfer-off-ledger](https://github.com/trustoverip/acdc/wiki/transfer-off-ledger)
+
+"The point is to be used, not to use the latest, coolest technique that is also very difficult to implement properly. That's the principle of KERI: solve a problem in the real world with the minimum techniques needed. The dumber the technology, but still sufficient to solve the problem, the better. 'Dumb technology' is freely available, understandable to everyone and easy to implement. In our case: just hashes and digital signatures." Source: [Sam Smith](https://docs.google.com/document/d/1quOTSGPuFXa_pduaGSHWY8LpfXZiYjzR) 2022
+
+Samuel Smith about `English Semantic Naming`:
+
+-   English has operators and has 6M words. Operators can be used to create valid words that are not in the dictionary. 6 million words in the English language, many relatively unused, and without baggage.
+
+> GOAL: Keep KERIpy more readable with short, evocative names.
+
+-   To Polysemy (ambiguity): ‘Type’ as an example -> too many meanings, you need to disambigue this
+-   Book “C elements and style” is advised: [https://www.amazon.com/Elements-Style-Programmers-Elegant-Programs/dp/1558512918](https://www.amazon.com/Elements-Style-Programmers-Elegant-Programs/dp/1558512918)
+
+> Example: Habitat ‘where everything resides’ -> Hab -> Habery
+
+1.  |noun|
+2.  Er = object instances that do stuff
+3.  Ery = factory classes or classes that manage other classes
+4.  |noun|+s -> Sigs, Sigers = a list of Sig and a list of Siger
+
+> Example II:
+>
+> -   siger - creates signatures
+> -   sig - would be qb64 representation of a signature
+> -   sigs - would be a list of signatures
+
+ACDC has been implemented inside of keripy. We have full credential issuance, revocation and streaming support in both the REST API as well as the command line.
+Source P. Feairheller, 2022
+
+> "We don't have version 1 of the specs of KERI yet.""
+
+As soon as we do, the code will look the version up, and act accordingly (backward compatibility).
+
+We split the KERIpy repo in two branches `dev` and `main`, so people can rely on a stable production version in `main`.
+
+1.  Authentic
+2.  Chained
+3.  Data containers (serialization of them) Mainly through SAIDs.
+
+Embedding a SAID as a field in the associated serialization indicates a preferred content-addressable identifier for that serialization that facilitates **greater interoperability**, **reduced ambiguity**, and **enhanced security** when reasoning about the serialization. Moreover, given sufficient cryptographic strength, a cryptographic commitment such as a signature, digest, or another SAID, to a given SAID is essentially equivalent to a commitment to its associated serialization. Any change to the serialization invalidates its SAID thereby ensuring secure immutability evident reasoning with SAIDs about serializations or equivalently their SAIDs. Thus SAIDs **better facilitate immutably** referenced data serializations for applications such as Verifiable Credentials or Ricardian Contracts.\\
+
+[Source](https://datatracker.ietf.org/doc/draft-ssmith-said/)
+
+The purpose of this paper is to capture and convey to a broader audience my increasingly worrisome concerns about the adoption path for Verifiable Credentials (VCs). My concerns began with the security limitations of VCs that use Linked Data (otherwise known as JSON-LD/RDF) and have since extended to the semantic inference limitations of Linked Data. My concerns may be expressed succinctly as, the VC standard appears to be an adoption vector for Linked Data, not the other way around. My overriding interest is that the concept of a VC as a securely attributable statement is a very powerful and attractive one and therefore should be widely adopted. We should therefore be picking the best technologies that best support broad VC adoption, not the other way around.
+Source: VC Spec Enhancement Strategy Proposal by Sam Smith
+
+Use _trans-contextual value_ creation and capture to fuel cooperative network effects.
+
+Sam is going to develop this
+
+**Security: technical**
+Sufficient cryptographic strength (quantum safe)
+Everything signed enforced ([strong bindings](#strong-bindings) and commitments, immutability)
+[Verifiable to root-of-trust](#verifiable-to-the-root-of-trust) (no middlemen)
+Fine-grained control mechanisms (lossless scalable in every technical direction; speed, prog.languages, codetables in CESR, )
+Proven technology for cryptographic functions (robustness)
+Interoperable by design (covers everthing; internet and off-line)
+Minimalized attack surface (reuse of primitives)
+Continuous internal and external consistency checks of data structures (duplicity)
+
+**Security: human self protection**
+Private keys as far away from agents as possible (only signatures exposed)
+pre-rotation (double-checked control authority)
+Rotation (act when you smell danger)
+Delegation (engage service provider without losing control; middleman on a leash)
+Revocation (minimize effects of adversely situation)
+Scalable witness & watchers network (reconciliation options; _first seen_)
+Round-robin composable streaming (for readability of commitments)
+Tamper evident (duplicity checks)
+Non-repudiation
+
+-   Private keys are not being kept private
+-   Private keys are reused over and over to sign stuff
+
+-   Controller binds cryptographic protected data to him/herself (by mistake)
+-   Graduated disclosure isn't used |TBW|
+
+-   Third party binds cryptographic protected data to other actors involved (by mistake) |TBW|
+
+| BASIS FOR COMPARISON | PRIVACY | CONFIDENTIALITY |
+| --- | --- | --- |
+
+| Meaning | The state of being secluded is known as Privacy. | Confidentiality refers to the the situation when it is expected from someone that he will not divulge the information to any other person. |
+| What is it? | It is the right to be let alone. | It is an agreement between the persons standing in fiduciary to maintain the secrecy of sensitive information and documents. |
+| Concept | Limits the access of the public. | Prevents information and documents from unauthorized access. |
+| Applies to | Individual | Information |
+| Obligatory | No, it is the personal choice of an individual | Yes, when the information is professional and legal. |
+| Disallowed | Everyone is disallowed from involving the personal affairs of an individual. | Only unauthorized persons are disallowed from using the information. |
+
+![privacy-vs-confidentiality table](https://raw.githubusercontent.com/WebOfTrustkeridoc/gh-pages/images/privacy-vs-confidentiality.png) [Source:](https://keydifferences.com/difference-between-privacy-and-confidentiality.html) Keydifferences.com
+
+_Security first_
+
+_Security first_, _confidentiallity_, _privacy_
+
+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
+-   delegated identifiers Consequently when applied recursively, delegation may be used to compose arbitrarily complex trees of hierarchical (delegative) key management event streams.
+
+This is the arguably 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. (new invention) More in the [whitepaper](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
+
+See [glossary item](https://github.com/trustoverip/acdc/wiki/non-repudiable)
+
+KERI alternative to total global ordering and consensus protocols is a mechanism called _Duplicity detection_. In the [verification](https://weboftrust.github.iokeridoc/docs/glossary/verification) and [validation](https://weboftrust.github.iokeridoc/docs/glossary/validate) **watchers are all that matter**; they guarantee that logs are immutable by one very simple rule: "[first seen](https://weboftrust.github.iokeridoc/docs/glossary/first-seen) wins".
+
+Because the cryptographic material in the events may be of variable length, a fixed field length serialization is not a viable approach. Consequently KERI must support variable length field serialization.
+
+Only the controller of the associated identifier prefix may compose KERI events, the ordering of elements in the event serialization may be determined solely by that controller. Other entities may sign the event serialization provided by the controller but do not need to provide a serialization of their own.
+
+In summary, the necessary constraint for complete event serialization is support for arbitrary data structures with variable length fields that are serializable and de-serializable in multiple formats. Reproducible ordering is not a necessary constraint. [Source](https://github.com/decentralized-identity/keri/blob/master/kids/kid0003)
+
+([Source](https://medium.com/happy-blockchains/cesr-one-of-sam-smiths-inventions-is-as-controversial-as-genius-d757f36b88f8))
+
+CESR uses a parse table so the same parsing code works on all codes.
+
+The text domain representation of a stream enables better usability (readability) and the binary domain representation of a stream enables better compactness.
+
+Allow efficient conversion or off-loading for concurrent processing of composed (concatenated) groups of primitives in a stream without having to individually parse each primitive before off-loading.
+
+**CESR is digital data streaming that**
+
+1.  can freely concatenate pieces of data
+2.  Has a fixed streamlet size in both text and binary format
+3.  Converts back and forth from text to binary without data loss and round robin
+4.  Is able to express complex data structures
+5.  Is extensible with derivation codes
+6.  Is extremely compact
+7.  Works asynchronously, e.g. collecting primitives, such as individual signatures of a Multisig from the web.
+8.  Is ready for post-quantum cryptography
+9.  Contributes to legally sound identifiers, because everything is “readable” in text format.
+
+“CESR doesn’t provide post-quantum proofing. The hash does. CESR just makes it easier to process the crypto material. How you use crypto material is not up to CESR.” Samual M. Smith
+This list of reinforcing features might make you think of new fields of application. That’s not entirely surprising and, to reiterate, that was my only goal with this article.
+Let me offer you a few applicable and hopefully inspiring facts to play around with in your head.
+Composability allows text domain streams of primitives or portions of streams (streamlets) to be converted as a whole to the binary domain and back again without loss.
+Fully qualified KERI cryptographic primitives are composable via concatenation in both the text (Base64) and binary domains.
+CESR’s approach to filling its derivation-code tables is a first needed, first served basis.
+In addition CESR’s requirement that all cryptographic operations maintain at least 128 bits of cryptographic strength precludes the entry of many weak cryptographic suites into the tables.
+
+"There are many coding schemes that could satisfy the composability constraint of alignment on 24-bit boundaries. The main reason for using a text domain-centric encoding is higher usability, readability, or human friendliness. Indeed **a primary design goal of CESR is to select an encoding approach that provides high usability, readability, or human friendliness** in the _text_ domain. This type of usability goal is simply not realizable in the binary domain.
+The _binary_ domain's purpose is merely to **provide convenient compactness at scale**. We believe usability in the text domain is maximized when the _type_ portion of the prepended framing code is stable or invariant. Stable type coding makes it much easier to recognize primitives of a given type when debugging source, reading messages, or documents in the text domain that include encoded primitives. This is true even when those primitives have different lengths or values."
+[Source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr) IETF Draft CESR.
+
+There are two possibilities for CESR's coding scheme to ensure a composable 24-bit alignment. The first is to add trailing pad characters post-conversion. The second is to add leading pad bytes pre-conversion. Because of the greater readability of the value portion of both the fully qualified text, T, or fully qualified binary, B, domain representations, the second approach was chosen for CESR.
+[Source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#code-characters-and-lead-bytes) IETF Draft CESR.
+
+Good cold start **re-synchronization** is essential to robust performant stream processing. Special CESR count codes support re-synchronization at each boundary between interleaved CESR and other serializations like JSON, CBOR, or MGPK
+
+The design goals for CESR framing codes include minimizing the framing code size for the most frequently used (most popular) codes while also supporting a sufficiently comprehensive set of codes for all foreseeable current and future applications. The design strives for a high degree of both flexibility and extensibility. We believe this is best achieved with multiple code tables each with a different coding scheme that is optimized for a different set of features instead of a single one-size-fits-all scheme. [Source](https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#multiple-code-table-approach).
+
+principles and pre-conditions
+
+principles and pre-conditions
+
+We have two types: witnesses (for the controller) and backer to check duplicity in the network. The reason we've done this because we thus avoid the _eclipse attack_, that blockchains suffer from.
+
+We foresee witness and watcher hosting services, just like web hosting currently. Technically speaking a watcher and a witness use the same code and protocol, watchers run in _promiscuous mode_.
+
+Correlation between identifiers and there controlling human beings and binding of identifiers to human beings in general.
+
+Applying salts, stretching passwords, etc.
+
+There are a few commons reasons to choose development tools. Mostly because they have the following features:
+
+-   open source
+-   not patented
+-   best of breed
+-   universally applicable
+-   tested for a few years
+
+The 10 principles were coined by Christopher Allen, one of the pioneers within this world, concerning the Self-Sovereign Identity (SSI). According to Allen, SSI can be interpreted in two ways: the first is ideological, which (key reading) affirms the importance of being able to control one’s own identity on the network without the need to counter trust; the second is technological, which means analysing which technologies and technological standards can enable this objective. The 10 principles of the SSI are precisely intended to define what values and goals the idea and technology should pursue. They were first enunciated in [Allen’s blog](http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html).
+We've integrated the 10 principles in [Social Values](#social-values) and [Societal Values](#societal-values) above.
+
+It weakens them, because it exposes it and allows people an opportunity to try and work against it.
+
+It's all your own identifier and you're controlling your identifier, so it's up to you what security constraints you want for that identifier. Anchoring, witness pools, thresholds, etc.
+
+Best and compactly described by Daniel Hardman in [Security, Silos, and Sovereignty](https://daniel-hardman.medium.com/security-silos-and-sovereignty-522e30bb8eb4) 2022:
+"SSI is not bestowed by corporate IT (Active Directory/LDAP systems); it’s not granted by internet giants (“sign in with Google/Facebook”); it’s not arranged through single sign-on vendors. SSI is for ordinary people who detest their messy collection of usernames and passwords, and just want bad guys to go away and good guys to enjoy the trust they deserve. SSI puts us — not institutions that leak our data to hackers, sell our data to partners, or surveil us for their own purposes — in charge. It also empowers governments, businesses, and other institutions that want to revolutionize privacy, redefine the cybersecurity and regulatory landscape, reduce cost and risk, keep people safe in pandemics, and do right by the people they serve."
+
+Principle: In a society there needs some control and surveillance of individuals (or individual entities) for the sake of the security of society as a whole. However, those situation should be limited to absolute minimum needed and be strictly independently monitored. We consider all other control and surveillance to be "needless".
+
+Manifestion: A robust witness network along with consistent witness rotation provides protection from monitoring and association of an individual's activity inside a KERI network.
+Source [Phil Feairheller](https://github.com/WebOfTrust/ietf-did-keri/blob/main/draft-pfeairheller-did-keri.md#privacy-considerations)
+
+
+
+
+---
+title: Visualisations
+description: Visualisations.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/visualisations/index
+  md: https://weboftrust.github.io/keridoc/docs/category/visualisations/index.md
+---
+
+# Visualisations
+
+[
+
+## 📄️ Backed and Backerless Issuance and Revocation
+
+Flow charts created by Jason Colburne.
+
+](https://weboftrust.github.io/keridoc/docs/visualisations/backed-and-backerless-issuance-and-revocation.md)
+
+[
+
+## 📄️ KERI & ACDC Architecture
+
+Flow charts created by Kent Bull.
+
+](https://weboftrust.github.io/keridoc/docs/visualisations/keri-and-acdc-architecture.md)
+
+[
+
+## 📄️ KERIA Service Architecture
+
+;
+
+](https://weboftrust.github.io/keridoc/docs/visualisations/keria-service-architecture.md)
+
+[
+
+## 📄️ Animated visualisation of repo connections
+
+See visualisation
+
+](https://weboftrust.github.io/keridoc/docs/visualisations/repo-connections.md)
+
+[
+
+## 📄️ Various visualisations from Slack discussions
+
+1
+
+](https://weboftrust.github.io/keridoc/docs/visualisations/various-visualisations-from-slack.md)
+
+
+
+
+---
+title: Video
+description: Video's.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/video/index
+  md: https://weboftrust.github.io/keridoc/docs/category/video/index.md
+---
+
+# Video
+
+[
+
+## 📄️ 2024-03-24 KERI dev call
+
+Why Zoom to KERISSE?
+
+](https://weboftrust.github.io/keridoc/docs/video/2024-03-24-KERI-dev-call.md)
+
+[
+
+## 📄️ Let's KERI on together
+
+The video
+
+](https://weboftrust.github.io/keridoc/docs/video/lets-keri-on-together.md)
+
+
+
+
+---
+title: Various external glossaries
+description: Here you find various external glossaries.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/various-external-glossaries/index
+  md: https://weboftrust.github.io/keridoc/docs/category/various-external-glossaries/index.md
+---
+
+# Various external glossaries
+
+[
+
+## 📄️ External Digital Govt NZ Glossary
+
+](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-digital.govt.md)
+
+[
+
+## 📄️ External eSSIF-Lab Glossary
+
+](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-essiflab.md)
+
+[
+
+## 📄️ External Nist Glossary
+
+](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-nist.md)
+
+[
+
+## 📄️ External ToIP Glossary
+
+](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-toip.md)
+
+[
+
+## 📄️ External ToIP did:webs Glossary
+
+w
+
+](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-toipdidweb.md)
+
+[
+
+## 📄️ External W3C DID Glossary
+
+](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-w3cdid.md)
+
+
+
+
+---
+title: Resources
+description: Resources.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/resources/index
+  md: https://weboftrust.github.io/keridoc/docs/category/resources/index.md
+---
+
+# Resources
+
+[
+
+## 📄️ Delving into the WOT Knowledge Repository
+
+Welcome to our comprehensive knowledge base – a dynamic compendium of whitepapers, slide presentations, video content, HackMD files, and much more. This repository isn't just a store of information; it's a meticulously curated and enhanced platform designed to augment your understanding of WOT and serve as your springboard for deep exploration and learning.
+
+](https://weboftrust.github.io/keridoc/docs/resources/intro.md)
+
+[
+
+## 📄️ All images found
+
+Total unique images found: 152
+
+](https://weboftrust.github.io/keridoc/docs/resources/all-images.md)
+
+[
+
+## 📄️ keri.one-labeled
+
+Primary Resources
+
+](https://weboftrust.github.io/keridoc/docs/resources/keri.md)
+
+[
+
+## 🗃️ mdfiles
+
+11 items
+
+](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/IdentifierTheory-ssmith-uidt.md)
+
+
+
+
+---
+title: Overview
+description: Overview.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/overview/index
+  md: https://weboftrust.github.io/keridoc/docs/category/overview/index.md
+---
+
+# Overview
+
+[
+
+## 📄️ Indexed in KERISSE
+
+Indexed at 02 April 2024 1740
+
+](https://weboftrust.github.io/keridoc/docs/overview/indexed-in-KERISSE.md)
+
+[
+
+## 📄️ overview-and-context
+
+Overview and context
+
+](https://weboftrust.github.io/keridoc/docs/overview/overview-and-context.md)
+
+
+
+
+---
+title: Intro
+description: Intro.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/intro/index
+  md: https://weboftrust.github.io/keridoc/docs/category/intro/index.md
+---
+
+# Intro
+
+[
+
+## 📄️ KERIDoc
+
+We aim to document everything related to KERI, ACDC and CESR and alike. To let autonomic identifiers florish.
+
+](https://weboftrust.github.io/keridoc/docs/intro/intro.md)
+
+
+
+
+---
+title: How we did
+description: Overview of how this website is made.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/how-we-did/index
+  md: https://weboftrust.github.io/keridoc/docs/category/how-we-did/index.md
+---
+
+# How we did
+
+[
+
+## 📄️ Intro
+
+This is a source directory that explains how this site came to be and how it can be maintained.
+
+](https://weboftrust.github.io/keridoc/docs/how-we-did/intro.md)
+
+[
+
+## 🗃️ general
+
+2 items
+
+](https://weboftrust.github.io/keridoc/docs/how-we-did/general/install-project-kerisse.md)
+
+[
+
+## 🗃️ glossary
+
+4 items
+
+](https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/edit-metadata.md)
+
+[
+
+## 🗃️ keridoc
+
+9 items
+
+](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/cheat-sheet-writing-page.md)
+
+[
+
+## 🗃️ kerific
+
+2 items
+
+](https://weboftrust.github.io/keridoc/docs/how-we-did/kerific/kerific-browser-extension.md)
+
+[
+
+## 🗃️ kerisse
+
+4 items
+
+](https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/create-search-index.md)
+
+
+
+
+---
+title: Education
+description: Educational resources.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/education/index
+  md: https://weboftrust.github.io/keridoc/docs/category/education/index.md
+---
+
+# Education
+
+[
+
+## 📄️ WOT Education
+
+This is a source directory that contains Q&As and other educational resources
+
+](https://weboftrust.github.io/keridoc/docs/education/intro.md)
+
+[
+
+## 📄️ KERI MOOC
+
+Goal is to facilitate self-education culminating in KERI knowlegde. Level: starters, novices, beginners and alike.
+
+](https://weboftrust.github.io/keridoc/docs/education/keri-mooc.md)
+
+[
+
+## 📄️ Q&A about KERI's Security model and Guarantees
+
+This document is part two of Q-and-A. Both files shares a common Glossary, KERI specific and more generic decentralized Identity ones, that has:
+
+](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security.md)
+
+[
+
+## 📄️ Q&A about KERI
+
+This document is part one. Part two is Q-and-A Security. Both files shares a common Glossary that has:
+
+](https://weboftrust.github.io/keridoc/docs/education/q-and-a.md)
+
+[
+
+## 📄️ Tutorials
+
+Search through tutorials
+
+](https://weboftrust.github.io/keridoc/docs/education/tutorials.md)
+
+
+
+
+---
+title: Concepts
+description: Concepts.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/concepts/index
+  md: https://weboftrust.github.io/keridoc/docs/category/concepts/index.md
+---
+
+# Concepts
+
+[
+
+## 📄️ WOT Concepts
+
+All the historical and actual concepts behind KERI and its off-springs
+
+](https://weboftrust.github.io/keridoc/docs/concepts/intro.md)
+
+[
+
+## 📄️ Concepts
+
+hackmd-github-sync-badge
+
+](https://weboftrust.github.io/keridoc/docs/concepts/concepts.md)
+
+[
+
+## 🗃️ how-to
+
+9 items
+
+](https://weboftrust.github.io/keridoc/docs/concepts/how-to/contribute-to-weboftrust-github.md)
+
+[
+
+## 📄️ Insights into the KERI Development Toolbox
+
+Discover the whys and hows of the development tools that power the KERI system.
+
+](https://weboftrust.github.io/keridoc/docs/concepts/keri-dev-env.md)
+
+[
+
+## 📄️ Mindmap
+
+hackmd-github-sync-badge
+
+](https://weboftrust.github.io/keridoc/docs/concepts/mindmap.md)
+
+[
+
+## 📄️ Roadmap to know what's coming
+
+People want to know when new code will be ready, who will produce it, where it'll be and how they can rely on the code they currently use and / or create extensions or modification too. For this reason, we'ld like to know the work planning and how certain tasks are (inter)dependent of other tasks.
+
+](https://weboftrust.github.io/keridoc/docs/concepts/roadmap.md)
+
+
+
+
+---
+title: Annotated Copies
+description: Literal copies of content elsewhere on the web.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/category/annotated-copies/index
+  md: https://weboftrust.github.io/keridoc/docs/category/annotated-copies/index.md
+---
+
+# Annotated Copies
+
+[
+
+## 📄️ WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
+
+Temporarily removed content, because the site won't generate.
+
+](https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc.md)
+
+[
+
+## 📄️ WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
+
+4493255410370, level 1
+
+](https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof.md)
+
+[
+
+## 📄️ WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
+
+248943216478, level 1
+
+](https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex.md)
+
+[
+
+## 📄️ WebOfTrust-keria-main-docs-protocol
+
+signify-keria-request-authentication-protocol--skrap-, level 1
+
+](https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-keria-main-docs-protocol.md)
+
+
+
+
+---
+title: WebOfTrust-keria-main-docs-protocol
+description: signify-keria-request-authentication-protocol--skrap-, level 1
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-keria-main-docs-protocol/index
+  md: https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-keria-main-docs-protocol/index.md
+---
+
+# WebOfTrust-keria-main-docs-protocol
+
+##
+
+signify-keria-request-authentication-protocol--skrap-, level 1
+
+##
+
+keria-service-endpoint-interfaces, level 1
+
+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.
+
+##
+
+agent-worker-initialization, level 1
+
+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:
+
+##
+
+step-one---generate-client-aid, level 1
+
+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": []
+}
+```
+##
+
+step-two---agent-worker-creation, level 1
+
+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
+}
+```
+##
+
+step-three--signify-client-delegation-approval, level 1
+
+_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.
+
+##
+
+reconnecting-to-existing-agent-worker, level 1
+
+Document the steps for retrieving state from the Admin interface and updating.
+
+##
+
+key-generate-methods, level 1
+
+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.
+
+##
+
+salty-keys, level 1
+
+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
+```
+##
+
+salty-key-salt-rotations, level 1
+
+Document the procedure for rotating a new Salt in for a Salty Key AID.
+
+##
+
+randy-keys, level 1
+
+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.
+
+##
+
+sandy-keys, level 1
+
+##
+
+group-keys, level 1
+
+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.
+
+##
+
+hsm-keys--experimental-, level 1
+
+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
+        """
+```
+##
+
+passcode-rotation, level 1
+
+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/`
+
+
+##
+
+partial-client-aid-rotaion-in-support-of-passcode-rotation, level 1
+
+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
+
+
+##
+
+passcode-rotation-recovery, level 1
+
+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-request-response-authentication, level 1
+
+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.
+
+##
+
+metadata-headers, level 1
+
+Document `Signify-Resource` and `Signify-Timestamp` headers here.
+
+##
+
+signature-input-header, level 1
+
+Document the `Signagture-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)
+
+##
+
+signature-header, level 1
+
+Docuemnt the signing method and `Signature` header.
+
+
+
+
+---
+title: WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
+description: 248943216478, level 1
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex/index
+  md: https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex/index.md
+---
+
+# WebOfTrust-ietf-ipex-main-draft-ssmith-ipex
+
+##
+
+248943216478, level 1
+
+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](https://weboftrust.github.io/keridoc/docs/annotated-copies/WG@example.md) arch: [https://example.com/WG](https://example.com/WG) github: USER/REPO latest: [https://example.com/LATEST](https://example.com/LATEST)
+
+name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](https://weboftrust.github.io/keridoc/docs/annotated-copies/Philip.Feairheller@gleif.md)
+
+normative:
+
+name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](https://weboftrust.github.io/keridoc/docs/annotated-copies/Philip.Feairheller@gleif.md) 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
+
+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
+
+##
+
+introduction, level 2
+
+TODO Introduction
+
+##
+
+terminology, level 1
+
+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_.
+
+##
+
+chain-link-confidentiality, level 1
+
+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.
+
+##
+
+exchange-protocol, level 1
+
+| 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 |
+
+##
+
+discussion, level 1
+
+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.
+
+##
+
+ipex-validation, level 1
+
+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.
+
+##
+
+issuer-signing-rules, level 1
+
+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.
+
+##
+
+example-most-compact-variant, level 1
+
+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.
+
+##
+
+conventions-and-definitions, level 1
+
+|::boilerplate bcp14-tagged|
+
+##
+
+security-considerations, level 1
+
+TODO Security
+
+##
+
+iana-considerations, level 1
+
+This document has no IANA actions.
+
+\--- back
+
+##
+
+acknowledgments, level 1
+
+|:numbered\="false"|
+
+TODO acknowledge.
+
+
+
+
+---
+title: WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
+description: 4493255410370, level 1
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof/index
+  md: https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof/index.md
+---
+
+# WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof
+
+##
+
+4493255410370, level 1
+
+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\]
+
+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
+
+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
+
+name: Mark Nottingham date: 2003
+
+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
+
+##
+
+introduction, level 2
+
+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.
+
+##
+
+streamable-sads, level 1
+
+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).
+
+##
+
+nested-partial-signatures, level 1
+
+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.
+
+##
+
+transposable-signature-attachments, level 1
+
+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-sad-path-language, level 1
+
+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.
+
+##
+
+description-and-usage, level 2
+
+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.
+
+##
+
+cesr-encoding-for-sad-path-language, level 3
+
+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).
+
+##
+
+sad-path-examples, level 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 |
+
+##
+
+alternative-pathing---query-languages, level 1
+
+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.
+
+##
+
+cesr-attachments, level 1
+
+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).
+
+##
+
+counter-four-character-codes, level 1
+
+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\].
+
+##
+
+variable-size-codes, level 1
+
+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-signature-attachments, level 1
+
+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.
+
+##
+
+signing-sad-content, level 1
+
+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.
+
+##
+
+signatures-with-non-transferable-identifiers, level 1
+
+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.
+
+##
+
+signatures-with-transferable-identifiers, level 1
+
+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).
+
+##
+
+additional-count-codes, level 1
+
+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.
+
+##
+
+sad-path-signature-group, level 1
+
+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 |
+
+##
+
+sad-path-groups, level 1
+
+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"
+    }
+  }
+}
+```
+##
+
+transposable-signature-attachments, level 1
+
+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
+
+##
+
+small-variable-raw-size-sad-path-code, level 1
+
+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.
+
+##
+
+nested-partial-signatures, level 1
+
+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.
+
+##
+
+signing-nested-sads, level 1
+
+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"
+      }
+    }
+  }
+}
+```
+##
+
+signing-saids, level 1
+
+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.
+
+##
+
+conventions-and-definitions, level 1
+
+|::boilerplate bcp14-tagged|
+
+##
+
+security-considerations, level 1
+
+TODO Security
+
+##
+
+iana-considerations, level 1
+
+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
+
+##
+
+acknowledgments, level 1
+
+|:numbered\="false"|
+
+Dr Sam Smith, Kevin Griffin and the Global Legal Entity Identifier Foundation (GLEIF)
+
+
+
+
+---
+title: WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
+description: Temporarily removed content, because the site won't generate.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc/index
+  md: https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc/index.md
+---
+
+# WebOfTrust-ietf-acdc-main-draft-ssmith-acdc
+
+Temporarily removed content, because the site won't generate.
+
+
+
+
+---
+title: kli-demo-2022
+description: -->
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/kli-demo-2022/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/kli-demo-2022/index.md
+---
+
+# kli-demo-2022
+
+Interviewer: Steven Milstein
+Interviewee: Phil Feairheller
+
+Subtitles, Links table, Brief explanations: Henk van Cann
+
+This [footage](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG) is the topic of this file.
+
+**Term**s are words used by Phil Feairheller, I provided a **link** to more explanation, mainly to the [ACDC glossary](https://github.com/trustoverip/acdc/wiki/). The point in the video where Phil _mentions the term for the first time_ is called **vidstart**, the **level** of understanding at which this term might need explanation, and finally a _brief explanation_ in field **text** of the term in the first column.
+
+To get to the links and other columns of the table you might need to scroll the table all the way to the right.
+
+Since KERI and ACDC education start off at the level of SSI-expert, a _beginner_ is not a layman, but somebody with a good common understanding of IT and digital identity.
+
+-   1=beginner digital identity expert
+-   3=advanced self-sovereign identity expert
+-   7=SSI experts
+```
+Just my 2 cents:
+Don't try KERI and ACDC on your family, friends and other innocent bystanders.
+```
+| Term | text | link | vidstart | level |
+| --- | --- | --- | --- | --- |
+
+| IIW | Internet Identity Workshop twice in a year un-conference since 2005 | [https://internetidentityworkshop.com](https://internetidentityworkshop.com) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m03s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m03s) | 7 |
+| KERI | Key Event Receipt Infrastructure | [https://github.com/WebOfTrust/keri](https://github.com/WebOfTrust/keri) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m12s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m12s) | 7 |
+| repo | Software repository | [https://github.com/trustoverip/acdc/wiki/repo](https://github.com/trustoverip/acdc/wiki/repo) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m27s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m27s) | 3 |
+| KERIpy | Python implementation of KERI | [https://github.com/WebOfTrust/keripy](https://github.com/WebOfTrust/keripy) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m27s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m27s) | 7 |
+| repo | Software repository | [https://github.com/trustoverip/acdc/wiki/repo](https://github.com/trustoverip/acdc/wiki/repo) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m33s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m33s) | 1 |
+| coroutines | Computer programs that can be suspended and resumed at will. | [https://github.com/trustoverip/acdc/wiki/coroutines](https://github.com/trustoverip/acdc/wiki/coroutines) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s) | 1 |
+| I/O | Input / output | [https://github.com/trustoverip/acdc/wiki/input-output-(I-O)](https://github.com/trustoverip/acdc/wiki/input-output-\(I-O\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s) | 1 |
+| HIO | Hierarchical asynchronous coroutines and I/O in Python | [https://github.com/trustoverip/acdc/wiki/hio](https://github.com/trustoverip/acdc/wiki/hio) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s) | 7 |
+| Sam Smith | Samuel M. Smith PhD, Inventor and lead developer of KERI | [https://www.linkedin.com/in/samuel-m-smith/](https://www.linkedin.com/in/samuel-m-smith/) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m41s) | 7 |
+| python | Programming Language | [https://www.python.org](https://www.python.org) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m49s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m49s) | 3 |
+| clone | A copy of a system that is - and works exactly as the original | [https://github.com/trustoverip/acdc/wiki/clone](https://github.com/trustoverip/acdc/wiki/clone) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m55s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=00m55s) | 3 |
+| branch | A duplicate of an object under version control for further separate modification | [https://github.com/trustoverip/acdc/wiki/branch](https://github.com/trustoverip/acdc/wiki/branch) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m00s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m00s) | 3 |
+| kli | KERI command line interface | [https://github.com/trustoverip/acdc/wiki/kli](https://github.com/trustoverip/acdc/wiki/kli) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m12s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m12s) | 7 |
+| Kubernetes | Kubernetes is an open source platform for managing software containers | [https://kubernetes.io](https://kubernetes.io) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m18s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m18s) | 3 |
+| kubectl | Kubernetes command line interface | [https://kubernetes.io/docs/reference/kubectl/](https://kubernetes.io/docs/reference/kubectl/) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m18s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m18s) | 7 |
+| verifiable credentials | The digital variant of our daily live's credentials (ike passport, driver's license), but in a machine-verifiable way | [https://github.com/trustoverip/acdc/wiki/verifiable-credential-(VC)](https://github.com/trustoverip/acdc/wiki/verifiable-credential-\(VC\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m26s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m26s) | 1 |
+| Docker containers | Docker takes away repetitive, mundane configuration tasks and is used for application development | [https://www.docker.com](https://www.docker.com) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m38s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m38s) | 3 |
+| sub shell | a child shell started up from - and contained in another parent shell | [https://github.com/trustoverip/acdc/wiki/sub-shell](https://github.com/trustoverip/acdc/wiki/sub-shell) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m46s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=01m46s) | 1 |
+| agent | A representative for an identity | [https://github.com/trustoverip/acdc/wiki/agent](https://github.com/trustoverip/acdc/wiki/agent) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m01s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m01s) | 3 |
+| cloud agent | Cloud agent is software that is installed on the cloud server instances for security, monitoring, and analysis | [https://github.com/trustoverip/acdc/wiki/cloud-agent](https://github.com/trustoverip/acdc/wiki/cloud-agent) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m01s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m01s) | 3 |
+| Py installer | Python installer bundles a Python application and all its dependencies into a single package | [https://pypi.org/project/pyinstaller/](https://pypi.org/project/pyinstaller/) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m09s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m09s) | 3 |
+| Electron | A Python interface for Apache Electron command line interface | [https://pypi.org/project/python-electron/](https://pypi.org/project/python-electron/) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m16s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m16s) | 3 |
+| U/I | A user interface (UI) is the space where interactions between humans and machines occur. | [https://github.com/trustoverip/acdc/wiki/user-interface-(U-I)](https://github.com/trustoverip/acdc/wiki/user-interface-\(U-I\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m16s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m16s) | 1 |
+| multi-sig | A digital signature scheme which allows a group of users to sign a single piece of digital data. | [https://github.com/trustoverip/acdc/wiki/multisig](https://github.com/trustoverip/acdc/wiki/multisig) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m29s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m29s) | 1 |
+| identifier | Something to uniquely identify (public) identities; pointing to something or someone else. | [https://github.com/trustoverip/acdc/wiki/identifier-system](https://github.com/trustoverip/acdc/wiki/identifier-system) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m29s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m29s) | 3 |
+| wallet | A wallet is a collection of data stores; made up of a keystore, local and remote key event log database and credential database. | [https://github.com/trustoverip/acdc/wiki/wallet](https://github.com/trustoverip/acdc/wiki/wallet) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m34s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m34s) | 7 |
+| wallet commands | The section of kli where verifiable credentials can be listed | [https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68\_0\_12](https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68_0_12) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m34s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m34s) | 7 |
+| witnesses | Entity that may receive, verify, and store key events for an identifier | [https://github.com/trustoverip/acdc/wiki/witness](https://github.com/trustoverip/acdc/wiki/witness) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m44s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m44s) | 7 |
+| watchers | Guarantee that KERI logs are immutable | [https://github.com/trustoverip/acdc/wiki/watcher](https://github.com/trustoverip/acdc/wiki/watcher) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m44s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=02m44s) | 7 |
+| key management | Management of cryptographic keys in a crypto-system. | [https://github.com/trustoverip/acdc/wiki/key-management](https://github.com/trustoverip/acdc/wiki/key-management) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m16s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m16s) | 7 |
+| init | Initialization, a command in the kli | [https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68\_0\_12](https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68_0_12) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m21s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m21s) | 3 |
+| single sig identifier | An identifier that is controlled by a one-of-one signing keypair | [https://github.com/trustoverip/acdc/wiki/single-signature-identifier](https://github.com/trustoverip/acdc/wiki/single-signature-identifier) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m27s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m27s) | 3 |
+| key store | A keystore in KERI is the encrypted data store that hold the private keys for a collection of AIDs. | [https://github.com/trustoverip/acdc/wiki/keystore](https://github.com/trustoverip/acdc/wiki/keystore) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m33s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m33s) | 7 |
+| key events | Events happening to controlling keys of an identifier recorded in a Key Event Log (KEL). | [https://github.com/trustoverip/acdc/wiki/key-event](https://github.com/trustoverip/acdc/wiki/key-event) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s) | 3 |
+| interaction event | Anchors external data to the key-state as established by the most recent prior establishment event | [https://github.com/trustoverip/acdc/wiki/interaction-event](https://github.com/trustoverip/acdc/wiki/interaction-event) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s) | 7 |
+| rotation event | Changes the key-state which includes a change to the set of authoritative keypairs for an AID | [https://github.com/trustoverip/acdc/wiki/rotation-event](https://github.com/trustoverip/acdc/wiki/rotation-event) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m39s) | 7 |
+| signing thresholds | Minimum number of valid signatures to satisfy the requirement for successful validation | [https://github.com/trustoverip/acdc/wiki/signing-threshold](https://github.com/trustoverip/acdc/wiki/signing-threshold) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m48s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=04m48s) | 7 |
+| KEL | Key Event Log is the native KERI verifiable data structure | [https://github.com/trustoverip/acdc/wiki/key-event-log-(KEL)](https://github.com/trustoverip/acdc/wiki/key-event-log-\(KEL\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=05m01s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=05m01s) | 7 |
+| verify signatures | Applying an algorithm that either accepts or rejects the message's claim to authenticity | [https://github.com/trustoverip/acdc/wiki/verify-signature](https://github.com/trustoverip/acdc/wiki/verify-signature) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=05m32s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=05m32s) | 3 |
+| peer-to-peer communications | Peers are equally privileged, equipotent participants in a network | [https://github.com/trustoverip/acdc/wiki/peer-to-peer-(P2P)](https://github.com/trustoverip/acdc/wiki/peer-to-peer-\(P2P\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=06m13s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=06m13s) | 3 |
+| bootstrap command | Start an empty agent or to run a single agent against one that's already been started | [https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68\_0\_20](https://docs.google.com/presentation/d/1RIMX7J-cdg8OctoG4JqxPOfqKZsVNodqajtpQ0oFIyE/edit#slide=id.gf2168aef68_0_20) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=06m31s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=06m31s) | 3 |
+| salts | Random data that is used as an additional input to a cryptographic one-way function | [https://github.com/trustoverip/acdc/wiki/salt](https://github.com/trustoverip/acdc/wiki/salt) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=06m50s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=06m50s) | 7 |
+| delegation | Delegation can be defined as “the act of empowering to act for another” | [https://github.com/trustoverip/acdc/wiki/delegation](https://github.com/trustoverip/acdc/wiki/delegation) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=07m44s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=07m44s) | 7 |
+| multi-sig delegation | delegated identifiers under multi-signature control | [https://github.com/trustoverip/acdc/wiki/delegation](https://github.com/trustoverip/acdc/wiki/delegation) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=07m44s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=07m44s) | 7 |
+| JSON | JavaScript Object Notation | [https://en.wikipedia.org/wiki/JSON](https://en.wikipedia.org/wiki/JSON) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=08m08s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=08m08s) | 3 |
+| transferable | Control over identifier can be transferred by rotating keys | [https://github.com/trustoverip/acdc/wiki/transferable-identifier](https://github.com/trustoverip/acdc/wiki/transferable-identifier) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=08m34s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=08m34s) | 7 |
+| ports | A number assigned to uniquely identify a connection endpoint and to direct data to a specific service. | [https://en.wikipedia.org/wiki/Port\_(computer\_networking)](https://en.wikipedia.org/wiki/Port_\(computer_networking\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=09m04s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=09m04s) | 3 |
+| configuration file | File used to configure the parameters and initial settings for some computer programs | [https://github.com/trustoverip/acdc/wiki/configuration-files](https://github.com/trustoverip/acdc/wiki/configuration-files) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=09m16s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=09m16s) | 1 |
+| REST | REpresentational State Transfer (REST) is a software architectural style that developers apply to web APIs | [https://github.com/WebOfTrust/keri/blob/main/docs/keri-dev-env.md#what-exactly-is-a-rest-api](https://github.com/WebOfTrust/keri/blob/main/docs/keri-dev-env.md#what-exactly-is-a-rest-api) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m00s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m00s) | 3 |
+| APIs | Application Programming Interface | [https://github.com/WebOfTrust/keri/blob/main/docs/keri-dev-env.md#what-exactly-is-a-rest-api](https://github.com/WebOfTrust/keri/blob/main/docs/keri-dev-env.md#what-exactly-is-a-rest-api) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m00s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m00s) | 3 |
+| CURL | Command-line tool (curl) for transferring data using various network protocols. | [https://en.wikipedia.org/wiki/CURL](https://en.wikipedia.org/wiki/CURL) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m17s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m17s) | 3 |
+| post and put | HTTP request methods to indicate the desired action to be performed on the identified resource | [https://en.wikipedia.org/wiki/Hypertext\_Transfer\_Protocol](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m17s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m17s) | 3 |
+| Swagger | OpenAPI (former Swagger) is important to KERI, CESR and ACDC. It's open sourced and has many ready-usable extensions in JSON available. | [https://github.com/WebOfTrust/keri/blob/main/docs/keri-dev-env.md#what-is-swagger-and-openapi](https://github.com/WebOfTrust/keri/blob/main/docs/keri-dev-env.md#what-is-swagger-and-openapi) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m31s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=10m31s) | 7 |
+| passcode | Secret data, typically a string of characters, usually used to confirm a user's identity | [https://github.com/trustoverip/acdc/wiki/passcode](https://github.com/trustoverip/acdc/wiki/passcode) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=11m06s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=11m06s) | 3 |
+| stretched into an encryption key | make a possibly weak key, typically a password or passphrase, more secure against a brute-force attack by increasing the resources | [https://github.com/trustoverip/acdc/wiki/key-stretching](https://github.com/trustoverip/acdc/wiki/key-stretching) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=11m11s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=11m11s) | 7 |
+| flag | Many command line programs can be set to various mode by using a flag; e.g. -v or --verbose for verbose mode | [https://en.wikipedia.org/wiki/Verbose\_mode](https://en.wikipedia.org/wiki/Verbose_mode) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=12m20s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=12m20s) | 3 |
+| non-transferable identifier | Controlling keys over this identifier cannot be rotated and therefore this identifier is non-transferable to other control | [https://github.com/trustoverip/acdc/wiki/non-transferable-identitifer](https://github.com/trustoverip/acdc/wiki/non-transferable-identitifer) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=14m28s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=14m28s) | 7 |
+| toad | Field in KERI data structure for describing the witness thresshold | [https://github.com/WebOfTrust/keripy/blob/28873f42aabef096d2b6f4bf1af5dbd9e219d13f/src/keri/core/eventing.py](https://github.com/WebOfTrust/keripy/blob/28873f42aabef096d2b6f4bf1af5dbd9e219d13f/src/keri/core/eventing.py) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=15m37s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=15m37s) | 7 |
+| witness threshold | The minimum number of valid witness signatures required | [https://github.com/trustoverip/acdc/wiki/threshold-signature-scheme](https://github.com/trustoverip/acdc/wiki/threshold-signature-scheme) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=15m37s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=15m37s) | 7 |
+| pre-rotation | commitment to next rotated key set in previous rotation or inception event | [https://github.com/trustoverip/acdc/wiki/pre-rotation](https://github.com/trustoverip/acdc/wiki/pre-rotation) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=15m54s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=15m54s) | 7 |
+| prefixes | 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 | [https://github.com/trustoverip/acdc/wiki/prefix](https://github.com/trustoverip/acdc/wiki/prefix) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m47s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m47s) | 7 |
+| Base64 | A group of binary-to-text encoding schemes that represent binary data | [https://github.com/trustoverip/acdc/wiki/base64](https://github.com/trustoverip/acdc/wiki/base64) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s) | 7 |
+| qualified | when qualified, a cryptographic primitive includes a prepended derivation code | [https://github.com/trustoverip/acdc/wiki/qualified](https://github.com/trustoverip/acdc/wiki/qualified) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s) | 7 |
+| derivation code | A special character that encodes the derivation process, pre-pended to the identifier | [https://github.com/trustoverip/acdc/wiki/derivation-code](https://github.com/trustoverip/acdc/wiki/derivation-code) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m53s) | 7 |
+| Blake3 hash | BLAKE3 is a relatively young (2020) cryptographic hash function based on Bao and BLAKE2. | [https://github.com/trustoverip/acdc/wiki/blake3](https://github.com/trustoverip/acdc/wiki/blake3) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m57s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=16m57s) | 7 |
+| anchor data into | Data anchors are digests of digital data, that uniquely identify this data | [https://github.com/trustoverip/acdc/wiki/data-anchor](https://github.com/trustoverip/acdc/wiki/data-anchor) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m14s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m14s) | 7 |
+| AID | An identifier that is self-certifying and self-sovereign | [https://github.com/trustoverip/acdc/wiki/autonomic-identifier-(AID)](https://github.com/trustoverip/acdc/wiki/autonomic-identifier-\(AID\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m50s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m50s) | 7 |
+| sequence number | Incremental number in a log | [https://www.storyofmathematics.com/number-sequences/](https://www.storyofmathematics.com/number-sequences/) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m57s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m57s) | 3 |
+| digest | Verifiable cryptographic commitment. It's a collision resistant hash of content | [https://github.com/trustoverip/acdc/wiki/digest](https://github.com/trustoverip/acdc/wiki/digest) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m57s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=17m57s) | 3 |
+| issuance event | The inception event of a verifiable credential | [https://github.com/trustoverip/acdc/wiki/issuance-event](https://github.com/trustoverip/acdc/wiki/issuance-event) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=18m02s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=18m02s) | 7 |
+| public transaction event log | Is a hash linked data structure of transactions that can be used to track state | [https://github.com/trustoverip/acdc/wiki/public-transaction-event-log-(PTEL)](https://github.com/trustoverip/acdc/wiki/public-transaction-event-log-\(PTEL\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=18m05s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=18m05s) | 7 |
+| verifiable | When you can succesfully verify a signature | [https://github.com/trustoverip/acdc/wiki/verify-signature](https://github.com/trustoverip/acdc/wiki/verify-signature) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=19m34s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=19m34s) | 7 |
+| establishment | An event that establishes control authority | [https://github.com/trustoverip/acdc/wiki/establishment-event](https://github.com/trustoverip/acdc/wiki/establishment-event) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=19m39s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=19m39s) | 7 |
+| lmdb databases | Lightning Memory-Mapped Database | [https://en.wikipedia.org/wiki/Lightning\_Memory-Mapped\_Database](https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=21m42s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=21m42s) | 7 |
+| indexed signatures | Used when signing anything with a multi-key autonomic identifier; a verifier knows which of the multiple public keys was used | [https://github.com/trustoverip/acdc/wiki/indexed-signature](https://github.com/trustoverip/acdc/wiki/indexed-signature) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=23m46s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=23m46s) | 7 |
+| hex | Hexadecimal notation | [https://en.wikipedia.org/wiki/Hexadecimal](https://en.wikipedia.org/wiki/Hexadecimal) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=23m59s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=23m59s) | 3 |
+| verbose | An option available in many computer operating systems and programming languages that provides additional details as to what the computer is doing | [https://en.wikipedia.org/wiki/Verbose\_mode](https://en.wikipedia.org/wiki/Verbose_mode) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=25m01s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=25m01s) | 3 |
+| self-addressing identifiers | An identifier that is deterministically generated from and embedded in the content it identifies, making it and its data mutually tamper-evident | [https://github.com/trustoverip/acdc/wiki/self-addressing-identifier-(SAID)](https://github.com/trustoverip/acdc/wiki/self-addressing-identifier-\(SAID\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=25m29s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=25m29s) | 7 |
+| backer | Backers include both regular KERI witnesses and ledger-registered backers | [https://github.com/trustoverip/acdc/wiki/backer](https://github.com/trustoverip/acdc/wiki/backer) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=27m48s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=27m48s) | 7 |
+| ledger backer | A witness in KERI that is ledger-registered | [https://github.com/trustoverip/acdc/wiki/ledger-backer](https://github.com/trustoverip/acdc/wiki/ledger-backer) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=27m55s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=27m55s) | 7 |
+| witness backer | A native KERI witness whose control authority is established in a KEL | [https://github.com/trustoverip/acdc/wiki/witness](https://github.com/trustoverip/acdc/wiki/witness) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=27m55s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=27m55s) | 7 |
+| vLEI | Digital verifiable credentials issued by (delegates) of GLEIF to prove that information about a legel entity is verifiably authentic | [https://github.com/trustoverip/acdc/wiki/verifiable-legal-entity-identifier-(vLEI)](https://github.com/trustoverip/acdc/wiki/verifiable-legal-entity-identifier-\(vLEI\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m17s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m17s) | 7 |
+| SSI system | SSI Infrastructure consisting of the technological components that are deployed all over the world | [https://github.com/trustoverip/acdc/wiki/ssi-system](https://github.com/trustoverip/acdc/wiki/ssi-system) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m22s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m22s) | 1 |
+| Indy network | Hyperledger Indy network is an SSI system based on a private blockchain | [https://www.hyperledger.org/use/hyperledger-indy](https://www.hyperledger.org/use/hyperledger-indy) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m22s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m22s) | 7 |
+| transfer off a ledger | The act of transferring control authority over an identifier from a ledger (or blockchain) to the native verifiable KERI data structure KEL | [https://github.com/trustoverip/acdc/wiki/transfer-off-ledger](https://github.com/trustoverip/acdc/wiki/transfer-off-ledger) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m39s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=30m39s) | 7 |
+| Ethereum | Ethereum is the community-run technology powering the cryptocurrency ether (ETH) and thousands of decentralized applications | [https://ethereum.org/en/](https://ethereum.org/en/) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=31m02s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=31m02s) | 7 |
+| Aries | Hyperledger Aries provides an interoperable tool kit for creating, transmitting and storing verifiable digital credentials | [https://www.hyperledger.org/use/aries](https://www.hyperledger.org/use/aries) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=31m46s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=31m46s) | 7 |
+| service endpoints | A web service endpoint which is a URL at which clients of specific service can get access to the service. | [https://github.com/trustoverip/acdc/wiki/service-endpoint](https://github.com/trustoverip/acdc/wiki/service-endpoint) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=32m54s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=32m54s) | 3 |
+| URLs | A reference to a web resource that specifies its location on a computer network and a mechanism for retrieving it | [https://github.com/trustoverip/acdc/wiki/uniform-resource-locator-(URL)](https://github.com/trustoverip/acdc/wiki/uniform-resource-locator-\(URL\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=33m00s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=33m00s) | 1 |
+| IP-address | A numerical label such as '192.0.2.1' that is connected to a computer network that uses the Internet Protocol for communication | [https://github.com/trustoverip/acdc/wiki/ip-address](https://github.com/trustoverip/acdc/wiki/ip-address) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=33m42s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=33m42s) | 1 |
+| TCP endpoint | This is a service endpoint of the web transmission control protocol | [https://github.com/trustoverip/acdc/wiki/tcp-endpoint](https://github.com/trustoverip/acdc/wiki/tcp-endpoint) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=34m00s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=34m00s) | 3 |
+| inquisitor |  | [https://github.com/trustoverip/acdc/wiki/inquisitor](https://github.com/trustoverip/acdc/wiki/inquisitor) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=37m19s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=37m19s) | 7 |
+| dip: tag |  |  | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=49m13s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=49m13s) | 7 |
+| icp: tag |  |  | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=49m13s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=49m13s) | 7 |
+| di: tag |  |  | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=49m20s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=49m20s) | 7 |
+| locked state | default state of an encrypted KERI data store with a passcode | [https://github.com/trustoverip/acdc/wiki/locked-state](https://github.com/trustoverip/acdc/wiki/locked-state) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=52m22s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=52m22s) | 7 |
+| onepass | password manager | [https://github.com/doglex/onepass](https://github.com/doglex/onepass) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=53m04s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=53m04s) | 7 |
+| data OOBIs | data out-of-band ntroductions | [https://github.com/trustoverip/acdc/wiki/out-of-band-introduction-(OOBI)](https://github.com/trustoverip/acdc/wiki/out-of-band-introduction-\(OOBI\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=53m48s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=53m48s) | 7 |
+| credential schema OOBIs | credential schema out-of-band ntroductions | [https://github.com/trustoverip/acdc/wiki/out-of-band-introduction-(OOBI)](https://github.com/trustoverip/acdc/wiki/out-of-band-introduction-\(OOBI\)) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=53m54s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=53m54s) | 7 |
+| Keep | Is KERI's and ACDC's crypto wallet: A task orientated application for managing AIDs in ecosystems, e.g. the vLEI Ecosystem | [https://github.com/trustoverip/acdc/wiki/keep](https://github.com/trustoverip/acdc/wiki/keep) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=54m12s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=54m12s) | 7 |
+| zero trust | a Zero Trust approach trusts no one | [https://github.com/trustoverip/acdc/wiki/zero-trust](https://github.com/trustoverip/acdc/wiki/zero-trust) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=55m37s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=55m37s) | 3 |
+| credential registries | Is a functional component that has the capability to register and advertise the information about Credential Types that their respective Governing Parties have decided to disclose | [https://essif-lab.github.io/framework/docs/terms/credential-catalogue](https://essif-lab.github.io/framework/docs/terms/credential-catalogue) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=55m53s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=55m53s) | 3 |
+| revocation events | An event that revokes control authority over an identifier | [https://github.com/trustoverip/acdc/wiki/revocation-event](https://github.com/trustoverip/acdc/wiki/revocation-event) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=55m58s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=55m58s) | 3 |
+| two-factor auth | Is an 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 | [https://en.wikipedia.org/wiki/Multi-factor\_authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=56m13s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=56m13s) | 1 |
+| escrow states |  | [https://github.com/trustoverip/acdc/wiki/escrow-state](https://github.com/trustoverip/acdc/wiki/escrow-state) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=56m59s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=56m59s) | 7 |
+| server-sent events | Mailbox notifications; a streaming service for the agent U/I, to get notifications from the KERI system itself | [https://github.com/trustoverip/acdc/wiki/server-sent-event](https://github.com/trustoverip/acdc/wiki/server-sent-event) | [https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH\_LHVhs0rZ9Bb8ocyKlPljkaG&t=57m19s](https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=57m19s) | 7 |
+|  |  |  |  |  |
+
+
+
+
+---
+title: draft-ssmith-said
+description: title: "Self-Addressing IDentifier (SAID)"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-said/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-said/index.md
+---
+
+# draft-ssmith-said
+
+title: "Self-Addressing IDentifier (SAID)" abbrev: "SAID" docname: draft-ssmith-said-latest category: info
+
+ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
+
+stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
+
+name: S. Smith organization: ProSapien LLC email: [sam@prosapien.com](mailto:sam@prosapien.com)
+
+normative: 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
+
+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
+
+tags: IETF, SAID, CESR, SAD, ACDC, KERI
+
+\--- abstract
+
+A `SAID` (Self-Addressing IDentifier) is a special type of content-addressable identifier based on encoded cryptographic digest that is self-referential. The `SAID` derivation protocol defined herein enables verification that a given `SAID` is uniquely cryptographically bound to a serialization that includes the `SAID` as a field in that serialization. Embedding a `SAID` as a field in the associated serialization indicates a preferred content-addressable identifier for that serialization that facilitates greater interoperability, reduced ambiguity, and enhanced security when reasoning about the serialization. Moreover, given sufficient cryptographic strength, a cryptographic commitment such as a signature, digest, or another `SAID`, to a given `SAID` is essentially equivalent to a commitment to its associated serialization. Any change to the serialization invalidates its `SAID` thereby ensuring secure immutability evident reasoning with `SAIDs` about serializations or equivalently their `SAIDs`. Thus `SAIDs` better facilitate immutably referenced data serializations for applications such as Verifiable Credentials or Ricardian Contracts.
+
+`SAIDs` are encoded with `CESR` (Composable Event Streaming Representation) \[CESR\] which includes a pre-pended derivation code that encodes the cryptographic suite or algorithm used to generate the digest. A `CESR` primitive's primary expression (alone or in combination ) is textual using Base64 URL-safe characters. `CESR` primitives may be round-tripped (alone or in combination) to a compact binary representation without loss. The `CESR` derivation code enables cryptographic digest algorithm agility in systems that use `SAIDs` as content addresses. Each serialization may use a different cryptographic digest algorithm as indicated by its derivation code. This provides interoperable future proofing. `CESR` was developed for the \[KERI\] protocol.
+
+\--- middle
+
+# Introduction
+
+The primary advantage of a content-addressable identifier is that it is cryptographically bound to the content (expressed as a serialization), thus providing a secure root-of-trust for reasoning about that content. Any sufficiently strong cryptographic commitment to a content-addressable identifier is functionally equivalent to a cryptographic commitment to the content itself.
+
+A `self-addressing identifier (SAID)` is a special class of content-addressable identifier that is also self-referential. This requires a special derivation protocol that generates the `SAID` and embeds it in the serialized content. The reason for a special derivation protocol is that a naive cryptographic content-addressable identifier must not be self-referential, i.e. the identifier must not appear within the content that it is identifying. This is because the naive cryptographic derivation process of a content-addressable identifier is a cryptographic digest of the serialized content. Changing one bit of the serialization content will result in a different digest. Therefore, self-referential content-addressable identifiers require a special derivation protocol.
+
+To elaborate, this approach of deriving self-referential identifiers from the contents they identify, is called `self-addressing`. It allows any validator to verify or re-derive the `self-referential, self-addressing identifier` given the contents it identifies. To clarify, a `SAID` is different from a standard content address or content-addressable identifier in that a standard content-addressable identifier may not be included inside the contents it addresses. Moreover, a standard content-addressable identifier is computed on the finished immutable contents, and therefore is not self-referential. In addition, a `self-addressing identifier (SAID)` includes a pre-pended derivation code that specifies the cryptographic algorithm used to generate the digest.
+
+An authenticatable data serialization is defined to be a serialization that is digitally signed with a non-repudiable asymmetric key-pair based signing scheme. A verifier, given the public key, may verify the signature on the serialization and thereby securely attribute the serialization to the signer. Many use cases of authenticatable data serializations or statements include a self-referential identifier embedded in the authenticatable serialization. These serializations may also embed references to other self-referential identifiers to other serializations. The purpose of a self-referential identifier is to enable reasoning in software or otherwise about that serialization. Typically, these self-referential identifiers are not cryptographically bound to their encompassing serializations such as would be the case for a content-addressable identifier of that serialization. This poses a security problem because there now may be more than one identifier for the same content. The first is self-referential, included in the serialization, but not cryptographically bound to its encompassing serialization and the second is cryptographically bound but not self-referential, not included in the serialization.
+
+When reasoning about a given content serialization, the existence of a non-cryptographically bound but self-referential identifier is a security vulnerability. Certainly, this identifier cannot be used by itself to securely reason about the content because it is not bound to the content. Anyone can place such an identifier inside some other serialization and claim that the other serialization is the correct serialization for that self-referential identifier. Unfortunately, a standard content-addressable identifier for a serialization which is bound to the serialization can not be included in the serialization itself, i.e. can be neither self-referential nor self-contained; it must be tracked independently. In contrast, a `self-addressing identifier` is included in the serialization to which it is cryptographically bound making it self-referential and self-contained. Reasoning about `self-addressing identifiers (SAIDs)` is secure because a `SAID` will verify if and only if its encompassing serialization has not been mutated, which makes the content immutable. `SAIDs` used as references to serializations in other serializations enable tamper-evident reasoning about the referenced serializations. This enables a more compact representation of an authenticatable data serialization that includes other serializations by reference to their `SAIDs` instead of by embedded containment.
+
+# Generation and Verification Protocols
+
+The _self-addressing identifier_ (`SAID`) verification protocol is as follows:
+
+-   Make a copy of the embedded `CESR` \[CESR\] encoded `SAID` string included in the serialization.
+-   replace the `SAID` field value in the serialization with a dummy string of the same length. The dummy character is `#`, that is, ASCII 35 decimal (23 hex).
+-   Compute the digest of the serialization that includes the dummy value for the `SAID` field. Use the digest algorithm specified by the `CESR` \[CESR\] derivation code of the copied `SAID`.
+-   Encode the computed digest with CESR \[CESR\] to create the final derived and encoded SAID of the same total length as the dummy string and the copied embedded `SAID`.
+-   Compare the copied `SAID` with the recomputed `SAID`. If they are identical then the verification is successful; otherwise unsuccessful.
+
+The `CESR` \[CESR\] encoding of a Blake3-256 (32 byte) binary digest has 44 Base-64 URL-safe characters. The first character is `E` which represents Blake3-256. Therefore, a serialization of a fixed field data structure with a SAID generated by a Blake3-256 digest must reserve a field of length 44 characters. Suppose the initial value of the fixed field serialization is the following string:
+```
+field0______field1______________________________________field2______
+```
+In the string, `field1` is of length 44 characters. The first step to generating the `SAID` for this serialization is to replace the contents of `field1` with a dummy string of `#` characters of length 44 as follows:
+```
+field0______############################################field2______
+```
+The Blake3-256 digest is then computed on the above string and encoded in `CESR` format. This gives the following `SAID`:
+```
+E8wYuBjhslETYaLZcxMkWrhVbMcA8RS1pKYl7nJ77ntA
+```
+The dummy string is then replaced with the `SAID` above to produce the final serialization with embedded `SAID` as follows:
+```
+field0______E8wYuBjhslETYaLZcxMkWrhVbMcA8RS1pKYl7nJ77ntA______
+```
+To verify the embedded `SAID` with respect to its encompassing serialization above, just reverse the generation steps.
+
+The crucial consideration in `SAID` generation is reproducibility. This requires the ordering and sizing of fields in the serialization to be fixed. Data structures in most computer languages have fixed fields. The example above is such an example.
+
+A very useful type of serialization especially in some languages like Python or JavaScript is of self-describing data structures that are mappings of (key, value) or (label, value) pairs. These are often also called dictionaries or hash tables. The essential feature needed for reproducible serialization of such mappings is that mapping preserve the ordering of its fields on any round trip to/from a serialization. In other words the mapping is ordered with respect to serialization. Another way to describe a predefined order preserving serialization is canonicalization or canonical ordering. This is often referred to as the mapping canonicalization problem.
+
+The _natural_ canonical ordering for such mappings is _insertion order_ or sometimes called _field creation order_. Natural order allows the fields to appear in a preset order independent of the lexicographic ordering of the labels. This enables functional or logical ordering of the fields. Logical ordering also allows the absence or presence of a field to have meaning. Fields may have a priority given by their relative order of appearance. Fields may be grouped in logical sequence for better usability and labels may use words that best reflect their function independent of their relative lexicographic ordering. The most popular serialization format for mappings is _JSON_. Other popular serializations for mappings are CBOR and MsgPack.
+
+In contrast, from a functional perspective, lexicographic ordering appears un-natural. In lexicographic ordering the fields are sorted by label prior to serialization. The problem with lexicographic ordering is that the relative order of appearance of the fields is determined by the labels themselves not some logical or functional purpose of the fields themselves. This often results in oddly-labeled fields that are so named merely to ensure that the lexicographic ordering matches a given logical ordering.
+
+Originally mappings in most if not all computer languages were not insertion order preserving. The reason is that most mappings used hash tables under the hood. Early hash tables were highly efficient but by nature did not include any mechanism for preserving field creation or field insertion order for serialization. Fortunately, this is no longer true in general. Most if not all computer languages that support dictionaries or mappings as first-class data structures now support variations that are insertion order preserving.
+
+For example, since version 3.6 the default `dict` object in Python is insertion order preserving. Before that, Python 3.1 introduced the `OrderedDict` class which is insertion order preserving, and before that, custom classes existed in the wild for order preserving variants of a Python `dict`. Since version 1.9 the Ruby version of a `dict`, the `Hash` class, is insertion order preserving. Javascript is a relative latecomer but since ECMAScript `ES6` the insertion ordering of JavaScript objects was preserved in `Reflect.ownPropertyKeys()`. Using custom `replacer` and `reviver` functions in `.stringify` and `.parse` allows one to serialize and de-serialize JavaScript objects in insertion order. Moreover, since ES11 the native `.stringify` uses insertion order all text string labeled fields in Javascript objects. It is an uncommon use case to have non-text string labels in a mapping serialization. A list is usually a better structure in those cases. Nonetheless, since ES6 the new Javascript `Map` object preserves insertion order for all fields for all label types. Custom `replacer` and `reviver` functions for `.stringify` and `.parse` allows one to serialize and de-serialize Map objects to/from JSON in natural order preserving fashion. Consequently, there is no need for any canonical serialization but natural insertion order preserving because one can always use lexicographic ordering to create the insertion order.
+
+Suppose the initial value of a Python `dict` is as follows:
+```
+{
+    "said": "",
+    "first": "Sue",
+    "last": "Smith",
+    "role": "Founder"
+}
+```
+As before the `SAID` will be a 44 character CESR encoded Blake3-256 digest. The serialization will be _JSON_. The `said` field value in the `dict` is to be populated with the resulting `SAID`. First the value of the `said` field is replaced with a 44 character dummy string as follows:
+```
+{
+    "said": "############################################",
+    "first": "Sue",
+    "last": "Smith",
+    "role": "Founder"
+}
+```
+The `dict` is then serialized into JSON with no extra whitespace. The serialization is the following string:
+```
+{"said":"############################################","first":"Sue","last":"Smith","role":"Founder"}
+```
+The Blake3-256 digest is then computed on that serialization above and encoded in `CESR` to provide the `SAID` as follows:
+```
+EnKa0ALimLL8eQdZGzglJG_SxvncxkmvwFDhIyLFchUk
+```
+The value of the `said` field is now replaced with the computed and encoded `SAID` to produce the final serialization with embedded `SAID` as follows:
+```
+{"said":"EnKa0ALimLL8eQdZGzglJG_SxvncxkmvwFDhIyLFchUk","first":"Sue","last":"Smith","role":"Founder"}
+```
+The final serialization may be converted to a python `dict` by deserializing the JSON to produce:
+```
+{
+    "said": "EnKa0ALimLL8eQdZGzglJG_SxvncxkmvwFDhIyLFchUk",
+    "first": "Sue",
+    "last": "Smith",
+    "role": "Founder"
+}
+```
+The generation steps may be reversed to verify the embedded `SAID`. The `SAID` generation and verification protocol for mappings assumes that the fields in a mapping serialization such as JSON are ordered in stable, round-trippable, reproducible order, i.e., canonical. The natural canonical ordering is called `field insertion order`.
+
+`SAIDs` make [JSON Schema](https://json-schema.org/draft/2020-12/json-schema-core.html) fully self-contained with self-referential, unambiguously cryptographically bound, and verifiable content-addressable identifiers. We apply the `SAID` derivation protocol defined above to generate the `$id` field.
+
+First, replace the value of the `$id` field with a string filled with dummy characters of the same length as the eventual derived value for `$id`.
+```
+{
+        "$id": "############################################",
+        "$schema": "http://json-schema.org/draft-07/schema#",
+        "type": "object",
+        "properties": {
+            "full_name": {
+            "type": "string"
+        }
+    }
+```
+Second, make a digest of the serialized schema contents that include the dummy value for the `$id`.
+```
+EZT9Idj7zLA0Ek6o8oevixdX20607CljNg4zrf_NQINY
+```
+Third, replace the dummy identifier value with the derived identifier value in the schema contents.
+```
+{
+        "$id": "EZT9Idj7zLA0Ek6o8oevixdX20607CljNg4zrf_NQINY",
+        "$schema": "http://json-schema.org/draft-07/schema#",
+        "type": "object",
+        "properties": {
+            "full_name": {
+            "type": "string"
+        }
+    }
+```
+Usages of `SAIDs` within authentic data containers as demonstrated here are referred to as `self-addressing data (SAD)`.
+
+As long as any verifier recognizes the derivation code of a `SAID`, the `SAID` is a cryptographically secure commitment to the contents in which it is embedded; it is a cryptographically verifiable, self-referential, content-addressable identifier. Because a `SAID` is both self-referential and cryptographically bound to the contents it identifies, anyone can validate this binding if they follow the _derivation protocol_ outlined above.
+
+To elaborate, this approach of deriving self-referential identifiers from the contents they identify, is called `self-addressing`. It allows any validator to verify or re-derive the self-referential, self-addressing identifier given the contents it identifies. To clarify, a `SAID` is different from a standard content address or content-addressable identifier in that a standard content-addressable identifier may not be included inside the contents it addresses. Moreover, a standard content-addressable identifier is computed on the finished immutable contents, and therefore is not self-referential.
+
+# Appendix: Embedding SAIDs in URLs
+
+ToDo. Provide normative protocol for embedding a SAID in a URL to replace a bare SAID in a data structure (field map). The purpose is to ease the transition from web 2.0 URL centric infrastructure to zero-trust infrastructure. This is a caveated adoption vector because it mixes discovery (URL) with integrity (SAID) layers. The OOBI protocol is an example of using embedded SAIDs inside URLs merely for verifiable discovery while using the bare SAID in the discovered data item.
+
+# Appendix: JSON Schema with SAIDs
+
+ToDo. Provide normative rules for using SAIDs to lock-down JSON Schema (immutable) to prevent schema malleability attacks.
+
+# Conventions and Definitions
+
+(::boilerplate bcp14-tagged)
+
+# Security Considerations
+
+TODO Security
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+\--- back
+
+# Acknowledgments
+
+(:numbered\="false")
+
+Members of the keripy development team and the ToIP ACDC WG.
+
+
+
+
+---
+title: draft-ssmith-oobi
+description: title: "Out-Of-Band-Introduction (OOBI) Protocol"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-oobi/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-oobi/index.md
+---
+
+# draft-ssmith-oobi
+
+title: "Out-Of-Band-Introduction (OOBI) Protocol" abbrev: "OOBI" category: info
+
+docname: draft-ssmith-oobi-latest v: 3 area: AREA workgroup: WG Working Group keyword: Internet-Draft venue: group: WG type: Working Group mail: [WG@example.com](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/WG@example.md) arch: [https://example.com/WG](https://example.com/WG) github: USER/REPO latest: [https://example.com/LATEST](https://example.com/LATEST)
+
+fullname: Samuel M. Smith organization: ProSapien LLC email: [sam@prosapien.com](mailto:sam@prosapien.com)
+
+normative:
+
+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
+
+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
+
+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:
+
+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
+
+PT: target: [https://en.wikipedia.org/wiki/Percolation\_theory](https://en.wikipedia.org/wiki/Percolation_theory) title: Percolation Theory
+
+FPP: target: [https://en.wikipedia.org/wiki/First\_passage\_percolation](https://en.wikipedia.org/wiki/First_passage_percolation) title: First Passage Percolation
+
+IPT: target: [https://www.physics.purdue.edu/flow/MMproject/Wilkinson1983.pdf](https://www.physics.purdue.edu/flow/MMproject/Wilkinson1983.pdf) title: Invasion Percolation
+
+DOMIP: target: [https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.103.018701](https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.103.018701) title: Dynamic Opinion Model and Invasion Percolation
+
+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/keripy/blob/master/ref/Peer2PeerCredentials.md](https://github.com/WebOfTrust/keripy/blob/master/ref/Peer2PeerCredentials.md) 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
+
+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)
+
+URL: target: [https://en.wikipedia.org/wiki/URL](https://en.wikipedia.org/wiki/URL) title: URL
+
+QR: target: [https://en.wikipedia.org/wiki/QR\_code](https://en.wikipedia.org/wiki/QR_code) title: QR Code
+
+DM: target: [https://en.wikipedia.org/wiki/Data\_Matrix](https://en.wikipedia.org/wiki/Data_Matrix) title: Data Matrix
+
+RTE: target: [https://gdpr-info.eu/art-17-gdpr/](https://gdpr-info.eu/art-17-gdpr/) title: GDPR Right to Erasure
+
+\--- abstract
+
+An Out-Of-Band Introduction (OOBI) provides a discovery mechanism that associates a given URI or URL with a given AID (Autonomic IDentifier) or SAID (Self-Addressing IDentifier) ||KERI\_ID||||KERI||||SAID\_ID||||OOBI\_ID||. 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 ||KERI\_ID||||KERI||. The OOBI protocol provides a web-based bootstrap and/or discovery mechanism for the KERI and the ACDC (Authentic Chained Data Container) protocols ||KERI\_ID||||ACDC\_ID||||OOBI\_ID||. Thus the security (or more correctly the lack of security) of an OOBI is out-of-band with respect to a KERI AID or an ACDC that uses KERI. To clarify, everything in KERI or that depends on KERI is end-verifiable, therefore it has no security dependency nor does it rely on security guarantees that may or may not be provided by web or internet infrastructure. OOBIs provide a bootstrap that enables what we call Percolated Information Discovery (PID) which is based on Invasion Percolation Theory ||IPT||||DOMIP||||PT||||FPP||. This bootstrap may then be parlayed into a secure mechanism for accepting and updating data. The principal data acceptance and update policy is denoted BADA (Best-Available-Data-Acceptance).
+
+\--- middle
+
+# Introduction
+
+Vacuous discovery of IP resources such as service endpoints associated with a KERI AID (Autonomic IDentifier) or SAID (Self-Addressing IDentifier) requires an Out-Of-Band Introduction (OOBI) to associate a given URL with a given AID (Autonomic IDentifier) or SAID (Self-Addressing IDentifier) ||KERI\_ID||||KERI||||SAID\_ID||||OOBI\_ID||||URL||. The principal reason for this requirement is that KERI AIDs are derived in a completely decentralized manner. The root-of-trust of a KERI AID is completely independent of internet and DNS addressing infrastructure. Thus an IP address or URL could be considered a type of Out-Of-Band Infrastructure (OOBI) for KERI. In this context, an introduction is an association between a KERI AID and a URL that may include either an explicit IP address or a DNS name for its host ||RFC3986||||URL||. We call this a KERI OOBI (Out-Of-Band-Introduction) and is a special case of Out-Of-Band-Infrastructure (OOBI) with a shared acronym. For the sake of clarity, unless otherwise qualified, OOBI is used to mean this special case of an _introduction_ and not the general case of _infrastructure_.
+
+Moreover, because IP infrastructure is not trusted by KERI, a KERI OOBI by itself is considered insecure with respect to KERI, and any OOBI must therefore be later verified using a KERI BADA (Best-Available-Data-Acceptance) mechanism. The principal use case for an OOBI is to jump-start the discovery of a service endpoint for a given AID. To reiterate, the OOBI by itself is not sufficient for discovery because the OOBI itself is insecure. The OOBI merely jump-starts authenticated discovery.
+
+Using IP and DNS infrastructure to introduce KERI AIDs which AIDs are then securely attributed allows KERI to leverage IP and DNS infrastructure for discovery. KERI does not, therefore, need its own dedicated discovery network, OOBIs with URLs will do.
+
+A secondary use case for OOBI's is to provide service endpoints or URIs for SAD (Self-Addressed Data) items identifier by their SAID (Self-Addressing IDentifier). A SAID is a content address derived from a cryptographic digest of the serialization of a data item. The SAID protocol provides a derivation process where the SAID is actually included in the SAD. This makes a SAID self-referential. Verification of a SAD resource obtained by querying a URI that includes the SAD's SAID is accomplished by simply re-deriving the SAID of the SAD in the reply and comparing it to the SAID in the URI. The `sad` URI scheme may be simply expressed as `sad:said` where _said_ is replaced with the actual SAID of the referenced SAD item. The mime-type of the returned SAD is determined by the serialization type such as JSON or CBOR for example.
+
+# Basic OOBI
+
+The simplest form of a KERI OOBI is a namespaced string, a tuple, a mapping, a structured message, or a structured attachment that contains both a KERI AID and a URL (or URI). The OOBI associates the URL with the AID. By convention the URL typically include the word `oobi` in its path to indicate that it is to be used as an OOBI but this is not required. In tuple form this abstractly,
+```
+(url, aid)
+```
+and concretely,
+```
+("http://8.8.5.6:8080/oobi", "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM")
+```
+An OOBI itself is not signed or otherwise authenticatable by KERI but may employ some other Out-Of-Band-Authentication (OOBA) mechanism i.e. non-KERI.
+
+The OOBI is intentionally simplistic to enable very low byte count introductions such as a may be conveyed by a QR code or Data matrix ||QR||||DM||.
+
+# BADA (Best-Available-Data-Acceptance) Policy
+
+The recipient of an OOBI verifies the OOBI by authenticating the endpoint URL given by the OOBI with respect to an authorization signed by the controller of the AID given by the OOBI. This authorization follows the BADA (Best Available Data Acceptance) policy. The BADA policy provides monotonicity for updates to authentically signed data at rest. This follows best practices for zero-trust computing infrastructure for authentic data. The authorization is usually obtained as a resource in reply to a query to the OOBI URL. Specifically, the service endpoint at the URL responds with a resource that contains the supporting reply messages that are KERI authenticatable.
+
+KERI follows a "zero-trust" security model for authentic or securely attributable data. That means that data is signed both in motion and at rest. The primary attack against signed data is a replay attack. In a replay attack, an adversary obtains a copy of data with a verifiable signature and then replays it later. Without some other information, it is difficult for a host to detect that it is indeed a replay or malicious reuse of signed data and not the original use of that data.
+
+To elaborate, there are two primary types of attacks on authentic or authenticatable data-at-rest. The first is a replay attack. The second is a deletion attack. In a replay attack, an adversary keeps a copy of an authentic message or data together with its verifiable signature that has already been created and used by the controller of a KERI AID and then sometime later replays that same message with the signature. A verifier may thereby be fooled into believing that the replay is actually a new message and not a stale message. There are both interactive and non-interactive mitigations to replay attacks. Interactive mitigations use some type of nonce exchanged between updater and updatee. The nonce exchange introduces latency, scalability, and synchronization limitations. Non-interactive mitigations require a monotonic ordering mechanism. Typically monotonic ordering is based on logic rooted in a sequence number or date-time stamp. Because non-interactive mitigations are asynchronous, however, they do not have the latency and scalability limitations of interactive mitigations and are therefore preferred.
+
+The KEL (Key Event Log) of a KERI AID provides such a monotonic ordering mechanism as it employs both a sequence number and digest chaining. For authentic data directly anchored to or determined by a KEL, the relative KEL location determines the monotonic order. This ordering determination includes TEL (Transaction Event Logs) which are monotonically ordered with respect to anchoring seals in the associated KEL ||PTEL\_ID||. For authentic data not directly anchored or included in a KEL, the relative key state (which is determined by the KEL) may be used in combination with a date-time stamp to ensure monotonic ordering. Finally, for any AID whose key state is fixed, a date-time stamp may be used with appropriate update logic to ensure monotonic ordering. The logic that ensures monotonic ordering is called BADA (Best Available Data Acceptance) and is described later in this section.
+
+A deletion attack is related to a replay attack. Once erased or deleted, a verifier may not be able to detect a replay attack of the deleted data because it has lost a record of the prior play to compare against. To elaborate, once erased, any stale authenticated data acting as authorization may be replayed without detection. This exposes a problem with the GPDR right-to-erasure, which if naively implemented as total erasure, exposes the data controller to a replay attack of erased data.
+
+The primary mitigation mechanism for deletion attacks is to maintain redundant copies of the signed authentic data. As long as one of the redundant copies has not been deleted then a comparison between the hosts of the redundant copies will expose the deletion attack given there is at least one undeleted copy. The monotonicity of the data is preserved in each copy. The host need merely compare copies. Only the current data item needs to be kept in full in order to support the use of that data. For protection against replay attacks using stale data, only copies of the digest or signature of the data need to be kept. To reiterate, a replay attack can be detected by comparing the digest or signature (which is a type of digest) of any undeleted copy with the presented data.
+
+To summarize, authentic data at rest consists of the data item and signature(s). The two primary attacks are replay and deletion. Replay attack mitigation relies on replay monotonicity in data updates. Deletion attack mitigation relies on the redundancy of monotonic data.
+
+The BADA (Best-Available-Data-Acceptance) rules apply to any data item stored in a database record whose value is used for some defined purpose. Updates are sourced from the controller of an associated KERI AID. The primary purpose of BADA policy is to enforce monotonicity of the updates with respect to the key state of that associated AID. This primarily protects against replay attacks on the database record. For example, a rollback to an earlier value via replay of an earlier update. An _Update_ or change to the database record is _accepted_ when it follows the BADA rules (policy) for acceptance. The BADA rules ensure the monotonicity of all updates.
+
+There are two different mechanisms for the controller of an AID to authorize updates to a given database record. The first is by including a reference to the update in the KEL of the authorizing AID. All entries in a KEL must be signed by the current signing key-pair(s) given by the key-state for that KEL. The second is by signing a date-time stamped update. In this case, the update either includes a reference to the key-state in the authorizing AID's KEL from which the signing key-pair(s) needed to verify the signature is obtained or the AID is ephemeral with a fixed key-state (has a non-transferable derivation code). The rules differ for each of the two mechanisms.
+
+The _Update_ to some record is included in or anchored via a seal to the AID’s key-state in its KEL. In either case, the _Update_ is referenced in an event in the KEL of the AID. By virtue of the reference, the Controller of that KEL's AID is authorizing that Update. The record may have a _Prior_ value that is being updated or the _Update_ serves to create the initial value of the record. _Prior_ means the prior record.
+```
+Rules for the acceptance of the *Update*:  (in order of priority)
+  Confirm *Update* is anchored or included in AID's KEL.
+
+  WHEN Update is anchored in AID's KEL AND...
+    IF no *Prior* THEN accept. (always)
+    IF *Prior* AND...
+      *Update’s* anchor appears later in KEL than the Prior’s anchor THEN accept.
+  Otherwise, do not accept.
+```
+The _Update_ to some record is signed by the controller of the AID, but the _Update_ itself is NOT included in or anchored to the AID’s KEL. The record may have a _Prior_ value that is being updated or the _Update_ serves to create the initial value of the record. _Prior_ means the prior record. All date-times are relative to the controller's date-time, NOT the database host's date-time. There are two cases. These are as follows.
+
+1.  Ephemeral AID whose key-state is fixed (no KEL needed)
+2.  Persistent AID whose key-state is provided by KEL
+```
+Rules for the acceptance of the *Update*:  (in order of priority)
+  Confirm signature on the *Update* verifies against indicated key-state under which signature was made.
+
+  WHEN signature verifies AND...
+    IF no *Prior* THEN accept (always).
+    IF *Prior* THEN ...
+      Compare the *Update’s* verified signature key-state against the *Prior's* verified signature key-state.
+      IF the *Update’s* key-state appears later in KEL than the *Prior's* key-state THEN accept.
+      IF both the *Update’s* and the *Prior's* key-states appear at the same location in KEL AND...
+              *Update’s* date-time is later than the *Prior's* date-time THEN accept.
+  Otherwise, do not accept.
+```
+In the conventional client-server database architecture, the database server is responsible for creating records on the behalf of clients and assigning unique identifiers for each record. The server returns to the client the unique record identifier when it creates a record. The server is the source of truth. But in a zero-trust (end-verifiable) decentralized peer-to-peer architecture, there is no client/server. Every host is a Peer. Each Peer is the source of truth for its own data. Therefore each Peer is responsible for managing its own records. Each Peer MUST be able to create unique identifiers for its own data. This inverts the architecture because each Peer creates a unique identifier for each of its own data items and sends that identifier with the data item to the other Peers. Each Peer stores data on the behalf of the other Peers. This inverted architecture enables consistent authentic data update policies that work asynchronously across multiple Peers and are replay and deletion attack resistant. Each Peer has an end-verifiable (via signature) monotonically updated view of the data records sourced from the other Peers.
+
+The acronym for the traditional client-server database update policy is CRUD (Create, Read, Update, Delete). The acronym for the new peer-to-peer end-verifiable monotonic update policy is RUN (Read, Update, Nullify). As described above, 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. The hosting Peer merely stores a copy of an Update to records sent out by the source Peer (controller). Thus there is no Create action only Update action. When a Peer has not yet seen any version of a record, then its copy is vacuous and is replaced by the first Update its sees. To clarify, a source Peer updates other Peers by sending out the latest copy or version of its own record. The original copy or version is always created by the source Peer.
+
+In order to ensure that the hosting Peers are resistant to replay and deletion attacks, they apply non-interactive monotonic update logic to any updates they receive from the source Peer. This means that a hosting Peer MUST NOT ever delete a record storing the latest version of an Update. Thus there is no Delete. Instead of Delete, Peers Nullify. A Nullify is a special type of Update that indicates that the data in the record is no longer valid without erasing the record that includes a reference to the latest monotonic determining anchor and/or date-time. There are two ways to indicate Nullification. The first is to assign a `null` value to the record. This works for single field records. The second is to assign a Boolean logic flag field that indicates the record has been Nullified. This works for multi-field records.
+
+An important use case for BADA-RUN is to process OOBIs that provide service endpoint discovery of the AIDS of KERI components. These components include but are not limited to, Controllers, Agents, Backers (Witness or Registrar), Watchers, Jurors, Judges, and Forwarders. An endpoint is a URL that may include an IP Scheme, Host, Port, and Path. The model for securely managing endpoint data starts with a Principal Controller of an AID. A Principal Controller authorizes some other component to act as a Player in a Role. Typically a Role serves some function needed by the Principal Controller to support its AID and may be reached at a service endpoint URL for that Role. Each component in turn is the Controller of its own AID. Each component AID is a Player that may provide or act in a Role on behalf of the Principal Controller by providing services at the associated service endpoint for its associated Role.
+
+The authorization model uses a zero-trust BADA-RUN policy to Update authorizations. A Principal Controller authorizes a Player by signing a Role authorization message that authorizes the Player's AID to act in a role. A Player authorizes its endpoint URL by signing an endpoint authorization message that authorizes a URL (location) with a scheme. Any Peer may keep an updated copy of the latest service endpoint URL(s) provided by a Player in a Role for a given Principal AID by following the BADA-RUN policy on updates sent to its database of these authorizations. The authorizations are issued in the context of the KERI key-state for the Principal and Player AIDs.
+
+Some components (Players in Roles) are implicitly authorized by the Principal controller by being explicitly designated in the KEL of the Principal, i.e. there is no explicit authorization message of the Player/Role. The authorization is implied by the KEL entry. For example, a Backer designation of a Witness or Registrar AID implicitly authorizes that AID to act as a Player in the Role of Witness or Registrar. An associated explicit endpoint authorization message signed by that Witness or Backer is still needed to provide the URL (location and scheme) of the actual service endpoint for that Player.
+
+The combination of KERI and the BADA-RUN policy enables any Controller to manage data in a zero-trust architecture at the database level. Any controller may promulgate verifiably authentic information with replay and deletion attack resistance. The authentic information may be merely source data or may be authorizations to enable some other function. The hard work of determining the associated key-state is provided by KERI. KERI makes the establishment of authenticity straightforward. The BADA-Run policy protects against replay and deletion attacks given authentic data.
+
+This approach follows the many thin layers approach of the Hourglass protocol model. BADA-RUN is a thin layer on top of KERI authenticity. OOBIs are a thin discovery layer that sits on top of a thin authorization layer (leveraging reply messages and BADA-RUN logic) on top of KERI.
+
+This also follows the design ethos of KERI of minimally sufficient means. OOBIs leverage the existing Internet discovery mechanisms but without needing to trust the Internet security model (or the lack of one). End-verifiability in KERI provides safety to any OOBI discovery. The Internet's discovery mechanism, DNS/CA, is out-of-band with respect to KERI security guarantees. Thus OOBIs may safely use DNS/CA, web search engines, social media, email, and messaging as discovery mechanisms. The worst case is the OOBI fails to result in a successful discovery and some other OOBI must be used.
+
+Typically, the query of a ReST endpoint given by the OOBI URL could return as proof any associated authorizing reply message(s) as well as any associated KELs.
+
+This section provides an example of using OKEA (OOBI KERI Endpoint Authorization) with BADA-RUN for endpoint disclosure.
+
+The KERI protocol defines a generic `reply` message for updating information using the BADA-RUN policy. Each `reply` message includes a route, `r`, field that indicates both the type of the payload and the handler that should process the message. The route, `r`, field value is a slash, `/` delimited pathname string. The Principal Controller AID is indicated by the CID (Controller ID) or `cid` field. The endpoint component Player is indicated the EID (Endpoint Controller ID) or `eid` field. There are two different authorization cases. In one case, a CID authorizes an EID in a Role. In the other case, an EID authorizes a Loc (URL location) for a scheme. There are two routes for each type of authorization. One route updates the authorization and the other nullifies the authorization. These are summarized as follows,
+
+-   Datetime stamped BADA authorization Reply message by CID of EID in Role (Update)
+-   Datetime stamped BADA deauthorization by CID of EID in Role (Nullify)
+-   Datetime stamped BADA authorization by EID of  URL for scheme (Update).
+-   Datetime stamped BADA deauthorization by EID of URL for scheme  (Nullify)
+
+A party interested in discovering the service endpoint for a given Controller AID initiates the discovery by providing an OOBI. A successful discovery will result in the return of signed `reply` messages that provide verifiable proof that the service endpoint (either directly provided in the OOBI, or indirectly provided via forwarding) is an authorized endpoint for that AID.
+
+To summarize, upon acceptance of an OOBI the recipient queries the provided URL for proof that the URL is an authorized endpoint for the given AID. The proof format may depend on the actual role of the endpoint. A current witness for an AID is designated in the current key state's latest establishment event in the AID's KEL. Therefore merely replying with the Key State or KEL may serve as proof for a witness introduced by an OOBI. The actual URL may be authorized by an attendant signed `/loc/scheme` reply message with the URL.
+
+Other roles that are not explicitly part of key-state (i.e. are not designated in KEL establishment events) must be authorized by explicit signed reply messages. Typically these will be a signed `/end/role/` reply message. The actual URL may be authorized by an attendant signed `/loc/scheme` reply message with the URL.
+
+Example reply messages.
+```
+{
+  "v": "KERI10JSON000113_",
+  "t": "rpy",
+  "d": "Ekd189yFsX1eLhQ2NffI6AaF8ZxKXyej_jfn4wMNJq-w",
+  "dt": "2021-01-01T00:00:00.000000+00:00",
+  "r": "/end/role/add",
+  "a":
+  {
+    "cid": "EhlsdBaCvxnW0z3m2OXxStaZkG76g0zC_vtPbPPglDK0",
+    "role": "witness",
+    "eid": "BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY"
+  }
+}
+```
+```
+{
+  "v": "KERI10JSON000113_",
+  "t": "rpy",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2021-01-01T00:00:00.000000+00:00",
+  "r": "/end/role/cut",
+  "a":
+  {
+    "cid": "EhlsdBaCvxnW0z3m2OXxStaZkG76g0zC_vtPbPPglDK0",
+    "role": "witness",
+    "eid": "BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY"
+  }
+}
+```
+```
+{
+  "v": "KERI10JSON000108_",
+  "t": "rpy",
+  "d": "EbAwspDQjS-Ve-tzDtAuzx4K8uhh-0AyXWZrSKm64PFQ",
+  "dt": "2021-01-01T00:00:00.000000+00:00",
+  "r": "/loc/scheme",
+  "a":
+  {
+    "eid": "BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY",
+    "scheme": "http",
+    "url": "http://localhost:8080/controller/tam"
+  }
+}
+```
+To Nullify set the `url` to the empty string `""`.
+```
+{
+  "v": "KERI10JSON000108_",
+  "t": "rpy",
+  "d": "EbAwspDQjS-Ve-tzDtAuzx4K8uhh-0AyXWZrSKm64PFQ",
+  "dt": "2021-01-01T00:00:00.000000+00:00",
+  "r": "/loc/scheme",
+  "a":
+  {
+    "eid": "BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY",
+    "scheme": "http",
+    "url": ""
+  }
+}
+```
+# SPED (Speedy Percolated Endpoint Discovery)
+
+All the information needed to discover and verify is bootstrapped from the OOBI. Subsequent authorization is non-interactive thus making it highly scalable. BADA-RUN authorization is also lightweight for the host because the only memory requirements are a sequence number, date-time stamp window, and nullification state. This provides what we call zero-trust percolated discovery or speedy percolated discovery ||PT||||FPP||||IPT||||DOMIP||. Percolation means that each discoverer in turn may share what it discovers with any subsequent discoverers. Because the information so discovered is end-verifiable, the percolation mechanism does not need to be trusted. Percolating intermediaries do not need to be trusted.
+
+just-in-time/need-to-know discovery ToDo
+
+# OOBI Variants
+
+An OOBI may include a list of URLs thus simultaneously making an introductory association between the AID and multiple URLs. This would be a multi-OOBI (MOOBI). In general, we may refer to a multi-OOBI as a special case of an OOBI without making a named distinction.
+
+URLs provide a namespace which means that the mapping between URL and AID can be combined into one namespaced URL where the AID is in the path component and any other hints such as roles or names are in the query component of the URL. This would be a type of self-describing OOBI URL.
+
+For example, suppose the `aid` is
+```
+EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM
+```
+This may be included as a path component of the `url` such as,
+```
+http://8.8.5.6:8080/oobi/EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM
+```
+This is called an _**OOBI URL**_ or `iurl` for short. This means that all that is needed to bootstrap discovery of a KERI AID is an `iurl`. KERI can leverage the full IP/DNS infra-structure for discovery bootstrap of an `aid` by providing an `iurl` with that `aid` for lookup.
+
+The aid may act in any of the KERI roles such as `watcher`, `witness`, `juror`, `judge` or `registrar` but is usually a `controller`. In the later case, the `iurl` may be a service endpoint provided by one of the supporting components for a given controller. Thus the `aid` in an OOBI may be either a controller id, `cid` or an endpoint provider id, `eid`. The resource at that URL in the OOBI is ultimately responsible for providing that detail but an OOBI as a URL may contain hints in the query string for the URL such as a `role` or `name` designation.
+```
+http://8.8.5.6:8080/oobi/EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM?role=watcher&name=eve
+
+https://example.com/oobi/EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM?role=witness
+```
+When the role is provided in the `iurl`, the AID (EID) of the endpoint provider for that role would be discovered via the proof returned by querying the URL. The proof returned may indicate a different URL for that role. Thus a self-describing OOBI URL may act as a forwarding mechanism.
+
+To clarify, the minimum information in an OOBI is the pair, `(url, aid)`. A compact representation of an OOBI leverages the namespacing of the URL itself to provide the AID. Furthermore, the query string in the URL namespace may contain other information or hints such as the role of the service endpoint represented by the URL or a user-friendly name.
+
+An OOBI may be returned as the result of a get request to an IETF RFC 5785 well-known URL. For example,
+```
+/.well-known/keri/oobi/EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM
+```
+Where `EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM` is the AID and the result of the request is either target URL or a redirection to the target URL where the target URL is something like
+```
+https://example.com/witness/witmer
+
+http://8.8.5.5:8080/witness/witmer
+
+http://10.0.5.15:8088/witness/witmer
+```
+The resultant target URL may be in a different domain or IP address from the `well-known` resource.
+
+A more verbose version would also include the endpoint role and the AID (EID) of the endpoint provider in a self-describing OOBI URL. For example,
+```
+https://example.com/oobi/EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM/witness/BrHLayDN-mXKv62DAjFLX1_Y5yEUe0vA9YPe_ihiKYHE
+
+http://8.8.5.6/oobi/EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM/witness/BrHLayDN-mXKv62DAjFLX1_Y5yEUe0vA9YPe_ihiKYHE
+```
+Where `EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM` is the AID (CID) of the controller and
+
+`BrHLayDN-mXKv62DAjFLX1_Y5yEUe0vA9YPe_ihiKYHE` is the AID (EID) of the controller's endpoint provider acting in the role of `witness`.
+
+A more verbose expression for an OOBI would be a KERI reply message `rpy` that is unsigned. The route, `r`, field in the message starts with `/oobi`. This specifies that it is an OOBI so the recipient knows to apply OOBI processing logic to the message. A list of URLs may be provided so that one reply message may provide multiple introductions. For example,
+```
+{
+  "v" : "KERI10JSON00011c_",
+  "t" : "rpy",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2020-08-22T17:50:12.988921+00:00",
+  "r" : "/oobi/witness",
+  "a" :
+  {
+    "urls":
+    [
+      "http://example.com/watcher/watson",
+      "http://example.com/witness/wilma"
+    ],
+    "aid":  "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"
+  }
+}
+```
+A service endpoint location reply message could also be re-purposed as an OOBI by using a special route path that starts with `/oobi` but also includes the AID being introduced and optionally the role of the service endpoint provider. This approach effectively combines the information from both the `/end/role` and `/loc/scheme` reply messages into one. This may allow a shortcut to authenticate the service endpoint. This is shown below.
+```
+{
+  "v" : "KERI10JSON00011c_",
+  "t" : "rpy",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2020-08-22T17:50:12.988921+00:00",
+  "r" : "/oobi/EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM/watcher",
+  "a" :
+  {
+    "eid": "BrHLayDN-mXKv62DAjFLX1_Y5yEUe0vA9YPe_ihiKYHE",
+    "scheme": "http",
+    "url":  "http://example.com/watcher/wilma"
+  }
+}
+```
+# Self and Blind Introductions
+
+A bare URL but no AID may be used as a blind OOBI for blind or self-introductions e.g. a blind OOBI or self OOBI. Querying that blind OOBI may return or result in a default target OOBI or default target endpoint reply. This provides a mechanism for self-introduction or blind i.e. self OOBI (SOOBI). Consider the examples of blind OOBIs below.
+```
+http://8.8.5.7:8080/oobi
+
+http://localhost:8080/oobi
+
+http://8.8.5.7:8080/oobi?role=controller&name=eve
+
+http://localhost:8080/oobi?role=controller&name=eve
+```
+To elaborate, by default, the result of a `GET` request to a blind OOBI URL could be another OOBI with an AID that is the `self` AID of the node providing the blind OOBI endpoint or the actual authenticatable `self` endpoint with its AID or a default set of authenticatable endpoints. This is useful to bootstrap components in an infrastructure where the target URLs do not use a public DNS address but instead use something more secure like an explicit public IP address or a private IP or private DNS address. A self-introduction provides a bootstrap mechanism similar to a hostname configuration file with the exception that in the OOBI case the AID is not in the configuration file just the bare URL and the given node queries that bare URL (blind OOBI) to get the target endpoint AID. This allows bootstrap using bare IP addresses in systems where the IP infrastructure is more securely managed than public DNS or where some other Out-Of-Band-Authentication (OOBA) mechanism is used in concert.
+
+To clarify, because a bare URL, blind OOBI, does not expose an AID, the resultant response when querying the OOBI may depend on other factors such as the source IP of the querier (requester) and/or another out-of-band-authentication (OOBA) mechanism. This supports the private bootstrap of infrastructure. Of course one could argue that this is just kicking the can down the road but IP addresses are correlatable and a blind OOBI can leverage IP infrastructure for discovery when used in combination with some other OOBA mechanism without unnecessary correlation.
+
+This may be especially useful to bootstrap components in an infrastructure where the target URLs do not use a public DNS address but use instead something more secure like an explicit public IP address or a private IP or private DNS address. A self-introduction provides a bootstrap mechanism similar to a hostname configuration file with the exception that in the OOBI case the AID is not in the configuration file just the bare OOBI URL and the given node queries that bare OOBI to get the target endpoint AID. This allows bootstrap using bare IP addresses in systems where the IP infrastructure is more securely managed than public DNS or where some other Out-Of-Band-Authentication (OOBA) mechanism is used in concert. Because the OOBI itself does not contain an AID the association of the resultant AID is not provided by the OOBI and the resultant AID's association must be secured by some other mechanism.
+
+For example, a given indirect mode controller is identified by its AID (CID). The controller must also create witness hosts with endpoints. This means first spinning up witness host nodes and creating witness AIDs (WIDs) for those nodes. Given that these WIDs must be eventually designated in the KEL for the CID, the controller of the CID can confirm using its KEL that the signed endpoint reply provided by a bare OOBI request is indeed signed by the corresponding private keys for a WID designated in its KEL. This means that the only place that the WID must appear is in the KEL and not in all the config files used to bootstrap communications between the CID host and its designated WID hosts. Bare OOBIs will do. The redundant configuration information may be a vector for a type of DDOS attack where corrupted inconsistent redundant configuration information results in a failure to boot a system that must be manually fixed. Redundancy for security is best applied in the context of a self-healing or resilient threshold structure that explicitly manages the redundancy as a security mechanism not as un-managed inadvertent redundancy.
+
+ToDo
+
+# OOBI Forwarding
+
+In every case, an OOBI may result in a proof for a different URL than that provided in the OOBI itself. The allows OOBI forwarding so that introductions produced as hard copies such as QR codes do not necessarily become stale. The recipient of the OOBI may choose to accept that proof or not. Ultimately the recipient only treats URLs as valid endpoints when they are fully KERI authenticated. Given that an OOBI result is always KERI authenticated before use in a given role, the worst case from a security perspective is that an OOBI may be part of a DDOS attack but not as part of a service endpoint cache poison attack.
+
+# OOBI with MFA
+
+An OOBI may be augmented with one or more Out-Of-Band Authentications (OOBAs) to minimize the likelihood of a DDOS OOBI attack. A given recipient may require as a precondition to accepting an OOBI one or more OOBA mechanisms such as text messages, emails, etc that together provide some degree of non-KERI-based security to the OOBI. Thus an OOBI could employ out-of-band (with respect to KERI) multi-factor-authentication (MFA) to preclude any OOBI-based DDOS attacks on KERI.
+
+# KERI OOBI Use in Installation Configuration
+
+The main value of an OOBI is that it is compact and is not encumbered by authentication proofs but may be used to kick-start the process of authentication (proving).
+
+One way to pre-configure a vacuous KERI installation is to provide OOBIs in a configuration file. The bootstrap process of the installation then queries the associated URLs to retrieve the KERI authentication proofs (BADA) that then are used to populate its database securely. This simplifies the configuration file.
+
+In contrast, an alternative would be to populate the configuration file with the KERI authentication proofs. But these proofs may be quite verbose and cumbersome and may make the config file somewhat difficult to manage in human-readable/writable form. Furthermore if one already had the proofs one could just pre-populate the database with those proofs. Therefore OOBI based configuration files may be advantageous as either easier to manage or as a viable option when the proofs are not yet available at configuration time.
+
+Furthermore, a clean clone replay restart of a given KERI component is designed to fix any unverified corruption of its associated KELs. If each component uses OOBIs to retrieve the authentication proofs from other components then all the components will have clean proofs instead of stale proofs.
+
+Each KERI installation may also optionally provide an OOBI permissioning record list associated with each habitat to indicate which OOBI queries it will respond to. This may also be inited with a config file.
+
+# Data OOBI (DOOBI)
+
+ToDo
+
+ToDo
+
+ToDo
+
+# Conventions and Definitions
+
+(::boilerplate bcp14-tagged)
+
+# Security Considerations
+
+OOBIs are out-of-band with respect to the security of the infrastructure to which they provide an introduction. OOBIs assume that any introduced endpoints will be subsequently verified by their associated in-band mechanisms. There are no other security considerations.
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+\--- back
+
+# Acknowledgments
+
+(:numbered\="false")
+
+TODO acknowledge.
+
+
+
+
+---
+title: draft-ssmith-keri
+description: title: "Key Event Receipt Infrastructure (KERI)"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-keri/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-keri/index.md
+---
+
+# draft-ssmith-keri
+
+title: "Key Event Receipt Infrastructure (KERI)" abbrev: "KERI" docname: draft-ssmith-keri-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: S. Smith organization: ProSapien LLC email: [sam@prosapien.com](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/sam@prosapien.md)
+
+normative:
+
+KERI-ID: target: [https://github.com/WebOfTrust/ietf-keri](https://github.com/WebOfTrust/ietf-keri) title: IETF KERI (Key Event Receipt Infrastructure) Internet Draft date: 2022 author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC
+
+CESR-ID: target: [https://github.com/WebOfTrust/ietf-cesr](https://github.com/WebOfTrust/ietf-cesr) title: IETF CESR (Composable Event Streaming Representation) Internet Draft date: 2022 author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC
+
+SAID-ID: target: [https://github.com/WebOfTrust/ietf-said](https://github.com/WebOfTrust/ietf-said) title: IETF SAID (Self-Addressing IDentifier) Internet Draft date: 2022 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
+
+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
+
+RFC8259: JSON
+
+JSOND: target: [https://www.json.org/json-en.html](https://www.json.org/json-en.html) title: JavaScript Object Notation Delimiters
+
+RFC8949: CBOR
+
+CBORC: target: [https://en.wikipedia.org/wiki/CBOR](https://en.wikipedia.org/wiki/CBOR) title: CBOR Mapping Object Codes
+
+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
+
+informative:
+
+KERI: target: [https://arxiv.org/abs/1907.02143](https://arxiv.org/abs/1907.02143) title: Key Event Receipt Infrastructure (KERI) date: 2021 author: ins: S. Smith name: Samuel M. Smith org: ProSapien LLC
+
+UIT: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory\_web.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) title: Universay Identifier Theory seriesinfo: WhitePaper date: 2020 author: ins: S. Smith name: Samuel M. Smith
+
+DAD: target: [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf) title: "Decentralized Autonomic Data (DAD) and the three R's of Key Management" seriesinfo: WhitePaper date: 2018 author: ins: S. Smith name: Samuel M. Smith
+
+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 seriesinfo: WhitePaper date: 2016 author: - ins: S. Smith name: Samuel M. Smith - ins: D. Khovratovich name: Dmitry Khovratovich
+
+RFC4648: Base64
+
+RFC0020: ASCII
+
+RFC3986: URI
+
+RFC8820: URIDesign
+
+RFC4627: JSONMIME
+
+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"
+
+RFC6901: JSONPTR
+
+HCR: target: [https://en.wikipedia.org/wiki/Collision\_resistance](https://en.wikipedia.org/wiki/Collision_resistance) title: Hash Collision Resistance
+
+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
+
+BLAKE3: target: ttps://github.com/BLAKE3-team/BLAKE3 title: BLAKE3
+
+BLAKE3Spec: target: [https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf](https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf) title: BLAKE3 one function, fast everywhere
+
+BLAKE3Hash: target: [https://www.infoq.com/news/2020/01/blake3-fast-crypto-hash/](https://www.infoq.com/news/2020/01/blake3-fast-crypto-hash/) title: “BLAKE3 Is an Extremely Fast, Parallel Cryptographic Hash” seriesinfo: InfoQ date: 2020-01-12
+
+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?"
+
+TMCrypto: target: [https://eprint.iacr.org/2019/1492.pdf](https://eprint.iacr.org/2019/1492.pdf) title: “Too Much Crypto” date: 2021-05-24 author: ins: J. Aumasson name: Jean-Philippe Aumasson
+
+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)" date: 2021-05-24 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
+
+TMEd: target: [https://eprint.iacr.org/2020/1244.pdf](https://eprint.iacr.org/2020/1244.pdf) title: Taming the many EdDSAs
+
+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
+
+Stretch: target: [https://en.wikipedia.org/wiki/Key\_stretching](https://en.wikipedia.org/wiki/Key_stretching) title: Key stretching
+
+HDKC: target: [https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/hierarchical-deterministic-keys--bip32-and-beyond.md](https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/topics-and-advance-readings/hierarchical-deterministic-keys--bip32-and-beyond.md) title: "Hierarchical Deterministic Keys: BIP32 & Beyond" author: - ins: C. Allen name: Christopher Allen - ins: S. Applecline name: Shannon Applecline
+
+OWF: target: [https://en.wikipedia.org/wiki/One-way\_function](https://en.wikipedia.org/wiki/One-way_function) title: One-way\_function
+
+COWF: target: [http://www.crypto-it.net/eng/theory/one-way-function.html](http://www.crypto-it.net/eng/theory/one-way-function.html) title: One-way Function seriesinfo: Crypto-IT
+
+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
+
+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
+
+Hash: target: [https://en.wikipedia.org/wiki/Cryptographic\_hash\_function](https://en.wikipedia.org/wiki/Cryptographic_hash_function) title: Cryptographic Hash Function
+
+W3C\_DID: target: [https://w3c-ccg.github.io/did-spec/](https://w3c-ccg.github.io/did-spec/) title: "W3C Decentralized Identifiers (DIDs) v1.0"
+
+PKI: target: [https://en.wikipedia.org/wiki/Public-key\_cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) title: Public-key Cryptography
+
+SCPK: target: [https://link.springer.com/content/pdf/10.1007%2F3-540-46416-6\_42.pdf](https://link.springer.com/content/pdf/10.1007%2F3-540-46416-6_42.pdf) title: Self-certified public keys seriesinfo: "EUROCRYPT 1991: Advances in Cryptology, pp. 490-497, 1991" author: ins: M. Girault name: Marc Girault
+
+SCURL: target: [https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps](https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps) title: "SFS-HTTP: Securing the Web with Self-Certifying URLs" seriesinfo: "Whitepaper, MIT, 1999" author: - ins: M. Kaminsky name: M. Kaminsky - ins: E. Banks name: E. Banks
+
+SFS: target: [https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps](https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps) title: "Self-certifying File System" seriesinfo: “MIT Ph.D. Dissertation" date: 2000-06-01 author: ins: D. Mazieres name: David Mazieres
+
+SCPN: target: [https://dl.acm.org/doi/pdf/10.1145/319195.319213](https://dl.acm.org/doi/pdf/10.1145/319195.319213) title: "Escaping the Evils of Centralized Control with self-certifying pathnames" seriesinfo: “MIT Laboratory for Computer Science, 2000" author: - ins: D. Mazieres name: David Mazieres - ins: M. Kaashoek name: M. F. Kaashoek
+
+RFC0791: IP
+
+RFC0799: IND
+
+DNS: target: [https://en.wikipedia.org/wiki/Domain\_Name\_System](https://en.wikipedia.org/wiki/Domain_Name_System) title: Domain Name System
+
+CAA: target: [https://en.wikipedia.org/wiki/DNS\_Certification\_Authority\_Authorization](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) title: DNS Certification Authority Authorization
+
+CA: target: [https://en.wikipedia.org/wiki/Certificate\_authority](https://en.wikipedia.org/wiki/Certificate_authority) title: Certificate Authority
+
+RFC5280: ICRL
+
+CRL: target: [https://en.wikipedia.org/wiki/Certificate\_revocation\_list](https://en.wikipedia.org/wiki/Certificate_revocation_list) title: Certificate Revocation List
+
+RFC6960: OCSP
+
+OCSPW: target: [https://en.wikipedia.org/wiki/Online\_Certificate\_Status\_Protocol](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol) title: Online Certificate Status Protocol
+
+WOT: target: [https://en.wikipedia.org/wiki/Web\_of\_trust](https://en.wikipedia.org/wiki/Web_of_trust) title: Web of Trust
+
+CEDS: target: "[https://resources.infosecinstitute.com/cybercrime-exploits-digital-certificates/#gref](https://resources.infosecinstitute.com/cybercrime-exploits-digital-certificates/#gref)" title: “How Cybercrime Exploits Digital Certificates” seriesinfo: "InfoSecInstitute" date: 2014-07-28
+
+KDDH: target: "[https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/](https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/)" title: A Deep Dive on the Recent Widespread DNS Hijacking Attacks seriesinfo: "KrebsonSecurity" date: 2019-02-19
+
+DNSH: target: "[https://arstechnica.com/information-technology/2019/01/a-dns-hijacking-wave-is-targeting-companies-at-an-almost-unprecedented-scale/](https://arstechnica.com/information-technology/2019/01/a-dns-hijacking-wave-is-targeting-companies-at-an-almost-unprecedented-scale/)" title: A DNS hijacking wave is targeting companies at an almost unprecedented scale seriesinfo: "Ars Technica" date: 2019-01-10 author: ins: D. Goodin name: Dan Goodin
+
+SFTCA: target: [https://pdfs.semanticscholar.org/7876/380d71dd718a22546664b7fcc5b413c1fa49.pdf](https://pdfs.semanticscholar.org/7876/380d71dd718a22546664b7fcc5b413c1fa49.pdf) title: "Search for Trust: An Analysis and Comparison of CA System Alternatives and Enhancements" seriesinfo: "Dartmouth Computer Science Technical Report TR2012-716, 2012" author: ins: A. Grant name: A. C. Grant
+
+DNSP: target: [https://www.thesslstore.com/blog/dns-poisoning-attacks-a-guide-for-website-admins/](https://www.thesslstore.com/blog/dns-poisoning-attacks-a-guide-for-website-admins/) title: "DNS Poisoning Attacks: A Guide for Website Admins" seriesinfo: "HashedOut" date: 2020/01/21 author: ins: G. Stevens name: G. Stevens
+
+BGPC: target: [https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf](https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf) title: Using BGP to acquire bogus TLS certificates seriesinfo: "Workshop on Hot Topics in Privacy Enhancing Technologies, no. HotPETs 2017" author: ins: "H. Birge-Lee" name: "H. Birge-Lee"
+
+BBGP: target: "[https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee](https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee)" title: "Bamboozling certificate authorities with BGP" seriesinfo: "vol. 27th USENIX Security Symposium, no. 18, pp. 833-849, 2018" author: ins: "H. Birge-Lee" name: "H. Birge-Lee"
+
+RFC6962: CT
+
+CTE: target: [https://certificate.transparency.dev](https://certificate.transparency.dev) title: Certificate Transparency Ecosystem
+
+CTAOL: target: [https://queue.acm.org/detail.cfm?id=2668154](https://queue.acm.org/detail.cfm?id=2668154) title: "Certificate Transparency: Public, verifiable, append-only logs" seriesinfo: "ACMQueue, vol. Vol 12, Issue 9" date: 2014-09-08 author: ins: B. Laurie name: B. Laurie
+
+RT: target: [https://www.links.org/files/RevocationTransparency.pdf](https://www.links.org/files/RevocationTransparency.pdf) title: Revocation Transparency
+
+VDS: target: [https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf) title: Verifiable Data Structures seriesinfo: "WhitePaper" date: 2015-11-01
+
+ESMT: target: [https://eprint.iacr.org/2016/683.pdf](https://eprint.iacr.org/2016/683.pdf) title: Efficient sparse merkle trees seriesinfo: "Nordic Conference on Secure IT Systems, pp. 199-215, 2016"
+
+RC: target: [https://en.wikipedia.org/wiki/Ricardian\_contract](https://en.wikipedia.org/wiki/Ricardian_contract) title: Ricardian Contract
+
+An identity system-based secure overlay for the Internet is presented. This is based on a Key Event Receipt Infrastructure (KERI) or the KERI protocol ||KERI||||KERIID||||RFC0791||. This includes a primary root-of-trust in self-certifying identifiers (SCIDs) ||UIT||||SCPK||||SFS||||SCPN||||SCURL||. It presents a formalism for Autonomic Identifiers (AIDs) and Autonomic Namespaces (ANs). They are part of an Autonomic Identity System (AIS). This system uses the design principle of minimally sufficient means to provide a candidate trust spanning layer for the internet. Associated with this system is a decentralized key management infrastructure (DKMI). The primary root-of-trust are self-certifying identifiers that are strongly bound at issuance to a cryptographic signing (public, private) keypair. These are self-contained until/unless control needs to be transferred to a new keypair. In that event, an append-only chained key-event log of signed transfer statements provides end verifiable control provenance. This makes intervening operational infrastructure replaceable because the event logs may be served up by any infrastructure including ambient infrastructure. End verifiable logs on ambient infrastructure enable ambient verifiability (verifiable by anyone, anywhere, at any time). The primary key management operation is key rotation (transference) via a novel key pre-rotation scheme ||DAD||||KERI||. Two primary trust modalities motivated the design, these are a direct (one-to-one) mode and an indirect (one-to-any) mode. The indirect mode 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. In the direct mode, the identity controller establishes control via verified signatures of the controlling keypair. The indirect mode extends that trust basis with witnessed key event receipt logs (KERL) for validating events. The security and accountability guarantees of indirect mode are provided by KA2CE or KERI’s Agreement Algorithm for Control Establishment among a set of witnesses. The KA2CE approach may be much more performant and scalable than more complex approaches that depend on a total ordering distributed consensus ledger. Nevertheless, KERI may employ a distributed consensus ledger when other considerations make it the best choice. The KERI approach to DKMI allows for more granular composition. Moreover, because KERI is event streamed it enables DKMI that operates in-stride with data events streaming applications such as web 3.0, IoT, and others where performance and scalability are more important. The core KERI engine is identifier namespace independent. This makes KERI a candidate for a universal portable DKMI ||KERI||||KERIID||||UIT||.
+
+# Introduction
+
+The main motivation for this work is to provide a secure decentralized foundation of attributional trust for the Internet as a trustable spanning layer in the form of an identifier system security overlay. This identifier system security overlay provides verifiable authorship (authenticity) of any message or data item via secure (cryptographically verifiable) attribution to a _cryptonymous (cryptographic strength pseudonymous)_ _self-certifying identifier (SCID)_ ||KERI||||UIT||||SCPK||||SFS||||SCPN||||SCURL||||PKI||.
+
+A major flaw in the original design of the Internet Protocol was that it has no security layer(s) (i.e. Session or Presentation layers) to provide interoperable verifiable authenticity ||RFC0791||. There was no built-in mechanism for secure attribution to the source of a packet. Specifically, the IP packet header includes a source address field that indicates the IP address of the device that sent the packet. Anyone (including any intermediary) can forge an IP (Internet Protocol) packet. Because the source address of such a packet can be undetectably forged, a recipient may not be able to ascertain when or if the packet was sent by an imposter. This means that secure attribution mechanisms for the Internet must be overlaid (bolted-on). KERI provides such a security overlay. We describe it as an identifier system security overlay.
+
+The KERI identifier system overlay leverages the properties of cryptonymous **_self-certifying identifiers_** (SCIDs) which are based on asymmetric public-key cryptography (PKI) to provide end-verifiable secure attribution of any message or data item without needing to trust in any intermediary ||PKI||||KERI||||UIT||||SCPK||||SFS||||SCPN||||SCURL||. A self-certifying identifier (SCID) is uniquely cryptographically derived from the public key of an asymmetric keypair, `(public, private)`. It is self-certifying in the sense that does not rely on a trusted entity. 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. A basic SCID is _ephemeral_ i.e. it does not support rotation 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. The class of identifiers that generalize SCIDs with enhanced properties such as persistence is called _autonomic identifiers_ (AIDs).
+
+A Key Event Log (KEL) gives rise to an enhanced class of SCIDs that are persistent, not ephemeral, because their keys may be refreshed or updated via rotation allowing secure control over the identifier in spite of key weakness or even compromise. This family of generalized enhanced SCIDs we call **_autonomic identifiers_** (AIDs). _Autonomic_ means self-governing, self-regulating, or self-managing and is evocative of the self-certifying, self-managing properties of this class of identifier.
+
+An important innovation of KERI is that it solves the key rotation problem of PKI (including that of simple self-certifying identifiers) via a novel but elegant mechanism we call **_key pre-rotation_** ||DAD||||KERI||. This _pre-rotation_ mechanism enables an entity to persistently maintain or regain control over an identifier in spite of the exposure-related weakening over time or even compromise of the current set of controlling (signing) keypairs. With key pre-rotation, control over the identifier can be re-established by rotating to a one-time use set of unexposed but pre-committed rotation keypairs that then become the current signing keypairs. Each rotation in turn cryptographically commits to a new set of rotation keys but without exposing them. Because the pre-rotated keypairs need never be exposed prior to their one-time use, their attack surface may be optimally minimized. The current key-state is maintained via an append-only **_verifiable data structure_** we call a **_key event log_** (KEL).
+
+A **_cryptographic primitive_** is a 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 cryptographic primitives in KERI MUST be expressed using the CESR (Compact Event Streaming Representation) protocol ||CESRID||. CESR supports round trip lossless conversion between its text, binary, and raw domain representations and lossless composability between its text and binary domain representations. Composability is ensured between any concatenated group of text primitives and the binary equivalent of that group because all CESR primitives are aligned on 24-bit boundaries. Both the text and binary domain representations are serializations suitable for transmission over the wire. The text domain representation is also suitable to be embedded as a string value of a field or array element as part of a field map serialization such as JSON, CBOR, or MsgPack ||RFC8259||||JSOND||||RFC8949||||CBORC||||MGPK||. The text domain uses the set of characters from the URL-safe variant of Base64 which in turn is a subset of the ASCII character set ||RFC4648||||RFC0020||. For the sake of readability, all examples in this specification will be expressed in CESR's text-domain.
+
+When _qualified_, a cryptographic primitive includes a prepended derivation code (as a proem) 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. Qualification is an essential property of CESR ||CESRID||. The CESR protocol supports several different types of encoding tables for different types of derivation codes. These tables include very compact codes. For example, a 256-bit (32-byte) digest using the BLAKE3 digest algorithm, i.e. Blake3-256, when expressed in text-domain CESR is 44 Base64 characters long and begins with the one character derivation code `E`, such as, `EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug` ||BLAKE3||||BLAKE3Spec||||BLAKE3Hash||. The equivalent _qualified_ binary domain representation is 33 bytes long. Unless otherwise indicated, all cryptographic primitives in this specification will appear as _qualified_ primitives using text-domain CESR.
+
+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) ||KERI||||VDS||||ESMT||||RT||. The identifier system provides a mapping between the identifier and the keypair(s) that control the identifier, namely, the public key(s) from those keypairs. The private key(s) is secret and is not shared.
+
+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.
+
+There are two major flaws in conventional PKI-based identifier system security overlays (including the Internet's DNS/CA system) ||PKI|| ||DNS|| ||RFC0799|| ||CAA||||CA|| ||RFC5280||.
+
+The _first major_ flaw is that the mapping between the identifier (domain name) and the controlling keypair(s) is merely asserted by a trusted entity e.g. certificate authority (CA) via a certificate. Because the mapping is merely asserted, a verifier can not cryptographically verify the mapping between the identifier and the controlling keypair(s) but must trust the operational processes of the trusted entity making that assertion, i.e. the CA who issued and signed the certificate. As is well known, a successful attack upon those operational processes may fool a verifier into trusting an invalid mapping i.e. the certificate is issued to the wrong keypair(s) albeit with a verifiable signature from a valid certificate authority. ||CEDS||||KDDH||||DNSH||||SFTCA||||DNSP||||BGPC||||BBGP||. Noteworthy is that the signature on the certificate is NOT made with the controlling keypairs of the identifier but made with keypairs controlled by the issuer i.e. the CA. The fact that the certificate is signed by the CA means that the mapping itself is not verifiable but merely that the CA asserted the mapping between keypair(s) and identifier. The certificate merely provides evidence of the authenticity of the assignment of the mapping but not evidence of the veracity of the mapping.
+
+The _second major flaw_ is that when rotating the valid signing keys there is no cryptographically verifiable way to link the new (rotated in) controlling/signing key(s) to the prior (rotated out) controlling/signing key(s). Key rotation is merely implicitly asserted by a trusted entity (CA) by issuing a new certificate with new controlling/signing keys. Key rotation is necessary because over time the controlling keypair(s) of an identifier becomes weak due to exposure when used to sign messages and must be replaced. An explicit rotation mechanism first revokes the old keys and then replaces them with new keys. Even a certificate revocation list (CRL) as per RFC5280, with an online status protocol (OCSP) registration as per RFC6960, does not provide a cryptographically verifiable connection between the old and new keys, it is merely asserted ||RFC5280||||RFC6960||||OCSPW||. The lack of a single universal CRL or registry means that multiple potential replacements may be valid. From a cryptographic verifiability perspective, rotation by assertion with a new certificate that either implicitly or explicitly provides revocation and replacement is essentially the same as starting over by creating a brand new independent mapping between a given identifier and the controlling keypair(s). This start-over style of key rotation may well be one of the main reasons that PGP's web-of-trust failed ||WOT||. Without a universally verifiable revocation mechanism, then any rotation (revocation and replacement) assertions either explicit or implicit are mutually independent of each other. This lack of universal cryptographic verifiability of a rotation fosters ambiguity at any point in time as to the actual valid mapping between the identifier and its controlling keypair(s). In other words, for a given identifier, any or all assertions made by some set of CAs may be potentially valid.
+
+We call the state of the controlling keys for an identifier at any time the key state. Cryptographic verifiability of the key state over time is essential to remove this ambiguity. Without this verifiability, the detection of potential ambiguity requires yet another bolt-on security overlay such as the certificate transparency system ||CTE||||CTAOL||||RFC6962||||RT||||VDS||||ESMT||.
+
+The KERI protocol fixes both of these flaws using a combination of **_autonomic identifiers_**, **_key pre-rotation_**, a **_verifiable data structure_** (VDS) called a KEL as verifiable proof of key-state, and **_duplicity-evident_** mechanisms for evaluating and reconciling key state by validators ||KERI||. Unlike certificate transparency, KERI enables the detection of duplicity in the key state via non-repudiable cryptographic proofs of duplicity not merely the detection of inconsistency in the key state that may or may not be duplicitous ||KERI||||CTAOL||.
+
+In simple form an identifier-system security-overlay binds together a triad consisting of the **_identifier_**, **_keypairs_**, and **_controllers_**. By **_identifier_** we mean some string of characters. By **_keypairs_** we mean a set of asymmetric (public, private) cryptographic keypairs used to create and verify non-repudiable digital signatures. By **_controllers_** we mean the set of entities whose members each control a private key from the given set of **_keypairs_**. When those bindings are strong then the overlay is highly _invulnerable_ to attack. In contrast, when those bindings are weak then the overlay is highly _vulnerable_ to attack. The bindings for a given identifier form a _triad_ that binds together the set of _controllers_, the set of _keypairs_, and the _identifier_. To reiterate, the set of controllers is bound to the set of keypairs, the set of keypairs is bound to the identifier, and the identifier is bound to the set of controllers. This binding triad can be diagrammed as a triangle where the sides are the bindings and the vertices are the _identifier_, the set of _controllers_, and the set of _keypairs_. This triad provides verifiable **_control authority_** for the identifier.
+
+With KERI all the bindings of the triad are strong because they are cryptographically verifiable with a minimum cryptographic strength or level of approximately 128 bits. See the Appendix on cryptographic strength for more detail.
+
+The bound triad is created as follows:
+
+-   Each controller in the set of controllers creates an asymmetric `(pubic, private)` keypair. The public key is derived from the private key or seed using a one-way derivation that MUST have a minimum cryptographic strength of approximately 128 bits ||OWF||||COWF||. Depending on the crypto-suite used to derive a keypair the private key or seed may itself have a length larger than 128 bits. A controller may use a cryptographic strength pseudo-random number generator (CSPRNG) ||CSPRNG|| to create the private key or seed material. Because the private key material must be kept secret, typically in a secure data store, the management of those secrets may be an important consideration. One approach to minimize the size of secrets is to create private keys or seeds from a secret salt. The salt MUST have an entropy of approximately 128 bits. The salt may then be stretched to meet the length requirements for the crypto suite's private key size ||Salt||||Stretch||. In addition, a hierarchical deterministic derivation function may be used to further minimize storage requirements by leveraging a single salt for a set or sequence of private keys ||HDKC||. Because each controller is the only entity in control (custody) of the private key, and the public key is universally uniquely derived from the private key using a cryptographic strength one-way function, then the binding between each controller and their keypair is as strong as the ability of the controller to keep that key private ||OWF||||COWF||. The degree of protection is up to each controller to determine. For example, a controller could choose to store their private key in a safe, at the bottom of a coal mine, air-gapped from any network, with an ex-special forces team of guards. Or the controller could choose to store it in an encrypted data store (key chain) on a secure boot mobile device with a biometric lock, or simply write it on a piece of paper and store it in a safe place. The important point is that the strength of the binding between controller and keypair does not need to be dependent on any trusted entity.
+
+-   The identifier is universally uniquely derived from the set of public keys using a one-way derivation function ||OWF||||COWF||. It is therefore an AID (qualified SCID). Associated with each identifier (AID) is incepting information that MUST include a list of the set of _qualified_ public keys from the controlling keypairs. In the usual case, the identifier is a _qualified_ cryptographic digest of the serialization of all the incepting information for the identifier. Any change to even one bit of the incepting information changes the digest and hence changes the derived identifier. This includes any change to any one of the qualified public keys including its qualifying derivation code. To clarify, a _qualified_ digest as identifier includes a derivation code as proem that indicates the cryptographic algorithm used for the digest. Thus a different digest algorithm results in a different identifier. In this usual case, the identifier is strongly cryptographically bound to not only the public keys but also any other incepting information from which the digest was generated.
+
+
+A special case may arise when the set of public keys has only one member, i.e. there is only one controlling keypair. In this case, the controller of the identifier may choose to use only the _qualified_ public key as the identifier instead of a _qualified_ digest of the incepting information. In this case, the identifier is still strongly bound to the public key but is not so strongly bound to any other incepting information. A variant of this single keypair special case is an identifier that can not be rotated. Another way of describing an identifier that cannot be rotated is that it is a _non-transferable_ identifier because control over the identifier cannot be transferred to a different set of controlling keypairs. Whereas a rotatable keypair is _transferable_ because control may be transferred via rotation to a new set of keypairs. Essentially, when non-transferable, the identifier's lifespan is _ephemeral_, not _persistent_, because any weakening or compromise of the controlling keypair means that the identifier must be abandoned. Nonetheless, there are important use cases for an _ephemeral_ self-certifying identifier. In all cases, the derivation code in the identifier indicates the type of identifier, whether it be a digest of the incepting information (multiple or single keypair) or a single member special case derived from only the public key (both ephemeral or persistent).
+
+-   Each controller in a set of controllers is may prove its contribution to the control authority over the identifier in either an interactive or non-interactive fashion. One form of interactive proof is to satisfy a challenge of that control. The challenger creates a unique challenge message. The controller responds by non-repudiably signing that challenge with the private key from the keypair under its control. The challenger can then cryptographically verify the signature using the public key from the controller's keypair. One form of non-interactive proof is to periodically contribute to a monotonically increasing sequence of non-repudiably signed updates of some data item. Each update includes a monotonically increasing sequence number or date-time stamp. Any observer can then cryptographically verify the signature using the public key from the controller's keypair and verify that the update was made by the controller. In general, only members of the set of controllers can create verifiable non-repudiable signatures using their keypairs. Consequently, the identifier is strongly bound to the set of controllers via provable control over the keypairs.
+
+\*\*\* Tetrad Bindings
+
+At inception, the triad of identifier, keypairs, and controllers are strongly bound together. But in order for those bindings to persist after a key rotation, another mechanism is required. That mechanism is a verifiable data structure called a _key event log_ (KEL) ||KERI||||VDS||. The KEL is not necessary for identifiers that are non-transferable and do not need to persist control via key rotation in spite of key weakness or compromise. To reiterate, transferable (persistent) identifiers each need a KEL, non-transferable (ephemeral) identifiers do not.
+
+For persistent (transferable) identifiers, this additional mechanism may be bound to the triad to form a tetrad consisting of the KEL, the identifier, the set of keypairs, and the set of controllers. The first entry in the KEL is called the _inception event_ which is a serialization of the incepting information associated with the identifier mentioned previously.
+
+The _inception event_ MUST include the list of controlling public keys. It MUST also include a signature threshold and MUST be signed by a set of private keys from the controlling keypairs that satisfy that threshold. Additionally, for transferability (persistence across rotation) the _inception event_ MUST also include a list of digests of the set of pre-rotated public keys and a pre-rotated signature threshold that will become the controlling (signing) set of keypairs and threshold after a rotation. A non-transferable identifier MAY have a trivial KEL that only includes an _inception event_ but with a null set (empty list) of pre-rotated public keys.
+
+A rotation is performed by appending to the KEL a _rotation event_. A _rotation event_ MUST include a list of the set of pre-rotated public keys (not their digests) thereby exposing them and MUST be signed by a set of private keys from these newly exposed newly controlling but pre-rotated keypairs that satisfy the pre-rotated threshold. The rotation event MUST also include a list of the digests of a new set of pre-rotated keys as well as the signature threshold for the set of pre-rotated keypairs. At any point in time the transferability of an identifier can be removed via a _rotation event_ that rotates to a null set (empty list) of pre-rotated public keys.
+
+Each event in a KEL MUST include an integer sequence number that is one greater than the previous event. Each event after the inception event MUST also include a cryptographic digest of the previous event. This digest means that a given event is cryptographically bound to the previous event in the sequence. The list of digests or pre-rotated keys in the inception event cryptographically binds the inception event to a subsequent rotation event. Essentially making a forward commitment that forward chains together the events. The only valid rotation event that may follow the inception event must include the pre-rotated keys. But only the controller who created those keys and created the digests may verifiably expose them. Each rotation event in turn makes a forward commitment (chain) to the following rotation event via its list of pre-rotated key digests. This makes the KEL a doubly (backward and forward) hash (digest) chained non-repudiably signed append-only verifiable data structure.
+
+Because the signatures on each event are non-repudiable, the existence of an alternate but verifiable KEL for an identifier is provable evidence of duplicity. In KERI, there may be at most one valid KEL for any identifier or none at all. Any validator of a KEL may enforce this one valid KEL rule before relying on the KEL as proof of the current key state for the identifier. This protects the validator. Any unreconcilable evidence of duplicity means the validator does not trust (rely on) any KEL to provide the key state for the identifier. Rules for handling reconciliable duplicity will be discussed later. From a validator's perspective, either there is one-and-only-one valid KEL or none at all. This protects the validator. This policy removes any potential ambiguity about key state. The combination of a verifiable KEL made from non-repudiably signed backward and forward hash chained events together with the only-one-valid KEL rule strongly binds the identifier to its current key-state as given by that one valid KEL or not at all. This in turn binds the identifier to the controllers of the current keypairs given by the KEL thus completing the tetrad.
+
+At inception, the KEL may be even more strongly bound to its tetrad by deriving the identifier from a digest of the _inception event_. Thereby even one change in not only the original controlling keys pairs but also the pre-rotated keypairs or any other incepting information included in the _inception event_ will result in a different identifier.
+
+The essense of the KERI protocol is a strongly bound tetrad of identifier, keypairs, controllers, and key event log that forms the basis of its identifier system security overlay. The KERI protocol introduces the concept of duplicity evident programming via duplicity evident verifiable data structures. The full detailed exposition of the protocol is provided in the following sections.
+
+# Basic Terminology
+
+Several new terms were introduced above. These along with other terms helpful to describing KERI are defined below.
+
+Primitive : A serialization of a unitary value. A _cryptographic primitive_ 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 (Compact Event Streaming Representation) ||CESRID||.
+
+Qualified : When _qualified_, a _cryptographic primitive_ includes a prepended derivation code (as a proem) 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 ||CESRID||. Qualification is an essential property of CESR ||CESRID||.
+
+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 cryptogrphic function with a sufficiently high degree of cryptographic strength (e.g. 128 bits, see appendix on cryptographic strength) ||OWF||||COWF||||TMCrypto||||QCHC||. A _cryptonym_ is a type of _primitive_. Due the enctropy in its derivation, a _cryptonym_ is a universally unique identifier and only the controller of the secret salt or seed 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.
+
+SCID : Self-Certifying IDentifier. A self-certifying identifier (SCID) is a type of cryptonym 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 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_ i.e. it does not support rotation 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 ||PKI||||KERI||||UIT||||SCPK||||SFS||||SCPN||||SCURL||||PKI||.
+
+AID : Autonomic IDentifier. A self-managing _cryptonymous_ identifier that MUST be self-certifying (self-authenticating) and MUST be encoded in CESR as a _qualified_ cryptographic primitive. An AID MAY exhibit other self-managing properties such as transferable control using key _pre-rotation_ which enables control over such an AID to persist in spite of key weakness or compromise due to exposure. Authoritative control over the identifier persists in spite of the evolution of the key-state.
+
+Key State : Includes the set of currently authoritative keypairs for an AID and any other information necessary to secure or establish control authority over an AID.
+
+Key Event : Concretely, the serialized data structure of an entry in the key event log 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 key event log actualized by a particular entry.
+
+Establishment Event : Key Event that establishes or changes the key-state which includes the current set of authoritative keypairs (key-state) for an AID.
+
+Non-establishment Event : 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.
+
+Inception Event : Establishment Event that provides the incepting information needed to derive an AID and establish its initial key-state.
+
+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.
+
+Rotation Event : Establishment Event that provides the information needed to change the key-state which includes a change to the set of authoritative keypairs for an AID.
+
+Rotation : The operation of revoking and replacing the set of authoritative keypairs for an AID. This operation is made verifiable and duplicity evident upon acceptance as a _rotation event_ that is appended to the AID's KEL.
+
+Interaction Event : Non-establishment Event that anchors external data to the key-state as established by the most recent prior establishment event.
+
+KEL : 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.
+
+Version : 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.
+
+Verifiable : 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.
+
+Duplicity : Means the existence of more than one version of a verifiable KEL for a given AID. Because every event in a KEL must be signed with non-repudiable signatures any inconsistency between any two instances of the KEL for a given AID is provable evidence of duplicity on the part of the signers with respect to either or both the key-state of that AID and/or any anchored data at a given key-state. A shorter KEL that does not differ in any of its events with respect to another but longer KEL is not duplicitous but merely incomplete. To clarify, duplicity evident means that duplicity is provable via the presentation of a set of two or more mutually inconsistent but independently verifiable instances of a KEL.
+
+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.
+
+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. 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.
+
+Message : 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.
+
+Key Event Message : Message whose body is a key event and whose attachments may include signatures on its body.
+
+Key Event Receipt : Message whose body references a key event and whose attachments MUST include one or more signatures on that key event.
+
+# Keypair Labeling Convention
+
+In order to make key event expressions both clearer and more concise, we use a keypair labeling convention. When an AID's key state is dynamic, i.e. the set of controlling keypairs is transferable, then the keypair labels are indexed in order to represent the successive sets of keypairs that constitute the key state at any position in the KEL (key event log). To elaborate, we use indexes on the labels for AIDs that are transferable to indicate which set of keypairs is associated with the AID at any given point in its key state or KEL. In contrast, when the key state is static, i.e. the set of controlling keypairs is non-transferable then no indexes are needed because the key state never changes.
+
+Recall that, a keypair is a two tuple, _(public, private)_, of the respective public and private keys in the keypair. For a given AID, the labeling convention uses an uppercase letter label to represent that AID. When the key state is dynamic, a superscripted index on that letter is used to indicate which keypair is used at a given key state. Alternatively, the index may be omitted when the context defines which keypair and which key state, such as, for example, the latest or current key state. To reiterate, when the key state is static no index is needed.
+
+In general, without loss of specificity, we use an uppercase letter label to represent both an AID and when indexed to represent its keypair or keypairs that are authoritative at a given key state for that AID. In addition, when expressed in tuple form the uppercase letter also represents the public key and the lowercase letter represents the private key for a given keypair. For example, let _A_ denote and AID, then let_A_ also denote a keypair which may be also expressed in tuple form as _(A, a)_. Therefore, when referring to the keypair itself as a pair and not the individual members of the pair, either the uppercase label, _A_, or the tuple, _(A, a)_, may be used to refer to the keypair itself. When referring to the individual members of the keypair then the uppercase letter, _A_, refers to the public key, and the lowercase letter, _a_, refers to the private key.
+
+Let the sequence of keypairs that are authoritative (i.e establish control authority) for an AID be indexed by the zero-based integer-valued, strictly increasing by one, variable _i_. Furthermore, as described above, an establishment key event may change the key state. Let the sequence of establishment events be indexed by the zero-based integer-valued, strictly increasing by one, variable _j_. When the set of controlling keypairs that are authoritative for a given key state includes only one member, then _i = j_ for every keypair, and only one index is needed. But when the set of keypairs used at any time for a given key state includes more than one member, then _i != j_ for every keypair, and both indices are needed.
+
+In the former case, where only one index is needed because _i = j_, let the indexed keypair for AID, _A_, be denoted by _Ai_ or in tuple form by _(Ai, ai)_ where the keypair so indexed uses the _ith_ keypair from the sequence of all keypairs. The keypair sequence may be expressed as the list, _\[A0, A1, A2, ...\]_. The zero element in this sequence is denoted by _A0_ or in tuple form by _(A0, a0)_.
+
+In the latter case, where both indices are needed because _i != j_, let the indexed keypair for AID, _A_, be denoted by _Ai,j_ or in tuple form by _(Ai,j, ai,j)_ where the keypair so indexed is authoritative or potentially authoritative for _ith_ keypair from the sequence of all keypairs that is authoritative in the the _jth_ key state. Suppose, for example, that for a given AID labeled _A_ each key state uses three keypairs to establish control authority, then the sequence of the first two key states will consume the first six keypairs as given by the following list, _\[A0,0, A1,0, A2,0, A3,1, A4,1, A5,1\]_.
+
+Furthermore, with pre-rotation, each public key from the set of pre-rotated keypairs may be hidden as a qualified cryptographic digest of that public key. The digest of the public key labeled _A_ is represented using the functional notation _H(A)_ for hash (digest). When singly indexed, the digest of _Ai_ is denoted by _H(Ai)_ and when doubly indexed the digest of _Ai,j_ is denoted by _H(Ai,j)_. A pre-rotated keypair is potentially authoritative for the next or subsequent establishment event after the establishment event when the digest of the pre-rotated keypair first appears. Therefore its _jth_ index value is one greater than the _jth_ index value of the establishment event in which its digest first appears. As explained in more detail below, for partial rotation of a pre-rotated set, a pre-rotated keypair from a set of two or more pre-rotated keypairs is only potentially authoritative so that its actual authoritative _jth_ index may change when it is actually rotated in if ever.
+
+Finally, each key event in a KEL MUST have a zero-based integer-valued, strictly increasing by one, sequence number. Abstractly we may use the variable _k_ as an index on any keypair label to denote the sequence number of an event for which that keypair is authoritative. Usually, this appears as a subscript. Thus any given keypair label could have three indices, namely, _i,j,k_ that appear as follows, _Ai,jk_ where _i_ denotes the _ith_ keypair from the sequence of all keypairs, _j_ denotes the \*jth establishment event in which the keypair is authoritative, and _k_ represents the _kth_ key event in which the keypair is authoritative. When a KEL has only establishment events then _j = k_.
+
+# Pre-rotation Detail
+
+Each establishment event involves two sets of keys that each play a role that together establishes complete control authority over the AID associated at the location of that event in the KEL. To clarify, control authority is split between keypairs that hold signing authority and keypairs that hold rotation authority. A rotation revodes and replaces the keypairs that hold signing authority as well as replacing the keypairs that hold rotation authority. The two set sets of keys are labeled _current_ and _next_. Each establishment event designates both sets of keypairs. The first (_current_) set consists of the authoritative signing keypairs bound to the AID at the location in the KEL where the establishment event occurs. The second (_next_) set consists of the pre-rotated authoritative rotation keypairs that will be actualized in the next (ensuing) establishment event. Each public key in the set of next (ensuing) pre-rotated public keys is hidden in or blinded by a digest of that key. When the establishment event is the inception event then the _current_ set is the _initial_ set. The pre-rotated _next_ set of Rotation keypairs are one-time use only rotation keypairs, but MAY be repurposed as signing keypairs after their one time use to rotate.
+
+In addition, each establishment event designates two threshold expressions, one for each set of keypairs (_current_ and _next_). The _current_ threshold determines the needed satisficing subset of signatures from the associated _current_ set of keypairs for signing authority to be considered valid. The _next_ threshold determines the needed satisficing subset of signatures from the associated _next_ set of hidden keypairs for rotation authority to be considered valid. The simplest type of threshold expression for either threshold is an integer that is no greater than nor no less than the number of members in the set. An integer threshold acts as an _M of N_ threshold where _M_ is the threshold and _N_ is the total number of keypairs represented by the public keys in the key list. If any set of _M_ of the _N_ private keys belonging to the public keys in the key list verifiably signs the event then the threshold is satisfied for the control authority role (signing or rotation) associated with the given key list and threshold .
+
+To clarify, each establishment event MUST include a list (ordered) of the qualified public keys from each of the current (initial) set of keypairs), a threshold for the current set, a list (ordered) of the qualified cryptographic digests of the qualified public keys from the next set of keypairs, and a threshold for the next set. Each event MUST also include the AID itself as either a qualified public key or a qualified digest of the inception establishment event.
+
+Each non-establishment event MUST be signed by a threshold-satisficing subset of private keys from the _current_ set of keypairs from the most recent establishment event. A little more explanation is needed to understand the requirements for a valid set of signatures for each type of establishment event.
+
+The creator of the inception event MUST create two sets of keypairs, the _current_ (_initial_) set, and the _next_ set. The private keys from the current set are kept as secrets. The public keys from the _current_ set are exposed via inclusion in the inception event. Both the public and private keys from the _next_ set are kept as secrets and only the cryptographic digests of the public keys from the _next_ set are exposed via inclusion in the event. The public keys from the _next_ set are only exposed in a subsequent establishment if any. Both thresholds are exposed via inclusion in the event.
+
+Upon emittance of the inception event, the _current_ (_initial_) set of keypairs becomes the current set of verifiable authoritative signing keypairs for the identifier. Emittance of the inception event also issues the identifier. Moreover, to be verifiably authoritative, the inception event must be signed by a threshold satisficing subset of the _current_ (_initial_) set of private keys. The inception event may be verified against the attached signatures using the included _current_ (_initial_) list of public keys. When self-addressing, a digest of the serialization of the inception event provides the AID itself as derived by the SAID protocol ||SAIDID||.
+
+There MUST be only one inception establishment event. All subsequent establishment events MUST be rotation events.
+
+Unlike inception, the creator of a rotation event MUST create only one set of keypairs, the newly _next_ set. Both the public and private keys from the newly _next_ set are kept as secrets and only the cryptographic digests of the public keys from the newly _next_ set are exposed via inclusion in the event. The list of newly _current_ public keys MUST include the an old _next_ threshold satisficing subset of old _next_ public keys from the most recent prior establishment event. 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. The subset of old _prior next_ keys that are included in the newly current set of public keys MUST be unhidden or unblinded because they appear as the public keys themselves and no longer appear as digests of the public keys. Both thresholds are exposed via inclusion in the event.
+
+Upon emittance of the rotation event, the newly _current_ keypairs become the _current_ set of verifiable authoritative signing keypairs for the identifier. The old _current_ set of keypairs from the previous establishment event has been revoked and replaced by the newly _current_ set. Moreover, to be verifiably authoritative, the rotation event must be signed by a dual threshold satisficing subset of the newly _current_ set of private keys. To elaborate, the set of signatures on a rotation event MUST satisfy two thresholds. These are the newly _current_ threshold and the old _prior next_ threshold from the most recent prior establishment event. Therefore the newly _current_ set of public keys must include a satisfiable subset with respect to the old _prior next_ threshold of public keys from the old _prior next_ key list. The included newly _current_ list of public keys enables verification of the rotation event against the attached signatures.
+
+The act of inclusion in each establishment event of the digests of the new _next_ set of public keys performs a pre-rotation operation on that set by making a verifiable forward blinded commitment to that set. Consequently, no other set may be used to satisfy the threshold for the _next_ rotation operation. Because the _next_ set of pre-rotated keys is blinded (i.e. has not been exposed i.e. used to sign or even published) an attacker can't forge and sign a verifiable rotation operation without first unblinding the pre-rotated keys. Therefore, given sufficient cryptographic strength of the digests, the only attack surface available to the adversary is a side-channel attack on the private key store itself and not on signing infrastructure. But the creator of the pre-rotated private keys is free to make that key store as arbitrarily secure as needed because the pre-rotated keys are not used for signing until the next rotation. In other words, as long as the creator keeps secret the pre-rotated public keys themselves, an attacker must attack the key storage infrastructure because side-channel attacks on signing infrastructure are obviated.
+
+As explained later, for a validator, the first seen rule applies, that is, the first seen version of an event is the authoritative one for that validator. The first seen wins. In other words the first published becomes the first seen. Upon rotation, the old prior _next_ keys are exposed but only after a new _next_ set has been created and stored. Thus the creator is always able to stay one step ahead of an attacker. By the time a new rotation event is published, it is too late for an attacker to create a verifiable rotation event to supplant it because the orginal version has already been published and may be first seen by the validator. The window for an attacker is the network latency for the first published event to be first seen by the network of validators. Any later key compromise is too late.
+
+In essence, each key set follows a rotation lifecycle where it changes its role with each rotation event. A pre-rotated keypair set starts as the member of the _next_ key set holding one-time rotation control authority. On the ensuing rotation that keypair becomes part of the the _current_ key set holding signing control authority. Finally on the following rotation that keypair is discarded. The lifecycle for the initial key set in an inception event is slightly different. The initial key set starts as the _current_ set holding signing authority and is discarded on the ensuing rotation event if any.
+
+Recall that the keypairs for a given AID may be represented by the indexed letter label such as _Ai,jk_ where _i_ denotes the _ith_ keypair from the sequence of all keypairs, _j_ denotes the \*jth establishment event in which the keypair is authoritative, and _k_ represents the _kth_ key event in which the keypair is authoritative. When a KEL has only establishment events then _j = k_. When only one keypair is authoritative at any given key state then _i = j_.
+
+Also, recall that a pre-rotated keypair is designated by the digest of its public key appearing in an establishment event. The digest is denoted as _H(A)_ or _H(Ai,jk)_ in indexed form. The appearance of the digest makes a forward verifiable cryptographic commitment that may be realized in the future when and if that public key is exposed and listed as a current authoritative signing key in a subsequent establishment event.
+
+The following example illustrates the lifecycle roles of the key sets drawn from a sequence of keys used for three establishment events; one inception followed by two rotations. The initial number of authoritative keypairs is three and then changes to two and then changes back to three.
+
+| Event | Current Keypairs | CT | Next Keypairs | NT |
+| --- | --- | --- | --- | --- |
+
+| 0 | _\[A0,0, A1,0, A2,0\]_ | 2 | _\[H(A3,1), H(A4,1)\]_ | 1 |
+| 1 | _\[A3,1, A4,1\]_ | 1 | _\[H(A5,2), H(A6,2), H(A7,2)\]_ | 2 |
+| 2 | _\[A5,2, A6,2, A7,2\]_ | 2 | _\[H(A8,3), H(A9,3), H(A10,3\]_ | 2 |
+
+-   _CTH_ means Current Threshold.
+
+-   _NTH_ means Next Threshold.
+
+
+The pre-rotation mechanism supports partial pre-rotation or more exactly partial rotation of pre-rotated keypairs. One important use case for partial rotation is to enable pre-rotated keypairs designated in one establishment event to be held in reserve and not exposed at the next (immediately subsequent) establishment event. This reserve feature enables keypairs held by controllers as members of a set of pre-rotated keypairs to be used for the purpose of fault tolerance in the case of non-availability by other controllers while at the same time minimizing the burden of participation by the reserve members. In other words, a reserved pre-rotated keypair contributes to the potential availability and fault tolerance of control authority over the AID without necessarily requiring the participation of the reserve key-pair in a rotation until and unless it is needed to provide continuity of control authority in the event of a fault (non-availability of a non-reserved member). This reserve feature enables different classes of key controllers to contribute to the control authority over an AID. This enables provisional key control authority. For example, a key custodial service or key escrow service could hold a keypair in reserve to be used only upon satisfaction of the terms of the escrow agreement. This could be used to provide continuity of service in the case of some failure event. Provisional control authority may be used to prevent types of common-mode failures without burdening the provisional participants in the normal non-failure use cases.
+
+Partial pre-rotation supports another important use case that of custodial key rotation. Because control authority is split between two key sets, the first for signing authority and the second (pre-roateted) for rotation authority the associated thresholds and key list can be structured in such a way that a designated custodial agent can hold signing authority while the original controller can hold exclusive rotation authority. The holder of the rotation authority can then at any time without the cooperation of the custodial agent if need be revoke the agent's signing authority and assign it so some other agent or return that authority to itself.
+
+This partial rotation feature for either reserve or custodial rotation authority is best employed with thresholds that are fractionally weighted. The exact syntax for fractionally weighted thresholds is provided later, but for the sake of explanation of partial pre-rotation, a summary is provided here. A fractionally weighted threshold consists of a list of one or more clauses where each clause is itself a list of legal rational fractions ( i.e. ratios of non-negative integers expressed as fractions, zero is not allowed in the denominator). Each entry in each clause in the fractional weight list corresponds one-to-one to a public key appearing in a key list in an establishment event. Key lists order a key set. A weight list of clauses orders a set of rational fraction weights. Satisfaction of a fractionally weighted threshold requires satisfaction of each and every clause in the list. In other words, the clauses are logically ANDed together. Satisfaction of any clause requires that the sum of the weights in that clause that correspond to verified signatures on that event must sum to at least one. Using rational fractions and rational fraction summation avoids the problem of floating-point rounding errors and ensures exactness and universality of threshold satisfaction computations.
+
+For example, consider the following simple single clause fractionally weighted threshold, _\[1/2, 1/2, 1/2\]_. Three weights mean there MUST be exactly three corresponding key pairs. Let the three keypairs in one-to-one order be denoted by the list of indexed public keys, _\[A0, A1, A2\]. The threshold is satisfied if any two of the public keys sign because _1/2 + 1/2 = 1_. This is exactly equivalent to an integer-valued_2 of 3\* threshold.
+
+The order of appearance of the public key in a given key list and its associated threshold weight list MUST be the same.
+
+Fractionally weighted thresholds become more interesting when the weights are not all equal or include multiple clauses. Consider the following five-element single clause fractionally weighted threshold list, _\[1/2, 1/2, 1/2, 1/4, 1/4\]_ and its corresponding public key list, \*\[A0, A1, A2, A3, A4\]. Satisfaction would be met given signatures from any two or more of A0, A1, or A2 because each of these keys has a weight of 1/2 and the combination of any two or more sums to 1 or more. Alternatively, satisfaction would be met with signatures from any one or more of A0, A1, or A2 and both of A3, and A4 because any of those combinations would sum to 1 or more. Because participation of A3 and A4 is not required as long as at least two of A0, A1, and A2 are available then A3 and A4 may be treated as reserve members of the controlling set of keys. These reserve members only need to participate in the unfortunate event that only one of the other three is available. The flexibility of a fractionally weighted threshold enables redundancy in the combinations of keys needed to satisfice for both day-to-day and reserve contingency use cases.
+
+Defined herein is a detailed description of the pre-rotation protocol. This protocol includes support for _partial pre-rotation_ i.e. 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.
+
+As described above, a valid **_rotation_** operation requires the satisfaction of two different thresholds. These are the _current_ threshold of the given rotation (establishment) 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 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 precisely, any rotation event's _current_ public key list MUST include a satisfiable subset of the _prior next_ key list with respect to the _prior next_ threshold. In addition, any rotation event's _current_ public key list MUST include a satisfiable set of public keys with respect to its _current_ threshold. In other words, the current public key list must be satisfiable with respect to both the _current_ and _prior next_ thresholds.
+
+To reiterate, in order to make verifiable the maintenance of the integrity of the forward commitment to the pre-rotated list of keys made by the _prior next_ event, i.e. provide verifiable rotation control authority, the _current_ key list MUST include a satisfiable subset of exposed (unblinded) pre-rotated next keys from the most recent prior establishment event where satisfiable is with respect to the _prior next_ threshold. Moreover, in order to establish verifiable signing control authority, the _current_ key list MUST also include a satisfiable subset of public keys where satisfiable is with respect to the _current_ threshold.
+
+These two conditions are trivially satisfied whenever the _current_ and _prior next_ key lists and thresholds are equivalent. When both the _current_ and the _prior next_ key lists and thresholds are identical then the validation can be simplified by comparing the two lists and thresholds to confirm that they are identical and then confirming that the signatures satisfy the one threshold with respect to the one key list. When not identical, the validator MUST perform the appropriate set math to confirm compliance.
+
+Recall, that the order of appearance of the public key in a given key list and its associated threshold weight list MUST be the same. The order of appearance, however, of any public keys that appear in both the _current_ and _prior next_ key lists MAY be different between the two key lists and hence the two associated threshold weight lists. A validator MUST therefore confirm that the set of keys in the _current_ key list truly includes a satisfiable subset of the _prior next_ key list and that the _current_ key list is satisfiable with respect to both the _current_ and _prior next_ thresholds. Actual satisfaction means that the set of attached signatures MUST satisfy both the _current_ and _prior next_ thresholds as applied to their respective key lists.
+
+Suppose that the _current_ public key list does not include a proper subset of the _prior next_ key list. This means that no keys were held in reserve. This also means that the current key list is either identical to the prior next key list or is a superset of the prior next key list. Nonetheless, such a rotation MAY change the _current_ key list and or threshold with respect to the _prior next_ key list and/or threshold as long as it meets the satisfiability constraints defined above.
+
+If the _current_ key list includes the full set of keys from the _prior next_ key list then a **_full rotation_** has occurred, not a **_partial rotation_** because no keys were held in reserve or omitted. A _full rotation_ MAY add new keys to the _current_ key list and/or change the current threshold with respect to the _prior next_ key list and threshold.
+
+Provided here is an illustrative example to help to clarify the pre-rotation protocol, especially with regard to and threshold satisfaction for reserve rotation.
+
+| SN | Role | Keys | Threshold |
+| --- | --- | --- | --- |
+
+| 0 | Crnt | _\[A0, A1, A2, A3, A4\]_ | _\[1/2, 1/2, 1/2, 1/4, 1/4\]_ |
+| 0 | Next | _\[H(A5), H(A6), H(A7), H(A8), H(A9)\]_ | _\[1/2, 1/2, 1/2, 1/4, 1/4\]_ |
+| 1 | Crnt | _\[A5, A6, A7\]_ | _\[1/2, 1/2, 1/2\]_ |
+| 1 | Next | _\[H(A10), H(A11), H(A12), H(A8),H(A9)\]_ | _\[1/2, 1/2, 1/2, 1/4, 1/4\]_ |
+| 2 | Crnt | _\[A10, A8, A9\]_ | _\[1/2, 1/2, 1/2\]_ |
+| 2 | Next | _\[H(A13), H(A14), H(A15), H(A16),H(A17)\]_ | _\[1/2, 1/2, 1/2, 1/4, 1/4\]_ |
+| 3 | Crnt | _\[A13, A14, A15\]_ | _\[1/2, 1/2, 1/2\]_ |
+| 3 | Next | _\[H(A18), H(A19), H(A20), H(A16),H(A17)\]_ | _\[1/2, 1/2, 1/2, 1/4, 1/4\]_ |
+| 4 | Crnt | _\[A18, A20, A21\]_ | _\[1/2, 1/2, 1/2\]_ |
+| 4 | Next | _\[H(A22), H(A23), H(A24), H(A16),H(A17)\]_ | _\[1/2, 1/2, 1/2, 1/4, 1/4\]_ |
+| 5 | Crnt | _\[A22, A25, A26, A16, A17\]_ | _\[1/2, 1/2, 1/2, 0, 0\]_ |
+| 5 | Next | _\[H(A27), H(A28), H(A29), H(A30),H(A31)\]_ | _\[1/2, 1/2, 1/2, 1/4, 1/4\]_ |
+
+The meaning of the column labels is as follows:
+
+-   SN is the sequence number of the event. Each event uses two rows in the table.
+-   Role is either Current (Crnt) or Next and indicates the role of the key list and threshold on that row.
+-   Keys is the list of public keys denoted with indexed label of the keypair sequence.
+-   Threshold is the threshold of signatures that must be satisfied for validity.
+
+Commentary of each event follows:
+
+-   (0) Inception: Five keypairs have signing authority and five other keypairs have rotation authority. Any two of the first three or any one of the first three and both the last two are sufficient. This anticipates holding the last two in reserve.
+
+-   (1) Rotation: The first three keypairs from the prior next, A5, A6, and A7, are rotated at the new current signing keypairs. This exposes the keypairs. The last two from the prior next, A8 and A9, are held in reserve. They have not been exposed are included in the next key list.
+
+-   (2) Rotation: The prior next keypairs, A11 and A12 are unavalible to sign the rotation and particpate as the part of the newly current signing keys. Therefore A8 and A9 must be activated (pulled out of reserve) and included and exposed as both one time rotation keys and newly current signing keys. The signing authority (weight) of each of A8 and A9 has been increased to 1/2 from 1/4. This means that any two of the three of A10, A8, and A9 may satisfy the signing threshold. Nonetheless, the rotation event #2 MUST be signed by all three of A10, A8, and A9 in order to satisfy the prior next threshold because in that threshold A8, and A9 only have a weight of 1/4.
+
+-   (3) Rotation: The keypairs H(A16),H(A17 have been held in reserve from event #2
+
+-   (4) Rotation: The keypairs H(A16), H(A17 continue to be held in reserve.
+
+-   (5) Rotation: The keypairs A16, and A17 are pulled out of reserved and exposed in order to perform the rotation because A23, and A24 are unavailable. Two new keypairs, A25, A26, are added to the current signing key list. The current signing authority of A16, and A17 is none because they are assigned a weight of 0 in the new current signing threshold. For the rotation event to be valid it must be signed by A22, A16, and A17 in order to satisfy the prior next threshold for rotation authority and also must be signed by any two of A22, A25, and A26 in order to satisfy the new current signing authority for the event itself. This illustrates how reserved keypairs may be used exclusively for rotation authority and not for signing authority.
+
+
+Provided here is an illustrative example to help to clarify the pre-rotation protocol, especially with regard to threshold satisfaction for custodial rotation.
+
+| SN | Role | Keys | Threshold |
+| --- | --- | --- | --- |
+
+| 0 | Crnt | _\[A0, A1, A2\]_ | _\[1/2, 1/2, 1/2\]_ |
+| 0 | Next | _\[H(A3), H(A4), H(A5)\]_ | _\[1/2, 1/2, 1/2\]_ |
+| 1 | Crnt | _\[A3, A4, A5, A6, A7, A8\]_ | _\[0, 0, 0, 1/2, 1/2, 1/2\]_ |
+| 1 | Next | _\[H(A9), H(A10), H(A11)\]_ | _\[1/2, 1/2, 1/2\]_ |
+| 2 | Crnt | _\[A9, A10, A11, A12, A13, A14\]_ | _\[0, 0, 0, 1/2, 1/2, 1/2\]_ |
+| 2 | Next | _\[H(A15), H(A16), H(A17)\]_ | _\[1/2, 1/2, 1/2\]_ |
+
+The meaning of the column labels is as follows:
+
+-   SN is the sequence number of the event. Each event uses two rows in the table.
+-   Role is either Current (Crnt) or Next and indicates the role of the key list and threshold on that row.
+-   Keys is the list of public keys denoted with indexed label of the keypair sequence.
+-   Threshold is the threshold of signatures that must be satisfied for validity.
+
+Commentary of each event follows:
+
+-   (0) Inception: The private keys from current signing keypairs A0, A1, and A2 are held by the custodian of the identifier. The owner of the identifier provides the digests of the next rotation keypairs, H(A3), H(A4), and H(A5) to the custodian in order that the custodian may include them in the event and then sign the event. The owner holds the private keys from the next rotation keypairs A3, A4, and A5. A self-addressing AID would then be created by the formulation of the inception event. Once formed, the custodian controls the signing authority over the identifier by virtue of holding the associated private keys for the current key list. But the owner controls the rotation authority by virtue of holding the associated private keys for the next key list. Because the controller of the rotation authority may at their sole discretion revoke and replace the keys that hold signing authority, the owner, holder of the next private keys, is ultimately in control of the identifier so constituted by this inception event.
+
+-   (1) Rotation: The owner changes custodians with this event. The new custodian creates new current signing keypairs, A6, A7, and A8 and holds the associated private keys. The new custodian provides the public keys A6, A7, and A8 to the owner so that the owner can formulate and sign the rotation event that transfers signing authority to the new custodian. The owner exposes its rotation public keys, A3, A4, and A5 by including them in the new current key list. But the weights of those rotation keys in the new current signing threshold are all 0 so they have no signing authority. The owner creates a new set of next keypairs and includes their public key digests, H(A9), H(A10), H(A11) in the new next key list. The owner holds the associated private keys and thereby retains rotation authority. This event MUST be signed by any two of A3, A4, and A5 in order to satisfy the prior next threshold and also MUST be signed by any two A6, A7, and A8 in order to satisfy the new current signing threshold. The new current threshold and new next threshold clearly delineate that the new custodian now holds exclusive signing authority and owner continues to retain exclusive rotation authority.
+
+-   (2) Rotation: Change to yet another custodian following the same pattern as event #1
+
+
+# KERI Data Structures
+
+A KERI data structure such as a key event message body 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||||JSOND||||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_. Serialized KERI data structures depend on insertion-ordered field maps for their canonical serialization/deserialization. KERI data structures 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||||JSOND||||CBORC||||RFC8949||||MGPK||||CESRID||. The basic set of normative field labels in KERI field maps is defined in the table in the following section.
+
+| Label | Title | Description | Notes |
+| --- | --- | --- | --- |
+
+| v | Version String |  |  |
+| i | Identifier Prefix (AID) |  |  |
+| s | Sequence Number |  |  |
+| t | Message Type |  |  |
+| te | Last received Event Message Type in a Key State Notice |  |  |
+| d | Event SAID |  |  |
+| p | Prior Event SAID |  |  |
+| kt | Keys Signing Threshold |  |  |
+| k | List of Signing Keys (ordered key set) |  |  |
+| nt | Next Keys Signing Threshold |  |  |
+| n | List of Next Key Digests (ordered key digest set) |  |  |
+| bt | Backer Threshold |  |  |
+| b | List of Backers (ordered backer set of AIDs) |  |  |
+| br | List of Backers to Remove (ordered backer set of AIDS) |  |  |
+| ba | List of Backers to Add (ordered backer set of AIDs) |  |  |
+| c | List of Configuration Traits/Modes |  |  |
+| a | List of Anchors (seals) |  |  |
+| di | Delegator Identifier Prefix (AID) |  |  |
+| rd | Merkle Tree Root Digest (SAID) |  |  |
+| ee | Last Establishment Event Map |  |  |
+| vn | Version Number ("major.minor") |  |  |
+
+A field label may have different values in different contexts but MUST not have a different field value **_type_**. This requirement makes it easier to implement in strongly typed languages with rigid data structures. Notwithstanding the former, some field value types MAY be a union of elemental value types.
+
+Because the order of appearance of fields is enforced in all KERI data structures, whenever a field appears (in a given message or block in a message) the message in which a label appears MUST provide the necessary context to fully determine the meaning of that field and hence the field value type and associated semantics.
+
+The primary field labels are compact in that they use only one or two characters. KERI is 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 KERI field map in which it appears. Typically the version string, `v`, field appears as the first top-level field in a KERI message body. This enables a RegEx stream parser to consistently find the version string in any of the supported serialization formats for KERI messages. The `v` field provides a regular expression target for determining the serialization format and size (character count) of a serialized KERI message body. A stream parser may use the version string to extract and deserialize (deterministically) any serialized KERI message body in a stream of serialized KERI messages. Each KERI message in a stream may use a different serialization type.
+
+The format of the version string is `KERIvvSSSShhhhhh_`. The first four characters `KERI` 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 KERI 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 ||JSOND||||RFC4627||||CBORC||||RFC8949||||MGPK||||CESRID||. The next six characters provide in lowercase hexadecimal notation the total number of characters in the serialization of the KERI message body. The maximum length of a given KERI message body 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 KERI serialization type may use field map delimiters 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 serialization (KERI message body) from the stream without first deserializing it or parsing it field-by-field. This enables performant stream parsing and off-loading of KERI message streams that include any or all of the supported serialization types interleaved in a single stream.
+
+Some fields in KERI data structures may have for their value a SAID. In this context, `d` is short for digest, which is short for Self-Addressing IDentifier (SAID). A SAID follows the SAID protocol ||SAIDID||. 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.
+
+Each SAID provides a stable universal cryptographically verifiable and agile reference to its encapsulating block (serialized _field map_).
+
+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 KERI data structures 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 KERI data structure given by its top-level SAID, `d`, field as well as reasoning about any nested or attached data structures using their SAIDS.
+
+Some fields, such as the `i` and `di` fields, MUST each have an AID (Autonomic IDentifier) as its value. An AID is a fully qualified Self-Certifying IDentifier (SCID) as described above ||KERI||||KERIID||. An AID MUST be self-certifying. In this context, `i` is short for `ai`, which is short for the Autonomic IDentifier (AID). The AID given by the `i` field may also be thought of as a securely attributable identifier, authoritative identifier, authenticatable identifier, authorizing identifier, or authoring identifier.Another way of thinking about an `i` field is that it is the identifier of the authoritative entity to which a statement may be securely attributed, thereby making the statement verifiably authentic via a non-repudiable signature made by that authoritative entity as the Controller of the private key(s).
+
+Because KERI is agnostic about the namespace for any particular AID, different namespace standards may be used to express KERI AIDs within AID fields in an ACDC. The examples below use the W3C DID namespace specification with the `did:keri` method ||DIDKID||. 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).
+
+ToDo Explain agnosticism vis a vis namespaces Because AIDs may be namespaced, the essential component of an AID is the cryptographically derived Controller identifier prefix. An AID MUST be the Controller identifier prefix. part of a W3C Decentralized IDentifier (DID) ||W3C\_DID|| or other namespace convention.
+
+Version string namespaces the AIDs as KERI so don't need any namespacing on a per identifier basis.
+
+Get from ACDC
+
+The `nt` field is next threshold for the next establishment event.
+
+`v` is the version string `d` is the SAID of the enclosing block or map `i` is a KERI identifier AID `a` is the data attributes or data anchors depending on the message type
+
+# Seals
+```
+{
+  "d": "Eabcde..."
+}
+```
+```
+{
+  "rd": "Eabcde8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM"
+}
+```
+```
+{
+  "bi": "BACDEFG8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
+  "d": "EFGKDDA8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM"
+}
+```
+```
+{
+  "i": "Ebietyi8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM.",
+  "s": "3",
+  "d": "Eabcde8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM"
+}
+```
+```
+{
+  "i": "BACDEFG8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM"
+}
+```
+# Key Event Messages (Non-delegated)
+
+Because adding the `d` field SAID to every key event message type will break all the explicit test vectors. Its no additional pain to normalize the field ordering across all message types and seals. Originally all messages included an `i` field but that is not true anymore. So the changed field ordering is to put the fields that are common to all message types first in order followed by fields that are not common. The common fields are `v`, `t`, `d`. The newly revised messages and seals are shown below.
+
+When the AID in the `i` field is a self-addressing self-certifying AID, the new Inception Event has two qualified digest fields. In this case both the `d` and `i` fields must have the same value. This means the digest suite's derivation code, used for the `i` field must be the same for the `d` field. The derivation of the `d` and `i` fields is special. Both the `d` and `i` fields are replaced with dummy `#` characters of the length of the digest to be used. The digest of the Inception event is then computed and both the `d` and `i` fields are replaced with the qualified digest value. Validation of an inception event requires examining the `i` field's derivation code and if it is a digest-type then the `d` field must be identical otherwise the inception event is invalid.
+
+When the AID is not self-addressing, i.e. the `i` field derivation code is not a digest. Then the `i` is given its value and the `d` field is replaced with dummy characters `#` of the correct length and then the digest is computed. This is the standard SAID algorithm.
+```
+{
+  "v": "KERI10JSON0001ac_",
+  "t": "icp",
+  "d": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
+  "i": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
+  "s": "0",
+  "kt": "2", // 2 of 3
+  "k": [
+    "DnmwyZ-i0H3ULvad8JZAoTNZaU6JR2YAfSVPzh5CMzS6b",
+    "DZaU6JR2nmwyZ-VPzhzSslkie8c8TNZaU6J6bVPzhzS6b",
+    "Dd8JZAoTNnmwyZ-i0H3U3ZaU6JR2LvYAfSVPzhzS6b5CM"
+  ],
+  "nt": "3", // 3 of 5
+  "n": [
+    "ETNZH3ULvYawyZ-i0d8JZU6JR2nmAoAfSVPzhzS6b5CM",
+    "EYAfSVPzhzaU6JR2nmoTNZH3ULvwyZb6b5CMi0d8JZAS",
+    "EnmwyZdi0d8JZAoTNZYAfSVPzhzaU6JR2H3ULvS6b5CM",
+    "ETNZH3ULvS6bYAfSVPzhzaU6JR2nmwyZfi0d8JZ5s8bk",
+    "EJR2nmwyZ2i0dzaU6ULvS6b5CM8JZAoTNZH3YAfSVPzh"
+  ],
+  "bt": "2",
+  "b": [
+    "BGKVzj4ve0VSd8z_AmvhLg4lqcC_9WYX90k03q-R_Ydo",
+    "BuyRFMideczFZoapylLIyCjSdhtqVb31wZkRKvPfNqkw",
+    "Bgoq68HCmYNUDgOz4Skvlu306o_NY-NrYuKAVhk3Zh9c"
+  ],
+  "c": [],
+  "a": []
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "rot",
+  "d": "E0d8JJR2nmwyYAfZAoTNZH3ULvaU6Z-iSVPzhzS6b5CM",
+  "i": "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
+  "s": "1",
+  "p": "EULvaU6JR2nmwyZ-i0d8JZAoTNZH3YAfSVPzhzS6b5CM",
+  "kt": "2", // 2 of 3
+  "k": [
+    "DnmwyZ-i0H3ULvad8JZAoTNZaU6JR2YAfSVPzh5CMzS6b",
+    "DZaU6JR2nmwyZ-VPzhzSslkie8c8TNZaU6J6bVPzhzS6b",
+    "Dd8JZAoTNnmwyZ-i0H3U3ZaU6JR2LvYAfSVPzhzS6b5CM"
+  ],
+  "nt": "3", // 3 of 5
+  "n": [
+    "ETNZH3ULvYawyZ-i0d8JZU6JR2nmAoAfSVPzhzS6b5CM",
+    "EYAfSVPzhzaU6JR2nmoTNZH3ULvwyZb6b5CMi0d8JZAS",
+    "EnmwyZdi0d8JZAoTNZYAfSVPzhzaU6JR2H3ULvS6b5CM",
+    "ETNZH3ULvS6bYAfSVPzhzaU6JR2nmwyZfi0d8JZ5s8bk",
+    "EJR2nmwyZ2i0dzaU6ULvS6b5CM8JZAoTNZH3YAfSVPzh"
+  ],
+  "bt": "1",
+  "ba": ["DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM"],
+  "br": ["DH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8TNZJZAo5CM"],
+  "a": []
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "isn",
+  "d": "E0d8JJR2nmwyYAfZAoTNZH3ULvaU6Z-iSVPzhzS6b5CM",
+  "i": "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
+  "s": "2",
+  "p": "EULvaU6JR2nmwyZ-i0d8JZAoTNZH3YAfSVPzhzS6b5CM",
+  "a": [
+    {
+      "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
+      "i": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
+      "s": "1"
+    }
+  ]
+}
+```
+# Delegated Key Event Messages
+
+ToDo in delegation section below. Delegated custodial example with partial rotation and using 0 fraction signing weights on exposed pre-rotated keys
+```
+{
+  "v": "KERI10JSON0001ac_",
+  "t": "icp",
+  "d": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
+  "i": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
+  "s": "0",
+  "kt": "2", // 2 of 3
+  "k": [
+    "DnmwyZ-i0H3ULvad8JZAoTNZaU6JR2YAfSVPzh5CMzS6b",
+    "DZaU6JR2nmwyZ-VPzhzSslkie8c8TNZaU6J6bVPzhzS6b",
+    "Dd8JZAoTNnmwyZ-i0H3U3ZaU6JR2LvYAfSVPzhzS6b5CM"
+  ],
+  "nt": "3", // 3 of 5
+  "n": [
+    "ETNZH3ULvYawyZ-i0d8JZU6JR2nmAoAfSVPzhzS6b5CM",
+    "EYAfSVPzhzaU6JR2nmoTNZH3ULvwyZb6b5CMi0d8JZAS",
+    "EnmwyZdi0d8JZAoTNZYAfSVPzhzaU6JR2H3ULvS6b5CM",
+    "ETNZH3ULvS6bYAfSVPzhzaU6JR2nmwyZfi0d8JZ5s8bk",
+    "EJR2nmwyZ2i0dzaU6ULvS6b5CM8JZAoTNZH3YAfSVPzh"
+  ],
+  "bt": "2",
+  "b": [
+    "BGKVzj4ve0VSd8z_AmvhLg4lqcC_9WYX90k03q-R_Ydo",
+    "BuyRFMideczFZoapylLIyCjSdhtqVb31wZkRKvPfNqkw",
+    "Bgoq68HCmYNUDgOz4Skvlu306o_NY-NrYuKAVhk3Zh9c"
+  ],
+  "c": [],
+  "a": [],
+  "di": "EJJR2nmwyYAZAoTNZH3ULvaU6Z-i0d8fSVPzhzS6b5CM"
+}
+```
+```
+{
+  "v" : "KERI10JSON00011c_",
+  "t" : "drt",
+  "d" : "E0d8JJR2nmwyYAfZAoTNZH3ULvaU6Z-iSVPzhzS6b5CM",
+  "i" : "EZAoTNZH3ULvaU6Z-i0d8JJR2nmwyYAfSVPzhzS6b5CM",
+  "s" : "1",
+  "p" : "EULvaU6JR2nmwyZ-i0d8JZAoTNZH3YAfSVPzhzS6b5CM",
+  "kt": "2", // 2 of 3
+  "k" :
+    [
+      "DnmwyZ-i0H3ULvad8JZAoTNZaU6JR2YAfSVPzh5CMzS6b",
+      "DZaU6JR2nmwyZ-VPzhzSslkie8c8TNZaU6J6bVPzhzS6b",
+      "Dd8JZAoTNnmwyZ-i0H3U3ZaU6JR2LvYAfSVPzhzS6b5CM"
+    ],
+  "nt": "3",  // 3 of 5
+  "n" :
+    [
+      "ETNZH3ULvYawyZ-i0d8JZU6JR2nmAoAfSVPzhzS6b5CM",
+      "EYAfSVPzhzaU6JR2nmoTNZH3ULvwyZb6b5CMi0d8JZAS",
+      "EnmwyZdi0d8JZAoTNZYAfSVPzhzaU6JR2H3ULvS6b5CM",
+      "ETNZH3ULvS6bYAfSVPzhzaU6JR2nmwyZfi0d8JZ5s8bk",
+      "EJR2nmwyZ2i0dzaU6ULvS6b5CM8JZAoTNZH3YAfSVPzh",
+    ],
+  "bt": "1",
+  "ba":  ["DTNZH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8JZAo5CM"],
+  "br":  ["DH3ULvaU6JR2nmwyYAfSVPzhzS6bZ-i0d8TNZJZAo5CM"],
+  "a" :[]
+  "di" : "EJJR2nmwyYAZAoTNZH3ULvaU6Z-i0d8fSVPzhzS6b5CM"
+}
+```
+# Receipt Messages
+
+For receipts, the `d` field is the SAID of the associated event, not the receipt message itself.
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "rct",
+  "d": "DZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
+  "i": "AaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+  "s": "1"
+}
+```
+For receipts, the `d` field is the SAID of the associated event, not the receipt message itself.
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "vrc",
+  "d": "DZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
+  "i": "AaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+  "s": "1",
+  "a": {
+    "d": "DZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
+    "i": "AYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8JZAoTNZH3ULv",
+    "s": "4"
+  }
+}
+```
+# Other Messages
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "qry",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2020-08-22T17:50:12.988921+00:00",
+  "r": "logs",
+  "rr": "log/processor",
+  "q": {
+    "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+    "s": "5",
+    "dt": "2020-08-01T12:20:05.123456+00:00"
+  }
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "qry",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2020-08-22T17:50:12.988921+00:00",
+  "r": "logs",
+  "rr": "log/processor",
+  "q": {
+    "d": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+    "i": "EAoTNZH3ULvYAfSVPzhzS6baU6JR2nmwyZ-i0d8JZ5CM",
+    "s": "5",
+    "dt": "2020-08-01T12:20:05.123456+00:00"
+  }
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "rpy",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2020-08-22T17:50:12.988921+00:00",
+  "r": "logs/processor",
+  "a": {
+    "i": "EAoTNZH3ULvYAfSVPzhzS6baU6JR2nmwyZ-i0d8JZ5CM",
+    "name": "John Jones",
+    "role": "Founder"
+  }
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "rpy",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2020-08-22T17:50:12.988921+00:00",
+  "r": "logs/processor",
+  "a": {
+    "d": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+    "i": "EAoTNZH3ULvYAfSVPzhzS6baU6JR2nmwyZ-i0d8JZ5CM",
+    "name": "John Jones",
+    "role": "Founder"
+  }
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "prd",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "r": "sealed/data",
+  "rr": "process/sealed/data",
+  "q":
+  {
+     d" : "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+    "i" : "EAoTNZH3ULvYAfSVPzhzS6baU6JR2nmwyZ-i0d8JZ5CM",
+    "s" : "5",
+    "ri": "EAoTNZH3ULvYAfSVPzhzS6baU6JR2nmwyZ-i0d8JZ5CM",
+    "dd": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"
+  }
+}
+```
+Reference to the anchoring seal is provided as an attachment to the bare, `bre` message. A bare, 'bre', message is a SAD item with an associated derived SAID in its 'd' field.
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "bre",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "r": "process/sealed/data",
+  "a": {
+    "d": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+    "i": "EAoTNZH3ULvYAfSVPzhzS6baU6JR2nmwyZ-i0d8JZ5CM",
+    "dt": "2020-08-22T17:50:12.988921+00:00",
+    "name": "John Jones",
+    "role": "Founder"
+  }
+}
+```
+```
+{
+  "v": "KERI10JSON00006a_",
+  "t": "exn",
+  "d": "EF3Dd96ATbbMIZgUBBwuFAWx3_8s5XSt_0jeyCRXq_bM",
+  "dt": "2021-11-12T19:11:19.342132+00:00",
+  "r": "/echo",
+  "rr": "/echo/response",
+  "a": {
+    "msg": "test"
+  }
+}
+```
+# Notices Embedded in Reply Messages
+```
+{
+  "v": "KERI10JSON0001d9_",
+  "d": "EYk4PigtRsCd5W2so98c8r8aeRHoixJK7ntv9mTrZPmM",
+  "i": "E4BsxCYUtUx3d6UkDVIQ9Ke3CLQfqWBfICSmjIzkS1u4",
+  "s": "0",
+  "p": "",
+  "f": "0",
+  "dt": "2021-01-01T00:00:00.000000+00:00",
+  "et": "icp",
+  "kt": "1",
+  "k": ["DqI2cOZ06RwGNwCovYUWExmdKU983IasmUKMmZflvWdQ"],
+  "n": "E7FuL3Z_KBgt_QAwuZi1lUFNC69wvyHSxnMFUsKjZHss",
+  "bt": "1",
+  "b": ["BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY"],
+  "c": [],
+  "ee": {
+    "s": "0",
+    "d": "EYk4PigtRsCd5W2so98c8r8aeRHoixJK7ntv9mTrZPmM",
+    "br": [],
+    "ba": []
+  },
+  "di": ""
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "rpy",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2020-08-22T17:50:12.988921+00:00",
+  "r": "/ksn/BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY",
+  "a": {
+    "v": "KERI10JSON0001d9_",
+    "d": "EYk4PigtRsCd5W2so98c8r8aeRHoixJK7ntv9mTrZPmM",
+    "i": "E4BsxCYUtUx3d6UkDVIQ9Ke3CLQfqWBfICSmjIzkS1u4",
+    "s": "0",
+    "p": "",
+    "f": "0",
+    "dt": "2021-01-01T00:00:00.000000+00:00",
+    "et": "icp",
+    "kt": "1",
+    "k": ["DqI2cOZ06RwGNwCovYUWExmdKU983IasmUKMmZflvWdQ"],
+    "n": "E7FuL3Z_KBgt_QAwuZi1lUFNC69wvyHSxnMFUsKjZHss",
+    "bt": "1",
+    "b": ["BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY"],
+    "c": [],
+    "ee": {
+      "s": "0",
+      "d": "EYk4PigtRsCd5W2so98c8r8aeRHoixJK7ntv9mTrZPmM",
+      "br": [],
+      "ba": []
+    },
+    "di": ""
+  }
+}
+```
+```
+{
+  "v": "KERI10JSON0001b0_",
+  "d": "EpltHxeKueSR1a7e0_oSAhgO6U7VDnX7x4KqNCwBqbI0",
+  "i": "EoN_Ln_JpgqsIys-jDOH8oWdxgWqs7hzkDGeLWHb9vSY",
+  "s": "1",
+  "ii": "EaKJ0FoLxO1TYmyuprguKO7kJ7Hbn0m0Wuk5aMtSrMtY",
+  "dt": "2021-01-01T00:00:00.000000+00:00",
+  "et": "vrt",
+  "a": {
+    "s": 2,
+    "d": "Ef12IRHtb_gVo5ClaHHNV90b43adA0f8vRs3jeU-AstY"
+  },
+  "bt": "1",
+  "br": [],
+  "ba": ["BwFbQvUaS4EirvZVPUav7R_KDHB8AKmSfXNpWnZU_YEU"],
+  "b": ["BwFbQvUaS4EirvZVPUav7R_KDHB8AKmSfXNpWnZU_YEU"],
+  "c": []
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "rpy",
+  "d": "EZ-i0d8JZAoTNZH3ULaU6JR2nmwyvYAfSVPzhzS6b5CM",
+  "dt": "2020-08-22T17:50:12.988921+00:00",
+  "r": "/ksn/registry/BwFbQvUaS4EirvZVPUav7R_KDHB8AKmSfXNpWnZU_YEU",
+  "a": {
+    "v": "KERI10JSON0001b0_",
+    "d": "EpltHxeKueSR1a7e0_oSAhgO6U7VDnX7x4KqNCwBqbI0",
+    "i": "EoN_Ln_JpgqsIys-jDOH8oWdxgWqs7hzkDGeLWHb9vSY",
+    "s": "1",
+    "ii": "EaKJ0FoLxO1TYmyuprguKO7kJ7Hbn0m0Wuk5aMtSrMtY",
+    "dt": "2021-01-01T00:00:00.000000+00:00",
+    "et": "vrt",
+    "a": {
+      "s": 2,
+      "d": "Ef12IRHtb_gVo5ClaHHNV90b43adA0f8vRs3jeU-AstY"
+    },
+    "bt": "1",
+    "br": [],
+    "ba": ["BwFbQvUaS4EirvZVPUav7R_KDHB8AKmSfXNpWnZU_YEU"],
+    "b": ["BwFbQvUaS4EirvZVPUav7R_KDHB8AKmSfXNpWnZU_YEU"],
+    "c": []
+  }
+}
+```
+# Transaction Event Log Messages
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "vcp",
+  "d": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "i": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "ii": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
+  "s": "0",
+  "bt": "1",
+  "b": ["BbIg_3-11d3PYxSInLN-Q9_T2axD6kkXd3XRgbGZTm6s"],
+  "c": ["NB"]
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "vrt",
+  "d": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "i": "E_D0eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqA7BxL",
+  "s": "2",
+  "p": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "bt": "1",
+  "br": ["BbIg_3-11d3PYxSInLN-Q9_T2axD6kkXd3XRgbGZTm6s"],
+  "ba": []
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "iss",
+  "d": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "i": "E_D0eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqA7BxL",
+  "s": "0",
+  "ri": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "dt": "2020-08-01T12:20:05.123456+00:00"
+}
+```
+```
+{
+  "v": "KERI10JSON00011c_",
+  "t": "rev",
+  "d": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "i": "E_D0eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqA7BxL",
+  "s": "1",
+  "p": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "ri": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "dt": "2020-08-01T12:20:05.123456+00:00"
+}
+```
+```
+{
+  "v" : "KERI10JSON00011c_",
+  "t" : "bis",
+  "d" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "i" : "E_D0eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqA7BxL",
+  "s" : "0",
+  "ri" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "ra" : {
+      "d": "E8ipype17kJlQfYp3gcF3F1PNKfdX6vpOLXU8YyykB5o",
+      "i": "EFvQCx4-O9bb9fGzY7KgbPeUtjtU0M4OBQWsiIk8za24",
+      "s": 0
+  }
+  "dt": "2020-08-01T12:20:05.123456+00:00"
+}
+```
+```
+{
+  "v" : "KERI10JSON00011c_",
+  "t" : "brv",
+  "d" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "i" : "E_D0eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqA7BxL",
+  "s" : "1",
+  "p" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+  "ri" : "EvxMACzQxU2rDj-X5SPDZYtUn56i4fjjH8yDRFRzaMfI",
+  "ra" : {
+      "d": "E8ipype17kJlQfYp3gcF3F1PNKfdX6vpOLXU8YyykB5o",
+      "i": "EFvQCx4-O9bb9fGzY7KgbPeUtjtU0M4OBQWsiIk8za24",
+      "s": 0
+  }
+  "dt": "2020-08-01T12:20:05.123456+00:00"
+}
+```
+# Appendix: Cryptographic Strength and Security
+
+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 ||TMCrypto||||QCHC||. 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_.
+
+# Conventions and Definitions
+
+{::boilerplate bcp14-tagged}
+
+# Security Considerations
+
+TODO Security
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+\--- back
+
+# Acknowledgments
+
+{:numbered\="false"}
+
+KERI Community at the WebOfTrust Github project.
+
+
+
+
+---
+title: draft-ssmith-ipex
+description: title: "Issuance and Presentation Exchange Protocol"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-ipex/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-ipex/index.md
+---
+
+# 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](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/WG@example.md) arch: [https://example.com/WG](https://example.com/WG) github: USER/REPO latest: [https://example.com/LATEST](https://example.com/LATEST)
+
+name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/Philip.Feairheller@gleif.md)
+
+normative:
+
+name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/Philip.Feairheller@gleif.md) 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
+
+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
+
+# Introduction
+
+TODO Introduction
+
+# Terminology
+
+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.
+
+# Exchange Protocol
+
+| 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.
+
+# Example Most Compact Variant
+
+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.
+
+# Conventions and Definitions
+
+(::boilerplate bcp14-tagged)
+
+# Security Considerations
+
+TODO Security
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+\--- back
+
+# Acknowledgments
+
+(:numbered\="false")
+
+TODO acknowledge.
+
+
+
+
+---
+title: draft-ssmith-cesr
+description: title: "Composable Event Streaming Representation (CESR)"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-cesr/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-cesr/index.md
+---
+
+# draft-ssmith-cesr
+
+title: "Composable Event Streaming Representation (CESR)" abbrev: "CESR" docname: draft-ssmith-cesr-latest category: info
+
+ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
+
+stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
+
+name: S. Smith organization: ProSapien LLC email: [sam@prosapien.com](mailto:sam@prosapien.com)
+
+normative: RFC4648: Base64
+
+RFC20: ASCII
+
+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
+
+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: CBOR
+
+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
+
+BOM: target: [https://en.wikipedia.org/wiki/Byte\_order\_mark](https://en.wikipedia.org/wiki/Byte_order_mark) title: UTF Byte Order Mark
+
+DLog: target: [https://en.wikipedia.org/wiki/Discrete\_logarithm](https://en.wikipedia.org/wiki/Discrete_logarithm) title: Discrete Logarithm Problem
+
+NaCL: target: [https://nacl.cr.yp.to](https://nacl.cr.yp.to) title: NaCl Networking and Cryptography library
+
+MultiCodec: target: [https://github.com/multiformats/multicodec](https://github.com/multiformats/multicodec) title: MultiCodec Multiformats Codecs
+
+MCTable: target: [https://github.com/multiformats/multicodec/blob/master/table.csv](https://github.com/multiformats/multicodec/blob/master/table.csv) title: MultiCodec Table
+
+IPFS: target: [https://richardschneider.github.io/net-ipfs-core/api/Ipfs.Registry.HashingAlgorithm.html](https://richardschneider.github.io/net-ipfs-core/api/Ipfs.Registry.HashingAlgorithm.html) title: IPFS MultiFormats
+
+Base58Check: target: [https://en.bitcoin.it/wiki/Base58Check\_encoding](https://en.bitcoin.it/wiki/Base58Check_encoding) title: Base58Check Encoding
+
+WIF: target: [https://en.bitcoin.it/wiki/Wallet\_import\_format](https://en.bitcoin.it/wiki/Wallet_import_format) title: Wallet Import Format ECDSA Base58Check
+
+Bin2Txt: target: [https://en.wikipedia.org/wiki/Binary-to-text\_encoding](https://en.wikipedia.org/wiki/Binary-to-text_encoding) title: Binary to Text Encoding
+
+ASCII: target: [https://en.wikipedia.org/wiki/ASCII](https://en.wikipedia.org/wiki/ASCII) title: Text Printable ASCII Characters
+
+UTF8: target: [https://en.wikipedia.org/wiki/UTF-8](https://en.wikipedia.org/wiki/UTF-8) title: "UTF-8 Unicode"
+
+Latin1: target: [https://en.wikipedia.org/wiki/ISO/IEC\_8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1) title: "Latin-1 ISO 8859-1"
+
+STOMP: target: [https://stomp.github.io](https://stomp.github.io) title: Simple Text Oriented Messaging Protocol
+
+RAET: target: [https://github.com/RaetProtocol/raet](https://github.com/RaetProtocol/raet) title: Reliable Asynchronous Event Transport
+
+Affinity: target: [https://crd.lbl.gov/assets/Uploads/Nathan-NDM14.pdf](https://crd.lbl.gov/assets/Uploads/Nathan-NDM14.pdf) title: Analysis of the Effect of Core Affinity on High-Throughput Flows date: 2014-11-16
+
+\--- abstract The Composable Event Streaming Representation (CESR) is a dual text-binary encoding format that has the unique property of text-binary concatenation composability. This composability 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. This enables convenient usability in the text domain and compact transmission in the binary domain. CESR primitives are self-framing. CESR supports self-framing group codes that enable stream processing and pipelining in both the text and binary domains. CESR supports composable text-binary encodings for general data types as well as suites of cryptographic material. Popular cryptographic material suites have compact encodings for efficiency while less compact encodings provide sufficient extensibility to support all foreseeable types. CESR streams also support interleaved JSON, CBOR, and MGPK serializations. CESR is a universal encoding that uniquely provides dual text and binary domain representations via composable conversion. The CESR protocol is used by other protocols such as KERI ||KERI||.
+
+\--- middle
+
+# Introduction
+
+One way to better secure Internet communications is to use cryptographically verifiable primitives and data structures both inside messages and in support of messaging protocols. Cryptographically verifiable primitives provide essential building blocks for zero-trust computing and networking architectures. Traditionally cryptographic primitives including but not limited to digests, salts, seeds (private keys), public keys, and digital signatures have been largely represented in some type of binary encoding. This limits their usability in domains or protocols that are human-centric or equivalently that only support ||ASCII|| text-printable characters, ||RFC20||. These domains include source code, documents, system logs, audit logs, Ricardian contracts, and human-readable text documents of many types ||JSON||||RFC4627||.
+
+Generic binary-to-text, ||Bin2Txt||, or simply textual encodings such as Base64 ||RFC4648||, do not provide any information about the type or size of the underlying cryptographic primitive. Base64 only provides "value" information. More recently ||Base58Check|| was developed as a fit-for-purpose textual encoding of cryptographic primitives for shared distributed ledger applications that in addition to value may include information about the type and in some cases the size of the underlying cryptographic primitive, ||WIF||. But each application may use a non-interoperable encoding of type and optionally size. Interestingly because a binary encoding may include as a subset some codes that are in the text-printable compatible subset of ||ASCII|| such as ISO Latin-1, ||Latin1|| or UTF-8, ||UTF8||, one may _serendipitously_ find, for a given cryptographic primitive, a text-printable type code from a binary code table such as the table ||MCTable|| from ||MultiCodec|| for ||IPFS||. Indeed some ||Base58Check|| applications take advantage of the binary MultiCodec tables but only used _serendipitous_ text-compatible type codes. _Serendipitous_ text encodings that appear in binary code tables, do not, however, work in general for any size or type. So the _Serendipitous_ approach is not universally applicable and is no substitute for a true textual encoding protocol for cryptographic primitives.
+
+In general, there is no standard text-based encoding protocol that provides universal type, size, and value encoding for cryptographic primitives. Providing this capability is the primary motivation for the encoding protocol defined herein.
+
+Importantly, a textual encoding that includes type, size, and value is self-framing. 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|| or ||RAET||. Although a first-class textual encoding of cryptographic primitives is the primary motivation for the CESR 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 data structures of all types into text not merely those that contain cryptographic primitives.
+
+Textual encodings have numerous usability advantages over binary encodings. The one advantage, however, that a binary encoding has over text is compactness. An encoding protocol that has the property we call _text-binary concatenation composability_ or more succinctly _**composability**_ enables both the usability of text and the compactness of binary. _**Composability**_ may be the most uniquely innovative and useful feature of the encoding protocol defined herein.
+
+_Composability_ as defined here is short for _text-binary concatenation composability_. An encoding has _composability_ when any set of self-framing 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. Essentially, _composability_ provides round-trippable lossless conversion between text and binary representations of any set of concatenated primitives when converted as a set not merely individually. The property enables a stream processor to safely convert en-masse a stream of text primitives to binary for compact transmission that may be safely converted back to text en-masse by a stream processor at the other end for further processing or archival storage. The addition of group framing codes as independently composable primitives enables hierarchical compositions. Such a hierarchically composable encoding protocol enables pipelining (multiplexing and de-multiplexing) of complex streams in either text or compact binary. This allows management at scale for high-bandwidth applications that benefit from core affinity off-loading of streams ||Affinity||.
+
+The cryptographic primitives defined here (i.e. CESR) inhabit three different domains each with a different representation. The first domain we call streamable text or _text_ and is denoted as _**T**_. The second domain we call streamable binary or _binary_ and is denoted as _**B**_. Composability is defined between the _T_ and _B_ domains. The third domain we call _raw_ and is denoted as _**R**_. The third domain is special because primitives in this domain are represented by a pair or two-tuple of values namely _(text code, raw binary)_ or `(code, raw)` for short. The _text code_ element of the _R_ domain pair is a string of one or more text characters that provides the type and size information for the encoded primitive when in the _T_ domain. The raw binary element is composed of bytes. The actual use of cryptographic primitives happens in the _R_ domain using the _raw binary_ element of the `(code, raw)` pair. Cryptographic primitive values are usually represented as strings of bytes that represent very large integers. Cryptographic libraries typically assume that the inputs and outputs of their functions will be such strings of bytes. The _raw binary_ element of the _R_ domain pair is such a string of bytes. The CESR protocol, however, is not limited to merely encoding cryptographic primitives but any primary data type (numbers, text, datetimes, lists, maps) may be encoded in a composable way.
+
+A given primitive in the _T_ domain is denoted with `t`. A member of an indexed set of primitives in the _T_ domain is denoted with `t[k]`. Likewise, a given primitive in the _B_ domain is denoted with `b`. A member of an indexed set of primitives in the _B_ domain is denoted with `b[k]`. Similarly, a given primitive in the _R_ domain is denoted with `r`. A member of an indexed set of primitives in the _R_ domain is denoted with `r[k]`.
+
+Although, the composability property mentioned in the previous section only applies to conversions back and forth between the _T_, and _B_, domains, conversions between the _R_, and _T_ domains as well as conversions between the _R_ and _B_ domains are also defined and supported by the protocol as described in detail in this section. As a result, there is a total of six transformations, one in each direction between the three domains.
+
+Let `T(B)` denote the abstract transformation function from the _B_ domain to the _T_ domain. This is the dual of `B(T)` below.
+
+Let `B(T)` denote the abstract transformation function from the _T_ domain to the _B_ domain. This is the dual of `T(B)` above.
+
+Let `T(R)` denote the abstract transformation function from the _R_ domain to the _T_ domain. This is the dual of `R(T)` below.
+
+Let `R(T)` denote the abstract transformation function from the _T_ domain to the _R_ domain. This is the dual of `T(R)` above.
+
+Let `B(R)` denote the abstract transformation function from the _R_ domain to the _B_ domain. This is the dual of `R(B)` below.
+
+Let `R(B)` denote the abstract transformation function from the _B_ domain to the _R_ domain. This is the dual of `B(R)` above.
+
+Given these transformations, we can complete a circuit of transformations that starts in any of the three domains and then crosses over the other two domains in either direction. For example, starting in the _R_ domain we can traverse a circuit that crosses into the _T_ and _B_ domains and then crosses back into the _R_ domain as follows:
+```
+R->T(R)->T->B(T)->B->R(B)->R
+```
+Likewise starting in the _R_ domain we can traverse a circuit that crosses into the _B_ and _T_ domains and then crosses back into the _R_ domain as follows:
+```
+R->B(R)->B->T(B)->T->R(T)->R
+```
+Let `+` represent concatenation. Concatenation is associative and may be applied to any two primitives or any two groups or sets of concatenated primitives. For example:
+```
+t[0] + t[1] + t[2] + t[3] = (t[0] + t[1]) + (t[2] + t[3])
+```
+If we let `cat(x[k])` denote the concatenation of all elements of a set of indexed primitives `x[k]` where each element is indexed by a unique value of `k`. Given the indexed representation, we can express the transformation between domains of a concatenated set of primitives as follows:
+
+Let `T(cat(b[k]))` denote the concrete transformation of a given concatenated set of primitives, `cat(b[k])` from the _B_ domain to the _T_ domain.
+
+Let `B(cat(t[k]))` denote the concrete transformation of a given concatenated set of primitives, `cat(t[k])` from the _T_ domain to the _B_ domain.
+
+The concatentation composability property between _T_ and _B_ is expressed as follows:
+
+Given a set of primitives `b[k]` and `t[k]` and transformations `T(B)` and `B(T)` such that `t[k] = T(b[k])` and `b[k] = B(t[k])` for all `k`, then `T(B)` and `B(T)` are jointly concatenation composable if and only if,
+```
+T(cat(b[k]))=cat(T(b[k])) and B(cat(t[k]))=cat(B(t[k])) for all k.
+```
+Basically, _composability_ (over concatenation) means that the transformation of a set (as a whole) of concatenated primitives is equal to the concatenation of the set of individually transformed primitives.
+
+For example, suppose we have two primitives in the text domain, namely, `t[0]` and `t[1]` that each transforms, respectively, to primitives in the binary domain, namely, `b[0]` and `b[1]`. The transformation duals, `B(T)` and `T(B)`, are composable if and only if,
+```
+B(t[0] + t[1]) = B(t[0]) + B(t[1]) = b[0] + b[1]
+```
+and
+```
+T(b[0] + b[1]) = T(b[0]) + T(b[1]) = t[0] + t[1].
+```
+The composability property defined above allows us to create arbitrary compositions of primitives via concatenation in either the _T_ or _B_ domain and then convert the composition en masse to the other domain and then de-concatenate the result without loss. The self-framing property of the primitives enables de-concatenation.
+
+The composability property is an essential building block for streaming in either domain. The use of framing primitives that count or group other primitives enables multiplexing and demultiplexing of arbitrary groups of primitives for pipelining and/or on or offloading of streams. The text domain representation of a stream enables better usability (readability) and the binary domain representation of a stream enables better compactness. In addition, pipelined hierarchical composition codes, allow efficient conversion or off-loading for concurrent processing of composed (concatenated) groups of primitives in a stream without having to individually parse each primitive before off-loading.
+
+# Concrete Domain Representations
+
+Text, _T_, domain representations in CESR use only the characters from the URL and filename safe variant of the IETF RFC-4648 Base64 standard ||RFC4648||. Unless otherwise indicated all references to Base64 ||RFC4648|| in this document imply the URL and filename safe variant. The URL and filename safe variant of Base64 uses in order the 64 characters `A to Z`, `a to z`, `0 to 9`, `-`, and `_` to encode 6 bits of information. In addition, Base64 uses the `=` character for padding but CESR does not use the `=` character for any purpose because all CESR-encoded primitives are composable.
+
+Notable is the fact that, Base64 ||RFC4648|| by itself does not satisfy the composability property and must employ pad characters to ensure one-way convertability between binary and text.
+
+In CESR, however, both _T_ and _B_ domain representations include a prepended framing code prefix that is structured in such a way as to ensure composability.
+
+Suppose for example we wish to use Base64 characters in the text domain and binary bytes in the binary domain. For the sake of example, we will call these respectively, naive text and naive binary encodings and domains. Recall that a byte encodes 8 bits of information and a Base64 character encodes 6 bits of information. Furthermore suppose that we have three primitives denoted `a`, `b`, and `c` in the naive binary domain with lengths of 1, 2, and 3 bytes respectively.
+
+In the following diagrams, we denote each byte in a naive binary primitive with zero-based most significant bit first indices. For example, `a1` is bit one from `a`, `a0` is bit zero, and `A0` for byte zero, `A1` for byte 1, etc.
+
+The byte and bit-level diagrams for `a` is shown below where we use `A` to denote its bytes:
+```
+|           A0          |
+|a7:a6:a5:a4:a3:a2:a1:a0|
+```
+Likewise for `b` below:
+```
+|           B1          |           B0          |
+|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|
+```
+And finally for `c` below:
+```
+|           C2          |           C1          |           C0          |
+|c7:c6:c5:c4:c3:c2:c1:c0|c7:c6:c5:c4:c3:c2:c1:c0|c7:c6:c5:c4:c3:c2:c1:c0|
+```
+When doing a naive Base64 conversion of a naive binary primitive, one Base64 character represents only six bits from a given byte. In the following diagrams, each character of a Base64 conversion is denoted using zero-based indices, most significant character first.
+
+Therefore encoding `a` in Base64 requires at least two Base64 characters because the zeroth character only captures the six bits from the first byte and another character is needed to capture the other two bits. The convention in Base64 uses a Base64 character where the non-coding bits are zeros. This is diagrammed as follows:
+```
+|           A0          |
+|a7:a6:a5:a4:a3:a2:a1:a0|z3:z2:z1:z0|
+|        T1       |        T0       |
+```
+where `aX` represents a bit from `A0` and `zX` represents a zeroed pad bit, and `TX` represents a non-pad character from the converted Base64 text representing one hextet of information from the converted binary string.
+
+Naive Base64 encoding always pads each individual conversion of a string of bytes to an even multiple of four characters. This provides a property that is not true composability but does ensure that multiple distinct concatenated conversions from binary to Base64 text are separable. It may be described as a sort of one-way composability. So with pad characters, denoted by replacing the spaces with `=` characters, the Base64 conversion of `a` is as follows:
+```
+|           A0          |
+|a7:a6:a5:a4:a3:a2:a1:a0|z3:z2:z1:z0|
+|        T3       |        T2       |========P1=======|========P0=======|
+```
+where `aX` represents a bit from `a`, `AX` represents a byte from `a`, `zX` represents a zeroed pad bit, `PX` represents a trailing pad character, and `TX` represents a non-pad character from the converted Base64 text representing one hextet of information from the converted binary string. We see that Base64 conversion effectively left shifts `a` by four bits plus two pad characters. In other words, the Base64 conversion of `a` is no longer right aligned with respect to the trailing Base64 character.
+
+Likewise `b` requires at least three Base64 characters to capture all of its sixteen bits of information as follows:
+```
+|           B1          |           B0          |
+|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|z1:z0|
+|        T2       |        T1       |        T0       |
+```
+where `bX` represents a bit from `b`, `BX` represents a byte from `b`, `zX` represents a zeroed pad bit, and `TX` represents a non-pad character from the converted Base64 text representing one hextet of information from the converted binary string. Alignment on a 4 character (24-bit) boundary requires one pad character this becomes:
+```
+|           B1          |           B0          |
+|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|z1:z0|
+|        T2       |        T1       |        T0       |========P0=======|
+```
+where `bX` represents a bit from `b`, `BX` represents a byte from `b`, `zX` represents a zeroed pad bit, `PX` represents a trailing pad character, and `TX` represents a non-pad character from the converted Base64 text representing one hextet of information from the converted binary string. We see that Base64 conversion effectively left shifts `a` by four bits plus two pad characters. We see that Base64 conversion effectively left shifts `b` by four bits plus one pad character. In other words, the Base64 conversion of `b` is no longer right aligned with respect to the trailing Base64 character.
+
+Finally, `c` requires exactly four Base64 characters to capture all of its twenty-four bits of information. There are no pad characters required.
+```
+|           C2          |           C1          |           C2          |
+|c7:c6:c5:c4:c3:c2:c1:c0|c7:c6:c5:c4:c3:c2:c1:c0|c7:c6:c5:c4:c3:c2:c1:c0|
+|        T3       |        T2       |        T1       |        T0       |
+```
+where `cX` represents a bit from `c`, `CX` represents a byte from `c`, and `TX` represents a non-pad character from the converted Base64 text representing one hextet of information from the converted binary string. There are no bit shifts because there are no pad bits nor pad characters needed, and the resulting Base64 conversion is right aligned with respect to the trailing Base64 character.
+
+Suppose now we concatenate `a + b` into a three-byte composition in the naive binary domain before Base64 encoding the concatenated whole. We have the following:
+```
+|           A0          |           B1          |           B0          |
+|a7:a6:a5:a4:a3:a2:a1:a0|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|
+|        T3       |        T2       |        T1       |        T0       |
+```
+We see that the least significant two bits of `A0` are encoded into the same character, `T2` as the four most significant four bits of `B1`. Therefore, a text-domain parser would be unable to cleanly de-concatenate on a character-by-character basis the conversion of `a + b` into separate text-domain primitives. Therefore, standard (naive) binary to Base64 conversion does not satisfy the composability constraint.
+
+Suppose instead we start in the text domain with primitives `u` and `v` of lengths 1 and 3 characters respectively. If we concatenate these two primitives as `u + v` in the text domain and then convert them as a whole to naive binary. We have the following:
+```
+|        U0       |        V2       |        V1       |        V0       |
+|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|
+|           B2          |           B1          |           B0          |
+```
+We see that all six bits of information in `U0` is included in `B2` along with the least significant two bits of information in `V2`. Therefore a binary domain parser is unable to cleanly de-concatenate on a byte-by-byte basis the conversion of `u + v` into separate binary domain primitives. Therefore, standard (naive) Base64 to binary conversion does not satisfy the composability constraint.
+
+Indeed, the composability property is only satisfied if each primitive in the _T_ domain is an integer multiple of four Base64 characters (24 bits) and each primitive in the _B_ domain is an integer multiple of three bytes (24 bits). Each of either four Base64 text characters or three binary bytes captures twenty-four bits of information. Twenty-four is the least common multiple of six and eight. Therefore in order to cleanly capture integer multiples of twenty-four bits of information, primitive lengths MUST be integer multiples of either four Base64 text characters or three binary bytes in their respective domains. Given the constraint of alignment on 24-bit boundaries in either text or binary domains is satisfied, the conversion of concatenated primitives in one domain never results in the same byte or character in the converted domain sharing bits from two adjacent primitives. This constraint of 24-bit alignment, therefore, satisfies the _composability_ property.
+
+To elaborate, when converting streams made up of concatenated primitives back and forth between the _T_ and _B_ domains, the converted results will not align on byte or character boundaries at the end of each primitive unless the primitives themselves are integer multiples of twenty-four bits of information. In other words, all primitives must be aligned on twenty-four-bit boundaries to satisfy the composability property. This means that the length of any primitive in the _B_ domain MUST be an integer multiple of three binary bytes with a minimum length of three binary bytes. Likewise, this means that the length of any primitive in the _T_ domain MUST be an integer multiple of 4 Base64 characters with a minimum length of four Base64 characters.
+
+There are many coding schemes that could satisfy the composability constraint of alignment on 24-bit boundaries. The main reason for using a _T_ domain-centric encoding is higher usability, readability, or human friendliness. Indeed a primary design goal of CESR is to select an encoding approach that provides high usability, readability, or human friendliness in the _T_ domain. This type of usability goal is simply not realizable in the _B_ domain. The B domain's purpose is merely to provide convenient compactness at scale. We believe usability in the _T_ domain is maximized when the type portion of the prepended framing code is _stable_ or _invariant_. Stable type coding makes it much easier to recognize primitives of a given type when debugging source, reading messages, or documents in the _T_ domain that include encoded primitives. This is true even when those primitives have different lengths or values. For primitive types that have fixed lengths, i.e. all primitives of that type have the same length, stable type coding aids not only visual type but visual size recognition.
+
+The usability of stable type coding is maximized when the type portion appears first in the framing code. Stability also requires that for a given type, the type coding portion must consume a fixed integer number of characters in the _T_ domain. To clarify, as used here, stable type coding in the _T_ domain never shares information bits with either length or value coding in any given framing code character and appears first in the framing code. Stable type coding in the _T_ domain translates to stable type coding in the _B_ domain except that the type coding portion of the framing code may not respect byte boundaries. This is an acceptable tradeoff because binary-domain parsing tools easily accommodate bit fields and bit shifts while text-domain parsing tools do not. Generally, text-domain parsing tools only process whole characters. This is another reason to impose a stability constraint on the _T_ domain type coding instead of the _B_ domain.
+
+A secondary usability constraint is recognizable or readable stable value coding in the text, _T_, domain. Not all primitives benefit from stable value coding. Any representation of a value that is a long random string of characters is essentially unreadable or recognizable versus some other representation. Bit shifts of the value, as long as they are static do not change the readability. This is not true however of values that are small numbers. Base64 encodings of small numbers are readable. for example, the numerical sequence of decimal numbers, `0, 1, 2`, is recognizable as the sequence of Base64 characters, `A, B, C`. Thus, all else equal, readable stable value encodings also contribute to usability, at least in some cases.
+
+There are two ways to provide the required alignment on 24-bit boundaries to satisfy the composability property. One is post-pad, with trailing pad characters `=`, the text domain encoding to ensure that the _T_ domain primitive has a total size (length) that is an integer multiple of 4. This is what naive Base64 encoding 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.
+
+Given the second way, there is one of two options that depend on the specific code. In the first option, an appropriate number of the text characters that result from the conversion of a porting of the leading pre-pad zero bytes are replaced with the appropriate number of code characters. In the second option, the code characters are pre-pended to the conversion with leading zeros intact. In the second option, the length of the pre-pended type code MUST also, thereby, be an integer multiple of 4 characters. In either option, the total length of the _T_ domain primitive with code is an integer multiple of 4 characters.
+
+The first way may be more compact in some cases than the second. The second way may be easier to compute in some cases. The most significant advantage of the second way is that the value portion of is stable and more readable both in the text, _T_, domain and in the, _B_, binary domain because the value portion is not shifted by the Base64 conversion as it is with the first way.
+
+In order to avoid confusion with the use of the term `pad character`, when pre-padding with bytes that are not replaced later, we use the term `lead bytes`. The term pad 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.
+
+Suppose for example the raw binary value is 32 bytes in length. The next higher integer multiple of 3 is 33 bytes. Thus 1 additional leading pad byte is needed to make the size (length in byte) of raw binary an integer multiple of 3. The 1 lead byte makes that combination a total of 33 bytes in length. The resultant Base64 converted value will be 44 characters in length, which is an integer multiple of 4 characters. In contrast, recall that when we convert a 32-byte raw binary value to Base64 the converted value will have 1 trailing pad character. In both cases, the resultant length in Base64 is 44 characters.
+
+Similarly, a 64-byte raw binary value needs 2 lead bytes to make the combination 66 bytes in length where 66 is the next integer multiple of 3 greater than 64. When converted the result is 88 characters in length. The number of pad characters added on the result of the Base64 conversion of a 64-byte raw binary is also 2.
+
+In summary, there are two possibilities for CESR's coding scheme to ensure a composable 24-bit alignment. The first is to add trailing pad characters post-conversion. The second is to add leading pad bytes pre-conversion. Because of the greater readability of the value portion of both the fully qualified text, _T_, or fully qualified binary, _B_, domain representations, the second approach was chosen for CESR.
+
+The design goals for CESR framing codes include minimizing the framing code size for the most frequently used (most popular) codes while also supporting a sufficiently comprehensive set of codes for all foreseeable current and future applications. This requires a high degree of both flexibility and extensibility. We believe this is best achieved with multiple code tables each with a different coding scheme that is optimized for a different set of features instead of a single one-size-fits-all scheme. A specification that supports multiple coding schemes may appear on the surface to be much more complex to implement but careful design of the coding schemes can reduce implementation complexity by using a relatively simple single integrated parse and conversion table. Parsing in any given domain given stable type codes may then be imple899mented with a single function that simply reads the appropriate type selector in the table to know how to parse and convert the rest of the primitive.
+
+# Text Coding Scheme Design
+
+Recall from above, that the R domain representation is a pair`(text code, raw binary)`. The text code is stable and begins with one or more Base64 characters that provide the primitive type and may also include one or more additional characters that provide the length. The actual usable cryptographic material is provided by the _raw binary_ element.
+
+The corresponding _T_ domain representation of this pair is created by first prepending leading pad bytes of zeros to the _raw binary_ element. This result is then converted to Base64. Depending on the code, either the frontmost characters that result from the Base64 conversion of leading pad bytes of zeros are replaced with the text code element of appropriate size in characters, or an appropriately sized text code element is prepended to the conversion without replacing any characters.
+
+Recall, that when the length of a given naive binary string is not an integer multiple of three bytes, standard Base64 conversion software appends one or two pad characters to the resultant Base64 conversion.
+
+With standard Base64 conversion that employs pad characters, the text domain representation that results from the individual conversion of a set of binary strings when concatenated in the text domain after conversion and stripping off pad characters is not necessarily equivalent to the text domain representation that results from converting en masse to text the concatenation of the same set of binary strings and then stripping off pad characters. In the latter case knowledge of the set of binary strings is lost because the resultant conversion may have bits from two binary bytes concatenated in one text character. Restated, the problem with standard Base64 is that it does not preserve byte boundaries after the en-masse conversion of concatenated binary strings. Consequently, standard (naive) Base64 does not provide two-way or true composability as defined above.
+
+To elaborate, the number of pad characters appended with standard Base64 encoding is a function of the length of the binary string. Let _N_ be the length in bytes of the binary string. When `N mod 3 = 1` then there are 8 bits in the remainder that must be encoded into Base64. Recall from the examples above that a single byte (8 bits) requires two Base64 characters. The first encodes 6 bits and the second the remaining 2 bits for a total of 8 bits. The last character is selected such that its non-coding 4 bits are zero. Thus two additional pad characters are required to pad out the resulting conversion so that its length is an integer multiple of 4 Base64 characters. Furthermore when `N mod 3 = 1` then the addition of 2 more zeroed bytes to the length of the binary string such that `M = N + 2` would result in `M mod 3 = 0` or equivalently `N + 2 mod 3 = 0`.
+
+Similarly, when `N mod 3 = 2` then there are two bytes (16 bits) in the remainder that must be encoded into Base64. Recall from the examples above that two bytes (16 bits) requires three Base64 characters. The first two encode 6 bits each (for 12 bits) and the third encodes the remaining 4 bits for a total of 16. The last character is selected such that its non-coding 2 bits are zero. Thus one additional trailing pad character is required to pad out the resulting conversion so that its length is an integer multiple of 4 characters. Furthermore when `N mod 3 = 2` then the addition of 1 more byte of zeros added to the length of the binary string such that `M = N + 1` would result in `M mod 3 = 0` or equivalently `N + 2 mod 3 = 0`. Thus the number of leading pre-pad zeroed bytes needed to align the binary string on a 24-bit boundary is the same as the number of trailing pad characters needed to align the converted Base64 text string on a 24-bit boundary.
+
+Finally, when `N mod 3 = 0` then the binary string is aligned on a 24-bit boundary and no trailing pad characters are required to ensure the length of the Base64 conversion is an integer multiple of 4 characters. Likewise, no leading pad bytes are required to ensure the length of the binary string is an integer multiple of 3 bytes.
+
+Thus, in all three cases, the number of trailing post-pad characters, if any, needed to align the converted Base64 text string on a 24-bit boundary is the same as the number of leading pre-pad bytes, if any, needed to align the binary string on a 24-bit boundary.
+
+The number of required trailing Base64 post-pad characters or equivalently the number of leading pre-pad zeroed bytes to ensure 24 bit alignment may be computed with the following formula:
+
+`ps = (3 - (N mod 3)) mod 3)`, where `ps` is the pad size (pre-pad bytes or post-pad characters) and `N` is the size in bytes of the binary string.
+
+Recall that composability is provided here by prepending text codes that are of the appropriate length to ensure 24-bit boundaries in both the _T_ and the corresponding _B_ domain. The advantage of this approach is that naive Base64 software tooling may be used to convert back and forth between the _T_ and _B_ domains, i.e. `T(B)` is naive Base64 encode, and `B(T)` is naive Base64 decode. In other words, CESR primitives are compatible with existing Base64 (RFC-4648) tooling. Whereas new software tooling is needed for conversions between the _R_ and _T_ domains, e.g. `T(R)` and `R(T` and the _R_ and _B_ domains, e.g. `B(R)` and `R(B)`.
+
+The pad size computation is also useful for computing the size of the text codes. Because true composability also requires that the _T_ domain value MUST be an integer multiple of 4 characters in length the size of the text code MUST also be a function of the pad size, `ps`, and hence the length of the raw binary element, `N`. Thus the size of the text code in Base64 characters is a function of the equivalent pad size determined by the length `N mod 3` of the raw binary value. If we let _M_ be a non-negative integer-valued variable then we have three cases:
+
+| Pad Size | Code Size |
+| --- | --- |
+
+| 0 | 4•M |
+| 1 | 4•M + 1 |
+| 2 | 4•M + 2 |
+
+The minimum code sizes are 1, 2, and 4 characters for pad sizes of 1, 2, and 0 characters with _M_ equaling 0, 0, and 1 respectively. By increasing _M_ we can have larger code sizes for a given pad size.
+
+Returning to the examples above, let's observe what happens when we pre-pad the binary strings with zeroed leading pad bytes of the appropriate length given by `ps = (3 - (N mod 3)) mod 3)` where `ps` is the number of leading pad bytes and `N` is the length of the raw binary string before padding is prepended.
+
+For the one byte raw binary string `a`, `ps` is two. The pre-padded conversion results in the following:
+```
+|           Z1          |           Z0          |           A0          |
+|z7:z6:z5:z4:z3:z2:z1:z0|z7:z6:z5:z4:z3:z2:z1:z0|a7:a6:a5:a4:a3:a2:a1:a0|
+|        T3       |        T2       |        T1       |        T0       |
+```
+where `ZX` represents a zeroed pre-pad byte, `zX` represents a zeroed pre-pad bit, `AX` represents a byte from `a`, `aX` represents a bit from `a`, and `TX` represents a Base64 character that results from the Base64 conversion of the pre-padded `a`.
+
+Noteworthy is that the first two (i.e. `ps`) characters of the conversion, namely, `T3T2` does not include any bits of information from `a`. This also means that `T3T2` can be modified after conversion without impacting the appearance or value of the converted `a` that appears solely in `T1T0`, i.e. there is no overlap. Moreover, the resulting Base64 conversion of `a` is right aligned with respect to the trailing Base64 character. This means that one can "read" and understand the numerical values for `a` from such an unshifted Base64 conversion. This also means that a text-based parser on a character-by-character basis can cleanly process `T3T2` separate from the Base64 encoding of `a` that appears in `T1T0`. Given this separation we could replace `T3T2` with two character Base64 textual type code `C1C0` as follows:
+```
+|           Z1          |           Z0          |           A0          |
+|z7:z6:z5:z4:z3:z2:z1:z0|z7:z6:z5:z4:z3:z2:z1:z0|a7:a6:a5:a4:a3:a2:a1:a0|
+|        S1       |        S0       |        T1       |        T0       |
+|s5:s4:s3:s2:s1:s0|s5:s4|s3:s2:s1:s0|z3:z2:z1:z0|a7:a6:a5:a4:a3:a2:a1:a0|
+```
+where `ZX` represents a zeroed pre-pad byte, `zX` represents a zeroed pre-pad bit, `AX` represents a byte from `a`, `aX` represents a bit from `a`, `TX` represents a Base64 character that results from the Base64 conversion of the pre-padded `a`, `SX` represents a Base64 code character replacing one of the `TX`, and `sX` is a code bit. The resultant four character Base64 encoded primitive would be `C1C0T1T0`.
+
+When `C1C0T1T0` is converted back to binary from Base64 the result would be as follows:
+```
+|        S1       |        S0       |        T1       |        T0       |
+|s5:s4:s3:s2:s1:s0|s5:s4|s3:s2:s1:s0|z3:z2:z1:z0|a7:a6:a5:a4:a3:a2:a1:a0|
+|           U1          |        U0             |           A0          |
+```
+where `CX` represents a Base64 code character replacing one of the `TX`, `cX` is a code bit, `UX` represents byte from converted code char which may include zeroed bits, `zX` represents a zeroed pre-pad bit, `AX` represents a byte from `a`, `aX` represents a bit from `a`, and `TX` represents a Base64 character that results from the Base64 conversion of the pre-padded `a`.
+
+Stripping off `U1U0` leaves `a` in its original state. Noteworthy is that the code characters (only) are effectively left shifted 4 bits after conversion. The code characters `S1S0` can be recovered as the first two characters obtained from simply converting `U1O0` only back to Base64.
+
+For the two byte raw binary string `b`, `ps` is one. The pre-padded conversion results in the following:
+```
+|           Z0          |           B1          |           B0          |
+|z7:z6:z5:z4:z3:z2:z1:z0|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|
+|        T3       |        T2       |        T1       |        T0       |
+```
+where `ZX` represents a zeroed pre-pad byte, `zX` represents a zeroed pre-pad bit, `BX` represents a byte from `b`, `bX` represents a bit from `b`, and `TX` represents a Base64 character that results from the Base64 conversion of the pre-padded `b`.
+
+Noteworthy is that the first one (i.e. `ps`) character of the conversion, namely, `T3`, does not include any bits of information from `b`. This also means that `T3` can be modified after conversion without impacting the appearance or value of the converted `b` that appears solely in `T2T1T0`, i.e. there is no overlap. Moreover, the resulting Base64 conversion of `b` is right aligned with respect to the trailing Base64 character. This means that one can "read" and understand the numerical values for `b` from such an unshifted Base64 conversion. This also means that a text-based parser on a character-by-character basis can cleanly process `T3` separate from the Base64 encoding of `b` that appears in `T2T1T0`. Given this separation we could replace `T3` with one character Base64 textual type code `C0` as follows:
+```
+|           Z1          |           B1          |           B0          |
+|z7:z6:z5:z4:z3:z2:z1:z0|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|
+|        S0       |        T2       |        T1       |        T0       |
+|s5:s4:s3:s2:s1:s0|z1:z0|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|
+```
+where `ZX` represents a zeroed pre-pad byte, `zX` represents a zeroed pre-pad bit, `BX` represents a byte from `b`, `bX` represents a bit from `b`, `TX` represents a Base64 character that results from the Base64 conversion of the pre-padded `b`, `SX` represents a Base64 code character replacing one of the `TX`, and `sX` is a code bit,. The resultant four character Base64 encoded primitive would be `S0T2T1T0`.
+
+When `S0T2T1T0` is converted back to binary from Base64 the result would be as follows:
+```
+|        S0       |        T2       |        T1       |        T0       |
+|s5:s4:s3:c2:cs:s0|z1:z0|b7:b6:b5:b4:b3:b2:b1:b0|b7:b6:b5:b4:b3:b2:b1:b0|
+|           U0          |           U1          |           A0          |
+```
+where `SX` represents a Base64 code character replacing one of the `TX`, `sX` is a code bit, `UX` represents byte from converted code char which may include zeroed bits, `zX` represents a zeroed pre-pad bit, `BX` represents a byte from `b`, `bX` represents a bit from `b`, and `TX` represents a Base64 character that results from the Base64 conversion of the pre-padded `b`.
+
+Stripping off `U0` leaves `b` in its original state. Noteworthy is that the code character (only) is effectively left shifted 4 bits after conversion. The code character `S0` can be recovered as the first character obtained from simply converting `U0` only to Base64 .
+
+For the three byte raw binary string `c`, `ps` is zero. So prepadding is not needed.
+```
+|           C2          |           C1          |           C2          |
+|c7:c6:c5:c4:c3:c2:c1:c0|c7:c6:c5:c4:c3:c2:c1:c0|c7:c6:c5:c4:c3:c2:c1:c0|
+|        T3       |        T2       |        T1       |        T0       |
+```
+where `cX` represents a bit from `c`, `CX` represents a byte from `c`, and `TX` represents a non-pad character from the converted Base64 text representing one hextet of information from the converted binary string. There are no bit shifts because there are no pad bits nor pad characters needed, and the resulting Base64 conversion is right aligned with respect to the trailing Base64 character.
+
+Without pad characters, however, that there is no room to hold a type code. Consequently any text type code is just prepended to the conversion. The prepended type code MUST be an integer multiple of four Base64 characters. Let, `S3S2S1S0` be the type code then the full primitive with code and converted raw binary is given by the eight character Base64 string `S3S2S1S0T3T2T1T0`.
+
+When `S3S2S1S0T3T2T1T0` is converted back to binary, there is no overlapp or bit shifting because both the code and raw binary `c` are each seperately aligned on twenty-four bit boundaries.
+
+Suppose for example that we wish to encode two byte raw binary numbers into CESR using the pre-pad approach described above. In order to achieve twenty-four bit alignment, the pre-pad size for two byte numbers is 1 byte. As described above this mean the minimally sized text code is 1 Base64 character. Suppose that the text code is `M` (Base64). The following table provides examples of encoding the different two byte raw binary values in the three domains: raw, text, and binary. Recall that raw domain is expressed by a tuple of (code, raw) where the code is Base64 text and the raw is the raw binary value without code. For readability, raw binary values are represented in hexidecimal notation.
+
+| Raw | Text | Binary |
+| --- | --- | --- |
+
+| ("M", 0x0000) | "MAAA" | 0x300000 |
+| ("M", 0x0001) | "MAAB" | 0x300001 |
+| ("M", 0xffff) | "MP\_\_" | 0x30ffff |
+
+With this approach both the binary and text domain representations are as compact as possible for a fully qualified primitive that satisfies the composability property. The text domain representation has a stable readable code and a stable readable value. The binary domain is value right aligned. The text domain representation consists of 4 text printable characters from the Base64 set of characters and the binary domain representation consists of 3 bytes. Both are parsable in each domain along character/byte boundaries respectively. A parser reads the first character/byte. It then processes that value to get an index into a lookup table that it uses to find how many remaining characters/bytes to extract from the stream. This makes the primitive self-framing.
+
+As mentioned above one of the primary advantages of composable encoding is that special framing codes can be specified to support groups of primitives. Grouping enables pipelining. 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.
+
+A count code is it's own composable primitive and its length therefore MUST be an integer multiple of four characters in the text domain or equivalently an integer multiple of three bytes in the binary domain. To clarify, a count code is primitive that does not include a raw binary value, only its text code. Because a count code's raw binary element value is empty and its length is an integer multiple of four characters (three bytes), its pad size is always 0.
+
+To elaborate, we can use count codes as separators to better organize a stream of primitives or to interleave non-native (non-CESR) serializations. Count codes enable the grouping together of any combination of primitives, groups of primitives, or non-native serializations to optimize pipelining and offloading.
+
+As mentioned above, 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 ||JSON||||RFC4627||, CBOR ||CBOR||||RFC8949||, or MsgPack (MGPK) ||MGPK|| to serialize flexible self-describing data structures based on field maps, also known as dictionaries or hash tables. With respect to field map serializations, CESR primitives may appear in two different contexts. The first context is as a delimited text primitive inside of a field map serialization. The delimited text may be either the key or value of a (key, value) pair. The second context is as a standalone serialization that is interleaved with field map serializations in a stream. Special CESR count codes enable support for the second context of interleaving standalone CESR with other serializations.
+
+After a 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 yet 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. Good cold start re-synchronization is essential to robust performant stream processing.
+
+For example, in TCP a cold start usually means closing and then reopening the TCP connection. This flushes the TCP buffers and sends a signal to the other end of the stream that may be interpreted as a restart or cold start. In UDP each packet is individually framed but a stream may be segmented into multiple packets so a cold start may require an explicit ack or nack to force a restart.
+
+Special CESR count codes support re-synchronization at each boundary between interleaved CESR and other serializations like JSON, CBOR, or MGPK
+
+Given the popularity of three specific serializations, namely, JSON, CBOR, and MGPK, more fine-grained serialization boundary detection for interleaving CESR may be highly beneficial for both performance and robustness reasons. One way to provide this is by selecting the count code start bits such that there is always a unique (mutually distinct) set of start bits at each interleaved boundary between CESR, JSON, CBOR, and MGPK.
+
+Furthermore, it may also be highly beneficial to support in-stride switching between interleaved CESR text-domain streams and CESR binary domain streams. In other words, the start bits for count (framing) codes in both the _T_ domain (Base64) and the _B_ domain should be unique. This would provide the analogous equivalent of a UTF Byte Order Mark (BOM) ||BOM||. Recall that a BOM enables a parser of UTF encoded documents to determine if the UTF codes are big-endian or little-endian ||BOM||. In the CESR case, an analogous feature would enable a stream parser to know if a count code along with its associated counted or framed group of primitives is expressed in the _T_ or _B_ domain. Together these impose the constraint that the boundary start bits for interleaved text CESR, binary CESR, JSON, CBOR, and MGPK be mutually distinct.
+
+Amongst the codes for map objects in the JSON, CBOR, and MGPK only the first three bits are fixed and not dependent on mapping size. In JSON a serialized mapping object always starts with `{`. This is encoded as `0x7b`. the first three bits are `0b011`. In CBOR the first three bits of the major type of the serialized mapping object are `0b101`. In MGPK (MsgPack) there are three different mapping object codes. The _FixMap_ code starts with `0b100`. Both the _Map16_ code and _Map32_ code start with `0b110`.
+
+So we have the set of four used starting tritets (3 bits) in numeric order of `0b011`, `0b100`, `0b101`, and `0b110`. This leaves four unused tritets, namely, `0b000`, `0b001`, `0b010`, and `0b111` that may be selected as the CESR count (framing) code start bits. In Base64 there are two codes that satisfy our constraints. The first is the dash character, `-`, encoded as `0x2d`. Its first three bits are `0b001`. The second is the underscore character,`_`, encoded as `0x5f`. Its first three bits are `0b010`. Both of these are distinct from the starting tritets of any of the JSON, CBOR, and MGPK encodings above. Moreover, the starting tritet of the corresponding binary encodings of `-` and `_` is `0b111` which is also distinct from all the others. To elaborate, Base64 uses `_` in position 62 or `0x3E` (hex) and uses `_` in position 63 or `0x3F` (hex) both of which have starting tritet of `0b111`
+
+This gives us two different Base64 characters, `-` and `_` we can use for the first character of any framing (count) code in the _T_ domain. This also means we can have two different classes of framing (count) codes. This also provides a BOM-like capability to determine if a framing code is expressed in the _T_ or _B_ domain. To clarify, if a stream starts with the tritet `0b111` then the stream is _B_ domain CESR and a stream parser would thereby know how to convert the first sextet of the stream to determine which of the two framing codes is being used, `0x3E` or `ox3F`. If on the other hand, the framing code starts with either of the tritets `0b001` or `0b010` then the framing code is expressed in the _T_ domain and a stream parser likewise would thereby know how to convert the first character (octet) of the framing code to determine which framing code is being used. Otherwise, if a stream starts with `0b100` then is JSON, with `0b101` then its CBOR, and with either `0b011`, and `0b110` then its MGPK.
+
+This is summarized in the following table:
+
+| Starting Tritet | Serialization | Character |
+| --- | --- | --- |
+
+| 0b000 |  |  |
+| 0b001 | CESR _T_ Domain Count (Group) Code | `-` |
+| 0b010 | CESR _T_ Domain Op Code | `_` |
+| 0b011 | JSON | `{` |
+| 0b100 | MGPK |  |
+| 0b101 | CBOR |  |
+| 0b110 | MGPK |  |
+| 0b111 | CESR _B_ Domain |  |
+
+Given this set of tritets (3 bits), we can express a requirement for a well-formed stream start and restart.
+
+Each stream MUST start (restart) with one of five tritets:
+
+1.  A framing count (group) code in CESR _T_ domain
+2.  A framing count (group) code in CESR _B_ Domain.
+3.  A JSON encoded mapping.
+4.  A CBOR encoded Mapping.
+5.  A MGPK encoded mapping.
+
+A parser merely needs to examine the first tritet (3 bits) of the first byte of the stream start to determine which one of the five it is. When the first tritet is a framing code then, the remainder of the framing code itself will include the additional information needed to parse the attached group. When the first tritet indicates its JSON, CBOR, or MGPK, then the mapping's first field must be a version string that provides the additional information needed to fully parse the associated encoded serialization.
+
+The stream MUST resume with a starting byte that starts with one of the 5 tritets, either another framing code expressed in the _T_ or _B_ domain or a new JSON, CBOR, or MGPK encoded mapping.
+
+This provides an extremely compact and elegant stream parsing formula that generalizes not only support for CESR composability but also support for interleaved CESR with three of the most popular hash map serializations.
+
+As mentioned above, CESR uses a multiple code table design that enables both size-optimized text codes for the most popular primitive types and extensible universal support for all other primitive types. Modern cryptographic suites support limited sets of raw binary primitives with fixed (not variable) sizes. The design aesthetic is based on the understanding that there is a minimally sufficient cryptographic strength and more cryptographic strength is just wasting computation and bandwidth. Cryptographic strength is measured in bits of entropy which also corresponds to the number of trials that must be attempted to succeed in a brute force attack. The accepted minimum for cryptographic strength is 128 bits of entropy or equivalently `2**128` (2 raised to the 128th power) brute force trials. The size in bytes of a given raw binary primitive for a given modern cryptographic suite is usually directly related to this minimum strength of 128 bits (16 bytes). For example, the raw binary primitives from the well-known ||NaCL|| ECC (Elliptic Curve Cryptography) library all satisfy this 128-bit strength goal. In particular, the digital signing public key raw binary primitives for EdDSA are 256 bits (32 bytes) in length because well-known algorithms can reduce the number of trials to brute force invert an ECC public key to get the private key by the square root of the number of scalar multiplications which is also related to the size of both the private key and public key coordinates (discrete logarithm problem ||DLog||). Thus 256 bit (32-byte) ECC keys are needed to achieve 128 bits of cryptographic strength. In general, the size of a given raw binary primitive is typically some multiple of 128 bits of cryptographic strength. This is also true for the associated EdDSA raw binary signatures which are 512 bits (64 bytes) in length.
+
+Similar scale factors exist for cryptographic digests. A standard default Blake3 digest is 256 bits (32 bytes) in length in order to get 128 bits of cryptographic strength. This is also true of SHA3-256. Indeed the sweet spots for modern cryptographic raw primitive lengths are 32 bytes for many digests as well as EdDSA public and private keys as well as ECDSA private keys. Likwise, 64 bytes is the sweetspot for EdDSA and ECDSA-secp256k1 signatures and 64-byte variants of the most popular digests. Therefore optimized text code tables for these two sweet spots (32 and 64 bytes) would be highly advantageous.
+
+A 32-byte raw binary value has a pad size of 1 character.
+```
+(3 - (32 mod 3)) mod 3) = 1
+```
+Therefore the minimal text code size is 1 character for 32-byte raw binary cryptographic material and all other raw binary material values whose pad size is 1 character.
+
+A 64-byte raw binary value has a pad size of 2 characters.
+```
+(3 - (64 mod 3)) mod 3) = 2
+```
+Therefore the minimal text code size is 2 characters for 64-byte raw binary cryptographic material and all other raw binary material values whose pad size is 1 character. For example, a 16-byte raw binary value also has a pad size of 2 characters.
+
+For all other cryptographic material values whose pad size is 0, such as the 33 byte ECDSA public keys then the minimum size text code is 4 characters. So the minimally sized text code tables are 1, 2, and 4 characters respectively.
+
+Given that a given cryptographic primitive type has a known fixed raw binary size then we can efficiently encode that primitive type and size with just the type information. The size is given by the type.
+
+So for example an Ed25519 (EdDSA) raw public key is always 32 bytes so knowing that the type is `Ed25519 public key` implies the size of 32 bytes and a pad size of 1 character that therefore may be encoded with a 1 character text code. Likewise an Ed25519 (EdDSA) signature is always 64 bytes so knowing that the type is `Ed25519 signature` implies the size of 64 bytes and a pad size of 2 characters that therefore may be encoded with a 2 character text code.
+
+In order to efficiently parse a stream of primitives with types from multiple text code tables, the first character in the text code must determine which code table 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. There are 64 Base64 characters (64 values). We only need 12 tables to support all the codes and code formats needed for the foreseeable future. Therefore only 12 of those characters need to be dedicated as code table selectors which leaves 52 characters that may be used for the 1 character type codes in the default table. This gives a total of 13 type code tables consisting of the dual purpose 1 character type or selector code table and 12 other tables.
+
+As described above the selector characters for the framing or count code tables that best support interleaved JSON, CBOR, and MGPK are `-` and `_`. We use the numerals `0` through `9` to each serve as a selector for the other tables. That leaves the letters `A` to `Z` and `a` to `z` as single character selectors. This provides 52 unique type codes for fixed-length primitive types with raw binary values that have a pad size of 1.
+
+To clarify, the first character of any primitive is either a selector or a 1 character code type. The characters `0` through `9`, `-` and `_` are selectors that select a given code table and indicate the number of remaining characters in the text code.
+
+There are two special tables that are dedicated to the most popular fixed size raw binary cryptographic primitive types. These are the most compact so they optimize bandwidth but only provide a small number of total types. In both of these, the text code size equals the number of pad characters, i.e. the pad size.
+
+The one character type code table does not have a selector character per se but uses as type codes the non-selector characters `A` - `Z` and `a` - `z`. This provides 52 unique type codes for fixed-size raw binary values with a pad size of 1.
+
+The two-character type code table uses selector `0` as its first character. The second character is the type code. This provides 64 unique type codes for fixed-size raw binary values that have a pad size of 2.
+
+The three tables in this group are for large fixed raw size primitives. These three tables use 0, 1, or 2 lead bytes as appropriate for a pad size of 0, 1, or 2 for a given fixed raw binary value. The text code size for all three tables is 4 characters. The selector character not only encodes the table but also implicitly encodes the number of lead bytes. The 3 remaining characters is each type code in each table provide 262,144 unique types. This should provide enough type codes to accommodate all fixed raw size primitive types for the foreseeable future.
+
+This table uses `1` as its first character or selector. The remaining 3 characters provide the types codes. Only fixed size raw binaries with a pad size of 0 are encoded with this table. The 3-character type code provides a total of 262,144 unique type code values (`262144 = 64**3)` for fixed-size raw binary primitives with a pad size of 0.
+
+This table uses `2` as its first character or selector. The remaining 3 characters provide the types codes. Only fixed size raw binaries with a pad size of 1 are encoded with this table. The 3 character type code provides a total of 262,144 unique type code values (`262144 = 64**3)` . Together with the 52 values from the 1 character code table above there are 262,196 type codes for fixed-size raw binary primitives with a pad size of 1.
+
+This table uses `3` as its first character or selector. The remaining 3 characters provide the types codes. Only fixed size raw binaries with a pad size of 2 are encoded with this table. The 3 character type code provides a total of 262,144 unique type code values (`262144 = 64**3)` . Together with the 64 values from the 2 character code table above (selector `0`), there are 262,208 type codes for fixed-size raw binary primitives with a pad size of 2.
+
+Although many primitives have fixed raw binary sizes, especially those for modern cryptographic suites such as keys, signatures, and digests, there are other primitives that benefit from variable sizing such as encrypted material or legacy cryptographic material types like RSA found in GPG or OpenSSL libraries. Indeed CESR is meant to support not only cryptographic material types but other basic types such as generic text strings and numbers. These benefit from variable-size codes.
+
+The three tables in this group are for small variable raw size primitives. These three tables use 0, 1, or 2 lead bytes as appropriate given the pad size of 0, 1, or 2 for a given variable size raw binary value. The text code size for all three tables is 4 characters. The first character is the selector, the second character is the type, and the last two characters provide the size of the value as a Base64 encoded integer. The number of unique type codes in each table is therefore 64. A given type code is repeated in each table for the same type so that all that differs is the number of lead bytes needed to align a given length on a twenty-four bit boundary. To clarify, what is different in each table is the number of lead bytes to twenty-four bit align a given variable length. Thus, the selector not only encodes for which type 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 value lengths of up to 16,380 characters (`4095 • 4`) or 12,285 bytes (`4095 • 3`).
+
+This table uses `4` as its first character or selector. The second character provides the type. The final two characters provide the size of the value in quadlets/triplets as a Base64 encoded integer. Only raw binaries with a pad size of 0 are encoded with this table. The 1-character type code provides a total of 64 unique type code values. The maximum length of the value provided by the 2 size characters is 4095 quadlets of characters in the _T_ domain and triplets of bytes in the _B_ domain. All are raw binary primitives with a pad size of 0 that each includes 0 lead bytes.
+
+This table uses `5` as its first character or selector. The second character provides the type. The final two characters provide the size of the value in quadlets/triplets as a Base64 encoded integer. Only raw binaries with a pad size of 1 are encoded with this table. The 1-character type code provides a total of 64 unique type code values. The maximum length of the value provided by the 2 size characters is 4095 quadlets of characters in the _T_ domain and triplets of bytes in the _B_ domain. All are raw binary primitives with a pad size of 1 that each includes 1 lead byte.
+
+This table uses `6` as its first character or selector. The second character provides the type. The final two characters provide the size of the value in quadlets/triplets as a Base64 encoded integer. Only raw binaries with a pad size of 0 are encoded with this table. The 1-character type code provides a total of 64 unique type code values. The maximum length of the value provided by the 2 size characters is 4095 quadlets of characters in the _T_ domain and triplets of bytes in the _B_ domain. All are raw binary primitives with a pad size of 2 that each includes 2 lead bytes.
+
+Many legacy cryptographic libraries such as OpenSSL and GPG support any variable-sized primitive for keys, signatures, and digests such as RSA. Although this approach is often criticized for providing too much flexibility, many legacy applications depend on this degree of flexibility. Consequently, these large variable raw size tables provide a sufficiently expansive set of tables with enough types and sizes to accommodate all the legacy cryptographic libraries as well as all the variable-sized non-cryptographic raw primitive types for the foreseeable future.
+
+The three tables in this group are for large variable raw size primitives. These three large variable raw size tables use 0, 1, or 2 lead bytes as appropriate for the associated pad size of 0, 1, or 2 for a given variable-sized raw binary value. The text code size for all three tables is 8 characters. As a special case, the first 62 entries in these tables represent that same crypto suite type as the 62 entries in the small variable raw size tables above. This allows one type to use a smaller 4-character text code when the raw size is small enough.
+
+The first character is the selector, the next three characters provide the type, and the last four characters provide the size of the value as a Base64 encoded integer. With 3 characters for each unique type code, each table provides 262,144 unique type codes. This should be enough type codes to accommodate all fixed raw size primitive types for the foreseeable future. A given type code is repeated in each table for the same type. What is different for each table is the number of lead bytes needed to align a given length on a twenty-four bit boundary. 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. Likewise computing the number of bytes when parsing or off-loading in the _B_ domain means multiplying the variable size by 3. The four Base64 size characters provide value lengths in quadlets/triplets from 0 to 16,777,215 (`64**4 -1`). This corresponds to value lengths of up to 67,108,860 characters (`16777215 • 4`) or 50,331,645 bytes (`16777215 • 3`).
+
+This table uses `7` as its first character or selector. The next three characters provide the type. The final four characters provide the size of the value in quadlets/triplets as a Base64 encoded integer. Only raw binaries with a pad size of 0 are encoded with this table. The 3-character type code provides a total of 262,144 unique type code values. The maximum length of the value provided by the 4 size characters is 16,777,215 quadlets of characters in the _T_ domain and triplets of bytes in the _B_ domain. All are raw binary primitives with pad size of 0 that each includes 0 lead bytes.
+
+This table uses `8` as its first character or selector. The next three characters provide the type. The final four characters provide the size of the value in quadlets/triplets as a Base64 encoded integer. Only raw binaries with a pad size of 1 are encoded with this table. The 3-character type code provides a total of 262,144 unique type code values. The maximum length of the value provided by the 4 size characters is 16,777,215 quadlets of characters in the _T_ domain and triplets of bytes in the _B_ domain. All are raw binary primitives with a pad size of 1 that each includes 1 lead byte.
+
+This table uses `9` as its first character or selector. The next three characters provide the type. The final four characters provide the size of the value in quadlets/triplets as a Base64 encoded integer. Only raw binaries with a pad size of 2 are encoded with this table. The 3-character type code provides a total of 262,144 unique type code values. The maximum length of the value provided by the 4 size characters is 16,777,215 quadlets of characters in the _T_ domain and triplets of bytes in the _B_ domain. All are raw binary primitives with a pad size of 2 that each includes 2 lead bytes.
+
+There may be as many at 13 count code tables, but only two are currently specified. These two are the small count, four-character table, and the large count, eight-character table. Because count codes only count quadlets/triplets or the number of primitives or groups of primitives, count codes have no value component but have only type and size components. Because primitives are already guaranteed to be composable, count codes do not need to account for pad size as long as the count code itself is aligned on a 24-bit boundary. The count code type indicates the type of primitive or group being counted and the size indicates either how many of that type are in the group or the number of quadlets/triplets consumed by that group. Both count code tables use the first two characters as a nested set of selectors. The first selector uses`-` as the initial selector for count codes. The next character is either a selector for another count code table or is the type for the small count code table. When the second character is numeral `0` - `9` or the letters `-` or `_` then it is a secondary count code table selector. When the second character is a letter in the range `A` - `Z` or `a` - `z` then it is a unique count code type. This gives a total of 52 single-character count code types.
+
+Codes in the small count code table are each four characters long. The first character is the selector `-`. The second character is the count code type. the last two characters are the count size as a Base64 encoded integer. The count code type MUST be a letter `A` - `Z` or `a` - `z`. If the second character is not a letter but is a numeral `0` - `9` or `-` or `_` then it is a selector for a different count code table. The set of letters provides 52 unique count codes. A two-character size provides counts from 0 to 4095 (`64**2 - 1`).
+
+Codes in the large count code table are each 8 characters long. The first two characters are the selectors `-`0\. The next two characters are the count code type. the last four characters are the count size as a Base64 encoded integer. With two characters for type, there are 4096 unique large count code types. A four-character size provides counts from 0 to 16,777,215 (`64**4 - 1`).
+
+The `_` selector is reserved for the yet to be defined opcode table or tables. 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 excecuted using a set of opcodes that provides primitive, primitive group, or stream processing instructions. This would enable highly customizable uses for CESR.
+
+The following table summarizes the _T_ domain coding schemes by selector code for the 13 code tables defined above.
+
+| Selector | Selector | Type Chars | Value Size Chars | Code Size | Lead Bytes | Pad Size | Format |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+|  |  |  |  |  |  |  |  |
+| `[A-Z,a-z]` |  | 1\* | 0 | 1 | 0 | 1 | `$&&&` |
+| `0` |  | 1 | 0 | 2 | 0 | 2 | `0$&&` |
+| `1` |  | 3 | 0 | 4 | 0 | 0 | `1$$$&&&&` |
+| `2` |  | 3 | 0 | 4 | 1 | 1 | `2$$$%&&&` |
+| `3` |  | 3 | 0 | 4 | 2 | 2 | `3$$$%%&&` |
+| `4` |  | 1 | 2 | 4 | 0 | 0 | `4$##&&&&` |
+| `5` |  | 1 | 2 | 4 | 1 | 1 | `5$##%&&&` |
+| `6` |  | 1 | 2 | 4 | 2 | 2 | `6$##%%&&` |
+| `7` |  | 3 | 4 | 8 | 0 | 0 | `7$$$####&&&&` |
+| `8` |  | 3 | 4 | 8 | 1 | 1 | `8$$$####%&&&` |
+| `9` |  | 3 | 4 | 8 | 2 | 2 | `9$$$####%%&&` |
+| `-` | `[A-Z,a-z]` | 1\* | 0 | 4 | 0 | 0 | `-$##` |
+| `-` | `0` | 2 | 0 | 8 | 0 | 0 | `-0$$####` |
+| `_` |  | TBD | TBD | TBD | TBD | TBD | `_` |
+
+The following table defines the meaning of the symbols used in the encoding scheme table
+
+| Symbol | Description |
+| --- | --- |
+
+|  |  |
+| `*` | selector-code character also provides the type |
+| `$` | type-code character from subset of Base64 `[A-Z,a-z,0-9,-,_]` |
+| `%` | lead byte where pre-converted binary includes the number of lead bytes shown |
+| `#` | Base64 digit as part of a base 64 integer. When part of primitive determines the number of following quadlets or triplets. When part of a count code determines the count of following primitives or groups of primitives |
+| `&` | Base64 value characters that represent the converted raw binary value. The actual number of characters is determined by the prepended text code. Shown is the minimum number of value characters. |
+| `TBD` | to be determined, reserved for future |
+
+Text domain parsing can be simplified by using a parse size table. A text domain parser uses the first character selector code to look up the hard size (stable) portion of the text code. The parse then extracts hard size characters from the text stream. These characters form an index into the parse size table which includes a set of sizes for the remainder of the primitive. Using these sizes for a given code allows a parser to extract and convert a given primitive. In the binary domain, the same text parse table may be used but each size value represents a multiple of a sextet of bits instead of Base64 characters. Example entries from that table are provided below. Two of the rows may always be calculated given the other 4 rows so the table need only have 4 entries in each row. Thus all basic primitives may be parsed with one parse size table.
+
+| selector | hs |
+| --- | --- |
+
+|  |  |
+| `B` | 1 |
+| `0` | 2 |
+| `5` | 2 |
+|  |  |
+
+Below is a snippet from the Parse Size Table for some example codes
+
+| hard sized index | hs | ss | vs | fs | ls | ps |
+| --- | --- | --- | --- | --- | --- | --- |
+
+|  |  |  |  |  |  |  |
+| `B` | 1 | 0 | 43\* | 44 | 0 | 1 |
+| `0B` | 2 | 0 | 86\* | 88 | 0 | 2\* |
+| `5A` | 2 | 2 | # | # | 1 | 1\* |
+|  |  |  |  |  |  |  |
+
+| Symbol | Description |
+| --- | --- |
+
+|  |  |
+| `*` | entry's size may be calculated from other sizes |
+| `#` | entry's size may be calculated from extracted code characters given by other sizes |
+|  |  |
+
+The following table includes both labels of parts shown in the columns in the Parse Size table as well as parts that may be derived from the Parse Table parts or from transformations,
+
+| Label | Description |
+| --- | --- |
+
+| _**hs**_ | hard (fixed) part of code size in chars |
+| _**ss**_ | soft (variable) part of code size in chars |
+| _cs_ | derived value size in chars where where _cs = hs + ss_ |
+| _**vs**_ | value size in chars |
+| _**fs**_ | full size in chars where _fs = hs + ss + vs_ |
+| _**ls**_ | lead size in bytes to prepad raw binary bytes |
+| _**ps**_ | Base64 encoded pad size in chars |
+| _rs_ | derived raw size in bytes of binary valure where \*rs is derived from `R(T)` |
+| _bs_ | derived binary size in bytes where where _bs = ls + rs_ |
+
+The set of tables above provide the basic or master encoding schemes. These coding schemes constitute the basic or master set of code tables. This basic or master set, however, may be extended with context-specific code tables. The context in which a primitive occurs may provide an additional implicit selector that is not part of the actual explicit text code. This allows context-specific coding schemes that would otherwise conflict with the basic or master encoding schemes and tables. Currently, there is only one context-specific coding scheme, that is, for indexed signatures. A common use case is thresholded multi-signature schemes. A threshold satisficing subset of signatures belonging to an ordered set or list of public keys may be provided as part of a stream of primitives. 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. The typical raw binary size for a signature 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. By using a similar dual selector type code character scheme as above, where the selectors are the numbers `0-9` and `-` and `_`. Then there are 52 type codes given by the letters `A- Z` and `a-z`. The index has 64 values which support up to 64 members in the public key list. A selector can be used to select a large text code with more characters dedicated to larger indices. Current only a small table is defined.
+
+A new signature scheme based on Ed448 with 114-byte signatures is also supported. These signatures have a pad size of zero so require a four-character text code. The first character is the selector `0`, the second character is the type with 64 values, and the last two characters provide the index as a Base64 encoded integer with 4096 different values.
+
+The associated indexed schemes are provided in the following table.
+
+| Selector | Selector | Type Chars | Index Chars | Code Size | Lead Bytes | Pad Size | Format |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+
+|  |  |  |  |  |  |  |  |
+| `[A-Z,a-z]` |  | 1\* | 1 | 2 | 0 | 2 | `$#&&` |
+| `0` |  | 1 | 2 | 4 | 0 | 0 | `0$##&&&&` |
+|  |  |  |  |  |  |  |  |
+
+The following table defines the meaning of the symbols used in the Indexed Code table
+
+| Symbol | Description |
+| --- | --- |
+
+|  |  |
+| `*` | selector-code character also provides the type |
+| `$` | type-code character from subset of Base64 `[A-Z,a-z,0-9,-,_]` |
+| `%` | lead byte where pre-converted binary includes the number of lead bytes shown |
+| `#` | Base64 digit as part of a base 64 integer. When part of primitive determines the number of following quadlets or triplets. When part of a count code determines the count of following primitives or groups of primitives |
+| `&` | Base64 value characters that represent the converted raw binary value. The actual number of characters is determined by the prepended text code. Shown is the minimum number of value characters. |
+| `TBD` | to be determined, reserved for future |
+
+The appendix contains the master code table with the concrete codes.
+
+# Appendix: Master Code Table
+
+The approach to filling the tables is a first needed first-served basis. In addition, the compact code tables prioritize entries that satisfy the requirement cryptographic operations maintain at least 128 bits of cryptographic strength. This precludes the entry of many weak cryptographic suites into the compact tables. CESR's compact code table includes only best-of-class cryptographic operations along with common non-cryptograpic primitive types. At the time of this writing, there is the expectaion that NIST will soon approve standardized post-quantum resistant cryptographic operations. When that happens, codes for the most appropriate post-quantum operations will be added. For example, Falcon appears to be one of the leading candidates with open source code already available.
+
+This master table includes all the different types of codes grouped and separated by headers. The table has 5 columns. These are as follows:
+
+1.  The Base64 stable (hard) text code itself.
+2.  A description of what is encoded or appended to the code.
+3.  The length in characters of the code.
+4.  the length in characters of the index or count portion of the code
+5.  The length in characters of the fully qualified primitive including code and append material or number of elements in the group.
+
+| Code | Description | Code Length | Count or Index Length | Total Length |
+| --- | --- | --- | --- | --- |
+
+|  | **Basic One Character Codes** |  |  |  |
+| `A` | Random seed of Ed25519 private key of length 256 bits | 1 |  | 44 |
+| `B` | Ed25519 non-transferable prefix public signing verification key. Basic derivation. | 1 |  | 44 |
+| `C` | X25519 public encryption key. May be converted from Ed25519 public signing verification key. | 1 |  | 44 |
+| `D` | Ed25519 public signing verification key. Basic derivation. | 1 |  | 44 |
+| `E` | Blake3-256 Digest. Self-addressing derivation. | 1 |  | 44 |
+| `F` | Blake2b-256 Digest. Self-addressing derivation. | 1 |  | 44 |
+| `G` | Blake2s-256 Digest. Self-addressing derivation. | 1 |  | 44 |
+| `H` | SHA3-256 Digest. Self-addressing derivation. | 1 |  | 44 |
+| `I` | SHA2-256 Digest. Self-addressing derivation. | 1 |  | 44 |
+| `J` | Random seed of ECDSA secp256k1 private key of length 256 bits | 1 |  | 44 |
+| `K` | Random seed of Ed448 private key of length 448 bits | 1 |  | 76 |
+| `L` | X448 public encryption key. May be converted from Ed448 public signing verification key. | 1 |  | 76 |
+| `M` | Short value of length 16 bits | 1 |  | 4 |
+|  | **Basic Two Character Codes** |  |  |  |
+| `0A` | Random salt, seed, private key, or sequence number of length 128 bits | 2 |  | 24 |
+| `0B` | Ed25519 signature. Self-signing derivation. | 2 |  | 88 |
+| `0C` | ECDSA secp256k1 signature. Self-signing derivation. | 2 |  | 88 |
+| `0D` | Blake3-512 Digest. Self-addressing derivation. | 2 |  | 88 |
+| `0E` | Blake2b-512 Digest. Self-addressing derivation. | 2 |  | 88 |
+| `0F` | SHA3-512 Digest. Self-addressing derivation. | 2 |  | 88 |
+| `0G` | SHA2-512 Digest. Self-addressing derivation. | 2 |  | 88 |
+| `0H` | Long value of length 32 bits | 2 |  | 8 |
+|  | **Basic Four Character Codes** |  |  |  |
+| `1AAA` | ECDSA secp256k1 non-transferable prefix public signing verification key. Basic derivation. | 4 |  | 48 |
+| `1AAB` | ECDSA secp256k1 public signing verification or encryption key. Basic derivation. | 4 |  | 48 |
+| `1AAC` | Ed448 non-transferable prefix public signing verification key. Basic derivation. | 4 |  | 80 |
+| `1AAD` | Ed448 public signing verification key. Basic derivation. | 4 |  | 80 |
+| `1AAE` | Ed448 signature. Self-signing derivation. | 4 |  | 156 |
+| `1AAF` | Tag Base64 4 chars or 3 byte number | 4 |  | 8 |
+| `1AAG` | DateTime Base64 custom encoded 32 char ISO-8601 DateTime | 4 |  | 36 |
+|  | **Indexed Two Character Codes** |  |  |  |
+| `A#` | Ed25519 indexed signature | 2 | 1 | 88 |
+| `B#` | ECDSA secp256k1 indexed signature | 2 | 1 | 88 |
+|  | **Indexed Four Character Codes** |  |  |  |
+| `0A##` | Ed448 indexed signature | 4 | 2 | 156 |
+| `0B##` | Label Base64 chars of variable length `L=N*4` where N is value of index | 4 | 2 | Variable |
+|  | **Counter Four Character Codes** |  |  |  |
+| `-A##` | Count of attached qualified Base64 indexed controller signatures | 4 | 2 | 4 |
+| `-B##` | Count of attached qualified Base64 indexed witness signatures | 4 | 2 | 4 |
+| `-C##` | Count of attached qualified Base64 nontransferable identifier receipt couples pre+sig | 4 | 2 | 4 |
+| `-D##` | Count of attached qualified Base64 transferable identifier receipt quadruples pre+snu+dig+sig | 4 | 2 | 4 |
+| `-E##` | Count of attached qualified Base64 first seen replay couples fn+dt | 4 | 2 | 4 |
+| `-F##` | Count of attached qualified Base64 transferable indexed sig groups pre+snu+dig + idx sig group | 4 | 2 | 4 |
+|  |  |  |  |  |
+| `-U##` | Count of qualified Base64 groups or primitives in message data | 4 | 2 | 4 |
+| `-V##` | Count of total attached grouped material qualified Base64 4 char quadlets | 4 | 2 | 4 |
+| `-W##` | Count of total message data grouped material qualified Base64 4 char quadlets | 4 | 2 | 4 |
+| `-X##` | Count of total group message data plus attachments qualified Base64 4 char quadlets | 4 | 2 | 4 |
+| `-Y##` | Count of qualified Base64 groups or primitives in group. (context dependent) | 4 | 2 | 4 |
+| `-Z##` | Count of grouped material qualified Base64 4 char quadlets (context dependent) | 4 | 2 | 4 |
+|  |  |  |  |  |
+| `-a##` | Count of anchor seal groups in list (anchor seal list) (a) | 4 | 2 | 4 |
+| `-c##` | Count of config traits (each trait is 4 char quadlet (configuration trait list) (c) | 4 | 2 | 4 |
+| `-d##` | Count of digest seal Base64 4 char quadlets in digest (digest seal (d) | 4 | 2 | 4 |
+| `-e##` | Count of event seal Base64 4 char quadlets in seal triple of (event seal) (i, s, d) | 4 | 2 | 4 |
+| `-k##` | Count of keys in list (key list) (k) | 4 | 2 | 4 |
+| `-l##` | Count of locations seal Base64 4 char quadlets in seal quadruple of (location seal) (i, s, t, p) | 4 | 2 | 4 |
+| `-r##` | Count of root digest seal Base64 4 char quadlets in root digest (root digest) (rd) | 4 | 2 | 4 |
+| `-w##` | Count of witnesses in list (witness list or witness remove list or witness add list) (w, wr, wa) | 4 | 2 | 4 |
+|  | **Counter Eight Character Codes** |  |  |  |
+| `-0U#####` | Count of qualified Base64 groups or primitives in message data | 8 | 5 | 8 |
+| `-0V#####` | Count of total attached grouped material qualified Base64 4 char quadlets | 8 | 5 | 8 |
+| `-0W#####` | Count of total message data grouped material qualified Base64 4 char quadlets | 8 | 5 | 8 |
+| `-0X#####` | Count of total group message data plus attachments qualified Base64 4 char quadlets | 8 | 5 | 8 |
+| `-0Y#####` | Count of qualified Base64 groups or primitives in group (context dependent) | 8 | 5 | 8 |
+| `-0Z#####` | Count of grouped material qualified Base64 4 char quadlets (context dependent) | 8 | 5 | 8 |
+|  |  |  |  |  |
+| `-0a#####` | Count of anchor seals (seal groups in list) | 8 | 5 | 8 |
+
+The table includes complex groups that are composed of other groups. For example, consider the counter attachment group with code `-F##` where `##` is replaced by the two-character Base64 count of the number of complex groups. This is known as the TransIndexedSigGroups counter. Within the complex group are one or more attached groups where each group consists of a triple pre+snu+dig followed by a ControllerIdxSigs group that in turn consists of a counter code `-A##` followed by one or more indexed signature primitives. The following example details how this complex group may appear.
+
+The example has only one group. The example is annotated with comments, spaces and line feeds for clarity.
+```
+-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
+AA5267UlFg1jHee4Dauht77SzGl8WUC_0oimYG5If3SdIOSzWM8Qs9SFajAilQcozXJVnbkY5stG_K4NbKdNB4AQ         # sig 0
+ABBgeqntZW3Gu4HL0h3odYz6LaZ_SMfmITL-Btoq_7OZFe3L16jmOe49Ur108wH7mnBaq2E_0U0N0c5vgrJtDpAQ    # sig 1
+ACTD7NDX93ZGTkZBBuSeSGsAQ7u0hngpNTZTK_Um7rUZGnLRNJvo5oOnnC1J2iBQHuxoq8PyjdT3BHS2LiPrs2Cg  # sig 2
+```
+# Conventions and Definitions
+
+(::boilerplate bcp14-tagged)
+
+# Security Considerations
+
+TODO Security
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+\--- back
+
+# Acknowledgments
+
+(:numbered\="false")
+
+The keripy development team, the KERI community, and the ToIP ACDC working group.
+
+
+
+
+---
+title: draft-ssmith-acdc
+description: title: "Authentic Chained Data Containers (ACDC)"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-acdc/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-acdc/index.md
+---
+
+# 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\]
+
+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
+
+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
+
+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"
+
+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)" 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)" 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)" 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)" 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
+
+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
+
+# Introduction
+
+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.
+
+# ACDC Fields
+
+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.
+
+# Schema Section
+
+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)".
+
+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.
+
+# ACDC Variants
+
+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.
+
+# Unpermissioned Exploitation of Data
+
+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||.
+
+ACDCS employ several mechanisms to protect against _unpermissioned exploitation of data_. These are:
+
+-   Chain-link Confidentiality ||CLC||
+-   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 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.
+
+# Field Ordering
+
+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`.
+
+# Compact ACDC
+
+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
+}
+```
+# Attribute Section
+
+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.
+
+# Edge Section
+
+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 "point 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 a 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 simple, compact, 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.
+
+# Rule Section
+
+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.
+
+# Disclosure-Specific (Bespoke) Issued ACDCs
+
+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."
+    }
+  }
+}
+```
+# Informative Examples
+```
+{
+  "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
+}
+```
+# Selective Disclosure
+
+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.
+
+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.
+
+# Extensibility
+
+ToDo append-to-extend
+
+# Appendix: Performance and Scalability
+
+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.
+
+# Appendix: Cryptographic Strength and Security
+
+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_.
+
+# Conventions and Definitions
+
+(::boilerplate bcp14-tagged)
+
+-   `SAID` - Self-Addressing Identifier - any identifier which is deterministically generated out of the content, digest of the content
+
+# Security Considerations
+
+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.
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+\--- back
+
+# Acknowledgments
+
+(:numbered\="false")
+
+ACDC community.
+
+
+
+
+---
+title: draft-pfeairheller-ptel
+description: title: "Public Transaction Event Logs (PTEL)"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-ptel/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-ptel/index.md
+---
+
+# draft-pfeairheller-ptel
+
+title: "Public Transaction Event Logs (PTEL)" abbrev: "PTEL" docname: draft-pfeairheller-ptel-latest category: info
+
+ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
+
+stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
+
+name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](mailto:Philip.Feairheller@gleif.org)
+
+normative:
+
+informative:
+
+\--- abstract
+
+TODO Abstract
+
+\--- middle
+
+# Introduction
+
+The _Transaction Event Log_ (TEL) is a hash linked data structure of transactions that can be used to track state. A _Public Verifiable Credential Registry_ can be represented in several TELs to establish issuance or revocation state of a Verifiable Credential (VC). The KEL 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. This document specifies a design for _public_ VCs only. The use of a hash digest of the VC contents as the identifier of that VC or an attribute in a TEL event allows for correlation of uses of the VC.
+
+A KERI KEL can control a TEL by anchoring the TEL to key events of the KEL with the following:
+
+1.  Create the inception event for the TEL with the TEL specific unique identifier.
+2.  Generate a hash digest of the serialized content of the TEL inception event.
+3.  Attach anchoring seals from the KEL events to the TEL events they are authorizing.
+4.  Sign the KEL event as usual to commit to the digest of the serialized TEL event.
+
+Any validator can cryptographically verify the authoritative state by validating the signatures of the referenced KEL. The TEL events do not have to be signed as the commitment to the event is in the form of the digest in the seal in the anchoring KEL event and the signatures on that event. Like KEL events, all TEL events have the fields `i`, `s`, and `t`. However, the `s` or sequence number field in TEL events represents the "clock" for that transaction set. Each transaction set can have its own "clock" (e.g. bitcoin block height, wall clock, etc) and is independent of the sequence number of the KEL events. In the case of the Verifiable Credential Registry, the `s` field is simply a monotonically increasing integer.
+
+The events are anchored back to the KEL using Event Source Seals whose JSON representation is as follows.
+```
+{
+ "s": "3",
+ "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM"
+}
+```
+For TEL events, this seal back to the KEL will be delivered as an attachment of event source seal triples in duple of (s, d).
+```
+-GAB
+0AAAAAAAAAAAAAAAAAAAAAAw
+ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM
+```
+Event source seal attachment example (line feeds added for readability)
+
+A _Public Verifiable Credential Registry_ (Registry) is a form of a _Verifiable Data Registry_ that tracks the issuance/revocation state of credentials issued by the controller of the KEL. Two types of TELs will be used for this purpose. The first type of TEL is the management TEL and will signal the creation of the Registry and track the list of Registrars that will act as Backers for the individual TELs for each VC. 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 it's corresponding management TEL.
+
+The following events will be used to create and maintain the TELs for the Registry.
+
+| Ilk | TEL | Name | Description |
+| --- | --- | --- | --- |
+
+| vcp | Management | Registry Inception Event | Inception statement for the Registry |
+| vrt | Management | Registry Rotation Event | Rotation event for updating Backers |
+| iss | VC | Simple Credential Issuance Event | Issue credential with no Backers |
+| rev | VC | Simple Credential Revocation Event | Revoke previously issued credential with no Backers |
+| bis | VC | Credential Issuance Event | Issue credential |
+| brv | VC | Credential Revocation Event | Revoke previously issued credential |
+| iis | VC | Simple Credential Issuance Event with VC Hash | Issue credential with no Backers, VC Hash as separate field |
+| irv | VC | Simple Credential Revocation Event with VC Hash | Revoke previously issued credential with no Backers, VC Hash as separate field |
+| ibs | VC | Credential Issuance Event with VC Hash | Issue credential, VC Hash as separate field |
+| ibr | VC | Credential Revocation Event with VC Hash | Revoke previously issued credential, VC Hash as separate field |
+
+The state tracked by the Management TEL will be the list of Registrar identifiers that serve as backers for each TEL under its provenance. This list of Registrars can be rotated with events specific to this type of TEL. In this way, Registrar lists are analogous to Backer lists in KERI KELs. Additional metadata can be tracked in this TEL, for example references to Schema. The Management TEL will have two events: `vcp` for Registry inception and `vrt` for rotation of the list or Registrars. The events will reference the controlling identifier in the `ii` field and be anchored to the KEL with an event seal triple attachment.
+
+The Registry specific identifier will be self-addressing (see [below](#self-addressing-identifiers) for definition) using its inception data for its derivation. This requires a commitment to the anchor in the controlling KEL and necessitates the event location seal be included in the event. The derived identifier is then set in the `i` field of the events in the management TEL.
+
+Though it is possible for a given identifier KEL to issue multiple types of credentials, it is anticipated that there will be relatively few (usually one) Management TELs anchored to a given KEL. A more scalable approach to issuing multiple credential types from a single identifier would be to use delegated identifiers for the different types of credentials to be issued.
+
+| Label | Description | Notes |
+| --- | --- | --- |
+
+| v | version string |  |
+| i | namespaced identifier of Registry |  |
+| s | sequence number of event |  |
+| t | message type of event |  |
+| p | prior event digest |  |
+| c | list of Configuration Traits/Modes | allows for config of no backer registry |
+| a | digest seal of attachment meta-data for registry |  |
+| ii | issuer identifier |  |
+| vi | hash digest of VC contents |  |
+| b | list of backer identifiers for credentials associated with this registry |  |
+| bt | backer threshold |  |
+| ba | list of backers to add (ordered backer set) |  |
+| br | list of backers to remove (ordered backer set) |  |
+
+The simplest (and most common) case for Registries relies on the witnesses of the controlling KEL and their receipts of the KEL events instead of Registry specific backers. To accommodate this case, the `c` element is added to the management TEL inception event with the configuration option `NB` to specify that the Registry will never have backers configured in the management TEL. In this case, there will only be one event in the management TEL for this Registry and the simple events `iss` and `rev` will be used for "simple issue" and "simple revoke" respectively in the VC specific TELs. For these events, the `ri` field will be the simple identifier referencing the management TEL.
+
+| Option | Description | Notes |
+| --- | --- | --- |
+
+| NB | No Backers | No registry specific backers will be configured for this Registry |
+```
+{
+ "v" : "KERI10JSON00011c_",
+ "i" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+ "ii": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
+ "s" : "0",
+ "t" : "vcp",
+ "b" : ["BbIg_3-11d3PYxSInLN-Q9_T2axD6kkXd3XRgbGZTm6s"],
+ "c" : []
+ "a" : {
+     "d": "EEBp64Aw2rsjdJpAR0e2qCq3jX7q7gLld3LjAwZgaLXU"
+  }
+}-GAB0AAAAAAAAAAAAAAAAAAAAABwEOWdT7a7fZwRz0jiZ0DJxZEM3vsNbLDPEUk-ODnif3O0
+```
+Registry inception event for establishing the list of Backers
+```
+{
+ "v" : "KERI10JSON00011c_",
+ "i" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+ "ii": "EJJR2nmwyYAfSVPzhzS6b5CMZAoTNZH3ULvaU6Z-i0d8",
+ "s" : "0",
+ "t" : "vcp",
+ "b" : [],
+ "c" : ["NB"]
+}-GAB0AAAAAAAAAAAAAAAAAAAAABwEOWdT7a7fZwRz0jiZ0DJxZEM3vsNbLDPEUk-ODnif3O0
+```
+Registry inception event for "backer-less" configuration
+```
+{
+ "v" : "KERI10JSON00011c_",
+ "i" : "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+ "p" : "EY2L3ycqK9645aEeQKP941xojSiuiHsw4Y6yTW-PmsBg",
+ "s" : "1",
+ "t" : "vrt",
+ "ba" : ["BXhpfP_H41hw8f-LluTidLfXxmC4EPwaENHI6CuruE6g"],
+ "br" : ["BbIg_3-11d3PYxSInLN-Q9_T2axD6kkXd3XRgbGZTm6s"]
+}-GAB0AAAAAAAAAAAAAAAAAAAAACQEOWdT7a7fZwRz0jiZ0DJxZEM3vsNbLDPEUk-ODnif3O0
+```
+Registrar rotation event updates the list of Backers
+
+The binary state (issued or revoked) of each verifiable credential (VC) will be tracked in individual TELs associated with each VC. The state changes will be represented by 4 sets of 2 events: `iss` for simple VC issuance and `rev` for simple revocation, `bis` for the issuance of the VCs with backers and `brv` for revocation of the VCs with backers and corresponding events `iis`, `irv` and `ibs`, `ibr` to be used when the identifier of the VC is not the self-addressing identifier of the VC and that identifier must be included is the separate `vi` field in the event. The events will be anchored to the KEL with an event seal triple attachment signified by the grouping counter `-e##`.
+
+The advantage of a content addressable identifier is that it is cryptographically bound to the contents. It provides a secure root-of-trust. Any cryptographic commitment to a content addressable identifier is functionally equivalent (given comparable cryptographic strength) to a cryptographic commitment to the content itself.
+
+A self-addressing identifier is a special class content-addressable identifier that is also self-referential. The special class is distinguished by a special derivation method or process to generate the self-addressing identifier. This derivation method is determined by the combination of both a derivation code prefix included in the identifier and the context in which the identifier appears. The reason for a special derivation method is that a naive cryptographic content addressable identifier must not be self-referential, i.e. the identifier must not appear within the contents that it is identifying. This is because the naive cryptographic derivation process of a content addressable identifier is a cryptographic digest of the serialized content. Changing one bit of the serialization content will result in a different digest. A special derivation method or process is required.
+
+This process is as follows:
+
+-   replace the value of the id field in the content that will hold the self-addressing identifier with a dummy string of the same length as the eventually derived self-addressing identifier
+-   compute the digest of the content with the dummy value for the id field
+-   prepend the derivation code to the digest and encode appropriately to create the final derived self-addressing identifier replace the dummy value with the self-addressing identifier
+
+As long as any verifier recognizes the derivation method, the 'self-addressing\` identifier is a cryptographically secure commitment to the contents in which it is embedded. It is a cryptographically verifiable self-referential content addressable identifier.
+
+Because a self-addressing identifier is both self-referential and cryptographically bound to the contents it identifies, anyone can validate this binding if they follow the binding protocol outlined above.
+
+To elaborate, this approach of deriving self-referential identifiers from the contents they identify, we call self-addressing. It allows a verifier to verify or re-derive the self-referential identifier given the contents it identifies. To clarify, a self-addressing identifier is different from a standard content address or content addressable identifier in that a standard content addressable identifier may not be included inside the contents it addresses. The standard content addressable identifier is computed on the finished immutable contents and therefore is not self-referential.
+
+`ii` issuer identifier is the controller prefix is self-certifying and may be also self-addressing (but may not be) wrt to its inception event (For GLEIF TELS the issuer identifier must be self-addressing)
+
+`ri`, `i` registry identifier is self-addressing wrt the registry inception event `i` VC identifier is self-addressing wrt to the VC itself
+
+There are two options for including a cryptographic commitment to the VC in the TEL VC events. The identifier of the VC can self-addressing using the same technique KERI uses for self-addressing identifiers. The VC identifier can be created by padding the VC `id` field and taking a hash digest of the serialized contents of the VC. This form of self-addressing identifier can be used as the `i` field in the TEL `iss`, `rev`, `bis` and `brv` events and no other reference to the VC is required. When the identifier of the VC is derived from some other method, the TEL events `iis`, `irv`, `ibs` and `ibr` are used, and a hash digest of the contents of the VC is placed in the `vi` field.
+
+The VC identifier can be namespaced using DID syntax. In this case, the VC identifier in the TEL events would be the method specific identifier of the full DID. For informational purposes, the fully qualified DID can be included as an attachment to the TEL events.
+
+The list of backers needed to sign each VC TEL event is maintained by the management TEL. Since that list can change over time with the `rot` management events listed above, the non-simple VC events (`bis`, `brv`) must be anchored to the event in the management TEL at the point when the VC event is published with the `ra` field. This way, the backer signatures can be indexed into the proper list of backers at the time of issuance or revocation.
+
+| Label | Description | Notes |
+| --- | --- | --- |
+
+| v | version string |  |
+| i | namespaced identifier of VC |  |
+| s | sequence number of event |  |
+| t | message type of event |  |
+| dt | issuer system data/time in iso format |  |
+| p | prior event digest |  |
+| ri | registry identifier from management TEL |  |
+| ra | registry anchor to management TEL |  |
+```
+{
+ "v" : "KERI10JSON00011c_",
+ "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
+ "s" : "0",
+ "t" : "iss",
+ "dt": "2021-05-27T19:16:50.750302+00:00",
+ "ri": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A"
+}-GAB0AAAAAAAAAAAAAAAAAAAAAAwELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM
+```
+```
+{
+ "v" : "KERI10JSON00011c_",
+ "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
+ "s" : "1",
+ "t" : "rev",
+ "dt": "2021-05-27T19:16:50.750302+00:00",
+ "p" : "EY2L3ycqK9645aEeQKP941xojSiuiHsw4Y6yTW-PmsBg"
+}-GAB0AAAAAAAAAAAAAAAAAAAAABAELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM
+```
+```
+{
+ "v" : "KERI10JSON00011c_",
+ "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
+ "s" : "0",
+ "t" : "bis",
+ "dt": "2021-05-27T19:16:50.750302+00:00",
+ "ra": {
+    "i": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+    "s": "2",
+    "d": "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4"
+  }
+}-GAB0AAAAAAAAAAAAAAAAAAAAAAwELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM
+```
+```
+{
+ "v" : "KERI10JSON00011c_",
+ "i" : "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4",
+ "s" : "1",
+ "t" : "brv",
+ "dt": "2021-05-27T19:16:50.750302+00:00",
+ "p" : "EY2L3ycqK9645aEeQKP941xojSiuiHsw4Y6yTW-PmsBg",
+ "ra": {
+    "i": "ELh3eYC2W_Su1izlvm0xxw01n3XK8bdV2Zb09IqlXB7A",
+    "s": "4",
+    "d": "Ezpq06UecHwzy-K9FpNoRxCJp2wIGM9u2Edk-PLMZ1H4"
+  }
+}-GAB0AAAAAAAAAAAAAAAAAAAAABAELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM
+```
+The _Verifiable Legal Entity Identifier_ (vLEI) provides a lightweight, easy to understand use case for a _Transaction Event Log_ as a _Verifiable Credential Registry_. Issuing a VC has been described above. Verification of a VC will start with the presentation of a vLEI VC as proof (all vLEI VCs are public and therefore proof presentation will include the entire vLEI VC). The verifier will extract the DID of the issuer from the VC, and calculate the hash digest of the serialized contents of the VC. By parsing the namespaced identifier of the VC, the verifier will perform the following steps:
+
+1.  Retrieve the key state from the KERI did method (or appropriate DID method tunnel) using the controller identifier embedded in the VC identifier
+2.  Retrieve and verify the KEL against the key state of the issuer
+3.  Retrieve the management TEL using the Registry identifier embedded in the VC identifier and determine the Registrars to use to retrieve the VC TEL.
+4.  Retrieve the VC TEL and calculate the issuance/revocation state of the VC from the events in the TEL.
+5.  Using the keys from the KERI event to which the `iss` event is anchored, verify the signature on the VC.
+
+1.  To avoid DDoS attack by flooding an Endorser with TEL events that are not associated with any identifiers they are associated with, TEL events need to be placed in escrow until an anchoring KEL event is seen for the TEL identifier.
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+\--- back
+
+# Acknowledgments
+
+(:numbered\="false")
+
+TODO acknowledge.
+
+
+
+
+---
+title: draft-pfeairheller-did-keri
+description: titlekeri DID Method"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-did-keri/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-did-keri/index.md
+---
+
+# draft-pfeairheller-did-keri
+
+title: "The did:keri DID Method" abbrev: "DID-KERI" docname: draft-pfeairheller-did-keri-latest category: info
+
+ipr: trust200902 area: TODO workgroup: TODO Working Group keyword: Internet-Draft
+
+stand\_alone: yes smart\_quotes: no pi: \[toc, sortrefs, symrefs\]
+
+name: Phil Feairheller organization: GLEIF email: [Philip.Feairheller@gleif.org](mailto:Philip.Feairheller@gleif.org)
+
+normative: 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
+
+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
+
+tags: IETF, KERI, CESR
+
+\--- abstract
+
+KERI provides a means for secure and decentralised key management. This specification defines a DID method based on KERI.
+
+\--- middle
+
+# Introduction
+
+The Key Event Receipt Infrastructure is a system for secure self-certifying Identifiers which aims at minimum sufficiency and maximum security. It defines mechanisms for proving the Root of Trust for self-certifying Identifiers and their associated Key State. This spec defines a transform from Key State to DID Document, such that any valid Key Event Log can be processed into a DID Document.
+
+A close analogy is did:peer, except that where the data model of did:peer is a DID Document and JSON patches on said Document, the basic data model of did:keri is an append-only log of Key Events. KERI-based Identifiers are suitable for both any-wise and n-wise purposes.
+
+# Concepts
+
+A Key Event is an atomic transaction over the Key State of an Identifier. While all events have some semantic meaning within KERI, only a subset will change the keys in a Key State (rotation and delegated rotation).
+
+The Key Event Log is a type of hash-chained data structure from which the Key State of an Identifier can be derived. It can always be used to recreate the state at any point ("event-sourcing").
+
+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.
+
+Key State represents the current values for the keys, witnesses and thresholds for a given identifier, signed by a provider. The signature from the provider signifies that the provider has verified the KEL for the identifier and the result of that verification is the key state. The key state is represented in a Key State Notification Message detailed fully in [Event Serialization Key State Messages](https://github.com/decentralized-identity/keri/blob/master/kids/kid0003.md#key-state-messages). The following fields are defined for a Key State Notification Message:
+
+-   `v`: Version String
+-   `i`: Identifier Prefix
+-   `s`: Sequence Number
+-   `t`: Message Type
+-   `d`: Event Digest (Seal or Receipt)
+-   `p`: Prior Event Digest
+-   `kt`: Keys Signing Threshold
+-   `k`: List of Signing Keys (ordered key set)
+-   `n`: Next Key Set Commitment
+-   `wt`: Witnessing Threshold
+-   `w`: List of Witnesses (ordered witness set)
+-   `wr`: List of Witnesses to Remove (ordered witness set)
+-   `wa`: List of Witnesses to Add (ordered witness set)
+-   `c`: List of Configuration Traits/Modes
+-   `a`: List of Anchors (seals)
+-   `da`: Delegator Anchor Seal in Delegated Event (Location Seal)
+-   `di`: Delegator Identifier Prefix in Key State
+-   `rd`: Merkle Tree Root Digest
+-   `e`: Last received Event Map in Key State
+-   `ee`: Last Establishment Event Map in Key State
+-   `vn`: Version Number ("major.minor")
+
+Key state notification messages differ depending on whether the signer is using a delegated identifier. The follow examples detail the fields needed for each permutation.
+```
+{
+              "v": "KERI10JSON00011c\_",
+              "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+              "s": "2",
+              "t": "ksn",
+              "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
+              "te": "rot",
+              "kt": "1",
+              "k": \["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"\],
+              "n": "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
+              "wt": "1",
+              "w": \["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"\],
+              "c": \["eo"\],
+              "ee":
+                {
+                  "s":  "1",
+                  "d":  "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
+                  "wr": \["Dd8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CMZ-i0"\],
+                  "wa": \["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"\]
+                },
+              "di": "EJZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8"
+            }
+
+            {
+              "v": "KERI10JSON00011c\_",
+              "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+              "s": "2",
+              "t": "ksn",
+              "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
+              "te": "rot",
+              "kt": "1",
+              "k": \["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"\],
+              "n": "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
+              "wt": "1",
+              "w": \["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"\],
+              "c": \["eo"\],
+              "ee":
+                {
+                  "s":  "1",
+                  "d":  "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
+                  "wr": \["Dd8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CMZ-i0"\],
+                  "wa": \["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"\]
+                },
+              "di": "EJZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8"
+            }
+```
+did:keri defines `keyState` DID Document Metadata (see [DID Document Metadata](https://w3c-ccg.github.io/did-resolution/#output-documentmetadata) in \[\[?DID-RESOLUTION\]\]).
+
+-   `keyState` is the verified state of the KEL for the identifier represented by this DID Doc (See Key State).
+```
+{
+            "didDocument": DID\_DOCUMENT\_OBJECT,
+            "didDocumentMetadata": {
+                "keyState":  {
+                  "v": "KERI10JSON00011c\_",
+                  "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
+                  "t": "ksn",
+                  "kt": "1",
+                  "k": \["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"\],
+                  "n": "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
+                  "wt": "1",
+                  "w": \["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"\],
+                  "c": \["eo"\],
+                  "e":
+                    {
+                      "s": "2",
+                      "t": "rot",
+                      "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
+                    },
+                  "ee":
+                    {
+                      "s": "1",
+                      "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
+                      "wr": \["Dd8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CMZ-i0"\],
+                      "wa": \["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"\]
+                    },
+                  "di": "",
+                  "a": {}
+                }
+            }
+        }
+```
+The following field MAY appear in a did:keri DID document: `verificationMethod`
+
+Non-normative note: multiple namespaces using the same DID method could prove control or replay history for one controlling keypair that has been used across multiple ledgers. KERL logs could be stored in a secondary root of trust (i.e., a ledger), and similar or identical resolver metadata could be returned by querying the same identifier there.
+
+The following field is not a core field in a did:keri DID document: `Services`. The did:keri method is provided for interoperability for the purpose of using KERI to establish control authority of the current public keys associated with KERI identifier behind the keri:did DID. It is anticipated that KERI tunnel methods (eg. did:indy:sov:keri) will provide these features to enable addition interop.
+
+# The did:keri Format
+
+The format for the did:keri method conforms to the \[\[DID-CORE\]\] specification and is simple. It consists of the `did:keri:` prefix, followed by the identifier prefix.
+
+The method name that identifies this DID method SHALL be: `keri`
+
+A DID that uses this method MUST begin with the following prefix: `did:keri:`. Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix, is the method specific identifier (MSI) described below.
+
+The method specific identifier for the did:keri method is the prefix for a content self-addressing self-certifying identifier.
+
+A self-addressing, self-certifying identifier is cryptographically bound to the inception keys used to create it. The rationale and process for the derivation of an identifier is described in detail in the [Derivation Codes](https://github.com/decentralized-identity/keri/blob/master/kids/kid0001.md#derivation-codes) section of \[\[KID0001\]\]
+
+did:keri:EXq5YqaL6L48pf0fu7IUhL0JRaU2\_RxFP0AL43wYn148
+
+# Operations
+
+The following section outlines the DID operations for the did:keri method.
+
+Creation of a did:keri DID is accomplished by creating, signing and publishing an Inception event. If witnesses are listed in the inception event, the receipts are also required for DID creation to be complete.
+
+Detailed steps for prefix derivation are in \[\[KID0001\]\] and witness configuration in \[\[KID0009\]\]. Inception events are covered in \[\[KID0003\]\].
+
+Steps to resolve a \`did:keri:$PREFIX\` DID:
+
+1.  Find the Key Event Log for the prefix \`$PREFIX\`. The method for discovering the Key Event Log is outside the scope of this specification. Possible implementations include the use of a Distributed Hash Table (DHT), anchoring a KEL in a ledger or the use of a gossip protocol involving a witness network.
+2.  Process the KEL into a Key State, according to the state validation rules/semantics of KERI as defined in \[\[KID0008\]\]
+3.  Create a DID Document with the DID \`did:keri:$PREF\`
+4.  For each key K in the Key State, add a Verification Method to the DID Doc containing K and the appropriate type, with the ID of K being K's prefix form (alternatively, the ID could be an integer of K's index in the current signer list)
+5.  Add the Key State as DID Document Metadata as defined in Resolver Metadata
+
+Establishment of control authority can be done independently of DID document contents, as long as the Key State is provided in the DID Document Metadata. See Resolver Metadata.
+
+Updating a did:keri DID is accomplished by publishing establishment events to the KEL for performing operations such as key rotation and updating signature thresholds, witnesses and delegates.
+
+A detailed description of event types, their semantics and uses can be found in \[\[KID0003\]\].
+
+Deactivation of a did:keri DID consists of rotation to 0 controlling keys, which terminates the ability to recover the identifier and indicates that the identifier has been abandoned. Identifiers which are delegated to by an abandoned Identifier are also considered abandoned (delegating Ixn events can no longer be created).
+
+Detailed steps are specified in \[\[KID0003\]\].
+
+# Privacy Considerations
+
+A breakdown of the privacy considerations from \[\[RFC6973\]\] section 5 is provided below.
+
+A robust witness network along with consistent witness rotation provides protection from monitoring and association of an individual's activity inside a KERI network.
+
+For resolvers that simply discover the Key State endorsed by another party in a discovery network, caching policies of that network would guide stored data security considerations. In the event that a resolver is also the endorsing party, meaning they have their own KERI identifier and are verifying the KEL and signing the Key State themselves, leveraging the facilities provided by the KERI protocol (key rotation, witness maintenance, multi-sig) should be used to protect the identities used to sign the Key State.
+
+See \[\[KID0005\]\] for information on KERI key rotation, \[\[KID0009\]\] for a discussion on witnesses and \[\[KID0004\]\] for KERI's support of multi-sig.
+
+DID Documents are not required to provide endpoints and thus not subject to unsolicited traffic.
+
+This DID Method relies on KERI's duplicity detection to determine when the non-repudiable controller of a DID has been inconsistent and can no longer be trusted. This establishment of non-repudiation enables consistent attribution.
+
+See \[\[KID0010\]\] for a detailed description of KERI’S Agreement Algorithm for Control Establishment (KAACE).
+
+The root of trust for KERI identifiers is entropy and therefore offers no direct means of correlation. In addition, KERI provides two modes of communication, direct mode and indirect mode. Direct mode allows for pairwise (n-wise as well) relationships that can be used to establish private relationships.
+
+See \[\[KID0001\]\] for a description of KID prefix generation and \[\[KID0009\]\] for a comparison between Direct and Indirect modes.
+
+The root of trust for KERI identifiers is entropy and therefore offers no direct means of identification. In addition, KERI provides two modes of communication, direct mode and indirect mode. Direct mode allows for pairwise (n-wise as well) relationships that can be used to establish private relationships.
+
+See \[\[KID0001\]\] for a description of KID prefix generation and \[\[KID0009\]\] for a comparison between Direct and Indirect modes.
+
+The Key State made available in the metadata of this DID method is generally available and can be used by any party to retrieve and verify the state of the KERL for the given identifier.
+
+No data beyond the Key State for the identifier is provided by this DID method.
+
+This DID method provides no opportunity for correlation (See [](#correlation)), identification (See [](#identification)) or disclosure (See [](#disclosure)) and therefore there is no opportunity to exclude the controller from knowing about data that others have about them.
+
+# Security Considerations
+
+Users of a did:keri did method resolver MUST verify the key state returned in the document metadata of the resolution result. The signature of the resolver can be used to determine if the resolver is dysfunctional and should no longer be trusted. However it should not be used to verify the key state.
+
+The only definitive method for verifying the key state is to pass the key state to a KERI library and perform the verification of that key state.
+
+A breakdown of the security considerations from \[\[RFC3552\]\] is provided below.
+
+All private keys used to establish control over the KERI identifier of a KERI DID method DID should be held secret. KERI's use of delegation ensures that private keys for each identifier never need to be transferred. DID controllers can delegate levels of authority of other identities to enable remote agents.
+
+See \[\[KID0007\]\] for a discussion of delegation.
+
+In addition, pre-rotation mechanism provides key rotation capabilities while eliminating exposure of the next public key until it is rotated into the current signing key. Enforcing key rotation for every event of a given identifier provides further protection against key exposure.
+
+See \[\[KID0005\]\] for a description of pre-rotation and the protections it provides
+
+did:keri relies on the KERI protocol which is not susceptible to replay attacks. The hash linking, signatures and sequence numbers of events ensures that replayed messages do not effect the protocol.
+
+See \[\[KID0003\]\] for a description of KERI events.
+
+did:keri relies on the KERI protocol which is not susceptible to message deletion or modification attacks. The hash linking, signatures and sequence numbers of events ensures that messages can not be modified or deleted without immediate detection. In addition, KERI's duplicity detection mechanisms allow easy detection of inserted messages allowing validators to determine the consistency of a DID controller.
+
+See \[\[KID0003\]\] for a description of KERI events and \[\[KID0010\]\] for the KAACE algorithm.
+
+The protections mentioned in Replay Attacks and Message Attacks render Man-In-The-Middle attacks ineffective against the KERI protocol and this DID Method.
+
+# Conventions and Definitions
+
+(::boilerplate bcp14-tagged)
+
+# Security Considerations
+
+TODO Security
+
+# IANA Considerations
+
+This document has no IANA actions.
+
+\--- back
+
+# Acknowledgments
+
+(:numbered\="false")
+
+TODO acknowledge.
+
+
+
+
+---
+title: draft-pfeairheller-cesr-proof
+description: title: "CESR Proof Signatures"
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-cesr-proof/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-cesr-proof/index.md
+---
+
+# 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\]
+
+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
+
+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
+
+name: Mark Nottingham date: 2003
+
+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
+
+# Introduction
+
+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 SAD Path Language
+
+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.
+
+# CESR Attachments
+
+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.
+
+# Nested Partial Signatures
+
+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.
+
+# Conventions and Definitions
+
+(::boilerplate bcp14-tagged)
+
+# Security Considerations
+
+TODO Security
+
+# IANA Considerations
+
+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
+
+# Acknowledgments
+
+(:numbered\="false")
+
+Dr Sam Smith, Kevin Griffin and the Global Legal Entity Identifier Foundation (GLEIF)
+
+
+
+
+---
+title: UNIVERSAL IDENTIFIER THEORY
+description: Samuel M. Smith Ph.D.\
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/IdentifierTheory-ssmith-uidt/index
+  md: https://weboftrust.github.io/keridoc/docs/resources/mdfiles/IdentifierTheory-ssmith-uidt/index.md
+---
+
+# UNIVERSAL IDENTIFIER THEORY
+
+Samuel M. Smith Ph.D.
+v1.33 2021/05/16
+
+A universal theory for identifiers is presented. This theory is based on a unified model of identifiers that include cryptographic autonomic identifiers (AIDs) and legitimized (authorized) human meaningful identifiers (LIDs). This model provides truly decentralized trust bases each derived from the cryptographic root-of-trust of a given AID. An AID is based on a self-certifying identifier (SCID) prefix. Self certifying identifiers are not human meaningful but have strong cryptographic properties. The 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 authorization. This authorization legitimizes that human meaningful identifier as an LID though its association with an AID. The result is a secured trust domain specific identifier couplet of aid|lid. AIDs are provided by the open standard key event receipt infrastructure (KERI) \[42\]. This unified model provides a systematic methodology for the design and implementation of secure decentralized identifier systems that underpin decentralized trust bases and their associated ecosystems of interactions.
+
+Autonomic Identifier, AID, Autonomic Identity System, AIS, Autonomic Namespace. Decentralized, Key Management Infrastructure, DKMI, Key, Event, Receipts, Pre-rotation, Rotation, Event, Streaming, KERI, KERL, KEL, KA2CE, Post-Quantum Security, Self-Sovereign Identity, SSI.
+
+A design goal for an identifier system is that it be secure, trustable, and universal. A system that is insecure may not be trusted, and a system that is neither secure nor trusted is not a viable candidate for universal use. Therefore security is of paramount importance. It is the foundation for any other useful property of the identifier system.
+
+We use the term identifier system instead of identity system to emphasize that it is the properties of the identifier that are first and foremost. The identifier properties imbue the associated identity system with its operative properties. Indeed, we use a narrow definition of identity to crystallize our understanding of the associated system. We formally define a (digital) identity to be a (digital) identifier plus attributes. The attributes themselves may include identifiers thereby enabling complex identities which may be represented by an identity graph. A subset of a graph is a tree or a forest.
+
+In general we want to have a theory or model of how to design identifier systems with desirable properties. As mentioned above, some desirable properties are security, trustability, and universality. Historically identifier systems has been designed without any unifying theory to guide the designers. This means that many identifier systems are largely bespoke to a given application. This may be problematic especially when the identifier system does not have a well defined approach to security. More recently, explicitly characterizing identifier properties has gained some recognition as a prerequisite to identifier system design. For example, the well known Zooko's triangle or trilemma is based on recognizing a conflict between three different desirable properties for an identifier \[61\]. The three properties are human meaningful, secure, and decentralized. The trilemma states that an identifier may have any two of the three properties by not all three. Some have claimed to have solved the trilemma by using a hybrid identifier system where human meaningful but insecure identifiers may be registered on a distributed consensus ledger. The registration process itself uses identifiers that are secure and decentralized but not human meaningful \[50\]. The fact that not one identifier but a combination of identifiers is needed to solve the trilemma hints that the identifier model therein employed is incomplete. A notional diagram of Zooko's triangle is shown below:
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/zookos-triangle.png)
+
+In our work we have developed a unified universal model of identifiers (digital) called the _autonomic identifier model_ (AID) \[42\]. This model takes a security first approach. The model is based on the recognition that all other properties of an identifier are of little value if the identifier is not securely controlled. The AID model is based on a formal theory of identifiers that we have been developing for several years \[10; 12; 35; 41-46; 49\]. All identifiers may now be classified and described within the framework of this theory. This model provides a principled approach to identifier system design. This may be used to inform and guide the design and development of any concrete implementation.
+
+As mentioned above the property that is of paramount importance to an identifier system is security. The dictionary definition of secure is free from or not exposed to danger or harm; safe. For identifiers security typically means secure from exploit or compromise. More specifically an identifier is secure with respect to an entity if there is a mechanism by which that entity may prove it has control over the identifier. The entity with such provable control we call the controller of the identifier. We may use secure identifiers in an identity system security overlay to secure other systems that do not have secure identifiers \[42\]. An important use case may be the internet because the Internet Protocol (IP) has no security mechanism for its IP addresses as identifiers. Likewise any existing insecure identifier system maybe secured by using a secure identifier system as a security overlay \[42\].
+
+The problem we face is how best to prove control over an identifier (digital). There are many such mechanisms that have been used over the years. This begs the question: Is there one mechanism that is sufficiently superior that it may be used as the universal basis for identifier security? AID theory answers that question with an unequivocal yes! That mechanism is rooted in a property called self-certification. A self-certifying identifier (SCID) exhibits this property. Self-certification is based on well established asymmetric cryptographic operations for digital signatures where the identifier is uniquely derived using cryptographic one way functions from a source of information entropy captured by the controller \[20; 34; 36; 37; 42\]. This property cryptographically binds the identifier to the controlling asymmetric key-pair or key-pair(s). This forms a secure cryptographic root-of-trust for the identifier.
+
+A root-of-trust is some component of a system that is secure by design and it security characteristics may be inherently trusted or relied upon by other components of the system. In a more general sense, the security of an identifier system is a function of its trust basis. A root-of-trust may form that trust basis. A self-certifying identifier is derived using cryptographic one-way functions with known cryptographic strength. For example, consider a basic SCID that is prefixed with a public key where that public key is derived from a private key. Suppose that the public key derivation algorithm (one-way function) has 128 bits of cryptographic strength. This means that as long as the private key remains private, an attacker has to perform something on the order of 2128 operations to brute force invert the derivation algorithm. This is practically infeasible. Security is then becomes a function of the protection of the secrecy of the private key. High security may be ensured through best practices key management.
+
+The root-of-trust and hence the trust basis for a SCID is inherently decentralizable. Only the entity that captures sufficient random or pseudo-random entropy to generate the private key may derive and prove control over the resulting public key and therefore the resulting SCID. Thus any entity with a cryptographic strength pseudo-random number generator (e.g. a computer) may be the sole controller over the resulting SCID. The controller may choose to manage its keys in a non-decentralized way. But centralized key management is not necessary and is typically less secure. The governance mechanism for the identifier is at the discretion of the controller. Thus any position on a spectrum of centralization/decentralization is possible. Moreover, because the SCID includes the public key or some cryptographically derived material (a large pseudo-random string of characters), the identifier is universally unique \[3\]. This SCID may then be used as a prefix for a namespace using a URL like approach \[54\]. All identifiers in that name space then share the same uniquely provable cryptographic root-of-trust. So a SCID comes with three very important properties:
+
+-   Self-contained secure cryptographic root-of-trust
+-   Decentralized control via private key managementkeridoc/
+-   Universally unique identifiers
+
+But a SCID that does not support rotation of the underlying key-pairs is not sustainable as a persistently secure identifier. Eventually through exposure due to use, the key-pairs may become weakened. Advances in cryptographic exploits may also make them weak over time. Thus a truly secure system needs the ability to rotate the key-pairs to new ones. SCIDs with this capability we call self-managing self-certifying identifiers or autonomic identifiers (AIDs). The meaning of the word autonomic is self-managing so an AID is a non-trivial SCID. This is explained in more detail in the next section. But relevant here is that we may use an AID as the root-of-trust to form what we call an autonomic trust basis. This is diagrammed as follows:
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/autonomic-trust-basis.png)
+
+Two other trust bases are in common use for identifier systems. One we call algorithmic. 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 block chain such as BitCoin, Ethereum, or Sovrin \[7-9; 18; 47\]. The primary exploit of a pool of nodes running such an algorithm is to suborn or gain control of a majority of the nodes. Depending on the algorithm, such an exploit may not necessarily require inverting any cryptographic one-way functions. In a permission-less proof-of-work block chain, for example, it may require capturing 51% of the hashing power of the nodes on the network. An algorithmic (blockchain) root-of-trust, however, may be very secure. Distributed consensus algorithms have well know security properties \[51\]. The difference is that a network algorithmic root-of-trust is critically dependent on the network infrastructure (the ledger and nodes that write to the ledger). This locks the identifiers to that specific instance of infrastructure. In other words the associated identifiers are not portable. Should the ledger go away, so does the root-of-trust. One may characterize a ledger as a centralized logical construct that is governed in a decentralized manner. Thus the degree of decentralization is less than a self-certifying cryptographic root-of-trust (autonomic). In addition, ledgers tend to be relatively expensive, slow, and with low throughput. This makes using them as a root-of-trust much more constrained than a cryptographic root-of-trust. Thus from a property point of view a cryptographic root-of-trust (autonomic) is generally superior to a network algorithmic (block chain) root-of-trust. An algorithmic trust basis is diagrammed below: keridoc/
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/algoritmic-trust-basis.png)
+
+The other commonly used trust basis in identifier systems is an administrative or organizational trust basis, i.e. a trusted entity. It is difficult if not pathologically so to characterize the roots-of-trust of a trusted entity. Security may be dependent on something as nebulous as employee morale. At its root, the Internet Protocol (IP) was not designed with security as a first class property. Instead Internet security is usually provided via a bolted on identity system security overlay. The security overlay in most widespread use is the open hierarchical Domain Name System plus Certificate Authorities (DNS+CA) \[14; 15\]. The DNS Certificate Authority system trust basis is administrative derived from the assumed "trusted" entities that are the certificate authorities. It uses the transport layer security (TLS) protocol and X.509 certificates \[11; 53; 60\]. As is well known, internet infrastructure based on DNS+CA continues to exhibit security vulnerabilities even when organizations follow best practices for conventional security system design and exhibit high levels of operational integrity \[2; 4 -6; 19; 23; 24; 29; 40; 48\]. Given the history of continuing exploits of such a trust basis, it is decidedly inferior from a security perspective to either cryptographic or network algorithm derived trust bases. By comparison, identifiers issued in such a system with an administrative trust basis are neither secure nor decentralized. An administrative trust basis is diagrammed below:
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/administrative-trust-basis.png)
+
+Although a self-certifying identifier (SCID) employs a cryptographic root-of-trust, it by itself does not provide control over an identifier that may persist in spite of a compromise of the key-pair(s) used to derive the identifier. Persistent control in spite of key compromise is the hard problem of key management. The typical solution to this problem is a mechanism for key rotation. Key rotation involves the revocation and replacement of the current controlling set of key-pair(s) with a new set. We call identifiers in a self-certifying identifier system that includes a secure key rotation mechanism self-managing self-certifying identifiers. There are other key management mechanisms such as delegation that such as system may also exhibit. As a short hand we call such a system an autonomic identifier system (AIS) and the associated identifiers are autonomic identifiers (AIDs). The meaning of the work _autonomic_ is self-governing or self-managing and comes form the Greek auto-nomos or literally translated self-rule. Thus autonomic identifiers (AIDs) are self-certifying identifiers (SCIDs) that may include other self-managing properties such as key rotation. The Key Event Receipt Infrastructure (KERI) is an open standard mechanism (protocol) for an autonomic identifier system (AIS) \[12; 35; 42\]. KERI provides support for fully decentralized portable secure key management operations on self-certifying identifiers. KERI relies on key event logs (KELs) of key management events such as rotation and delegation. These logs are cryptographically verifiable hash chained and signed data structures. A KEL provides proof of control authority of a given set of keys over an AID. This proof of control authority is end-verifiable by any verifier to the cryptographic root-of-trust of the AID. Its verifiability is not dependent on any intervening infrastructure or trusted entity. The details of KERI are beyond the scope of this paper but may be found here \[12; 35; 42\].
+
+The function of KERI is to establish control authority over an identifier (AID) in a cryptographically secure and verifiable way. Once that control authority has been established, a verifier may then securely verify any associated authorizations issued by the controller of the AID. These authorizations have the form of a signed authorization statement where the statement typically includes the AID under which the authorization is issued. A verifier may then verify the authorization by verifying the attached signature using the keys that were authoritative at the time the authorization was issued. These authorizations are secure to the extent that the established control authority is secure. The authorizations inherit their security from their associated AID. The trust domain of an AID is the set of statements that may be securely verified as being issued by the controller of that AID (along with any associated transactions or interactions). Authorizations both inhabit and are protected by this trust domain. In other words the authorizations are under the aegis of the AID (or equivalently the controller of the AID) that issued them.
+
+Authorizations may take many forms. One form of particular interest is the W3C Verifiable Credential (VC) standard \[55\]. Verifiable credentials use the W3C Decentralized Identifier (DID) standard \[57\]. The DID standard provides name spacing syntax for decentralized identifiers that is evocative of URIs \[54\]. A given DID may be a type of AID but not all DIDs are AIDs. Furthermore, because AIDs may use other name space syntax standards besides DIDs, not all AIDs are DIDs. KERI itself is name space agnostic so may be used to support AIDs in any name space that accepts pseudo-random strings as an element.
+
+Given an AID we may now unify the other desirable propkeridoc/identifier, that is human meaningfulness. In contrast the cryptographic material in an AID makes it decidedly non-human meaningful. The AID is represented succinctly by its cryptographic prefix. The prefix is a cryptographically derived pseudo-random sequence of characters. For example a 32 character AID prefix may be as follows:
+
+`EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148` (1.1) Such a long pseudo-random string of characters is the antithesis of human meaningful. In contrast, examples of human meaningfulness might be easily recognized words or names or some efficiently hierarchically organized composition of characters. Human meaningfulness has two limiting characteristics. The first is scarcity, this 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. Nevertheless, given the trust domain of an AID any human meaningful identifier may be uniquely authorized, sanctioned, or legitimized within that trust domain. Because only the controller of the AID may issue verifiable authorizations associated with that AID, that controller alone may authorize the use of any human meaningful identifier under the aegis of its trust domain. The associated authorization statement legitimizes the use of that human meaningful identifier within the trust domain. This gives rise to a new class of identifier, a legitimized or authorized human meaningful identifier identifier and use the acronym LID. The important property of an LID is that it is verifiable with respect to a given AID. The pair forms a new identifier couplet that we may represent as follows:
+
+aid|lid (1.2)
+
+where aid represents the cryptographic identifier prefix of an AID, the vertical bar, |, represents the legitimizing authorization, and lid represents the legitimized human meaningful identifier. This couplet may be diagrammed as follows:
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/aid-lid-couplet.png)
+
+This coupling is a special type of name spacing. For example suppose the LID is a library Dewey Decimal code for a book such as:
+
+`625.127C125r` (1.3)keridoc/
+
+Using the AID prefix example from above, the full aid|lid couplet may be expressed as follows:
+
+`EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148|625.127C125r` (1.4)
+
+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. Any verifier of the LID, however, knows from the given context how to cryptographically verify the legitimacy of the LID. 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 |. With this model, there is no longer any global scarcity associated with a given LID because each AID may have its own copy of the LID. Scarcity only occurs within the trust domain of each AID but is completely managed by the controller of that trust domain (AID).
+
+To further explicate this concept, we may characterize any aid|lid couplet as consisting of two classes of identifiers, primary and secondary. Primary identifiers are AIDs and are self-certifying to a cryptographic root-of-trust. Secondary identifiers are LIDs and are not self-certifying but are secured under the aegis of an associated primary identifier's trust domain. A tertiary class of identifier has no external security properties but may be useful within the confines of an application user interface or other local content. In other words, tertiary identifiers are unsecured and may only be used internally or where security is unimportant whereas primary and secondary identifier may be used externally. A primary may appear alone but a secondary must either appear within the known context of a primary or as a couplet with the primary itself. This trust domain contextualization is shown in the following diagram:
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/aid-trust-domain.png)
+
+This unified model of primary, secondary, and tertiary identifiers may now be used to guide the design of any identifier system. The design of the primary AID may be tuned to the specific security, performance, and governance properties of the application. The design of the secondary LID may be tuned to provide any other desirable human meaningful properties of the identifier. And all other identifiers are tertiary.
+
+In the context of an autonomic identifier system, trust has two distinct meanings or types. The first is trust is the cryptographic security of the root-of-trust of the AID and associated verifiable statements. The second is trust in the controlling entity of the private keys. The first type of trust is limited to the ability to cryptographically verify non-repudiable signed statements. These provide consistent attribution of any statement to the controller of the private keys. In other words, we may trust in who said something and we may prove that what they say is consistent (non-duplicitous) or not. But we may not trust in the veracity of what was said. For this we need the second type of trust. This second type of trust may be called reputational trust. It is trust that an entity will make accurate statements, that is, the entity is reputable. The dictionary definition of reputable is held in good repute; honorable; respectable; estimable, considered to be good or acceptable usage; standard. The related word reputation is a noun meaning, the estimation in which a person or thing is held, especially by the community or the public generally. Reputation is a measure of accumulated consistent behavior. It can be evaluated at different levels of granularity. The root of reputation comes from the Latin word reput?re, which is equivalent to re+put?re, that is, to re-think or re-consider.
+
+Identifier systems need both attributional trust and reputational trust. The first derived from consistent attribution, enables us to trust that a statement was made by an entity (who) and the second, reputation, enables us to trust in what that entity said. This forms a trust balance. For example, a verifiable credential issued by an entity is only of value if we can trust both that the entity indeed issued it and that the contents or attributes of the credential are accurate. Cryptography allows us to verify that the issuer truly created the credential but we must trust the institutional, organizational, behavioral integrity or reputation of the issuer in order to trust in what the credential asserts. The later requires reputational trust in the issuer of the credential. Another way of understanding this trust balance is that the primary value in any issuance of information is dependent on the veracity of that information and that veracity is dependent on the credibility (reputation) of the issuer but we may only securely associate that reputation to that information if the authenticity of the issuer is established. So first authenticity (AID) and then veracity (LID). This dependency is shown in the following diagram.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/veracity-authenticity.png)
+
+It is this reputational form of trust that makes a governing organization that authorizes LIDs within the context of their AID so valuable to the associated ecosystem. The integrity, consistency and repeatability of the organizational procedures used to issue authorizations for LIDs are essential to reputational trust.
+
+The aid|lid coupling mirrors this trust balance. We rely on the cryptography for the trustworthy establishment of the control authority of the controller of the AID. And we rely on the reputational integrity of the controller to trust that a given LID has been authorized correctly.
+
+A common usage of reputation is as a considered evaluation of how someone has behaved in the past that provides an estimation of how they might behave in the future. In other words, reputation is a measure of past behavior that may be used to predict future behavior. The context of a reputation may also be important, that is, past behavior may be a better predictor of future behavior when applied to similar contexts. Reputation is based on proof of consistent behavior which requires provably consistent attribution which brings us full circle. Provable trust in the AID mechanism enables provable trust in the entity behind the LID mechanism.
+
+The aid|lid couplet is an example of a very short chain-of-trust. The anchor or root link to that chain is the AID. But in order for such an AID to usable it must be universally recognized as the authoritative identifier for a given entity. Because an AID is self-certifying the identifier itself includes a universally unique pseudo-random string of characters. So there may be only one. But the problem is knowing which identifier is the one and only one authoritative identifier. As described previously such strings are not human meaningful. Therefore they are not easily recognized as the authoritative identifier. The process that establishes an AID as the root identifier with an organization may be called a well known reputational association. Once this connection between root AID and organization becomes common knowledge then it is secure.
+
+To elaborate, an AID prefix is cryptographic material. Best practice is to derive it via cryptographic one-way functions that maintain 128 bits of information theoretic entropy. Given this recognition, such a self-certifying identifier may practically be used as the root-of-trust for all other activity associated with the entity that controls the identifier. Control is established by virtue of possession of the private keys from which the identifier was derived. _This enables a secure bootstrap mechanism whereby the controller may securely issue other identifiers or authorizations._
+
+Because the identifier is not human meaningful, it may not be easily recognized as the authoritative root identifier (AID). Consequently, the identifier must first become well known as authoritative for that entity. This association becomes secure once it has become sufficiently well known that an attacker may not fool any verifier into recognizing a different identifier as the authoritative root identifier. In other words, the association between the AID and the entity must become common knowledge.
+
+The process of elevating an identifier to well known (i.e. common knowledge) status may leverage several other already well known URLS or registration mechanisms that verifiably associate the AID to the entity \[38\]. These well known mechanisms may employ some vetting process to accept a registration. Or they may consist of already well known resources under the control of the entity wherein the entity provides a statement that links the entity to the new AID. The strength of the well known establishment is multiplied by the number of such associations, i.e. provides a reputational source of trust.
+
+Any verifier may thereby check multiple redundant well known resources or registries to confirm that indeed the entity has declared the identifier as its authoritative AID. Once the authoritative status of the root AID is established via this well known process then any other identifier's authoritative status may be established merely via signed statements using the authoritative controlling key-pairs of the root AID. Because the root AID is self-certifying and self-managing, the public keys from the set of authoritative keys-pairs may be extracted from the identifier itself or if rotatable from its unique, verifiable key event log (KEL).
+
+When the AID is expressed as a W3C DID (decentralized identifier), the associated DID:Doc may use the following draft specification to provide references to verifiable credentials (VCs) that link the identifier to well-known URLs (domains) \[38; 58\]. The process of establishing the authoritative nature of an identifier using well known locations (URLs) is standardized in IETF RFC-8615 \[38\]. The RFC-8615 approach reserves a specific path component .well-known/ of a URL in each DNS domain that provides well known meta-data about some other resource. Consequently, meta-data about an AID may provide by the entity that controls the DNS domain an authoritative association between the AID and the controlling entity or some other entity.
+
+This well known path prefix, /.well-known, is reserved in HTTP, HTTPS, WebSocket (WS), and Secure WebSocket (WSS) URIs for these well-known locations. For example, the URL prefix myentity.com/root-identifer/.well-known/ could return a document that specifies the actual AID as being the root self-certifying identifier for the entity that controls the domain name myentity.com.
+
+The concept of well known or common knowledge associations is similar to the concept of a rich presentation of verifiable credentials \[13\]. A rich presentation makes the likelihood of the intersection of all the credentials by any but the true controller vanishingly small. Likewise, associations provided by multiple well known locations may establish with high likelihood the authoritative nature of a given AID. Consistent common knowledge is the root-of-reputational-trust by which the credibility of an association may be established. One need merely establish with sufficient redundancy a given association to be trustworthy.
+
+In summary, because AIDs are self-certifying, they have a secure primary cryptographic root-of-trust that is end-verifiable. The well known establishment process described above may secure the connection between the entity and the first link in this chain. Given a sufficient degree of common knowledge that a given AID is the first link in the verifiable chain-of-trust for an entity, then any subsequent links in the chain may be established by cryptographically verifiable attestation via the preceding link. Given this chain-of-trust, other items of data such as verifiable credentials or LIDs may be securely associated with the chain. Any subsequent attestations may extend the chain-of-trust in a secure manner. Any subsequent links are not vulnerable because they may be cryptographically verifiably authorized by a chain-of-trust back to the the root-of-trust which is the AID itself.
+
+Various standards bodies or industry organizations act as the reputable body that authorizes or legitimizes the issuance of LIDs for a given industry. These LIDs are human meaningful in the sense that they follow a structured syntax that is not cryptographic. Although they may not be human friendly they are still human meaningful from their structure. Usually the issuance of an LID uses an administrative trust basis.
+
+One example of an industry LID would be the GLEIF legal entity identifiers (LEI) \[31-33\]. Another example are the GS1 GTIN or SGTIN electronic product identifiers (ePI) \[16; 17; 25; 26; 28; 30; 56\]. By making the issuance a verifiable authorization via a VC from an AID with a cryptographic root of trust, these identifiers systems may inherit the security of the AID in the form of a couplet.
+
+For example GLEIF's Legal Entity Identifier (LEI) may be viewed as a type of LID (legitimized human meaningful identifier) \[31-33\]. An LEI code specifically is an hierarchically structured 20 character string. An example LEI may be expressed as follows:
+
+`254900OPPU84GM83MG36` (1.5)
+
+GLEIF may create a trust domain based on GLEIF's sole control over a root AID . Lets call this root AID the GLEIF AID or GID for short. The GID is uniquely represented by its cryptographic prefix. Suppose this is given by: `EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148` (1.6)
+
+The the resultant gid|lei couplet may be represented as follows:
+
+`EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148|254900OPPU84GM83MG36` (1.7)
+
+Within the GLEIF GID trust domain, GLEIF may issue authorizations that legitimize any number of LIDs in the form of LEIs. The authorizations makes the LEIs verifiable to the root-of-trust of the GID. Thus these may be called verifiable LEIs. The entities that participate in the GLEIF ecosystem may have their own trust domains protected by their own AIDs. They may receive authority to issue LEIs against their verifiable AID. But this enables the ecosystem security to be based on secure cryptographic roots-of-trust not merely administrative roots-of-trust.
+
+As a further example, a GS1 SGTIN is a hierarchically structured 23 character string \[16; 17; 25; 26; 28; 30; 56\]. An example SGTIN may be expressed as follows:
+
+`4815061414100073431459` (1.8)
+
+As described previously, a trust domain is based on some entity's sole control over a root AID. Lets call this root AID the GS1 AID or GID for short. The GID is uniquely represented by its cryptographic prefix. Suppose this is given by:
+
+`EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148` (1.9)
+
+The resultant gid|sgtin couplet may be represented as follows:
+
+`EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148|4815061414100073431459` (1.10)
+
+Within the GS1 trust domain of its AID, GS1 may issue authorizations in the form of VCs that legitimize any number of LIDs expressed as SGTINs. The authorization makes the associated SGTIN verifiable to the root-of-trust of the GS1 AID. Thus these may be called verifiable SGTINs. The entities that participate in the GS1 ecosystem may have their own trust domains protected by their own AIDs. They may receive authority to issue SGTINS against their verifiable AID. But this enables the ecosystem security to be based on secure cryptographic roots-of-trust not merely organizational or administrative roots-of-trust.
+
+Another LID example is the GS1 GLN for global location number. A GLN is a hierarchically structured 13 character string. GLNs may be used to identify physical locations, operational locations and legal entities \[1; 21; 22; 26; 27\]. An example GLN may be expressed as follows:
+
+`4567123489098` (1.11)
+
+Given the same GID and associated trust domain for GS1 as above, the resultant gid|gln couplet may be represented as follows:
+
+`EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148|4567123489098` (1.12) keridoc/ An ecosystem participant might use a combination of LIDs of different types from multiple trust domains. But any other participant will be able to end-verify the authorization status of that combination to the associated cryptographic roots-of-trust of each of the LIDs.
+
+Any identifier system security overly may have some degree of any combination of the following three properties but not all three completely, Or in other words one can can get variable degrees of all three but not completely all three at the same time. This is a trilemma for identifier systems.
+
+**The three properties are authenticity, privacy, and confidentiality.**
+
+KERI is designed to provide the highest level of authenticity. Because KERI provides complete authenticity, according to the trilemma, KERI may not therefore also provide complete privacy and complete confidentiality. Likewise a system that provides both complete privacy and complete confidentiality may not also provide complete authenticity.
+
+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.
+
+KERI employs non-repudiable signatures which provide the highest degree of authenticity in a practical cryptographic operation. But verifiable non-repudiable signatures are correlation points for the associated identifier. This makes privacy incomplete. Alternatively a Diffie-Hellman key exchange provides encryption keys for confidentiality, but does not provide non-repudiation so does not provide complete authenticity. Without going into detail here, careful examination of any cryptographic operation exposes a similar tradeoff. This triangle is diagrammed below: keridoc/
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/smiths-triangle.png)
+
+KERI supports separable control over shared data. This separation of control is between the controller and the validator. The controller controls the generation and promulgation of key events for the controller's AID and the validator controls the confirmation network that verifies the key events.
+
+The KERI white paper goes to some length to describe the trust basis for the controller of an identifier including specifically the cryptographic root-of-trust that AIDs derive from SCIDs (self-certifying identifiers) \[42; 59\]. This root-of-trust is protected by the controller's key management infrastructure. In KERI parlance the authoritative cryptographic material is called the identifier prefix. This is the a cryptographically strong string of characters that is derived via one-way functions from a pseudo-random string of characters that represents the information entropy captured by the controller. In addition to the key and event generation and signing infrastructure, when the associated AID is public, the controller also declares an event promulgation network of witnesses. A network of witnesses provide high availability of the associated key event log (KEL) for the AID. The controller may protect its key generation, key storage, and event signing infrastructure by running it inside a trusted execution environment (TEE) such as SGX, TrustZone, an HSM, a TPM, or other similarly protected hardware/software/firmware security system. This protects the cryptographic strength of the root-of-trust. The controller can then make the claim, that, with KERI, as long as its secrets remain secret then the rest of the controller's key management and event signing infrastructure may be as secure as the cryptographic strength of the one-way functions used to derive the identifier prefix. How the controller protects its secrets is application dependent. keridoc/ Similarly the controller may protect its witnesses by running them inside some TEE like protection system. However, the witness construct allows the controller to use a threshold structure to protect the witnesses even when not using some form of a TEE. Threshold structures are defined below \[51\]. The following diagram shows the promulgation network for a controller of the identifier prefix of a KERI AID.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/key-event-promulgation-service.png)
+
+The KERI white paper, however, does not go into length on the trust basis for the validator. The validator's essential task is to perform cryptographic signature verification on the events it receives either directly from the controller or indirectly from the controller's promulgation network. Should the software/firmware that runs the validator's signature verification become compromised then the validator may not know that the key events sourced by the controller are themselves compromised. The validator needs to protect its verification software.
+
+One approach to protection is to run signature verification inside a TEE or special purpose HSM. This is the dual operation to the controller running signature generation inside a TEE or HSM. Signature verification is a simple process that may leverage well known software libraries. Because the verifier may use any host or device to run the verification software it may be difficult for an attacker to know which hosts or devices to attack. Nonetheless protecting the verifier(s) is important. The root-of-trust for the validator is the security of its verifying devices. It is not cryptographic per se, but depends on the protection of the cryptographic operations that perform the verification. From an end-to-end system's perspective the signature verification software/firmware needs to be as secure with respect of the validator as is the root-of-trust the signature generation software/firmware is with respect to the controller.
+
+In addition to or instead of TEEs, a validator may also use the threshold structure of KERI to enable secure verification. Similar to a controller, a validator may employ a confirmation network of watcher (verifier) nodes. Indeed, KERI was designed specifically so that a pool of watchers may be employed for the validator function. When a pool of watchers is employed then that pool may be designed to be as secure as needed using a threshold structure (with or without using TEEs). Moreover, because KERI splits the system into two sides, each side has two distinct roots-of-trust, each of a different kind. Because the validator side is the easiest to manage, the KERI WP does not spend much time on it. The security considerations of both hardware and software on both sides should be addressed. The following diagram shows both a promulgation network of witnesses and a confirmation network of watchers.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/validators-promulgation-network.png)
+
+To elaborate, the promulgation side (the controller) uses a root-of-trust that is a SCID and the security is rooted in the cryptographic strength of the controller's private keys and the degree of protection of its key management infrastructure. The confirmation side (the validator) has a different root-of-trust which is based on the degree of protection of its event signature verification software/firmware. The validator's root-of-trust is independent of the controller's. It is not a function of the key management of the controller.
+
+This early influential paper by Nick Szabo describes the concept of a "threshold structure", which underlies the ideas in the security guarantees of multi-signatures, distributed consensus, and multi-factor authorization (MFA) to name a few \[51\]. KERI itself employs threshold structures namely, multi-sig and distributed consensus, and assumes that the key management is using best practices such as MFA. Threshold structures may be employed in a complementary manner to trusted execution environments (TEE) for security. Szabo's paper does a good job of explaining why the two types of security are complementary and that the whole may be greater than the sum of its parts.
+
+What a threshold structure for security does for us is that we can have weaker key management or execution environment infrastructure individually but use a threshold structure to achieve greater overall security by multiplying the number of attack surfaces that an attacker must overcome to compromise our system. In other words, with threshold structures, overall security may be greater than the security of any of the individual parts. For example, in MFA the combination of two factors, something you have and something you know, may be much more secure than either of the factors by themselves.
+
+As is well known, a distributed consensus algorithm is a provable algorithm using a set of nodes where the algorithm provides a security guarantee that is greater than the security guarantee of any of its constituent nodes. It makes a guarantee that in spite of a compromise of F of the 3F+1 nodes, that the ledger written by the pool as a whole is still secure \[7-9\]. So it's improving security by multiplying the number of attack surfaces that must be simultaneously overcome. This may be more or less complex depending on how one defines complexity. To restate, the value of Byzantine Fault Tolerant algorithms is that one can arbitrarily increase the degree of difficulty to an attacker by multiplying the attack surfaces using a distributed network of nodes with sufficient non-common mode failure vulnerabilities \[7-9\]..
+
+This applies to KERI as well. The witnesses and watchers 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 \[9\]. But when comparing apples (key management and trusted execution environment 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.
+
+With KERI's design we can make the following claim:
+
+Through threshold structures, KERI enables the promulgator (controller) to to make its system no less secure than the security of its secrets and enables the confirmer (validator) to make its security at least as secure as the security of the promulgator.
+
+Obviously in resource constrained applications there are limits to the application of distributed consensus for security. Nonetheless, the point of KERI is to capture the goodness of distributed consensus without the cost, latency, and throughput limitations of conventional blockchain distributed consensus algorithms used for cryptocurrencies. The most important feature of a cryptocurrency 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. As mentioned above the two halves are the promulgation half and the confirmation half.
+
+The promulgation half is under the control of the controller of the private keys. The controller is solely responsible for the security guarantees of its signed key events as well as the promulgation of those events. The controller is not dependent on any other entity for its security. The controller is free to make its promulgation system (witness set) arbitrarily as secure as it desires. Although there is no point in making it more secure than its root-of-trust in its key management. The promulgation infrastructure verifies signature on events already signed by the controller and then generates signatures on those events as receipts. The receipted events are then broadcast. No attacker can forge any signed event or receipt without compromising the signing infrastructure of the associated component. When using multi-sig this means compromising K of the N signatories. Moreover, no attacker can compromise the receipting infrastructure without compromising more than F of the witnesses. The worst an attacker can do without compromising the receipting infrastructure of F witnesses, is to DDOS or delete the broadcast. This is a well delimited and well understood type of attack with well understood mitigation.
+
+The confirmation half is under the control of the validator. The validator is solely responsible for the security guarantees of its confirmation network. This network is verifying signatures on events promulgated by the controller and/or its witnesses. The validator is free to design and implement its confirmation network of watchers to be as secure as it needs and is not dependent on any external entity for that. Because verification happens in the edge, an attacker must attack and overcome a multitude of edge verifiers (watchers) with little net gain per individual exploit. This multiplies the attack surfaces that the attacker must overcome. Mitigation mechanisms for attacks on verifier firmware are also well known. Because verification is largely a fixed operation in software, the verification software may be deployed by the validator in a manner that may not be predictable by any attacker. Once deployed the attacker must individually find, target, and exploit each edge verifier (watcher). By multiplying the attack surfaces with multiple watchers, each validator may arbitrarily increase the difficulty of attack without having to use TEEs for its watchers.
+
+KERI's design enables the validator to make a trade-off. A given watcher under the aegis of the validator may be secured by using a verifiable attestable hardware security module (HSM) (a type of TEE) to perform the end verification operations on the KERI events. This approach may provide assurance to the validator that the cryptographic signatures are verified correctly and that the verification software/firmware on the watcher has not been tampered with. Or the validator may choose to use a threshold structure to secure the signature verifications of its watchers through a distributed consensus pool of confirming nodes that each perform the signature verification and then compare results. Or the validator may choose to use a combination of both where each watcher uses an HSM/TEE to protect its signature verification so that fewer watchers are needed because each watcher is correspondingly more secure.
+
+Likewise, the promulgation (controller) can make similar trade-offs for its witnesses. More witnesses without HSM/TEE for signature verification and receipt generation or fewer with HSM/TEE. But most importantly the separation of control via the splitting up of promulgation and confirmation enables each to design and implement according to their desired guarantees of security.
+
+In summary, by splitting the attack surfaces into two independent sides. The controller (promulgation side) and the validator (confirmation side) each may independently set their security levels by multiplying their own attack surfaces separably.
+
+Nonetheless in the special case when the signature verification is performed on a single device (a single watcher) then that watcher/verifier may very well benefit from using a TEE in order to have the same degree of security as the controller when the controller is using a TEE. But if the validator is using a pool of watchers then the watchers as a pool may be as secure as a controller's TEE without any of the watchers using a TEE.
+
+KERI by design puts verification at the edge. The weakest case is an application where there is only one verifier/watcher. One example of this is a mobile device under the physical control of the validator. But even in this case verification at the edge means the attacker is fighting an asymmetric war where the asymmetry is in the favor of the validator. In spite of a lot of effort, an attacker may only compromise one device at a time. This assumes non-common mode exploits such as exploiting the crypto library on GitHub that sources the verifier's software.
+
+In other use cases where the device is not under the physical control of the validator such as a remote payment card reader, or some other like application where the sole verifier is a known high value target, then the verifying device may benefit greatly from using a TEE.
+
+As a use case, the end verifiability of KERI opens up an opportunity for HSMs for signature verification. Typically mobile phone devices could be used as a type of general purpose HSM for KERI event signature verification but a dedicated device that only does verification may provide a better security for cost trade-off. Currently there are many low cost hardware devices (HSMs) such as a Ledger Nano, UbiKey, Trezor etc. that provide signature generation. But not so for signature verification. With KERI there may be applications where verifiable attestable HSMs may be used for event signature verification. The trusted computing group recently released a standard for low cost HSM chips that would be applicable to HSM for signature verification for end verifiers \[52\]. This may be used in combined with the IETF standard for remote attestation \[39\]. Together a validator could implement an HSM for end verification where it could query the HSM and be assured via a signed attestation from the HSM that its signature verification firmware has not been tampered with.
+
+KERI makes some assumptions about a verifier.
+
+-   The software/firmware that is doing the signature verification is under the control of the validator.
+-   The verification hardware/software is not dependent on any external infrastructure to do the verification at the time of verification other than to receive a copy of the events.
+-   The software/hardware that is verifying signatures has not been compromised. Singly when only one watcher or multiply above a threshold when using multiple watchers. If the verification software/firmware has been compromised then no cryptographic operations run by the verifier may be trusted by the validator. But given the three assumptions above, the worst that an external attacker can do when attacking a verifier is a DDOS or delete attack to prevent the verifier from seeing the events. An attacker may not forge events to deceive a verifier.
+
+Duplicity detection, which protects, not against an external attacker, but against a malicious controller does require access to watchers that are also recording duplicitous events. So this may be viewed as a dependence on external infrastructure, but its dependence is generic. Furthermore, the goal is to make duplicity detection ambient such that a malicious controller may be easily detected.
+
+KERI's separable control design allows the controller and each validator to independently design their infrastructure. Because KERI is not dependent on a shared public ledger, each may implement their KERI components using off-the-shelf cloud computing infrastructure. Best practices for implementation should follow zero trust computing principles. These principles are described at more length elsewhere but may be summarized as follows \[10\]:
+
+1.  Network Hostility.
+    The network is always hostile, internally & externally; Locality is not trustworthy. 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 every-thing.
+    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. Policy is protected by diffuse trust.
+7.  Hosts locked down.
+
+Hosts or host components executing any of the logic mentioned above must be locked down. Any changes to the host execution logic or behavior must be fully security tested and validated over the respective possible combinations of hardware and software platform. 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 specially as 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 secure execution of the application logic (e.g. code injection, insecure object references, cross-site/service request forgery, cross-service scripting, etc.).
+
+One useful way of describing KERI is as a decentralized key management infrastructure (DKMI) based on key change events that supports attestable key events and consensus-based verification of key events.
+
+With KERI, security becomes largely a function of a given participant's infrastructure and not another entity's _trusted_ internet infrastructure. Each controller of an identifier gets to pick their own infrastructure, and each validator gets to pick their own infrastructure. This is a big advantage as it does away with the whole house of cards that are the _trusted entities_ in DNS/CA.
+
+It's much easier to secure one's own keys well than to secure everyone else's internet computing infrastructure well.
+
+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 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 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. The meaning (semantics) of the statement may merely be data that thereby becomes authoritative. Or the meaning (semantics) of the statement may be to convey an authorization for some other function. In either case revoking the authorization of the statement revokes the authoritativeness of the semantics of the statement.
+
+KERI terminology usually avoids that confusion between rotation 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.
+
+Given the KERI definition of rotate as applied to keys, revocation is usually unambiguously applied to mean revocation of the authorization of a signed statement. Otherwise when not clear from the context, one may simply use the modifier key revocation vs. statement revocation.
+
+To clarify, the authority of a signed statement is imbued by the attached signature(s) created with a set of authoritative keys. This begs the question: is a signed statement authoritative/authorized after the keys used to sign it have been rotated? If not, then the statement is effectively revoked as no longer being an authoritative/authorized statement. If the statement is still authoritative/authorized after the keys used to sign it have been rotated, then the statement is not effectively revoked by the rotation itself but requires a separate signed revocation statement that rescinds/revokes its authoritative/authorized status. This revocation statement may be signed by a different set of authoritative keys than the keys used to sign the statement being revoked.
+
+Given that key rotation and statement authorization are two distinct operations, a given identifier system needs to define the model of how to verify the authoritative state of a given authorized statement when the keys used to sign that statement have been rotated. There are several models for determining the status of an authorized statement after a rotation of the keys used to sign that statement. Each authorization model has an associated verification rule.
+
+> Rule 1: Persistent Authorization Model
+
+Any signed statement that is signed with the set of authoritative keys at the time of its signing, is valid until revoked (rescinded) with another signed statement that is signed with the set of authoritative keys at the time of the signing of the revocation statement.
+
+This means that merely rotating keys does not revoke or rescind the validity of prior signed statements. Otherwise every time one rotates keys one would have to reaffirm (reissue) every prior signed statement that used the now obsolete keys. This is the model most compatible with the issuer-holder-verifier model of VCs. A VC is a type of signed statement. In this case, the verifier does not need to communicate with the issuer, but need only communicate with the holder and a verifiable data registry (VDR) to determine the revocation state of the VC. This tripartite model enables more privacy for the holder because the issuer is not able to track each presentation of a VC by a holder to a verifier. KERI may be used to support this model because the key event log (KEL) may be used as a VDR to anchor both issuance and revocation statements.
+
+> Rule 2: Ephemeral Authorization Model
+
+All statements signed with the set of authoritative keys at the time of their signing are automatically revoked when that set of authoritative keys are rotated.
+
+This model of mandatory revocation of all signed statements is most commonly used in token-based security systems where all tokens issued under a given set of keys are automatically revoked when those keys are rotated. A given signed statement is authoritative only if it verifies against the current set of keys. This simplifies the system because no VDR is required. However, this means that whenever the keys are rotated, any continuing authorizations require reissuance of new signed statements using the new keys. This may be problematic when using the tripartite VC model of issuer-holder-verifier. The issuer must push out new VCs to all the holders each time it rotates keys.
+
+Typically, the ephemeral authorization model works best in a bipartite VC model where the verifier requests verification from the issuer directly. In this case, the holder does not actually hold a VC but merely a reference to a VC held on its behalf by the issuer. Alternatively, the identifiers in the VC are dynamic references that resolve to service endpoints. In either case the holder presents the references to the verifier who contacts the issuer directly to determine authorization status. Therefore, when rotating keys, the issuer does not have to re-issue a VC but merely tracks the authorized state of each VC internally. This bipartite approach is less privacy preserving than the tripartite approach because the issuer may now track all presentation requests by the holder. KERI also supports this model in the sense that an issuer may use the KEL for only tracking key rotations and not signed statements.
+
+> Rule 3: Some Authorizations are Persistent, and Some are Ephemeral (Hybrid) Model
+
+Any presentation of a signed statement with persistent authorization must include a reference to its location in the VDR (log) to determine the authoritative keys at the time (location) in the VDR when the statement was signed. The signed statement is authorized until revoked (rescinded) with another signed statement that is signed with the set of authoritative keys at the time of the signing of the revocation statement. If the VDR location reference is absent in the presentation, then the authorization is assumed to be ephemeral and the verifier uses the current authoritative keys to verify the authorization status of the signed statement.
+
+This is a hybrid of Rule 1 and Rule 2. In this model, only logged signed statements use rule 1) and all other signed statements use rule 2). Because Rule 3) requires a log for the persistently authorized signed statements, it may still be privacy preserving relative to a Rule 2 implementation without a log. In this case the verifier need only reference the log (VDR) to get the authoritative keys instead of making a presentation directly to the verifier. KERI supports Rule 3 because it provides both the key state and may also provide any anchored signed statement state.
+
+To elaborate, for Rule 1 or 3 to be practically implemented, one must maintain a verifiable data registry (VDR), such as, either a log of signed statements or a cryptographic commitment (digest) to those statements (via a Merkle tree or hash chained data structure). With a VDR one can verify that a persistently authorized statement was signed with the authoritative set of keys at the time of signing. Verification is always with respect to the set of signing keys used to create the signature at the time the statement was signed. This means the verifier must have a way of determining the history or lineage of control authority via a log or ledger of the key rotation history to know that a persistently authorized statement was signed with the authoritative set of keys at the time of signing. This means that the log or ledger must not only log the lineage of keys (key rotation history), but also the statements (or at least a digest of the statements) signed by those keys. Otherwise, a compromise of the current signing keys (which rotation protects from) would allow an exploit to create forged but verifiable supposedly authorized statements after the keys have been rotated.
+
+The log itself allows the controller to anchor cryptographic digests of any other data to the log at a specific place in the log. One may use the KERI KEL as a hash chain clock. The log provides a point in hash chain time for any anchored data item. That anchor is a cryptographic commitment to that data. The ordering of all anchored statement may then be verifiable like a ledger but without needing a "ledger", as the KEL is effectively a "micro ledger". This means that, with KERI, one may use the KEL as a clock for determining both the issuance and later revocation time for any anchored statements associated with VCs.
+
+If the use of a VDR (log or ledger) is not practical, then only Rule 2 is feasible. This is one reason why token-based authorization systems such as OIDC and JWT only use Rule 2. This means that when the keys used to sign the token have been rotated the token's authorization is automatically revoked; effectively, the token is always verified by the current set of signing keys so it will fail verification after key rotation.
+
+When leveraging authorization tooling to implement VCs, one should carefully consider how much is gained or lost by using tools built for different authorization models.
+
+> Rule 4: Rotate the Identifier not the Keys Model
+
+A signed statement's authorization is persistent until the ephemeral identifier associated with the authoritative keys has been rotated. Rotation of the identifier effectively rotates the authoritative keys.
+
+This model addresses the case where the keys controlling an identifier are not rotatable. This is more common than one might expect (for example, an Ethereum or Bitcoin address). In this case, any signed statement may not be revoked by merely rotating keys because the keys cannot be rotated. Instead, one might be tempted to use a revocation registry to determine if a given signed statement has been revoked by a later revocation statement. This approach is problematic, from a security perspective, because signing keys may eventually become compromised due to exposure at which point an exploiter may then corrupt the revocation registry, rendering the registry unrecoverable. keridoc/ In KERI, an AID or SCID prefix may be declared as non-transferable at inception (which means one may not rotate the AID's or SCID's controlling keys). This means no key event log (KEL) is ever needed. Furthermore, in KERI an identifier that is declared as transferable at inception (i.e. supports key rotation) may later be retired by rotating to a null key, after which no further events are accepted into its log.
+
+By definition, a new SCID has a new unique set of controlling keys. Therefore a practical solution for signed statement revocation of statements issued by SCIDs with non-rotatable keys is to rotate the SCID itself to a new SCID. In this case, one may then use Rule 2) to verify any signed statements made with the old identifier's (SCID) keys vis-a-vis the new identifier's (SCID) keys.
+
+The complication to this solution is keeping track of the fact that the identifier has indeed been rotated. Therefore one still needs a VDR (log or ledger) to track which identifier is authoritative for a given function that relies on signed statements for authorization. So, Rule 4 is yet another hybrid. The hybrid is that a VDR (log or ledger) used to track key rotation and signed statements for one SCID with rotatable keys may also be used to track the state of other ephemeral identifiers with non-rotatable keys where those ephemeral identifiers are authorized by the one rotatable identifier. The advantage of Rule 4 is that one VDR (log, ledger) that is in the trust domain of one AID (SCID) may be used to track ephemeral identifiers (AIDs), not simply ephemeral keys. The advantage of ephemeral identifiers is that they are discoverable whereas bare ephemeral keys are not.
+
+KERI employs the model of Rule 4 for witnesses. Witnesses use ephemeral (non-transferable) identifiers where non-transferable means non-rotatable controlling keys. This greatly simplifies the establishment of control authority for the witnesses. As mentioned above, an ephemeral (non-transferable) identifier needs no event log to establish its control authority. Therefore, verifiers do not need to retrieve key event logs to establish the control authority of a given witness in order to verify witness receipts on events. Should a witness become compromised then the controller of the identifier to which the witness is acting as a witness (not the witness' own identifier) rotates out the compromised witness in a key rotation event and rotates in a new witness with a new identifier. keridoc/ This same strategy may be applied to any management domain where one transferable identifier uses its KEL to track the verifiable authorizing declarations of other ephemeral identifiers. These "authorized" identifiers may be ephemeral because the authorizing declaration statements anchored in its KEL allow the non-ephemeral identifier to track the rotations of the authorized ephemeral identifiers themselves instead of tracking the rotation of the keys for the authorized ephemeral identifiers.
+
+Another example is an IoT application where a marshal maintains a template of the network configuration with a mapping between IoT device identifiers and network addresses. The Marshal may benefit from a transferable identifier but the IoT devices need only use ephemeral (non-transferable) identifiers because should they ever be compromised the marshal may replace their entry in the template with a new identifier (and associated keys).
+
+keridoc/ The root-of-trust for an AID based trust domain in KERI is the self-certifying identifier prefix for that AID. The security of that root-of-trust is essentially the security of the private key(s) that control that identifier prefix. More generally this is the security of the key management of the associated private keys. Recall that in KERI the keys being managed for control authority are cryptographic signing keys. The essential management functions we call the three R's of key management. These are key reproduction (key pair generation and storage), key recovery, and key rotation. Key rotation depends on the reproduction function for new key generation and storage and key recovery provides redundancy in the key storage or recreation. In addition to these management functions the other important relevant operations are event generation and event signing with those private keys. A useful way of viewing key management is that there are two infrastructures. One is the key-pair generation and storage infrastructure and the other is the key event generation and signing infrastructure. This is shown in the figure below.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/univalent-key-man-infra.png)
+
+The fundamental security principle is that secrets (random seeds or private keys) must remain secret. There are various mechanisms and best practices to protect both the key generation and storage and the event signing infrastructures. 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. The movement of keys, especially private keys poses a security risk. The signing operation potentially exposes the private key to a side-channel attack exposed by either the movement of private keys from the generation infrastructure to the signing infrastructure or in the signing computing infrastructure itself. Consequently, a given protection mechanism may co-locate both infrastructures. In this case we may refer to this combined infrastructure 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. These may include one or more of a secure enclave, a hardware security module (HSM), a trusted platform module (TPM) or some other type of trusted execution environment (TEE). The degree of protection 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.
+
+The way KERI addresses this security-cost-performance architecture trade-off is via delegation 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. A successful exploiter must also compromise the delegator's authoritative keys. A nested set of layered delegations in a delegation 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, the key generation and storage functions of the delegator and delegate, in terms of the 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. This is shown in the following diagram.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/bivalent-delegated-key-man-infra.png)
+
+The only data that needs to move between the two infrastructures (delegator and delegate) comes from the associated key events in the delegations. The movement of signed event data does not pose a security risk in any meaningful sense. A signed event is a verifiable statement that contains no secrets and given sufficient cryptographic strength of the underlying one way functions may not be forged by any practical means. The important feature of a delegated identifier prefix is that recovery from a compromise of the private keys of the delegate may be performed via a rotation event authorized by the delegator. In the worst case the delegator may revoke the delegates identifier prefix and replace it with a new one. This allows a beneficial separation of concerns where the delegator's key management infrastructure may be much more secure but less performant while the delegate's key management infrastructure may be less secure but much more performant. The delegate's infrastructure is still protected by recovery via the more secure delegator's infrastructure. In a bivalent setup, the delegator need only authorize delegation events which happens relatively infrequently so that high performance is not needed. Conversely the delegate may need to sign at scale other statements for various application interactions. The following diagram shows the key event streams for a delegation.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/delegation-key-event-streams.png)
+
+This delegation structure may be extended. A delegatorkeridoc/ultiple delegates thereby enabling elastic horizontal scalability. The following diagram shows multiple delegates from a single delegator.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/horizontally-scaled-delegated-key-event-streams.png)
+
+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.
+
+The important feature of such a nested delegation (mulkeridoc/nfrastructure is that the delegator, at the next higher level, may always recover, via a key rotation, from a compromised private signing key of any of its delegates in the next lower level. This nested recovery capability extends all the way up to the root identifier prefix. Thus an extremely well protected but less performant root may be used to protect a tree of less protected but more performant branches. This branching structure may be tuned to varying degrees of security-cost-performance trade-offs.
+
+An entity may provide the root-of-trust for some ecosystem via its root AID. Lets call this the RID for root AID. The RID must be protected using the highest level of security in its key management. Although through the use of a multivalent key management infrastructure, the entity can employ extreme protection of the RID while still enabling more performant key management infrastructure for its operations. The RID should employ a multi-signature self-addressing self-certifying identifier. This should be a minimum of 2 of 3, but 3 of 5 might provide more resistance to signatory unavailability. Suggested for each RID signatory is an air-gapped key generation and storage mechanism. This may include a TPM, TEE, or some other dedicated device. The event signing infrastructure may also be air-gapped and co-located with the the key generation and storage. However with multi-signature protection other component arrangement are viable. keridoc/ The RID key events should only be rotation events. This is the most secure use of KERI. This means that each delegation is performed via an extended rotation event. Each delegation event employs a set of first time, one time rotation keys. A set of dedicated witnesses provide the the RID event stream KERL.
+
+Delegated identifiers are used to control the other components at the top level of the ecosystem. These include a delegate to control internally facing infrastructure and multiple delegates to control different externally facing infrastructures. A notional diagram of those delegations is shown in the following diagram.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/multivalent-delegated-controller-key-management-infrastructure.png)
+
+This key infrastructure must be online in order to issue verifiable credential VC authorization of LIDs at scale. Each key management infrastructure instance may employ a TPM or other TEE for enhanced security. This is a trade-off. keridoc/ The next layer down in the delegation hierarchy may employ one of two control mechanisms depending on how tightly the root entity chooses to control that layer. The two control approaches are as follows: The first is a combination of delegated identifiers for each of the next layer down entities coupled with authorizing verifiable credentials (VCs). The second is merely authorizing verifiable credentials with each entity creating their own trust domains via their own root AIDs. The former case allows the root entity to both recover or revoke delegated AID identifiers not merely the authorizing VCs. The latter case only allows revocation of authorizing VCs and does not enable the root entity to recover or revoke the associated lower lever entity delegated AID. Revocation of the delegated AIDs provides a more comprehensive control mechanism but imposes more of a burden on the root entity for management of those AIDs. The two approaches are shown in the following two diagrams. The first is the delegated AID plus VC approach and the second is the VC only approach.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/multilevel-delegated-key-man-and-VC-issuance-infra.png)
+
+keridoc/
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/delegated-key-man-and-VC-issuance-infra.png)
+
+As described above KERI enables a separation of control between promulgation and confirmation infrastructure. A given promulgation infrastructure is under the aegis of its controller and a given confirmation infrastructure is under the aegis of its validator. In a multivalent key management infrastructure there may be multiple instances of promulgation infrastructure, one for each controller where each delegator or delegate is a controller in its own right at each layer of the infrastructure. Likewise validators of controllers at each layer may have have multiple instances of confirmation infrastructure.
+
+One of the issues facing a root entity that provides the root-of-trust for an ecosystem occurs when the potential ecosystem participants are diverse and each may want to use different promulgation and/or confirmation infrastructure to best meet their application or industry specific needs. Because KERI is agnostic about the specific promulgation or confirmation infrastructure used in each instance, the root entity may choose to support multiple types of promulgation and confirmation infrastructure as per the needs of its ecosystem participants. Moreover, these choices are not fixed but may change over time as technology and ecosystems needs evolve.
+
+Specifically, one important class of infrastructure for both promulgation and confirmation are shared distributed ledgers (blockchains) such as Sovrin or Ethereum. In KERI a special case for both a witness and a watcher is a shared ledger oracle. This is shown in the following diagram.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/shared-ledger-oracles-for-witness-and-watcher.png)
+
+Given ledger oracles as witnesses and in combination with delegated identifiers controlling those oracles, the root entity may implement an heterogeneous promulgation infrastructure using a combination of cloud hosted witnesses and ledger oracle witnesses for its externally facing infrastructure. Each ledger provides the basis for a network of participants associated with that ledger. The ledger itself is also a network of hosts. Thus it is appropriate to call this a network of networks approach to the witness (promulgation) infrastructure. A notional diagram of this architecture is shown below.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/ecosystem-witness-network-of-networks.png)
+
+In the diagram above, the entity cloud box represents a high performant globally distributed and synchronized cluster of KERI witnesses. The Indy/Sovrin box represents at the very least the Sovrin Foundation MainNet and may eventually include any interoperable Indy networks in the Sovrin ecosystem's own network-of-networks. The Ethereum box represents use of the the Ethereum Ledger as a witness. Each of these non-native KERI witness networks will need a KERI interoperability graft. This is already anticipated for inclusion in the new Indy DID method. The following diagram shows in more detail a notional architecture for the controller and witness network of networks.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/ecosystem-controller-and-witness-network-of-networks.png)
+
+We can expand the diagram above to include the watchers and witnesses of the next layer in the delgation hierarchy. This is shown in the following diagram:
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/delegated-ecosystem-participants-in-network-of-networks.png)
+
+The portability of KERI identifier prefixes is provided via the key event receipt log (KERL) for each prefix. A witness provides a copy of a KERL. The control authority over that prefix may be established by verifying the KERL. The KERL provides a cryptographic proof of control authority that is not dependent on the source of the copy of the KERL. Moreover, each prefix merely contains a universally unique string of cryptographic material. A given prefix may be used to control any and all name spaces that share that same prefix. Because a KERL is only concerned with the identifier prefix not any associated name space. The proof of control authority via the KERL is the same for all the name spaces that share the same prefix and therefore share the same KERL. To clarify, the same KERL may be used to prove control authority over any name space that shares its associated prefix. This includes the disparate name spaces for each of the witness networks shown above. This makes AIDs based on KERI truly portable.
+
+As previously discussed in the unified identifier theory section. A given AID forms a trust domain within which LIDs may be verifiable authorized. The root AID, that is, the RID forms the ecosystem trust domain within which the root entity may authorize the issuance of verifiable LIDs. Verifiable issuance of LIDs may be performed using verifiable credentials (VCs). VCs may also be issued as a delegation where a VC issued by one entity authorizes another entity to issue a delegated VCs. The verification logic may then traverse back up the delegation chain to the the root VC issuance. Each VC issuer must have and AID and each VC holder (issued to) must have an AID. These may be either independently generated or delegated AIDs. When the associated entities act under the auspices of the same parent organization then it may make sense to use delegated AIDs for the entities. This has the advantage that the delegated AIDs are published in the delegator's KEL and therefore may not need a separate publication mechanism for verification of authorization to participate in under the auspices of the organization. The delegation events provide that proof of authorization. This delegation chain forms a nested set of trust-domains. This is shown in the following diagram.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/delegated-entity-chain-of-trust.png)
+
+An important detail to understand about VC issuance is that an organization does not actually issue a VC. Some entity that works for the organization actually issues the VC. This entity is usually a natural person but may be a software agent. Ultimately a software agent is managed by some person. Best practices for securing issuance recognizes that persons are the ultimate source of issuance authorization actions. This means that fraudulent issuance is a vulnerability that is a function of the loyalty and accountability of the issuing person or agent to the issuing organization. One mechanism for increasing issuing accountability is to explicitly identify the issuing persons or agents. There are two mechanisms within KERI for doing that. One is to explicitly track the holders of key pairs. Thus any issuance action may be tracked via the signing keys. This has the drawback that a key rotation is required to remove signing authority. This may not be a problem for senior or trusted company officials but may be problematic for front line workers or software agents. The second method for tracking accountability is to issue authorized issuance capability credentials to front-line workers and agents. This adds a more flexibly revocable issuance accountability. The two methods are best employed in concert with both key holder tracking of the organizational VC and tracking of the issuing AID of a delegated VC issuer. This provides two non-common mode accountability mechanisms that have to both be suborned in order to successfully improperly issue a VC. The following diagram extends the previous nested trust domain issuance diagram to include individual employee delegated AID as tracked delegated VC issuers. This provides a highly fraud resistant approach to VC issuance within and across organizations in an ecosystem.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/delegated-entity-with-employee-chain-of-trust.png)
+
+In the diagram above, every entity labeled Employee could just as well be labeled software agent. The diagram shows a gross level of granularity in terms of employee/agent accountability. For more highly automated VC issuance processes a verifiable data supply chain may be used.
+
+As the VC issuance process becomes more highly automated the accountability architecture needs to become more granular. The end result is what we call a verifiable algorithm that uses a provenanced data supply chain. This is described in some detail here \[10; 46\]. A verifiable algorithm is both an explainable algorithm and a transparent algorithm which achieves fine grained GDPR compliance for transparency and fairness verifiability. Furthermore a verifiable algorithm for VC issuance provides point accountability of the individual software agents that contribute to the issuance of each LID VC. An example of a provenanced data supply chain for verifiable algorithms is shown below.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/provenanced-data-supply-chain-for-verifiable-algorithmic-VC-issuance.png)
+
+Each transformation block (with an AID) in the diagram may be a software agent or processing unit that transforms the data provided to it. The data flow shows how each block's transformed data contributes to a final aggregated data product. Because each transform block includes a digest of its priors and each block is signed, then the algorithm itself verifiable. In this case the data product is a VC that authorizes an LID.
+
+A unified model for the design of universal identifier systems is presented. The core concept is that an autonomic identifier (AID) may provide a trust domain for authorized human meaningful identifiers issued within the context of that AID. This authorized human meaningful identifiers are thereby legitimized by association with that AID. We call these legitimized identifiers LIDs. The fundamental construct is the couplet, aid|lid, where the vertical bar represents the authorization or legitimization of the LID with respect to the trust domain of the AID. Given this model, a verifiable LID issuance infrastructure based on KERI is provided. The model includes the decentralized key management infrastructure as well as the verifiable credential (VC) issuance infrastructure. The design trade-offs are explained. This explains the methodology for design and implementation using an autonomic (end-verifiable cryptographic) root-of-trust. This enables true portability of the associated identifiers across different support infrastructures both in time and space. This is an innovative approach that mitigates the primary security vulnerabilities of an administrative (trusted entity) root-of-trust and the primary portability limitations of an algorithmic (shared ledger) root-of-trust. This provides a security model for truly decentralized internet based ecosystems where each ecosystem may control is own trust domain but inter-operably interact with any other trust domain.
+
+The author wishes to thank all those that provided helpful feedback.
+
+![](https://raw.githubusercontent.com/WebOfTrust/keridoc/gh-pages/images/uidt/ssmith-photo.png)
+
+Samuel M. Smith Ph.D. has a deep interest in decentralized identity and reputation systems. Samuel received a Ph.D. in Electrical and Computer Engineering from Brigham Young University in 1991. He then spent 10 years at Florida Atlantic University, eventually reaching full professor status. In addition to decentralized identity and reputation, he has performed pioneering research in automated reasoning, machine learning, and autonomous vehicle systems. He has over 100 refereed publications in these areas and was principal investigator on numerous federally funded research projects. Dr. Smith has been an active participant in open standards development for networking protocols, and decentralized identity. He is also a serial entrepreneur.
+
+\[1\] "Global Location Numbers (GLN): A key enabler for improving efficiency and visibility of the supply and demand chains," [https://www.gs1.org/docs/idkeys/GS1\_Global\_Location\_Numbers.pdf](https://www.gs1.org/docs/idkeys/GS1_Global_Location_Numbers.pdf)
+
+\[2\] "A Deep Dive on the Recent Widespread DNS Hijacking Attacks," KrebsonSecurity, 2019/02/19 [https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/](https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/)
+
+\[3\] "A Universally Unique Identifier (UUID) URN Namespace," IETF RFC-4122, 2005/07/01 [https://tools.ietf.org/html/](https://tools.ietf.org/html/) rfc4122
+
+\[4\] Birge-Lee, H., Sun, Y., Edmundson, A., Rexford, J. and Mittal, P., "Using BGP to acquire bogus TLS certificates," vol. Workshop on Hot Topics in Privacy Enhancing Technologies, no. HotPETs 2017, 2017
+
+\[5\] Birge-Lee, H., Sun, Y., Edmundson, A., Rexford, J. and Mittal, P., "Bamboozling certificate authorities with |BGP|," vol. 27th |USENIX| Security Symposium, no. |USENIX| Security 18, pp. 833-849, 2018 [https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee](https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee)
+
+\[6\] Birge-Lee, H., Wang, L., Rexford, J. and Mittal, P., "Sico: Surgical interception attacks by manipulating bgp communities," vol. Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, pp. 431-448, 2019 [https://dl.acm.org/doi/abs/10.1145/3319535.3363197](https://dl.acm.org/doi/abs/10.1145/3319535.3363197)
+
+\[7\] "Byzantine fault tolerance," Wikipedia,[https://en.wikipedia.org/wiki/Byzantine\_fault\_tolerance](https://en.wikipedia.org/wiki/Byzantine_fault_tolerance)
+
+\[8\] Castro, M. and Liskov, B., "Practical Byzantine fault tolerance," vol. OSDI 99, pp. 173-186, 1999 [http://www.pmg.lcs.mit.edu/papers/osdi99.pdf](http://www.pmg.lcs.mit.edu/papers/osdi99.pdf)
+
+\[9\] Clement, A., Wong, E. L., Alvisi, L., Dahlin, M. and Marchetti, M., "Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults.," vol. NSDI 9, pp. 153-168, 2009[http://static.usenix.org/events/nsdi09/tech/full\_papers/clement/clement.pdf](http://static.usenix.org/events/nsdi09/tech/full_papers/clement/clement.pdf)
+
+\[10\] Conway, S., Hughes, A., Ma, M. et al., "A DID for Everything," Rebooting the Web of Trust RWOT 7, 2018/09/26 [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/A\_DID\_for\_everything.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/A_DID_for_everything.pdf)
+
+\[11\] Cooper, D., Santesson, S., Farrell, S. et al., "RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile," IETF, 2008/05/01 [https://tools.ietf.org/html/rfc5280](https://tools.ietf.org/html/rfc5280)
+
+\[12\] "DIF KERI Python Implementation Repository (keripy)," Decentralized Identity Foundation,[https://github.com/decentralized-identity/keripy](https://github.com/decentralized-identity/keripy)
+
+\[13\] Dingle, P., Hammann, S., Hardman, D., Winczewski, C. and Smith, S., "Alice Attempts to Abuse a Verifiable Credential," RWOT 9, 2020/01/24 [https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.pdf](https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.pdf)
+
+\[14\] "DNS Certification Authority Authorization," [https://en.wikipedia.org/wiki/DNS\_Certification\_Authority\_Authorization](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization)
+
+\[15\] "Domain Name System," Wikipedia, [https://en.wikipedia.org/wiki/Domain\_Name\_System](https://en.wikipedia.org/wiki/Domain_Name_System)
+
+\[16\] "EJC-RFID Info: Item Level Identification," epc-rfid.info, [https://www.epc-rfid.info/sgtin](https://www.epc-rfid.info/sgtin)
+
+\[17\] "EPC Tag Data Standard 1.11," GS1, 2017/09/01 [https://www.gs1.org/sites/default/files/docs/epc/GS1\_EPC\_TDS\_i1\_11.pdf](https://www.gs1.org/sites/default/files/docs/epc/GS1_EPC_TDS_i1_11.pdf)
+
+\[18\] "Ethereum," Ethereum Foundation, [http://www.ethdocs.org/en/latest/introduction/index.html](http://www.ethdocs.org/en/latest/introduction/index.html)
+
+\[19\] Gavrichenkov, A., "Breaking HTTPS with BGP Hijacking," BlackHat, 2015 [https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf](https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf)
+
+\[20\] Girault, M., "Self-certified public keys," EUROCRYPT 1991: Advances in Cryptology, pp. 490-497, 1991 [https://link.springer.com/content/pdf/10.1007%2F3-540-46416-6\_42.pdf](https://link.springer.com/content/pdf/10.1007%2F3-540-46416-6_42.pdf)
+
+\[21\] "GLN Allocation Rules," GS1, [https://www.gs1.org/glnrules](https://www.gs1.org/glnrules)
+
+\[22\] "Global Location Number (GLN)," GS1, [https://www.gs1.org/standards/id-keys/gln](https://www.gs1.org/standards/id-keys/gln)
+
+\[23\] Goodin, D., "A DNS hijacking wave is targeting companies at an almost unprecedented scale," Ars Technica, 2019/01/10 [https://arstechnica.com/information-technology/2019/01/a-dns-hijacking-wave-is-targeting-companies-at-an-almost-unprecedented-scale/](https://arstechnica.com/information-technology/2019/01/a-dns-hijacking-wave-is-targeting-companies-at-an-almost-unprecedented-scale/)
+
+\[24\] Grant, A. C., "Search for Trust: An Analysis and Comparison of CA System Alternatives and Enhancements," Dartmouth Computer Science Technical Report TR2012-716, 2012 [https://pdfs.semanticscholar.org/7876/380d71dd718a22546664b7fcc5b413c1fa49.pdf](https://pdfs.semanticscholar.org/7876/380d71dd718a22546664b7fcc5b413c1fa49.pdf)
+
+\[25\] "GS1 DataMatrix Guideline 2.5.1: Overview and technical introduction to the use of GS1 DataMatrix," GS1, 2018/01/01 [https://www.gs1.org/docs/barcodes/GS1\_DataMatrix\_Guideline.pdf](https://www.gs1.org/docs/barcodes/GS1_DataMatrix_Guideline.pdf)
+
+\[26\] "GS1 General Specifications 20.0," GS1, 2020/01/01 [https://www.gs1.org/docs/barcodes/GS1\_General\_Specifications.pdf](https://www.gs1.org/docs/barcodes/GS1_General_Specifications.pdf)
+
+\[27\] "GS1 GLN Allocation Rules Standard 2.0.1," GS1, 2017/01/01 [https://www.gs1.org/docs/barcodes/GS1\_GLN\_Allocation\_Rules.pdf](https://www.gs1.org/docs/barcodes/GS1_GLN_Allocation_Rules.pdf)
+
+\[28\] "GS1 Lightweight Messaging Standard for Verification of Product Identifiers 1.1," GS1, 2019/07/01 [https://www.gs1.org/sites/default/files/docs/standards/gs1\_lightweight\_verification\_messaging\_standard\_v1-1.pdf](https://www.gs1.org/sites/default/files/docs/standards/gs1_lightweight_verification_messaging_standard_v1-1.pdf)
+
+\[29\] "How Cybercrime Exploits Digital Certificates," InfoSecInstitute, 2014/07/28 [https://resources.infosecinstitute.com/cybercrime-exploits-digital-certificates/#gref](https://resources.infosecinstitute.com/cybercrime-exploits-digital-certificates/#gref)
+
+\[30\] "How to Translate a U.P.C. to a GTIN to an SGTIN to an EPC," GS1, [https://www.gs1us.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core\_Download&EntryId=389&language=en-US&PortalId=0&TabId=134](https://www.gs1us.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=389&language=en-US&PortalId=0&TabId=134)
+
+\[31\] "Introducing the Legal Entity Identifier (LEI)," GLEIF, [https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei#](https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei#)
+
+\[32\] "ISO 17442-1:2020 Financial services " Legal entity identifier (LEI) " Part 1: Assignment," ISO, 2020/08/01 [https://www.iso.org/standard/78829.html](https://www.iso.org/standard/78829.html)
+
+\[33\] "ISO 17442-2:2020 Financial services " Legal entity identifier (LEI) " Part 2: Application in digital certificates," ISO, 2020/08/01 [https://www.iso.org/standard/79917.html](https://www.iso.org/standard/79917.html)
+
+\[34\] Kaminsky, M. and Banks, E., "SFS-HTTP: Securing the Web with Self-Certifying URLs," MIT, 1999 [https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps](https://pdos.csail.mit.edu/~kaminsky/sfs-http.ps)
+
+\[35\] "KERI Project DIF," Decentralized Identity Foundation, [https://github.com/decentralized-identity/keri](https://github.com/decentralized-identity/keri)
+
+\[36\] Mazieres, D. and Kaashoek, M. F., "Escaping the Evils of Centralized Control with self-certifying pathnames," MIT Laboratory for Computer Science, 2000 [http://www.sigops.org/ew-history/1998/papers/mazieres.ps](http://www.sigops.org/ew-history/1998/papers/mazieres.ps)
+
+\[37\] Mazieres, D., "Self-certifying File System," MIT Ph.D. Dissertation, 2000/06/01 [https://pdos.csail.mit.edu/~ericp/doc/sfs-thesis.ps](https://pdos.csail.mit.edu/~ericp/doc/sfs-thesis.ps)
+
+\[38\] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)," IETF 8615, 2019/05/01 [https://tools.ietf.org/html/rfc8615](https://tools.ietf.org/html/rfc8615)
+
+\[39\] "Remote ATtestation proceduresS (RATS) WG," IETF, [https://datatracker.ietf.org/wg/rats/about/](https://datatracker.ietf.org/wg/rats/about/)
+
+\[40\] Serrano, N., Hadan, H. and Camp, L. J., "A complete study of PKI (PKI's Known Incidents)," Available at SSRN 3425554, 2019 [https://papers.ssrn.com/sol3/papers.cfm?abstract\_id=3425554](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3425554)
+
+\[41\] Shae, M., Smith, S. M. and Stocker, C., "Decentralized Identity as a Meta-platform: How Cooperation Beats Aggregation," Rebooting the Web of Trust, vol. RWOT 9, 2019/11/19 [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/CooperationBeatsAggregation.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/CooperationBeatsAggregation.pdf)
+
+\[42\] Smith, S. M., "Kery Event Receipt Infrastructure (KERI) Design," Github, 2020/04/22 [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI\_WP\_2.x.web.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
+
+\[43\] Smith, S. M., "Open Reputation Framework," vol. Version 1.2, 2015/05/13 [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/open-reputation-low-level-whitepaper.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/open-reputation-low-level-whitepaper.pdf)
+
+\[44\] Smith, S. M. and Khovratovich, D., "Identity System Essentials," 2016/03/29 [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf)
+
+\[45\] Smith, S. M., "Meta-Platforms and Cooperative Network-of-Networks Effects: Why Decentralized Platforms Will Eat Centralized Platforms," SelfRule, 2018/04/25 [https://medium.com/selfrule/meta-platforms-and-cooperative-network-of-networks-effects-6e61eb15c586](https://medium.com/selfrule/meta-platforms-and-cooperative-network-of-networks-effects-6e61eb15c586)
+
+\[46\] Smith, S. M., "Decentralized Autonomic Data (DAD) and the three R's of Key Management," Rebooting the Web of Trust RWOT 6, Spring 2018 [https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf)
+
+\[47\] "Sovrin: A Protocol and Token for Self- Sovereign Identity and Decentralized Trust," Sovrin.org, 2018/01/01 [https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf](https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf)
+
+\[48\] Stevens, G., "DNS Poisoning Attacks: A Guide for Website Admins," HashedOut, 2020/01/21 [https://www.thesslstore.com/blog/dns-poisoning-attacks-a-guide-for-website-admins/](https://www.thesslstore.com/blog/dns-poisoning-attacks-a-guide-for-website-admins/)
+
+\[49\] Stocker, C., Smith, S. and Caballero, J., "Quantum Secure DIDs," RWOT10, 2020/07/09 [https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/final-documents/quantum-secure-dids.pdf](https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/final-documents/quantum-secure-dids.pdf)
+
+\[50\] Szabo, N., "Secure Property Titles with Owner Authority," 1998 [https://nakamotoinstitute.org/secure-property-titles/](https://nakamotoinstitute.org/secure-property-titles/)
+
+\[51\] Szabo, N., "Advances in Distributed Security," 2003 [https://nakamotoinstitute.org/advances-in-distributed-security/](https://nakamotoinstitute.org/advances-in-distributed-security/)
+
+\[52\] TCG, "Implicit Identity Based Device Attestation," Trusted Computing Group, vol. Version 1.0, 2018/03/05 [https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf](https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf)
+
+\[53\] "Transport Layer Security," Wikipedia, [https://en.wikipedia.org/wiki/Transport\_Layer\_Security](https://en.wikipedia.org/wiki/Transport_Layer_Security)
+
+\[54\] "Uniform Resource Identifier (URI): Generic Syntax," IETF RFC-3986, 2005/01/01 [https://tools.ietf.org/html/rfc3986](https://tools.ietf.org/html/rfc3986)
+
+\[55\] "Verifiable Credentials Data Model," W3C Candidate Recommendation, [https://w3c.github.io/vc-data-model/](https://w3c.github.io/vc-data-model/)
+
+\[56\] "Verification Messaging: GS1 Lightweight Messaging Standard for Verification of Product Identifiers," GS1, [https://www.gs1.org/verification-messaging](https://www.gs1.org/verification-messaging)
+
+\[57\] W3C, "Decentralized Identifiers (DIDs)," W3C Draft Community Group Report, [https://www.w3.org/TR/did-core/](https://www.w3.org/TR/did-core/)
+
+\[58\] "Well Known DID Configuration: DIF Working Group Approved Draft," DIF, [https://identity.foundation/.well-known/resources/did-configuration/](https://identity.foundation/.well-known/resources/did-configuration/)
+
+\[59\] Windley, P. J., "The Architecture of Identity Systems," Technometria, 2020/09/28 [https://www.windley.com/archives/2020/09/the\_architecture\_of\_identity\_systems.shtml](https://www.windley.com/archives/2020/09/the_architecture_of_identity_systems.shtml)
+
+\[60\] "X.509," Wikipedia, [https://en.wikipedia.org/wiki/X.509](https://en.wikipedia.org/wiki/X.509)
+
+\[61\] "Zooko's Triange, " Wikipedia, [https://en.wikipedia.org/wiki/Zooko%27s\_triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle)
+
+
+
+
+---
+title: Typesense search install and configuration
+description: What is this: the necessary Typesense search engine commands and configs to serve the KERISSE site best
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/typesense-search-install-config/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/typesense-search-install-config/index.md
+---
+
+# Typesense search install and configuration
+
+What is this: the necessary Typesense search engine _commands and configs_ to serve the KERISSE site best
+
+For who: maintainers and search engine configurators that want a head start and learn from _how-we-did_ it for the KERI Suite Search Engine
+
+Objective: because the search engine software is not our core business we chose to organise this away from us as far as possible. So we hire Typesense hosting | TBW link |
+
+Result: A configuration that automatically indexes all native and scraped content in a way that we integrate pre-configured features with every run, like:
+
+-   overrides
+-   synonyms
+-   nearby vector searches
+-   ranking
+-   filtering options
+
+These are the instructions we followed and implemented in the site, from Oct 2022.
+
+[Subsribe here](https://www.typesense.org/)
+
+[Docusaurus-Typesense install](https://docusaurus.io/docs/search#using-typesense-docsearch)
+
+| @kordwarshuis TBW |
+
+| @kordwarshuis TBW |
+
+what more?
+
+
+
+
+---
+title: Overrides
+description: See//github.com/WebOfTrustkeridoc/blob/main/search-index-typesense/overrides.sh#L6
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/overrides/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/overrides/index.md
+---
+
+# Overrides
+
+See: [https://github.com/WebOfTrustkeridoc/blob/main/search-index-typesense/overrides.sh#L6](https://github.com/WebOfTrustkeridoc/blob/main/search-index-typesense/overrides.sh#L6)
+
+
+
+
+---
+title: IP rights of scraped sources
+description: What is this: accountability for having asked permission, where needed, to use the sources on the internet and scrape (copy) and index them into the Typesense search engine
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/ip-rights-scraping/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/ip-rights-scraping/index.md
+---
+
+# IP rights of scraped sources
+
+What is this: accountability for having asked permission, where needed, to use the sources on the internet and scrape (copy) and index them into the Typesense search engine
+
+For who: anyone concerned about IP rights of third parties in relation to what we're doing with KERISSE
+
+Result: peace of mind, hopefully
+
+It depends.
+
+-   On Github.io for Reading and Referencing
+-   On Github.com for Creation, Update & Delete and Github (transformation) Actions
+-   On any text-base webpage and Kerific tool installed: Adoption & Creation-reminder
+
+We have personally asked permission to scrape:
+
+-   the blogs that we offer in KERISSE
+-   the website keri.one of Samuel Smith
+
+We don't need extra explicit permission because the license allow us to scrape, index, change, amend the data:
+
+-   all the data on github.com under Apache-2 license
+-   all the glossaries we import and combine
+
+We try to acknowledge people's effort and intellectual property at least once on our KERISSE site. If you feel we need to acknowledge better or more, just create an issue [here](https://github.com/WebOfTrustkeridoc/issues) and we will look into the claim. keridoc/
+
+In case we've madde a mistake. Just create an issue [here](https://github.com/WebOfTrustkeridoc/issues) and we will look into the claim. Worst case we'll drop the source of our import-scraping-indexing tools and we'll go look for other data elsewhere that fits into the Apache-2 open source educational resources we provide.
+
+
+
+
+---
+title: Create a search index
+description: Instructions plus background.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/create-search-index/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/create-search-index/index.md
+---
+
+# Create a search index
+
+Instructions plus background.
+
+To add a website to the search index there are three parts to consider:
+
+1.  Obtaining a sitemap.xml
+2.  Scraping all the URLs in the sitemap
+3.  Importing the content into the search index
+
+Everything is done via the terminal (command line).
+
+Find out if the website has a sitemap.xml.
+
+If the website is `https://the-website.com` then try `https://the-website.com/sitemap.xml`, if that gives a list with URLs then that is your sitemap. Write it down so you can use it in a moment.
+
+If it does not exist, or you think it is not up to date then make a sitemap via de Kerisse sitemap creator:
+
+Open `search-index-typesense/config/config_sitemaps_create.sh` and follow the instructions.
+
+There are two sections _General websites_ and _Github repos_. Use _sitemap-generator_ for a website in general and use the specialized _createSitemapGithub.mjs_ for Github repo's.
+
+Now that we have the URLs that we want to scrape, we have to configure the scraper.
+
+Open `search-index-typesense/config/configScraperGenericSitemaps.mjs`.
+
+> [!NOTE]
+> > [!NOTE]
+> > note
+> > [!NOTE]
+> > For every website there is a config object and a function. Every function has to be exported. This is not very user-friendly, and will change in the future.
+
+Now go to the main menu:
+```
+sh search-index-typesense/main.sh
+```
+Choose option \[1\] Scrape all sites
+
+It can take a long time before the scraper finishes. The terminal will output what is happening.
+
+After the scrape session has finished, go to the main menu again:
+```
+sh search-index-typesense/main.sh
+```
+and choose option \[3\] Import
+
+Now the new content will be imported into the Typesense system (in the cloud).
+
+Go to the config section: `search-index-typesense/config/`
+
+For manual entries in the search index, see [this Readme](https://github.com/WebOfTrust/keridoc/blob/main/search-index-typesense/config/config-search-index-entries-manual/README.md)
+
+For manual created sitemaps, see [this Readme](https://github.com/WebOfTrust/keridoc/blob/main/search-index-typesense/config/config-sitemaps-exlude-urls/README.md)
+
+For manual created sitemaps, see [this Readme](https://github.com/WebOfTrust/keridoc/blob/main/search-index-typesense/config/config-sitemaps-manual/README.md)
+
+It is possible to override search index entries and give them prio in the search results.
+
+Example:
+```
+[
+    {
+        "name": "Diger",
+        "query": "Diger",
+        "url": "https://github.com/WebOfTrust/keripy/blob/main/src/keri/core/coring.py",
+        "position": 1,
+        "match": "exact"
+    }
+]
+```
+For who is this _how-we-did_: Maintainers of the KERISSE site
+
+Why should you stick to this step by step: | @kordwarshuis ?? |
+
+The creation of a search index for a website involves three steps:
+
+1.  Decide which webpages (URLs) we want in our search index
+2.  Retrieve the content of the URLs (scraping)
+3.  Import the content into the Typesense search index
+
+You cannot be sent out to fetch something if they don't tell you where to go. That is what a sitemap is for.
+
+We have to create lists that contain all URLs that should be visited and scraped. These lists are called _sitemaps_.
+
+A sitemap is a list of URLs. The most common format is XML.
+
+There are three kinds of sitemaps we have to deal with:
+
+1.  The sitemap.xml can be **remote**, that means, it is located at the domain that you will scrape, usually in the root, named “sitemap.xml”. It is also a source for search engines like Google and Bing. If this is not present, we have to look further:
+2.  The remote sitemap can also be in the form of an **HTML sitemap**. This sitemap is meant for human visitors but can also be read by scrapers. If this also does not exist, we have to create something ourselves:
+3.  The sitemap can be a local sitemap. Meaning: this sitemap is **created by you**, using a sitemap builder or manually.
+
+The scraper uses the sitemaps as input and goes through all the URLs and indexes all paragraphs, lists, tables, code fragments, and saves it in JSONL (a special form of JSON) format.
+
+When all the URLs of a website (or multiple websites) have been scraped and captured in JSON, this JSON is imported into the search engine. The search engine we use is called **Typesense**, and the data is imported into their cloud solution.
+
+In **Typesense** a “document” is what a “record” is in a database.
+
+The documents we want to import have to follow a schema ([Example schema on the Typesense website](https://typesense.org/docs/26.0/api/collections.html#with-pre-defined-schema)). We created our own schema for Kerisse.
+
+More info on the [Typesense website](https://typesense.org/docs/).
+
+-   Test If Required Libraries Are Installed
+-   Initializing
+    -   Get the directory where the main.sh script is located
+-   Preparing
+    -   Prepare file system. Remove old files and directories and create new ones.
+    -   Copy handmade stuff: entries for direct import into Typesense, manual files, sitemaps.
+    -   Create sitemaps via sitemap-generator.
+    -   Remove unwanted urls from the sitemaps (new sitemaps generated or not)
+    -   Filenames to lowercase.
+    -   Fetch external content from Google Sheets.
+-   Start Scraping
+    -   Scrape the websites.
+    -   Split the content.jsonl file into multiple files so the size is optimal for Typesense.
+    -   Count the total number of lines in all .jsonl files and write it to log dir.
+    -   Sort and style the index file.
+-   Backing Up
+    -   Backup output (scrape results, handmade stuff, sitemaps, logs, webpage overview, typesense export).
+
+The following tools are used for scraping:
+
+-   Cheerio
+-   Puppeteer
+
+“[Cheerio can parse nearly any HTML or XML document. Cheerio works in both browser and server environments.](https://cheerio.js.org/)”
+
+“[Puppeteer is a Node.js library which provides a high-level API to control Chrome or Firefox over the DevTools Protocol or WebDriver BiDi. Puppeteer runs in the headless (no visible UI) by default but can be configured to run in a visible ("headful") browser.](https://pptr.dev/)”
+
+![](https://weboftrust.github.io/keridoc/assets/images/scraping-1d8a5c98ffb43b69eb989d27171b175a.md)
+
+
+
+
+---
+title: Kerific Discord bot
+description: See the Kerific Discord Bot README.MD
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/kerific/kerific-discord-bot/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/kerific/kerific-discord-bot/index.md
+---
+
+# Kerific Discord bot
+
+See the [Kerific Discord Bot README.MD](https://github.com/kordwarshuis/kerific-discord-bot/blob/main/README.md)
+
+Here you will find information on the Kerific Discord bot that is Hosted on Heroku. The bot can retrieve information concerning KERI.
+
+
+
+
+---
+title: Kerific Bookmarklet and Chrome Extension
+description: Your browser does not support video tags.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/kerific/kerific-browser-extension/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/kerific/kerific-browser-extension/index.md
+---
+
+# Kerific Bookmarklet and Chrome Extension
+
+Your browser does not support video tags.
+
+[Link to the video](https://weboftrust.github.io/keridoc/assets/files/kerific-explainer-1-2199979b43b727db0b31d9732798469f.md)
+
+The “Kerific” bookmarklet / chrome webinspector will look for Keri-related terms, and add buttons below each paragraph with these terms. On click it will show definitions of the term in various Keri-related glossaries.
+
+Clicking on the bookmarklet or extension will add the buttons.
+
+The differences between the bookmarklet and the Chrome extension are:
+
+-   The bookmarklet is blocked on some sites, where the Chrome extension is allowed
+-   The bookmarklet is updated more frequently. They share the same source code but adding a new version of the exension to the Chrome store is a time consuming task and it takes about a day before it is approved.
+
+Drag the bookmarklet to your bookmarks bar / favorites bar → [Kerific](https://weboftrust.github.io/keridoc/docs/how-we-did/kerific/kerific-browser-extension/javascript:\(function\(\.md)%7B var existingScript = document.getElementById\('kerific-83450285767488'\);var existingCSS = document.getElementById\('kerific-css-83450285767488'\);if \(existingScript\) %7BexistingScript.remove\(\);%7D if \(existingCSS\) %7BexistingCSS.remove\(\);%7D var jsCode = document.createElement\('script'\);jsCode.setAttribute\('src', 'https://weboftrust.github.io/kerific/assets/index.js'\);jsCode.setAttribute\('id', 'kerific-83450285767488'\);document.body.appendChild\(jsCode\);var cssCode = document.createElement\('link'\);cssCode.setAttribute\('rel', 'stylesheet'\);cssCode.setAttribute\('type', 'text/css'\);cssCode.setAttribute\('href', 'https://weboftrust.github.io/kerific/assets/index.css'\);cssCode.setAttribute\('id', 'kerific-css-83450285767488'\);document.head.appendChild\(cssCode\);%7D\)\(\);)
+
+The “Kerific” Chrome extension is available in the webstore.
+
+You find it here: [Kerific in Chrome webstore](https://chromewebstore.google.com/detail/kerific/ckbmkbbmnfbeecfmoiohobcdmopekgmp)
+
+
+
+
+---
+title: The Terms WOT manage structure explained
+description: What is this: A description of architecture and follow-up technical design
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/why-terms-wot-manage-structure/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/why-terms-wot-manage-structure/index.md
+---
+
+# The Terms WOT manage structure explained
+
+What is this: A description of architecture and follow-up technical design
+
+For who: anyone that likes to understand the architecture and how-we-did build KERISSE using `github.com` and its wiki, Typesense and Docusaurus and actions, resulting in the WOT-terms repo `github.io` site.
+
+To generate our static content site on the Github project page of this [WOT-terms page](https://weboftrust.github.iokeridoc/) repo, we have:
+
+1.  wiki resources, terms in separate `.md` files in a Docusaurus directory structure
+2.  a sheet called _Terms WOT manage_ (`a Google sheet`) a central location with strict editing rights: [here](https://docs.google.com/spreadsheets/d/18IUa-1NSJ_8Tz_2D-VSuSQa_yf3ES1s_hovitm3Clvc/edit?pli=1#gid=209150977).
+3.  From this central sheet you can go where ever you like: e.g. a "comma separated" file _Terms WOT manage_ (`.csv`) exported from the Sheet in any directory locally. In fact it's a semi-colon-separated text file that you might get; so check the result.
+
+![Terms-wot-manage-screen-example](https://weboftrust.github.io/keridoc/assets/images/Terms-wot-manage-screen-example-24bbfca4f566f29a41a9024396966af2.md) ![csv-utf-8-save-as](https://weboftrust.github.io/keridoc/assets/images/csv-utf-8-save-as-46a64cc6223bb7c50d83800294177006.md)
+
+_How-we-did_ in 2023 and onwards is:
+
+-   use Google Docs to maintain and edit the structure and content of the sheet
+-   pull in the data and the structure into JSON format using github actions script | TBW @kordwarshuis |
+
+We need a place where terms are defined and declared. A sheet of terms is very practical:
+
+-   lots of software available to amend and manage sheets
+-   many people have the skills to manage sheets with this type of software (Excel, Google sheets, Numbers, etc.)
+-   a sheet can enforce a notion of a unique value ('Key') in a column, a meaningless long-living identifier
+-   sheets can be flexibly expanded so that the content gets richer: tags, categories, dictionaries, etc
+-   sheets can be exported to comma separated files (CSVs)
+-   resulting CSVs can be imported into markdown, front matter, yaml files, etc.
+
+The reason it's called '_Terms WOT manage_':
+
+1.  it's the management tool of our unique terms identifier
+2.  it covers all the concepts, terms, categories, dictionaries, tags in the WebofTrust (WOT) field.
+3.  The smallest unit of declaration is a 'Term'.
+
+A term is a bitch. A term might have one or more abbreviations that are assimilated already (e.g. 'PTEL' and 'Public TEL' for public-transaction-event-log). It can be lower case, upper case, mixed case (e.g. 'vLEI'). it can be singular and plural (e.g. 'OOBIs' is more used than 'OOBI'). So, to have a term as identifying `Key` to itself (self-referential) is a pain as long as the process hasn't completed; the term hasn't _hardened_ yet. This process is very different for every single term. For example `icp: tag` doesn't even have a proper term name yet (mid 2022).
+
+-   Start: We need a 'Key' field to identify a most probably changing term and prevent the database from getting polluted with double terms.
+-   Midlife: We need a 'Key' field to uniquely identify a term that might have various names used in the same (!) context.
+-   End: A term is well-known, agreed upon by the community, therefore assimilated and unique, and we don't need 'Key' anymore.
+
+1.  We prefer **a singular expression** over plural expression. So for example the term is OOBI not OOBIs, unless it's grammatically incorrect (can't think of anything now).
+2.  We use **lower case** as much as we can in the long (identifying) terms. The abbreviated term are linkers: they will get a `## See` header and a link to the long more meaningful term in itself.
+3.  **Longer compound terms take precedence** over the parts. `public TEL` or `public-transaction-event-log` is apparently worth explaining as a special form of `TEL` or `transaction-event-log`. So we first look for a hit on the longer term while parsing texts.
+
+Columns are comparable to _fields_ in a database. The rows are the _records_ in a database.
+
+Field _names_ are in the first row. A few columns maintain our database-like structure:
+
+-   Key: a unique incremental meaningless numeric identifier. The uniqueness is not enforced by code, but by userinterface: conditional formatting colours the cells with the same value red. The Key field becomes redundant as soon as the term itself is a well-known meaningful Key and Term at the same time, like a [country code](https://www.countrycode.org).
+-   Type: for filtering purposes. The field has only one character, it always fits in the general category, but maybe the terms is inherently more specific to subsequently SSI, Autonomic identifiers and finally the KERI suite.
+    -   `K`: KERI suite specific terms
+    -   `A`: Autonomic Identifier specific
+    -   `S`: SSI specific
+    -   `G`: General
+-   Form: mainly for explanatory reasons, possibly filtering. The field has only one character that best fits the form description of the term.
+    -   `n` : noun
+    -   `v` : verb
+    -   `a` : adjective/adverb
+    -   `r` : relation
+-   Text : This is the short description of the term. It will be shown as a popup after pressing the `+` sign. This sign is located after any link in glossary definition texts to a term that we have registered in the WOT-terms sheet. The Level of the description is mostly `1`; which means "Digital Identity advanced knowledge"
+-   Link: The direct link to the source input utility, from 2022 and still in 2024 being the wiki op the repo on github.com
+-   Level : level of understanding. In what kind of language is the term definition expressed? The field has only one character.
+    -   `3` : KERI expert (to be); this is the target group of KERISSE
+    -   `2` : SSI expert (decentralized IDs)
+    -   `1` : Digital Identity advanced knowledge
+
+> Observation: we do not serve laymen. Exception: Level `4` is extraordinary level. Philip Feairheller in 2021: "this the level only KERI Suite founder Sam Smith can formulate and understand, nobody else can". If you happen to come across level 4 text in the KERI Suite, don't feel lonely. :)
+
+-   TTTTT\_FKey: this columns contains foreigns key into another table or sheet. TTTTT can be a file that has terms mentioned in a video ("PhilVid") or another Glossary ("eSSIF-lab") that are related to the matching term on a specific row in our sheet.
+-   Cat\_CCCCC: this columns contains Categories. We consider a term from a certain category went it's mentioned regularly in the content of certain repository (e.g. 'KERI' or 'OOBI') of the WebofTrust Github site.
+
+One term per row. We give **an extra row to the abbreviation** of a term. The reason fot this is a ToIP convention:
+
+-   the term is lowercase and has '-' between the words of the term, e.g. 'key-event-log'
+-   the abbreviation is uppercase and can have a hyphen, e.g. 'VC-TEL'
+-   the term always has a corresponding .md file in the ToIP Glossary, its .md file has a '## Definition' header
+-   the abbreviation (if relevant, which is a subjective guess by the team) also has a corresponding .md file in the ToIP Glossary, its .md file ONLY has a **'## See' header**. The 'See' contains a link to the matching term.
+
+KEL.md:
+```
+## See
+[Key event log](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/why-terms-wot-manage-structure/key-event-log.md)
+```
+key-event-log.md:
+```
+## Definition
+A verifiable data structure that is a backward and forward chained ...
+```
+We're generating static websites, for good reasons. [More info](https://www.cloudflare.com/en-gb/learning/performance/static-site-generator#Pros). But feel free to Google comparison and evaluations which direction you consider best. E.g. [wpamelia.com](https://wpamelia.com/static-vs-dynamic-website/?gclid=Cj0KCQjwxveXBhDDARIsAI0Q0x234PSArlYOfbriIL6u0g3RUlRST8zfdAnYtkrRSs-GJ3RdgwaCSaEaArioEALw_wcB).
+
+Because we've chosen a static site generator, [Docusaurus](https://docusaurus.io) for the time being, but there are other open-source options, **a database would be balast**.
+
+The counting tool is offered by Blockchainbird.org and has been develop in 2019 as a means to assess the level of real expertise in blockchain publications. It crawled through a pdf, based on a dictionaries of terms and very simple business rules.
+
+> E.g. If a pdf mentions 'bitcoin' in conjunction with words like 'scam', 'tax evasion', etc. we considered the writers as not being informed too well about the true nature of the bitcoin / blockchain innovation.
+
+The actual presence of a certain glossary term in documents and webpages is a strong indication whether the term at hand is relevant in a certain section. Based on this relevance expressed in an objective count we can automatically added certain tags and categories to the term.
+
+> The term 'out-of-band' has lots of 'hits' in the OOBI repo, but much less so in the KERI repo.
+
+Based on this relevance expressed in an objective count we can automatically added certain tags and categories to the term.
+
+> The term 'out-of-band' wil have an impressive count in the column `Cat_OOBI`. We might offer a high level menu item for the term in the sidebar of the WebofTrust Glossary 'OOBI'.
+
+The other reason is that a manual check for terms in documents is a very strenuous and time-consuming effort. And the result is always outdated per definition: once your change the source, the glossary needs to be updated too.
+
+**In brief:
+We count, so we're lazily up to date.**
+
+Recently the tool has been engineered towards the WOT-terms challenge:
+
+-   it crawls any Github page and also pdfs (if necessary)
+-   the tool uses the 'Terms WOT manage' sheet to match terms
+-   the scores are based on a combination of parameters:
+    1.  level of (understanding need for) the term
+    2.  number of appearances, the actual count
+
+-   Some abbreviations are too short. The acronyms match non-relevant things in the text. E.g. "AN", "AID" and "SAID". We need to look for "(AN)", " AN " or at the beginning of a paragraph: "\\nAN " instead.
+-   multiple-word expressions like "virtual-credential-transaction-event-log" should be looked for using "virtual credential transaction event log".
+-   The longer combination that matches exactly, takes precedence in the count: "virtual-credential-transaction-event-log", then "credential transaction event log" and lastly "transaction event log". No double counts here. Same with acronyms: an exact match for "VC-TEL" implies that there's no count for "TEL". Lastly also in syllables: a hit for "keridemlia" doesn't count "keri" in this word.
+
+The count of terms are in the Cat\_CCCCC columns after a (re)run of the counting tool.
+
+| TBW prio 1: the tool is currently being re-developed, August 18 2022 |
+
+-   Key: We might need a Key field **to be able to** have a unique long-livinkeridoc/r for a term in the WebofTrust domain. However, any term goes through a life cycle, with the end state of a term being well-known, unchanged for a while and unique. The `Key` field has become superfluous by then.
+-   Type: We don't need this, but it's courtesy to users / learners to be able to filter or select just specific terms to SSI, Autonomic identifier space and KERI suite specific consequetively.
+-   TTTTT\_Fkey / TTTTT\_start: We use this Foreign Key to link to other educational resources of the this term, like Youtube footage\*, webpages and other glossaries.
+-   level: We assess a [level of understanding](https://github.com/WebOfTrustkeridoc/blob/main/README.md#levels-of-understanding) to meaningful study a term. Regardless this subjective and personal judgement, the filtering options are numerous:
+
+1.  offer everything (a glossary)
+2.  offer a learning trajectory
+3.  filter in the opposite direction: exclude terms for experts; don't bother them with Noob answers.
+4.  etc.
+
+-   Cat\_CCCCC: we are now able to store the [counts](#counting-tool) and then offer the term in various relevant contexts at the front end of the site.
+
+'\* Youtube footage: plus the start time of where the term is mentioned first or most extensively. keridoc/
+
+Per term various levels of explanation (plus related further readings) are offered within one source file `.md`. The reason for this is that every individual learner is different. Within the source file of a term we can label "stars" to both questions and answers, compliant to what's explained in this section of the README.md file : [Levels of Understanding](https://github.com/WebOfTrustkeridoc/blob/main/README.md#levels-of-understanding.md)
+
+By offering "everything we have" about a certain term in one file, a reader is able to identify herself / himself with a certain level in a specific context and "filter the stars" in an eye blink.
+
+Three major applications: keridoc/ Being the home of our terms maintenance, we [load ToIP glossary](https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/load-glossary-weboftrust-in-docusaurus.md) and generate our Docusaurus [static content site](https://weboftrust.github.iokeridoc/) on Github. This whole process is steered with the content in the _Terms WOT manage sheet_.
+
+Any resource that mentions WebofTrust terms can be much easier enriched with the use of _Terms WOT manage sheet_. For example, we can create a [terms link table for any footage](https://weboftrust.github.io/keridoc/docs/how-we-did/[https:/github.com/WebOfTrustkeridoc/blob/gh-pages/how-we-did/create-terms-link-table.md]\(https:/github.com/WebOfTrustkeridoc/blob/gh-pages/how-we-did/create-terms-link-table.md)) from the sheet Terms WOT manage sheet.
+
+Integration and synchronisation with other glossaries and destination information sources is possible by maintenance of Key and Foreign Keys in _Terms WOT manage sheet_.
+
+This is a non-exhaustive list of application options.
+
+
+
+
+---
+title: Github Actions
+description: For who
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/organization-of-Github-Action-scripts/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/organization-of-Github-Action-scripts/index.md
+---
+
+# Github Actions
+
+This article is for maintainers, but also users who'd like to know what actions get triggered by what type of events.
+
+Results: insight in the choice around our Coninuous Development Continuous Integration (CDCI) process.
+
+Github Actions are readible for most people who are able to read pseudo-code. The structure and organization of our Action scripts and those brought in by third party tools like Docusaurus, can be distilled fom the [source code](https://github.com/WebOfTrustkeridoc/tree/main/.github/workflows). However, we 'd like to offer a convenient insight in the structure and working.
+
+-   script are set off by hand or automatic? Or both? In which situation would you apply these options.
+-   are certain Action scripts calling eachtother? If so it needs to be clear under what circumstances.
+
+There are currently five Github Actions. All actions should be started manually. One script is started via Cron: the “Find broken links” action. No actions are triggered by Push commits.
+
+This means that after updating the Wiki, you should run the “Import wiki” action manually to get the new content into this repo. If you wish to publish the new content to the website, you should run “Deploy to Github Pages”.
+
+The same goes for importing external glossaries and importing metadata.
+
+1.  **[Deploy to Github Pages](https://github.com/WebOfTrustkeridoc/actions/workflows/deploy-to-gh-pages.yml)**:
+    -   runs on workflow\_dispatch (manual start)
+    -   receives changes that are pushed (content updates, e.g. HowTo's, or design updates)
+    -   builds and copies _/build_ to gh-pages
+2.  **[Find broken links](https://github.com/WebOfTrustkeridoc/actions/workflows/find-broken-links.yml)**:
+    -   runs on _cron_ and _workflow\_dispatch_ (manual start)
+    -   checks links
+    -   creates issue
+3.  **[Import external glossaries](https://github.com/WebOfTrustkeridoc/actions/workflows/import-external-glossaries.yml)**:
+    -   runs on _workflow\_dispatch_ (manual start)
+    -   updates external glossaries
+    -   pushes updates into repo
+4.  **[Import meta data from google sheets](https://github.com/WebOfTrustkeridoc/actions/workflows/import-metadata-google-sheet.yml)**:
+    -   runs on _workflow\_dispatch_ (manual start)
+    -   updates meta data from google sheet
+    -   pushes updates into repo
+5.  **[Import wiki](https://github.com/WebOfTrustkeridoc/actions/workflows/import-wiki.yml)**:
+    -   runs on workflow\_dispatch (manual start)
+    -   copies wiki to /docs/glossary
+    -   pushes changes into repo
+6.  **Scraper**: To Be Created
+    -   runs on _workflow\_dispatch_:
+    -   scrapes various sources
+    -   imports result into Typesense, makes backup, etc
+    -   pushes updates into repo
+
+
+
+
+---
+title: JavaScript documentation
+description: Client Side and NodeJS JavaScript documention using JSDoc (opens in new tab)
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/javascript-jsdoc/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/javascript-jsdoc/index.md
+---
+
+# JavaScript documentation
+
+[Client Side and NodeJS JavaScript documention using JSDoc (opens in new tab)](https://weboftrust.github.io/keridoc/JSDoc/index.md)
+
+
+
+
+---
+title: File system
+description: For who: maintainers and developers
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/file-system/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/file-system/index.md
+---
+
+# File system
+
+For who: maintainers and developers
+
+WHy: traversing the file system and understand what you see
+
+Result: faster more efficient and less error-prone work if we show and explain _how-we-did_ set it up.
+
+See the [Docusaurus documentation](https://docusaurus.io) for a general explanation of the file system.
+
+Here follows a brief description of the specific directories and files of KERISSE:
+
+| @kordwarshuis |
+
+![](https://weboftrust.github.io/keridoc/assets/images/file-system-1f73032f54e85c83f3eb836d232e7098.md)
+
+
+
+
+---
+title: Docusaurus process
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/docusaurus-process/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/docusaurus-process/index.md
+---
+
+# Docusaurus process
+
+Canvas 1Page readyRectanglePage ready to viewConnectionClient sideCross linksinsertVideoInsert SubtitlesDynamic Tablesmake overview table go full screenwrite changes to OverviewHorizontal Scroll HintShow inline definitions On ClickAdd knowledge level andtype category as html attribto Show GPT summaryBrowser (Client Modules)Run in parallelCLIENTSERVER-SIDEServer sideImport Google Sheet datainto .md file (Node.js)RectangleServerRun Docsaurus BuildDeploy as website to GitHub PagesCLIENT-SIDEEvery time a new versionof the websiteis pushed toGithub pagesEvery time a webpageis loaded intothe browser
+
+
+
+
+---
+title: Create an online table to link terms to resources
+description: What is this: This is how-we-did the processing of a video into an educational resource.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/create-terms-link-table/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/create-terms-link-table/index.md
+---
+
+# Create an online table to link terms to resources
+
+What is this: This is _how-we-did_ the processing of a video into an educational resource.
+
+For who: Anyone processing videos by hand.
+
+Result: an online table to jump into a video based on kerywords and terms.
+
+-   A resource (like footage, e.g. [Phil's IIW demo](https://youtu.be/GqjsRuu0V5A) interview with Steven)
+-   Subtitle (.sbv) file
+-   [Glossary](https://www.makeuseof.com/how-to-create-edit-youtube-subtitles/)
+-   Excel or open source alternative
+-   Excel function to transform Youtube time format to URL format
+-   Mark down table creation tool
+-   Mark Down Editor
+-   Version control (git, Github or Gitlab)
+
+A certain resource needs to be subtitled, explained further, etc. Be sure it has the added value you think it has. Ask around. Because there'll be a hugh effort involved to:
+
+-   transcribe the resource
+-   correct the subtitles by listening carefully what's been said by whom
+-   connect the resource to the glossary
+-   create new glossary items and amend existing ones (to avoid confusion when a term in a different context means something else)
+-   create an index of terms used in the resource into the video (timing) and into the glossary
+-   document the resource properly and take into production after testing.
+
+An hour of footage can take days to decipher and document. Again, be sure it's worth it.
+
+Upload the video to for example Youtube. Choose the right confidentiality and Youtube will start to create subtitles automatically. _Download_ the subtitle-file to your local machine once it's ready: a `.sbv` file. Mind the copy rights of your video platform.
+
+As you edit, also have a an Excel sheet open with a few columns:
+
+-   term
+-   text
+-   level
+-   link
+-   vidstart
+
+**Term**s are words used by the speakers in the resource, you can provide a **link** to more explanation, mainly to the [ACDC glossary](https://github.com/trustoverip/acdc/wiki/). The point in the video where a speaker _mentions the term for the first time_ is called **vidstart**, you can copy this data from from the .sbv subtitle file downloaded from Youtube. the **level** of understanding at which this term might need explanation, and finally a _brief explanation_ in field **text** of the term in the first column.
+
+There are lots of tips and tools on the web you can find to edit your Youtube subtitles / captions. Just to link a few:
+
+-   [https://www.makeuseof.com/how-to-create-edit-youtube-subtitles](https://www.makeuseof.com/how-to-create-edit-youtube-subtitles)
+-   [https://support.google.com/youtube/answer/2734705?hl=en](https://support.google.com/youtube/answer/2734705?hl=en)
+
+Since KERI and ACDC education start off at the level of SSI-expert, a _beginner_ is not a layman, but somebody with a good common understanding of IT and digital identity.
+
+-   1=beginner digital identity expert
+-   2=advanced self-sovereign identity expert
+-   3=SSI experts
+
+Do this simultaneously.
+
+Mind you `F2` is the cell that contains the time in Youtube time format: `0:00:00.000`
+
+-   Minutes: `=MID(TRIM(F2);3;2)` the example here has the Minutes in cell `G2`
+-   Seconds: `=MID(TRIM(F2);6;2)` the example here has the Seconds in cell `H2`
+
+And glue it together into a clickable and working URL to the right spot/timing in the footage:
+
+`=CONCATENATE("https://youtu.be/GqjsRuu0V5A?list=PLXVbQu7JH_LHVhs0rZ9Bb8ocyKlPljkaG&t=";G2;"m";H2;"s")`
+
+The start of example Excel sheet would like this:
+
+![](https://hackmd.io/_uploads/rkWsMskAc.png)
+
+The Excel file can be saved as a Comma Separated file `.csv`
+
+The .CSV-file, an example [here](https://github.com/WebOfTrustkeridoc/blob/main/resources/Terms-transcription-Phils-demo-IIIW.csv) that is the basis for a descriptive page, could be used to be imported elsewhere, to filter on the level field, and/or provide links or brief explanation to students.
+
+I've used [Tablesgenerator.com](https://www.tablesgenerator.com). Use the following settings:
+
+-   Markdown (menu - switch)
+-   Compact (toggle checkbox)
+
+![](https://hackmd.io/_uploads/HJ3zejyCq.png) ![](https://hackmd.io/_uploads/S19Llo1C9.png) ![](https://hackmd.io/_uploads/Hk93ki1Aq.png)
+
+And then copy the result; use the clipboard
+
+![](https://hackmd.io/_uploads/rkljgoyA9.png)
+
+and paste into your editor. After pasting the column headers in compact form will show
+
+![](https://hackmd.io/_uploads/BkwAmsJ09.png)
+
+remove the column you don't need, by not referencing them (the data is still in the column, redundantly). In this example I removed 3 columns:
+
+![](https://hackmd.io/_uploads/S1qt4sJ0q.png)
+
+I explain this to create three types: a HackMD file and a Github basic repo `.MD` page and pages created using a static site generator and/or Github Actions.
+
+Use the following CSS styling and adjust the column width at will (be sure it's "100%" in total):
+```
+
+
+
+\
+table a {
+    display: inline-block;
+    width: 50px;
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+  }
+
+  table th:first-of-type {
+      width: 20%;
+  }
+  table th:nth-of-type(2) {
+      width: 50%;
+  }
+  table th:nth-of-type(3) {
+      width: 10%;
+  }
+  table th:nth-of-type(4) {
+      width: 10%;
+  }
+  table th:nth-of-type(5) {
+      width: 10%;
+  }
+\
+```
+Use git functionality to push the HackMD file to your destination repo and or use a local repository to sync the `.md` file with your remote production repo.
+
+The `.md` file will show, however:
+
+To get to the links and other columns of the table you might need to scroll the table all the way to the right.
+
+The reason is that Github ignores all CSS input to normal repo .md files while rendering the output of `.MD` files in browsers. There are work-arounds but I don't advice those. Static pages generators can overcome this.
+
+You could also use the resulting Markdown file as input to a static site generator and or Github Actions to create more sophisticated version of the description file and / or glossary.
+
+Any source that uses the css to adjust the column and cell width (to shrink the size of the clickable links). Additionally this should be placed in a CSS file and referenced with the command above in comments:
+```
+
+```
+For example:
+
+![](https://hackmd.io/_uploads/HyYs35JC9.png)
+
+This is the HackMD result from the step by step above
+
+[kli-demo-2022](https://hackmd.io/pv11Cne-TiG4zhXUS-T6IA)
+
+And this the file on Github (notice the fact you need to scroll right through the table)
+
+[kli-demo-2022.md](https://github.com/WebOfTrustkeridoc/blob/main/resources/kli-demo-2022.md)
+
+
+
+
+---
+title: Create Omnigraffle infographic and convert to SVG
+description: Why this doc: to show how-we-did create SVG files to serve as infographics on the site
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/create-omnigraffle-infographic-and-convert-to-svg/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/create-omnigraffle-infographic-and-convert-to-svg/index.md
+---
+
+# Create Omnigraffle infographic and convert to SVG
+
+Why this doc: to show how-we-did create SVG files to serve as infographics on the site
+
+For who: anyone handy with clickable images and eager to contribute or update infographics
+
+Result: semi-automaticly (re)generated SVG files in the right spot.
+
+Three steps:
+
+1.  Use Omnigraffle app
+2.  Run `node maintenance/fixOmnigraffleSvgOutput.js` to fix the svg for our Docusaurus purposes. This script enhances the compatibility and display of OmniGraffle-produced SVGs.
+3.  Incoperate resulting svg in a Docusaurus page
+
+Commercial app available here: [https://www.omnigroup.com/download](https://www.omnigroup.com/download). We've used version 7.
+
+Sub steps
+
+1.  Create or adjust your drawing and links in the drawing
+
+2.  Export to svg in the right directory: `[root]/static/img` ![](https://weboftrust.github.io/keridoc/assets/images/hwd-export-297bf7dff5defb82b88eec607835d703.md) ![](https://weboftrust.github.io/keridoc/assets/images/hwd-svgexport-473e1ef66fbc03876310f8163d8e8642.md)
+
+3.  Set the background to transparent, tick the box in the Omnigraffle UI ![](https://weboftrust.github.io/keridoc/assets/images/hwd-inrightdir-7957f10160b5f3f77471f505cb4776a0.md)
+
+4.  Save or replace file ![](https://weboftrust.github.io/keridoc/assets/images/hwd-replace-14c649c65956bbb795f10a5e9f28a863.md)
+
+
+**Step 2 below expects the svg file to be in `/static/img` but must be run from the `[root]`**
+
+**In short, this script enhances the compatibility and display of OmniGraffle-produced SVGs.**
+
+Run `node maintenance/fixOmnigraffleSvgOutput.js` to fix the svg for our Docusaurus purposes. This script enhances the compatibility and display of OmniGraffle-produced SVGs.
+
+**Run this script from the `[root]` of your project, it expects your files to be in dir `[root]/static/img`**
+
+This Node.js script is for dealing with SVG files generated by OmniGraffle in a Docusaurus project. It tackles common OmniGraffle SVG inconsistencies, corrects namespaces and linking attributes, and adjusts SVGs for flexible, responsive use by removing fixed dimensions.
+
+The script also fixes relative URLs in anchor tags to ensure correct linking within the Docusaurus project and rearranges specific SVG elements for optimal rendering.
+
+This Node.js script is for OmniGraffle-generated SVGs. OmniGraffle, a diagramming and digital illustration application, often uses non-standard or deprecated attributes in its SVG output, which this script addresses to improve compatibility.
+
+The script defines replacements to rectify common OmniGraffle SVG output issues, including the removal of SVG DOCTYPE declaration and XML version tag, and correction of the 'xl:' namespace and 'xl:href' attributes to 'xmlns:xlink' and 'xlink:href' respectively.
+
+The script reads all files in the specified directory (../static/img), and for each '.svg' file, it performs the following:
+
+Applies the predefined replacement rules
+
+Checks for 'viewBox' attribute on the SVG element using the 'cheerio' library, and if found, removes the 'width' and 'height' attributes for responsive scaling
+
+For each anchor ('a') element, it corrects relative URLs and rearranges rectangle ('rect') elements within the anchor for optimal rendering
+
+Modified SVG data is then saved back to the file. Error handling is implemented at several stages to address potential issues during directory scanning, file reading, and writing.
+
+In essence, this script is a tool for preprocessing OmniGraffle-produced SVGs for better usability, compatibility, and display.
+
+In a markdown file that is in the build-able reach within the Docusaurus tree, e.g. under the `docs` directory, say for example `import Scraping from '/img/scraping.svg';`
+
+where `Scraping` is a React object that you have to call with `` so that DS can conjure up the image on the screen behind the scenes. and `scraping.svg` is the updated or newly produced svg in the above-described process.
+
+See detailed instructions here: [https://docusaurus.io/docs/markdown-features/assets#inline-svgs](https://docusaurus.io/docs/markdown-features/assets#inline-svgs)
+
+
+
+
+---
+title: Check and accept PR production KERISSE site locally
+description: Why this how-we-did: To test pull request offered before accepting them in github
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/check-and-accept-pr-production-edusite-locally/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/check-and-accept-pr-production-edusite-locally/index.md
+---
+
+# Check and accept PR production KERISSE site locally
+
+Why this _how-we-did_: To test pull request offered before accepting them in github
+
+For who: crew responsible for acceptance of PRs offered by content developers
+
+What is the objective: To check content and code that is uploaded to the team as a PR.
+```
+git stash
+git status
+git fetch upstream main
+git log
+```
+-   `fix-mdfiles` is the name of the PR.
+-   `testSC1` is the acronym of the developer that I use in this example.
+```
+git checkout -b testSC1
+git fetch upstream
+git merge upstream/fix-mdfiles
+```
+Now the changes that the PR proposes have been locally applied to the new branch
+```
+npm run build
+npm run serve
+```
+Now you can locally test the site at the address that look something like `http://localhost:3000keridoc/`. The result of `npm run serve` will tell you the exact URL.
+```
+git checkout main
+git merge testSC1
+```
+```
+git push -u upstream main
+```
+![](https://hackmd.io/_uploads/SkPSW_L6i.png)
+```
+git stash pop
+git branch -D testSC1
+```
+
+
+
+
+---
+title: Cheat sheet: writing a page inside /docs
+description: What is this: A few rules about headings, internal linking, images and more that we kept in mind. It's how we did it.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/cheat-sheet-writing-page/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/cheat-sheet-writing-page/index.md
+---
+
+# Cheat sheet: writing a page inside /docs
+
+What is this: A few rules about headings, internal linking, images and more that we kept in mind. It's _how we did_ it.
+
+For who: Anyone documenting in the KERI Suite and WOT-terms repo specifically.
+
+What problem does it solve: Everything that is important to do the right way, but you keep forgetting how to do it. Here's the cheat sheet to remind you and assist you.
+
+What's the result: The KERI Suite uses Docusaurus to generate enhanced technical documentation. Complying with the rules in this cheat sheet means optimal readability, less broken links, well-styled images, etc.
+
+> [!NOTE]
+> Use an editor that fixes markdown links when changing file names or moving files. We recommend _[Visual Studio Code](https://code.visualstudio.com)_.
+>
+> Change default setting in Visual Studio Code:
+>
+> -   Go to preferences
+> -   Type in search field: “markdown link update”
+> -   Set to “prompt” or “always”
+>
+> ([This video](https://www.youtube.com/watch?v=3hcN0yfOAzQ) explains.
+
+Use empty lines between every block:
+
+Right:
+```
+# Main title
+
+## Subtitle
+
+A paragraph text
+
+Another paragraph text
+```
+Wrong:
+```
+# Main title
+## Subtitle
+A paragraph text
+Another paragraph text
+```
+Start a page with a `#` followed by a space.
+
+(If you start with a `##` then Docusaurus will ad a `#` based on the file name. Not desirable.)
+
+Example:
+
+`# Main title`
+
+This will result in a `
` in the final html after the Markdown is parsed.
+
+Add structure to your document by adding `
`, in Markdown a `##` followed by a space.
+
+Example:
+```
+# Main title
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit.
+
+## Subtitle 1
+
+Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium
+
+## Subtitle 2
+
+Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit.
+```
+> [!NOTE]
+> -   Unlike a CMS like Wordpress, Docusaurus is file based. Renaming a file means that a link to this file no longer works if the file name is not also changed inside the link.
+>
+> -   After renaming a file or directory you will have to restart the localserver to take effect. Also it is recommended to use an incognito browser to avoid caching issues. (And even then it looks like sometimes it may take while before links start to work.)
+
+Internal linking is not easy in most content management systems. In Docusaurus it's difficult to keep all links working after renaming files. Here you will find best practise.
+
+General rules:
+
+-   use relative links
+-   use the `.md` extension at the end
+-   use the **file**name, not what you see in the browser address bar (numbers at the beginning of a file are used for ordering and removed in the url. You should use the file name with numbers in it)
+
+Let's take this file system:
+```
+├── concepts
+│   ├── concepts.md
+│   └── keri-dev-env.md
+├── education
+│   ├── intro.md
+```
+To create a link inside education/intro.md TO concepts/concepts.md write the following:
+```
+[Link to concepts](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/concepts/concepts.md)
+```
+If you do it this way, you can make Visual Studio Code [work for you](#strongly-recommended) and update the links if you move or rename files.
+
+There are more ways to create links, read about it on [https://docusaurus.io/docs/markdown-features/links](https://docusaurus.io/docs/markdown-features/links), but this is how we do it here.
+
+To create a link to an anchor in the same page:
+```
+[anchor link inside the same page](#foo)
+```
+```
+[Link to concepts](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/concepts/concepts.md#foo)
+```
+```
+[link text](https://www.example.com)
+```
+-   Use html syntax (not markdown)
+-   however, use `className` and not the normal `class`
+-   and use `require` for local images
+-   do not add html attributes like `width` or `height` and do not use `style='…'`
+-   always use an `alt` attribute. If the image is decorative leave it empty (`alt=""`), else write something as if you explain the image to someone on the phone
+
+You can copy these examples and use it (there is a copy button available at the right):
+```
+Foo
+```
+```
+Foo
+```
+```
+Foo
+```
+```
+Foo
+```
+You can insert images using Markdown but you cannot style these images using classes (CSS). So that is not very usable. That is why we use html syntax.
+
+Images are styled via CSS.
+
+The following classes are available for styling (there is a copy button available at the right):
+```
+inline-thumb-start
+```
+```
+inline-thumb-end
+```
+```
+inline-small-start
+```
+```
+inline-small-end
+```
+```
+inline-medium-start
+```
+```
+inline-medium-end
+```
+Start means “to the left” (in left-to-right languages).
+
+When no class is added the image will be 100% width.
+
+TBW
+
+More info: [https://docusaurus.io/docs/markdown-features/assets#images](https://docusaurus.io/docs/markdown-features/assets#images)
+
+Use
+
+-   [kebab-case](https://en.wikipedia.org/wiki/Naming_convention_\(programming\)#Delimiter-separated_words)
+-   all lower case (except… in the glossary, where you will find files like `ACDC.md` etc. These abbreviations need to be uppercase)
+
+This is how it is done in a default Docusaurus install.
+
+Examples:
+
+Directory: `tutorial-basics`
+
+File: `create-a-page.md`
+
+Combined: `tutorial-basics/create-a-page.md`
+
+No conventions (yet), except two:
+
+-   remove spaces and replace with dash, underscore or nothing.
+-   put all media files in `/static` (and not in an image dir somewhere in `/doc`).
+
+The sidebar menu is autogenerated and sorted alphanumerically.
+```
+├── concepts
+│   ├── concepts.md
+│   └── keri-dev-env.md
+├── education
+│   ├── intro.md
+```
+The directories “concepts” and “education” are called “categories” in Docusaurus. To give them a custom order, do as follows:
+```
+├── 02_concepts
+│   ├── concepts.md
+│   └── keri-dev-env.md
+├── 01_education
+│   ├── intro.md
+```
+As a bonus effect, the Visual Studio File Explorer will rearrange the directories, so will other systems like MacOS Finder etc. It is simple, effective (and intuitive for most people).
+
+The `01_` and `02_` are removed and not visible in the browser. Renumbering will change paths in internal links but Visual Studio Code will fix these paths for you if you [have configured it to do so](#strongly-recommended).
+
+Thank you for going all the way down the cheat sheet. Have a great time writing!
+
+
+
+
+---
+title: Load weboftrust glossary in weboftrust github page
+description: Why how-we-did this: We'ld like to have a straightforward editting tool that authenticates users that Create Update and/or Delete the content of the terms repo. With the use of git it will register all changes and done by whom, which facilitates curation and adds reputation.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/load-glossary-weboftrust-in-docusaurus/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/load-glossary-weboftrust-in-docusaurus/index.md
+---
+
+# Load weboftrust glossary in weboftrust github page
+
+Why _how-we-did_ this: We'ld like to have a straightforward editting tool that authenticates users that Create Update and/or Delete the content of the terms repo. With the use of `git` it will register all changes and done by whom, which facilitates curation and adds reputation.
+While the input is a rather basic operation in the wiki, we'ld like to enjoy all the extra's that a front-end technical dodumentation site can offer:
+
+-   levels of understanding
+-   categories
+-   pop-up
+-   formatting
+-   fold-puts
+-   etc And also add meta data to the terms definition using some kind of database table, which allows:
+-   filtering
+-   selection
+-   sorting
+-   checks
+
+For who: anyone who likes to see the results of wiki glossary input in the front-end `github.io` website KERISSE.
+
+Purpose: With regard to the glossary our weboftrust github page of the WOT-terms repo serves two clearly distinctive purposes:
+
+1.  conform to the ToIP and eSSIF-lab standards of generating glossaries
+2.  create our own version of the glossary where we add meta data, levels, catogeries and change the layout and UI to fit the Docusaurus KERISSE image.
+
+Result: Github actions script (2024: `content-fetch-and-deploy-update-glossary.yml`) transforms the source in the [wiki](https://github.com/weboftrustkeridoc/wiki) to a Docusaurus webpage structure called 'Glossary' in the left menu, thereby extracting meta data from a Google sheet into a JSON file and furthermore integrating this data on the front-end of the website.
+
+1.  The WebofTrust glossary (all the .md files pulled from [repo wiki](https://github.com/weboftrustkeridoc/wiki))
+2.  Terms WOT manage [Google Sheet](https://docs.google.com/spreadsheets/d/18IUa-1NSJ_8Tz_2D-VSuSQa_yf3ES1s_hovitm3Clvc/edit#gid=209150977)
+3.  Version control (git & Github)
+
+> [!NOTE]
+> Be sure to leave the following files in tact when overwriting glossary items in Docusaurus dir `nn-glossary` (`nn` will be any sequence number before "glossary to instruct the order") from the source WOT-terms wiki:
+>
+> -   **\_category\_.json**
+> -   **intro.md**
+>
+> These are vital for Docusaurus to offer links from various parts of the documentation straight to the glossary.
+
+Yes, the WebofTrust wiki glossary is the new home of our glossary. But we can sync with ToIP [acdc wiki](https://github.com/trustoverip/acdc/wiki) anytime. For example by offering PRs to the ToIP version or vice versa.
+
+We use local repo's or PR to sync Weboftrust `WOT-terms.wiki` and TrustoverIP `acdc.wiki`. Note that the wiki pages of a github repo are manifest in a seperate repo.
+
+The main reason is interoperability. We want to join in the effort to create cross-referencing concepts, terms and glossary resources at WebofTrust.
+
+From our WebofTrust view ToIP is our umbrella organisation that has similar objectives and principles. ToIP has good working relations with the European umbrella organisation eSSIF-lab too, who in 2023 can be considered as the global front runners of getting the terminology sorted out for Self-Sovereign Identity.
+
+**How our own repo [WebofTrust](https://github.com/WebOfTrust) came to be** In 2022 we reasoned:
+
+-   we would to have to build similar Github Actions tooling like [ToIP](https://wiki.trustoverip.org/display/HOME/Terms+Wikis) already has.
+-   we can't join the synchronization effort already taking place with [eSSIF-lab](https://essif-lab.github.io/framework)
+-   we would have to maintain these auxiliary which keeps us off okeridoc/ant work
+
+In 2023 we experienced:
+
+-   lagtime by ToIP and Linux Foundation internal github governance rules
+-   the knowledge and skills needed to "roll our own" had been acquired
+
+Mid 2023 we decided:
+
+-   to start using [Weboftrust wiki](https://github.com/WebOfTrustkeridoc/wiki)
+-   to sync at will with [ToIP wiki](https://github.com/trustoverip/acdc/wiki)
+
+For Github pages Docusaurus runs locally and remotely (Github Actions). **Be sure to**:
+
+1.  Have the same version of Docusaurus installed locally as Github currently uses remotely
+2.  study [this guide](https://docusaurus.io/docs/advanced/routing#file-paths-and-url-paths) to avoid frustration with paths.
+
+Because the glossary is maintained in Github wiki using Github userinterface here: [Weboftrust wiki](https://github.com/WebOfTrustkeridoc/wiki), the most recent version is a remote repo. We have to pull this wiki-repo (be sure to have the **wiki** repo not the "normal" WOT-terms repo!) to local to be able to create our own glossary and Docusaurus static site from this. The static site is then run as a github project page (branch _gh-pages_).
+
+This is performed by this section in the Github Actions script \[Deploy to GitHub Pages\](https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/load-glossary-weboftrust-in-docusaurus/WOT-terms/.github/workflows /deploy.md):
+```
+##############################
+      # Clones the wiki
+      ##############################
+
+      - name: Checkout wiki
+        run: |
+          git clone https://github.com/WebOfTrust/WOT-terms.wiki.git wiki
+
+      # Copies the wiki contents to the /docs/04_glossary/ directory
+      - name: Copy Wiki To Docusaurus Glossary directory
+        run: |
+          mkdir -p docs/04_glossary  # Create the directory if it doesn't exist
+
+          # Files that are already in the /docs/04_glossary/ directory will not be overwritten
+          rsync -a wiki/ docs/04_glossary/  # Synchronize wiki contents to /docs/04_glossary/
+          keridoc/
+          # The /wiki directory is not needed anymore
+          rm -rf wiki/  # Remove the /wiki directory
+      ##############################
+```
+Because the glossary is maintained in Github wiki using Github userinterface here: [Weboftrust wiki](https://github.com/WebOfTrustkeridoc/wiki), the most recent version is a remote repo. We used to pull this wiki-repo (and had to be sure to have the **wiki** repo not the "normal" WOT-terms repo!) to local to be able to create our own glossary and Docusaurus static site from this. All done by hand.
+```
+git clone https://github.com/weboftrust/WOT-terms.wiki.git
+cd WOT-terms.wiki
+git remote get-url origin
+ls
+```
+![wiki-repo-ls-result](https://weboftrust.github.io/keridoc/assets/images/wiki-repo-ls-68875431943122e705931e7a87d6d708.md)
+```
+git pull origin master
+```
+To able to generate a tailor made explanation site we use two inputs (see full list of inputs [here](#input)):
+
+1.  The WebofTrust glossary locally (all the .md files pulled from [Weboftrust wiki](https://github.com/WebOfTrustkeridoc/wiki)
+2.  Terms WOT manage (xls or csv) table, currently maintained in Google Sheets (mid 2023)
+
+Step into the Docusaurus dir structure to `WOT-terms/docs/glossary` and execute the command `cp ../../../WOT-terms.wiki/* .` to finish what we'd like to achieve: Copy the glossary resources into the Docusaurus file structure.
+```
+##############################
+      # Google sheet: WOT-terms, tab: Terms-WOT-manage
+      ##############################
+
+      # Fetches data from WOT-terms (Google sheet) and generates an overview file that takes all the terms and their definitions and puts them into a single file.
+      - name: Import Google Sheet “WOT-terms”, tab “Terms-WOT-manage” data into markdown file
+        run: node fetchExternalContent/fetchTermsWOTmanage/fetchTermsWOTmanage.js
+      ##############################
+```
+Inner working:
+
+-   it reads the input file (2.) per line.
+-   each row describes a term and its resource file
+-   we create a proper file name
+-   we try to match the terms in the ToIP glossary resources and bind them
+
+Docusaurus takes care of
+
+-   writing `.md` files with Front matter code and includes
+
+Columns
+
+-   key
+-   (WWWWW-key) multiple foreign keys
+-   term
+-   text
+-   level
+-   link
+-   (Cat-CCCC) multiple categories
+
+Explanation
+
+-   **key** needs to be unique and once established it should not change.
+-   **Term**s are words used in the resource,
+-   you can provide a **link** to more explanation, mainly to the [WOT glossary](https://github.com/weboftrustkeridoc/wiki/).
+-   Then the **level** of understanding at which this term might need explanation, and finally
+-   a _brief explanation_ in field **text** of the term in the first column.
+
+> As of mid 2023 temporarily disabled
+
+Since KERI Suite education starts off at the level of SSI-expert, a _beginner_ is not a layman, but somebody with a good common understanding of IT and digital identity.
+
+-   1=general digital identity expert
+-   2=advanced self-sovereign identity expert
+-   3=autonomic identifier & KERI experts
+
+Push the locally updated files to the remote WebofTrust repo:
+```
+git status
+git add .
+git commit -m "update the WebofTrust glossary"
+git push  gh-pages
+```
+The push will activate Github Actions and the resources will be input to a static site generator.
+
+This is the Github pages result from the step by step above:
+
+[glossary](https://weboftrust.github.io/keridoc/docs/how-we-did/category/glossary.md)
+
+
+
+
+---
+title: Fill out terms in the WebofTrust wiki
+description: What is this
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/fill-out-terms-toip-wiki/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/fill-out-terms-toip-wiki/index.md
+---
+
+# Fill out terms in the WebofTrust wiki
+
+What is this: This page tells a little bit about how to use the WebofTrust terms wiki:
+
+-   how to use
+-   how to fill
+-   how to manage
+
+For who: content creators wrtiting term definition or updating them.
+
+Result: terms definition in the source environment Wiki that will process automatically into glossaries on github.io, using github action scripts.
+
+But first a big **Thank You** to ToIP and Daniel Hardman, where we got the source code from and we sync our glossary with.
+
+The [README](https://github.com/weboftrustkeridoc/wiki/README) has to most recent rules to stick to.
+
+For new learners, the video | TBW prio1 | of Daniel Hardman is very educational.
+
+You could also have a look at the elaborate and comprehensive description of the ToIP terms wikis [here](https://github.com/trustoverip/toip)
+
+Go to any of them, for example to the [acdc](https://github.com/weboftrustkeridoc/wiki) wiki of the KERI team. It's the KERI Suite terms there, so all about KERI, ACDC, CESR, OOBI, KERIA, IPEX, etc. keridoc/
+
+1.  **Find a page**: To find a term just type part of it and the available list will be filtered instantly
+
+![How to find a term in the terms wiki](https://weboftrust.github.io/keridoc/assets/images/find-a-page-7fbc71998ad31410b7760111e06c2aa0.md)
+
+> this is a very handy feature when attending virtual meeting and the experts are throwing in various terms. you could save the newcomers by throwing links in the chat to the matching terms in the wiki.
+
+![How to filter terms in the terms wiki](https://weboftrust.github.io/keridoc/assets/images/filter-pages-8fe05aea2b49254f7c841690645cdcc0.md)
+
+"So we decided that it was simpler to handle acronyms a different way. Whenever you have a term with an associated acronym, just create two wiki pages. One should document the full, spelled out version of the term, including its definition and any other interesting metadata. The other should NOT contain a `## Definition` block but rather a `## See` block that contains a cross reference. You can see this pattern in the TOIP glossary entries for SSI and self-sovereign identity: [https://trustoverip.github.io/toip/glossary#ssi](https://trustoverip.github.io/toip/glossary#ssi)" (Source: Daniel Hardman)
+
+1.  all lower case words with spaces. These will be converted to dashed terms
+
+2.  Only for those entries complying to 1.
+
+```
+## Definition
+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'.
+```
+![How to create a new term in the terms wiki](https://weboftrust.github.io/keridoc/assets/images/new-term-wiki-page-505ef75acd3f75601f04f3e58c9c5f1d.md)
+
+3.  Abbreviations
+
+Example `CESR`:
+```
+## See
+[composable event streaming representation](https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/fill-out-terms-toip-wiki/composable-event-streaming-representation.md)
+```
+The resulting markdown file will be saved and accessible as CESR.md
+
+Originally, the instruction was to create a term and is acronym the way you have done -- a single page in the wiki, where the page tile is "term with many words (acronym)". The term tool generates entries for both.
+
+However, it turns out that generating two entries from one wiki page creates some undesirable complications. The tool needs to generate two tag lists and two edit histories as well. References to the term have an ID that is the same for both the short and the long form, and which authors may not remember. (You're writing a doc and you want to link to "SSI" but you have to remember to link to "self sovereign identity (SSI)" instead.) Etc.
+(Source: Daniel Hardman)
+
+
+
+
+---
+title: Embed a Github-hosted image in a Github wiki page
+description: For who: content developers and those who'd like to repair broken images
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/embed-github-hosted-image-in-github-wiki-page/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/embed-github-hosted-image-in-github-wiki-page/index.md
+---
+
+# Embed a Github-hosted image in a Github wiki page
+
+For who: content developers and those who'd like to repair broken images
+
+Why: repair and avoid broken images
+
+Result: github-hosted images with a valid link
+
+The URL of an image hosted on Github is not what it seems.
+
+> **Example**
+> The link the image was broken here: [https://trustoverip.github.io/acdc/glossary#prefix](https://trustoverip.github.io/acdc/glossary#prefix), it did not show an image. However, copying the image link results in "[https://github.com/WebOfTrust/keri/blob/main/images/prefix.png](https://github.com/WebOfTrust/keri/blob/main/images/prefix.png)", and if you paste this link, you do get an image!
+
+What's going on here? And why is this relevant?
+
+We are better off knowing what the difference between 'raw' and 'generated' in Github means, so we can move faster and more be efficient. Read on.
+
+When you check an image into Github, and then browse to the image's path in the repo, github doesn't display the raw picture.
+
+Rather, it displays **a generated html page** that includes a bunch of Github framing so you can see the repo, the version history, etc.
+
+> **Example continued**
+> If you look at the wiki page for the glossary entry in question: [https://github.com/trustoverip/acdc/wiki//prefix](https://github.com/trustoverip/acdc/wiki//prefix), you will see that the URL of the image is [https://github.com/WebOfTrust/keri/blob/main/images/prefix.png](https://github.com/WebOfTrust/keri/blob/main/images/prefix.png).
+
+Even though that URL ends with "png", what it returns is not a raw PNG, but an actual web page.
+
+To embed an image properly in a github wiki page (whether the wiki page is a terms wiki or not), **you need to get the URL for the raw image file**. You can get this done by
+
+THREE different ways!
+
+A.
+
+1.  clicking the button that says "Download" and
+2.  right-clicking the image and choose "Copy Image Address"
+
+> Example result: `https://raw.githubusercontent.com/WebOfTrust/keri/main/images/prefix.png`
+
+OR
+
+B.
+
+1.  right-clicking on the button that says "Download" and
+2.  choosing "Copy Link"
+
+> Example result: `https://github.com/WebOfTrust/keri/raw/main/images/prefix.png`
+
+Either way will work. Here's the proof :), that I've deleted already:
+
+![](https://hackmd.io/_uploads/B1l9wwX-09.png)
+
+C. Just add `?raw=true` to the URL
+
+> example result: [https://github.com/WebOfTrust/keri/blob/main/images/prefix.png?raw=true](https://github.com/WebOfTrust/keri/blob/main/images/prefix.png?raw=true)
+
+Either way will work. And here is the proof, that I've already deleted of course from the production environment:
+
+![](https://hackmd.io/_uploads/S15bh7Z09.png)
+
+I think this will fix your broken image links and resolve the issue mentioned above.
+
+
+
+
+---
+title: Edit glossary metadata
+description: The glossary metadata are currently hosted in Google Sheets.
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/edit-metadata/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/edit-metadata/index.md
+---
+
+# Edit glossary metadata
+
+The glossary metadata are currently hosted in Google Sheets.
+
+The data are imported and rendered on [overview/overview-and-context](https://weboftrust.github.io/keridoc/docs/overview/overview-and-context.md)
+
+Every cell has an edit and cancel button. Changes are currently not written to the google sheet, but are stored on an external server.
+
+There is currently basic authentication: you need a Github token. If you try to save the edits in a cell this token will be requested.
+
+
+
+
+---
+title: Redirects
+description: These are the redirects that can be used:
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/general/redirects/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/general/redirects/index.md
+---
+
+# Redirects
+
+These are the redirects that can be used:
+
+-   kerisse.org ==> [https://weboftrust.github.io/kerisse/](https://weboftrust.github.io/kerisse/)
+-   glossary.kerisse.org ==> [https://weboftrust.github.io/WOT-terms/](https://weboftrust.github.io/WOT-terms/)
+-   search.kerisse.org ==> [https://weboftrust.github.io/kerisse/](https://weboftrust.github.io/kerisse/)
+-   doc.kerisse.org ==> [https://weboftrust.github.io/keridoc/](https://weboftrust.github.io/keridoc/)
+
+These are configured in the Digistate Admin Panel.
+
+Every redirect is created from an entry in the Domain Administrator. So `glossary.kerisse.org` etc are registered as a _Domain_.
+
+Next step is to register a redirect in that domain.
+
+
+
+
+---
+title: Install this repo
+description: Result: | @kordwarshuis TBW |
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/how-we-did/general/install-project-kerisse/index
+  md: https://weboftrust.github.io/keridoc/docs/how-we-did/general/install-project-kerisse/index.md
+---
+
+# Install this repo
+
+Result: | @kordwarshuis TBW |
+
+What is this: [Github README](https://github.com/weboftrustkeridoc/README) describes the download, install, configuration and launch of this project.
+
+For who: site maintainer
+
+-   Clone this repository
+-   Run `npm install`
+-   Install four extra libraries manually (for the scrapers functionality):
+    -   `jq` ([https://stedolan.github.io/jq/](https://stedolan.github.io/jq/))
+    -   `curl` ([https://curl.se/](https://curl.se/))
+    -   `ImageMagick` ([https://imagemagick.org](https://imagemagick.org))
+    -   `sitemap-generator-cli` ([https://github.com/lgraubner/sitemap-generator-cli](https://github.com/lgraubner/sitemap-generator-cli))
+
+To install `jq`, `curl`, `ImageMagick`, use a package manager e.g., apt, yum, brew, etc.
+
+To install `sitemap-generator-cli` look here: [https://github.com/lgraubner/sitemap-generator-cli?tab=readme-ov-file#install](https://github.com/lgraubner/sitemap-generator-cli?tab=readme-ov-file#install)
+
+Now you can refresh the **search index** if needed: `$ sh search-index-typesense/main.sh`
+
+This takes about half an hour.
+
+Instructions on how to use createSitemap.js: [https://github.com/WebOfTrustkeridoc/blob/main/search-index-typesense/createSitemap.mjs](https://github.com/WebOfTrustkeridoc/blob/main/search-index-typesense/createSitemap.mjs)
+
+
+
+
+---
+title: Verify a credential
+description: Lorem ipsum
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/verify-a-credential/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/verify-a-credential/index.md
+---
+
+# Verify a credential
+
+Lorem ipsum
+
+
+
+
+---
+title: Set up a basic KERI network
+description: Lorem ipsum
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/set-up-basic-keri-network/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/set-up-basic-keri-network/index.md
+---
+
+# Set up a basic KERI network
+
+Lorem ipsum
+
+
+
+
+---
+title: Present a credential
+description: Lorem ipsum
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/present-a-credential/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/present-a-credential/index.md
+---
+
+# Present a credential
+
+Lorem ipsum
+
+
+
+
+---
+title: Make a schema
+description: Lorem ipsum
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/make-a-schema/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/make-a-schema/index.md
+---
+
+# Make a schema
+
+Lorem ipsum
+
+
+
+
+---
+title: Issue a credential
+description: Lorem ipsum
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/issue-a-credential/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/issue-a-credential/index.md
+---
+
+# Issue a credential
+
+Lorem ipsum
+
+
+
+
+---
+title: Intro
+description: Lorem ipsum
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/intro/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/intro/index.md
+---
+
+# Intro
+
+Lorem ipsum
+
+
+
+
+---
+title: Current open issues
+description: Lorem ipsum
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/current-open-issues/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/current-open-issues/index.md
+---
+
+# Current open issues
+
+Lorem ipsum
+
+
+
+
+---
+title: Create a basic ACDC graph
+description: Lorem ipsum
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/create-a-basic-acdc-graph/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/create-a-basic-acdc-graph/index.md
+---
+
+# Create a basic ACDC graph
+
+Lorem ipsum
+
+
+
+
+---
+title: Contributors' Guide
+description: Introduction
+source_url:
+  html: https://weboftrust.github.io/keridoc/docs/concepts/how-to/contribute-to-weboftrust-github/index
+  md: https://weboftrust.github.io/keridoc/docs/concepts/how-to/contribute-to-weboftrust-github/index.md
+---
+
+# Contributors' Guide
+
+Welcome to kerisse's contribution guide! This project aims to develop documentation and educational resources surrounding the KERI standards, protocols, and tools developed in WebOfTrust on github. We deeply appreciate the time and effort of contributors like you!
+
+This project has a split license whose details are contained [here](https://github.com/WebOfTrust/ietf-keri/blob/main/LICENSE.md)
+
+Before you start, make sure you:
+
+-   Are somewhat familiar with the [KERI, ACDC, CESR standards and the KERI whitepapers](https://github.com/WebOfTrust/keri). Jargon isn't always the best, but it does speed communication with maintainers whose time is often in short supply and appreciate clarity in all things. The purpose of kerisse is really to make these digestable in small pieces to an audience that doesn't have time to pore over all those papers so any contributer should make sure that they've at least developed a passing references with the things contained in these papers.
+
+The KERISSE (like the KERI) community welcomes [all kinds of contributions](https://opensource.guide/how-to-contribute/).
+
+For simple contributions like fixing typos sometimes you can just submit a naked PR with a title like "I'm fixing a spelling issue in x,y,z". If these PRs are small often times they'll just get merged without further review. Typos or grammatical errors are human nature and probably don't require a great deal of process to fix.
+
+A really simple way to contribute is just to use KERISSE and spread the word. When people need educational resources, have questions about particular terms, or KERISSE has the information related to their query, linking the resource can often times be a great way to advertise that the project exists and is useful so they can help themselves in the future. Let people know about KERISSE and create a welcoming community by actively participating and helping with what you know, and educating and contributing resources to KERISSE and talking about them is helpful to grow.
+
+Issues and discussions are meant to be discussed and commented upon. Even a +1 to an issue that you're also experiencing can help the core maintainers decide where to focus their energies. Discussions can help provide clarity if things aren't exactly clear. Feel free to contribute (but also note the homework in [PREREQUISITES](#prerequisites), its frustrating for people to explain things that are already explained elsewhere).
+
+However, this particular file is more about contributing resources to KERISSE. The general principal in this (and all open source really) is if you can think of a way that things might be better, instead of just suggesting it or discussing it, often times its a good idea to do some work to show what/how/when an idea might look like or contributing resources. Educational Material >> discussion 9 times out of ten. Balanced of course with the caveat not to go off into the ivory tower for months and do lots of work before presenting your work and finding out that the community doesn't like it. Small examples, howtos, tutuorials, or snippets are often best. From there we can build up to more extensive efforts. The rest of the details of contributing resources are below.
+
+There are no hard and fast guidelines but it is helpful to:
+
+-   Descriptive, to the point messages are ideal
+-   Link to the issue you're trying to solve with a message of how the commit does or doesn't solve that issue.
+-   Be sure to note important issues for checkpoint commits like "does not build"
+-   Most importantly, the commit message should explain the WHY of all the code changes. When reviewing, reviewers will be confused if code changes for things you didn't list in the commit aren't there.
+
+Branch from development, name your branches descriptively, something like `howto-keri-witness-instantiation` or `tutorial-keri-ssh`. If you're fixing an issue with previously created material or changing something about kerisse that already exists, be sure to file an issue on github to discuss with maintainers your particular issue or issue you're trying to fix. Name the branch and indicate in your PR what issue you're trying to solve. When you have created or fixed and the work is ready for review, submit a PR to WebOfTrust/kerisse. If you need feedback it can also be appropriate to submit a **draft** PR to this repository and ask for comments.
+
+1.  Find and issue and let the maintainers on discord (in the #kerisse channnel) know you're working on it (and maybe comment on the issue to let people know you're picking it up) or what you'd like to create.
+2.  Create/fix
+3.  Submit a PR to \[WebOfTrust/kerisse\]
+4.  Let maintainers know on discord in the appropriate channel
+5.  Come to Thursday KERI development meeting to discuss if at all possible (sometimes its easier for maintainers to provide feedback directly rather than through async text, particularly if its a large or complex change).
+6.  Iterate 2-6 if your change needs some fixes/updates
+
+-   **SEARCH FOR THE BUG OR FEATURE IN THE CURRENT ISSUES IN REPO**. If it already exists, add a comment/script/test/+1/whatever there. Duplicates BAD.
+-   If the bug/feature doesn't exist create an issue wherein you describe the bug, feature, or issue with as much detail as possible (but maybe not enough that you overload the reader with details).
+-   Code snippets, scripts, or test cases should be added to the issue if possible.
+-   Message in the appropriate discord channel to let people know about your bug/feature/issue, but remember that maintainers maintain at their own pace and discretion on issues of their choosing. Its best not to ping them more than once a week. As with all open source, if its an ultra critical bug/feature for you, cash bounties certainly incentivize people to pay attention and offer to help you directly.
+
+[From the discord channel](https://discord.com/channels/1148629222647148624/1148686277269532703/1148686279945498624)
+
+We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
+
+Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all.
+
+Please be kind and courteous. There’s no need to be mean or rude.
+
+Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
+
+Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.
+
+We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior. We interpret the term “harassment” as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don’t tolerate behavior that excludes people in socially marginalized groups.
+
+Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel admins immediately. Whether you’re a regular contributor or a newcomer, we care about making this community a safe place for you and we’ve got your back.
+
+Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome. Attribution Adapted from the Rust Code of Conduct: [https://www.rust-lang.org/policies/code-of-conduct](https://www.rust-lang.org/policies/code-of-conduct)
+
+For questions or clarifications, reach out via:
+
+-   Discord: [https://discord.gg/edGDD632tP](https://discord.gg/edGDD632tP)
+-   KERI Development Meetings: \[[https://github.com/WebOfTrust/keri#implementors-call](https://github.com/WebOfTrust/keri#implementors-call)\]
+-   ACDC Standards Meeting@TOIP (technically must be a member of ToIP to contribute): \[[https://github.com/WebOfTrust/keri#specification-call](https://github.com/WebOfTrust/keri#specification-call)\]
+
+Thanks to all our wonderful contributors.
+
+-   [Related Projects](https://github.com/WebOfTrust)
+
+
diff --git a/llm-docs/llms.txt b/llm-docs/llms.txt
new file mode 100644
index 00000000..716f914a
--- /dev/null
+++ b/llm-docs/llms.txt
@@ -0,0 +1,179 @@
+# KERIDoc Documentation
+
+KERI Suite Documentation
+
+> [!TIP]
+> A complete archive of all documentation in Markdown format is available at https://weboftrust.github.io/keridoc/markdown.zip
+
+## Documentation
+
+- [KERIDoc](https://weboftrust.github.io/keridoc/index.md): KERI Suite Documentation
+- [Visualisations](https://weboftrust.github.io/keridoc/visualisations/index.md)
+- [Markdown page example](https://weboftrust.github.io/keridoc/markdown-page/index.md): You don't need React to write simple standalone pages.
+- [Menu](https://weboftrust.github.io/keridoc/howtos-menu/index.md): How-to pages.
+- [Feedback](https://weboftrust.github.io/keridoc/feedback/index.md): We appreciate your feedback.
+- [Document Information](https://weboftrust.github.io/keridoc/ToIP-IR/ToIPIssuerRequirements.docx.md)
+- [Source: modules-js-universal/toLowerCaseAndRemoveSpecialChars.js](https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_toLowerCaseAndRemoveSpecialChars.js.md)
+- [Source: modules-js-universal/positionInArray.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-universal_positionInArray.mjs.md)
+- [Source: modules-js-node/unzipFile.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_unzipFile.mjs.md)
+- [Source: modules-js-node/glossaryJsonToMarkdown.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_glossaryJsonToMarkdown.mjs.md)
+- [Source: modules-js-node/downloadFile.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_downloadFile.mjs.md)
+- [Source: modules-js-node/createSpecUpJsonFile.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_createSpecUpJsonFile.mjs.md)
+- [Source: modules-js-node/cleanJson.mjs](https://weboftrust.github.io/keridoc/JSDoc/modules-js-node_cleanJson.mjs.md)
+- [Module: unzipFile](https://weboftrust.github.io/keridoc/JSDoc/module-unzipFile.md)
+- [Module: toLowerCaseAndRemoveSpecialChars](https://weboftrust.github.io/keridoc/JSDoc/module-toLowerCaseAndRemoveSpecialChars.md)
+- [Module: positionInArray](https://weboftrust.github.io/keridoc/JSDoc/module-positionInArray.md)
+- [Module: downloadFile](https://weboftrust.github.io/keridoc/JSDoc/module-downloadFile.md)
+- [Module: cleanJsonFile](https://weboftrust.github.io/keridoc/JSDoc/module-cleanJsonFile.md)
+- [Source: maintenance/fix_INDEX_OVERVIEW_FILE.js](https://weboftrust.github.io/keridoc/JSDoc/maintenance_fix_INDEX_OVERVIEW_FILE.js.md)
+- [Source: maintenance/fixOmnigraffleSvgOutput.js](https://weboftrust.github.io/keridoc/JSDoc/maintenance_fixOmnigraffleSvgOutput.js.md)
+- [Source: maintenance/fixDashInWikiCopyFilenames.js](https://weboftrust.github.io/keridoc/JSDoc/maintenance_fixDashInWikiCopyFilenames.js.md)
+- [Source: maintenance/findBrokenLinks.js](https://weboftrust.github.io/keridoc/JSDoc/maintenance_findBrokenLinks.js.md)
+- [Source: maintenance/XMLsitemapEditor.js](https://weboftrust.github.io/keridoc/JSDoc/maintenance_XMLsitemapEditor.js.md)
+- [Home](https://weboftrust.github.io/keridoc/JSDoc/index.md)
+- [Global](https://weboftrust.github.io/keridoc/JSDoc/global.md)
+- [Source: clientModules/writeChanges.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_writeChanges.js.md)
+- [Source: clientModules/upvoteSearchResult.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_upvoteSearchResult.js.md)
+- [Source: clientModules/typesenseInstantSearchInit.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseInstantSearchInit.js.md)
+- [Source: clientModules/typesenseInstantSearch.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseInstantSearch.js.md)
+- [Source: clientModules/typesenseHandleSearchModal.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_typesenseHandleSearchModal.js.md)
+- [Source: clientModules/showLevels.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_showLevels.js.md)
+- [Source: clientModules/showGPTsummary.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_showGPTsummary.js.md)
+- [Source: clientModules/showDefinitionsPopUpOnClick.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_showDefinitionsPopUpOnClick.js.md)
+- [Source: clientModules/scrollHorizontallyToKeyWordInSearchResults.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_scrollHorizontallyToKeyWordInSearchResults.js.md)
+- [Source: clientModules/insertVideo.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_insertVideo.js.md)
+- [Source: clientModules/insertSubtitles.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_insertSubtitles.js.md)
+- [Source: clientModules/imageFullSize.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_imageFullSize.js.md)
+- [Source: clientModules/horizontalScrollHint.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_horizontalScrollHint.js.md)
+- [Source: clientModules/findMentalModelMatches.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_findMentalModelMatches.js.md)
+- [Source: clientModules/fetchFormsColumnFromWotTerms.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_fetchFormsColumnFromWotTerms.js.md)
+- [Source: clientModules/fetchCommitHash.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_fetchCommitHash.js.md)
+- [Source: clientModules/elementGoFullScreen.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_elementGoFullScreen.js.md)
+- [Source: clientModules/dynamicTables.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_dynamicTables.js.md)
+- [Source: clientModules/crossLinks.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_crossLinks.js.md)
+- [Source: clientModules/createLinkToWikiPage.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_createLinkToWikiPage.js.md)
+- [Source: clientModules/addUiToSidebar.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_addUiToSidebar.js.md)
+- [Source: clientModules/addDataTypes.js](https://weboftrust.github.io/keridoc/JSDoc/clientModules_addDataTypes.js.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/vlei.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/signify.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/signify-dev.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/random.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/licencing.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/keripy.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/keriml.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/keri-swift.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/keri-rs.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/keri-dev.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/keri-cesr-licensing.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/introductions.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/index.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/iiw-nov-2022.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/governance.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/general.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/edu.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/did-keri.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/did-keri-dev.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/cesr.md)
+- [Slack Archive](https://weboftrust.github.io/keridoc/slack/html/cesr-dev.md)
+- [1     
+KERI Specifications](https://weboftrust.github.io/keridoc/html/GLEIF/2022-12-06_id_l-id_b-Ecosystem-Governance-Framework-Technical-Requirements-Part1-KERI-Infrastructure-Prep-1.0-Publication_v0.6_work.md)
+- [1     
+Related Specifications](https://weboftrust.github.io/keridoc/html/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      
+Introduction](https://weboftrust.github.io/keridoc/html/GLEIF/2022-11-30_Legal-Entity-QVI-AUTH-vLEI-Credential-GF-Prep-1.0-Publication_v0.6_work.md)
+- [Tags](https://weboftrust.github.io/keridoc/docs/tags/index.md)
+- [KERI Suite Glossary in ToIP style](https://weboftrust.github.io/keridoc/docs/glossary-toip-style/index.md)
+- [Dictionary SSI](https://weboftrust.github.io/keridoc/docs/dictionary/index.md)
+- [Various visualisations from Slack discussions](https://weboftrust.github.io/keridoc/docs/visualisations/various-visualisations-from-slack/index.md): 1
+- [Animated visualisation of repo connections](https://weboftrust.github.io/keridoc/docs/visualisations/repo-connections/index.md): See visualisation
+- [KERIA Service Architecture](https://weboftrust.github.io/keridoc/docs/visualisations/keria-service-architecture/index.md): ;
+- [KERI & ACDC Architecture](https://weboftrust.github.io/keridoc/docs/visualisations/keri-and-acdc-architecture/index.md): Flow charts created by Kent Bull.
+- [Backed and Backerless Issuance and Revocation](https://weboftrust.github.io/keridoc/docs/visualisations/backed-and-backerless-issuance-and-revocation/index.md): Flow charts created by Jason Colburne.
+- [Let's KERI on together](https://weboftrust.github.io/keridoc/docs/video/lets-keri-on-together/index.md): The video
+- [2024-03-24 KERI dev call](https://weboftrust.github.io/keridoc/docs/video/2024-03-24-KERI-dev-call/index.md): Why Zoom to KERISSE?
+- [One doc tagged with "KERI"](https://weboftrust.github.io/keridoc/docs/tags/keri/index.md)
+- [One doc tagged with "ACDC"](https://weboftrust.github.io/keridoc/docs/tags/acdc/index.md)
+- [keri.one-labeled](https://weboftrust.github.io/keridoc/docs/resources/keri.one-labeled/index.md): Primary Resources
+- [Delving into the WOT Knowledge Repository](https://weboftrust.github.io/keridoc/docs/resources/intro/index.md): Welcome to our comprehensive knowledge base – a dynamic compendium of whitepapers, slide presenta...
+- [All images found](https://weboftrust.github.io/keridoc/docs/resources/all-images/index.md): Total unique images found: 152
+- [overview-and-context](https://weboftrust.github.io/keridoc/docs/overview/overview-and-context/index.md): Overview and context
+- [Indexed in KERISSE](https://weboftrust.github.io/keridoc/docs/overview/indexed-in-KERISSE/index.md): Indexed at 02 April 2024 1740
+- [KERIDoc](https://weboftrust.github.io/keridoc/docs/intro/intro/index.md): We aim to document everything related to KERI, ACDC and CESR and alike. To let autonomic identifi...
+- [Intro](https://weboftrust.github.io/keridoc/docs/how-we-did/intro/index.md): This is a source directory that explains how this site came to be and how it can be maintained.
+- [External W3C DID Glossary](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-w3cdid/index.md)
+- [External ToIP did:webs Glossary](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-toipdidweb/index.md): w
+- [External ToIP Glossary](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-toip/index.md)
+- [External Nist Glossary](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-nist/index.md)
+- [External eSSIF-Lab Glossary](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-essiflab/index.md)
+- [External Digital Govt NZ Glossary](https://weboftrust.github.io/keridoc/docs/glossaries-external/glossary-digital.govt.nz/index.md)
+- [vLei issues](https://weboftrust.github.io/keridoc/docs/github-latest-activity/vLei/index.md): Real-time info.
+- [Signify-ts issues](https://weboftrust.github.io/keridoc/docs/github-latest-activity/signify-ts/index.md): Real-time info.
+- [KERIPY issues](https://weboftrust.github.io/keridoc/docs/github-latest-activity/keripy/index.md): Real-time info.
+- [KERIA issues](https://weboftrust.github.io/keridoc/docs/github-latest-activity/keria/index.md): Real-time info.
+- [KERI issues](https://weboftrust.github.io/keridoc/docs/github-latest-activity/keri/index.md): Real-time info.
+- [Cesride issues](https://weboftrust.github.io/keridoc/docs/github-latest-activity/cesride/index.md): Real-time info.
+- [Tutorials](https://weboftrust.github.io/keridoc/docs/education/tutorials/index.md): Search through tutorials
+- [Q&A about KERI's Security model and Guarantees](https://weboftrust.github.io/keridoc/docs/education/q-and-a-security/index.md): This document is part two of Q-and-A. Both files shares a common Glossary, KERI specific and more...
+- [Q&A about KERI](https://weboftrust.github.io/keridoc/docs/education/q-and-a/index.md): This document is part one. Part two is Q-and-A Security. Both files shares a common Glossary that...
+- [KERI MOOC](https://weboftrust.github.io/keridoc/docs/education/keri-mooc/index.md): Goal is to facilitate self-education culminating in KERI knowlegde. Level: starters, novices, beg...
+- [WOT Education](https://weboftrust.github.io/keridoc/docs/education/intro/index.md): This is a source directory that contains Q&As and other educational resources
+- [Roadmap to know what's coming](https://weboftrust.github.io/keridoc/docs/concepts/roadmap/index.md): People want to know when new code will be ready, who will produce it, where it'll be and how they...
+- [Mindmap](https://weboftrust.github.io/keridoc/docs/concepts/mindmap/index.md): hackmd-github-sync-badge
+- [Insights into the KERI Development Toolbox](https://weboftrust.github.io/keridoc/docs/concepts/keri-dev-env/index.md): Discover the whys and hows of the development tools that power the KERI system.
+- [WOT Concepts](https://weboftrust.github.io/keridoc/docs/concepts/intro/index.md): All the historical and actual concepts behind KERI and its off-springs
+- [Concepts](https://weboftrust.github.io/keridoc/docs/concepts/concepts/index.md): hackmd-github-sync-badge
+- [Visualisations](https://weboftrust.github.io/keridoc/docs/category/visualisations/index.md): Visualisations.
+- [Video](https://weboftrust.github.io/keridoc/docs/category/video/index.md): Video's.
+- [Various external glossaries](https://weboftrust.github.io/keridoc/docs/category/various-external-glossaries/index.md): Here you find various external glossaries.
+- [Resources](https://weboftrust.github.io/keridoc/docs/category/resources/index.md): Resources.
+- [Overview](https://weboftrust.github.io/keridoc/docs/category/overview/index.md): Overview.
+- [Intro](https://weboftrust.github.io/keridoc/docs/category/intro/index.md): Intro.
+- [How we did](https://weboftrust.github.io/keridoc/docs/category/how-we-did/index.md): Overview of how this website is made.
+- [Education](https://weboftrust.github.io/keridoc/docs/category/education/index.md): Educational resources.
+- [Concepts](https://weboftrust.github.io/keridoc/docs/category/concepts/index.md): Concepts.
+- [Annotated Copies](https://weboftrust.github.io/keridoc/docs/category/annotated-copies/index.md): Literal copies of content elsewhere on the web.
+- [WebOfTrust-keria-main-docs-protocol](https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-keria-main-docs-protocol/index.md): signify-keria-request-authentication-protocol--skrap-, level 1
+- [WebOfTrust-ietf-ipex-main-draft-ssmith-ipex](https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-ipex-main-draft-ssmith-ipex/index.md): 248943216478, level 1
+- [WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof](https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-cesr-proof-main-draft-pfeairheller-cesr-proof/index.md): 4493255410370, level 1
+- [WebOfTrust-ietf-acdc-main-draft-ssmith-acdc](https://weboftrust.github.io/keridoc/docs/annotated-copies/WebOfTrust-ietf-acdc-main-draft-ssmith-acdc/index.md): Temporarily removed content, because the site won't generate.
+- [kli-demo-2022](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/kli-demo-2022/index.md): -->
+- [draft-ssmith-said](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-said/index.md): title: "Self-Addressing IDentifier (SAID)"
+- [draft-ssmith-oobi](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-oobi/index.md): title: "Out-Of-Band-Introduction (OOBI) Protocol"
+- [draft-ssmith-keri](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-keri/index.md): title: "Key Event Receipt Infrastructure (KERI)"
+- [draft-ssmith-ipex](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-ipex/index.md): title: "Issuance and Presentation Exchange Protocol"
+- [draft-ssmith-cesr](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-cesr/index.md): title: "Composable Event Streaming Representation (CESR)"
+- [draft-ssmith-acdc](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-ssmith-acdc/index.md): title: "Authentic Chained Data Containers (ACDC)"
+- [draft-pfeairheller-ptel](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-ptel/index.md): title: "Public Transaction Event Logs (PTEL)"
+- [draft-pfeairheller-did-keri](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-did-keri/index.md): titlekeri DID Method"
+- [draft-pfeairheller-cesr-proof](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/draft-pfeairheller-cesr-proof/index.md): title: "CESR Proof Signatures"
+- [UNIVERSAL IDENTIFIER THEORY](https://weboftrust.github.io/keridoc/docs/resources/mdfiles/IdentifierTheory-ssmith-uidt/index.md): Samuel M. Smith Ph.D.\
+- [Typesense search install and configuration](https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/typesense-search-install-config/index.md): What is this: the necessary Typesense search engine commands and configs to serve the KERISSE sit...
+- [Overrides](https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/overrides/index.md): See//github.com/WebOfTrustkeridoc/blob/main/search-index-typesense/overrides.sh#L6
+- [IP rights of scraped sources](https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/ip-rights-scraping/index.md): What is this: accountability for having asked permission, where needed, to use the sources on the...
+- [Create a search index](https://weboftrust.github.io/keridoc/docs/how-we-did/kerisse/create-search-index/index.md): Instructions plus background.
+- [Kerific Discord bot](https://weboftrust.github.io/keridoc/docs/how-we-did/kerific/kerific-discord-bot/index.md): See the Kerific Discord Bot README.MD
+- [Kerific Bookmarklet and Chrome Extension](https://weboftrust.github.io/keridoc/docs/how-we-did/kerific/kerific-browser-extension/index.md): Your browser does not support video tags.
+- [The Terms WOT manage structure explained](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/why-terms-wot-manage-structure/index.md): What is this: A description of architecture and follow-up technical design
+- [Github Actions](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/organization-of-Github-Action-scripts/index.md): For who
+- [JavaScript documentation](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/javascript-jsdoc/index.md): Client Side and NodeJS JavaScript documention using JSDoc (opens in new tab)
+- [File system](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/file-system/index.md): For who: maintainers and developers
+- [Docusaurus process](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/docusaurus-process/index.md)
+- [Create an online table to link terms to resources](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/create-terms-link-table/index.md): What is this: This is how-we-did the processing of a video into an educational resource.
+- [Create Omnigraffle infographic and convert to SVG](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/create-omnigraffle-infographic-and-convert-to-svg/index.md): Why this doc: to show how-we-did create SVG files to serve as infographics on the site
+- [Check and accept PR production KERISSE site locally](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/check-and-accept-pr-production-edusite-locally/index.md): Why this how-we-did: To test pull request offered before accepting them in github
+- [Cheat sheet: writing a page inside /docs](https://weboftrust.github.io/keridoc/docs/how-we-did/keridoc/cheat-sheet-writing-page/index.md): What is this: A few rules about headings, internal linking, images and more that we kept in mind....
+- [Load weboftrust glossary in weboftrust github page](https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/load-glossary-weboftrust-in-docusaurus/index.md): Why how-we-did this: We'ld like to have a straightforward editting tool that authenticates users ...
+- [Fill out terms in the WebofTrust wiki](https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/fill-out-terms-toip-wiki/index.md): What is this
+- [Embed a Github-hosted image in a Github wiki page](https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/embed-github-hosted-image-in-github-wiki-page/index.md): For who: content developers and those who'd like to repair broken images
+- [Edit glossary metadata](https://weboftrust.github.io/keridoc/docs/how-we-did/glossary/edit-metadata/index.md): The glossary metadata are currently hosted in Google Sheets.
+- [Redirects](https://weboftrust.github.io/keridoc/docs/how-we-did/general/redirects/index.md): These are the redirects that can be used:
+- [Install this repo](https://weboftrust.github.io/keridoc/docs/how-we-did/general/install-project-kerisse/index.md): Result: | @kordwarshuis TBW |
+- [Verify a credential](https://weboftrust.github.io/keridoc/docs/concepts/how-to/verify-a-credential/index.md): Lorem ipsum
+- [Set up a basic KERI network](https://weboftrust.github.io/keridoc/docs/concepts/how-to/set-up-basic-keri-network/index.md): Lorem ipsum
+- [Present a credential](https://weboftrust.github.io/keridoc/docs/concepts/how-to/present-a-credential/index.md): Lorem ipsum
+- [Make a schema](https://weboftrust.github.io/keridoc/docs/concepts/how-to/make-a-schema/index.md): Lorem ipsum
+- [Issue a credential](https://weboftrust.github.io/keridoc/docs/concepts/how-to/issue-a-credential/index.md): Lorem ipsum
+- [Intro](https://weboftrust.github.io/keridoc/docs/concepts/how-to/intro/index.md): Lorem ipsum
+- [Current open issues](https://weboftrust.github.io/keridoc/docs/concepts/how-to/current-open-issues/index.md): Lorem ipsum
+- [Create a basic ACDC graph](https://weboftrust.github.io/keridoc/docs/concepts/how-to/create-a-basic-acdc-graph/index.md): Lorem ipsum
+- [Contributors' Guide](https://weboftrust.github.io/keridoc/docs/concepts/how-to/contribute-to-weboftrust-github/index.md): Introduction
diff --git a/llm-docs/markdown.zip b/llm-docs/markdown.zip
new file mode 100644
index 00000000..187e14d9
Binary files /dev/null and b/llm-docs/markdown.zip differ