Indicate list of OR signatories

[Leonid_Rozenberg]

But in order to know that, one would have to look at the transactions leading to a given T, (ie find the fetch node ?) as opposed to looking at the code for T.

Imagine

template T
  with
    player: Party
    sponsor: Party
    limit: Int
    observers: [Party]
   where
      signatory player, sponsor
      onCreation do
        (_, funds) <- fetchByKey @Funds sponsor
        assert $ funds.amount > limit

[entzik]

@bernhard

What happens if Alice has role broker, creates a contract with the ensure clause, and then loses the broker role. Does the contract become void? Does it stay around because the ensure clause is only enforced at the point of creation? Can the role not be taken away until there are no active contracts of that type?

That’s definitely not any concern of the language or runtime. The language and runtime should only provide a means to assign and remove roles to / from parties. What happens if a role is retracted? that’s regulation. Business logic. Up to the application to deal with.

A couple of weeks back they discuvered somebody in France who was illegally practicing medicine after illegally obtaining a Medical Doctor license. In reaction, the “Ordre des Medecins” has retracted the license (retracted the role) and they are working with every patient currently ongoing treatment to check if everything is fine and compensate. And it’s similar in every other domain. That’s how real world works.

[entzik]

@bernhard

Who administers these attributes in a distributed setting? Who decides that a notary is a notary or a broker is a broker?

Who administers parties today ? external systems who get access to the admin API. If those external systems have the authority to define parties in the first place, maybe they could also do that in a more precise way, by adding and removing roles.

[entzik]

@bernhard

How do you make sure the ensure clause can be validated in a deterministic way? Suppose I set an attribute for Alice and she immediately fires off a transaction that needs that attribute, how can we ensure there is consensus about whether the attribute setting happened before or after the transaction?

I do not know DAML internals well enough to answer that. It’s obviously some work. I do not pretend to have the answer, I merely dare suggest a feature that would make DAML easier to use in certain use cases and more secure.

[bernhard]

Fully understand and appreciate your suggestion. My questions were purely rhetoric in order to explain where we see challenges with offering externally administered role-based auth. It’s a topic that does come up regularly and one I take very seriously. Really my whole post was just meant to lay out where my current thinking on the matter is.

[entzik]

@bernhard

A lot of these questions can be resolved quite easily by making roles an on-ledger concept. Ie put your attribute in a contract:

template PartyAttribute
  with
    giver : Party
    holder : Party
    name : Text
    value : Text
  where
    signatory [giver, holder]
    key (holder, name) : (Party, Text)
    maintainer : hey._1

The problem I see with this kind of approach - is that anyone, not just the giver, should be able to assert the party’s attributes (roles), and that’s literally everyone, every party on the system. And that’s beyond cumbersome. It could work if the contract could be made public (everyone can be an observer) but to my knowledge, that’s not possible.

[bernhard]

@entzik

It could work if the contract could be made public (everyone can be an observer) but to my knowledge, that’s not possible.

Ah, but that’s a gap we are hoping to fill some time soon. See here for a long thread on the matter: Query and Create Exercise as multiple parties - #18 by dliakakos

[Jean_Safar]

Those attributes indeed fall into the realm of distributed network governance and should be administered by contracts. This is especially important as, hopefully, networks will be interconnected.

[entzik]

looking forward to that

[Gary_Verhaegen]

@entzik

A couple of weeks back they discuvered somebody in France who was illegally practicing medicine after illegally obtaining a Medical Doctor license. In reaction, the “Ordre des Medecins” has retracted the license (retracted the role) and they are working with every patient currently ongoing treatment to check if everything is fine and compensate. And it’s similar in every other domain. That’s how real world works.

If “Ordre des Médecins” is a party on the ledger, does that not let you do what you want? Practicing doctors could have a license they receive from it (i.e. a contract signed by it) and insurance companies/pharmacies/other caregivers that depend on a doctor’s authority would check that signature.

[entzik]

@Gary_Verhaegen

If “Ordre des Médecins” is a party on the ledger, does that not let you do what you want? Practicing doctors could have a license they receive from it (i.e. a contract signed by it) and insurance companies/pharmacies/other caregivers that depend on a doctor’s authority would check that signature.

well yes in theory it works, in practice, as I said, it’s beyond cumbersome. think about it, every pharmacy, every insurance company any other doctor, any patient, basically anyone who will ever want to make sure another party is a doctor, will have to be an observer of every doctor contract in the world. And as you add new parties to the system in the future, you’ll have to add them as obsevers as well.

That’s not just a huge waste of storage and compute, it also make the the entire code base more complex and error prone.

If the role is an attribute of the party, all this goes away.

Also being able to create public contracts (where everyone is an observer by default) would an acceptable solution because it eliminates the complexity of having to store the entire world as an observer on each “role” contract, and apparently that’s on its way.

[zoharhod]

is there an update related to the roles roll out functions in the next SDK?

[bernhard]

We are expecting the functionality to land in release 1.9.