This POC describes the initial scope of Nessus DIDComm - an SSI agent that uses DIDComm-2.0 to communicate with other agents (e.g. Aries Cloud Agent Python)
Alice, a citizen of British Columbia has graduated from Faber College some time ago. Faber College, well situated at the heart of emerging tech, has since adopted a form of digital transcripts that it now offers to its former students. These transcripts are verifiable credentials, which are a key feature of Self Sovereign Identity. Alice has since moved to Munich, which provides access to EBSI services for its citizens.
In SSI terms, Faber is an Issuer of verifiable credentials (VC) and Alice is a Holder. Alice may later apply for a job with Acme Corp, which then becomes a Verifier in our Trust Triangle
All three parties need to agree on reliable/secure communication, which DIDComm Messaging is well suited for. Faber uses AcyPy and registers the necessary cryptographic material on the VON Network. Alice is not known to the VON Network, neither does she have access to a Hyperledger Aries compliant agent. All parties communicate via DIDComm alone and use common standards to exchange information.
- Out of Band Invitation from Faber to Alice and vice versa
- DID Exchange between Faber & Alice
- Alice creates peer-to-peer Dids to communicate with Faber and Acme
- Plaintext Message exchange
- Signed Message exchange
- Encrypted Message exchange
- Anything else?
- Support for W3C Verifiable Credentials
- Support for Aries Verifiable Credentials (maybe)
- Closely work with Aries on AIP3.0
- Credential revocation
- Anything else?
- Nessus DIDComm is written in Kotlin
- For DIDComm Messages it uses didcomm-jvm from SICPA
- For integration with AcaPy it uses acapy-java-client
- For integration with EBSI is uses waltid-ssikit
- Integration with Apache Camel to supplement/replace nessus-aries
PRs, Issues, Comments all welcome
cheers -- thomas