Here’s a scenario I’m wondering about. Is it possible to:
Write Daml app with a front-end that runs in your browser, and have the browser verify (client-side) that contracts have been signed by parties with a valid SSL certificate.
Taking a step back: I understand that a Daml deployment has an IAM component, which is managed by the domain operator. i.e. you need to trust the operator to verify that users say who they are. What I’d like to know is whether there is a way to integrate any web-based PKI infrastructure (e.g. SSL certs, GPG keys) with a deployment, so that an end-user (participant?) can verify independently the identity of parties on contracts.
This would require I guess
first, an IAM that supports SSL certificates, and
second, a way to verify a party (contract?) in Daml code corresponds to a certain public certificate
I’m assuming that the first problem is straightforward to solve. But I’m unsure about the second. In Daml, parties are opaque, so there isn’t really much we can do with them. Of course, I suppose I could store some meta contract with the party public keys, but I’m wondering if there is a way to do this with what the SDK provides.
Could someone correct me if my understanding here is completely wrong? Does this idea make any sense at all, or is it pointless?
There are no cryptographic primitives in Daml beyond sha256, see Cryptographic primitives in DAML. Generally we try to let the ledger deal with things like certificates, signing, … behind the scenes instead of exposing them in the Daml code. So there isn’t really a way to do what you are suggesting in Daml.
That said, it isn’t quite clear to me why this has to happen on ledger. Can’t you check the party ids off-ledger and use that to decide whether you agree to a proposal or similar?
I suppose my question was not worded very clearly, and I contradicted myself. But essentially I want to …
By this I mean that I want to pick a contract from the ACS, look at the signatures, and verify that the party that is called, say ‘Microsoft Corp’ is who the say they are, by doing some cryptographic verification (off-ledger) rather than relying on the domain controller to do this verification when onboarding the party. i.e. say in case I don’t trust the domain controller.
In Canton a party id does include the hash of the public key of the corresponding participant iirc. That said, I’m not fully sure what scenario you want to protect against.
In Daml you trust your participant. If you don’t, host your own. So your browser has to trust the participant it connects to. But that participant will already validate that the parties come from the participants they are allocated to and validate corresponding signatures from that participant (in Canton). So if you trust the participant, I’m not sure what you are verifying. And if you don’t, the participant can feed you arbitrary party ids (or more generally completely arbitrary transactions) anyway so your verification isn’t doing much.