Roots Wallet Implementation Scope
Inspired on the layered Trust over IP model and Aries Interoperability Profiles, the objective of this document is to present the scope for RootsWallet first release following the layers defined in the technology side of the dual stack ToIP model:
The lowest layer is about DIDs, DID methods, Credentials primitive operations and storage. The initial proposal is to use did:prism for credential related operations (interaction with the ledger) and did:peer to establish peer-to-peer wallet communication. Under this assumption the following functionality will be developed:
-
DID method operations for did prism: Create, Update, Resolve, Deactivate and Publish
-
DID method operations for did peer: Create, Update, Resolve, and Deactivate
-
Credential operations (only for prism): Issue, Revoke and Verify
-
Key management service (KMS): Ideally all information stored in the wallet is encrypted at rest, some exceptions may apply when a value needs to be queried with a ‘like’ type of expression. KMS service will handle the private keys used for encryption of wallet data; Private keys should not be available to wallet code, the idea of the KMS is to manage the keys in a hardware component or software secure enclave, secured with biometric capabilities on the device.
-
Secure Storage: a wallet is a repository of identity related information; we have identified the following storage objects that need to be stored and managed by the wallet:
- Credential: Claims, proofs, and operation hashes
- Operational data: DID (URI), key paths, key pairs, and operation hashes
- Seed
Note: Aries wallets have the concept of Agent/Controller where the Agent is a standalone entity, and the controller can be a mobile/desktop/browser application that runs on top. Our implementation will have the agent and the controller fused together and we will call this entity the wallet.
The second layer is about wallet-to-wallet communication, here we only care about sending messages between wallets without worrying about the content. The target is to use DIDComm v2 for our implementation. Besides conforming to DIDCom v2, the goal for this layer is to also implementation the following protocols:
-
Out-of-band Protocol: Is the protocol to initialize a secure communication connection. This is done by presenting an invitation (QR Code, url, or json file) that includes, in plain text, a public key and a service endpoint. The invitee can use the public key to send encrypted data to the inviter through the service endpoint. (see 0434-outofband)
-
DIDComm Transports: DIDComm Messaging is designed to be transport independent, the target for the implementation is http(s) and websocket transport methods. (see 0025-didcomm-transports)
-
Route coordination: To coordinate routing configuration when a mediator is needed. (see 0211-route-coordination)
-
DID Exchange Protocol: this protocol is about establishing a pairwise connection between wallets. It happens after the out-of-band invitation has been accepted. The outcome is an exchange of DIDs and DIDDocs between the parties that later can be used for async communication. (see 0023-did-exchange)
-
Basic message protocol: Stateless basic messaging feature. (see 0095-basic-message)
-
Secure Storage: Layer 2 creates a need to store more data, namely a directory of DID Connections, Protocol State Machine, and transaction logs. By the async nature and potentially long reply times of DIDComm we believe is better to handle the protocol states on a db.
This layer is about managing verifiable credential formants and handling the negotiations required to perform higher level transactions. Here we deal with pre-defined protocols the participants need to follow to achieve a goal. Our target contemplates the implementation of:
- Issue Credential Protocol (see 0453-issue-credential-v2)
- Present Proof Protocol (see 0454-present-proof-v2)
Regarding the verifiable credential formats, we have identified the existence of the following ones:
- Indy AnonCreds, supports ZKP, ZKP predicates, selective disclosure, ZKP revocation, but doesn’t meet W3C standard
-
Json LD, meets W3C standard, has two types of signatures:
- LD Signatures: The presentation discloses the complete credential, no selective disclosure, no ZKP.
- BBS+: Supports selective disclosure, there is not yet a ZKP revocation capability, ZKP predicates are theoretically possible
- Plain Json, no support for ZKP neither selective disclosure. It is the format currently used by Atala PRISM.
For the first release we will implement plain Json. On future releases we will consider supporting additional formats.
The last layer is about user experience, UI design and additional functionalities like:
- Wallet backup/restore
- Internationalization
- Mobile application UI/UX