Collection Reference

[michaelsena]

cip: 29
title: Collection Reference
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-29)

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

This CIP describes a Collection Reference, which contains user-specific information about the data stores defined in a given Collection Definition (CIP-28).

Abstract

The Collection Reference contains user-specific information about data stores defined in a given Collection Definition (CIP-28). The Collection Reference stores things like unique storeID, host, and more that allow third-parties to locate and interact with the user's data. This document is created and updated as the user interacts with the application to which it applies.

Collection References are complimentary to Collection Definitions (CIP-28), which describe the generic data model of data stores referenced in a Collection Reference. Links to both of these documents are stored in a DID's Collections Index (CIP-16), providing a way for user data to be made interoperable across application and platforms.

Motivation

Specification

Schema

The Collection Reference stores a collectionDef as a global value, and then stores an array of objects which each include reference, storeId, host, and applications.

collectionDef: The DocId of the Collection Definition (CIP-28) to which this Collection Reference applies.

reference: A pointer to a specific entry in the Collection Definition that is possessed by this DID.

storeId: A unique identifier for the user's store. Depending on storeType, this can be the unique address of a peer-to-peer database, an entry in a registry, the ID/hash of a transaction, or the DocId of a Ceramic document.

host: A pointer to a location where the data store is hosted. This can be a centralized service or a decentralized, peer-to-peer network.

applications: A list of applications that have been granted access to the data store.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "title": "CollectionReference",
  "additionalProperties": false,
  "required": [
    "collectionRef",
    "references"
  ],
  "properties": {
    "collectionRef": {
      "$ref": "#/definitions/CeramicDocId"
    },
    "references": {
      "type": "array",
      "items": {
        "$ref": "#/definitions/CollectionRef"
      }
    }
  },
  "definitions": {
    "CeramicDocId": {
      "type": "string",
      "pattern": "^ceramic://.+(\\?version=.+)?"
    },
    "CollectionRef": {
      "type": "object",
      "required": [
        "reference",
        "storeId",
        "host",
        "applications"
      ],
      "properties": {
        "reference": {
          "type": "string",
          "title": "reference"
        },
        "storeId": {
          "type": "string",
          "title": "storeId"
        },
        "host": {
          "type": "string",
          "title": "host"
        },
        "applications": {
          "type": "array",
          "title": "applications",
          "items": {
            "type": "string"
          }
        }
      }
    }
  }
}

Usage

Encryption:

Data Interoperability Protocol (DIP):

[simonovic86]

@oed @michaelsena updated the schema

[Schwartz10]

How does the applications block relate to the access-control doctype? How do they interact with one another? How is this access control enforced?

One potentially naive thought that comes to mind is to have an optional "secret" property here. Uncovering the secret would allow access to the underlying data store in reference. The access-control doctype could provide more information about how to decode and use the secret? Is that dangerous? Do doctypes generally store secrets?

[oed]

@Schwartz10 yeah I think that's a resonable approach. We've thought about storing symmetric encryption keys within a separate document, encrypted to the public key of the DID. Each symmetric key is then used to encrypt an entry in the collection reference here.

[oed]

Closing, stale.