What happens if there is not DataRegistry using your shape tree

[michielbdejong]

See jaxoncreed/ldo-react-tutorial-1#4 (comment)

You will also need to add at least one data registry using your shapetree, for example here
https://github.com/janeirodigital/sai-js/tree/main/packages/css-storage-fixture/alice-home/dataRegistry

Is this really part of the instructions for making an app ready for SAI? But what if my app introduces a new shapetree and I want thousands of people to use it (not just myself), do all those users need to have at least one data registry using my shapetree?

What happens if the user doesn't have it?

[elf-pavlik]

The main challenge is that descriptions from the Shapetree are used on the authorization screen. We consider them to be trusted, compared to information coming from the app's access need description, which is not considered trusted.

If we allow the app to use shape trees from any source, especially one controlled by the app, we can't rely anymore on the trust of the shape tree descriptions. Still, if app uses a shape tree that it controls, it is unlikely any other apps will use so as log as we allow one shape tree per data registration it should be fine.

Still, we need a trusted source to provide a trusted shape tree with descriptions that the authorization screen can rely on. We expect many apps to interoperate using the same shape tree since Solid CG will provide shapes (preferably also shapes) for client-to-client domains. We could already assume the existence of such a mainline source and start with having those available to be automatically created by the authorization agent if missing.

What do you think about adding a local version of such an official repo to sai-js and automating the creation of the data registrations that are part of it?

---

There is also the bigger topic of bootstrapping all the SAI registries; currently, this repo doesn't include such bootstrapping functionality. In other words, it assumes that the user has all the needed registries. We could add a feature to the authorization agent where the user can create a new Registry Set and all the Registries. The user would need to provide storages for creating those registered.

Preferably, the Authorization Registry and Agent Registry have one dedicated storage, while data registered can be created in multiple other storages. There is also a requirement that at the root level, those storages need to have acp:client set to the owner's authorization agent, since no other client shall have the acl:Control access to any storage used with SAI.

[ericprud]

+1 to everything @elf-pavlik said. Couple use cases to consider:

jailbreak

Health provider DocInABox offers a SAI infrastructure to clients. Alice installs it but then decides she wants to manage security herself so she can install the Peepers photo app from outside the DocInABox ecosystem. Can Peepers re-use ShapeTrees from the DocInABox ecosystem? Can it create new onces? I don't see how we can prevent either of these if Alice is root.

multi-ecosystem

Insurance company BetOnDisaster also offers an ecosystem. Can they share some ShapeTrees? Can they share some apps? From the perspective of either of the ecosystems, is this measurably different from being jail-broken?

Maybe y'all have already worked this out. If so, I can remove this to reduce confusion.