Privy integration for user-controlled VCs in CollabLand

[sternhenri]

Attribute	Value
clip
title	Privy integration for user-controlled VCs in CollabLand
description	Collabland should integrate with Privy for private storage of user VCs.
author	Henri Stern (@sternhenri)
discussions-to
status	Draft
created	2022-06-07
requires (*optional)	<CLIP number(s)>

Abstract
CollabLand Verifiable Credentials should be stored in a neutral third-party data store under user control. A native integration for CollabLand and Privy would enable user-controlled storage of VCs in a secure off-chain environment. This would mean integrating the Privy API with CollabLand interfaces to enable VCs issued via CL to be stored within Privy, retrieved by the user and shared with authorized third-parties.

Motivation
VC integrations will enable CollabLand to sign richer attestations for its users powering stronger communities with users controlling their core identity.

This integration would enable user-control of issued verifiable credentials and help bridge the gap between the UX of VC control and the underlying secure storage of said credentials so the CollabLand ecosystem can integrate rich user data.

This would enable:

• decentralized user control of issued credentials
• private-by-default credential usage, stored e2ee in a third party data store
• richer UX as part of Collab.Land communities without sacrificing user privacy

Doing this entails:

• VCs are accessible to users cross-device/browser using their existing auth solutions
• VCs are stored in encrypted, secure off-chain storage
• Access to user VCs is controlled by the user themselves.

Specification

Collab.Land can issue VCs on behalf of users.

These credentials can be stored for users in Privy natively, thereby enabling users to control their VCs natively using trusted hosted infrastructure. Any default registry must be built upon existing authentication infrastructure provided by Collab.Land and take care of client-side encryption, and flexible access control on behalf of the user. This entails:

Privacy

• Ability for a given user to authenticate directly with the datastore without needing a backend
• Ability to store and retrieve signed JSON into an encrypted third party datastore

Portability

• Ability for CL users to pick from a set of default VC registries to store in
• Ability for the user to export their VC natively
• Ability for the user to delete their VC from the datastore

Sprawl minimization

• Ability for the user to list all issued VCs associated to their identifier
• Ability for the user to update (allow and revoke) permissions related to any given VC for a third party -- this entails that VC being signed over to that specific third party by the user

Rationale
The proposed MVP is built around the need to balance UX, user privacy and data portability for the user. Specifically, this includes:

• default integration with a datastore -- to enable VC storage in a way that is fully transparent to the user: the system just works (TM) and requires no upfront configuration
• default ability to change datastores/export/delete VCs from datastore -- user should not be locked in to a given datastore
• native direct authentication -- user must be able to authenticate with the datastore directly using existing authentication credentials so they are not dependent on a third party who would have the ability to impersonate the user to the datastore. Authentication is the cornerstone of user data control.
• native datastore encryption -- VCs contain sensitive data and must be encrypted at the datastore lest off-chain datastores become honeypots.
• flexible permissions -- users should be able to grant/revoke access to VCs to individual third parties without having the VC move to a third-party datastore.

Backwards Compatibility
Any future updates to the initial POC must include support for old interfaces into VC registries to ensure that stored VCs remain accessible to users in perpetuity.

Test Cases
Collab.Land provides:

• User DIDs
• Signed VCs

Privy provides:

• Means of creating authenticated sessions for user
• Ability to store/retrieve e2ee data from data store
• Flexible permissions system with APIs to enable users to share or revoke access to VCs
• Deletion API

Reference Implementation
TBD

Security Considerations (Initial Considerations - Refined During POC Creation)
TBD

Similar Reference Implementations
Privy currently has a few reference implementations and has documented APIs.

Missing Categories?
Usability