In this post we will show that Daml’s identity model is able to provide the same degree of security as systems built on a user experience that focuses almost exclusively on cryptographic identity while also providing a superior user experience and better flexibility in terms of deployment options:
- Decentralized – Entities can run ledger nodes, which are equivalent to miners in blockchains, and provide full cryptographic security, verifiability, and uninterrupted network access.
- Network aaS – Entities can run participant nodes, which are equivalent to full nodes in blockchains. They get the same cryptographic security and verifiability, but rely on a third-party ledger node for access to the network.
- Ledger API aaS – Entities can consume the Ledger API as a service, which at best provides verifiability of the ledger and non-repudiation for the API host. This is loosely similar to running a Light node in blockchain.
- Solution aaS – Entities can consume Daml applications as a service, which is the same as consuming any other hosted application, or accessing blockchains via a web wallet.
Each of these options provides its own tradeoff between operational complexity and security, and different models can be mixed and matched within the same network. Before diving deeper into these, and exploring what participant nodes are, or how security is guaranteed in Daml, we need to take a step back and ground this discussion by revisiting identity on the types of systems Daml targets: Blockchains, Distributed Ledgers, and databases (with or without inbuilt cryptographic signing and verifiability)
Identity on Ledgers
We will call these “ledgers” collectively regardless of whether they are in any way distributed or not.
All these systems function fundamentally the same:
- An identity is a public key (or a hash of one).
- Any write operation – usually called a transaction – is accompanied by cryptographic signatures, signed with the private keys corresponding to public keys.
- There are some rules, which govern which signatures are needed on a transaction to be valid. These rules can be access rules in the (cryptographic) database or smart contract on a blockchain, for example.
The entities running the ledger – let’s call them ledger operators – and those that have an identity on the ledger – let’s call them users – are usually not the same. Typically there are a lot more users than ledger operators, and nobody trusts anybody. Users don’t trust each other. Users don’t trust ledger operators. Ledger operators don’t trust users. And in many cases, ledger operators don’t trust each other.
The identity scheme serves three main purposes:
- Authorization – Anyone – both ledger operators and users – can establish the identities of the requesters of a transaction and check whether they are authorized to write that transaction.
- Non-repudiation – Once a transaction is signed and submitted, anyone – both ledger operators and users – can prove that the signing user did indeed sign that transaction.
- Verifiability – Users can verify that exactly the transaction that they requested and signed have been recorded.
Put differently, the ledger operators can reject invalid transactions, and prove that valid transactions are indeed valid, and users can verify the ledger and detect any attempted cheating by ledger operators.
The cryptographic identity scheme described here achieves those goals, but also has major downsides:
- Identity is a bearer instrument – Identity in these systems behaves quite differently to identity anywhere else in life. Whoever holds a private key owns that identity and all rights and assets associated with it. That’s like saying “if you lose the key to your house, you lose the title to it”. To quantify this problem: There are estimates that 20% of all Bitcoin in existence has been lost.
- Users need to understand transactions – To sign a transaction, you must first compute it. If we imagine that the users are interacting with the app trustlessly via their web-browser, that would require running the entire application in their browser to compute and sign transactions client-side. Light Node models first compute transactions server-side, on a leger node, then send it to the client for signing. Unless the user does careful due diligence on what they are signing, this requires the user to trust the operator of that light node, defeating the trust model the system is trying to solve for.
- Cryptography becomes a central concern of applications – Cryptographic identity, signing, and signature verification tend to leak deep into the tools used to develop apps for such platforms, leading to more complex and error prone code. Mistakes of this kind are real and consequential. One of the co-creators of Solidity froze over 20% of all Ethereum in existence with a faulty application. (source)
Participants and Parties to the Rescue
Daml aims to remove all of these downsides. Users should not have the burden of having to handle and safeguard cryptographic identity and users should be able to interact with the system like they do with any other application on the web. This requires an intermediary between users and ledger, which we call a participant node.
The participant node takes the place of a user on the ledger, holds a cryptographic identity on the ledger, and computes and signs transactions. Users interact with the ledger via the Daml Ledger API on trusted participants. Note that Users can choose to host their own exclusive participant, in which case the user can guarantee the validity of signatures and transactions for all its parties.
The Authorization and Non-repudiation properties described in “Identity on Ledgers” are preserved, but with ledger operators in place of users.
Parties as User (and Role) Identities
The introduction of participants changes nothing about the fact that it is users that act on the system. Users need to have an identity on the ledger with which they can authorize (or sign) transactions. This identity needs to be traceable to users and users want to be safe from impersonation. Lastly, whatever identity we choose should be an opaque identifier in the Daml language so that cryptographic concerns are abstracted away for the developer.
Daml Parties provide exactly this kind of identity. Every Daml ledger maintains a many-to-many mapping between Parties and Participants. How this mapping is maintained differs slightly from ledger to ledger, but it’s best imagined as an implicit contract between the participants. The Canton documentation on Identity Management provides a good example of how this works.
When a new user wants to join the system, they need to do so via a participant of their choosing (or run their own participant). The participant submits a signed transaction that creates a new Party mapped to the participant. If successful, this mapping is now known to all participants. The new Party is said to be hosted by the participant. Further transactions may also add mappings between other participants and that party, allowing the party to be hosted on multiple participants in read-only or full capacity.
Assuming the relationship between participant and user is sufficiently trusting, this model still solves for authorization, non-repudiation, and verifiability.
- Authorization – Since the mapping form parties to participants is public knowledge for ledger and participant operators, and Daml commits and transactions contain their requester and required authorizer parties, any participant or ledger node can determine whether a transaction signed by a participant node is well-authorized or not. So the only open question is whether the submitting participant correctly authenticated the external user. We assume that they did since it’s a trusted relationship, and Daml uses best-practice JWT-based authorization on the Ledger API.
- Non-Repudiation – Similarly, if a user sees a transaction on the ledger, they can trace it back to the submitting user:
1. Their participant can trace it back to the submitting participant via the cryptographic signature(s) on the transaction
2. The submitting participant can trace it back to a user by looking into their logs and user/party mappings.
- Verifiability – Participants are trusted by their users to verify that all transactions were recorded as requested.
Looking at this picture for the Sandbox or the current Daml Driver for PostgreSQL, we can see why party identity seems so loose. The Ledger Nodes and Participants all collapse into a single trusted centralized ledger server, which manages party identities. Party identities are conceptually equivalent to database users in that set-up, which is why they are just plain strings. Cryptographic signing is omitted altogether because it would add no additional value. Note that the Daml Driver for PostgreSQL 2.0 will separate the Ledger and Participant nodes, which means only the Ledger Nodes collapse into a single node, Party identity becomes something more profound again, and participant nodes will cryptographically sign transactions.
While it would be possible for the participant to use separate keypairs per party, this does not improve any trust assumptions. The participant is in control of all keypairs so it can swap them out as it wants to. Therefore, to make that trust assumption explicit, we only use a single keypair per participant.
Signatures and Signatories in Daml
Daml has a notion of a Party being a `signatory` on a contract, and the Daml documentation does talk about parties “signing” contracts. These notions of signing should not be confused with cryptographic signing of transactions. They should rather be taken as descriptive of the relationship between the user or entity that controls the Party and the data on ledger.
The Daml Ledger Model and the identity scheme presented here guarantee two things:
- Explicit Consent – A Party can never end up as the signatory of a contract without explicitly consenting to a transaction which allows this to happen. “Explicitly consenting” means that a participant that hosts the party in question submits a (cryptographically signed) transaction which in some way (pre-)authorizes the creation of the contract in question.
- Traceability – Given any party signature on the Daml Ledger, it is possible to reconstruct the exact chain of events that led to that signature. Each link in that chain can be attributed to some party giving explicit consent to a transaction in the above sense.
For every party signature in the Daml ledger, there is indeed a trail of underlying cryptographic signatures. Indeed, the link between parties, ledger model, and participant identities is such that a party signature in Daml gives equivalent guarantees to a cryptographic signature in a blockchain, say. The link between party signature and external user is merely less direct. Ease of use for the end-user of a Daml system is prioritized over ease of use in case of disputes that require tracing and auditing.
Cryptographic Security for all Deployment Scenarios
As highlighted in the introduction, Daml’s aims to provide security under clear assumptions in a large variety of deployment scenarios. The visuals above have already highlighted the three types of trust boundaries in Daml systems:
- Between ledger operators, corresponding to a decentralized deployment
- Between ledger and participant operator corresponding to transacting via someone else’s ledger – Network aaS
- Between user and participant operator, corresponding to providing the Ledger API as a service with low trust between user and service provider – Ledger API aaS or Solution aaS.
From this and the discussion of participants and parties, it should already be clear that the lower down in the stack the trust boundary lies, the better the guarantees Daml provides. Thanks to a feedback from Daml’s user community, we have come to realize that there is demand for features that also allow for lower-trust relationships between users and participants, in the Ledger API aaS model.
Reducing trust between User and Participant
This deployment model is going to be supported through two new features currently in the works:
The current assumption that users and participant operators trust each other in the presence of an IAM system and JWT-based authentication may be too strong for some deployment scenarios. A participant operator can impersonate users by acting as parties hosted on that participant. That opens the participant up to repudiation. What do they do if a user claims they didn’t submit a command that resulted in a transaction?
The traditional tools for this problem are to collect an audit trail consisting of network logs which ultimately lead back to a client. But this is complex and error prone.
To allow participants to provide their services more safely, a user non-repudiation feature is easy to imagine. The participant operator would require that every command to the Ledger API is accompanied by a cryptographic signature which they store as evidence. This requires users to handle private keys again, but since these private keys do not represent their identity on a distributed system, but merely the access key to the Ledger API, their loss is less costly. They can be rotated easily through a safe off-ledger process.
In short, user non-repudiation weakens the amount of trust a participant operator needs to give their users.
Users can verify that the Daml ledger they see through the Ledger API complies to the Daml Ledger Model and that the transactions they submitted are recorded therein.
However, they don’t have sufficient access to the underlying ledger to verify that their view has actually been recorded – ie it’s theoretically possible for a participant operator to show their users completely false information. One way to safeguard against this would be to cross-check information between multiple participant nodes, but that’s a pretty poor UX. So an important improvement to the Ledger API is to provide enough cryptographic evidence to users that they can verify that their view does actually correspond to what has been recorded on the ledger.
In short, user verifiability weakens the amount of trust a user needs to give their participant operator. A Participant operator will still be able to impersonate a user, or block their access, but with this feature, a user can immediately detect that they did so.
While both these features allow for a user to improve their trust relationship with their participant operator, there is no substitute for users operating their own participant nodes if they care deeply about the underlying accuracy of the ledger and the transactions that they authorize.
Daml’s identity model provides a high-level of flexibility to choose suitable trade-offs between security and user experience. Different approaches can be mixed and matched within the same ledger as needed, provided the underlying ledger chosen supports multi-node ledgers and separate participants.
As long as the system is run in a sufficiently open fashion, each entity within a Daml network can choose for themselves, whether they want to fully participate in consensus and redundancy, whether they want to merely participate in the cryptographic protocols, or whether they want to trust an operator to a greater or lesser extent to provide access as a service.
What is common to all these models is that they provide clear guarantees to all involved parties under the given trust assumptions. And as long as the given trust is not violated, every transaction can be guaranteed to have been authorized correctly and can be traced back to the user that requested it.
For more information on identity management in Daml, refer to the Canton Documentation as an example. You can download Canton to try this out in action here: