Implement remaining DataVaultConfiguration properties

[DRK3]

There are additional properties in DataVaultConfiguration objects that haven't been implemented, such as sequence, controller, delgator, etc.

However, there aren't a lot of details on these fields and there still seems to be some things in the spec that need to get worked out since there's a note in that section that says:

ISSUE 5 Data vault configuration isn't strictly necessary for using the other features of data vaults. This should have its own conformance section/class or potentially event be non-normative.

We should figure out what to do here, perhaps after the spec has been updated?

See https://www.youtube.com/watch?v=1zNe_KsdszI to see how Transmute uses a DID to verify that the controller is indeed the one accessing the vault.

[llorllale]

@DRK3 the delegator property would allow the vault's controller to authorize access to third parties without authorization servers involved.

Example: the end-user stores their primary key shares in SDS' and authorize the Key Server to read them. Without delegator or some other mechanism that allows the end-user agent to act directly as an authorization server, third parties would need to be redirected to an AS that would then contact the user (authN/Z). This is clearly not a desired outcome for us because the user should not have to perform N>1 authorizations during their onboarding.

[llorllale]

One way it would work for us is if the SDS:

• protects the endpoint that creates data vaults with OAuth2, and
• protects the other endpoints that do any CRUD on a specific data vault with delegator

[llorllale]

We are still faced with a bootstrapping dilemma for existing users (chicken&egg)...

1. Wallet would need possession of secrets in order to access their vault
2. Secrets are either: a) the primary key shares, which are stored in the same SDS vaults we are trying to access, or b) operational keys, which are stored in the Key Server, for which we need the primary key shares to unlock.....

[llorllale]

New users also have a similar problem:

1. Can create data vault with OAuth2 authz
2. Cannot create documents without proving controllership of key. In this case this is the user's primary key.

[llorllale]

Also I think delegator is not the correct place to authZ access to individual SDS documents... apparently this aspect is delegated unto the JWE spec as per this example:

POST /encrypted-data-vaults/z4sRgBJJLnYy/docs HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate

{
  "id": "urn:uuid:94684128-c42c-4b28-adb0-aec77bf76044",
  "sequence": 0,
  "jwe": {
    "protected": "eyJlbmMiOiJDMjBQIn0",
    "recipients": [{
      "header": {
        "alg": "A256KW",
        "kid": "https://example.com/kms/zSDn2MzzbxmX"
      },
      "encrypted_key": "OR1vdCNvf_B68mfUxFQVT-vyXVrBembuiM40mAAjDC1-Qu5iArDbug"
    }],
    "iv": "i8Nins2vTI3PlrYW",
    "ciphertext": "Cb-963UCXblINT8F6MDHzMJN9EAhK3I",
    "tag": "pfZO0JulJcrc3trOZy8rjA"
  }
}

The document is simply encrypted for a list of recipients. The key server can be one of those recipients.

[llorllale]

The above still doesn't answer the authZ question though... how is the requesting party sending this request get authorized to fetch the document and attempt to decrypt?

[llorllale]

Relevant TODO in digitalbazaar/bedrock-edv-storage: https://github.com/digitalbazaar/bedrock-edv-storage/blob/abc79792fb7eda7725e582a5c9dd1bf931ce4d0a/lib/http.js#L268-L270

[llorllale]

PR that adds validations to endpoints: https://github.com/digitalbazaar/bedrock-edv-storage/pull/64 disregard - PR only validates JSON schemas

[llorllale]

DB is using HTTP signatures via digitalbazaar/http-signature-zcap-verify.

The HTTP headers carry zCAP tokens that provide the foundation for their authorization mechanism.