Update to ecosystem diagram

[ewelton]

The ecosystem diagram establishes a picture of Agent/Wallet communication with Storage. This has the advantage of making all authentication happen between the Agent/Wallet and the User, presumably using KMS (which often uses a TEE).

I propose making the position of the User clear in this diagram, as it helps illustrate the 2nd missing component from this diagram - which is "sharing between entities", such as in the spec use case 1.3.3. Specifically, the sharing is done between "Storage" (which is the scope of the SDS) and not between Agent/Wallets which use the Storage.

Likewise, in the multiple-device scenarios, such as spec use case 1.3.4 and the two spec use case 1.3.5/multiple-devices items - the architecture suggests that it is the storage layer itself which is responsible for the multi-device, multi-location movement and synchronization of data - rather than the invoking the Agent/Wallet software.

Together, the above two points suggest and update to the ecosystem diagram that demonstrate that multiple people and multiple devices are all relying upon the SDS specification to perform the bulk of the heavy lifting.

With the heavyweight SDS decoupled from the agent and involved in a large amount of direct sharing, we need to consider if our goal is to facilitate inter-user communication via data sharing across multiple SDS systems from multiple vendors to be involved in this exchange - something that could be conveyed using simple graphical markers in an enhanced ecosystem diagram.

Far from being cosmetic, clarity about the actual ecosystem under development will help identify what is required for 1.4.2 - since Agents are not in play, but rather, Agents are the programmers-and-controllers (on behalf of users) of a high-powered SDS-based information sharing architecture. This, in turn, sheds light on issue #36 - since the "request for access" would flow between Agents & Agent/Wallets, on behalf of users - and the Agent or Agent/Wallet would then "program" the SDS to support the required sharing, notifications(4.4.1), revocations, etc. - perhaps via ZCAPs or perhaps via some form of personal Authorization Server (e.g. last sentence of 1.4.2)

The question for the community then is how we should go about updating the ecosystem diagram as that process might not be as well suited for PRs as text updates. Perhaps there is some discussion of the points above, establishment of a set of "concepts to capture and reflect", and then enlistment of appropriately skilled individuals to produce some PR candidates?

[OR13]

On the call today:

Apparently from the call, the group desires a separate document for use cases.

@ewelton can you take a first stab at a PR that creates this separate document for use cases?

[OR13]

This issue seems to be mostly a request for better diagrams, we can upload them on the issue, gather feedback and then open a PR to add them to the spec.

[OR13]

Waiting for volunteers to make a better diagram, and open a PR.

[dmitrizagidulin]

Attempt at updating the diagram in PR #88.

[OR13]

Pending close, no active interest from wg.

ping @bumblefudge

[tplooker]

This issue has been addressed as per above