# Query and Create Exercise as multiple parties **URL:** \ **Category:** Outreach\ **Tags:** daml, json-api\ **Created:** [May 8, 2020, 6:12pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409 "2020-05-08T18:12:12Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![dliakakos](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/dliakakos/32/62_2.png) [@dliakakos](https://forum.canton.network/u/dliakakos)\ **Post date:** [May 8, 2020, 6:12pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/1 "2020-05-08T18:12:12Z")
Have we ever thought of the possibility of having the http json api allowing to query simultaneously as two or more parties and return the union of the result? Also on the exercise and create path could the json api accept a command where 2 or more parties are authorizers (so we could potentially exercise a conjunction choices)? Rationale: Read path - The multiple party read path will help a lot in performing data disclosure on applications that consume the json api. For example if we want to publicly disclose contracts then we can have a special party (ie the public party) that we can add as an observer. Then we mint JWTs that can read as both as Alice and the public party and query using that. Write path - For the write path of create and exercise, this will help in modeling user groups with specific authorities over the active contracts on the ledger. For example if we want at some point to grant Alice the ability to exercise a choice on an existing contract we would have to have a disjunction choice and explicitly add Alice to the list of disjunction parties before she can exercise that choice. Instead, we make the choice exercisable by a single party (ie some admin) and simply give Alice the token to exercise that. The subtlety here is that Alice is not necessarily a party on the ledger but an actual person that can read and write as multiple parties. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [May 8, 2020, 7:10pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/2 "2020-05-08T19:10:27Z")
# Reading Reading as multiple parties is not supported but theoretically possible, as there is a support for multi-party subscriptions on the Ledger API. Still, I would discourage it: this is just my opinion, but I believe there is an inherent advantage in keeping streams for separate parties separate, as you can easily reason about a single party at a time and not mix up together data that should have been segregated per party. Even if it’s intended for public disclosure, having something acting as the hub for publicly available contracts is something I would value as an app developer. On the practical side, single party subscription can also be faster than multi-party ones, because multi-party subs require the server to compute who the intended witness is for every event returned (whereas in the single party sub it’s clear that whomever is receiving an event is a witness). This, of course, comes into play when you have to perform at scale. # Writing Writing as multiple parties is not possible via the Ledger API, so it’s not possible on the HTTP JSON API either, since it runs on top of the Ledger API. ---
**Author:** ![georg](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/georg/32/368_2.png) [@georg](https://forum.canton.network/u/georg)\ **Post date:** [May 8, 2020, 7:18pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/3 "2020-05-08T19:18:46Z")
@stefanobaghino-da Dimitri also wanted to know if we’ve ever considered the multi-party write flow, and if not, why not 🙂 On the public read party: the problem with this is that you’ll only ever be able to see those contracts’ data, you’ll not be able to interact with them or use them in a choice using your own party. That’s severely limiting the usability of that approach imo. ---
**Author:** ![stefanobaghino-da](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stefanobaghino-da/32/7057_2.png) [@stefanobaghino-da](https://forum.canton.network/u/stefanobaghino-da)\ **Post date:** [May 8, 2020, 7:26pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/4 "2020-05-08T19:26:04Z")
> [@georg](#): > > @stefanobaghino-da Dimitri also wanted to know if we’ve ever considered the multi-party write flow, and if not, why not 🙂 Unfortunately I’m not aware of this, otherwise I would have included it in my answer. ---
**Author:** ![dliakakos](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/dliakakos/32/62_2.png) [@dliakakos](https://forum.canton.network/u/dliakakos)\ **Post date:** [May 8, 2020, 7:31pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/5 "2020-05-08T19:31:22Z")
Thanks for the clarification @georg - yes it would be nice to know if the write path was ever considered and dismissed. On the read path I would argue that it is a major benefit for displaying public data (or groups of data) on your application (even though you can’t fetch them in your choices). It’s not very different from the case where your party is merely an observer on a contract but not a controller. You can still see the choices but if you try to take any you will get rejected. ---
**Author:** ![Leonid\_Shlyapnikov](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_shlyapnikov/32/241_2.png) [@Leonid\_Shlyapnikov](https://forum.canton.network/u/Leonid_Shlyapnikov)\ **Post date:** [May 8, 2020, 8:31pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/6 "2020-05-08T20:31:32Z")
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) ---
**Author:** ![Leonid\_Shlyapnikov](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_shlyapnikov/32/241_2.png) [@Leonid\_Shlyapnikov](https://forum.canton.network/u/Leonid_Shlyapnikov)\ **Post date:** [May 8, 2020, 8:54pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/7 "2020-05-08T20:54:07Z")
> [@dliakakos](#): > > Write path - For the write path of create and exercise, this will help in modeling user groups with specific authorities over the active contracts on the ledger. For example if we want at some point to grant Alice the ability to exercise a choice on an existing contract we would have to have a disjunction choice and explicitly add Alice to the list of disjunction parties before she can exercise that choice. 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? > [@dliakakos](#): > > Instead, we make the choice exercisable by a single party (ie some admin) and simply give Alice the token to exercise that. 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 🙂. Dimitri, what exact problem are you trying to solve? ---
**Author:** ![drsk](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/drsk/32/43_2.png) [@drsk](https://forum.canton.network/u/drsk)\ **Post date:** [May 11, 2020, 10:25am UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/8 "2020-05-11T10:25:57Z")
> [@dliakakos](#): > > For example if we want to publicly disclose contracts then we can have a special party (ie the public party) that we can add as an observer 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’. ---
**Author:** ![Leonid\_Shlyapnikov](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_shlyapnikov/32/241_2.png) [@Leonid\_Shlyapnikov](https://forum.canton.network/u/Leonid_Shlyapnikov)\ **Post date:** [May 11, 2020, 1:53pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/9 "2020-05-11T13:53:58Z")
> [@drsk](#): > > You could just define a ‘broadcast’ party and give all parties read access as ‘broadcast’. 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. ---
**Author:** ![Leonid\_Rozenberg](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_rozenberg/32/48_2.png) [@Leonid\_Rozenberg](https://forum.canton.network/u/Leonid_Rozenberg)\ **Post date:** [May 11, 2020, 2:01pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/10 "2020-05-11T14:01:18Z")
@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. ---
**Author:** ![Leonid\_Rozenberg](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_rozenberg/32/48_2.png) [@Leonid\_Rozenberg](https://forum.canton.network/u/Leonid_Rozenberg)\ **Post date:** [May 11, 2020, 2:02pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/11 "2020-05-11T14:02:46Z")
> [@User aliases, a tale of two approaches. A developer grapples with DAML](https://discuss.daml.com/t/user-aliases-a-tale-of-two-approaches-a-developer-grapples-with-daml/332/10): > > If privacy is not a concern (eg. you specifically want global visibility of all aliases) and your lookups are far more frequent than write operations (add, delete, change aliases), then some of the concerns of MapOnLedger are not as grave - so it might be the better option then. The LedgerAsMap option is better for when the disclosure of an alias is considered a business process, and each party has a set of aliases it interacts with that is much smaller than the global population. In this case … The people have spoken! Universally observable templates for the people! ---
**Author:** ![drsk](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/drsk/32/43_2.png) [@drsk](https://forum.canton.network/u/drsk)\ **Post date:** [May 11, 2020, 2:34pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/12 "2020-05-11T14:34:58Z")
> [@Leonid\_Shlyapnikov](#): > > This would mean that anyone could become an observer without contract signatories approval, which would violate the entire purpose of signatories 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. ---
**Author:** ![drsk](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/drsk/32/43_2.png) [@drsk](https://forum.canton.network/u/drsk)\ **Post date:** [May 11, 2020, 2:36pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/13 "2020-05-11T14:36:46Z")
> [@Leonid\_Rozenberg](#): > > 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. 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. ---
**Author:** ![Leonid\_Rozenberg](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_rozenberg/32/48_2.png) [@Leonid\_Rozenberg](https://forum.canton.network/u/Leonid_Rozenberg)\ **Post date:** [May 11, 2020, 2:40pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/14 "2020-05-11T14:40:05Z")
That’s great and an elegant solution! ---
**Author:** ![Leonid\_Shlyapnikov](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_shlyapnikov/32/241_2.png) [@Leonid\_Shlyapnikov](https://forum.canton.network/u/Leonid_Shlyapnikov)\ **Post date:** [May 11, 2020, 2:55pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/15 "2020-05-11T14:55:42Z")
> [@drsk](#): > > 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. 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. ---
**Author:** ![drsk](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/drsk/32/43_2.png) [@drsk](https://forum.canton.network/u/drsk)\ **Post date:** [May 11, 2020, 5:17pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/16 "2020-05-11T17:17:43Z")
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`. ---
**Author:** ![Leonid\_Shlyapnikov](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/leonid_shlyapnikov/32/241_2.png) [@Leonid\_Shlyapnikov](https://forum.canton.network/u/Leonid_Shlyapnikov)\ **Post date:** [May 11, 2020, 6:00pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/17 "2020-05-11T18:00:01Z")
> [@drsk](#): > > If someone who controls the identity/keys infrastructure of a party makes a mistake, then you’ll be in trouble in any case 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](https://github.com/digital-asset/daml/issues/new?milestone=HTTP+JSON+API+Maintenance) and refer to this doc: [https://docs.daml.com/app-dev/authentication.html#access-tokens-and-claims](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. ---
**Author:** ![dliakakos](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/dliakakos/32/62_2.png) [@dliakakos](https://forum.canton.network/u/dliakakos)\ **Post date:** [May 11, 2020, 6:48pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/18 "2020-05-11T18:48:20Z")
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. ---
**Author:** ![cocreature](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/cocreature/32/36_2.png) [@cocreature](https://forum.canton.network/u/cocreature)\ **Post date:** [May 11, 2020, 7:03pm UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/19 "2020-05-11T19:03:13Z")
> [@dliakakos](#): > > 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. The DAML Ledger model already allows multiple requesters on a commit, see [Structure — Daml SDK 2.7.6 documentation](https://docs.daml.com/concepts/ledger-model/ledger-structure.html#ledgersfor) 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 ---
**Author:** ![Ratko\_Veprek](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/ratko_veprek/32/206_2.png) [@Ratko\_Veprek](https://forum.canton.network/u/Ratko_Veprek)\ **Post date:** [May 12, 2020, 7:38am UTC](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409/21 "2020-05-12T07:38:26Z")
> [@georg](#): > > On the public read party: the problem with this is that you’ll only ever be able to see those contracts’ data, you’ll not be able to interact with them or use them in a choice using your own party. That’s severely limiting the usability of that approach imo Why can’t you act on them? Isn’t that what flexible controllers would allow you to do? [Next page](https://forum.canton.network/t/query-and-create-exercise-as-multiple-parties/409.md?page=2)