decentralized-identity / confidential-storage

Confidential Storage Specification and Implementation
https://identity.foundation/confidential-storage/
Apache License 2.0
78 stars 23 forks source link

PROPOSAL: Anyone with the link has the capability to access the resource #157

Closed OR13 closed 3 years ago

OR13 commented 3 years ago

Consider the capability:

const unsignedCapability = {
      '@context': "https://w3id.org/security/v2",
      id: `urn:uuid:123`,
      invocationTarget: `https://vault.example/edvs/456/documents/789`,
      invoker: did:key:000,
      allowedAction: 'read',
      parentCapability: `https://vault.example/edvs/456/zcaps/documents/789`,
      proof: {}
    };

If we want to make a link to this document which allows anyone to access the document, but which can be revoked at any point in the future, we can construct a new URL as follows:

https://my.app.example/share#base64url(capability,privateKeyJwk)

note that CORS is not an issue since EDVs rely on http signatures for security, ANY application on ANY domain, can access the resource, so for example:

https://my.app2.example/share#base64url(capability,privateKeyJwk)

Is also able to access the resource.

the privateKeyJwk must be transformed into 2 did keys.

  1. Ed25519 Invocation Signer Key
  2. X25519 KeyAgreementKey

If hmac is needed, it can be generated directly from "d" or hashes of d, etc.. deterministically.

Note that in current implementations, only publicKeyBase58 is allowed for expressing key material, but this could be fixed in the future, by using https://github.com/transmute-industries/did-key.js or similar which supports JWK and Base58 keys.

It's also possible for my.app2.example to be a progressive web application with offline support, so the URL will continue to work without network access.

In the future, we might want to support other protocol handlers, like:

didcomm://my.app2.example/share#base64url(capability,privateKeyJwk)