diff --git a/docs/04_glossary/ACDC.md b/docs/04_glossary/ACDC.md deleted file mode 100644 index 30b6b018..00000000 --- a/docs/04_glossary/ACDC.md +++ /dev/null @@ -1,3 +0,0 @@ -# ACDC -## See -[authentic chained data container](authentic-chained-data-container) \ No newline at end of file diff --git a/docs/04_glossary/ADC.md b/docs/04_glossary/ADC.md deleted file mode 100644 index 82af4dfb..00000000 --- a/docs/04_glossary/ADC.md +++ /dev/null @@ -1,3 +0,0 @@ -# ADC -## See -[Authentic data container](authentic-data-container) \ No newline at end of file diff --git a/docs/04_glossary/ADR.md b/docs/04_glossary/ADR.md deleted file mode 100644 index 56c768d2..00000000 --- a/docs/04_glossary/ADR.md +++ /dev/null @@ -1,3 +0,0 @@ -# ADR -## See -[Architectural Decision Record](architectural-decision-record) diff --git a/docs/04_glossary/AID.md b/docs/04_glossary/AID.md deleted file mode 100644 index f298ac86..00000000 --- a/docs/04_glossary/AID.md +++ /dev/null @@ -1,3 +0,0 @@ -# AID -## See -[Autonomic identifier](autonomic-identifier) \ No newline at end of file diff --git a/docs/04_glossary/APC.md b/docs/04_glossary/APC.md deleted file mode 100644 index 8f8f93c2..00000000 --- a/docs/04_glossary/APC.md +++ /dev/null @@ -1,3 +0,0 @@ -# APC -## See -[Authentic provenance chain](authentic-provenance-chain) \ No newline at end of file diff --git a/docs/04_glossary/API.md b/docs/04_glossary/API.md deleted file mode 100644 index d17dd433..00000000 --- a/docs/04_glossary/API.md +++ /dev/null @@ -1,3 +0,0 @@ -# API -## See -[Application programming interface](application-programming-interface) \ No newline at end of file diff --git a/docs/04_glossary/AVR.md b/docs/04_glossary/AVR.md deleted file mode 100644 index 1e6e4720..00000000 --- a/docs/04_glossary/AVR.md +++ /dev/null @@ -1,3 +0,0 @@ -# AVR -## See -[Authorized vLEI Representative](authorized-vlei-representative) \ No newline at end of file diff --git a/docs/04_glossary/BADA.md b/docs/04_glossary/BADA.md deleted file mode 100644 index 050b7254..00000000 --- a/docs/04_glossary/BADA.md +++ /dev/null @@ -1,3 +0,0 @@ -# BADA -## See -[Best available data acceptance mechanism](best-available-data-acceptance-mechanism) \ No newline at end of file diff --git a/docs/04_glossary/BFT.md b/docs/04_glossary/BFT.md deleted file mode 100644 index fea1acf3..00000000 --- a/docs/04_glossary/BFT.md +++ /dev/null @@ -1,3 +0,0 @@ -# BFT -## See -[Byzantine fault tolerance](byzantine-fault-tolerance) \ No newline at end of file diff --git a/docs/04_glossary/BOLA.md b/docs/04_glossary/BOLA.md deleted file mode 100644 index 9fdcdf65..00000000 --- a/docs/04_glossary/BOLA.md +++ /dev/null @@ -1,3 +0,0 @@ -# BOLA -## See -[Broken Object Level Authorization](broken-object-level-authorization) \ No newline at end of file diff --git a/docs/04_glossary/CBOR.md b/docs/04_glossary/CBOR.md deleted file mode 100644 index 6b4c3410..00000000 --- a/docs/04_glossary/CBOR.md +++ /dev/null @@ -1,3 +0,0 @@ -# CBOR -## See -[Concise Binary Object Representation](concise-binary-object-representation) \ No newline at end of file diff --git a/docs/04_glossary/CESR.md b/docs/04_glossary/CESR.md deleted file mode 100644 index 9c3ee184..00000000 --- a/docs/04_glossary/CESR.md +++ /dev/null @@ -1,3 +0,0 @@ -# CESR -## See -[composable event streaming representation](composable-event-streaming-representation) \ No newline at end of file diff --git a/docs/04_glossary/CLC.md b/docs/04_glossary/CLC.md deleted file mode 100644 index f06d1a71..00000000 --- a/docs/04_glossary/CLC.md +++ /dev/null @@ -1,3 +0,0 @@ -# CLC -## See -[Chain link confidential](chain-link-confidentiality) \ No newline at end of file diff --git a/docs/04_glossary/CRUD.md b/docs/04_glossary/CRUD.md deleted file mode 100644 index f95fb55b..00000000 --- a/docs/04_glossary/CRUD.md +++ /dev/null @@ -1,10 +0,0 @@ -# CRUD -## Definition - -Is acronym for the traditional _client-server_ database update policy is CRUD (**Create, Read, Update, Delete**). - -CRUD as opposed to [RUN](RUN) which is the acronym for the new peer-to-peer end-verifiable monotonic update policy. - -## OOBI related -We [RUN off the CRUD](run-off-the-crud), 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. - \ No newline at end of file diff --git a/docs/04_glossary/CSPRNG.md b/docs/04_glossary/CSPRNG.md deleted file mode 100644 index b14cc4c5..00000000 --- a/docs/04_glossary/CSPRNG.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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) - -## See also -[PRNG](PRNG) \ No newline at end of file diff --git a/docs/04_glossary/CT.md b/docs/04_glossary/CT.md deleted file mode 100644 index b94ece05..00000000 --- a/docs/04_glossary/CT.md +++ /dev/null @@ -1,3 +0,0 @@ -# CT -## See -[Certificate transparency](certificate-transparency) \ No newline at end of file diff --git a/docs/04_glossary/DAG.md b/docs/04_glossary/DAG.md deleted file mode 100644 index b9dce7a8..00000000 --- a/docs/04_glossary/DAG.md +++ /dev/null @@ -1,3 +0,0 @@ -# DAG -## See -[Directed acyclic graph](directed-acyclic-graph) diff --git a/docs/04_glossary/DAR.md b/docs/04_glossary/DAR.md deleted file mode 100644 index 6a05813e..00000000 --- a/docs/04_glossary/DAR.md +++ /dev/null @@ -1,3 +0,0 @@ -# DAR -## See -[Designated Authorized Representatives](designated-authorized-representative) \ No newline at end of file diff --git a/docs/04_glossary/DEL.md b/docs/04_glossary/DEL.md deleted file mode 100644 index e13e8968..00000000 --- a/docs/04_glossary/DEL.md +++ /dev/null @@ -1,3 +0,0 @@ -# DEL -## See -[Duplicitous event log](duplicitous-event-log) \ No newline at end of file diff --git a/docs/04_glossary/DHT.md b/docs/04_glossary/DHT.md deleted file mode 100644 index 0c0b302f..00000000 --- a/docs/04_glossary/DHT.md +++ /dev/null @@ -1,3 +0,0 @@ -# DHT -## See -[Distributed hash table](distributed-hash-table) \ No newline at end of file diff --git a/docs/04_glossary/DID.md b/docs/04_glossary/DID.md deleted file mode 100644 index e06aed4b..00000000 --- a/docs/04_glossary/DID.md +++ /dev/null @@ -1,3 +0,0 @@ -# DID -## See -[Decentralized Identifier](https://github.com/trustoverip/acdc/wiki/decentralized-identifier) \ No newline at end of file diff --git a/docs/04_glossary/DKMI.md b/docs/04_glossary/DKMI.md deleted file mode 100644 index 5f58dff7..00000000 --- a/docs/04_glossary/DKMI.md +++ /dev/null @@ -1,3 +0,0 @@ -# DKMI -## See -[Decentralized key management infrastructure](decentralized-key-management-infrastructure) \ No newline at end of file diff --git a/docs/04_glossary/DPKI.md b/docs/04_glossary/DPKI.md deleted file mode 100644 index 004ce210..00000000 --- a/docs/04_glossary/DPKI.md +++ /dev/null @@ -1,3 +0,0 @@ -# DPKI -## See -[Decentralized key management infrastructure](decentralized-key-management-infrastructure) \ No newline at end of file diff --git a/docs/04_glossary/E2E.md b/docs/04_glossary/E2E.md deleted file mode 100644 index 8223e7e6..00000000 --- a/docs/04_glossary/E2E.md +++ /dev/null @@ -1,3 +0,0 @@ -# E2E -## See -[End-to-end](end-to-end) \ No newline at end of file diff --git a/docs/04_glossary/ECR.md b/docs/04_glossary/ECR.md deleted file mode 100644 index 4b54b476..00000000 --- a/docs/04_glossary/ECR.md +++ /dev/null @@ -1,3 +0,0 @@ -# ECR -## See -[Engagement context role](engagement-context-role) diff --git a/docs/04_glossary/ESSR.md b/docs/04_glossary/ESSR.md deleted file mode 100644 index b9f71def..00000000 --- a/docs/04_glossary/ESSR.md +++ /dev/null @@ -1,3 +0,0 @@ -# ESSR -## See -[Encrypt‐Sender‐Sign‐Receiver](https://github.com/WebOfTrust/WOT-terms/wiki/encrypt-sender-sign-receiver) \ No newline at end of file diff --git a/docs/04_glossary/FFI.md b/docs/04_glossary/FFI.md deleted file mode 100644 index 4f3cacbd..00000000 --- a/docs/04_glossary/FFI.md +++ /dev/null @@ -1,3 +0,0 @@ -# FFI -## See -[Foreign Function Interface](foreign-function-interface) \ No newline at end of file diff --git a/docs/04_glossary/GAR.md b/docs/04_glossary/GAR.md deleted file mode 100644 index f05ad162..00000000 --- a/docs/04_glossary/GAR.md +++ /dev/null @@ -1,3 +0,0 @@ -# GAR -## See -[GLEIF authorized representative](gleif-authorized-representative) diff --git a/docs/04_glossary/GLEIF.md b/docs/04_glossary/GLEIF.md deleted file mode 100644 index ac135b01..00000000 --- a/docs/04_glossary/GLEIF.md +++ /dev/null @@ -1,6 +0,0 @@ -# GLEIF -## Definition -Global Legal Entity Identifier Foundation - -## More information -https://www.gleif.org/en \ No newline at end of file diff --git a/docs/04_glossary/GLEIS.md b/docs/04_glossary/GLEIS.md deleted file mode 100644 index 55bf28ac..00000000 --- a/docs/04_glossary/GLEIS.md +++ /dev/null @@ -1,3 +0,0 @@ -# GLEIS -## Definition -Global Legal Entity Identifier System \ No newline at end of file diff --git a/docs/04_glossary/GPG.md b/docs/04_glossary/GPG.md deleted file mode 100644 index f7f9e84b..00000000 --- a/docs/04_glossary/GPG.md +++ /dev/null @@ -1,3 +0,0 @@ -# GPG -## See -[Gnu privacy guard](gnu-privacy-guard) \ No newline at end of file diff --git a/docs/04_glossary/HSM.md b/docs/04_glossary/HSM.md deleted file mode 100644 index d930591b..00000000 --- a/docs/04_glossary/HSM.md +++ /dev/null @@ -1,3 +0,0 @@ -# HSM -## See -[Hardware security model](hardware-security-module) \ No newline at end of file diff --git a/docs/04_glossary/Home.md b/docs/04_glossary/Home.md deleted file mode 100644 index cc4610c0..00000000 --- a/docs/04_glossary/Home.md +++ /dev/null @@ -1,20 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/I-O.md b/docs/04_glossary/I-O.md deleted file mode 100644 index 8ebf7756..00000000 --- a/docs/04_glossary/I-O.md +++ /dev/null @@ -1,3 +0,0 @@ -# I O -## See -[Input output](input-output) \ No newline at end of file diff --git a/docs/04_glossary/IANA.md b/docs/04_glossary/IANA.md deleted file mode 100644 index 23632bab..00000000 --- a/docs/04_glossary/IANA.md +++ /dev/null @@ -1,3 +0,0 @@ -# IANA -## See -[Internet assigned numbers authority](internet-assigned-numbers-authority) \ No newline at end of file diff --git a/docs/04_glossary/IPEX.md b/docs/04_glossary/IPEX.md deleted file mode 100644 index 750e413b..00000000 --- a/docs/04_glossary/IPEX.md +++ /dev/null @@ -1,3 +0,0 @@ -# IPEX -## See -[Issuance and presentation exchange protocol](issuance-and-presentation-exchange-protocol) \ No newline at end of file diff --git a/docs/04_glossary/JOSE.md b/docs/04_glossary/JOSE.md deleted file mode 100644 index ccf1e623..00000000 --- a/docs/04_glossary/JOSE.md +++ /dev/null @@ -1,3 +0,0 @@ -# JOSE -## See -[Javascript object signing and encryption](javascript-object-signing-and-encryption) \ No newline at end of file diff --git a/docs/04_glossary/JSON.md b/docs/04_glossary/JSON.md deleted file mode 100644 index f88a8b7d..00000000 --- a/docs/04_glossary/JSON.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/KA2CE.md b/docs/04_glossary/KA2CE.md deleted file mode 100644 index abb102ae..00000000 --- a/docs/04_glossary/KA2CE.md +++ /dev/null @@ -1,3 +0,0 @@ -# KA2CE -## See -[KERI agreement algorithm for control establishment](keri-agreement-algorithm-for-control-establishment) \ No newline at end of file diff --git a/docs/04_glossary/KAACE.md b/docs/04_glossary/KAACE.md deleted file mode 100644 index b8e678b2..00000000 --- a/docs/04_glossary/KAACE.md +++ /dev/null @@ -1,3 +0,0 @@ -# KAACE -## See -[KERI agreement algorithm for control establishment](keri-agreement-algorithm-for-control-establishment) \ No newline at end of file diff --git a/docs/04_glossary/KAPI.md b/docs/04_glossary/KAPI.md deleted file mode 100644 index ae4b98aa..00000000 --- a/docs/04_glossary/KAPI.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/KEL.md b/docs/04_glossary/KEL.md deleted file mode 100644 index 5da78140..00000000 --- a/docs/04_glossary/KEL.md +++ /dev/null @@ -1,4 +0,0 @@ -# KEL -A Key Event Log. -## See -[Key Event Log](key-event-log) \ No newline at end of file diff --git a/docs/04_glossary/KERI.md b/docs/04_glossary/KERI.md deleted file mode 100644 index 2c4f78a3..00000000 --- a/docs/04_glossary/KERI.md +++ /dev/null @@ -1,3 +0,0 @@ -# KERI -## See -[Key event receipt infrastructure](key-event-receipt-infrastructure) \ No newline at end of file diff --git a/docs/04_glossary/KERIMask.md b/docs/04_glossary/KERIMask.md deleted file mode 100644 index fb438cc3..00000000 --- a/docs/04_glossary/KERIMask.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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](signify-keria-request-authentication-protocol) \ No newline at end of file diff --git a/docs/04_glossary/KERISSE.md b/docs/04_glossary/KERISSE.md deleted file mode 100644 index 46aeeeab..00000000 --- a/docs/04_glossary/KERISSE.md +++ /dev/null @@ -1,3 +0,0 @@ -# KERISSE -## See -[KERI suite search engine](keri-suite-search-engine) \ No newline at end of file diff --git a/docs/04_glossary/KERL.md b/docs/04_glossary/KERL.md deleted file mode 100644 index 104e2a36..00000000 --- a/docs/04_glossary/KERL.md +++ /dev/null @@ -1,3 +0,0 @@ -# KERL -## See -[Key event receipt log](key-event-receipt-log) \ No newline at end of file diff --git a/docs/04_glossary/KID.md b/docs/04_glossary/KID.md deleted file mode 100644 index 09cb69d8..00000000 --- a/docs/04_glossary/KID.md +++ /dev/null @@ -1,3 +0,0 @@ -# KID -## See -[KERI improvement doc](keri-improvement-doc) \ No newline at end of file diff --git a/docs/04_glossary/KRAM.md b/docs/04_glossary/KRAM.md deleted file mode 100644 index d1c6dfcb..00000000 --- a/docs/04_glossary/KRAM.md +++ /dev/null @@ -1,3 +0,0 @@ -# KRAM -## See -[KERI Request Authentication Method](keri-request-authentication-method) \ No newline at end of file diff --git a/docs/04_glossary/LEI.md b/docs/04_glossary/LEI.md deleted file mode 100644 index eed840e8..00000000 --- a/docs/04_glossary/LEI.md +++ /dev/null @@ -1,3 +0,0 @@ -# LEI -## Definition -Legal Entity Identifier \ No newline at end of file diff --git a/docs/04_glossary/LID.md b/docs/04_glossary/LID.md deleted file mode 100644 index b8a811f6..00000000 --- a/docs/04_glossary/LID.md +++ /dev/null @@ -1,3 +0,0 @@ -# LID -## See -[Legitimized human meaningful identifier ](legitimized-human-meaningful-identifier ) \ No newline at end of file diff --git a/docs/04_glossary/LLM.md b/docs/04_glossary/LLM.md deleted file mode 100644 index 89632e14..00000000 --- a/docs/04_glossary/LLM.md +++ /dev/null @@ -1,2 +0,0 @@ -# LLM -## See [Large Language Model](large-language-model) \ No newline at end of file diff --git a/docs/04_glossary/LoA.md b/docs/04_glossary/LoA.md deleted file mode 100644 index e616139f..00000000 --- a/docs/04_glossary/LoA.md +++ /dev/null @@ -1,3 +0,0 @@ -# LoA -## See -[Levels of assurance](levels-of-assurance) \ No newline at end of file diff --git a/docs/04_glossary/LoC.md b/docs/04_glossary/LoC.md deleted file mode 100644 index e5240bd6..00000000 --- a/docs/04_glossary/LoC.md +++ /dev/null @@ -1,3 +0,0 @@ -# LoC -## See -[Loci of control](loci-of-control) \ No newline at end of file diff --git a/docs/04_glossary/MFA.md b/docs/04_glossary/MFA.md deleted file mode 100644 index 56694150..00000000 --- a/docs/04_glossary/MFA.md +++ /dev/null @@ -1,3 +0,0 @@ -# MFA -## See -[Multi-factor Authentication](multi-factor-authentication) \ No newline at end of file diff --git a/docs/04_glossary/MIME-type.md b/docs/04_glossary/MIME-type.md deleted file mode 100644 index 84cd1227..00000000 --- a/docs/04_glossary/MIME-type.md +++ /dev/null @@ -1,3 +0,0 @@ -# MIME type -## See -[Media type](media-type) \ No newline at end of file diff --git a/docs/04_glossary/NFT.md b/docs/04_glossary/NFT.md deleted file mode 100644 index 1c388a5b..00000000 --- a/docs/04_glossary/NFT.md +++ /dev/null @@ -1,3 +0,0 @@ -# NFT -## See -[Non-fungible token](non-fungible-token) \ No newline at end of file diff --git a/docs/04_glossary/OOBI.md b/docs/04_glossary/OOBI.md deleted file mode 100644 index bbf49115..00000000 --- a/docs/04_glossary/OOBI.md +++ /dev/null @@ -1,3 +0,0 @@ -# OOBI -## See -[Out-of-band introduction](out-of-band-introduction) \ No newline at end of file diff --git a/docs/04_glossary/OOR.md b/docs/04_glossary/OOR.md deleted file mode 100644 index 1b3a7836..00000000 --- a/docs/04_glossary/OOR.md +++ /dev/null @@ -1,3 +0,0 @@ -# OOR -## See -[Official Organizational Role](official-organizational-role) \ No newline at end of file diff --git a/docs/04_glossary/P2P.md b/docs/04_glossary/P2P.md deleted file mode 100644 index cf7564ef..00000000 --- a/docs/04_glossary/P2P.md +++ /dev/null @@ -1,3 +0,0 @@ -# P2P -## See -[Peer to peer](peer-to-peer) \ No newline at end of file diff --git a/docs/04_glossary/PGP.md b/docs/04_glossary/PGP.md deleted file mode 100644 index 0f4edb12..00000000 --- a/docs/04_glossary/PGP.md +++ /dev/null @@ -1,3 +0,0 @@ -# PGP -## See -[Pretty good privacy](pretty-good-privacy) \ No newline at end of file diff --git a/docs/04_glossary/PID.md b/docs/04_glossary/PID.md deleted file mode 100644 index f81123b8..00000000 --- a/docs/04_glossary/PID.md +++ /dev/null @@ -1,3 +0,0 @@ -# PID -## See -[percolated information discovery](percolated-information-discovery) \ No newline at end of file diff --git a/docs/04_glossary/PKI.md b/docs/04_glossary/PKI.md deleted file mode 100644 index 56b4ca64..00000000 --- a/docs/04_glossary/PKI.md +++ /dev/null @@ -1,3 +0,0 @@ -# PKI -## See -[Public key infrastructure](public-key-infrastructure) \ No newline at end of file diff --git a/docs/04_glossary/PRNG.md b/docs/04_glossary/PRNG.md deleted file mode 100644 index 82fe6ed4..00000000 --- a/docs/04_glossary/PRNG.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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) - -## See also -[CSPRNG](CSPRNG) \ No newline at end of file diff --git a/docs/04_glossary/PTEL.md b/docs/04_glossary/PTEL.md deleted file mode 100644 index bdd20c33..00000000 --- a/docs/04_glossary/PTEL.md +++ /dev/null @@ -1,3 +0,0 @@ -# PTEL -## See -[Public transaction event log](public-transaction-event-log) \ No newline at end of file diff --git a/docs/04_glossary/QAR.md b/docs/04_glossary/QAR.md deleted file mode 100644 index d3c69d90..00000000 --- a/docs/04_glossary/QAR.md +++ /dev/null @@ -1,3 +0,0 @@ -# QAR -## See -[QVI Authorized Representative](qvi-authorized-representative) \ No newline at end of file diff --git a/docs/04_glossary/QVI.md b/docs/04_glossary/QVI.md deleted file mode 100644 index 8f97ad77..00000000 --- a/docs/04_glossary/QVI.md +++ /dev/null @@ -1,3 +0,0 @@ -# QVI -## See -[Qualified vLEI issuer](qualified-vlei-issuer) \ No newline at end of file diff --git a/docs/04_glossary/RID.md b/docs/04_glossary/RID.md deleted file mode 100644 index 390e929a..00000000 --- a/docs/04_glossary/RID.md +++ /dev/null @@ -1,3 +0,0 @@ -# RID -## See -[Root autonomic identifier (AID)](root-autonomic-identifier) \ No newline at end of file diff --git a/docs/04_glossary/RUN.md b/docs/04_glossary/RUN.md deleted file mode 100644 index a187cf71..00000000 --- a/docs/04_glossary/RUN.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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](CRUD) which is the traditional client-server database update policy. - -## OOBI related -We [RUN off the CRUD](run-off-the-crud), 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. - diff --git a/docs/04_glossary/SAD.md b/docs/04_glossary/SAD.md deleted file mode 100644 index 09af94c5..00000000 --- a/docs/04_glossary/SAD.md +++ /dev/null @@ -1,3 +0,0 @@ -# SAD -## See -[Self addressing data](self-addressing-data) \ No newline at end of file diff --git a/docs/04_glossary/SAID.md b/docs/04_glossary/SAID.md deleted file mode 100644 index 834d2daf..00000000 --- a/docs/04_glossary/SAID.md +++ /dev/null @@ -1,3 +0,0 @@ -# SAID -## See -[Self-addressing identifier](self-addressing-identifier) \ No newline at end of file diff --git a/docs/04_glossary/SATP.md b/docs/04_glossary/SATP.md deleted file mode 100644 index 4b79bd4f..00000000 --- a/docs/04_glossary/SATP.md +++ /dev/null @@ -1,3 +0,0 @@ -# SATP -## See -[Secure asset transfer protocol](secure-asset-transfer-protocol) \ No newline at end of file diff --git a/docs/04_glossary/SCID.md b/docs/04_glossary/SCID.md deleted file mode 100644 index 53bf5a7e..00000000 --- a/docs/04_glossary/SCID.md +++ /dev/null @@ -1,3 +0,0 @@ -# SCID -## See -[Self-certifying identifier](self-certifying-identifier) \ No newline at end of file diff --git a/docs/04_glossary/SKRAP.md b/docs/04_glossary/SKRAP.md deleted file mode 100644 index ca6c155b..00000000 --- a/docs/04_glossary/SKRAP.md +++ /dev/null @@ -1,3 +0,0 @@ -# SKRAP -## See -[Signify/KERIA Request Authentication Protocol](signify-keria-request-authentication-protocol) \ No newline at end of file diff --git a/docs/04_glossary/SKWA.md b/docs/04_glossary/SKWA.md deleted file mode 100644 index ee2f2b3d..00000000 --- a/docs/04_glossary/SKWA.md +++ /dev/null @@ -1,3 +0,0 @@ -# SKWA -## See -[Simple KERI for web auth](simple-keri-for-web-auth) \ No newline at end of file diff --git a/docs/04_glossary/SPAC.md b/docs/04_glossary/SPAC.md deleted file mode 100644 index 902cef38..00000000 --- a/docs/04_glossary/SPAC.md +++ /dev/null @@ -1,3 +0,0 @@ -# SPAC -## See -[Secure Private Authentic Confidentiality](secure-private-authentic-confidentiality) \ No newline at end of file diff --git a/docs/04_glossary/SSI.md b/docs/04_glossary/SSI.md deleted file mode 100644 index 8ebb344b..00000000 --- a/docs/04_glossary/SSI.md +++ /dev/null @@ -1,3 +0,0 @@ -# SSI -## See -[Self-sovereign identity](self-sovereign-identity) \ No newline at end of file diff --git a/docs/04_glossary/TCP.md b/docs/04_glossary/TCP.md deleted file mode 100644 index 4098a071..00000000 --- a/docs/04_glossary/TCP.md +++ /dev/null @@ -1,3 +0,0 @@ -# TCP -## See -[Transmission control protocol](transmission-control-protocol) \ No newline at end of file diff --git a/docs/04_glossary/TEE.md b/docs/04_glossary/TEE.md deleted file mode 100644 index 2f073277..00000000 --- a/docs/04_glossary/TEE.md +++ /dev/null @@ -1,3 +0,0 @@ -# TEE -## See -[trusted execution environment](trusted-execution-environment) \ No newline at end of file diff --git a/docs/04_glossary/TEL.md b/docs/04_glossary/TEL.md deleted file mode 100644 index 3fa0218c..00000000 --- a/docs/04_glossary/TEL.md +++ /dev/null @@ -1,3 +0,0 @@ -# TEL -## See -[Transaction event log](transaction-event-log) \ No newline at end of file diff --git a/docs/04_glossary/TOAD.md b/docs/04_glossary/TOAD.md deleted file mode 100644 index 916c83a7..00000000 --- a/docs/04_glossary/TOAD.md +++ /dev/null @@ -1,3 +0,0 @@ -# TOAD -## See -[threshold of accountable duplicity](threshold-of-accountable-duplicity) \ No newline at end of file diff --git a/docs/04_glossary/TPM.md b/docs/04_glossary/TPM.md deleted file mode 100644 index 3751035f..00000000 --- a/docs/04_glossary/TPM.md +++ /dev/null @@ -1,3 +0,0 @@ -# TPM -## See -[Trusted platform module](trusted-platform-module) \ No newline at end of file diff --git a/docs/04_glossary/TSP.md b/docs/04_glossary/TSP.md deleted file mode 100644 index e4752006..00000000 --- a/docs/04_glossary/TSP.md +++ /dev/null @@ -1,3 +0,0 @@ -# TSP -## See -[Trust Spanning Protocol](trust-spanning-protocol) \ No newline at end of file diff --git a/docs/04_glossary/UI.md b/docs/04_glossary/UI.md deleted file mode 100644 index 9b628260..00000000 --- a/docs/04_glossary/UI.md +++ /dev/null @@ -1,3 +0,0 @@ -# UI -## See -[User interface](user-interface) \ No newline at end of file diff --git a/docs/04_glossary/URL.md b/docs/04_glossary/URL.md deleted file mode 100644 index 36e8c45e..00000000 --- a/docs/04_glossary/URL.md +++ /dev/null @@ -1,3 +0,0 @@ -# URL -## See -[Uniform resource locator](uniform-resource-locator) \ No newline at end of file diff --git a/docs/04_glossary/VC-TEL.md b/docs/04_glossary/VC-TEL.md deleted file mode 100644 index 36a53a1e..00000000 --- a/docs/04_glossary/VC-TEL.md +++ /dev/null @@ -1,3 +0,0 @@ -# VC TEL -## See -[Virtual credential transaction event log](virtual-credential-transaction-event-log) \ No newline at end of file diff --git a/docs/04_glossary/VC.md b/docs/04_glossary/VC.md deleted file mode 100644 index 52bcd447..00000000 --- a/docs/04_glossary/VC.md +++ /dev/null @@ -1,3 +0,0 @@ -# VC -## See -[Verifiable credential](verifiable-credential) \ No newline at end of file diff --git a/docs/04_glossary/VDS.md b/docs/04_glossary/VDS.md deleted file mode 100644 index 8cfe610c..00000000 --- a/docs/04_glossary/VDS.md +++ /dev/null @@ -1,3 +0,0 @@ -# VDS -## See -[Verifiable data structure](verifiable-data-structure) \ No newline at end of file diff --git a/docs/04_glossary/VID.md b/docs/04_glossary/VID.md deleted file mode 100644 index 827d62d2..00000000 --- a/docs/04_glossary/VID.md +++ /dev/null @@ -1,3 +0,0 @@ -# VID -## See -[Verifiable Identifier](verifiable-identifier) \ No newline at end of file diff --git a/docs/04_glossary/XBRL.md b/docs/04_glossary/XBRL.md deleted file mode 100644 index badf155a..00000000 --- a/docs/04_glossary/XBRL.md +++ /dev/null @@ -1,3 +0,0 @@ -# XBRL -## See -[eXtensible Business Reporting Language](extensible-business-reporting-language) \ No newline at end of file diff --git a/docs/04_glossary/_category_.json b/docs/04_glossary/_category_.json deleted file mode 100644 index 5af18ebf..00000000 --- a/docs/04_glossary/_category_.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "label": "Glossary", - "link": { - "type": "generated-index", - "description": "Web of Trust Glossary." - } -} diff --git a/docs/04_glossary/access-controlled-interaction.md b/docs/04_glossary/access-controlled-interaction.md deleted file mode 100644 index f3355ecd..00000000 --- a/docs/04_glossary/access-controlled-interaction.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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](registration-interaction) \ No newline at end of file diff --git a/docs/04_glossary/agency.md b/docs/04_glossary/agency.md deleted file mode 100644 index 4b2df68a..00000000 --- a/docs/04_glossary/agency.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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](agency). \ No newline at end of file diff --git a/docs/04_glossary/agent.md b/docs/04_glossary/agent.md deleted file mode 100644 index 4e7bb7e5..00000000 --- a/docs/04_glossary/agent.md +++ /dev/null @@ -1,7 +0,0 @@ -# agent -## Definition -A representative for an identity. MAY require the use of a wallet. MAY support transfer. - -### KERIA Agent - -An agent in [KERIA](keria) terms is an instance of a keystore ([Hab](hab)) that runs in a given instance of the KERIA agent server. diff --git a/docs/04_glossary/ambient-verifiability.md b/docs/04_glossary/ambient-verifiability.md deleted file mode 100644 index 1012c8f4..00000000 --- a/docs/04_glossary/ambient-verifiability.md +++ /dev/null @@ -1,9 +0,0 @@ -# ambient verifiability -## Definition -Verifiable by anyone, anywhere, at anytime. Although this seems a general term, it was first used in the context of KERI by Sam Smith. - -_Ambient Duplicity Detection_ is an example of ambient verifiability that describes the possibility of detecting duplicity by anyone, anywhere, anytime. - -### Criteria -As soon as you limit any of the parameters of location, time or who can verify, it's not 'ambient verifiability' anymore. -For a signature to be ambiently verifiable, it needs to have no restrictions on these parameters. diff --git a/docs/04_glossary/ample.md b/docs/04_glossary/ample.md deleted file mode 100644 index c2932822..00000000 --- a/docs/04_glossary/ample.md +++ /dev/null @@ -1,74 +0,0 @@ -# ample -## Definition - -The minimum required number of participants in an event to have a [supermajority](supermajority) so that one and only one agreement or consensus on an event may be reached. This is a critical part of the [KAACE](KAACE) agreement algorithm (consensus) in KERI for establishing consensus between witnesses on the key state of a KERI identifier. This consensus on key state forms the basis for accountability for a KERI controller, or what a person who controls a KERI identifier may be held legally responsible for. - -This supermajority is also called a _sufficient majority_ that is labeled _immune_ from certain kinds of attacks or faults. - -From section **11.4.2.4 Immune** of v2.60 of the KERI whitepaper, -> Satisfaction of this constraint guarantees that at most one sufficient agreement occurs or none at -all despite a dishonest controller but where at most F of the witnesses are potentially faulty. - -Ample Agreement Constraint: -![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](KAACE): - -```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)) -``` diff --git a/docs/04_glossary/append-only-event-logs.md b/docs/04_glossary/append-only-event-logs.md deleted file mode 100644 index 750791f4..00000000 --- a/docs/04_glossary/append-only-event-logs.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/application-programming-interface.md b/docs/04_glossary/application-programming-interface.md deleted file mode 100644 index 9d33c58c..00000000 --- a/docs/04_glossary/application-programming-interface.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](API) may refer either to the specification or to the implementation. - -More on [source](https://en.wikipedia.org/wiki/API) Wikipedia. diff --git a/docs/04_glossary/architectural-decision-record.md b/docs/04_glossary/architectural-decision-record.md deleted file mode 100644 index 88f26c55..00000000 --- a/docs/04_glossary/architectural-decision-record.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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/) \ No newline at end of file diff --git a/docs/04_glossary/attributional-trust.md b/docs/04_glossary/attributional-trust.md deleted file mode 100644 index 6869ab41..00000000 --- a/docs/04_glossary/attributional-trust.md +++ /dev/null @@ -1,7 +0,0 @@ -# attributional trust -## Definition -KERI offers cryptographic root-of-trust to establish attributional trust. In the real world you'd also need [reputational trust](reputational-trust). 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](out-of-band-introduction)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](identity-assurance) by a to be trusted middle-men party, like [GLEIF](GLEIF). \ No newline at end of file diff --git a/docs/04_glossary/authentic-chained-data-container.md b/docs/04_glossary/authentic-chained-data-container.md deleted file mode 100644 index 2ecb1836..00000000 --- a/docs/04_glossary/authentic-chained-data-container.md +++ /dev/null @@ -1,7 +0,0 @@ -# authentic chained data container -## Definition - -In brief, an ACDC or [ADC](authentic-data-container) 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. - - - diff --git a/docs/04_glossary/authentic-data-container.md b/docs/04_glossary/authentic-data-container.md deleted file mode 100644 index 35a6f58c..00000000 --- a/docs/04_glossary/authentic-data-container.md +++ /dev/null @@ -1,7 +0,0 @@ -# authentic data container -## Definition -A mechanism for conveying data that allows the [authenticity](authenticity) of its content to be proved. - -## Instance -A [Verifiable Credential](https://w3.org/TR/vc-data-model/) is an ACDC - diff --git a/docs/04_glossary/authentic-data.md b/docs/04_glossary/authentic-data.md deleted file mode 100644 index 04ef986d..00000000 --- a/docs/04_glossary/authentic-data.md +++ /dev/null @@ -1,3 +0,0 @@ -# authentic data -## Definition -[Integer](integrity) and [Provenanced](provenance) data. Source: Timothy Ruff #IIW37 diff --git a/docs/04_glossary/authentic-provenance-chain.md b/docs/04_glossary/authentic-provenance-chain.md deleted file mode 100644 index 0b6e6027..00000000 --- a/docs/04_glossary/authentic-provenance-chain.md +++ /dev/null @@ -1,5 +0,0 @@ -# authentic provenance chain -## Definition - -Interlinked presentations of evidence that allow data to be tracked back to its origin in an objectively verifiable way. - diff --git a/docs/04_glossary/authentic-web.md b/docs/04_glossary/authentic-web.md deleted file mode 100644 index da0bda0a..00000000 --- a/docs/04_glossary/authentic-web.md +++ /dev/null @@ -1,21 +0,0 @@ -# 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](KERI) 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](directed-acyclic-graph) -- 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](root-of-trust) - -## 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 diff --git a/docs/04_glossary/authenticity.md b/docs/04_glossary/authenticity.md deleted file mode 100644 index 99c95bc4..00000000 --- a/docs/04_glossary/authenticity.md +++ /dev/null @@ -1,19 +0,0 @@ -# authenticity -## Definition - -The quality of having an objectively verifiable origin ; contrast [veracity](veracity). 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](security). Ideally it should be [verifiable](verifiable) (to a [root-of-trust](root-of-trust)). The future picture therein is the [Authentic Web](authentic-web). - -## 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](confidentiality) -- [privacy](privacy) \ No newline at end of file diff --git a/docs/04_glossary/authoritative.md b/docs/04_glossary/authoritative.md deleted file mode 100644 index 0da44539..00000000 --- a/docs/04_glossary/authoritative.md +++ /dev/null @@ -1,13 +0,0 @@ -# authoritative -## Definition -Established control [authority](authority) 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](PKI) key pairs that have this feature. - -## Four A’s of secure data control -1. Author: creator, [source-of-truth](source-of-truth) -2. Authentic: provable origin, [root-of-trust](root-of-trust) -3. Authorized: consent, [loci-of-control](loci-of-control) -4. **Authoritative: accurate, reputable** - -"A4" data control securely is established via [self-certifying](self-certifying-identifier) pseudonymous identifiers -[Source](https://youtu.be/L82O9nqHjRE) Samuel M. Smith \ No newline at end of file diff --git a/docs/04_glossary/authority.md b/docs/04_glossary/authority.md deleted file mode 100644 index 2e89655c..00000000 --- a/docs/04_glossary/authority.md +++ /dev/null @@ -1,2 +0,0 @@ -# authority -## See ToIP glossary \ No newline at end of file diff --git a/docs/04_glossary/authorization.md b/docs/04_glossary/authorization.md deleted file mode 100644 index 51386f13..00000000 --- a/docs/04_glossary/authorization.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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](autonomic-identifier) under which the authorization is issued. A [verifier](verifier) may then [verify](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](security) from their associated AID. - -### W3C VC form -Authorizations may take many forms. One form of particular interest is the *W3C Verifiable Credential* [VC](VC) standard. Verifiable credentials use the W3C Decentralized Identifier [DID](DID) 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](pseudo-random-number) strings as an element. \ No newline at end of file diff --git a/docs/04_glossary/authorized-vlei-representative.md b/docs/04_glossary/authorized-vlei-representative.md deleted file mode 100644 index a3fa1f4f..00000000 --- a/docs/04_glossary/authorized-vlei-representative.md +++ /dev/null @@ -1,8 +0,0 @@ -# authorized vlei representative -## Definition -Also 'AVR'. This a representative of a Legal Entity that are authorized by the [DAR](DAR) of a Legal Entity to request issuance and revocation of: -- vLEI Legal Entity Credentials -- Legal Entity Official Organizational Role vLEI Credentials ([OOR](official-organizational-role) vLEI Credentials) -- Legal Entity Engagement Context Role vLEI Credentials ([ECR](engagement-context-role) 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. \ No newline at end of file diff --git a/docs/04_glossary/autonomic-computing-systems.md b/docs/04_glossary/autonomic-computing-systems.md deleted file mode 100644 index 087af514..00000000 --- a/docs/04_glossary/autonomic-computing-systems.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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". diff --git a/docs/04_glossary/autonomic-identifier.md b/docs/04_glossary/autonomic-identifier.md deleted file mode 100644 index a7da0122..00000000 --- a/docs/04_glossary/autonomic-identifier.md +++ /dev/null @@ -1,15 +0,0 @@ -# autonomic identifier -## Definition - -An identifier that is [self-certifying](self-certifying-identifier) and [self-sovereign](self-sovereign-identity) (or *self-managing*). - -## KERI related requirements -A self-managing [cryptonym](cryptonym)ous identifier that MUST be self-certifying (self-authenticating) and MUST be encoded in CESR as a [qualified](qualified) cryptographic primitive. An AID MAY exhibit other self-managing properties such as transferable control using key [pre-rotation](pre-rotation) which enables control over such an AID to persist in spite of key weakness or compromise due to exposure. [Authoritative](authoritative) 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 diff --git a/docs/04_glossary/autonomic-identity-system.md b/docs/04_glossary/autonomic-identity-system.md deleted file mode 100644 index 3e42f058..00000000 --- a/docs/04_glossary/autonomic-identity-system.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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. - - \ No newline at end of file diff --git a/docs/04_glossary/autonomic-namespace.md b/docs/04_glossary/autonomic-namespace.md deleted file mode 100644 index 40d3b7ad..00000000 --- a/docs/04_glossary/autonomic-namespace.md +++ /dev/null @@ -1,3 +0,0 @@ -# autonomic namespace -## Definition -A namespace that is self-certifying and hence self-administrating. ANs are therefore portable = truly self sovereign. \ No newline at end of file diff --git a/docs/04_glossary/autonomic-trust-basis.md b/docs/04_glossary/autonomic-trust-basis.md deleted file mode 100644 index 32e96a4f..00000000 --- a/docs/04_glossary/autonomic-trust-basis.md +++ /dev/null @@ -1,12 +0,0 @@ -# autonomic trust basis -## Definition -When use an [AID](AID) as the [root-of-trust](root-of-trust) 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](security) nor [decentralized](decentralized-identifier). diff --git a/docs/04_glossary/backer.md b/docs/04_glossary/backer.md deleted file mode 100644 index 02b4ba4f..00000000 --- a/docs/04_glossary/backer.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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. - - \ No newline at end of file diff --git a/docs/04_glossary/base-media-type.md b/docs/04_glossary/base-media-type.md deleted file mode 100644 index 196be175..00000000 --- a/docs/04_glossary/base-media-type.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/base64.md b/docs/04_glossary/base64.md deleted file mode 100644 index 00285978..00000000 --- a/docs/04_glossary/base64.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/bespoke-credential.md b/docs/04_glossary/bespoke-credential.md deleted file mode 100644 index dad1a067..00000000 --- a/docs/04_glossary/bespoke-credential.md +++ /dev/null @@ -1,17 +0,0 @@ -# bespoke credential -## Definition -It's an [issuance](issuance-event) 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) \ No newline at end of file diff --git a/docs/04_glossary/best-available-data-acceptance-mechanism.md b/docs/04_glossary/best-available-data-acceptance-mechanism.md deleted file mode 100644 index 66c49b24..00000000 --- a/docs/04_glossary/best-available-data-acceptance-mechanism.md +++ /dev/null @@ -1,9 +0,0 @@ -# best available data acceptance mechanism -## Definition - -The BADA security model provides a degree of [replay attack](replay-attack) 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](authorization) 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](KERI)'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](run-off-the-crud) -- [RUN](read-update-nullify) \ No newline at end of file diff --git a/docs/04_glossary/bexter.md b/docs/04_glossary/bexter.md deleted file mode 100644 index 0d91fafe..00000000 --- a/docs/04_glossary/bexter.md +++ /dev/null @@ -1,58 +0,0 @@ -# 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 the -qb64 version not including the leader. - -Due to ambiguity that arises from pre-padding bext whose length is a multiple of three with one or more 'A' chars. Any bext that starts with an 'A' and whose length is either a multiple of 3 or 4 may not round trip. Bext with a leading 'A' whose length is a multiple of four may have the leading 'A' stripped when round tripping. -- Bexter(bext='ABBB').bext == 'BBB' -- Bexter(bext='BBB').bext == 'BBB' -- Bexter(bext='ABBB').qb64 == '4AABABBB' == Bexter(bext='BBB').qb64 - -To avoid this problem, only use for applications of base 64 strings that never start with 'A' - -Examples: base64 text strings: -- bext = "" -- qb64 = '4AAA' -- bext = "-" -- qb64 = '6AABAAA-' -- bext = "-A" -- qb64 = '5AABAA-A' -- bext = "-A-" -- qb64 = '4AABA-A-' -- bext = "-A-B" -- qb64 = '4AAB-A-B' - -#### 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 otherwise -Properties: - .text is the Base64 text value, .qb64 with text code and leader removed. -Hidden: - ._pad is method to compute .pad property - ._code is str value for .code property - ._raw is bytes value for .raw property - ._index is int value for .index property - ._infil is method to compute fully qualified Base64 from .raw and .code - ._exfil is method to extract .code and .raw from fully qualified Base64 -Methods: -""" - \ No newline at end of file diff --git a/docs/04_glossary/binding.md b/docs/04_glossary/binding.md deleted file mode 100644 index 606d478f..00000000 --- a/docs/04_glossary/binding.md +++ /dev/null @@ -1,3 +0,0 @@ -# binding -## Definition -In short, the technique of connecting two data elements together. In the context of [KERI](key-event-receipt-infrastructure) it's the association of data or an [identifier](identifier) with another identifier or a subject (a person, organization or machine), thereby lifting the privacy of the subject through that connection, i.e. **binding**. diff --git a/docs/04_glossary/bis.md b/docs/04_glossary/bis.md deleted file mode 100644 index 637cfc61..00000000 --- a/docs/04_glossary/bis.md +++ /dev/null @@ -1,3 +0,0 @@ -# bis -## Definition -bis = backed vc issue, registry-backed transaction event log credential issuance diff --git a/docs/04_glossary/bivalent.md b/docs/04_glossary/bivalent.md deleted file mode 100644 index b76b3346..00000000 --- a/docs/04_glossary/bivalent.md +++ /dev/null @@ -1,14 +0,0 @@ -# bivalent -## Definition -A nested set of layered delegations in a [delegation](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. - -![bivalent-key-management-infrastructure](https://github.com/weboftrust/WOT-terms/static/img/bivalent-key-management-infrastructure.png) - -To elaborate, in a [cooperative delegation](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. - -Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith - - -## Also see -[Multivalent](multi-valent) -[Univalent](univalent) \ No newline at end of file diff --git a/docs/04_glossary/blake3.md b/docs/04_glossary/blake3.md deleted file mode 100644 index ecaf502e..00000000 --- a/docs/04_glossary/blake3.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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. diff --git a/docs/04_glossary/blind-oobi.md b/docs/04_glossary/blind-oobi.md deleted file mode 100644 index 23e3845b..00000000 --- a/docs/04_glossary/blind-oobi.md +++ /dev/null @@ -1,24 +0,0 @@ -# blind oobi -## Definition -A blind [OOBI](OOBI) means that you have some mechanisms in place for verifying the [AID](AID) instead of via the OOBI itself. A blind OOBI is essentially a [URL](URL). 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](KEL) 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 - - - diff --git a/docs/04_glossary/blinded-revocation-registry.md b/docs/04_glossary/blinded-revocation-registry.md deleted file mode 100644 index 86ca8c40..00000000 --- a/docs/04_glossary/blinded-revocation-registry.md +++ /dev/null @@ -1,17 +0,0 @@ -# blinded revocation registry -## Definition -The current state of a [transaction event log](transaction-event-log) (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](rainbow-table-attack) because the hash has enough [entropy](entropy) 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!" \ No newline at end of file diff --git a/docs/04_glossary/bran.md b/docs/04_glossary/bran.md deleted file mode 100644 index 76adec42..00000000 --- a/docs/04_glossary/bran.md +++ /dev/null @@ -1,25 +0,0 @@ -# bran -## Definition - -A cryptographic string used as a primary input, a seed, for creating key material for and [autonomic-identifier](autonomic-identifier). - -## 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 \ No newline at end of file diff --git a/docs/04_glossary/branch.md b/docs/04_glossary/branch.md deleted file mode 100644 index e989c9f9..00000000 --- a/docs/04_glossary/branch.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/broken-object-level-authorization.md b/docs/04_glossary/broken-object-level-authorization.md deleted file mode 100644 index 331dc607..00000000 --- a/docs/04_glossary/broken-object-level-authorization.md +++ /dev/null @@ -1,3 +0,0 @@ -# broken object level authorization -## Definition -Refers to [security](security) flaws where users can access data they shouldn't, due to inadequate permission checks on individual (sub)objects. diff --git a/docs/04_glossary/brv.md b/docs/04_glossary/brv.md deleted file mode 100644 index cbc107ec..00000000 --- a/docs/04_glossary/brv.md +++ /dev/null @@ -1,3 +0,0 @@ -# brv -## Definition -brv = backed vc revoke, registry-backed transaction event log credential revocation diff --git a/docs/04_glossary/byzantine-agreement.md b/docs/04_glossary/byzantine-agreement.md deleted file mode 100644 index 00d6c44e..00000000 --- a/docs/04_glossary/byzantine-agreement.md +++ /dev/null @@ -1,14 +0,0 @@ -# byzantine agreement -## Definition -(non PoW) Byzantine Agreement is [Byzantine fault tolerance](byzantine-fault-tolerance) 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 -``` \ No newline at end of file diff --git a/docs/04_glossary/byzantine-fault-tolerance.md b/docs/04_glossary/byzantine-fault-tolerance.md deleted file mode 100644 index 08598ae4..00000000 --- a/docs/04_glossary/byzantine-fault-tolerance.md +++ /dev/null @@ -1,16 +0,0 @@ -# byzantine fault tolerance -## Definition -A Byzantine fault (also interactive consistency, source congruency, error avalanche, [Byzantine agreement](byzantine-agreement) 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. \ No newline at end of file diff --git a/docs/04_glossary/certificate-transparency.md b/docs/04_glossary/certificate-transparency.md deleted file mode 100644 index c4966722..00000000 --- a/docs/04_glossary/certificate-transparency.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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). \ No newline at end of file diff --git a/docs/04_glossary/cesr-proof-signatures.md b/docs/04_glossary/cesr-proof-signatures.md deleted file mode 100644 index 0e8cbc78..00000000 --- a/docs/04_glossary/cesr-proof-signatures.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) - - \ No newline at end of file diff --git a/docs/04_glossary/cesride.md b/docs/04_glossary/cesride.md deleted file mode 100644 index 57992b21..00000000 --- a/docs/04_glossary/cesride.md +++ /dev/null @@ -1,24 +0,0 @@ -# cesride -## Definition -is concerned with parsing CESR primitives. - -Cesride is built from cryptographic primitives that are named clearly and concisely. There are: -* [Diger](diger) -* [Verfer](verfer) -* [Signer](signer) -* [Siger](siger) -* [Cigar](cigar) -* [Salter](salter) - -Each primitive will have methods attached to it that permit one to generate and parse the qualified base2 or [base64](base64) 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](parside) diff --git a/docs/04_glossary/chain-link-confidentiality.md b/docs/04_glossary/chain-link-confidentiality.md deleted file mode 100644 index f504a4b2..00000000 --- a/docs/04_glossary/chain-link-confidentiality.md +++ /dev/null @@ -1,13 +0,0 @@ -# chain link confidentiality -## Definition -Chains together a sequence of [Disclosees](disclosee) 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](discloser) 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](presentation-exchange) 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](directed-acyclic-graph) 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) diff --git a/docs/04_glossary/chain-of-custody.md b/docs/04_glossary/chain-of-custody.md deleted file mode 100644 index 89ca3d48..00000000 --- a/docs/04_glossary/chain-of-custody.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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)) \ No newline at end of file diff --git a/docs/04_glossary/cigar.md b/docs/04_glossary/cigar.md deleted file mode 100644 index 5f1aad03..00000000 --- a/docs/04_glossary/cigar.md +++ /dev/null @@ -1,4 +0,0 @@ -# cigar -## Definition -An **_un_**[indexed signature](indexed-signature). -[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne \ No newline at end of file diff --git a/docs/04_glossary/claim.md b/docs/04_glossary/claim.md deleted file mode 100644 index 81fcfac6..00000000 --- a/docs/04_glossary/claim.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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)). \ No newline at end of file diff --git a/docs/04_glossary/clone.md b/docs/04_glossary/clone.md deleted file mode 100644 index fe6d5923..00000000 --- a/docs/04_glossary/clone.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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)) \ No newline at end of file diff --git a/docs/04_glossary/cloud-agent.md b/docs/04_glossary/cloud-agent.md deleted file mode 100644 index 94fe2494..00000000 --- a/docs/04_glossary/cloud-agent.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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](agent). - -## 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 \ No newline at end of file diff --git a/docs/04_glossary/code-table-selector.md b/docs/04_glossary/code-table-selector.md deleted file mode 100644 index f85c7cb2..00000000 --- a/docs/04_glossary/code-table-selector.md +++ /dev/null @@ -1,7 +0,0 @@ -# code table selector -## Definition -the first character in the text code of [CESR stream](composable-event-streaming-representation) that determines which [code table](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. - -## Selector code table -See row 1. - diff --git a/docs/04_glossary/code-table.md b/docs/04_glossary/code-table.md deleted file mode 100644 index 21f943e4..00000000 --- a/docs/04_glossary/code-table.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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 - - - -## CESR related -Multiple text and binary code tables exist to pre-pend characters before the respective stream parts to characterize ([self-framing](self-framing)) them or group them. \ No newline at end of file diff --git a/docs/04_glossary/cold-start-stream-parsing.md b/docs/04_glossary/cold-start-stream-parsing.md deleted file mode 100644 index 7b0949bb..00000000 --- a/docs/04_glossary/cold-start-stream-parsing.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/collective-signature.md b/docs/04_glossary/collective-signature.md deleted file mode 100644 index 4bd4401c..00000000 --- a/docs/04_glossary/collective-signature.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/collision.md b/docs/04_glossary/collision.md deleted file mode 100644 index c4209821..00000000 --- a/docs/04_glossary/collision.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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](namespace) or a given scope cannot be unambiguously resolved. -[Source Wikipedia](https://en.wikipedia.org/wiki/Naming_collision) - - - - diff --git a/docs/04_glossary/compact-variant.md b/docs/04_glossary/compact-variant.md deleted file mode 100644 index eacd4cc3..00000000 --- a/docs/04_glossary/compact-variant.md +++ /dev/null @@ -1,12 +0,0 @@ -# compact variant -## Definition -Either a [most compact](most-compact) version of an ACDC or the [fully compact](fully-compact) version of an ACDC. An [Issuer](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](top-level-section) is either the [SAD](SAD) or the [SAID](SAID) of the SAD of the associated section. - -## Relation -All the variants of an [ACDC](authentic-chained-data-container) 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)](fully-expanded) version of an ACDC -[Fully compact(ed)](fully-compact) version of an ACDC -[Most compact](most-compact) version of an ACDC. \ No newline at end of file diff --git a/docs/04_glossary/complementary-integrity-verification.md b/docs/04_glossary/complementary-integrity-verification.md deleted file mode 100644 index 555ae1b0..00000000 --- a/docs/04_glossary/complementary-integrity-verification.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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](key-event-log) that has been verified to its [root-of-trust](root-of-trust) 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](integrity) -[verified integrity](verified-integrity) \ No newline at end of file diff --git a/docs/04_glossary/composability.md b/docs/04_glossary/composability.md deleted file mode 100644 index a5eafa7e..00000000 --- a/docs/04_glossary/composability.md +++ /dev/null @@ -1,3 +0,0 @@ -# composability -## See -[Text binary concatenation composability](text-binary-concatenation-composability) \ No newline at end of file diff --git a/docs/04_glossary/composable-event-streaming-representation.md b/docs/04_glossary/composable-event-streaming-representation.md deleted file mode 100644 index a66c2e72..00000000 --- a/docs/04_glossary/composable-event-streaming-representation.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](composability) 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. - diff --git a/docs/04_glossary/composable.md b/docs/04_glossary/composable.md deleted file mode 100644 index 7c8b5de4..00000000 --- a/docs/04_glossary/composable.md +++ /dev/null @@ -1,3 +0,0 @@ -# composable -## See -[Composability](composable) \ No newline at end of file diff --git a/docs/04_glossary/concatenation.md b/docs/04_glossary/concatenation.md deleted file mode 100644 index a69822ab..00000000 --- a/docs/04_glossary/concatenation.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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](composability); it is associative and may be applied to any two [primitives](primitive) 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](self-framing) property of the primitives enables de-concatenation. - diff --git a/docs/04_glossary/concise-binary-object-representation.md b/docs/04_glossary/concise-binary-object-representation.md deleted file mode 100644 index 5ebd1771..00000000 --- a/docs/04_glossary/concise-binary-object-representation.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/confidentiality.md b/docs/04_glossary/confidentiality.md deleted file mode 100644 index 3667a205..00000000 --- a/docs/04_glossary/confidentiality.md +++ /dev/null @@ -1,20 +0,0 @@ -# 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](authenticity) -- [privacy](privacy) - diff --git a/docs/04_glossary/configuration-files.md b/docs/04_glossary/configuration-files.md deleted file mode 100644 index ef55ec88..00000000 --- a/docs/04_glossary/configuration-files.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/configuration-traits.md b/docs/04_glossary/configuration-traits.md deleted file mode 100644 index c1714817..00000000 --- a/docs/04_glossary/configuration-traits.md +++ /dev/null @@ -1,4 +0,0 @@ -# configuration traits -## Definition - -A list of specially defined strings representing a configuration of a [KEL](key-event-log). diff --git a/docs/04_glossary/consensus-mechanism.md b/docs/04_glossary/consensus-mechanism.md deleted file mode 100644 index 1f0c70a9..00000000 --- a/docs/04_glossary/consensus-mechanism.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/content-addressable-hash.md b/docs/04_glossary/content-addressable-hash.md deleted file mode 100644 index 43bd2e7e..00000000 --- a/docs/04_glossary/content-addressable-hash.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/contextual-linkability.md b/docs/04_glossary/contextual-linkability.md deleted file mode 100644 index a08e556c..00000000 --- a/docs/04_glossary/contextual-linkability.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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](contractually-protected-disclosure) 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/ \ No newline at end of file diff --git a/docs/04_glossary/contingent-disclosure.md b/docs/04_glossary/contingent-disclosure.md deleted file mode 100644 index d0a4194f..00000000 --- a/docs/04_glossary/contingent-disclosure.md +++ /dev/null @@ -1,5 +0,0 @@ -# contingent disclosure -## Definition -[Chain link confidentiality](chain-link-confidentiality) is a form of contingent disclosure. - -| TBW prio 1 | diff --git a/docs/04_glossary/contractually-protected-disclosure.md b/docs/04_glossary/contractually-protected-disclosure.md deleted file mode 100644 index f0ce1168..00000000 --- a/docs/04_glossary/contractually-protected-disclosure.md +++ /dev/null @@ -1,16 +0,0 @@ -# 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](IPEX). Contractually protected disclosure includes both [chain-link confidential](chain-link-confidentiality) and [contingent disclosure](contingent-disclosure). -Paraphrased by @henkvancann based on [source](https://github.com/WebOfTrust/ietf-ipex/blob/main/draft-ssmith-ipex.md#discussion) - -## Relation -This [IPEX](IPEX) protocol leverages important features of [ACDC](ACDC)s and ancillary protocols such as [CESR](CESR), [SAID](SAID)s, and [CESR-Proofs](cesr-proof-signatures) as well as [Ricardian contract](ricardian-contract)s and graduated disclosure (partial, selective, full) to enable contractually protected disclosure. Contractually protected disclosure includes both [chain-link confidential](chain-link confidential) and [contingent disclosure](contingent disclosure). - -## Rule -The disclosure performed by a presentation exchange MAY be [graduated](graduated-disclosure) and MAY be [contractually](contractually-protected-disclosure) protected. \ No newline at end of file diff --git a/docs/04_glossary/control-authority.md b/docs/04_glossary/control-authority.md deleted file mode 100644 index 8f024e9f..00000000 --- a/docs/04_glossary/control-authority.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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](keripy) two [rotations](rotation-event) 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](digest). 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](dual-indexed-codes) in CESR. \ No newline at end of file diff --git a/docs/04_glossary/controller.md b/docs/04_glossary/controller.md deleted file mode 100644 index 970f98a2..00000000 --- a/docs/04_glossary/controller.md +++ /dev/null @@ -1,10 +0,0 @@ -# controller -## Definition - -A controller is a controlling entity (person, organization, or autonomous software) of an identifier. For an [autonomic identifier (AID)](autonomic-identifier), a controlling entity has the capability to make changes to the [key event log (KEL)](key-event-log) 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](key-event) 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)](multisig). 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](custodial-rotation), the controller grants a designated custodial agent the signing authority while retaining their rotation authority. In the case of a [delegated identifier](delegated-identifier), the delegated identifier is granted some degree of control authority from its delegating identifier. \ No newline at end of file diff --git a/docs/04_glossary/cooperative-delegation.md b/docs/04_glossary/cooperative-delegation.md deleted file mode 100644 index 9dc8c4db..00000000 --- a/docs/04_glossary/cooperative-delegation.md +++ /dev/null @@ -1,5 +0,0 @@ -# cooperative delegation -## Definition -The way KERI addresses the [security-cost-performance architecture trade-off](security-cost-performance-architecture-trade-off) is via [delegation](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. - -Source [Universal Identifier Theory](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) by Samuel Smith \ No newline at end of file diff --git a/docs/04_glossary/coroutines.md b/docs/04_glossary/coroutines.md deleted file mode 100644 index ccae884b..00000000 --- a/docs/04_glossary/coroutines.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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) diff --git a/docs/04_glossary/correlation.md b/docs/04_glossary/correlation.md deleted file mode 100644 index 68186bf0..00000000 --- a/docs/04_glossary/correlation.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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." \ No newline at end of file diff --git a/docs/04_glossary/count-code.md b/docs/04_glossary/count-code.md deleted file mode 100644 index 6d63b23b..00000000 --- a/docs/04_glossary/count-code.md +++ /dev/null @@ -1,3 +0,0 @@ -# count code -## See -[Group framing code](group-framing-code) \ No newline at end of file diff --git a/docs/04_glossary/credential.md b/docs/04_glossary/credential.md deleted file mode 100644 index d3e0e98e..00000000 --- a/docs/04_glossary/credential.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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. diff --git a/docs/04_glossary/crypto-libraries.md b/docs/04_glossary/crypto-libraries.md deleted file mode 100644 index 5b159521..00000000 --- a/docs/04_glossary/crypto-libraries.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/cryptocurrency.md b/docs/04_glossary/cryptocurrency.md deleted file mode 100644 index 45d99145..00000000 --- a/docs/04_glossary/cryptocurrency.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/cryptographic-commitment-scheme.md b/docs/04_glossary/cryptographic-commitment-scheme.md deleted file mode 100644 index 3cc49ada..00000000 --- a/docs/04_glossary/cryptographic-commitment-scheme.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/cryptographic-primitive.md b/docs/04_glossary/cryptographic-primitive.md deleted file mode 100644 index c36c89f9..00000000 --- a/docs/04_glossary/cryptographic-primitive.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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](composable-event-streaming-representation). - -## See also -The more general term [primitive](primitive). diff --git a/docs/04_glossary/cryptographic-strength.md b/docs/04_glossary/cryptographic-strength.md deleted file mode 100644 index f4fecf44..00000000 --- a/docs/04_glossary/cryptographic-strength.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/cryptonym.md b/docs/04_glossary/cryptonym.md deleted file mode 100644 index c3f6f3ee..00000000 --- a/docs/04_glossary/cryptonym.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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](cryptographic-strength). A cryptonym is a type of primitive. -Due the [entropy](entropy) in its derivation, a cryptonym is a universally unique identifier and only the [controller](controller) of the secret [salt](salt) or [seed](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.\ -Source [Smith, ietf-keri draft](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md) - diff --git a/docs/04_glossary/custodial-agent.md b/docs/04_glossary/custodial-agent.md deleted file mode 100644 index c70c7926..00000000 --- a/docs/04_glossary/custodial-agent.md +++ /dev/null @@ -1,11 +0,0 @@ -# custodial agent -## Definition -An [agent](agent) owned by an individual who has granted [signing authority](signing-authority) to a custodian who is usually also the host of the running agent software. Using [partial rotation](partial-rotation) to facilitate custodial key management the owner of the identifier retains [rotational authority](rotation-authority) 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](digital-signature) 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](key-management) 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. - diff --git a/docs/04_glossary/custodial-rotation.md b/docs/04_glossary/custodial-rotation.md deleted file mode 100644 index 944c0e9b..00000000 --- a/docs/04_glossary/custodial-rotation.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](partial-rotation) supports the important use case that of custodial key rotation to authorize a [custodial agent](custodial-agent). -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. diff --git a/docs/04_glossary/data-anchor.md b/docs/04_glossary/data-anchor.md deleted file mode 100644 index 0ec33541..00000000 --- a/docs/04_glossary/data-anchor.md +++ /dev/null @@ -1,12 +0,0 @@ -# data anchor -## Definition -Data anchors are [digests](digest) 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](self-addressing-data) are a type of data anchors. - -## Beware -[Link anchors](https://en.wikipedia.org/wiki/Hyperlink#Anchor_links) are a totally different concepts. \ No newline at end of file diff --git a/docs/04_glossary/dead-attack.md b/docs/04_glossary/dead-attack.md deleted file mode 100644 index d7a48f5f..00000000 --- a/docs/04_glossary/dead-attack.md +++ /dev/null @@ -1,6 +0,0 @@ -# dead attack -## Definition -A Dead-Attack is an attack on an [establishment event](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. - -## Also see -Security Properties of [Pre-rotation](Pre-rotation) \ No newline at end of file diff --git a/docs/04_glossary/dead-drop.md b/docs/04_glossary/dead-drop.md deleted file mode 100644 index 7bac22ac..00000000 --- a/docs/04_glossary/dead-drop.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/decentralized-identifier.md b/docs/04_glossary/decentralized-identifier.md deleted file mode 100644 index 9752fbfe..00000000 --- a/docs/04_glossary/decentralized-identifier.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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. diff --git a/docs/04_glossary/decentralized-identity.md b/docs/04_glossary/decentralized-identity.md deleted file mode 100644 index e47efbb2..00000000 --- a/docs/04_glossary/decentralized-identity.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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`. \ No newline at end of file diff --git a/docs/04_glossary/decentralized-key-management-infrastructure.md b/docs/04_glossary/decentralized-key-management-infrastructure.md deleted file mode 100644 index a190813c..00000000 --- a/docs/04_glossary/decentralized-key-management-infrastructure.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/delegated-identifier.md b/docs/04_glossary/delegated-identifier.md deleted file mode 100644 index e657faa2..00000000 --- a/docs/04_glossary/delegated-identifier.md +++ /dev/null @@ -1,14 +0,0 @@ -# delegated identifier -## Definition - -Matches the act of [delegation](delegation) 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](transferable-identifier) -- [non-transferable identifiers](non-transferable-identifier) -- delegated identifiers \ No newline at end of file diff --git a/docs/04_glossary/delegation.md b/docs/04_glossary/delegation.md deleted file mode 100644 index 74457472..00000000 --- a/docs/04_glossary/delegation.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/derivation-code.md b/docs/04_glossary/derivation-code.md deleted file mode 100644 index eb94014a..00000000 --- a/docs/04_glossary/derivation-code.md +++ /dev/null @@ -1,24 +0,0 @@ -# derivation code -## Definition - -To properly extract and use the [public key](public-key-infrastructure) embedded in a [self-certifying identifier](self-certifying-identifier) we need to know the cryptographic _signing scheme_ used by the [key pair](key-pair). 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](qualified) 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. diff --git a/docs/04_glossary/designated-aliases.md b/docs/04_glossary/designated-aliases.md deleted file mode 100644 index 860c8e04..00000000 --- a/docs/04_glossary/designated-aliases.md +++ /dev/null @@ -1,4 +0,0 @@ -# designated aliases -## Definition - -An AID controller can designate aliases which are AID controlled identifiers such as a did:keri, did:webs, etc. The [AID](AID) 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) \ No newline at end of file diff --git a/docs/04_glossary/designated-authorized-representative.md b/docs/04_glossary/designated-authorized-representative.md deleted file mode 100644 index 28439f53..00000000 --- a/docs/04_glossary/designated-authorized-representative.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](authorized-vlei-representative)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. \ No newline at end of file diff --git a/docs/04_glossary/diger.md b/docs/04_glossary/diger.md deleted file mode 100644 index d2f9720e..00000000 --- a/docs/04_glossary/diger.md +++ /dev/null @@ -1,4 +0,0 @@ -# diger -## Definition -A _primitive_ that represents a [digest](digest). It has the ability to [verify](verify) that an input hashes to its raw value. -[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne \ No newline at end of file diff --git a/docs/04_glossary/digest.md b/docs/04_glossary/digest.md deleted file mode 100644 index d80a13a6..00000000 --- a/docs/04_glossary/digest.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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)](authentic-chained-data-container) 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. \ No newline at end of file diff --git a/docs/04_glossary/digital-signature.md b/docs/04_glossary/digital-signature.md deleted file mode 100644 index f8990884..00000000 --- a/docs/04_glossary/digital-signature.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](electronic-signature), the latter are quite different in purpose and practical use. diff --git a/docs/04_glossary/dip.md b/docs/04_glossary/dip.md deleted file mode 100644 index cc25c3a5..00000000 --- a/docs/04_glossary/dip.md +++ /dev/null @@ -1,3 +0,0 @@ -# dip -## Definition -dip = delcept, delegated inception \ No newline at end of file diff --git a/docs/04_glossary/direct-mode.md b/docs/04_glossary/direct-mode.md deleted file mode 100644 index 5821be3d..00000000 --- a/docs/04_glossary/direct-mode.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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](key-event-receipt-log)s, but has direct (albeit intermittent) network contact with the validator. - -## Operational mode -To protect a [validator](validator) when engaging with some other controller’s identifier, be it [verification](verification), control authority establishment, or [duplicity](duplicity) 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](indirect-mode) \ No newline at end of file diff --git a/docs/04_glossary/directed-acyclic-graph.md b/docs/04_glossary/directed-acyclic-graph.md deleted file mode 100644 index a8cbce6a..00000000 --- a/docs/04_glossary/directed-acyclic-graph.md +++ /dev/null @@ -1,24 +0,0 @@ -# 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) - -## 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). \ No newline at end of file diff --git a/docs/04_glossary/disclosee.md b/docs/04_glossary/disclosee.md deleted file mode 100644 index 712861eb..00000000 --- a/docs/04_glossary/disclosee.md +++ /dev/null @@ -1,4 +0,0 @@ -# disclosee -## Definition -an ACDC in a disclosure is disclosed to the Disclosee - diff --git a/docs/04_glossary/discloser.md b/docs/04_glossary/discloser.md deleted file mode 100644 index 717570bb..00000000 --- a/docs/04_glossary/discloser.md +++ /dev/null @@ -1,3 +0,0 @@ -# discloser -## Definition -An [ACDC](authentic-chained-data-container) in a disclosure is disclosed by the Discloser. \ No newline at end of file diff --git a/docs/04_glossary/discovery.md b/docs/04_glossary/discovery.md deleted file mode 100644 index 934502af..00000000 --- a/docs/04_glossary/discovery.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](percolated-information-discovery) \ No newline at end of file diff --git a/docs/04_glossary/distributed-hash-table.md b/docs/04_glossary/distributed-hash-table.md deleted file mode 100644 index acfa0c82..00000000 --- a/docs/04_glossary/distributed-hash-table.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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)) \ No newline at end of file diff --git a/docs/04_glossary/dnd.md b/docs/04_glossary/dnd.md deleted file mode 100644 index 721aa777..00000000 --- a/docs/04_glossary/dnd.md +++ /dev/null @@ -1,5 +0,0 @@ -# dnd -## Definition -Do Not Delegate is a flag / attribute for a AID and this is default set to you can delegate. - -| TBW | diff --git a/docs/04_glossary/domain-name.md b/docs/04_glossary/domain-name.md deleted file mode 100644 index 4f429058..00000000 --- a/docs/04_glossary/domain-name.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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). diff --git a/docs/04_glossary/domain.md b/docs/04_glossary/domain.md deleted file mode 100644 index 85300ce5..00000000 --- a/docs/04_glossary/domain.md +++ /dev/null @@ -1,3 +0,0 @@ -# domain -## See -[Trust domain](trust-domain) and / or [Domain name](domain-name) \ No newline at end of file diff --git a/docs/04_glossary/double-spend-proof.md b/docs/04_glossary/double-spend-proof.md deleted file mode 100644 index bedf3eb1..00000000 --- a/docs/04_glossary/double-spend-proof.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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](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. The two halves are the *promulgation* half (by witnesses) and the *confirmation* half (by valdators). \ No newline at end of file diff --git a/docs/04_glossary/drt.md b/docs/04_glossary/drt.md deleted file mode 100644 index 9807aed2..00000000 --- a/docs/04_glossary/drt.md +++ /dev/null @@ -1,3 +0,0 @@ -# drt -## Definition -drt = deltate, delegated rotation diff --git a/docs/04_glossary/dual-indexed-codes.md b/docs/04_glossary/dual-indexed-codes.md deleted file mode 100644 index b888e508..00000000 --- a/docs/04_glossary/dual-indexed-codes.md +++ /dev/null @@ -1,9 +0,0 @@ -# dual indexed codes -## Definition -a context-specific coding scheme, for the common use case of thresholded multi-signature schemes in [CESR](CESR). - -## 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) \ No newline at end of file diff --git a/docs/04_glossary/dual-text-binary-encoding-format.md b/docs/04_glossary/dual-text-binary-encoding-format.md deleted file mode 100644 index 5c7f65b6..00000000 --- a/docs/04_glossary/dual-text-binary-encoding-format.md +++ /dev/null @@ -1,8 +0,0 @@ -# dual text binary encoding format -## Definition -An encoding format that allows for both text and binary encoding format, which is fully interchangeable. The [composability](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. -Read more in [source](https://github.com/trustoverip/tswg-cesr-specification/blob/main/draft-ssmith-cesr.md) of Samuel Smith - -## Related -- [CESR](CESR) -- [composability](composability) \ No newline at end of file diff --git a/docs/04_glossary/duplicitous-event-log.md b/docs/04_glossary/duplicitous-event-log.md deleted file mode 100644 index b239ea3f..00000000 --- a/docs/04_glossary/duplicitous-event-log.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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](key-event-receipt-log). 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](inconsistency) event messages with respect to a KERL. Each [juror](juror) keeps a duplicitous event log (DEL) for each [controller](controller) and all designated witness with respect to a KERL. Any [validator](validator) may confirm [duplicity](duplicity) by examining a DEL. \ No newline at end of file diff --git a/docs/04_glossary/duplicity-detection.md b/docs/04_glossary/duplicity-detection.md deleted file mode 100644 index 2657eba9..00000000 --- a/docs/04_glossary/duplicity-detection.md +++ /dev/null @@ -1,7 +0,0 @@ -# duplicity detection -## Definition - -A mechanism to detect [duplicity](duplicity) in cryptographically secured event logs. - -## KERI related -Duplicity detection, which protects, *not against an external attacker*, but against a malicious [controller](controller) does require access to [watchers](watcher) that are also recording duplicitous events. diff --git a/docs/04_glossary/duplicity.md b/docs/04_glossary/duplicity.md deleted file mode 100644 index e62b5584..00000000 --- a/docs/04_glossary/duplicity.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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](inconsistency) 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'. \ No newline at end of file diff --git a/docs/04_glossary/eclipse-attack.md b/docs/04_glossary/eclipse-attack.md deleted file mode 100644 index 9839291a..00000000 --- a/docs/04_glossary/eclipse-attack.md +++ /dev/null @@ -1,17 +0,0 @@ -# eclipse attack -## Definition -An eclipse attack is a [P2P](peer-to-peer) 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 - diff --git a/docs/04_glossary/electronic-signature.md b/docs/04_glossary/electronic-signature.md deleted file mode 100644 index b2b5ae8c..00000000 --- a/docs/04_glossary/electronic-signature.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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](digital-signature), 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. - diff --git a/docs/04_glossary/encrypt-sender-sign-receiver.md b/docs/04_glossary/encrypt-sender-sign-receiver.md deleted file mode 100644 index 909a6a4b..00000000 --- a/docs/04_glossary/encrypt-sender-sign-receiver.md +++ /dev/null @@ -1,3 +0,0 @@ -# encrypt sender sign receiver -## Definition -An authenticated encryption approach, using [PKI](PKI). It covers [authenticity](authenticity) and [confidentiality](confidentiality). diff --git a/docs/04_glossary/end-role.md b/docs/04_glossary/end-role.md deleted file mode 100644 index e81dbeaf..00000000 --- a/docs/04_glossary/end-role.md +++ /dev/null @@ -1,7 +0,0 @@ -# end role -## Definition -An end role is an authorization for one [AID](AID) to serve in a role for another [AID](AID). - -For example, declaring that your [Agent](agent) [AID](AID) is serving in the role of [Agent](agent) for your business AIDs. - -Source: Phil Feairheller \ No newline at end of file diff --git a/docs/04_glossary/end-to-end.md b/docs/04_glossary/end-to-end.md deleted file mode 100644 index 67aba389..00000000 --- a/docs/04_glossary/end-to-end.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/end-verifiable.md b/docs/04_glossary/end-verifiable.md deleted file mode 100644 index 8d9f0e80..00000000 --- a/docs/04_glossary/end-verifiable.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/engagement-context-role.md b/docs/04_glossary/engagement-context-role.md deleted file mode 100644 index e38ec53e..00000000 --- a/docs/04_glossary/engagement-context-role.md +++ /dev/null @@ -1,6 +0,0 @@ -# engagement context role -## Definition -A person that represents the [Legal Entity](legal-entity) in a functional or in another context role and is issued an ECR [vLEI Credential](vlei-credential). - -## Issuance of credentials -On the basis of [Legal entity engagement context role vLEI credential governance framework](legal-entity-engagement-context-role-vlei-credential-governance-framework) an ECR [vLEI Credential](vlei-credential) is **issued to** an engagement context role (ECR). diff --git a/docs/04_glossary/entity.md b/docs/04_glossary/entity.md deleted file mode 100644 index cca7e2ce..00000000 --- a/docs/04_glossary/entity.md +++ /dev/null @@ -1,3 +0,0 @@ -# entity -## See -[entity](https://trustoverip.github.io/essiflab/glossary#entity) in the **#essiflab** glossary. \ No newline at end of file diff --git a/docs/04_glossary/entropy.md b/docs/04_glossary/entropy.md deleted file mode 100644 index ebd182cb..00000000 --- a/docs/04_glossary/entropy.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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_. - - - - \ No newline at end of file diff --git a/docs/04_glossary/ephemeral.md b/docs/04_glossary/ephemeral.md deleted file mode 100644 index 7e8c90a0..00000000 --- a/docs/04_glossary/ephemeral.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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. - diff --git a/docs/04_glossary/escrow-state.md b/docs/04_glossary/escrow-state.md deleted file mode 100644 index 8e273c68..00000000 --- a/docs/04_glossary/escrow-state.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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. diff --git a/docs/04_glossary/escrow.md b/docs/04_glossary/escrow.md deleted file mode 100644 index e6d9f59a..00000000 --- a/docs/04_glossary/escrow.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/establishment-event.md b/docs/04_glossary/establishment-event.md deleted file mode 100644 index 88336ef3..00000000 --- a/docs/04_glossary/establishment-event.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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](key-event-log) (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) diff --git a/docs/04_glossary/exn.md b/docs/04_glossary/exn.md deleted file mode 100644 index 4e95bdbb..00000000 --- a/docs/04_glossary/exn.md +++ /dev/null @@ -1,3 +0,0 @@ -# exn -## Definition -exn = exchange diff --git a/docs/04_glossary/exp.md b/docs/04_glossary/exp.md deleted file mode 100644 index 3965b5c1..00000000 --- a/docs/04_glossary/exp.md +++ /dev/null @@ -1,3 +0,0 @@ -# exp -## Definition -exp = expose, sealed data exposition diff --git a/docs/04_glossary/extensible-business-reporting-language.md b/docs/04_glossary/extensible-business-reporting-language.md deleted file mode 100644 index 7e2a6271..00000000 --- a/docs/04_glossary/extensible-business-reporting-language.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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/) diff --git a/docs/04_glossary/field-map.md b/docs/04_glossary/field-map.md deleted file mode 100644 index 1ea5e1ce..00000000 --- a/docs/04_glossary/field-map.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/first-seen.md b/docs/04_glossary/first-seen.md deleted file mode 100644 index 6b04ad98..00000000 --- a/docs/04_glossary/first-seen.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/foreign-function-interface.md b/docs/04_glossary/foreign-function-interface.md deleted file mode 100644 index a8b7baf2..00000000 --- a/docs/04_glossary/foreign-function-interface.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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 - -## Relevance in CESR -To have the output from RUST-based developed (e.g. cesride) consumed by higher level languages. diff --git a/docs/04_glossary/frame-code.md b/docs/04_glossary/frame-code.md deleted file mode 100644 index 4dac73ac..00000000 --- a/docs/04_glossary/frame-code.md +++ /dev/null @@ -1,3 +0,0 @@ -# frame code -## See -[Group framing code](group-framing-code) \ No newline at end of file diff --git a/docs/04_glossary/full-disclosure.md b/docs/04_glossary/full-disclosure.md deleted file mode 100644 index 84ade0cb..00000000 --- a/docs/04_glossary/full-disclosure.md +++ /dev/null @@ -1,5 +0,0 @@ -# full disclosure -## Definition -A disclosure of data in all its details. - -When used in the context of [selective disclosure](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](partial-disclosure), full disclosure means _detailed disclosure of the [field map](field-map)_ that was so far only partially disclosed. \ No newline at end of file diff --git a/docs/04_glossary/fully-compact.md b/docs/04_glossary/fully-compact.md deleted file mode 100644 index bf8a7936..00000000 --- a/docs/04_glossary/fully-compact.md +++ /dev/null @@ -1,18 +0,0 @@ -# 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](most-compact) version is the anchoring to the [Tranaction event log](transaction-event-log). Here were various proofs ([hashes](distributed-hash-table)) can be "stored" which are optional in all kind of [ACDC](ACDC) variants. - -## See -[Fully (expanded)](fully-expanded) version of an ACDC -[Most compact](most-compact) 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](SAID) 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. - diff --git a/docs/04_glossary/fully-expanded.md b/docs/04_glossary/fully-expanded.md deleted file mode 100644 index ecbcf676..00000000 --- a/docs/04_glossary/fully-expanded.md +++ /dev/null @@ -1,10 +0,0 @@ -# fully expanded -## Definition -The most user-friendly version of an [ACDC](ACDC) 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](TEL) 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)](fully-compact) version of an ACDC -[Most compact](most-compact) version of an ACDC. \ No newline at end of file diff --git a/docs/04_glossary/ghost-credential.md b/docs/04_glossary/ghost-credential.md deleted file mode 100644 index 4c4a8295..00000000 --- a/docs/04_glossary/ghost-credential.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](QVI) and the QVI has not revoked their credentials (yet) then those credentials become ghost credentials. - - diff --git a/docs/04_glossary/gleif-authorized-representative.md b/docs/04_glossary/gleif-authorized-representative.md deleted file mode 100644 index 6de8949b..00000000 --- a/docs/04_glossary/gleif-authorized-representative.md +++ /dev/null @@ -1,6 +0,0 @@ -# gleif authorized representative -## Definition -A representative of GLEIF authorized to perform the identity verifications requirements needed to issue the [QVI](QVI) [vLEI](vLEI) 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) - diff --git a/docs/04_glossary/gnu-privacy-guard.md b/docs/04_glossary/gnu-privacy-guard.md deleted file mode 100644 index bc2175e5..00000000 --- a/docs/04_glossary/gnu-privacy-guard.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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](PGP). \ No newline at end of file diff --git a/docs/04_glossary/governance-framework.md b/docs/04_glossary/governance-framework.md deleted file mode 100644 index ade4169c..00000000 --- a/docs/04_glossary/governance-framework.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/graduated-disclosure.md b/docs/04_glossary/graduated-disclosure.md deleted file mode 100644 index 434ddb74..00000000 --- a/docs/04_glossary/graduated-disclosure.md +++ /dev/null @@ -1,24 +0,0 @@ -# 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](compact-variant)) Issuer commitment verifiability as an essential property. It supports graduated disclosure by the [Disclosee](disclosee) 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](SAID) of a given variant is useful even when it is not the SAID of the variant the [Issuer](issuer) signed because during graduated disclosure the [Discloser](discloser) 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](graduated-disclosure) and MAY be [contractually](contractually-protected-disclosure) 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 \ No newline at end of file diff --git a/docs/04_glossary/graph-fragment.md b/docs/04_glossary/graph-fragment.md deleted file mode 100644 index f78ae380..00000000 --- a/docs/04_glossary/graph-fragment.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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. - - \ No newline at end of file diff --git a/docs/04_glossary/group-code.md b/docs/04_glossary/group-code.md deleted file mode 100644 index 4f483cda..00000000 --- a/docs/04_glossary/group-code.md +++ /dev/null @@ -1,3 +0,0 @@ -# group code -## See -[Group framing code](group-framing-code) \ No newline at end of file diff --git a/docs/04_glossary/group-framing-code.md b/docs/04_glossary/group-framing-code.md deleted file mode 100644 index 2720bb1f..00000000 --- a/docs/04_glossary/group-framing-code.md +++ /dev/null @@ -1,8 +0,0 @@ -# group framing code -## Definition -special framing codes can be specified to support groups of [primitives](primitive) in [CESR](composable-event-streaming-representation). Grouping enables [pipelining](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.\ -[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. - diff --git a/docs/04_glossary/hab.md b/docs/04_glossary/hab.md deleted file mode 100644 index d94c3676..00000000 --- a/docs/04_glossary/hab.md +++ /dev/null @@ -1,6 +0,0 @@ -# hab -## Definition - -A Hab is a keystore for one identifier. The Python implementation in [KERIpy](keripy), also used by [KERIA](keria) 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](habery). \ No newline at end of file diff --git a/docs/04_glossary/habery.md b/docs/04_glossary/habery.md deleted file mode 100644 index 1cbe276a..00000000 --- a/docs/04_glossary/habery.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/hardware-security-module.md b/docs/04_glossary/hardware-security-module.md deleted file mode 100644 index 8ba03854..00000000 --- a/docs/04_glossary/hardware-security-module.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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](authenticity) and other cryptographic functions. -More in source [Wikipedia](https://en.wikipedia.org/wiki/Hardware_security_module) \ No newline at end of file diff --git a/docs/04_glossary/hierarchical-asynchronous-coroutines-and-input-output.md b/docs/04_glossary/hierarchical-asynchronous-coroutines-and-input-output.md deleted file mode 100644 index 78affa61..00000000 --- a/docs/04_glossary/hierarchical-asynchronous-coroutines-and-input-output.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/hierarchical-composition.md b/docs/04_glossary/hierarchical-composition.md deleted file mode 100644 index e1406a4a..00000000 --- a/docs/04_glossary/hierarchical-composition.md +++ /dev/null @@ -1,9 +0,0 @@ -# hierarchical composition -## Definition -Encoding protocol that is composable in a hierarchy and enables [pipelining](pipelining) (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](count-code) and the [composability](composability) - and [concatenation](concatenation) property in CESR, [pipelining](pipelining) is possible, which then uses [multiplexing](multiplexing) (combining [self-framing](self-framing) primitives) and _de-multiplexing_ (unravelling self-framing [primitives](primitive)). \ No newline at end of file diff --git a/docs/04_glossary/hierchical-deterministic-keys.md b/docs/04_glossary/hierchical-deterministic-keys.md deleted file mode 100644 index e76ddd74..00000000 --- a/docs/04_glossary/hierchical-deterministic-keys.md +++ /dev/null @@ -1,4 +0,0 @@ -# hierchical deterministic keys -## Definition -A HDK type is a type of deterministic bitcoin wallet derived from a known [seed](seed), 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) \ No newline at end of file diff --git a/docs/04_glossary/hio.md b/docs/04_glossary/hio.md deleted file mode 100644 index 62b30df2..00000000 --- a/docs/04_glossary/hio.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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. diff --git a/docs/04_glossary/icp.md b/docs/04_glossary/icp.md deleted file mode 100644 index 0b4137ad..00000000 --- a/docs/04_glossary/icp.md +++ /dev/null @@ -1,3 +0,0 @@ -# icp -## Definition -icp = incept, inception \ No newline at end of file diff --git a/docs/04_glossary/identifier-system.md b/docs/04_glossary/identifier-system.md deleted file mode 100644 index 5558dd7c..00000000 --- a/docs/04_glossary/identifier-system.md +++ /dev/null @@ -1,31 +0,0 @@ -# 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) - diff --git a/docs/04_glossary/identifier.md b/docs/04_glossary/identifier.md deleted file mode 100644 index 6b841c15..00000000 --- a/docs/04_glossary/identifier.md +++ /dev/null @@ -1,3 +0,0 @@ -# identifier -## Definition -Something to uniquely identify (public) identities; pointing to something or someone else. \ No newline at end of file diff --git a/docs/04_glossary/identity-assurance.md b/docs/04_glossary/identity-assurance.md deleted file mode 100644 index a37f120e..00000000 --- a/docs/04_glossary/identity-assurance.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](GLEIF). Instead, KERI is for [attributional trust](attributional-trust). 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](out-of-band-introduction)s (OOBIs) to establish attributional trust, which is done with KERI. \ No newline at end of file diff --git a/docs/04_glossary/identity.md b/docs/04_glossary/identity.md deleted file mode 100644 index f878be02..00000000 --- a/docs/04_glossary/identity.md +++ /dev/null @@ -1,3 +0,0 @@ -# identity -## Definition -A unique entity. Typically represented by a unique [identifier](identifier). \ No newline at end of file diff --git a/docs/04_glossary/inception-event.md b/docs/04_glossary/inception-event.md deleted file mode 100644 index b448fca4..00000000 --- a/docs/04_glossary/inception-event.md +++ /dev/null @@ -1,22 +0,0 @@ -# inception event -## Definition -An inception event is an establishment key event that represents the creation operation of an -identifier including its derivation and its initial set of controlling keys as well as other inception -or configuration data for supporting infrastructure. -This is the information needed to derive an [AID](AID) 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 - -**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_) diff --git a/docs/04_glossary/inception.md b/docs/04_glossary/inception.md deleted file mode 100644 index 20431955..00000000 --- a/docs/04_glossary/inception.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) diff --git a/docs/04_glossary/inconsistency.md b/docs/04_glossary/inconsistency.md deleted file mode 100644 index 5ffeb7f6..00000000 --- a/docs/04_glossary/inconsistency.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](key-event-log) can be internally _inconsistent_ which is a clear indication that this data structure is not [verifiable](verifiable). \ No newline at end of file diff --git a/docs/04_glossary/indexed-signature.md b/docs/04_glossary/indexed-signature.md deleted file mode 100644 index b6f5e615..00000000 --- a/docs/04_glossary/indexed-signature.md +++ /dev/null @@ -1,19 +0,0 @@ -# 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](qualified) [base64](base64). 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](witness) signatures can also be attached as indexed signatures. So a verifier can determine which witness signed a particular [receipt](receipt). This is useful when witnesses are receipting an event and only attaching their own signature. The [controller](controller) knows which witness signed the receipt by looking up the index in their list of witnesses for that event. -Source:Philip Feairheller - - diff --git a/docs/04_glossary/indirect-mode.md b/docs/04_glossary/indirect-mode.md deleted file mode 100644 index fdd7606e..00000000 --- a/docs/04_glossary/indirect-mode.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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](key-event-receipt-log)) for validating events. The security and accountability guarantees of indirect mode are provided by [KA2CE](KA2CE) 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](validator) when engaging with some other controller’s identifier, be it [verification](verification), control authority establishment, or [duplicity](duplicity) 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](controller) is not attached to the network and therefore not able to communicate directly with a [validator](validator). 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](direct-mode) diff --git a/docs/04_glossary/input-output.md b/docs/04_glossary/input-output.md deleted file mode 100644 index 9863188c..00000000 --- a/docs/04_glossary/input-output.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/inquisitor.md b/docs/04_glossary/inquisitor.md deleted file mode 100644 index f3734557..00000000 --- a/docs/04_glossary/inquisitor.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](witness). - -## 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) \ No newline at end of file diff --git a/docs/04_glossary/integrity.md b/docs/04_glossary/integrity.md deleted file mode 100644 index 04294bbf..00000000 --- a/docs/04_glossary/integrity.md +++ /dev/null @@ -1,31 +0,0 @@ -# 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](internal-inconsistency) -2. external consistency or [duplicity](duplicity) evident - -Integrity in ACDCs is "self-verifying": the [SAID](self-addressing-identifier) that is contained in the data is also the of hash of the data. - -The integrity of streaming data in [CESR](composable-event-streaming-representation) and [CESR proof signatures](cesr-proof-signatures) is established by code tables and verifiable by the mere (killer-)feature: round-robin [composability](composability). 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](non-repudiable) - 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](validate)* 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](verified-integrity) -[(complementary) integrity verification](complementary-integrity-verification) - -*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. diff --git a/docs/04_glossary/interaction-event.md b/docs/04_glossary/interaction-event.md deleted file mode 100644 index 67a773fe..00000000 --- a/docs/04_glossary/interaction-event.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/interactive-authentication-design.md b/docs/04_glossary/interactive-authentication-design.md deleted file mode 100644 index 30417463..00000000 --- a/docs/04_glossary/interactive-authentication-design.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](non-interactive-authentication-design) \ No newline at end of file diff --git a/docs/04_glossary/interceptor.md b/docs/04_glossary/interceptor.md deleted file mode 100644 index f6864cf1..00000000 --- a/docs/04_glossary/interceptor.md +++ /dev/null @@ -1,7 +0,0 @@ -# interceptor -## Definition -a [keria](keria) 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 \ No newline at end of file diff --git a/docs/04_glossary/interleaved-serialisation.md b/docs/04_glossary/interleaved-serialisation.md deleted file mode 100644 index 7df4a884..00000000 --- a/docs/04_glossary/interleaved-serialisation.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](distributed-hash-table). -[Source IETF-CESR](https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html#section-3.5) \ No newline at end of file diff --git a/docs/04_glossary/internal-inconsistency.md b/docs/04_glossary/internal-inconsistency.md deleted file mode 100644 index 0784ce55..00000000 --- a/docs/04_glossary/internal-inconsistency.md +++ /dev/null @@ -1,6 +0,0 @@ -# internal inconsistency -## Definition -Internal is used to describe things that exist or happen inside an [entity](entity). In our scope of digital [identifiers](identifier) its (in)consistency is considered within the defining data structures and related data stores. - -In [KERI](key-event-receipt-infrastructure) we are protected against internal inconsistency by the hash chain datastructure of the [KEL](key-event-log), because the only [authority](authority) that can sign the log is the [controller](controller) itself. - diff --git a/docs/04_glossary/internet-assigned-numbers-authority.md b/docs/04_glossary/internet-assigned-numbers-authority.md deleted file mode 100644 index 62a61331..00000000 --- a/docs/04_glossary/internet-assigned-numbers-authority.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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) diff --git a/docs/04_glossary/interoperability.md b/docs/04_glossary/interoperability.md deleted file mode 100644 index 69ff59f3..00000000 --- a/docs/04_glossary/interoperability.md +++ /dev/null @@ -1,16 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/interoperable.md b/docs/04_glossary/interoperable.md deleted file mode 100644 index f4de0cc7..00000000 --- a/docs/04_glossary/interoperable.md +++ /dev/null @@ -1,3 +0,0 @@ -# interoperable -## See -[Interoperability](interoperability) \ No newline at end of file diff --git a/docs/04_glossary/ip-address.md b/docs/04_glossary/ip-address.md deleted file mode 100644 index ff682dae..00000000 --- a/docs/04_glossary/ip-address.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/iss.md b/docs/04_glossary/iss.md deleted file mode 100644 index 7161b619..00000000 --- a/docs/04_glossary/iss.md +++ /dev/null @@ -1,3 +0,0 @@ -# iss -## Definition -iss = vc issue, verifiable credential issuance diff --git a/docs/04_glossary/issuance-and-presentation-exchange-protocol.md b/docs/04_glossary/issuance-and-presentation-exchange-protocol.md deleted file mode 100644 index ca544e5d..00000000 --- a/docs/04_glossary/issuance-and-presentation-exchange-protocol.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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](issuance-exchange) and [presentation](presentation-exchange)) by recognizing that all exchanges (both issuance and presentation) may be modeled as the disclosure of information by a [Discloser](discloser) to a [Disclosee](disclosee). -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)) \ No newline at end of file diff --git a/docs/04_glossary/issuance-event.md b/docs/04_glossary/issuance-event.md deleted file mode 100644 index 9fee8c70..00000000 --- a/docs/04_glossary/issuance-event.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](inception-event)" of a verifiable credential. diff --git a/docs/04_glossary/issuance-exchange.md b/docs/04_glossary/issuance-exchange.md deleted file mode 100644 index af0c1e95..00000000 --- a/docs/04_glossary/issuance-exchange.md +++ /dev/null @@ -1,5 +0,0 @@ -# issuance exchange -## Definition -A special case of a [presentation exchange](presentation-exchange) where the [Discloser](discloser) is the [Issuer](issuer) of the origin (Primary) ACDC of the [DAG](directed-acyclic-graph) formed by the set of chained [ACDC](authentic-chained-data-container)s so disclosed. - -In an issuance exchange, when the origin ACDC has an [Issuee](issuee), the [Disclosee](disclosee) MAY also be the origin ACDC's Issuee. \ No newline at end of file diff --git a/docs/04_glossary/issuee.md b/docs/04_glossary/issuee.md deleted file mode 100644 index db9a0e62..00000000 --- a/docs/04_glossary/issuee.md +++ /dev/null @@ -1,6 +0,0 @@ -# issuee -## Definition -An [ACDC](authentic-chained-data-container) is optionally issued to the Issuee. When present, the Issuee identifier ([AID](autonomic-identifier)) 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](issuer) and MAY have an [Issuee](issuee). The set of [ACDC](ACDC)s so disclosed in a presentation exchange MUST be chained. This set of chained ACDCs define a [directed acyclic graph](directed-acyclic-graph) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices. \ No newline at end of file diff --git a/docs/04_glossary/issuer.md b/docs/04_glossary/issuer.md deleted file mode 100644 index 20729f16..00000000 --- a/docs/04_glossary/issuer.md +++ /dev/null @@ -1,7 +0,0 @@ -# issuer -## Definition -An [ACDC](authentic-chained-data-container) is issued by the Issuer. The Issuer identifier ([AID](autonomic-identifier)) appears in the top level of the ACDC. - -## Rule -Each ACDC MUST have an [Issuer](issuer) and MAY have an [Issuee](issuee). The set of [ACDC](ACDC)s so disclosed in a presentation exchange MUST be chained. This set of chained ACDCs define a [directed acyclic graph](directed-acyclic-graph) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices. - diff --git a/docs/04_glossary/ixn.md b/docs/04_glossary/ixn.md deleted file mode 100644 index db31f42d..00000000 --- a/docs/04_glossary/ixn.md +++ /dev/null @@ -1,7 +0,0 @@ -# ixn -## Definition -[JSON](JSON) field name (attribute) for Interaction Event; its content (value) contains a hash pointer. All [TEL](transaction-event-log) events are anchored in a [KEL](key-event-log) in either ixn ([interaction](interaction-event)) or [rot](rot) ([rotation event](rotation-event)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](rot) \ No newline at end of file diff --git a/docs/04_glossary/javascript-object-notation-(JSON).md b/docs/04_glossary/javascript-object-notation-(JSON).md deleted file mode 100644 index dbd50b7b..00000000 --- a/docs/04_glossary/javascript-object-notation-(JSON).md +++ /dev/null @@ -1,9 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/javascript-object-signing-and-encryption.md b/docs/04_glossary/javascript-object-signing-and-encryption.md deleted file mode 100644 index 4f5a6b15..00000000 --- a/docs/04_glossary/javascript-object-signing-and-encryption.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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/) \ No newline at end of file diff --git a/docs/04_glossary/judge.md b/docs/04_glossary/judge.md deleted file mode 100644 index 6c1c5ecf..00000000 --- a/docs/04_glossary/judge.md +++ /dev/null @@ -1,14 +0,0 @@ -# judge -## Definition -A judge is an entity or component that examines the entries of one or more [KERLs](key-event-receipt-log) and DELs of a given identifier to validate that the event history is from a non-[duplicitous](duplicity) controller and has been witnessed by a sufficient number of non-duplicitous [witnesses](witness) such that it may be trusted or conversely not-trusted by a [validator](validator). - -## Task and result -A judge determines current [authoritative] key set for identifier from the [key event receipt logs](key-event-receipt-log) 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](duplicity) is the only thing [watchers](watcher) 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) - diff --git a/docs/04_glossary/juror.md b/docs/04_glossary/juror.md deleted file mode 100644 index 782902d0..00000000 --- a/docs/04_glossary/juror.md +++ /dev/null @@ -1,3 +0,0 @@ -# juror -## Definition -A juror has a simpler task of performing [duplicity](duplicity) detection on events and event receipts. \ No newline at end of file diff --git a/docs/04_glossary/jury.md b/docs/04_glossary/jury.md deleted file mode 100644 index d523ebd8..00000000 --- a/docs/04_glossary/jury.md +++ /dev/null @@ -1,3 +0,0 @@ -# jury -## Definition -The jury is the set of entities or components acting as [jurors](juror). \ No newline at end of file diff --git a/docs/04_glossary/keep.md b/docs/04_glossary/keep.md deleted file mode 100644 index b6006bff..00000000 --- a/docs/04_glossary/keep.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/keri-agreement-algorithm-for-control-establishment.md b/docs/04_glossary/keri-agreement-algorithm-for-control-establishment.md deleted file mode 100644 index 3c11da47..00000000 --- a/docs/04_glossary/keri-agreement-algorithm-for-control-establishment.md +++ /dev/null @@ -1,21 +0,0 @@ -# keri agreement algorithm for control establishment -##Definition -Agreement on an event in a key event log [KEL](KEL) means each [witness](witness) has observed the same version of the event and each witness’ [receipt](receipt) 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](KA2CE)' 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) \ No newline at end of file diff --git a/docs/04_glossary/keri-command-line-interface.md b/docs/04_glossary/keri-command-line-interface.md deleted file mode 100644 index 3b88a526..00000000 --- a/docs/04_glossary/keri-command-line-interface.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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) diff --git a/docs/04_glossary/keri-event-stream.md b/docs/04_glossary/keri-event-stream.md deleted file mode 100644 index 05801c00..00000000 --- a/docs/04_glossary/keri-event-stream.md +++ /dev/null @@ -1,5 +0,0 @@ -# keri event stream -## Definition -A stream of verifiable KERI data, consisting of the [key event log](key-event-log) and other data such as a [transaction event log](transaction-event-log). This data is a CESR event stream (TODO: link to IANA application/cesr media type) and may be serialized in a file using [CESR](composable-event-streaming-representation) 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) diff --git a/docs/04_glossary/keri-improvement-doc.md b/docs/04_glossary/keri-improvement-doc.md deleted file mode 100644 index 73fb3ee3..00000000 --- a/docs/04_glossary/keri-improvement-doc.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/keri-ox.md b/docs/04_glossary/keri-ox.md deleted file mode 100644 index a3ebbe5a..00000000 --- a/docs/04_glossary/keri-ox.md +++ /dev/null @@ -1,3 +0,0 @@ -# keri ox -## Definition -The RUST programming-language implementation of the [KERI](https://github.com/trustoverip/acdc/wiki/KERI) protocol. \ No newline at end of file diff --git a/docs/04_glossary/keri-request-authentication-method.md b/docs/04_glossary/keri-request-authentication-method.md deleted file mode 100644 index 048e2f26..00000000 --- a/docs/04_glossary/keri-request-authentication-method.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](SKWA) diff --git a/docs/04_glossary/keri-suite-search-engine.md b/docs/04_glossary/keri-suite-search-engine.md deleted file mode 100644 index 24a25851..00000000 --- a/docs/04_glossary/keri-suite-search-engine.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](SSI) and the support of their journey to understand the structure of the code and how things work in the [KERI suite](keri-suite) it's more a search engine that drills down on documentation. - -## Related kerific -[kerific](kerific) is a front-end tool that show all available glossary-definition in [KERISSE](KERISSE) 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 \ No newline at end of file diff --git a/docs/04_glossary/keri-suite.md b/docs/04_glossary/keri-suite.md deleted file mode 100644 index 5f597126..00000000 --- a/docs/04_glossary/keri-suite.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/keria.md b/docs/04_glossary/keria.md deleted file mode 100644 index b43b5bcc..00000000 --- a/docs/04_glossary/keria.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/keride.md b/docs/04_glossary/keride.md deleted file mode 100644 index d58446f9..00000000 --- a/docs/04_glossary/keride.md +++ /dev/null @@ -1,5 +0,0 @@ -# keride -## Definition -is a _Rust_ programming language library for [Key Event Receipt Infrastructure](key-event-receipt-infrastructure). Among its features - is [CESR](CESR), signing, prefixing, pathing, and parsing. -More on [Github repo](https://github.com/WebOfTrust/keride) \ No newline at end of file diff --git a/docs/04_glossary/keridemlia.md b/docs/04_glossary/keridemlia.md deleted file mode 100644 index 8c6b7627..00000000 --- a/docs/04_glossary/keridemlia.md +++ /dev/null @@ -1,5 +0,0 @@ -# keridemlia -## Definition - -It is a contraction of [KERI](key-event-receipt-infrastructure) and [Kademlia](https://en.wikipedia.org/wiki/Kademlia). It's the distributed database of Witness IP-addresses based on a [Distributed Hash Table](distributed-hash-table). It also does the CNAME - stuff that [Domain Name](domain-name) 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) \ No newline at end of file diff --git a/docs/04_glossary/kerific.md b/docs/04_glossary/kerific.md deleted file mode 100644 index b9d7621c..00000000 --- a/docs/04_glossary/kerific.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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](self-sovereign-identity) field. - -## Relation with KERISSE -All glossaries that [KERISSE](KERISSE) 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) - diff --git a/docs/04_glossary/keripy.md b/docs/04_glossary/keripy.md deleted file mode 100644 index 58eb9fc2..00000000 --- a/docs/04_glossary/keripy.md +++ /dev/null @@ -1,3 +0,0 @@ -# keripy -## Definition -The Python programming-language implementation of the [KERI](KERI) protocol. \ No newline at end of file diff --git a/docs/04_glossary/kever.md b/docs/04_glossary/kever.md deleted file mode 100644 index c2f63331..00000000 --- a/docs/04_glossary/kever.md +++ /dev/null @@ -1,3 +0,0 @@ -# kever -## Definition -Kever is a key event verifier. \ No newline at end of file diff --git a/docs/04_glossary/key-compromise.md b/docs/04_glossary/key-compromise.md deleted file mode 100644 index dbc6868c..00000000 --- a/docs/04_glossary/key-compromise.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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 verification -So 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) \ No newline at end of file diff --git a/docs/04_glossary/key-event-log.md b/docs/04_glossary/key-event-log.md deleted file mode 100644 index 4a52f277..00000000 --- a/docs/04_glossary/key-event-log.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/key-event-message.md b/docs/04_glossary/key-event-message.md deleted file mode 100644 index 9b245617..00000000 --- a/docs/04_glossary/key-event-message.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/key-event-receipt-infrastructure.md b/docs/04_glossary/key-event-receipt-infrastructure.md deleted file mode 100644 index 6ac3a3ee..00000000 --- a/docs/04_glossary/key-event-receipt-infrastructure.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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. diff --git a/docs/04_glossary/key-event-receipt-log.md b/docs/04_glossary/key-event-receipt-log.md deleted file mode 100644 index 65a5515e..00000000 --- a/docs/04_glossary/key-event-receipt-log.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/key-event-receipt.md b/docs/04_glossary/key-event-receipt.md deleted file mode 100644 index f8e23c4c..00000000 --- a/docs/04_glossary/key-event-receipt.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/key-event.md b/docs/04_glossary/key-event.md deleted file mode 100644 index 361f8071..00000000 --- a/docs/04_glossary/key-event.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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_) - - \ No newline at end of file diff --git a/docs/04_glossary/key-management.md b/docs/04_glossary/key-management.md deleted file mode 100644 index 0b93feb5..00000000 --- a/docs/04_glossary/key-management.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](#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) \ No newline at end of file diff --git a/docs/04_glossary/key-pair.md b/docs/04_glossary/key-pair.md deleted file mode 100644 index f6835bd8..00000000 --- a/docs/04_glossary/key-pair.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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](public-key-infrastructure) (PKI). \ No newline at end of file diff --git a/docs/04_glossary/key-state.md b/docs/04_glossary/key-state.md deleted file mode 100644 index 5875e501..00000000 --- a/docs/04_glossary/key-state.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/key-stretching.md b/docs/04_glossary/key-stretching.md deleted file mode 100644 index 8de59498..00000000 --- a/docs/04_glossary/key-stretching.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/key-transparency.md b/docs/04_glossary/key-transparency.md deleted file mode 100644 index d95d3c6b..00000000 --- a/docs/04_glossary/key-transparency.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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_) \ No newline at end of file diff --git a/docs/04_glossary/key.md b/docs/04_glossary/key.md deleted file mode 100644 index c897725b..00000000 --- a/docs/04_glossary/key.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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)) \ No newline at end of file diff --git a/docs/04_glossary/keystore.md b/docs/04_glossary/keystore.md deleted file mode 100644 index 243ddd5c..00000000 --- a/docs/04_glossary/keystore.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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](keystore) and [wallet](wallet); the latter being a superset of the former. [Keep](keep) 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! \ No newline at end of file diff --git a/docs/04_glossary/kli.md b/docs/04_glossary/kli.md deleted file mode 100644 index e46ac04e..00000000 --- a/docs/04_glossary/kli.md +++ /dev/null @@ -1,3 +0,0 @@ -# kli -## See -[KERI command line interface](keri-command-line-interface) \ No newline at end of file diff --git a/docs/04_glossary/ksn.md b/docs/04_glossary/ksn.md deleted file mode 100644 index 26191dd7..00000000 --- a/docs/04_glossary/ksn.md +++ /dev/null @@ -1,3 +0,0 @@ -# ksn -## Definition -ksn = state, key state notice diff --git a/docs/04_glossary/large-language-model.md b/docs/04_glossary/large-language-model.md deleted file mode 100644 index eb1787b8..00000000 --- a/docs/04_glossary/large-language-model.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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) diff --git a/docs/04_glossary/lead-bytes.md b/docs/04_glossary/lead-bytes.md deleted file mode 100644 index 089de8eb..00000000 --- a/docs/04_glossary/lead-bytes.md +++ /dev/null @@ -1,6 +0,0 @@ -# lead bytes -## Definition -In order to avoid confusion with the use of the term [pad](pad) character, when [pre-pad](pre-pad)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](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_. \ No newline at end of file diff --git a/docs/04_glossary/ledger-backer.md b/docs/04_glossary/ledger-backer.md deleted file mode 100644 index 53bc8f23..00000000 --- a/docs/04_glossary/ledger-backer.md +++ /dev/null @@ -1,3 +0,0 @@ -# ledger backer -## Definition -A [witness](witness) in KERI that is ledger-registered. It's a type of [backer](backer) that proof its authenticity by a signing key anchored to the public key of a data item on a (public) blockchain. diff --git a/docs/04_glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md b/docs/04_glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md deleted file mode 100644 index fc4adf1b..00000000 --- a/docs/04_glossary/legal-entity-engagement-context-role-vlei-credential-governance-framework.md +++ /dev/null @@ -1,10 +0,0 @@ -# legal entity engagement context role vlei credential governance framework -## Definition -A document that details the requirements for [vLEI Role Credentials](vlei-role-credential) **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](legal-entity) -- [Engagement context role (ECR)](engagement-context-role) -- [vLEI credential](vlei-credential) -- [Governance framework](governance-framework) \ No newline at end of file diff --git a/docs/04_glossary/legal-entity-official-organizational-role-vlei-credential-governance-framework.md b/docs/04_glossary/legal-entity-official-organizational-role-vlei-credential-governance-framework.md deleted file mode 100644 index 724d7393..00000000 --- a/docs/04_glossary/legal-entity-official-organizational-role-vlei-credential-governance-framework.md +++ /dev/null @@ -1,10 +0,0 @@ -# legal entity official organizational role vlei credential governance framework -## Definition -A document that details the requirements for [vLEI Role Credentials](vlei-role-credential) **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](legal-entity) -- [Official organizational role (OOR)](official-organizational-role) -- [vLEI credential](vlei-credential) -- [Governance framework](governance-framework) \ No newline at end of file diff --git a/docs/04_glossary/legal-entity-vlei-credential-governance-framework.md b/docs/04_glossary/legal-entity-vlei-credential-governance-framework.md deleted file mode 100644 index 2400e3f0..00000000 --- a/docs/04_glossary/legal-entity-vlei-credential-governance-framework.md +++ /dev/null @@ -1,3 +0,0 @@ -# legal entity vlei credential governance framework -## Definition -A _document_ that details the requirements for vLEI Credential **issued by** a [Qualified vLEI Issuer](qualified-vlei-issuer) to a [Legal Entity](legal-entity). \ No newline at end of file diff --git a/docs/04_glossary/legal-entity.md b/docs/04_glossary/legal-entity.md deleted file mode 100644 index 6f61c050..00000000 --- a/docs/04_glossary/legal-entity.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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. diff --git a/docs/04_glossary/legitimized-human-meaningful-identifier.md b/docs/04_glossary/legitimized-human-meaningful-identifier.md deleted file mode 100644 index ed132c0b..00000000 --- a/docs/04_glossary/legitimized-human-meaningful-identifier.md +++ /dev/null @@ -1,11 +0,0 @@ -# legitimized human meaningful identifier -## Definition -An [AID](AID) 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](end-verifiable) [authorization](authorization). 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](autonomic-identifier) 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 |. diff --git a/docs/04_glossary/levels-of-assurance.md b/docs/04_glossary/levels-of-assurance.md deleted file mode 100644 index 6ca856f8..00000000 --- a/docs/04_glossary/levels-of-assurance.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/listed-identifier.md b/docs/04_glossary/listed-identifier.md deleted file mode 100644 index 40c6a443..00000000 --- a/docs/04_glossary/listed-identifier.md +++ /dev/null @@ -1,4 +0,0 @@ -# listed identifier -## Definition -Is a list in an [ACDC](authentic-chained-data-container) 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 \ No newline at end of file diff --git a/docs/04_glossary/liveness.md b/docs/04_glossary/liveness.md deleted file mode 100644 index 74e2ed7c..00000000 --- a/docs/04_glossary/liveness.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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](#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) \ No newline at end of file diff --git a/docs/04_glossary/loci-of-control.md b/docs/04_glossary/loci-of-control.md deleted file mode 100644 index 89c65870..00000000 --- a/docs/04_glossary/loci-of-control.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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](#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. \ No newline at end of file diff --git a/docs/04_glossary/locked-state.md b/docs/04_glossary/locked-state.md deleted file mode 100644 index 40ddd612..00000000 --- a/docs/04_glossary/locked-state.md +++ /dev/null @@ -1,4 +0,0 @@ -# locked state -## Definition - -The default status a KERI data store is in once it has been created using a [passcode](passcode); it is by default encrypted. \ No newline at end of file diff --git a/docs/04_glossary/management-TEL.md b/docs/04_glossary/management-TEL.md deleted file mode 100644 index 8bbfff10..00000000 --- a/docs/04_glossary/management-TEL.md +++ /dev/null @@ -1,3 +0,0 @@ -# management TEL -## See -[Management transaction event log](management-transaction-event-log) \ No newline at end of file diff --git a/docs/04_glossary/management-transaction-event-log.md b/docs/04_glossary/management-transaction-event-log.md deleted file mode 100644 index a5d1bfec..00000000 --- a/docs/04_glossary/management-transaction-event-log.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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). \ No newline at end of file diff --git a/docs/04_glossary/manager.txt b/docs/04_glossary/manager.txt deleted file mode 100644 index e8e2d895..00000000 --- a/docs/04_glossary/manager.txt +++ /dev/null @@ -1,2 +0,0 @@ -# manager -Dwight is the assistant regional manager. diff --git a/docs/04_glossary/media-type.md b/docs/04_glossary/media-type.md deleted file mode 100644 index 71695689..00000000 --- a/docs/04_glossary/media-type.md +++ /dev/null @@ -1,13 +0,0 @@ -# media type -## Definition -A Media type (formerly known as _MIME type_) is a standard way to indicate the nature and format of a file, in the same way as 'image/jpeg' for JPEG images, used on the internet. - -It is a two-part identifier for file formats and format contents transmitted on the internet. Their purpose is somewhat similar to file extensions in that they identify the intended data format. - -The [Internet Assigned Numbers Authority (IANA)](https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority) is the official authority for the standardization and publication of these classifications. -Source: [Wikipedia](https://en.wikipedia.org/wiki/Media_type) - -### Criteria -The more important criteria are: -- Standard Format: MIME types must adhere to the format type/subtype -- Registered with IANA: Although, ideally, MIME types should be registered with the Internet Assigned Numbers Authority ([IANA](IANA)), ensuring they are part of a recognized standard, we consider Experimental or Proposed MIME types as being a valid MIME type as well. diff --git a/docs/04_glossary/message.md b/docs/04_glossary/message.md deleted file mode 100644 index d7888070..00000000 --- a/docs/04_glossary/message.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/messagepack.md b/docs/04_glossary/messagepack.md deleted file mode 100644 index 53203918..00000000 --- a/docs/04_glossary/messagepack.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) diff --git a/docs/04_glossary/moobi.md b/docs/04_glossary/moobi.md deleted file mode 100644 index 4bc0d524..00000000 --- a/docs/04_glossary/moobi.md +++ /dev/null @@ -1,11 +0,0 @@ -# moobi -## Definition - -Multi [OOBI](OOBI) 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 \ No newline at end of file diff --git a/docs/04_glossary/most-compact.md b/docs/04_glossary/most-compact.md deleted file mode 100644 index e891b336..00000000 --- a/docs/04_glossary/most-compact.md +++ /dev/null @@ -1,13 +0,0 @@ -# most compact -## Definition -An [ACDC](ACDC) that, for a given level of disclosure, is as compact as it can be which means -- it has the [SAID](SAID)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)](fully-expanded) version of an ACDC -[Fully compact(ed)](fully-compact) version of an ACDC \ No newline at end of file diff --git a/docs/04_glossary/multi-factor-authentication.md b/docs/04_glossary/multi-factor-authentication.md deleted file mode 100644 index fca16ce1..00000000 --- a/docs/04_glossary/multi-factor-authentication.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](authenticity) mechanism. -[Source Wikipedia](https://en.wikipedia.org/wiki/Multi-factor_authentication) diff --git a/docs/04_glossary/multi-valent.md b/docs/04_glossary/multi-valent.md deleted file mode 100644 index a19c2305..00000000 --- a/docs/04_glossary/multi-valent.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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](univalent) -[Bivalent](bivalent) \ No newline at end of file diff --git a/docs/04_glossary/multicodec.md b/docs/04_glossary/multicodec.md deleted file mode 100644 index 3082e1a3..00000000 --- a/docs/04_glossary/multicodec.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/multiplexing.md b/docs/04_glossary/multiplexing.md deleted file mode 100644 index b2af6186..00000000 --- a/docs/04_glossary/multiplexing.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](count-code) and the [composability](composability) - and [concatenation](concatenation) property in CESR, [pipelining](pipelining) is possible, which then uses _multiplexing_ (combining [self-framing](self-framing) primitives) and _de-multiplexing_ (unravelling self-framing [primitives](primitive)). The addition of group framing codes as independently composable primitives enables [hierarchical compositions](hierarchical-composition). \ No newline at end of file diff --git a/docs/04_glossary/multisig.md b/docs/04_glossary/multisig.md deleted file mode 100644 index 7fb70d3d..00000000 --- a/docs/04_glossary/multisig.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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](non-repudiable) signatures. -KERI's CESR, and therefore KERI and ACDC is extensible with the latest more sophisticated multi-signature schemes like Schnorr signatures. \ No newline at end of file diff --git a/docs/04_glossary/naive-conversion.md b/docs/04_glossary/naive-conversion.md deleted file mode 100644 index 13022215..00000000 --- a/docs/04_glossary/naive-conversion.md +++ /dev/null @@ -1,14 +0,0 @@ -# naive conversion -## Definition - -Non-CESR Base64 conversion. How people are used to using the Base64 encode and decode. Without [pre-pad](pre-pad)ding etc all the stuff CESR does to ensure aligns on 24 bit boundaries so [CESR](CESR) never uses the '=' pad character. But naive [Base64](base64) 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](composability) and / or on the [concatenation](concatenation) 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](base64) conversions, because it helps explaining the necessity of stable code characters and padding in CESR to achieve: -- [self-framing](self-framing) -- round-robin [composability](composability) -- [concatenation](concatenation) options -- [pipelined](pipelining) streaming diff --git a/docs/04_glossary/namespace.md b/docs/04_glossary/namespace.md deleted file mode 100644 index b2249562..00000000 --- a/docs/04_glossary/namespace.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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. -``` diff --git a/docs/04_glossary/ndigs.md b/docs/04_glossary/ndigs.md deleted file mode 100644 index 00a2178f..00000000 --- a/docs/04_glossary/ndigs.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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. diff --git a/docs/04_glossary/nested-cooperative-delegated-identifiers.md b/docs/04_glossary/nested-cooperative-delegated-identifiers.md deleted file mode 100644 index 3c75676f..00000000 --- a/docs/04_glossary/nested-cooperative-delegated-identifiers.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/non-establishment-event.md b/docs/04_glossary/non-establishment-event.md deleted file mode 100644 index 264a9747..00000000 --- a/docs/04_glossary/non-establishment-event.md +++ /dev/null @@ -1,18 +0,0 @@ -# non establishment event -## Definition -A key event tieing or anchoring a data payload to the [key event log](key-event-log) of an identifier. This data payload includes a set of one or more [seals](seal) each of which anchor data to the key event. -The data payload event may be used to make verifiable, authoritative statements on behalf of the identifier controller. -These might include authorizations of encryption keys, communication routes, service endpoints, and so forth. - -Transactions or workflows composed of non-establishment events are secured by virtue of being included in the verifiable key event -sequence with the verifiable authoritative establishment events. - -A non-establishment event is a key event that does not change the current key-state for an AID. - -Source [KERI Whitepaper Section 7.22 page 46](https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf) -Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology) - -## Made easier -A non-establishment event is a key event that does not change the current key-state for an [identifier](identifier). The event (only) ties or anchors digital data to the [key event log](key-event-log) of the identifier. -_(@henkvancann)_ - diff --git a/docs/04_glossary/non-fungible-token.md b/docs/04_glossary/non-fungible-token.md deleted file mode 100644 index 8871841c..00000000 --- a/docs/04_glossary/non-fungible-token.md +++ /dev/null @@ -1,21 +0,0 @@ -# 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). - -## Criteria -### 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" about a non-fungible token in our perspective. It's just another unique identifier controlled by a public private key pair. The fact that NFTs uniquely identify a digital entity isn't very impressive, because of their -- security flaw : the security is dependent on the host ledger the NFT is anchored to -- transferability flaw : you need a transaction to transfer ownership on the host blockchain, controlling keys can't be rotated -- monetization flaw : there's no good reason whatsoever to mingle the value aspect and the uniqueness property of a digital asset; unfortunately, that's what NFTs are doing. - -Uniqueness tokenization done correctly is to be praised. Moreover, **it's recommended to look into KERI identifiers and ACDC veracity claims to support the value of the identifiers**, whose monetary value can be recorded elsewhere and separately from the identifier system. Key (pre-)rotation can transfer ownership of a unique digital asset without the need for a transaction on a blockchain. - -### 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 inclusive, because in the KERI/ACDC case we are dealing with globally portable unique digital twins, not anchored to, i.e. locked in, a blockchain. \ No newline at end of file diff --git a/docs/04_glossary/non-interactive-authentication-design.md b/docs/04_glossary/non-interactive-authentication-design.md deleted file mode 100644 index ff4b0797..00000000 --- a/docs/04_glossary/non-interactive-authentication-design.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](zero-trust) architectures. -More in [source](https://hackmd.io/ZbVAbNK1SPyT90-oNwN_cw) Keri Request Authentication Mechanism (KRAM) by Samuel Smith - -## Related -[Interactive authentication design](interactive-authentication-design) \ No newline at end of file diff --git a/docs/04_glossary/non-normative.md b/docs/04_glossary/non-normative.md deleted file mode 100644 index 6e21ab6a..00000000 --- a/docs/04_glossary/non-normative.md +++ /dev/null @@ -1,4 +0,0 @@ -# non normative -## Definition -A theory is called non-normative if it does not do what has described under '[Normative](normative)'. 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). \ No newline at end of file diff --git a/docs/04_glossary/non-repudiable.md b/docs/04_glossary/non-repudiable.md deleted file mode 100644 index fd1a5c4f..00000000 --- a/docs/04_glossary/non-repudiable.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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) diff --git a/docs/04_glossary/non-transferable-identifier.md b/docs/04_glossary/non-transferable-identifier.md deleted file mode 100644 index 17676074..00000000 --- a/docs/04_glossary/non-transferable-identifier.md +++ /dev/null @@ -1,12 +0,0 @@ -# non transferable identifier -## Definition -Controlling keys over this identifier cannot be rotated and therefore this identifier is [non-transferable](non-transferable) 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](transferable). - -## 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](transferable-identifier) -- non-transferable identifiers -- [delegated identifiers](delegated-identifier) \ No newline at end of file diff --git a/docs/04_glossary/non-transferable.md b/docs/04_glossary/non-transferable.md deleted file mode 100644 index af74cd98..00000000 --- a/docs/04_glossary/non-transferable.md +++ /dev/null @@ -1,8 +0,0 @@ -# non transferable -## Definition -No [capacity to transfer](transferable) (the control over) a certain digital asset in an unobstructed or loss-less manner. As opposed to [transferable](transferable). - -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](non-transferable-identifier); 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. \ No newline at end of file diff --git a/docs/04_glossary/normative.md b/docs/04_glossary/normative.md deleted file mode 100644 index 3ee1c47a..00000000 --- a/docs/04_glossary/normative.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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). \ No newline at end of file diff --git a/docs/04_glossary/official-organizational-role.md b/docs/04_glossary/official-organizational-role.md deleted file mode 100644 index bfeb5100..00000000 --- a/docs/04_glossary/official-organizational-role.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/one-way-function.md b/docs/04_glossary/one-way-function.md deleted file mode 100644 index 2f780308..00000000 --- a/docs/04_glossary/one-way-function.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/opcode.md b/docs/04_glossary/opcode.md deleted file mode 100644 index 949cfbab..00000000 --- a/docs/04_glossary/opcode.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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](composable-event-streaming-representation). - -### Opcode tables -The ‘_’ selector is reserved for the yet to be defined [opcode](opcode) table or tables. \ No newline at end of file diff --git a/docs/04_glossary/out-of-band-introduction.md b/docs/04_glossary/out-of-band-introduction.md deleted file mode 100644 index 590fc7af..00000000 --- a/docs/04_glossary/out-of-band-introduction.md +++ /dev/null @@ -1,31 +0,0 @@ -# out of band introduction -## Definition - -Out-of-band Introductions (OOBIs) are discovery and validation of IP resources for [KERI](key-event-receipt-infrastructure) 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](best-available-data-acceptance-mechanism) 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](autonomic-identifier-(AID) or [self-addressing identifier (SAID)](self-addressing-identifier)). 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](key-event-receipt-infrastructure). diff --git a/docs/04_glossary/owner.md b/docs/04_glossary/owner.md deleted file mode 100644 index bc203601..00000000 --- a/docs/04_glossary/owner.md +++ /dev/null @@ -1,3 +0,0 @@ -# owner -## See -[Owner](https://github.com/trustoverip/toip/wiki/owner) in ToIP glossary \ No newline at end of file diff --git a/docs/04_glossary/ownership.md b/docs/04_glossary/ownership.md deleted file mode 100644 index 6347a6d0..00000000 --- a/docs/04_glossary/ownership.md +++ /dev/null @@ -1,3 +0,0 @@ -# ownership -## See -[Ownership](https://github.com/trustoverip/toip/wiki/ownership) in ToIP glossary \ No newline at end of file diff --git a/docs/04_glossary/pad.md b/docs/04_glossary/pad.md deleted file mode 100644 index 2945e443..00000000 --- a/docs/04_glossary/pad.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](lead-bytes). \ No newline at end of file diff --git a/docs/04_glossary/parside.md b/docs/04_glossary/parside.md deleted file mode 100644 index 321402dd..00000000 --- a/docs/04_glossary/parside.md +++ /dev/null @@ -1,33 +0,0 @@ -# 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](count-code). (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](strip-parameter) tells us what part will be parsed be which code. - -## Design ideas Feb 2023 -1. Parside should be concerned with parsing group codes, [cesride](cesride) concerned with parsing primitives. -2. Parside will contain a [count code](count-code) at the beginning of the stream, each cesr primitive is self framing, JSON is not; hence the [Version string](version-string). -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](group-code) - -| TBW | - -## Related -- [Version code](version-code) -- [Version string](version-string) -- [Strip parameter](strip-parameter) -- [Cesride](cesride) -- [Sniffer](sniffer) - -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](sniffer) 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 diff --git a/docs/04_glossary/partial-disclosure.md b/docs/04_glossary/partial-disclosure.md deleted file mode 100644 index f01e6fae..00000000 --- a/docs/04_glossary/partial-disclosure.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](selective-disclosure) 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 \ No newline at end of file diff --git a/docs/04_glossary/partial-pre-rotation.md b/docs/04_glossary/partial-pre-rotation.md deleted file mode 100644 index edeefa55..00000000 --- a/docs/04_glossary/partial-pre-rotation.md +++ /dev/null @@ -1,3 +0,0 @@ -# partial pre rotation -## See -[Partial rotation](partial-rotation) \ No newline at end of file diff --git a/docs/04_glossary/partial-rotation.md b/docs/04_glossary/partial-rotation.md deleted file mode 100644 index e2f6a029..00000000 --- a/docs/04_glossary/partial-rotation.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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](reserve-rotation) -- [Custodial rotation](custodial-rotation) - -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](signing-threshold) of the given [rotation](rotation) ([establishment](establishment-event)) 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](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 in [Source](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#partial-pre-rotation-detail) \ No newline at end of file diff --git a/docs/04_glossary/party.md b/docs/04_glossary/party.md deleted file mode 100644 index 7405db77..00000000 --- a/docs/04_glossary/party.md +++ /dev/null @@ -1,4 +0,0 @@ -# party -## Definition -An entity who participates or is concerned in an action, proceeding, plan, etc. -Source: ToIP diff --git a/docs/04_glossary/passcode.md b/docs/04_glossary/passcode.md deleted file mode 100644 index 5d868d3a..00000000 --- a/docs/04_glossary/passcode.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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) - - diff --git a/docs/04_glossary/pathing.md b/docs/04_glossary/pathing.md deleted file mode 100644 index 1e345392..00000000 --- a/docs/04_glossary/pathing.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/payload.md b/docs/04_glossary/payload.md deleted file mode 100644 index 8466e1bf..00000000 --- a/docs/04_glossary/payload.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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 key -Note tha KERI never puts raw data or privacy-sensitive data in a `KEL` or `KERL`. \ No newline at end of file diff --git a/docs/04_glossary/peer-to-peer.md b/docs/04_glossary/peer-to-peer.md deleted file mode 100644 index 84d30f34..00000000 --- a/docs/04_glossary/peer-to-peer.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/percolated-information-discovery.md b/docs/04_glossary/percolated-information-discovery.md deleted file mode 100644 index d734ae7f..00000000 --- a/docs/04_glossary/percolated-information-discovery.md +++ /dev/null @@ -1,13 +0,0 @@ -# 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. diff --git a/docs/04_glossary/persistent-data-structure.md b/docs/04_glossary/persistent-data-structure.md deleted file mode 100644 index 018b2d3d..00000000 --- a/docs/04_glossary/persistent-data-structure.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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 diff --git a/docs/04_glossary/persistent-identifier.md b/docs/04_glossary/persistent-identifier.md deleted file mode 100644 index f92a20c6..00000000 --- a/docs/04_glossary/persistent-identifier.md +++ /dev/null @@ -1,3 +0,0 @@ -# persistent identifier -## See -[Transferable Identifiers](transferable-identifier) \ No newline at end of file diff --git a/docs/04_glossary/pii.md b/docs/04_glossary/pii.md deleted file mode 100644 index ee1a239c..00000000 --- a/docs/04_glossary/pii.md +++ /dev/null @@ -1,4 +0,0 @@ -# pii -## Definition - -personally identifiable information \ No newline at end of file diff --git a/docs/04_glossary/pipelining.md b/docs/04_glossary/pipelining.md deleted file mode 100644 index 759bdc8a..00000000 --- a/docs/04_glossary/pipelining.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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](CESR) is the only streaming protocol that has this anticipation on board. -Source: Samuel Smith, KERI Zoom meeting Dec 5 2023. - -### Related -[Multiplexing](multiplexing) diff --git a/docs/04_glossary/post-pad.md b/docs/04_glossary/post-pad.md deleted file mode 100644 index e10dcced..00000000 --- a/docs/04_glossary/post-pad.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](composability) 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](naive-conversion) does. -The other way is to [pre-pad](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) diff --git a/docs/04_glossary/post-quantum.md b/docs/04_glossary/post-quantum.md deleted file mode 100644 index d90ce182..00000000 --- a/docs/04_glossary/post-quantum.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](entropy) might be used for key generation. \ No newline at end of file diff --git a/docs/04_glossary/pre-pad.md b/docs/04_glossary/pre-pad.md deleted file mode 100644 index ad99020e..00000000 --- a/docs/04_glossary/pre-pad.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](composability) property. One is [post-pad](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](naive-conversion) 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) \ No newline at end of file diff --git a/docs/04_glossary/pre-rotation.md b/docs/04_glossary/pre-rotation.md deleted file mode 100644 index d6fcc399..00000000 --- a/docs/04_glossary/pre-rotation.md +++ /dev/null @@ -1,13 +0,0 @@ -# pre rotation -## Definition -Cryptographic commitment to next rotated key set in previous rotation or [inception event](inception-event). - -## Rotation -The main purpose of [key rotation](rotation) 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) \ No newline at end of file diff --git a/docs/04_glossary/prefix.md b/docs/04_glossary/prefix.md deleted file mode 100644 index af6ea30e..00000000 --- a/docs/04_glossary/prefix.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/presentation-exchange.md b/docs/04_glossary/presentation-exchange.md deleted file mode 100644 index 4b77e248..00000000 --- a/docs/04_glossary/presentation-exchange.md +++ /dev/null @@ -1,9 +0,0 @@ -# presentation exchange -## Definition -An exchange that provides disclosure of one or more [ACDC](authentic-chained-data-container)s between a Discloser and a Disclosee. - -A presentation exchange is the process by which [authenticatable](authenticity) information may be exchanged between two parties, namely, the [Discloser](discloser) and [Disclosee](disclosee). - -## Rule -Each ACDC MUST have an [Issuer](issuer) and MAY have an [Issuee](issuee). The set of [ACDC](ACDC)s so disclosed in a presentation exchange MUST be chained. This set of chained ACDCs define a [directed acyclic graph](directed-acyclic-graph) that MUST have at least one vertex and MAY have zero or more edges pointing to other vertices. - diff --git a/docs/04_glossary/pretty-good-privacy.md b/docs/04_glossary/pretty-good-privacy.md deleted file mode 100644 index b660be3b..00000000 --- a/docs/04_glossary/pretty-good-privacy.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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](GPG) term. diff --git a/docs/04_glossary/primary-root-of-trust.md b/docs/04_glossary/primary-root-of-trust.md deleted file mode 100644 index ac161515..00000000 --- a/docs/04_glossary/primary-root-of-trust.md +++ /dev/null @@ -1,6 +0,0 @@ -# primary root of trust -## Definition -In KERI a [root-of-trust](root-of-trust) 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. - diff --git a/docs/04_glossary/primitive.md b/docs/04_glossary/primitive.md deleted file mode 100644 index b0ad8442..00000000 --- a/docs/04_glossary/primitive.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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](cryptographic-primitive) - -## KERI related -In KERI and ACDC it a serialization of a unitary value. A [cryptographic primitive](cryptographic-primitive) 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](composable-event-streaming-representation). \ No newline at end of file diff --git a/docs/04_glossary/privacy-washing.md b/docs/04_glossary/privacy-washing.md deleted file mode 100644 index 39ff327c..00000000 --- a/docs/04_glossary/privacy-washing.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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". diff --git a/docs/04_glossary/privacy.md b/docs/04_glossary/privacy.md deleted file mode 100644 index 2ada4b15..00000000 --- a/docs/04_glossary/privacy.md +++ /dev/null @@ -1,20 +0,0 @@ -# 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](authenticity) -- [confidentiality](confidentiality) - diff --git a/docs/04_glossary/promiscuous-mode.md b/docs/04_glossary/promiscuous-mode.md deleted file mode 100644 index 7bb23d19..00000000 --- a/docs/04_glossary/promiscuous-mode.md +++ /dev/null @@ -1,9 +0,0 @@ -# promiscuous mode -## Definition -It is the mode a [watcher](watcher) runs in. A watcher uses the same code as a [witness](witness). 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. - - diff --git a/docs/04_glossary/proof-of-authority.md b/docs/04_glossary/proof-of-authority.md deleted file mode 100644 index 095cc305..00000000 --- a/docs/04_glossary/proof-of-authority.md +++ /dev/null @@ -1,24 +0,0 @@ -# proof of authority -## Definition - -Proof that somebody or something has certain rights or permissions. It's about _data_. Whereas [proof of authorship](proof-of-authorship) 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](proof-of-authority) are integrated in [Authentic Chained Data Containers (ACDCs)](authentic-chained-data-container): -- 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](controller) 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. \ No newline at end of file diff --git a/docs/04_glossary/proof-of-authorship.md b/docs/04_glossary/proof-of-authorship.md deleted file mode 100644 index 4f6f84c3..00000000 --- a/docs/04_glossary/proof-of-authorship.md +++ /dev/null @@ -1,19 +0,0 @@ -# proof of authorship -## Definition - -Proof that somebody or something has originally created certain content. It's about _data_'s inception. Whereas [proof-of-authority](proof-of-authority) 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](proof-of-authority) are integrated in [Authentic Chained Data Containers (ACDCs)](authentic-chained-data-container) constituting an [Authentic Provenance Chain (APC)](authentic-provenance-chain): -- 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](controller) over the book and its digital twin: the proof of authority by the chain of ACDCs. diff --git a/docs/04_glossary/protocol.md b/docs/04_glossary/protocol.md deleted file mode 100644 index 045a6923..00000000 --- a/docs/04_glossary/protocol.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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). diff --git a/docs/04_glossary/provenance.md b/docs/04_glossary/provenance.md deleted file mode 100644 index 6b524967..00000000 --- a/docs/04_glossary/provenance.md +++ /dev/null @@ -1,18 +0,0 @@ -# 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)](authentic-chained-data-container) establish provenance in two coherent ways: -- historic documentation of cryptographic verifiable key states and data consistency (result: secure attribution) -- historic documentation of [credentials](credential) (result: attested [veracity](veracity)) -(_@henkvancann_) \ No newline at end of file diff --git a/docs/04_glossary/provenanced.md b/docs/04_glossary/provenanced.md deleted file mode 100644 index 54ecc53d..00000000 --- a/docs/04_glossary/provenanced.md +++ /dev/null @@ -1,6 +0,0 @@ -# provenanced -## Definition -The act of verifying [authenticity](authenticity) or quality of documented history or origin of something - -## KERI specific -Focus on authenticity. See [provenance](provenance). \ No newline at end of file diff --git a/docs/04_glossary/pseudo-random-number.md b/docs/04_glossary/pseudo-random-number.md deleted file mode 100644 index bb73eeec..00000000 --- a/docs/04_glossary/pseudo-random-number.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/public-key-infrastructure.md b/docs/04_glossary/public-key-infrastructure.md deleted file mode 100644 index c4bb45ff..00000000 --- a/docs/04_glossary/public-key-infrastructure.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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 - -More on [Wikipedia](https://en.wikipedia.org/wiki/Public_key_infrastructure) \ No newline at end of file diff --git a/docs/04_glossary/public-transaction-event-log.md b/docs/04_glossary/public-transaction-event-log.md deleted file mode 100644 index 98d2e06e..00000000 --- a/docs/04_glossary/public-transaction-event-log.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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](TEL)s to establish issuance or revocation state of a [Verifiable Credential](verifiable-credential) (VC). - -### Control authority vs. issuance and revocation of VCs -The [KEL](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. - -[Source: pfeairheller](https://github.com/WebOfTrust/ietf-ptel/blob/main/draft-pfeairheller-ptel.md) \ No newline at end of file diff --git a/docs/04_glossary/public-verifiable-credential-registry.md b/docs/04_glossary/public-verifiable-credential-registry.md deleted file mode 100644 index 5cab6bcd..00000000 --- a/docs/04_glossary/public-verifiable-credential-registry.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](key-event-log). - -Two types of TELs will be used for this purpose. The first type of [TEL](transaction-event-log) is the [management TEL](management-transaction-event-log) and will signal the creation of the Registry and track the list of Registrars that will act as [Backers](backer) for the individual TELs for each [VC](verifiable-credential). The second type of TEL is the [VC TEL](virtual-credential-transaction-event-log) 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 diff --git a/docs/04_glossary/qry.md b/docs/04_glossary/qry.md deleted file mode 100644 index 6cd79ba5..00000000 --- a/docs/04_glossary/qry.md +++ /dev/null @@ -1,3 +0,0 @@ -# qry -## Definition -qry = query diff --git a/docs/04_glossary/qualified-vlei-issuer-vlei-credential-governance-framework.md b/docs/04_glossary/qualified-vlei-issuer-vlei-credential-governance-framework.md deleted file mode 100644 index 6767bbce..00000000 --- a/docs/04_glossary/qualified-vlei-issuer-vlei-credential-governance-framework.md +++ /dev/null @@ -1,3 +0,0 @@ -# qualified vlei issuer vlei credential governance framework -## Definition -A _document_ that details the requirements to enable this Credential to be **issued by** [GLEIF](GLEIF) **to** [Qualified vLEI Issuers](qualified-vlei-issuer) which allows the Qualified vLEI Issuers to issue, verify and revoke [Legal Entity vLEI Credentials](legal-entity-vlei-credential-governance-framework), [Legal Entity Official Organizational Role vLEI Credentials](legal-entity-official-organizational-role-vlei-credential-governance-framework), and [Legal Entity Engagement Context Role vLEI Credentials](legal-entity-engagement-context-role-vlei-credential-governance-framework). \ No newline at end of file diff --git a/docs/04_glossary/qualified-vlei-issuer.md b/docs/04_glossary/qualified-vlei-issuer.md deleted file mode 100644 index e4acc105..00000000 --- a/docs/04_glossary/qualified-vlei-issuer.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](vLEI) credentials to others. \ No newline at end of file diff --git a/docs/04_glossary/qualified.md b/docs/04_glossary/qualified.md deleted file mode 100644 index 38c79c37..00000000 --- a/docs/04_glossary/qualified.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/qvi-authorized-representative.md b/docs/04_glossary/qvi-authorized-representative.md deleted file mode 100644 index 1989181d..00000000 --- a/docs/04_glossary/qvi-authorized-representative.md +++ /dev/null @@ -1,3 +0,0 @@ -# qvi authorized representative -A designated representative of a [QVI](QVI) authorized, to conduct QVI operations with GLEIF and [Legal Entities](legal-entity). 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. \ No newline at end of file diff --git a/docs/04_glossary/race-condition.md b/docs/04_glossary/race-condition.md deleted file mode 100644 index 0580a080..00000000 --- a/docs/04_glossary/race-condition.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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 | \ No newline at end of file diff --git a/docs/04_glossary/rainbow-table-attack.md b/docs/04_glossary/rainbow-table-attack.md deleted file mode 100644 index e3d6e4bc..00000000 --- a/docs/04_glossary/rainbow-table-attack.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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](content-addressable-hash). 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](authenticity) and able to log -More on [source](https://www.beyondidentity.com/glossary/rainbow-table-attack) diff --git a/docs/04_glossary/rct.md b/docs/04_glossary/rct.md deleted file mode 100644 index 8b548dee..00000000 --- a/docs/04_glossary/rct.md +++ /dev/null @@ -1,3 +0,0 @@ -# rct -## Definition -rct = receipt diff --git a/docs/04_glossary/read-update-nullify.md b/docs/04_glossary/read-update-nullify.md deleted file mode 100644 index 254d62ad..00000000 --- a/docs/04_glossary/read-update-nullify.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](run-off-the-crud) -- [BADA](BADA) \ No newline at end of file diff --git a/docs/04_glossary/receipt-log.md b/docs/04_glossary/receipt-log.md deleted file mode 100644 index 895dda3b..00000000 --- a/docs/04_glossary/receipt-log.md +++ /dev/null @@ -1,3 +0,0 @@ -# receipt log -## Definition -ordered record of all key event receipts for a given set of witnesses \ No newline at end of file diff --git a/docs/04_glossary/receipt.md b/docs/04_glossary/receipt.md deleted file mode 100644 index 61e5c5e2..00000000 --- a/docs/04_glossary/receipt.md +++ /dev/null @@ -1,6 +0,0 @@ -# receipt -## Definition -event message or reference with one or more witness signatures. - -See Also: -[key event receipt](key-event-receipt) \ No newline at end of file diff --git a/docs/04_glossary/reconciliation.md b/docs/04_glossary/reconciliation.md deleted file mode 100644 index 4332eac0..00000000 --- a/docs/04_glossary/reconciliation.md +++ /dev/null @@ -1,8 +0,0 @@ -# reconciliation -## Definition -Reconciliation is the process in which you decide to accept a fork of the [KEL](key-event-log) 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 diff --git a/docs/04_glossary/redundant-credential.md b/docs/04_glossary/redundant-credential.md deleted file mode 100644 index 1b4329c7..00000000 --- a/docs/04_glossary/redundant-credential.md +++ /dev/null @@ -1,6 +0,0 @@ -# redundant credential -## Definition -Multiple credentials issued by the same issuer (e.g. a [QVI](QVI)). 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. \ No newline at end of file diff --git a/docs/04_glossary/registrar.md b/docs/04_glossary/registrar.md deleted file mode 100644 index 587c24df..00000000 --- a/docs/04_glossary/registrar.md +++ /dev/null @@ -1,3 +0,0 @@ -# registrar -## Definition -identifiers that serve as backers for each [transaction event log](transaction-event-log) (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. diff --git a/docs/04_glossary/registration-interaction.md b/docs/04_glossary/registration-interaction.md deleted file mode 100644 index 6dadcae6..00000000 --- a/docs/04_glossary/registration-interaction.md +++ /dev/null @@ -1,12 +0,0 @@ -# registration interaction -## Definition -Setup/Registration interaction, new AID and authorization to establish access control. You present a ([vLEI](vLEI)) 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](delegation) authority. - -The [Credential](verifiable-credential) is like a bearer token. Does it matter if the credential was delivered by the [issuee](issuee)? The token is [proof of the authorization](proof-of-authority), 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](access-controlled-interaction) \ No newline at end of file diff --git a/docs/04_glossary/registry.md b/docs/04_glossary/registry.md deleted file mode 100644 index addbb3c7..00000000 --- a/docs/04_glossary/registry.md +++ /dev/null @@ -1,16 +0,0 @@ -# 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](namespace), or by [domain](domain). - - - -[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](schema-registry). - diff --git a/docs/04_glossary/replay-attack.md b/docs/04_glossary/replay-attack.md deleted file mode 100644 index 2c5c313d..00000000 --- a/docs/04_glossary/replay-attack.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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) diff --git a/docs/04_glossary/repo.md b/docs/04_glossary/repo.md deleted file mode 100644 index cd448e86..00000000 --- a/docs/04_glossary/repo.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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) 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) \ No newline at end of file diff --git a/docs/04_glossary/reputation.md b/docs/04_glossary/reputation.md deleted file mode 100644 index 7fd53f39..00000000 --- a/docs/04_glossary/reputation.md +++ /dev/null @@ -1,4 +0,0 @@ -# reputation -## Definition -Consistent behaviour over time on the basis of which anyone else makes near-future decisions. -Source: Samuel Smith at IIW37. \ No newline at end of file diff --git a/docs/04_glossary/reputational-trust.md b/docs/04_glossary/reputational-trust.md deleted file mode 100644 index dfba5fe0..00000000 --- a/docs/04_glossary/reputational-trust.md +++ /dev/null @@ -1,3 +0,0 @@ -# reputational trust -## Definition -Established by a trusted party offering [Identity Assurance](identity-assurance). diff --git a/docs/04_glossary/reserve-rotation.md b/docs/04_glossary/reserve-rotation.md deleted file mode 100644 index 2928523f..00000000 --- a/docs/04_glossary/reserve-rotation.md +++ /dev/null @@ -1,4 +0,0 @@ -# reserve rotation -## Definition -One important use case for [partial rotation](partial-rotation) is to enable pre-rotated key pairs designated in one [establishment event](establishment-event) **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. \ No newline at end of file diff --git a/docs/04_glossary/rev.md b/docs/04_glossary/rev.md deleted file mode 100644 index cb6f50b2..00000000 --- a/docs/04_glossary/rev.md +++ /dev/null @@ -1,3 +0,0 @@ -# rev -## Definition -rev = vc revoke, verifiable credential revocation diff --git a/docs/04_glossary/revocation-event.md b/docs/04_glossary/revocation-event.md deleted file mode 100644 index 19db0304..00000000 --- a/docs/04_glossary/revocation-event.md +++ /dev/null @@ -1,17 +0,0 @@ -# revocation event -## Definition - - -## Considerations - -## KERI related -An event that revokes [control authority](control-authority) over an [identifier](identifier). 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](KEL). - -## Also see -[Revocation](revocation) - -## 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. - diff --git a/docs/04_glossary/revocation.md b/docs/04_glossary/revocation.md deleted file mode 100644 index b807d71f..00000000 --- a/docs/04_glossary/revocation.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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](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](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. - -## How KERI avoids confusion -KERI terminology usually avoids confusion between [rotation](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. - -## Also see -[Revocation event](revocation-event) diff --git a/docs/04_glossary/ricardian-contract.md b/docs/04_glossary/ricardian-contract.md deleted file mode 100644 index 4df12b10..00000000 --- a/docs/04_glossary/ricardian-contract.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](ACDC). \ No newline at end of file diff --git a/docs/04_glossary/root-autonomic-identifier.md b/docs/04_glossary/root-autonomic-identifier.md deleted file mode 100644 index ca5e0676..00000000 --- a/docs/04_glossary/root-autonomic-identifier.md +++ /dev/null @@ -1,8 +0,0 @@ -# root autonomic identifier -## Definition -An entity may provide the [root-of-trust](root-of-trust) for some ecosystem (with delegation )via its root [AID](AID). Let’s call this the _RID_ for "root AID". The RID must be protected using the highest level of [security](security) in its [key management](key-management). Although through the use of a [multi-valent](multi-valent) 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 - - - - diff --git a/docs/04_glossary/root-of-trust.md b/docs/04_glossary/root-of-trust.md deleted file mode 100644 index 87085715..00000000 --- a/docs/04_glossary/root-of-trust.md +++ /dev/null @@ -1,15 +0,0 @@ -# root of trust -## Definition - -A root-of-trust is some component of a system that is [secure](security) 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](non-repudiable) 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](primary-root-of-trust) in a KEL and a [secondary root-of-trust](secondary-root-of-trust), for example in a TEL or data on a blockchain. \ No newline at end of file diff --git a/docs/04_glossary/rot.md b/docs/04_glossary/rot.md deleted file mode 100644 index ece15811..00000000 --- a/docs/04_glossary/rot.md +++ /dev/null @@ -1,7 +0,0 @@ -# rot -## Definition -[JSON](JSON) field name (attribute) for Rotation Event; its content (value) contains a hash pointer. All [TEL](transaction-event-log) events are anchored in a [KEL](key-event-log) in either ixn ([interaction](interaction-event)) or [rot](rot) ([rotation event](rotation-event)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](ixn) \ No newline at end of file diff --git a/docs/04_glossary/rotation-authority.md b/docs/04_glossary/rotation-authority.md deleted file mode 100644 index 9226f001..00000000 --- a/docs/04_glossary/rotation-authority.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](autonomic-identifier) can hold exclusive rotation authority. Because control authority is split between two key sets, the first for [signing authority](signing-authority) and the second ([pre-rotated](pre-rotation)) for rotation authority, the associated thresholds and key list can be structured in such a way that a designated [custodial agent](custodial-agent) can hold signing authority while the original controller can hold exclusive rotation authority. \ No newline at end of file diff --git a/docs/04_glossary/rotation-event.md b/docs/04_glossary/rotation-event.md deleted file mode 100644 index 8951b5f4..00000000 --- a/docs/04_glossary/rotation-event.md +++ /dev/null @@ -1,12 +0,0 @@ -# rotation event -## Definition -An [establishment event](establishment-event) 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](authoritative) keypairs for an [AID](autonomic-identifier). -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](root-of-trust) 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](key-event-receipt-log). -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](key-event-receipt-infrastructure).\ -_(SamASmith)_ \ No newline at end of file diff --git a/docs/04_glossary/rotation.md b/docs/04_glossary/rotation.md deleted file mode 100644 index 4e851c17..00000000 --- a/docs/04_glossary/rotation.md +++ /dev/null @@ -1,4 +0,0 @@ -# rotation -## Definition -The operation of revoking and replacing the set of [authoritative](authoritative) [key pairs](key-pair) for an [AID](AID). This operation is made verifiable and [duplicity](duplicity) evident upon acceptance as a rotation event that is appended to the AID's [KEL](KEL). -Source [Sam Smith](https://github.com/WebOfTrust/ietf-keri/blob/main/draft-ssmith-keri.md#basic-terminology) \ No newline at end of file diff --git a/docs/04_glossary/rpy.md b/docs/04_glossary/rpy.md deleted file mode 100644 index 43a3d34d..00000000 --- a/docs/04_glossary/rpy.md +++ /dev/null @@ -1,3 +0,0 @@ -# rpy -## Definition -rpy = reply diff --git a/docs/04_glossary/run-off-the-crud.md b/docs/04_glossary/run-off-the-crud.md deleted file mode 100644 index 3ad98740..00000000 --- a/docs/04_glossary/run-off-the-crud.md +++ /dev/null @@ -1,14 +0,0 @@ -# run off the crud -## Definition - -_RUN off the [CRUD](CRUD)_ - -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](best-available-data-acceptance-mechanism) - 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. \ No newline at end of file diff --git a/docs/04_glossary/sally.md b/docs/04_glossary/sally.md deleted file mode 100644 index 37e7cfb9..00000000 --- a/docs/04_glossary/sally.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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](GLEIF) Reporting API can show what [vLEIs](vLEI) are; issued to [Legal Entities](legal-entity). - -## Inner working -The Sally [vLEI](vLEI) Audit Reporting Agent _receives presentations of credentials_ and notices of [revocation](revocation-event), verifies the structure and cryptographic integrity of the credential or revocation event and performs a POST to the configured webhook [URL](URL) -[Source](https://github.com/GLEIF-IT/sally) \ No newline at end of file diff --git a/docs/04_glossary/salt.md b/docs/04_glossary/salt.md deleted file mode 100644 index 2de510bd..00000000 --- a/docs/04_glossary/salt.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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)) \ No newline at end of file diff --git a/docs/04_glossary/salter.md b/docs/04_glossary/salter.md deleted file mode 100644 index 5be835cc..00000000 --- a/docs/04_glossary/salter.md +++ /dev/null @@ -1,4 +0,0 @@ -# salter -## Definition -A primitive that represents a [seed](seed). It has the ability to generate new [Signer](signer)s. -[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne \ No newline at end of file diff --git a/docs/04_glossary/salty-nonce-blinding-factor.md b/docs/04_glossary/salty-nonce-blinding-factor.md deleted file mode 100644 index 9988434b..00000000 --- a/docs/04_glossary/salty-nonce-blinding-factor.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/schema-namespace-registry.md b/docs/04_glossary/schema-namespace-registry.md deleted file mode 100644 index 56d757f4..00000000 --- a/docs/04_glossary/schema-namespace-registry.md +++ /dev/null @@ -1,7 +0,0 @@ -# schema namespace registry -## Definition - -a centrally managed [schema registry](schema-registry) where corporations or individuals reserve schemas within a specific [namespace](namespace) in order to have an interoperable schema that is labeled with a corporation-specific or individual-specific namespace. - -## ACDC related -[Graphs](directed-acyclic-graph) in ACDC have decentralised the old-school schema registry, so it's [interoperable](interoperability) by design. \ No newline at end of file diff --git a/docs/04_glossary/schema-registry.md b/docs/04_glossary/schema-registry.md deleted file mode 100644 index 4e549ee9..00000000 --- a/docs/04_glossary/schema-registry.md +++ /dev/null @@ -1,16 +0,0 @@ -# schema registry -## Definition -Central [registry](registry) 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](public-verifiable-credential-registry)" 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](VDS) and [graph fragments](graph-fragment). - - \ No newline at end of file diff --git a/docs/04_glossary/seal.md b/docs/04_glossary/seal.md deleted file mode 100644 index 0b325392..00000000 --- a/docs/04_glossary/seal.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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 | diff --git a/docs/04_glossary/secondary-root-of-trust.md b/docs/04_glossary/secondary-root-of-trust.md deleted file mode 100644 index ae1f5ec9..00000000 --- a/docs/04_glossary/secondary-root-of-trust.md +++ /dev/null @@ -1,5 +0,0 @@ -# secondary root of trust -## Definition - -In KERI its a [root-of-trust](root-of-trust) that, for its secure attribution, depends on another verifiable data structure (VDS) which MUST be a [primary root-of-trust](primary-root-of-trust). -By its nature and cryptographic anchoring via [seals](seal) to a primary root-of-trust, a secondary root-of-trust still has a high level of trustability and can be automatically verified. diff --git a/docs/04_glossary/secure-asset-transfer-protocol.md b/docs/04_glossary/secure-asset-transfer-protocol.md deleted file mode 100644 index 83b8ccd4..00000000 --- a/docs/04_glossary/secure-asset-transfer-protocol.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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). \ No newline at end of file diff --git a/docs/04_glossary/secure-attribution.md b/docs/04_glossary/secure-attribution.md deleted file mode 100644 index 0832aafc..00000000 --- a/docs/04_glossary/secure-attribution.md +++ /dev/null @@ -1,10 +0,0 @@ -# secure attribution -## Definition - -In short: secure attribution is "whodunit?!" in cyberspace. - -Secure attribution is strongly related to _making and proving statements_. A [controller](controller) makes statements to the a [validator](validator) or verifier, who in turn validates the statements issued. A [controller](controller) "_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. \ No newline at end of file diff --git a/docs/04_glossary/secure-private-authentic-confidentiality.md b/docs/04_glossary/secure-private-authentic-confidentiality.md deleted file mode 100644 index 437d811d..00000000 --- a/docs/04_glossary/secure-private-authentic-confidentiality.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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 - -## 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. - diff --git a/docs/04_glossary/secure.md b/docs/04_glossary/secure.md deleted file mode 100644 index 2d5e6cc4..00000000 --- a/docs/04_glossary/secure.md +++ /dev/null @@ -1,3 +0,0 @@ -# secure -## See -[Security](security) diff --git a/docs/04_glossary/security-cost-performance-architecture-trade-off.md b/docs/04_glossary/security-cost-performance-architecture-trade-off.md deleted file mode 100644 index 35a55f82..00000000 --- a/docs/04_glossary/security-cost-performance-architecture-trade-off.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/security-overlay-properties-trillema.md b/docs/04_glossary/security-overlay-properties-trillema.md deleted file mode 100644 index 19b9363b..00000000 --- a/docs/04_glossary/security-overlay-properties-trillema.md +++ /dev/null @@ -1,10 +0,0 @@ -# security overlay properties trillema -## Definition -An identifier system has some degree of any combination of the three properties [authenticity](authenticity), [privacy](privacy) and [confidentiality](confidentiality), 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/blob/df57ca77aafca255f4c4ddefb099151009d85556/static/img/Trilemma-of-Identifier-System-Properties.png?raw=true) \ No newline at end of file diff --git a/docs/04_glossary/security.md b/docs/04_glossary/security.md deleted file mode 100644 index 1ff4058b..00000000 --- a/docs/04_glossary/security.md +++ /dev/null @@ -1,3 +0,0 @@ -# security -## Definition -'secure' is free from or not exposed to danger or harm; safe. For [identifier](identifier)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](controller) over the identifier. \ No newline at end of file diff --git a/docs/04_glossary/seed.md b/docs/04_glossary/seed.md deleted file mode 100644 index 3d1c7ce4..00000000 --- a/docs/04_glossary/seed.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/selective-disclosure.md b/docs/04_glossary/selective-disclosure.md deleted file mode 100644 index b8260f67..00000000 --- a/docs/04_glossary/selective-disclosure.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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](partial-disclosure) - -Source: distilled from ACDC Zoom meeting, date March 28, 2023 \ No newline at end of file diff --git a/docs/04_glossary/self-addressing-data.md b/docs/04_glossary/self-addressing-data.md deleted file mode 100644 index 875a37f0..00000000 --- a/docs/04_glossary/self-addressing-data.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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) diff --git a/docs/04_glossary/self-addressing-identifier.md b/docs/04_glossary/self-addressing-identifier.md deleted file mode 100644 index 9612a2cc..00000000 --- a/docs/04_glossary/self-addressing-identifier.md +++ /dev/null @@ -1,30 +0,0 @@ -# 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. -1. Canonicalize the data, if needed. The result is called the SAID's **identifiable basis**. -1. Hash the *identifiable basis*. The result is the value of the SAID. -1. 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**. -1. In the *claimed saidified data*, replace the SAID value with a placeholder. The result is the **identifiable basis** for the SAID. -1. Hash the *identifiable basis*. -1. 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)`. diff --git a/docs/04_glossary/self-authenticating.md b/docs/04_glossary/self-authenticating.md deleted file mode 100644 index 6e2d3352..00000000 --- a/docs/04_glossary/self-authenticating.md +++ /dev/null @@ -1,3 +0,0 @@ -# self authenticating -## See -[self-certifying](self-certifying-identifier) \ No newline at end of file diff --git a/docs/04_glossary/self-certifying-identifier.md b/docs/04_glossary/self-certifying-identifier.md deleted file mode 100644 index 275b5123..00000000 --- a/docs/04_glossary/self-certifying-identifier.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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](controller) 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](prefix) in the identifier. - -## Important SCID properties: -- Self-contained secure cryptographic [root-of-trust](root-of-trust) -- Decentralized control via [private key management](PKI) -- Universally unique identifiers - -## Related to KERI -A self-certifying identifier (SCID) is a type of [cryptonym](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](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](ephemeral) i.e. it does not support [rotation](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. \ No newline at end of file diff --git a/docs/04_glossary/self-framing.md b/docs/04_glossary/self-framing.md deleted file mode 100644 index 835477ef..00000000 --- a/docs/04_glossary/self-framing.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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](composable-event-streaming-representation) 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. \ No newline at end of file diff --git a/docs/04_glossary/self-sovereign-identity.md b/docs/04_glossary/self-sovereign-identity.md deleted file mode 100644 index 51041cc7..00000000 --- a/docs/04_glossary/self-sovereign-identity.md +++ /dev/null @@ -1,7 +0,0 @@ -# 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). - -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) diff --git a/docs/04_glossary/self-sovereignty.md b/docs/04_glossary/self-sovereignty.md deleted file mode 100644 index 810bedbf..00000000 --- a/docs/04_glossary/self-sovereignty.md +++ /dev/null @@ -1,3 +0,0 @@ -# self sovereignty -## See -[Self sovereignty](https://github.com/trustoverip/toip/wiki/self-sovereignty) in Trust over IP wiki. diff --git a/docs/04_glossary/server-sent-event.md b/docs/04_glossary/server-sent-event.md deleted file mode 100644 index f6573ccf..00000000 --- a/docs/04_glossary/server-sent-event.md +++ /dev/null @@ -1,4 +0,0 @@ -# server sent event -## Definition - -Mailbox notifications; a streaming service for the agent U/I, to get notifications from the KERI system itself. \ No newline at end of file diff --git a/docs/04_glossary/service-endpoint.md b/docs/04_glossary/service-endpoint.md deleted file mode 100644 index d28a9712..00000000 --- a/docs/04_glossary/service-endpoint.md +++ /dev/null @@ -1,8 +0,0 @@ -# service endpoint -## Definition -In our context we consider a **web service endpoint** which is a [URL](uniform-resource-locator) 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) \ No newline at end of file diff --git a/docs/04_glossary/siger.md b/docs/04_glossary/siger.md deleted file mode 100644 index 38449bee..00000000 --- a/docs/04_glossary/siger.md +++ /dev/null @@ -1,2 +0,0 @@ -# siger -## See [Indexed signature](indexed-signature) \ No newline at end of file diff --git a/docs/04_glossary/signed-digest.md b/docs/04_glossary/signed-digest.md deleted file mode 100644 index d7b6059e..00000000 --- a/docs/04_glossary/signed-digest.md +++ /dev/null @@ -1,3 +0,0 @@ -# signed digest -## Definition -commitment to content, by digitally signing a digest of this content. \ No newline at end of file diff --git a/docs/04_glossary/signer.md b/docs/04_glossary/signer.md deleted file mode 100644 index 60a1c832..00000000 --- a/docs/04_glossary/signer.md +++ /dev/null @@ -1,4 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/signify-keria-request-authentication-protocol.md b/docs/04_glossary/signify-keria-request-authentication-protocol.md deleted file mode 100644 index cdb688a6..00000000 --- a/docs/04_glossary/signify-keria-request-authentication-protocol.md +++ /dev/null @@ -1,21 +0,0 @@ -# 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](AID)s via [agent](agent)s in the new, multi-tenant Mark II Agent server, [KERIA](keria). -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](KERIMask) 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](signify) signs things at the edge. This includes [ACDC](ACDC)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) - diff --git a/docs/04_glossary/signify.md b/docs/04_glossary/signify.md deleted file mode 100644 index c102aa58..00000000 --- a/docs/04_glossary/signify.md +++ /dev/null @@ -1,20 +0,0 @@ -# signify -## Definition - -Signify is a web client [(key) event](key-event) signing - and key pair creation app that minimizes the use of [KERI](KERI) 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](#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](digest) and current signing key) come from the client -- Cloud host ensures that the code supply chain is secure and never sees the private keys \ No newline at end of file diff --git a/docs/04_glossary/signing-authority.md b/docs/04_glossary/signing-authority.md deleted file mode 100644 index aa0ced44..00000000 --- a/docs/04_glossary/signing-authority.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](rotation-authority) is not included. - -## Relation to rotation authority -The original controller of an [AID](autonomic-identifier) can hold exclusive [rotation authority](rotation-authority). Because control authority is split between two key sets, the first for signing-authority and the second ([pre-rotated](pre-rotation)) for [rotation authority](rotation-authority), the associated thresholds and key list can be structured in such a way that a designated [custodial agent](custodial-agent) can hold signing authority while the original controller can hold exclusive rotation authority. diff --git a/docs/04_glossary/signing-threshold.md b/docs/04_glossary/signing-threshold.md deleted file mode 100644 index b047b001..00000000 --- a/docs/04_glossary/signing-threshold.md +++ /dev/null @@ -1,6 +0,0 @@ -# signing threshold -## Definition -Is the minimum number of valid signatures to satisfy the requirement for successful verification in a [Threshold Signature Scheme](threshold-signature-scheme). - -## 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. \ No newline at end of file diff --git a/docs/04_glossary/simple-keri-for-web-auth.md b/docs/04_glossary/simple-keri-for-web-auth.md deleted file mode 100644 index 0e6b3aa1..00000000 --- a/docs/04_glossary/simple-keri-for-web-auth.md +++ /dev/null @@ -1,7 +0,0 @@ -# simple keri for web auth -## Definition -A [KERI](KERI) 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](keep). [Signify](signify) is designed for public clouds. diff --git a/docs/04_glossary/single-signature-identifier.md b/docs/04_glossary/single-signature-identifier.md deleted file mode 100644 index 7fcb253d..00000000 --- a/docs/04_glossary/single-signature-identifier.md +++ /dev/null @@ -1,4 +0,0 @@ -# single signature identifier -## Definition - -or single sig identifier; is an identifier controlled by a one-of-one signing [keypair](key-pair) \ No newline at end of file diff --git a/docs/04_glossary/sniffable.md b/docs/04_glossary/sniffable.md deleted file mode 100644 index 1678a6e5..00000000 --- a/docs/04_glossary/sniffable.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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](parside)) 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](sniffer) \ No newline at end of file diff --git a/docs/04_glossary/sniffer.md b/docs/04_glossary/sniffer.md deleted file mode 100644 index 01e69e10..00000000 --- a/docs/04_glossary/sniffer.md +++ /dev/null @@ -1,11 +0,0 @@ -# sniffer -## Definition -The _sniffer_ is part of [Parside](parside) 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](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 result is 'CESR' then when at the top level looks for the CESR [version count code](version-code) or any other count codes. - -Source Slack Cesride thread: Feb 2 2023 - -## Related -[Sniffable](sniffable) \ No newline at end of file diff --git a/docs/04_glossary/solicited-issuance.md b/docs/04_glossary/solicited-issuance.md deleted file mode 100644 index 8327b74e..00000000 --- a/docs/04_glossary/solicited-issuance.md +++ /dev/null @@ -1,7 +0,0 @@ -# solicited issuance -## Definition -The issuance of a Legal Entity vLEI Credentials, [OOR](OOR) vLEI Credentials and [ECR](ECR) vLEI Credentials upon receipt by the [QAR](QAR) of a Fully Signed issuance request from the [AVR](AVR)(s) of the [Legal Entity](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 -See [Unsolicited issuance](unsolicited-issuance) \ No newline at end of file diff --git a/docs/04_glossary/source-of-truth.md b/docs/04_glossary/source-of-truth.md deleted file mode 100644 index 49ffdf75..00000000 --- a/docs/04_glossary/source-of-truth.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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. - - diff --git a/docs/04_glossary/spanning-layer.md b/docs/04_glossary/spanning-layer.md deleted file mode 100644 index 6eec8775..00000000 --- a/docs/04_glossary/spanning-layer.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/spurn.md b/docs/04_glossary/spurn.md deleted file mode 100644 index efadbc31..00000000 --- a/docs/04_glossary/spurn.md +++ /dev/null @@ -1,5 +0,0 @@ -# spurn -## Definition -Reject. The verb 'spurn' is originated in [IPEX](IPEX) specification. - -| TBW prio 2 | \ No newline at end of file diff --git a/docs/04_glossary/ssi-system.md b/docs/04_glossary/ssi-system.md deleted file mode 100644 index f0b25cd1..00000000 --- a/docs/04_glossary/ssi-system.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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)](self-sovereign-identity) available nowadays. - diff --git a/docs/04_glossary/stale-event.md b/docs/04_glossary/stale-event.md deleted file mode 100644 index aa28bfd8..00000000 --- a/docs/04_glossary/stale-event.md +++ /dev/null @@ -1,4 +0,0 @@ -# stale event -## Definition -A stale key event is an outdated or irrelevant (key) event involving an [expired encryption key](stale-key) that may compromise security. - diff --git a/docs/04_glossary/stale-key.md b/docs/04_glossary/stale-key.md deleted file mode 100644 index 01b1acdc..00000000 --- a/docs/04_glossary/stale-key.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](stale-event) \ No newline at end of file diff --git a/docs/04_glossary/strip-parameter.md b/docs/04_glossary/strip-parameter.md deleted file mode 100644 index e996b2f1..00000000 --- a/docs/04_glossary/strip-parameter.md +++ /dev/null @@ -1,8 +0,0 @@ -# strip parameter -## Definition -tells us what part of the [CESR](CESR) stream will be parsed by which code. - -## Related -[Parside](parside) - -| TBW | \ No newline at end of file diff --git a/docs/04_glossary/sub-shell.md b/docs/04_glossary/sub-shell.md deleted file mode 100644 index 7e764500..00000000 --- a/docs/04_glossary/sub-shell.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/supermajority.md b/docs/04_glossary/supermajority.md deleted file mode 100644 index d395fbba..00000000 --- a/docs/04_glossary/supermajority.md +++ /dev/null @@ -1,3 +0,0 @@ -# supermajority -## Definition -Sufficient majority that is labeled _immune_ from certain kinds of attacks or faults. \ No newline at end of file diff --git a/docs/04_glossary/tcp-endpoint.md b/docs/04_glossary/tcp-endpoint.md deleted file mode 100644 index 0176433f..00000000 --- a/docs/04_glossary/tcp-endpoint.md +++ /dev/null @@ -1,9 +0,0 @@ -# tcp endpoint -## Definition - -This is a [service endpoint](service-endpoint) of the web [transmission control protocol](transmission-control-protocol) - -## 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) \ No newline at end of file diff --git a/docs/04_glossary/text-binary-concatenation-composability.md b/docs/04_glossary/text-binary-concatenation-composability.md deleted file mode 100644 index 1be27725..00000000 --- a/docs/04_glossary/text-binary-concatenation-composability.md +++ /dev/null @@ -1,18 +0,0 @@ -# text binary concatenation composability -## Definition - -An encoding has _composability_ when any set of [self-framing](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. - -## 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. - - - -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). - diff --git a/docs/04_glossary/tholder.md b/docs/04_glossary/tholder.md deleted file mode 100644 index 7f02b8b2..00000000 --- a/docs/04_glossary/tholder.md +++ /dev/null @@ -1,3 +0,0 @@ -# tholder -## Definition -t-holder object that supports fractionally-weighted [thresholds](signing-threshold) \ No newline at end of file diff --git a/docs/04_glossary/threshold-of-accountable-duplicity.md b/docs/04_glossary/threshold-of-accountable-duplicity.md deleted file mode 100644 index 45c4f0e5..00000000 --- a/docs/04_glossary/threshold-of-accountable-duplicity.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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)](key-event-log) during the [key inception event](inception-event) and may edit it during subsequent [key rotation events](rotation-event). - -## 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. \ No newline at end of file diff --git a/docs/04_glossary/threshold-signature-scheme.md b/docs/04_glossary/threshold-signature-scheme.md deleted file mode 100644 index 1e3ee939..00000000 --- a/docs/04_glossary/threshold-signature-scheme.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/threshold-structure-security.md b/docs/04_glossary/threshold-structure-security.md deleted file mode 100644 index feda02a8..00000000 --- a/docs/04_glossary/threshold-structure-security.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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](multi-factor-authentication) 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](trusted-execution-environment)) for security. The two types of security are complementary. - -## KERI related -This applies to KERI as well. The [witnesses](witness) and [watchers](watcher) 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 diff --git a/docs/04_glossary/top-level-section.md b/docs/04_glossary/top-level-section.md deleted file mode 100644 index ccfa1b0c..00000000 --- a/docs/04_glossary/top-level-section.md +++ /dev/null @@ -1,9 +0,0 @@ -# top level section -## Definition -The fields of an ACDC in [compact variant](compact-variant). 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 diff --git a/docs/04_glossary/trans-contextual-value.md b/docs/04_glossary/trans-contextual-value.md deleted file mode 100644 index 9ba106cd..00000000 --- a/docs/04_glossary/trans-contextual-value.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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. - - diff --git a/docs/04_glossary/transaction-event-log.md b/docs/04_glossary/transaction-event-log.md deleted file mode 100644 index d5f8977f..00000000 --- a/docs/04_glossary/transaction-event-log.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](key-event-log). Any validator may therefore cryptographically verify the [authoritative state](authoritative) of the [registry](registry). - -### 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) diff --git a/docs/04_glossary/transfer-off-ledger.md b/docs/04_glossary/transfer-off-ledger.md deleted file mode 100644 index fd2942b6..00000000 --- a/docs/04_glossary/transfer-off-ledger.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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 just -doing rotation events and changing your anchor, your backers here. -So an identifier cannot be anchored, let's say to multiple Indies or Ethereum. You could be only anchored in one at a time. - -## Move identifiers across networks -You can move identifiers across networks with KERI, but it's not what it has been designed for. \ No newline at end of file diff --git a/docs/04_glossary/transferable-identifier.md b/docs/04_glossary/transferable-identifier.md deleted file mode 100644 index 457344a8..00000000 --- a/docs/04_glossary/transferable-identifier.md +++ /dev/null @@ -1,14 +0,0 @@ -# transferable identifier -## Definition -Control over the identifier [can be transferred](transferable) 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](non-transferable-identifier) -- [delegated identifiers](delegated-identifier) \ No newline at end of file diff --git a/docs/04_glossary/transferable.md b/docs/04_glossary/transferable.md deleted file mode 100644 index 836f5faa..00000000 --- a/docs/04_glossary/transferable.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](non-transferable). -[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](transferable-identifier), private keys, etc. \ No newline at end of file diff --git a/docs/04_glossary/transmission-control-protocol.md b/docs/04_glossary/transmission-control-protocol.md deleted file mode 100644 index 42535dd0..00000000 --- a/docs/04_glossary/transmission-control-protocol.md +++ /dev/null @@ -1,5 +0,0 @@ -# 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. diff --git a/docs/04_glossary/trust-domain.md b/docs/04_glossary/trust-domain.md deleted file mode 100644 index f84eee7f..00000000 --- a/docs/04_glossary/trust-domain.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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](domain-name). - diff --git a/docs/04_glossary/trust-spanning-protocol.md b/docs/04_glossary/trust-spanning-protocol.md deleted file mode 100644 index c729035d..00000000 --- a/docs/04_glossary/trust-spanning-protocol.md +++ /dev/null @@ -1,3 +0,0 @@ -# trust spanning protocol -## Definition -Protocol using [VID](verifiable-identifier)s that signs every single message on the internet and makes them verifiable. diff --git a/docs/04_glossary/trusted-execution-environment.md b/docs/04_glossary/trusted-execution-environment.md deleted file mode 100644 index 9ff20846..00000000 --- a/docs/04_glossary/trusted-execution-environment.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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 \ No newline at end of file diff --git a/docs/04_glossary/trusted-platform-module.md b/docs/04_glossary/trusted-platform-module.md deleted file mode 100644 index 44c606be..00000000 --- a/docs/04_glossary/trusted-platform-module.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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 diff --git a/docs/04_glossary/ts-node.md b/docs/04_glossary/ts-node.md deleted file mode 100644 index e6850773..00000000 --- a/docs/04_glossary/ts-node.md +++ /dev/null @@ -1,3 +0,0 @@ -# ts node -## Definition -npm package that lets you run typescript from a shell \ No newline at end of file diff --git a/docs/04_glossary/uniform-resource-locator.md b/docs/04_glossary/uniform-resource-locator.md deleted file mode 100644 index f3758758..00000000 --- a/docs/04_glossary/uniform-resource-locator.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/univalent.md b/docs/04_glossary/univalent.md deleted file mode 100644 index 3f8bf902..00000000 --- a/docs/04_glossary/univalent.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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](multi-valent) -[Bivalent](bivalent) \ No newline at end of file diff --git a/docs/04_glossary/unsolicited-issuance.md b/docs/04_glossary/unsolicited-issuance.md deleted file mode 100644 index 121fb793..00000000 --- a/docs/04_glossary/unsolicited-issuance.md +++ /dev/null @@ -1,7 +0,0 @@ -# unsolicited issuance -## Definition -Issuance of a Legal Entity vLEI Credential upon notice by a [QAR](QAR) to the [AVR](AVR)(s) of the Legal Entity that a Legal Entity vLEI Credential has been solicited on the [Legal Entity](legal-entity)’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](solicited-issuance) \ No newline at end of file diff --git a/docs/04_glossary/user-interface.md b/docs/04_glossary/user-interface.md deleted file mode 100644 index 5d9d515e..00000000 --- a/docs/04_glossary/user-interface.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/vLEI.md b/docs/04_glossary/vLEI.md deleted file mode 100644 index 2c8ef117..00000000 --- a/docs/04_glossary/vLEI.md +++ /dev/null @@ -1,3 +0,0 @@ -# vLEI -## See -[Verifiable legal entity identifier](verifiable-legal-entity-identifier) \ No newline at end of file diff --git a/docs/04_glossary/validate.md b/docs/04_glossary/validate.md deleted file mode 100644 index 9ae8895a..00000000 --- a/docs/04_glossary/validate.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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](verify) - -In contrast, [validator](validator) and [verifier](verifier) have been clearly outlined in the WebofTrust vocabulary. \ No newline at end of file diff --git a/docs/04_glossary/validator.md b/docs/04_glossary/validator.md deleted file mode 100644 index 43abc544..00000000 --- a/docs/04_glossary/validator.md +++ /dev/null @@ -1,18 +0,0 @@ -# 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](verifier) are close to synonyms for our purposes. - -A `validator` in [KERI](key-event-receipt-infrastructure) and [ACDC](authentic-chained-data-container) 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](verifier) checks to see if a verifiable [credential](credential) ([VC](VC)) 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) diff --git a/docs/04_glossary/vcp.md b/docs/04_glossary/vcp.md deleted file mode 100644 index 3e95eb9a..00000000 --- a/docs/04_glossary/vcp.md +++ /dev/null @@ -1,3 +0,0 @@ -# vcp -## Definition -vcp = vdr incept, verifiable data registry inception diff --git a/docs/04_glossary/vdr.md b/docs/04_glossary/vdr.md deleted file mode 100644 index 5ff023bc..00000000 --- a/docs/04_glossary/vdr.md +++ /dev/null @@ -1,3 +0,0 @@ -# vdr -## See -[Verifiable data registry](verifiable-data-registry) \ No newline at end of file diff --git a/docs/04_glossary/veracity.md b/docs/04_glossary/veracity.md deleted file mode 100644 index a898c284..00000000 --- a/docs/04_glossary/veracity.md +++ /dev/null @@ -1,4 +0,0 @@ -# veracity -## Definition - -The quality of being true; contrast [authenticity](authenticity). 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*). \ No newline at end of file diff --git a/docs/04_glossary/verfer.md b/docs/04_glossary/verfer.md deleted file mode 100644 index 443a0ead..00000000 --- a/docs/04_glossary/verfer.md +++ /dev/null @@ -1,4 +0,0 @@ -# verfer -## Definition -A primitive that represents a public key. It has the ability to [verify](verify) signatures on data. -[Source](https://github.com/WebOfTrust/cesride#terminology) by Jason Colburne \ No newline at end of file diff --git a/docs/04_glossary/verifiable-credential.md b/docs/04_glossary/verifiable-credential.md deleted file mode 100644 index 3e1d4a93..00000000 --- a/docs/04_glossary/verifiable-credential.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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. - -## 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/) - diff --git a/docs/04_glossary/verifiable-data-registry.md b/docs/04_glossary/verifiable-data-registry.md deleted file mode 100644 index be7761f6..00000000 --- a/docs/04_glossary/verifiable-data-registry.md +++ /dev/null @@ -1,4 +0,0 @@ -# verifiable data registry -## Definition -a [Verifiable Data Structure](verifiable-data-structure) that has actual content. -It contains either a log of signed statements or a cryptographic commitment ([digest](digest)) to those statements (via a Merkle tree or hash chained data structure). \ No newline at end of file diff --git a/docs/04_glossary/verifiable-data-structure.md b/docs/04_glossary/verifiable-data-structure.md deleted file mode 100644 index 0807fa7f..00000000 --- a/docs/04_glossary/verifiable-data-structure.md +++ /dev/null @@ -1,18 +0,0 @@ -# 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](#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). \ No newline at end of file diff --git a/docs/04_glossary/verifiable-identifier.md b/docs/04_glossary/verifiable-identifier.md deleted file mode 100644 index 778fadac..00000000 --- a/docs/04_glossary/verifiable-identifier.md +++ /dev/null @@ -1,3 +0,0 @@ -# verifiable identifier -## Definition -Cryptographically verifiable authentic decentralized identifier (verfiable [DID](DID)) \ No newline at end of file diff --git a/docs/04_glossary/verifiable-legal-entity-identifier.md b/docs/04_glossary/verifiable-legal-entity-identifier.md deleted file mode 100644 index 5dc9fc8b..00000000 --- a/docs/04_glossary/verifiable-legal-entity-identifier.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/verifiable.md b/docs/04_glossary/verifiable.md deleted file mode 100644 index 77cda83d..00000000 --- a/docs/04_glossary/verifiable.md +++ /dev/null @@ -1,7 +0,0 @@ -# verifiable -## Definition -able to cryptographically verify a certain data structure on its [consistency](inconsistency) and its [authenticity](authenticity) - -## 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) \ No newline at end of file diff --git a/docs/04_glossary/verification.md b/docs/04_glossary/verification.md deleted file mode 100644 index 31ec90f8..00000000 --- a/docs/04_glossary/verification.md +++ /dev/null @@ -1,9 +0,0 @@ -# verification -## Definition -An action an [agent](agent) (of a principal) performs to determine the [authenticity](authenticity) 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](verify) diff --git a/docs/04_glossary/verified-integrity.md b/docs/04_glossary/verified-integrity.md deleted file mode 100644 index 2f08e3cd..00000000 --- a/docs/04_glossary/verified-integrity.md +++ /dev/null @@ -1,12 +0,0 @@ -# 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](internal-inconsistency) of [KE(R)L](key-event-receipt-log) and [TEL](transaction-event-log) plus [duplicity](duplicity) detection. -- In ACDC the [self addressing identifier](self-addressing-identifier) (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](composability). - -## See also -[integrity](integrity) -[(complementary) integrity verification](complementary-integrity-verification) diff --git a/docs/04_glossary/verifier.md b/docs/04_glossary/verifier.md deleted file mode 100644 index 178a36a9..00000000 --- a/docs/04_glossary/verifier.md +++ /dev/null @@ -1,9 +0,0 @@ -# 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](validator) 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) diff --git a/docs/04_glossary/verify-signature.md b/docs/04_glossary/verify-signature.md deleted file mode 100644 index 8974ae58..00000000 --- a/docs/04_glossary/verify-signature.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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 - diff --git a/docs/04_glossary/verify.md b/docs/04_glossary/verify.md deleted file mode 100644 index 5cdadde0..00000000 --- a/docs/04_glossary/verify.md +++ /dev/null @@ -1,8 +0,0 @@ -# verify -## Definition -The act, by or on behalf of a [party](party), of determining whether that data is [authentic](authenticity) (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](verification) - diff --git a/docs/04_glossary/version-code.md b/docs/04_glossary/version-code.md deleted file mode 100644 index 0593f7d7..00000000 --- a/docs/04_glossary/version-code.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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](version-string) diff --git a/docs/04_glossary/version-string.md b/docs/04_glossary/version-string.md deleted file mode 100644 index ac6e8d4a..00000000 --- a/docs/04_glossary/version-string.md +++ /dev/null @@ -1,6 +0,0 @@ -# version string -## Definition -The Version String in JSON, CBOR and MGPK is a workaround to make those self-framing. - -## Compare -[Version code](version-code) \ No newline at end of file diff --git a/docs/04_glossary/version.md b/docs/04_glossary/version.md deleted file mode 100644 index a34804c2..00000000 --- a/docs/04_glossary/version.md +++ /dev/null @@ -1,8 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/virtual-credential-transaction-event-log.md b/docs/04_glossary/virtual-credential-transaction-event-log.md deleted file mode 100644 index a6a21ffe..00000000 --- a/docs/04_glossary/virtual-credential-transaction-event-log.md +++ /dev/null @@ -1,3 +0,0 @@ -# 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)_. \ No newline at end of file diff --git a/docs/04_glossary/vlei-credential.md b/docs/04_glossary/vlei-credential.md deleted file mode 100644 index 4f7b754b..00000000 --- a/docs/04_glossary/vlei-credential.md +++ /dev/null @@ -1,3 +0,0 @@ -# vlei credential -## Definition -Credential concerning a verifiable Legal Entity Identifier, residing in the [GLEIS](GLEIS) and compliant with one or more of the GLEIF [Governance Framework](governance-framework)s \ No newline at end of file diff --git a/docs/04_glossary/vlei-ecosystem-governance-framework.md b/docs/04_glossary/vlei-ecosystem-governance-framework.md deleted file mode 100644 index 1e53f701..00000000 --- a/docs/04_glossary/vlei-ecosystem-governance-framework.md +++ /dev/null @@ -1,4 +0,0 @@ -# vlei ecosystem governance framework -## Definition -The Verifiable LEI (vLEI) Ecosystem [Governance Framework](governance-framework) 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. \ No newline at end of file diff --git a/docs/04_glossary/vlei-role-credential.md b/docs/04_glossary/vlei-role-credential.md deleted file mode 100644 index ac99eb14..00000000 --- a/docs/04_glossary/vlei-role-credential.md +++ /dev/null @@ -1,5 +0,0 @@ -# vlei role credential -## Definition -A [vLEI credential](vlei-credential) that attests a role. - -| TBW prio 3 | \ No newline at end of file diff --git a/docs/04_glossary/vrt.md b/docs/04_glossary/vrt.md deleted file mode 100644 index e0fbd0fc..00000000 --- a/docs/04_glossary/vrt.md +++ /dev/null @@ -1,3 +0,0 @@ -# vrt -## Definition -vrt = vdr rotate, verifiable data registry rotation diff --git a/docs/04_glossary/wallet.md b/docs/04_glossary/wallet.md deleted file mode 100644 index 9962ec0a..00000000 --- a/docs/04_glossary/wallet.md +++ /dev/null @@ -1,22 +0,0 @@ -# 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](keystore), 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](keystore) 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`](agency) 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)](verifiable-credential). 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)](verifiable-credential).\ -KERI explicitly distinguishes [keystore](keystore) and [wallet](wallet); the latter being a superset of the former. [Keep](keep) is KERI's and ACDC's user interface with Keripy agent API as a back end. - diff --git a/docs/04_glossary/watcher.md b/docs/04_glossary/watcher.md deleted file mode 100644 index bc28d2e6..00000000 --- a/docs/04_glossary/watcher.md +++ /dev/null @@ -1,6 +0,0 @@ -# watcher -## Definition -KERI alternative to total global ordering and consensus protocols is a mechanism called [duplicity](duplicity) detection. In the [verification](verifier) and [validation](validate) **watchers are all that matter**; they guarantee that logs are immutable by one very simple rule: "[first seen](first-seen) 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. \ No newline at end of file diff --git a/docs/04_glossary/web-of-trust.md b/docs/04_glossary/web-of-trust.md deleted file mode 100644 index 1886979e..00000000 --- a/docs/04_glossary/web-of-trust.md +++ /dev/null @@ -1,9 +0,0 @@ -# web of trust -## Definition - -In cryptography, a web of trust is a concept used in [PGP](PGP), [GnuPG](gnu-privacy-guard), 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 - -More on [Wikipedia](https://en.wikipedia.org/wiki/Web_of_trust) diff --git a/docs/04_glossary/weight-of-weights.md b/docs/04_glossary/weight-of-weights.md deleted file mode 100644 index 9b57997b..00000000 --- a/docs/04_glossary/weight-of-weights.md +++ /dev/null @@ -1,10 +0,0 @@ -# weight of weights -## Definition -There are 2 levels in the multi-sign weighted thresholds of [multi-signatures](multisig) in [KERI](KERI) 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](delegation)). - -## CESR related -It also gives the advantage that the resulting [CESR](CESR) 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. \ No newline at end of file diff --git a/docs/04_glossary/well-known-witnesses.md b/docs/04_glossary/well-known-witnesses.md deleted file mode 100644 index 4fc6f542..00000000 --- a/docs/04_glossary/well-known-witnesses.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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. \ No newline at end of file diff --git a/docs/04_glossary/witness.md b/docs/04_glossary/witness.md deleted file mode 100644 index 61ebc361..00000000 --- a/docs/04_glossary/witness.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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](trust-domain) and may be controlled (but not necessarily so) by its [controller](controller). The purpose of a pool of witnesses is to protect the controller from external exploit of its identifier. -The term _[Backer](backer)_ 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 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) \ No newline at end of file diff --git a/docs/04_glossary/xip.md b/docs/04_glossary/xip.md deleted file mode 100644 index 85cfd9e5..00000000 --- a/docs/04_glossary/xip.md +++ /dev/null @@ -1,6 +0,0 @@ -# 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) \ No newline at end of file diff --git a/docs/04_glossary/zero-trust-computing.md b/docs/04_glossary/zero-trust-computing.md deleted file mode 100644 index 964ca88a..00000000 --- a/docs/04_glossary/zero-trust-computing.md +++ /dev/null @@ -1,16 +0,0 @@ -# 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](zero-trust) \ No newline at end of file diff --git a/docs/04_glossary/zero-trust.md b/docs/04_glossary/zero-trust.md deleted file mode 100644 index 9bef971b..00000000 --- a/docs/04_glossary/zero-trust.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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. \ No newline at end of file