Open DRK3 opened 4 years ago
@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.
One way it would work for us is if the SDS:
delegator
We are still faced with a bootstrapping dilemma for existing users (chicken&egg)...
New users also have a similar problem:
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.
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?
Relevant TODO in digitalbazaar/bedrock-edv-storage: https://github.com/digitalbazaar/bedrock-edv-storage/blob/abc79792fb7eda7725e582a5c9dd1bf931ce4d0a/lib/http.js#L268-L270
PR that adds validations to endpoints: https://github.com/digitalbazaar/bedrock-edv-storage/pull/64 disregard - PR only validates JSON schemas
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.
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.