solid-contrib / cryptography-and-security Goto Github PK

Standardization activity on how to do client-side data encryption for personal data storage is heating up in the wider standards community, led by the W3C Credentials Community group and the Decentralized Identify Foundation (DIF) (including Microsoft, Workday, Consensys, and others). This is also relevant to Solid, for use cases that have strong client-side data encryption requirements (such as storage of health records and other high-value items).

The current Linked-Data-friendly standard being incubated jointly by those groups is the Encrypted Data Vault spec (see the introductory Encrypted Data Vault requirements paper).

This is a placeholder issue to track pre-requisite specs and infrastructure to enable client-side encryption on Solid.

Pre-requisite infrastructure:

• - #3 - Support for Linked Data Signature key format for WebID Profile docs
• - #4 - Key Management API / best practices for Solid pods
• - (optional but helpful for wider interop) identity-panel/#1 - Support for Decentralized Identifiers (DIDs)

@kezike's excellent exploration / prototype of Verifiable Credentials on Solid demonstrated initial implementation feasibility. Now that the Verifiable Credential Model is an official W3C standard, this is a placeholder issue to track use cases, interoperability and infrastructure requirements for VC use for the Solid ecosystem.

Pre-requisite infrastructure for VCs on Solid:

• - #3 - Support for Linked Data Signature key format for WebID Profile docs
• - #4 - Key Management API / best practices for Solid pods
• - (optional but helpful for wider interop) identity-panel/#1 - Support for Decentralized Identifiers (DIDs)
• - (optional but helpful) specification/#101 - WebID Profiles for Groups/Organizations (useful for Issuer applications)

In addition to the 2008 Cert ontology (which only expresses RSA keys), Solid WebID Profile documents should support expressing keys and cryptographic material using the current Linked Data Signatures format.

This would yield the following benefits:

• Enables support of other key formats, such as the Ed25519 (useful for signatures), Curve25519 (useful for encryption), and EcdsaSecp256k1 keys (useful for deterministic hierarchical key generation, used by many blockchains)
• Enables the usage of the WebID Profile document for the purposes of W3C Verifiable Credentials
• Moves the WebID Profile document towards compatibility with the W3C DID (Decentralized Identifiers) standard.

Example RSA key using LD-Sig:

<#key1>
  <http://purl.org/dc/terms/created> "2017-09-23T20:21:34Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
  <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#RsaVerificationKey2018> .
  <https://w3id.org/security#controller> <https://alice.solid.community/profile/card> .
  <https://w3id.org/security#publicKeyPem> "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" .

Several advanced use cases on the Solid roadmap (such as Verifiable Credentials and data encryption) will require user-level key management.

This is a placeholder issue to track specification of a KMS API that a Solid pod could potentially provide key management for users.

References:

• W3C Credentials Community Group WebKMS spec

Consensus: Solid project should instead switch over to using the @peculiar/webcrypto-core library, which is a drop-in replacement for @trust/webcrypto, and is better supported.

Original issue:
Should Solid project adopt the @trust/webcrypto library

One of the dependencies used by many of our crypto-related libraries is the @trust/webcrypto package. It's used in the jose lib (and through it, in auth-solid-client), as well as in the oidc-rp lib.

The problem is this: @trust/webcrypto has been archived, and is no longer actively maintained at that original repo. I've always figured we'd get around to deciding its fate eventually, but since an external developer brought up this issue in nodeSolidServer/oidc-rp#26, I think we should have this discussion.

It's a good library, and is used by several non-Solid groups (such as Digital Bazaar in the minimal-cipher lib), and recently the larger Self-Sovereign Identity community has expressed increasing interest in it.

The decision we have before us is this:

Should the Solid project step forward to maintain the webcrypto library?

Reasons to adopt it:

• It's used throughout our authn stack, and will become even more useful once we get into features like DIDs and encryption.
• Adopting it will let the Solid project have a larger degree of control than if it's maintained by another group

Reasons not to adopt it (and let some other group pick it up):

• Time / developer resources
• I've talked to a couple of groups that are interested in taking on the task if Solid doesn't.

cc @jaxoncreed @pjworrall @justinwb @michielbdejong @kjetilk @robmccoll and whoever else wants to join in this discussion.