# 07.07.2021 Risk Assessment Meeting Notes
###### tags: `risk assessment`
## Notes

Question: Identity Life Cycle for the ONCE wallet already established?
Probably only an implicite life cycle defined. We discussed some aspects of the SSI identity lifecycle (creation, update, revocation) during this call

---
## Life Cycle
### 1. Wallet / Self-Sovereign Identity creation
Eugeniu presents document: https://www.notion.so/jolocom/SSI-Identity-Creation-70e886ac3ee54e5da4f836a7e1e61eee

- A **seed** value based on entropy (random values) is collected from OS and possibly using user input as well
- A set of pub/private keys are derived from the entropy (possibly using Heirarchical Derivation)
- The DID is derived from the public key
- Depending on the DID method used, the DID is "anchored"
- for example with `did:jolo` the anchoring is a transaction done on the Ethereum chain
- for ex. with `did:jun` / `did:keri` / `did:peer` the anchoring is simply creation of a self-signing message called the "inception event" that is stored locally and exchanged with other parties during interaction
- Private keys are encrypted and stored on the device locally. The encryption password is provided by the device OS and protected by a local PIN / Password setting, and optionally biometrics
- The "seed" value is converted to a twelve word mnemonic (BIP39) and displayed to the user who is asked to save the value in a safe place
- this value (or its mnemonic) can be used to rederive the private key that controls the identity

### 2. Wallet / Self-Sovereign Identity update and deactivation
**Key rotation** is realised by creating a key [rotation event](https://github.com/decentralized-identity/keri/blob/master/kids/kid0003.md#rotation-event--also-delegating-rotation) and persisting it locally (alongside the previously created identity inception event). The new event can be shared with the services / entities as part of future interactions. The services will have an updated view / understanding of the keys associated with the DID.

*An open question here would be -- how is the user incentivized to rotate their keys, or can the ONCE wallet do this automatically at specific recommended intervals?*

**Revocation / deactivation** of a DID is realised as a rotation to an empty set of keys. A ONCE wallet user could trigger this process (e.g. by starting the appropriate flow from the settings menu) at any point. The revocation event can be propagated to relevant services (akin to the key rotation event). Future interactions initiated by a deactivated DID will fail / be rejected by the service.

- This message can be interpreted as a end of life message, makes services aware of deactivated DIDs (with empty rotation message)
- can be triggerd by user (DSGVO)

#### Summary
local derivation of key pairs based on local seed
DID, inception event (public)
keys and DID, stored locally encrypted

seed (or mneomic) are able to restore wallet (key material)
seed is never stored in the wallet (currently), lost/stolen Phone threat, no possibility for an attacker to rotate keys

2. Domain specific Credential creation

Issuing Verifiable Credential by external system
- "this DID has this attribute"
- 3 exchange flows, that are quite similiar
- issue by someone else (credential issuance protocol [defined here](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2))
- presenting a credential (credential presentation protocol [defined here](https://github.com/hyperledger/aries-rfcs/tree/9363159d517afa3c17a79b5d8394e933c652de84/features/0454-present-proof-v2))
- issuing to oneself (no protocol needed, local operation, shown in this ["DFD / Sequence Diagram"](https://drive.google.com/file/d/1UTaYtHsC8wW5P08v6hMgdfFUcffiKjv8/view?usp=sharing))

communication between Wallet and SSI Domain (Provisioning Service)

offer message - nohing of value contained (maybe callback url). The offer messages can be assumed to be public, i.e. they contain no important assets / private info

request credential - signature over message contained
issue credential message - signed credential
messages are encrypted and signed one layer up but part of the protocoll ([DIDComm](https://identity.foundation/didcomm-messaging/spec/) -> Technology)

Safe Issuer?
Additional Infrastructure. Compliance,Governance. Trust needs to be bootstraped, i.e. hardcoded.

Next topics, eID creation and communication with external systems