Refactor DID support to use 3ID's about verida-js

[tahpot]

Need to consider how to connect in a server (or mobile) environment v connect in a web environment.

• Server environment will require access to a blockchain private key that is used to authenticate with Ceramic.
• Web environment will use 3ID-connect.

Both separate process will result in the creation of a DID object that can be used to sign and encrypt data via a 3ID.

Proposed architecture

• packages/connect-web: Uses 3ID Connect to authenticate a user and generate a DID instance
• packages/connect-node: Uses EthereumAuthProvider from Ceramic to wrap a private key and blockchain network. This is injected into a @3id/manager instance that can produce a DID instance.
• packages/datastore: Accepts a DID instance and replicates the existing datastore capabilities

However, the above fails to work in a web environment if we are wanting a user to authorize access to a specific application context. Under the above model, the web environment has granted full access to the current website to the 3ID, rather than delegating access to an application context that has limited access (ie: can't write to the user's profile).

I have asked the Ceramic team on Discord about this application context issue.

Can hopefully build into connect-web and connect-node the application specific authorization.

[tahpot]

I have asked the Ceramic team on Discord about this application context issue.

From Ceramic discord:

The plan right now for IDX "spaces" i.e. encrypted definitions/records can be found here: https://github.com/ceramicnetwork/CIP/blob/main/CIPs/CIP-11/CIP-11.md#idx-keychain-definition

A read of this indicates any support will require changes to Ethereum libraries, while the current 3id-connect library doesn't support paths (3id-did-provider does, in theory).

I don't feel we can rely on ceramic / IDX for this capability at this stage, so will need to roll out own.

Security: At the moment web applications using 3ID's gain full access to sign and encrypt using that 3ID, providing no ability to restrict access between different web applications.

We can solve this by enforcing our single sign on to only work via a mobile application, but that's not ideal long term.

[tahpot]

From the proposed architecture above:

packages/connect-web: Uses 3ID Connect to authenticate a user and generate a DID instance

After further investigation 3id-connect does everything we need here, so no need for a separate Verida helper library.

packages/connect-node: Uses EthereumAuthProvider from Ceramic to wrap a private key and blockchain network. This is injected into a @3id/manager instance that can produce a DID instance.

This has been implemented with working tests as packages/3id-utils-node. See 4579439.

[tahpot]

Ceramic + IDX introduces latency issues in web or mobile environments

Doing some basic tests with https://self.id shows a variable time to connect anywhere from 4-8 seconds. This isn't great, however this should only be required on the mobile app when a user first connects and will then be cached.

Tests of fetching an existing user's IDX profile returned a result in ~1 second, which should be fine.

[tahpot]

Ceramic + IDX won't work within React Native environment

According to Ceramic discord others are working on this, so assume it's not an issue.

Create a web based PoC that validates the above approach to using 3ID to store and unlock per application databases will work as expected

Decision is to use Verida's Single Sing on to support this as Ceramic won't support it any time soon.

[tahpot]

The core packages that support this are now complete:

• https://github.com/verida/verida-js/tree/main/packages/3id-utils-node (Utility to generate 3ID's from Ethereum private keys)
• https://github.com/verida/verida-js/tree/main/packages/storage-link (Utility to create named secure storage contexts for 3ID's)
• https://github.com/verida/verida-js/tree/main/packages/storage-keyring (Utility to create a keyring for a given seed. Used by storage-link)