# Wallet Management Service

## Goals

The Wallet Management (micro)Service is a new service responsible for managing self sovereigh identities and their associated verifiable credentials (VCs) / verifiable presentations.

It has two key goals:
* abstracting the interaction with the self sovereign identities, and how they are stored in wallets. This also of course implies that the actual wallet implementation is hidden behind the service api
* isolating the dependencies for the wallet implementation from the dependencies of the Alkemio server.

The latter in particular is a key blocker for the integration of the current version of Jolocom's SDK - our initial wallet implementation. This helps both with conflicts in terms of shared dependency versions, as well as the choice for the docker image base version.

It also is simply good engineering practice to keep the key platform capabilities isolated in terms of run time dependencies.

## Current status
A proof of concept using the Jolocom 1.0 SDK was created in Q2 2021. This demonstrated the following key steps:
* Defining a Challenge State Modification VC that would grant the holder the privilege of updating the state of a Challenge
* Issuing of a VC of the above type, but specific to a particular Challenge, to an Agent representing a User
* Extending the Credential Based Authorization framework to be able to specify the holding of a VC for authorizing an action on a Challenge

Later the integration of the Jolocom SDK had to be removed due to conflicts in mutual package dependencies, as well as a choice related to the base dockerimage required for the Jolocom SDK to run.

## Roadmap
We are going to use R&D approach, de-risking SSI flows and protocols as there is a lot of uncertainty around how these intereactions are going to be mapped in Alkemio. Every sprint we will schedule a spike + prototype, leading to a new spike etc until we have enough knowledge about VC, SSI protocols, the needs of Alkemio customers and current wallet implementations on the market.

### Milestone 1: Platform issued VCs
The first milestone is to replicate the previously proof of concept functionality using a separate Wallet Manager microservice.

The high level design for this milestone is shown below:


This milestone has the following setup:
* Platform identity: used to issue VCs on behalf of the platform. This includes in this milestone being able to issue e.g. VCs for enabling Challenge state transitions. Note that as the issuer is an identity managed by the platform this milestone does not need to deal with managing external trust sources.
* VC Definitions: defined as part of the Alkemio server. Hard coded.
* Events: the sending / receiving of messages will be done using the platform message broker.
* Protocols: the only protocol supported is that needed for the issuing of new VCs.
* User held wallet: not in scope.
* External issuer: not in scope
* Performance: not a concern. This means that in this phase we do not look to e.g. cache the credentials in the Alkemio server, but instead retrieve them via the Wallet Manager each time the credential is required e.g. for Authorizing a Challenge state transition.

The interaction flow for the issuing of new VCs is shown below:

The work implied in this milestone includes:
* Defining the events and the associated payloads
* Updating the existing SSI Agent implementation to interact with the Wallet Manager service
* Ensuring that the logic within the SSI Agent waits for the response events before proceeding. This is needed to avoid having to deal with event correlation / interaction flow management on the server level.

### Future milestones / exploration
Beyond the initial milestone key aspects to be explored / designed are:
* Delegation / presentation of VCs held by a user to an identity managed by the platform for each user
* Definition / management of the trust frameworks, potentially per Hub / Challenge, for which SSI Assurance communities they trust
* Specification for how a particular VC can be used to authorize actions by a user on the platform. CBAS was our original intended component for that but that is not active at the moment so I want to also look at alternatives.

## Reference
https://en.wikipedia.org/wiki/Object-capability_model
https://w3c-ccg.github.io/zcap-ld/ + https://github.com/w3c-ccg/zcap-ld + https://github.com/digitalbazaar/zcapld
https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force