Expanding a bit on what @stefanobaghino-da said, implicit party allocation is a
sandbox feature where the Daml ledger (served by
sandbox in this case) blindly accepts any string as a Party. This is fine for development, but it is definitely not something you’d want in production.
In production, and especially in distributed context, the Daml ledger needs to create parties explicitly. While it may seem very tedious to have to create partie manually by running the
daml ledger allocate-parties or by providing a comprehensive list of parties in
daml.yaml, this is not how you should think about it. Let’s take a step back.
The Daml ledger accepts (requires) a JWT token to identify which party is currently sending a command. The JWT token is an authorization mechanism: a given token carries with it a number of rights that allows whoever carries it to perform actions on the ledger. Crucially, the token itself does not prove who is performing an action, it simply asserts that the carrier has a given set of rights.
This should raise the question of how those tokens get distributed, and who is responsible for ensuring that the right person gets the right (set of) token(s). This is not covered by Daml components and needs to happen externally. Authenticating a user and deciding which token they should get is something that has to be managed by a system external to your Daml ledger. As that system needs to create tokens for your users, it also needs to know which external identity (say, an email address) corresponds to which Daml party (or set of parties) so it can generate the proper tokens.
That external system should be in charge of allocating parties; it should, as part of its login flow, check if it already knows the party name for a user, and if not, call the
/v1/parties/allocate endpoint and record the user ID <-> party name mapping.
With that setup, you can still get dynamic party allocation, with no manual intervention.