Hello,
In order to enforce (off-ledger) user-defined workflows, we use a Trusted Execution Environment to generate (serialize and sign) our transactions. These transactions are then returned to the caller, who can broadcast them.
As far as I can tell, Canton performs its authentication through JWT. This is not ideal, since it means the caller must be given the JWT in full to process the request, which they can then use to call any method, thus bypassing the TEE.
Is there an authentication method that I am missing, that maybe uses a signature/HMAC rather than a token?
Thanks.
Hi @Lea_Max , currently it’s not possible to authenticate against the Ledger API on a per-request basis. We are thinking about adding the ability to sign commands and validate command signatures as part of the ledger protocol so that it’s possible to control choices without needing to be online.
However, this would apply only to the Command(Submission)Service and not replace JWT-based API authentication as you may still want to permission who can use your node to submit commands in such a fashion, and who can read data from your node.
Is this your use use case, or are you looking for a more general per-request authentication method?
Hi!
We’re hitting a similar use case.
The issue with JWTs is that they authenticate users, but they don’t necessarily stand up against man in the middle attackers.
Since the request is sent in the HTTP request, an attacker with access to the network can perform any number of queries with it.
Compare this to most crypto exchanges, where the request’s body and headers are signed/macced using a clientside secret.
If the request is intercepted, the attacker will not be able to create a new request, but only replay the existing request
The possibility to add a different key specifically to exercise choices, while keeping the party itself online would also work, and be even better if it’s at network level!
Very valid and valuable input. We are thinking about adding something like that to Daml.
Would this mean that participants wouldn’t be able to exercise choices for the parties they control?
If so this would be an amazing addition and would make it a lot more viable for us to integrate Canton.
We operate a solution where clients are typically in control of their keys, but we manage everything else, including nodes. For Canton, as it stands, this means they need to trust us to not run operations using their party. This means they want to run the participant themselves, which is a large hurdle for them, and they might just prefer switching to something like a custom Besu deployment.
If we could operate the node but not exercise choices on their behalf, it would solve a lot of issues.
Yes, I can confirm that we are actively working on this feature and are making good progress. The result will be that parties will be able to submit through ANY participant node of their choice (if the participant node let’s them), without having to trust the submitting node.
2 Likes
That’s great news thanks!
I’ll be sure to follow it closely