Implement group-agent countersigning for EconomicEvent

[pospi]

Once single-agent countersigning is completed in #82 we will need to do the same for group agents. This will also require #9 to be completed first.

The issue with signing and groups comes down to when receiver is a group agent- the group agent then must sign for the event; which means some human or "oracle" agent(s) with authority to do so must sign on behalf of the group.

Like timestamping, the correct approach here will depend on the requirements of the economic network. Some options could be:

• self-signing: participants are trusted to counter-sign their own events, or counter-signatures are not required
• M of N multisig: a threshold of agents configured to be part of the group must sign for the event in order for it to be accepted
• non-self-signing: any agent with permission in the group other than provider can sign as receiver, and vice-versa

Letting us know of any other options we should consider here would be much appreciated (:

[fosterlynn]

I think we'll need to consider role-based signing, at some level of complexity. But I totally agree we should be driven by the requirements of the economic networks. I suspect we will eventually want different "plug in" kinds of things that a group can choose to implement, and can develop these first-come-first-served....

[jvanbockryck]

Maybe writing some use cases will help.

[TheLaughableCoder]

The way I see it:

Admin: can add users to the group
Signer: Can sign transactions on behalf of the group, this group would be good to have levels of access too, ie someone who can agree on a monitory transaction, and there might be users within the group that may only receive deliveries and they need to sign that the transaction is complete.
View only: View transactions, and also the ability to limit what is viewable by resource type, ie some users only able to see the resources if they are not currency resources. This view only can be used to provide proof that the transaction has occurred.

For supply chains that are sensitive, these transactions need to be private, similar to how double-entry accounting is now. Everyone is sensitive to the value they have sold for becoming public knowledge and come supply chains are sensitive about the knowledge of the origin of their supply becoming public knowledge as the R&D into the finding a supplier that can meet the specifications is considered intellectual property. However, legislation like Modern Slavery and the potential for GHG emissions tracking is enclosing on these types of supply chains and the old guard is looking for solutions to still maintain this level of privacy while being compliant.

The benefits that REA brings is traceability so having origins, or certifications like modern slavery or carbon being passed to the recipient would be desirable, how this is possible? by an oracle, or an even better solution is if this could be passed via a zero-knowledge proof if the architecture can handle that.

I also see problematic issues with all of this data being stored on the node’s source chain to provide the privacy with access granted above should be possible via capability tokens? this can have issues of being able to access the data due to network partitioning or node just being offline. The architecture will require high availability super-agent nodes for the group that hold all data for the group.

[TheLaughableCoder]

We might need the ability to send commands to delete the data held on one of the group devices, for when an agent leaves the group, or their device is lost. Similar to what Android and iOS can do when a device is lost.