did:(customer)
Transmute’s evolving criteria for matching DID methods to business requirements.
Transmute builds solutions that solve real business problems. For this reason, we support a number of different decentralized identifier (DID) methods. While we are committed to providing optionality to our customers, it’s equally important to communicate the selection criteria behind these options so that customers can consider the tradeoffs of underlying DID-methods alongside the problem set they’re solving for. Essentially, we help them pick the right tool for the job.
In the spirit of sharing and improving as an industry, here are the work-in-progress criteria we use to help customers assess what DID method is best for their use case:
Interoperability
This DID method meets the interoperability requirements of my business, for example:
- Other parties can verify my DID method.
- I can switch out this DID method in the future if my business needs change.
Security
This DID method meets the security requirements of my business, such as:
- Approved cryptography for jurisdiction/industry
- Ledger/anchoring preferences
- Key rotation/revocation
Privacy
This DID method meets privacy requirements relevant to my use case, for example:
- Identifiers of individuals (data privacy and consent priorities)
- Identifiers for companies (organization identity and legal protection priorities)
- Identifiers for things (scaling, linking, and selective sharing priorities)
Scalability
This DID method meets the scalability needs of my business use case, for example:
- Speed
- Cost
- Stability/maturity
Root(s) of Trust
This DID method appropriately leverages existing roots of trust that have value for my business or network (or it is truly decentralized). For example:
- Trusted domain
- Existing identifiers/ identity systems
- Existing credentials
We are currently using and improving these criteria as we co-design and implement solutions with customers.
For example, our commercial importer customers care a lot about ensuring that their ecosystem can efficiently use the credentials they issue (interoperability) without disclosing sensitive trade information (privacy). Government entities emphasize interoperability and accepted cryptography. Use cases that include individual consumers focus more on data privacy regulation and control/consent. In some instances where other standardized identifiers already exist, DIDs may not make sense as primary identifiers at all.
Examples of DID methods Transmute helps customers choose from today include: Sidetree Element (did:elem, Ethereum anchoring), Sidetree Ion (did:ion, Bitcoin anchoring), Sidetree Photon (did:photon, Amazon QLDB anchoring), did:web (ties to trusted domains), did:key (testing and hardware-backed keys), and more.
How do you think about selecting the right DID method for the job?
Let’s improve this framework together.
