Query and Create Exercise as multiple parties

Ledger API supports multi-party reads, JSON API does not.

JSON API authentication/authorization was designed a bit a head of Ledger API and we did not have a use case for multi-party reads in JSON API.

Our take on multi-party authentication in JSON API:

  • 1 party - 1 authentication token (JWT), no super users
  • if participant needs to act as multi-party, this participant needs multiple authentication tokens (one per party)
1 Like

This sounds reasonable to me. A new copy of the contract with Alice added to it has to be created and approved/accepted by all signatories. This is by design. What if one of the signatories does not want Alice exercising a choice on the contract or does not want Alice to be able to read this contract?

This does not sound right. Granting Alice admin rights you cannot control what Alice can read and exercise. Alice becomes a super user with access to all contracts that Admin can access. This also means you will end up with multiple counter-parties/entities being admins.

I remember the discussion with @dtanabe when we decided to make it impossible to have super users in JSON API :slight_smile:.

Dimitri, what exact problem are you trying to solve?

1 Like

Almost in every app I wrote in DAML I run into the need for a way to broadcast data to all parties. If we would allow reads as multiple parties, the above would be a simple solution for this. You could just define a ‘broadcast’ party and give all parties read access as ‘broadcast’.

1 Like

This would mean that anyone could become an observer without contract signatories approval, which would violate the entire purpose of signatories. I think a flag to enable broadcast to every party on the ledger should be added to the DAML template. We have observers, something like observed-by-everybody: Bool. When signatories are signing a contract they will have to accept the fact that the contract can be broadcasted to every party.

BTW, it is pretty easy to add support for multi-party reads to JSON API, but I think it would open a way to violate contract privacy.

1 Like

@drsk To enable this vision it would be convenient if the react bindings had the ability to specify what party is making a request (within a DamlLedger context), to avoid having to go into the ledger api.

The people have spoken! Universally observable templates for the people!

I can’t quite follow this. The contract would be designed in a way that you add the ‘broadcast’ party explicitly to the observers, so it’s clear in the DAML code itself that such a contract is broadcasted. So no change to the privacy rules or change to the signatory purpose.

1 Like

Actually, for this idea it wouldn’t be necessary. Because a party would get a JWT token where it has the right to read as the broadcast party, so there is no need to switch the acting party context.

2 Likes

That’s great and an elegant solution!

1 Like

If DLT operator can give Alice permission to read contracts as Broadcast party, technically the same DLT operator, can make a mistake and let Alice read contracts as Bob… contract signatories will not have any control over this, they won’t even be notified about this mistake.

If someone who controls the identity/keys infrastructure of a party makes a mistake, then you’ll be in trouble in any case. I think this observation is independent of the question, whether multiple parties should be allowed in readAs.

That is not the point… My personal opinion that canReadAs and canActAs break the ledger privacy model and allow someone else besides signatories to give access to observe and exercise choices on contracts.

If I sign an IOU with Alice, I would NOT like the idea that let’s say the government or a bank can make this contract visible to everyone else. It should be between me and Alice and nobody else.

You can create an issue here: Sign in to GitHub · GitHub

and refer to this doc: https://docs.daml.com/app-dev/authentication.html#access-tokens-and-claims

I will make sure we discuss this issue with the product owners this week.

It’s nice to see that this thread has gained some traction. Let me try to clarify a bit more.

I also agree with @drsk that there is no violation of signatories happening just a re-think of what is actually a Party in DAML. DAML in its authorization model never accounted for how parties map to actual users with log in information. It is also not opinionated as to whether a party is an individual or a legal entity or a group of people. It is simply a mechanism for calculating permissions for updating a the active contract set and for disclosing part of that contract set. Mentioning Alice and Bob in our starter example as parties IMO is a good way to start but soon enough falls short when designing a production use-case.

For the read side it has become apparent that we do need a mechanism for reading public data. In DABL we have already introduced the concept of a PublicParty where you can get its Party value from a well known endpoint as well as get a JWT for it without any special permission. Then the app developer is burdened with performing multiple calls (one for the public party and one for the logged in user of the app) in order to properly render the desired state. Therefore a mechanism where a single call can return both public and user authorized data without compromising the principles of the DAML ledger is a win.

For the write side it gets a bit more complicated. As I understand it, the ledger api itself needs to change in order to support multiple submitters. I would have loved all along to be able to do something like submit [alice, bob] create Agreement with .. where agreement has both alice and bob as signatories. This is already the case with conjunction choices that can be taken in the body of other choices as long as the set of authorizers is a superset of the controller parties in the conjunction choice. Having the ability to outright create contracts with multiple signatories or outright exercise conjunction choices will enable faster upgrades and simpler workflows without I THINK (and that’s something that I need a language expert to answer. perhaps @Martin_Huschenbett or @meiersi) compromising the ledger model.

A use case for the write path by using a JWT for multiple parties is that of user groups. Alice has her own token for a Party on the ledger. However she is upgraded to an admin which is a party on the ledger and now can read and write as a both parties.
She can go ahead an exercise a choice that is modeled for the admin party since on every choice she takes she submits a set of authorizers containing her party and the admin party (ie a superset of the controllers that the choice needs).
Another use case is that of fetching ‘public’ contracts (where the public party is the observer or signatory). Think about the case where Alice exercises a choice where she is the controller and that choice needs to make use of some reference data where the public party observes. Since the public party is in the set of authorizers, it can be used for fetching the public contract in the body of the choice that Alice takes.

2 Likes

The DAML Ledger model already allows multiple requesters on a commit, see Structure — Daml SDK 2.7.6 documentation details. Relevant section:

In the ledger model, a commit is allowed to have multiple requesters, although the current DAML Ledger API offers the request functionality only to individual parties.n

1 Like

Why can’t you act on them? Isn’t that what flexible controllers would allow you to do?

1 Like

@Ratko_Veprek because it was only disclosed out-of-band via the public party. my own party doesn’t have visibility on that contract in terms of the ledger so I can’t fetch the contract.

1 Like

@dliakakos so, the ledger-api itself should support what you are looking for. and i do see your point. for quite a while, we have said that we still need to add something like a “public section of the ledger”, which amounts to your broadcast. however, so far, this hasn’t been a top priority, so it was never followed through up to now.

however, if you look at the canton identity management system, it actually already supports public parties in theory.

with respect to the http-json api: i don’t think that the http-json api should try to implement different semantics on the permissioning / how to use parties. in that sense, i would also expect that you can du multi-party subscriptions there.

and btw, multi-party subscriptions were added three years ago because maintaining 100 open subscriptions, one for each party from a single app was a nightmare.

2 Likes

Yes, but that’s related to another semantic issue, the fact that a contract-id are opaque. Once the meaning of contract-id is changed such that they also refer to the payload, we solve quite a few issues at once: public parties, out-of-band disclosure, read delegation.

1 Like

Agree. I’d be interested in @bernhard 's stance on what’s planned for the read model overhaul.

I agree with @cocreature. From a conceptual point of view I expect we should be able to support submitting a command on behalf of multiple parties.

I think we don’t have it, because it has not been a priority. And it could be an expensive change, as it affects many components.

1 Like