# Roadmap KERI and ACDC

**"More than three will confuse the troops"**

This is the roadmap, the progress and links to (intermediate) results KERI and ACDC

## Parts and boundaries
1. what’s the vLEI and what’s KERI? - it's hard to do this and a continuous effort
2. Key management (storage & rotation)
3. presistent Identifier systems (where are we?) - versioning will do the trick, but we have to write how

## Status of implementation
1. What has been implemented?
2. On which platform?
3. Is it working?

## Stages in the deepening process
1. familiar with KERI
2. easy CLI to demo (Docker)
3. do a basic reference implementation (you need a usecase)

## Usecases
1. what would you do with KERI if you had it? (a dangerous question to have answered by individuals, when we haven't sorted out the reversed engineered [concepts](https://github.com/WebOfTrust/WOT-terms/blob/gh-pages/concepts.md) nor the other bulletpoint above of this Roadmap)
2. How does KERI/ACDC relate to other developments (DID COMM, BCC envelopes)
3. {one more?}

### Associated Specifications

All deliverables of the KERI Community or shown in the KERI [README](https://github.com/WebOfTrust/keri#keri-community-development-efforts) file.

## Status of implementation
Is it working?
1. planned
2. **started**
3. tested
4. in acceptance
5. accepted (working!)
6. in production (working!)
7. deprecated

### Criteria for 'Is it working?!'
1. **What** is it
2. **Who** is doing it
3. with **What** resources or tooling
4. **When** is it being done
5. and **Why**?

This might have some similarities with *expectation management* as a part of *contract management*.

The simple question "Is it working?" is the hard problem of the **definition of done** in a multiple sided situation.
Every individual criterium listed above influences the outcome of the other four bullet points.
> Example: a student programmer, who is unit-testing a newly programmed piece of software for educational reasons has a different view on the *definition of done* than a [QAR](https://github.com/trustoverip/acdc/wiki/qvi-authorized-representative) who is using the production site while having a customer on the phone.

### SMART objectives
So, we need to funnel the answers to these question into a *definition of done* that is feasible and measurable. We apply the SMART method by George T. Doran. Making objectives SMART means they need to be: Specific, Measurable, Assignable, Realistic and Time-related. Completing the elements ensures you have got the basic goal definition right. SMART is not a guarantee for success yet unspecific objectives are a guarantee for suboptimal results. [Source](https://boardview.io/blog/get-smart-in-defining-smart-goals/)
• Specific – target a specific area for improvement.
• Measurable – quantify or at least suggest an indicator of progress.
• Assignable – specify who will do it.
• Realistic – what results can realistically be achieved, given available resources.
• Time-bound – specify when the result(s) can be achieved.

**But something's starting to not feel quite right here...**

##### Beware: "The best helmsmen stand on shore"
WebofTrust is an open source initiative. *Few, if any, are hired and thus have no direct obligation to deliver*; no a fixed scope, fixed time, nor fixed price. So please be prudent with expectations. The more you deliver tangible results yourself the more your feedback will fall into the right spot and the more your voice will be heard. The more you pay upfront ... this might work too, however no guarantees it will.

#### SMART Objective Table

> **Legend and fill**
> Acronym: link + last modified date "row upd."
> Specification: status + a link
> Technical Design: status + a link
> Coding Python: status + a link
> Coding Rust: status + a link
> Lead( programmer)s: github usernames
> Report/Notes: version number + links to commits
> Next date: dates as to when we can expect the most wanted features to be implemented
> n.a.: not applicable

| Acronym | Specification | Technical Design | Python | Rust | Leads | Report/Notes | Next date |
|---------|---------------|------------------|--------|------|-------|--------------|-----------|
| [KERI](https://github.com/trustoverip/acdc/wiki/key-event-receipt-infrastructure) | TESTED-3 [IETF KERI Draft](https://github.com/WebOfTrust/ietf-keri) ||||@SmithSamuelM| ||
| [DID KERI](https://github.com/trustoverip/acdc/wiki/decentralized-identifier) | PLANNED-1 [IETF DID KERI Method Draft](https://github.com/WebOfTrust/ietf-did-keri) |||| @pfeairheller | ||
| [DID KERI W3C Reg](https://github.com/trustoverip/acdc/wiki/decentralized-identifier) | PLANNED-1 [Registration](https://github.com/w3c/did-spec-registries/blob/main/methods/keri.json) ||n.a.|n.a.| @pfeairheller | ||
| [SAID](https://github.com/trustoverip/acdc/wiki/self-addressing-identifier) | TESTED-3 [IETF SAID Draft](https://github.com/WebOfTrust/ietf-said) |||| @SmithSamuelM | ||
| [ACDC](https://github.com/trustoverip/acdc/wiki/authentic-chained-data-container) | ACCEPTED-5 [IETF ACDC Draft](https://github.com/trustoverip/tswg-acdc-specification) |||| @SmithSamuelM | ||
| [PTEL](https://github.com/trustoverip/acdc/wiki/public-transaction-event-log) | PLANNED-1 [IETF PTEL Draft](https://github.com/WebOfTrust/ietf-ptel) |||| @pfeairheller | ||
| [IPEX](https://github.com/trustoverip/acdc/wiki/issuance-and-presentation-exchange-protocol)| STARTED-2 [IETF IPEX Draft](https://github.com/WebOfTrust/ietf-ipex) |||| @SmithSamuelM, @pfeairheller | ||
| [OOBI](https://github.com/trustoverip/acdc/wiki/out-of-band-introduction) | [IETF OOBI Draft](https://github.com/WebOfTrust/ietf-oobi) |||| @SmithSamuelM |||
| [CESR](https://github.com/trustoverip/acdc/wiki/composable-event-streaming-representation) | ACCEPTANCE-4 [IETF CESR Draft](https://github.com/WebOfTrust/ietf-cesr)|[CESROX Roadmap](https://hackmd.io/W2Z39cuSSTmD2TovVLvAPg?edit)|planned|planned| @SmithSamuelM, @kentbull | [CESROX Meeting Notes](https://hackmd.io/UQaEI0w8Thy_xRF7oYX03Q?edit) | 2022-10-13|
| [CESR Proof](https://github.com/trustoverip/acdc/wiki/cesr-proof-signatures)| status unknown [IETF CESR Proof Signatures Draft](https://github.com/WebOfTrust/ietf-cesr-proof) |||| @pfeairheller | ||
## Branches other implementations
| Acronym | Main | Dev | Other 1 | Other 2 | Instructions| Staging lead | Notes |
|---|---|---|---|---|---|---|---|
| [KEEP](https://github.com/trustoverip/acdc/wiki/keep) | ACCEPTED-5 [KEEP repo](https://github.com/WebOfTrust/keep) |||| @m00sey |||
| [GLOS](https://github.com/trustoverip/acdc/wiki) (row upd. 2022-10-20) | ACCEPTED-5 ToIP-#concepts-terminology-wg group [Concepts.md](https://github.com/WebOfTrust/WOT-terms/blob/1635c60d78849c8f3a33cb2641da37880136cd99/concepts.md) |TESTED-3 - Continuous dev in ToIP-#ctwg-toolkit-dev group [ToIP/toip](https://github.com/trustoverip/toip)|n.a.|n.a.| @henkvancann |continuous development, continuous integration using Github Actions|2022-12-03 to PRODUCTION-6 |
| [GHKP](https://weboftrust.github.io/keep/)| |||n.a.| @m00sey |||
| [GHWP](https://weboftrust.github.io/WOT-terms/) (row upd. 2022-10-20) | STARTED-2 [Jekyll static site](https://weboftrust.github.io/WOT-terms/) and [Jekyllrb.com](https://jekyllrb.com) |PLANNED-1 - CDCI with [Github action](https://github.com/WebOfTrust/WOT-terms/actions): shell script atuomation|n.a.|n.a.| @henkvancann |continuous development, continuous integration using Github Actions|2022-11-3 to TESTED-3 |

#### Technology Readiness Level

The Technology Readiness Level (TRL) is a measurement for the **maturity of a technology** developed by NASA. The values range from 1 to 9 with increasing values meaning increased maturity. In short these levels describe:
- TRL 1: scientific research is beginning and those results are being translated into future research and development
- TRL 2: basic principles have been studied and practical applications can be applied to those initial findings, little to no experimental proof of concept for the technology
- TRL 3 : active research and design begin, often a proof-of-concept model is constructed
- TRL 4 : proof-of-concept technology is ready, multiple component pieces are tested with one another
- TRL 5 : technology is identified as a breadboard technology and must undergo more rigorous testing
- TRL 6 : technology has a fully functional prototype or representational model
- TRL 7 : technology requires that the working model or prototype be demonstrated in a space environment
- TRL 8 : technology has been tested and "flight qualified" and it's ready for implementation into an already existing technology or technology system
- TRL 9 : technology has been "flight proven" during a successful mission

More information on TRL can be found [here](https://www.nasa.gov/directorates/heo/scan/engineering/technology/technology_readiness_level).

The TRL of various technologies in the table (represented in rows) are given and are based on the implementation support for that technology.

## Branches PYTHON implementation

> **Legend and fill**
> Acronym: link + last modified date "row upd."
> Main: production branch + a link [+ TRL]
> Dev: development branch + a link [+ TRL]
> Other 1: (optional) name branch + description + a link
> Other 2: (optional) name branch + description + a link
> Instruction: how to create a working environment
> Staging Lead: github username
> Notes: {free field}
> n.a.: not applicable
>
| Acronym | Main | Dev | Other 1 | Other 2 | Instructions| Staging lead | Notes |
|---|---|---|---|---|---|---|---|
| [KERI](https://github.com/trustoverip/acdc/wiki/key-event-receipt-infrastructure) (row upd. 2022-09-22)|[Main](https://github.com/WebOfTrust/keripy/tree/main)|[Development](https://github.com/WebOfTrust/keripy/tree/development)|||@SmithSamuelM||Contains KERI Core Lib, CLI, Agent. Future goal to split Agent into sep. repo|
| [DID KERI](https://github.com/trustoverip/acdc/wiki/decentralized-identifier) | |||| @pfeairheller | ||
| [DID KERI W3C Reg](https://github.com/trustoverip/acdc/wiki/decentralized-identifier) | ||n.a.|n.a.| @pfeairheller | ||
| [SAID](https://github.com/trustoverip/acdc/wiki/self-addressing-identifier) (row upd. 2022-09-22)|[Main](https://github.com/WebOfTrust/keripy/tree/main)|[Development](https://github.com/WebOfTrust/keripy/tree/development)||| @SmithSamuelM | | Part of KERI Core lib in main repo|
| [ACDC](https://github.com/trustoverip/acdc/wiki/authentic-chained-data-container) (row upd. 2022-09-22) |[Main](https://github.com/WebOfTrust/keripy/tree/main)|[Development](https://github.com/WebOfTrust/keripy/tree/development) ||| @SmithSamuelM | |Part of KERI Core lib in main repo. Plans to split into sep. repo|
| [PTEL](https://github.com/trustoverip/acdc/wiki/public-transaction-event-log) (row upd. 2022-09-22)|[Main](https://github.com/WebOfTrust/keripy/tree/main)|[Development](https://github.com/WebOfTrust/keripy/tree/development)||| @pfeairheller | ||
| [IPEX](https://github.com/trustoverip/acdc/wiki/issuance-and-presentation-exchange-protocol)| |||| @SmithSamuelM, @pfeairheller | ||
| [OOBI](https://github.com/trustoverip/acdc/wiki/out-of-band-introduction) (row upd. 2022-09-22)|[Main](https://github.com/WebOfTrust/keripy/tree/main)|[Development](https://github.com/WebOfTrust/keripy/tree/development)||| @SmithSamuelM |||
| [CESR](https://github.com/trustoverip/acdc/wiki/composable-event-streaming-representation) (row upd. 2022-09-22)|[Main](https://github.com/WebOfTrust/keripy/tree/main)|[Development](https://github.com/WebOfTrust/keripy/tree/development)||| @SmithSamuelM ||Part of KERI Core lib in main repo|
| [CESR Proof](https://github.com/trustoverip/acdc/wiki/cesr-proof-signatures) (row upd. 2022-09-22)|[Main](https://github.com/WebOfTrust/keripy/tree/main)|[Development](https://github.com/WebOfTrust/keripy/tree/development)||| @pfeairheller | ||

## Branches other implementations
| Acronym | Main | Dev | Other 1 | Other 2 | Instructions| Staging lead | Notes |
|---|---|---|---|---|---|---|---|
| [KEEP](https://github.com/trustoverip/acdc/wiki/keep) (row upd. 2022-09-22) | [Main](https://github.com/WebOfTrust/keep/tree/main) |[Development](https://github.com/WebOfTrust/keep/tree/development)||| @m00sey |||
| [GLOS](https://github.com/trustoverip/acdc/wiki) (row upd. 2022-09-10) |[Main](https://github.com/trustoverip/acdc/wiki) TR5 |[backup](https://github.com/henkvancann/acdc/wiki) TR4||| @henkvancann ||continuous development, continuous integration using Github Actions|
| [GHKP](https://weboftrust.github.io/keep/) | |||n.a.| @m00sey |||
| [GHWP](https://weboftrust.github.io/WOT-terms/) (row upd. 2022-09-10) | [GitHub WOT-terms Pages](https://github.com/WebOfTrust/WOT-terms/tree/gh-pages) TRL4 |[Test](https://github.com/henkvancann/WOT-terms/tree/gh-pages) TRL3 |[Main WOT](https://github.com/WebOfTrust/WOT-terms/tree/main)|[Dev Main](https://github.com/henkvancann/WOT-terms/tree/main)| @henkvancann ||continuous development, continuous integration using Jekyll Github Actions||

## Branches RUST implementation
{TBW after the PYTHON table has matured}

# Concept

## [What is this](#)?
1. the roadmap of the KERI & ACDC suite
2. parts planning, status, and scope
3. external connections (developments elsewhere)

## [Why this page](#)?
1. to have a roadmap
2. to be able to measure progress 
3. to be able to monitor changes over time

## [For Whom](#)?
1. all Identity experts
2. operational managers
3. product developers

## [How](#)?
1. HackMD file
2. static site generated on Github 
3. can be searched and commented on

## [When](#)?
1. {asap?}
2. after adoption by a problem holder

# Core Value of a roadmap

## [Practical values](#)
- mor4 transparency
- timing oportunity
- easier access to eductional resources

# Roadmap

## Parts and boundaries
1. what’s GLEIF and what’s KERI?
2. Key management (storage & rotation)
3. presistent Identifier systems (where are we?)


## Status implementation
1. What has been implemented?
2. On which platform?
3. Is it working?

## Stages
1. familiar with KERI
2. easy CLI to demo (Docker) 
3. do a basic reference implementation

## Usecases
1. what would you do with KERI if you had it?
2. How does KERI/ACDC relate to other developments (DID COMM, BCC envelopes)
3. {one more?}