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.