# Henk's feedback on envelope cli playlist

## General

Remarkable piece of work. My compliments. I haven't been able to oversee the full extent of this development yet, but it's multi applicable and new to me. My comments below may sounds critical, but they are not intented this way. I think the team have done a marvelous job and Wolff "owns" this topic in the vids, like he's been doing this for many years.

And then now the feedback you asked for.

### What's the purpose of the playlist?

It says:
> Envelope is a new "smart document" functionality that is part of the Gordian Architecture for cryptographic wallets. These efforts are led by Blockchain Commons for the blockchain and identity wallet communities. Envelope CLI is a reference tool for learning about and creating envelopes.

But what is this list exactly, why are we doing this and for who and why should I dig into this stuff?

What about this alternative summary:
> This is an educational resource for Digital ID experts. The list of videos addresses envelopes: a brand new development of Blockchain Commons for the blockchain and identity wallet communities.
> Envelope is a new "smart document" functionality that is part of the Gordian Architecture for cryptographic wallets.
> Envelope CLI is a reference tool for learning about and creating envelopes.
> Envelopes are not mandatory, just use them when needed in situations like non-correlation efforts, privacy preservation, selective disclosure, proven authenticity and alike.

### These vids are a great resource for a central *concepts* document and a central glossary (single point of definition)

Just an observation. See my [questions](#Questions) below to maybe do something with this.

### There is substantial overlap in design principles and development with KERI/ACDC

And that's not only in the name 'weboftrust', but also: blockchain-less, DIDs, SCIDs, CID (I think CID can be matched on "[universal](#universal-identity-theory)" identifier in KERIs world), etc.
The IETF ACDC draft uses some of the same terms as Wolff / Chris does (selective disclosure, non-correlation, etc, even envelops I think ) and it would be interesting the create a comparison of at least the meaning of the terms used in both worlds.

Two further remarks:
1. Because KERI is a minimal sufficient means design, I am very much interested how you where able to use parts of it, and not dispose of KERIs vital security features.
2. I'd love to see how we could study the integration of both via [CESR](https://github.com/WebOfTrust/ietf-cesr) and this is closely related to my topic for the next RWOT in The Hague.

## Introduction
[link to vid](https://www.youtube.com/watch?v=tQ9SPek0mnI&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=1)

I had a look at the Introduction to Envelopes. I was at the live presentation of this intro one night. I very much like the introduced symbols and analogies in the vid! Well done. However, I think we can do even more.

Have a look here what I've done with a presentation of a KERI / ACDC team member:
https://www.youtube.com/watch?v=GqjsRuu0V5A&t=876s

(there is also a version with burnt-in subtitles: https://www.youtube.com/watch?v=enBAgyKhXso&t=169s ).

What I've done:
1. Build a glossary of terms he uses, and relate them to the terms already known and used by ToIP and eSSIF.
2. Correct the auto generated subtitles and keep the timing right, take out the uhs and ahs.
2. Assign a level of understanding in a terms management sheet and generate https://hackmd.io/pv11Cne-TiG4zhXUS-T6IA, this links back to the vid. In the SHOW MORE under the video you can find these links too.
4. Now from the vid I am generating a Jekyll Site on Github Pages (not ready yet) that has context and level sensitive side bars. E.g. if I am a beginner ID expert I get more terms in the sidebar then when I am Daniel Hardman or Dave Huseby, who in imo are experts in SSI. A preview you can find [here](#preview-jekyll-site), I need a few months more to have this ready and keep it up to date using Github Actions.
5. I wrote [HowTos](https://github.com/WebOfTrust/WOT-terms/tree/gh-pages/howto)

### Preview Jekyll site
[here preview](https://weboftrust.github.io/WOT-terms/mydoc_about_ruby_gems_etc.html)
Only look at the sidebar, it is generated from the \
a. CESR context and \
b. starting level understanding (KERI-1).

This will approach give the opportunity to generate all kinds of glossary access next to for example whitepapers that are mostly indigestible for lots of people, even for experts.

## Envelope MVA (Minimal Viable Architecture) & Cryptographic Choices
[link to vid](https://www.youtube.com/watch?v=S0deyIHXukk&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=2)

Minute 4:00 CID is not explained.

### Verfication and validation
Minute 17:20 and onwards: Some interesting wording. A signature "checks" , "is it OK" etc. Hence Chris uses 'validates' where others would use 'verifies'.

I think it is important to standardise a bit and conform to what is more broadly common terminology in the SSI field. Could we at BCC distinguish **verfication** (cryptographically ok, check etc.) from **validation** more clearly and name the criteria for which situation we're either in 'validation' or 'verfication' and why this differs (if it does) from glossary definitions of some other umbrella orgs? Maybe we could add subtitles or burnt-in text to explain our choices of wording.

See eSSIF-lab:
- [verify](https://essif-lab.github.io/framework/docs/essifLab-glossary#verify)
- [verifier](https://essif-lab.github.io/framework/docs/essifLab-glossary#verifier)
- [validate](https://essif-lab.github.io/framework/docs/essifLab-glossary#validate)
- [validator](https://essif-lab.github.io/framework/docs/essifLab-glossary#validator)

At the WebofTrust org on Github, we've been able to partially sync with the definitions of ToIP/eSSIF-lab and define clearly the criteria why we deviate from those too. There's still lots more work to do in this area. witness & multisig are other words that cause confusion. Or most recently the word *credential*. See here the [resulting polemic](https://daniel-hardman.medium.com/response-to-kaliyas-being-real-post-13fddb9410f0).

## Envelope Privacy Requirements for Non-Correlation & Support Elision Redaction Reference (2022-08-17)

[link to vid](https://www.youtube.com/watch?v=ubqKJAizayU&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=3)

First Minute 0:50 : CID -> interesting to compare this with [Universal Identifier Theory](
https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf) and relate BCC's CID to the three main types of universal or common (synomym?; see [excerpt](#add-1:-Universal-identity-theory) below) identifiers and again name the criteria why CID is in or out.

Minute 26:50 and onwards : KERI solves the collision of namespacing problem or the secure attribution problem over the web without an intermediary (like a blockchain). So KERI-based DID (layer 3 ToIP) is less interesting to me then KERI-based DIDCOMM (layer 2 ToIP).

Minute 28:00 : "The interesting stuff we'd like to do with Musig" -> the things Chris describes can afaik already be done in KERI using pre-rotation, rotation and delegation. However KERI's multisig is still threshold-based and multiple public keys. Therefore my focus would be to investigate: can we use KERI identifiers for our CIDs and do the interesting stuff via a CESR adaptor for musig and / or agggregated Schnorr. I think we'd get best of both worlds a fully composable event streaming protocol (instead of CBOR*) and sophisticated multisign.

Minute 29:30 : The merges sound interesting, haven't heard of this in the ACDC meetings. Anyways, afaik lots of uncharted overlaps, and I'll take the lead to create an insight.

'* Here [my article](https://medium.com/happy-blockchains/cesr-one-of-sam-smiths-inventions-is-as-controversial-as-genius-d757f36b88f8) on why KERI could not use CBOR and had to design CESR.

## Envelope CLI Presentation (from Collaborative Seed Recovery Meeting 2022-08-07)

[link to vid](https://www.youtube.com/watch?v=JowheoEIGmE&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=5)

I attended this meeting, no further comments for now.

## Envelope CLI Q&A (from Collaborative Seed Recovery Meeting 2022-08-07)
[link to vid](https://www.youtube.com/watch?v=2MjcrKLEsSE&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=5)

I attended this meeting, no further comments for now.

## Envelope CLI - 1 - Commands Overview
[link to vid](https://www.youtube.com/watch?v=K2gFTyjbiYk&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=6)

Minute 10:30 and onwards. I think at this stage in the vid it would be good to touch the WHY of the fact that envelops keep the same digest, even if the content is changed (`elided`). Why is this an important feature. In which cases?

The same remark for `symmetric key encryption` and `signing` that follow in the vid: it'd be good to answer the question 'why are we doing this' because then it makes sense what I'm looking at.

A good example is the following `SSKR sharding` explanation where Wolff starts off with the WHY of it and then continues with the How and What, which is perfect.

`Adding salts` leaves us with the same question: why? Wolff briefly explains "because in certain cases you don't want the digest of the wrapped and non-wrapped envelops be the same". Which cases are we talking about?

## Envelope CLI - 2 - Examples
[link to vid](https://www.youtube.com/watch?v=LYjtuBO1Sgw&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=7)

Where is the CID rooted? The CID has no way of changing control over it or delegate it to somebody else and keeping that key state publicly verifiable?

As I go I start to understand the audience of this vid list: it proofs to experts that envelops are complete, mixable and mashable and serve confidentiality and privacy (correlation prevention). They also serve a spectrum of thinkable applications. A great solution knowing that there's plenty of problems out there that it can tackle. \
But we might need to explicitly describe the WHYs and killer apps to address other target groups than SSI experts.

## Envelope CLI - 3 - Elision in detail
[link to vid](https://www.youtube.com/watch?v=3G70mUYQB18&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=8)

No further remarks; a clear use case and we know why we're doing this.

## Envelope CLI - 4 - Distributed identifier
[link to vid](https://www.youtube.com/watch?v=3G70mUYQB18&list=PLCkrqxOY1FbooYwJ7ZhpJ_QQk8Az1aCnG&index=8)

Isn't DID *decentralised* identifier instead of *distributed* identifier?

Alice starts with a signed DID Doc and the sig is hooked at a registrar... so we trust a centralised party.\
Where is Alice's CID rooted?

How do you know that it's really Alice that is signing in the example challenge and not somebody else that took or got control over her identifier? How has the keystate of Alice's CID been registered between the moment of signing the DID Doc and the actual challenge?

## Questions
1. is there a central doc discussing the design principles and concepts of BCC (I found this: https://www.blockchaincommons.com/projects.html)
2. is there a general purpose glossary for BCC yet, if so where would that be?
3. who is working on concepts, terminology and glossaries at BCC and syncs developments with ToIP and / or ESSIF-lab?

## add 1: Universal identity theory
An excerpt from recent meeting minutes concerning Sam Smith's paper: Universal Identifier Theory.
https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf

### Three types of identifiers we care about
- 1. Cryptonomous Identifier. Self certifying. Derived from pub/priv key pairs
- [Transferable](https://github.com/trustoverip/acdc/wiki/transferable-identifier) vs [Non-transferable](https://github.com/trustoverip/acdc/wiki/non-transferable-identifier) identifiers ([persistent](https://github.com/trustoverip/acdc/wiki/persistent-identifier) vs ephemeral)
- 2. Public Identfiers that are not cryptonomous. DNS domain, social security number, etc. (Non-cryptographically generated ID)
- 3. Local Identifiers, Aliases. Only have meaning to a local entity. Not shared, avoids collisions.
- Pet Names: Take local identifiers and share them with "friends". Trying to solve Zooko's Triangle.
- https://en.wikipedia.org/wiki/Zooko%27s_triangle
- Can be solved with an identifier graph.
- Problem with collisions.
- To solve the problems with #2 you have a trust domain. You place each identifier in a trust domain resolved by the cryptonomous identifiers associated in the trust domain. This avoids the need for a centralized registry or locus of control. Because we solved the collision problem of namespacing.
- Multi-factor association of loci of control. For example, GLEIF will publish the root of trust to multiple public sources. The set of these publication has loci of control which allows us to bootstrap the root of trust.