After a jwt token is generated, a user can authenticate themselves with the jwt token, but who ultimately signs the transaction (using a public/private key pair) as it is written to the ledger? Would that be the token issuer, IE the administrator of the node? Therefore, if a node administrator wants to act on the ledger, they would first need to generate a JWT assigned to their own respective party and submit a request using that JWT token?
And therefore, if a user wants to be a first-class party on a ledger (ie with their own public private key pair that can allocate or operate on smart contracts), they need to operate a node?
If the node administrator wants to be extremely secure, they can assign an extremely low expiration time to this token and discard the JWT token after use, or only generate JWT tokens for single use as needed?
The process that generates tokens is only signing tokens; let’s call that process “the token provider”. The participant will check the validity of a token based on the public key of the token provider. If that succeeds, the participant will accept the command and it (the participant) will sign the transaction. (A typical transaction will be signed by more than one participant, as it will involve more than one party and those parties may be represented on different participants.)
The token provider is not part of the Daml system and only interacts with it by:
- Signing JWTs with a private key.
- Providing a public key for JWT signature verification.
This means that, on the ledger itself, the “trustable unit” is the participant, not the party or user. The thing that signs transactions is the participant node. From that perspective, if you want to minimize the number of things you need to trust, you should run your own participant node, and may be tempted to imagine a setup where every single party has their own participant and each participant only has one party. (There are cases where that’s feasible, but in most cases that’s going to be too much work for individual users.)
What is a participant? And if a participant wants to have their own respective party do they have to generate a JWT token for this party or can they directly use their public/private key pair without a JWT token?
“Participant” is the name of one of the types of processes involved in a Daml system.
The participant is the process that exposes the Daml Ledger API, against which applications can be developed. There are internal protocols for communication between the other parts of a Daml system, but those are internal and you’re not supposed to interact with those directly (unless you’re writing an alternate participant implementation, I suppose).
The participant acts on the ledger “on behalf” of a number of parties; how the participant identifies those parties is up to it. It’s usually through a JWT with an external token provider, but in theory that could be any other system, including no authentication at all if you somehow trust your network configuration enough to be confident no one else is able to access your participant’s gRPC port.
Hi @tiw maybe this blog post also answers some of your questions: Identity in Daml