Today, Spruce is open-sourcing under the Apache 2.0 license an early developer release of Credible (GitHub repository here), a native mobile wallet for W3C Verifiable Credentials and Decentralized Identifiers built on DIDKit and Flutter. We were able to package the DIDKit library written in Rust into a Flutter application running on both Android and iOS, using C bindings and Dart’s FFI capabilities. A special thank you to brickpop/flutter-ffi-rust for paving the way in the use of this technique, which inspired our own implementation’s architecture.
Who this is for
We believe that there will be no “one size fits all” credential wallet because the user experience must be appropriately tailored to each use case. Workflows involving trusted information tend to be extremely sensitive to context, with vast differences in the kinds of information used, methods of verification, and user interfaces from situation to situation. For example, the following use cases will demand completely different interfaces:
- A hospital wants to allow its qualified medical staff and pharmacists to digitally sign and verify prescriptions, respectively.
- A trading desk wants to set position limits based on a trader’s digital authorizations issued by the firm.
- A user wishes to demonstrate their history of transactions with a merchant, granting them special status and benefits at another venue through a commercial partnership.
Comparing just these three, there’s a lot of variety that no single user experience can truly satisfy. They all share a need to make important data verifiable and portable, but the difference in their user experiences shows how unlikely it is for one overarching “wallet interface” to rule them all.
Instead, we are striving to build a solid, general-purpose technological foundation suitable to be tailored for specific use cases and workflows. This is the wallet counterpart to the rich, growing toolkit supplied by DIDKit, the two pillars of a reference architecture for creating trusted interactions at scale.
Credible’s core technologies: VCs and DIDs
Verifiable Credentials (VCs) are a cryptographically-signed, contextualized, and highly portable data format used to represent beliefs about reality, such as someone’s educational certifications, employment history, and licenses. They can also be used to represent beliefs about non-person entities (NPEs) such as code repositories, IoT devices, and data sets. Credible brings the ability to receive with, safely store in, and present VCs from your smartphone, making them truly yours.
Decentralized Identifiers (DIDs) are a kind of URI that can be universally resolvable across the Internet, public blockchains, and other data sources. They are used in conjunction with a DID method to establish public key-based control authority of a “DID controller” and enable service discovery of “service endpoints.” People may manage several DIDs each to keep different aspects of their life separate and private. DIDs may also be managed by non-person entities, such as software agents, industrial equipment, and computer servers. Credible currently supports the use of a single DID from your smartphone, with multi-DID support on the roadmap.
VCs and DIDs may be used together in powerful patterns, built from the fundamental issuance, storage, verification, and revocation workflow. DIDs can be used to cryptographically sign VCs, and because most DIDs can be resolved to their public keys, anyone can then verify the produced VC as authentic and tamper-proof, thereby increasing their trust of the information inside. Credible currently supports the use of DIDs to request, store, verify, and present VCs. Future versions of Credible will also allow for issuance and revocation.
Credible ships out of the box with support for the Tezos DID method, which we have jointly authored with the Tezos ecosystem. The development of this DID method, as described in our DIDKit release post, will be able to take full advantage of future protocol upgrades on the Tezos public blockchain to provide best in class decentralized identity-specific support across the whole stack, down to the VM bytecode. We especially look forward to the use of shielded transactions to increase privacy while retaining the availability of DID resolution, and the use of tickets to allow for sophisticated on-chain permissioning while exercising DID document control.
Currently, the only server interactions that Credible will make are through URLs scanned from QR codes. The user must explicitly consent to dereferencing the URL before any connection is made.
What’s currently supported
Connections over QR codes containing URLs
- Fetch and Send CredentialOffers over HTTPS
- Receive Verifiable Credentials over HTTPS
- Store Verifiable Credentials
- View Verifiable Credentials Details
- Send Verifiable Presentations with embedded Verifiable Credentials over HTTPS
- Basic information
- Placeholders for notices, privacy policies, etc.
- Issue Verifiable Presentations containing Verifiable Credentials
- Verify Verifiable Credentials
- Key generation (via ring)
- Key export (via BIP39)
- did-tezos (1 layer of resolution for tz1)
DID method resolution
- did-tezos (1 layer of resolution for tz1)
What’s next for Credible
- Cross-platform continuous integration testing for Android and iOS
- TestFlight and Play Store Beta releases
- Full did-tezos implementation (3 layers of resolution and smart contract-based management across tz1/tz2/tz3)
- did-web support on Credible (we must either package openssl to Flutter or allow did-web to use ring via rustls)
- Support for multiple DID management
- Flutter Web through DIDKit in WASM
- Flutter Desktop with a desktop native user interface
- DIDComm or TorGap support to allow two Credible instances to broker and maintain secure communications based on DIDs.
- OpenID Connect SIOP v2 support to serve as the IdP in a SIOP interaction
- Support for Presentation Exchange
- Support for Universal Wallet Interop Spec
Follow us on Twitter
Follow us on LinkedIn