Review and request for clarification

[henkvancann]

My review point sequentially through the doc. But first: it's a remarkable piece of art / work that extends all prior work and design around KERI based or KERI invoked technologies. Well done, Philip. I can grasp it. Here are my two cents about the things I think deserve clarification.

1. First paragraph: 'This document specifies a design for public VCs only.' -> Explain briefly why private TELs are different and why this is a different topic.

2. TEL paragraph
   This explanation begs for a schematic infographic, but I am afraid that's not done in IETF specs?

3. VCR paragraph: 'A Public Verifiable Credential Registry (Registry) is a form of a Verifiable Data Registry' -> Me: where is the sugar? Shop owner: next to the salt! ...

4. VCR paragraph: 'Two types of TELs will be used for this purpose.' -> Be more specific, which two types do you refer back to? I think you mean iception vs. tracking, but could also be issuance vs. revocation, but it's not clear AT THIS POINT in the text. Later it becomes clear that you mean management vs. VC TELs.

5. management TEL paragraph: pls check definition https://github.com/trustoverip/acdc/wiki/registrar

6. Self Addressing Identifiers / Derivation paragraphs:
   a.. use the abbrev SAID too. Why? Because people might be confused: is this the same Self Addressing Identifier (SAID!) that's all over the place in ACDC?
   b. reference the more detailed IETF description of SAIDs and shorten these paragraphs. You don't need to repeat. If it's no repetition then tell me what it is and why you do it. At least it's not clear why SAIDs and its derivation come out of the blue in this IETF spec AT THIS POINT in the text.

7. Self-Addressing Identifiers in a TEL paragraph: typos in the first sentence makes it gibberish. What is 'wrt'?

8. Use Case paragraph:
   ' a lightweight, easy to understand use case ' Don't even go there :) for several reasons:
   a. it's not lightweight, it's not easy to understand
   b. New acronyms drop in (vLEI, you mean what? Should I know GLEIF?) without any explanation
   c. you introduce a mechanism "proof presentation" that hasn't been addressed so far.

9. Security Considerations paragraph:
   What is an Endorser?
   TEL events need to be placed in escrow -> first mention, what is it? (I know, but the reader doesn't)
   until an anchoring KEL event is seen for the TEL identifier. 'Is seen', do you mean 'first seen' or is first seen not relevant in countering DDOS? (afaik it is).

This spec is clearly still 'Under construction'. Hope you find the time to finish the spec and have some guidance from this review.

[henkvancann]

If Philip wants to use these remarks to create a new version of the spec one day, it can be kept open, if not it can be closed. These aren't remarks that I could offer in PR unfortunately