In April, I proposed a more accessible set of tools for developers working in SSI to use. I called it Simple SSI. I also announced simple-cesr, a simple, limited, true-to-spec implementation of the CESR protocol. My argument then centered on simplicity and ease of use. Today, I’d like to look at another critical aspect of good software development: composability.
In my view, there are four broad flavors of SSI:
- Hyperledger/Aries/Anoncreds/
- ISO 18013/mDL
- OID4VC/JWT/SD-JWT
- KERI/ACDC
Each of these has rich (if not always easy-to-use) toolsets. These are inevitably focused internally, i.e., keri-py won’t help you issue a JWT. We need a composable set of tools scoped for SSI as a whole. The did:tdw spec is the latest example to blend concepts associated with different flavors SSI. As SSI enters the real world, I predict this trend will accelerate. The best ideas from within SSI will be blended in sensible ways. This calls for a different approach to tools.
I launched simple-signer last week. Eventually, I intend it to be a library that just signs stuff and supports any relevant signing protocol. The concept of signing data is central to the SSI domain regardless of any broader protocol details. It is wise to abstract this functionality away since it is needed in every case, and specifics will vary from case to case. Similar concepts to abstract away might include:
- Encryption
- Key
- Credential/Schema
- Resolver
- Transport
- Etc. (A more considered analysis of the SSI domain is necessary before locking any of these categories down).
With a comprehensive set of libraries such as these, it would become trivially easy to compose compelling solutions using the best ideas. This flexibility will be necessary as we build more real-world SSI applications.
