Applying Role concept on my DAML Project

Hi Daml’ers,
I just want to have a clear discussion about the concept of applying role in my daml app.
I have these 3 roles of a party :

  • Citizen
  • HealthOfficer
  • TourismOffice

I already define the Daml model for the 3 parties

How can a web user signup (UI) on my app as citizen or HealthOfficer or TourismOfficer?
I always stack on the concept of relational db vs ledger :frowning:

How do I apply the concept of PartyHintID on a user when signing up?

I am new to Daml and currently exploring.

example scenario :
Alice singnup as a citizen
Bob signup as HealthOfficer
and so on…

Thanks

1 Like

Hi @ariscatan,

A full Daml system must include not only a Daml ledger (and optionally Daml Connect components), but also an identity provider.

The identity provider is an external (to the Daml ledger) system that handles authentication and party creation. In effect, it must support the following use-cases:

  • User logs in for the first time: create a party for them, store the identity-to-party mapping, and create initial contracts as required by your model.
  • User comes back: re-issue a token for the same party, using the saved mapping.

Optionally, the identity provider may also handle things like:

  • Allocating multiple parties for a single external identity, giving users the option of which one to act as; in that sense, you can have some notion of roles, or shared parties between multiple people.
  • Providing users with multi-party token, e.g. actAs themselves and readAs some public party.

Because most of these operations depend, in some way, on your Daml model, the identity provider is an integral part of a full Daml system, and needs to be taken into account in design of the system.

So in your case, the identity provider could determine which role a user is supposed to play and initialize their account accordingly.

Note that the identity provider is by necessity the highest authority on the ledger*: since it is issuing tokens, it can impersonate anyone. In particular, it can itself create contracts as some “special” admin party that everyone recognizes as an authority for trusting role allocations.

*: More specifically, on the participants that trust it to generate tokens.

1 Like