feat: SDS EDV format provider #2210
Conversation
DRK3
force-pushed
the
EncryptedProviderSkeleton
branch
from
dba30a6 to
1993b8d
Compare
DRK3
changed the title
|
Note for reviewers: I recommend you start by looking at the |
DRK3
force-pushed
the
EncryptedProviderSkeleton
branch
from
1993b8d to
76855ec
Compare
|
|
||
| "github.com/hyperledger/aries-framework-go/pkg/storage" | ||
| "github.com/hyperledger/aries-framework-go/pkg/storage/sds" | ||
| "github.com/hyperledger/aries-framework-go/pkg/storage/sds/edvformatprovider/edvdocumentprocessor" |
There was a problem hiding this comment.
edvformatprovider depends on a sub package (edvdocumentprocessor), is the document processor only going to be used by the format provider?
There was a problem hiding this comment.
Yes. The EDVFormatProvider will use it to do the encryption before storing in the underlying provider, and it'll also use it for decrypting the data from the underlying provider. The idea is that the existing providers work without making any changes. In another PR I'll be pushing in the near-future, I'll be adding the EDV rest API as a provider as well that can be used as an underlying provider.
There was a problem hiding this comment.
(per our offline conversation, I made the EDVFormatProvider and EDVDocumentProcessor packages siblings in terms of their folder hierarchy.)
|
|
||
| // EDVDocumentProcessor represents a type that can encrypt and decrypt between | ||
| // Structured Documents and Encrypted Documents. | ||
| type EDVDocumentProcessor interface { |
There was a problem hiding this comment.
is there going to be a default implementation of this interface?
There was a problem hiding this comment.
Yes - the default implementation will use the Aries JOSE Encrypter and Decrypter.
DRK3
force-pushed
the
EncryptedProviderSkeleton
branch
from
76855ec to
6aa5de6
Compare
|
|
||
| // EDVDocumentProcessor represents a type that can encrypt and decrypt between | ||
| // Structured Documents and Encrypted Documents. | ||
| type EDVDocumentProcessor interface { |
There was a problem hiding this comment.
all packages, files and interface start with edv - there is a lot of stutter
There was a problem hiding this comment.
Moved all the "edv" files within a folder and removed that prefix.
DRK3
force-pushed
the
EncryptedProviderSkeleton
branch
from
6aa5de6 to
31d2031
Compare
DRK3
force-pushed
the
EncryptedProviderSkeleton
branch
2 times, most recently
from
4777bf6 to
574ad52
Compare
Codecov Report
@@ Coverage Diff @@
## master #2210 +/- ##
==========================================
+ Coverage 89.52% 89.57% +0.04%
==========================================
Files 220 221 +1
Lines 15032 15094 +62
==========================================
+ Hits 13458 13520 +62
Misses 935 935
Partials 639 639
Continue to review full report at Codecov.
|
|
|
||
| "github.com/hyperledger/aries-framework-go/pkg/storage" | ||
| "github.com/hyperledger/aries-framework-go/pkg/storage/sds" | ||
| "github.com/hyperledger/aries-framework-go/pkg/storage/sds/edv/documentprocessor" |
There was a problem hiding this comment.
we might need to come back to this topic - sds/edv seems a bit odd, but I don't currently have a better suggestion.
There was a problem hiding this comment.
Removed the sds folder and just moved edv to be directly under storage for now since everything that's in there is purely EDV-related. The SDS spec is still in flux so perhaps this should change in the future.
pkg/storage/sds/models.go
Outdated
| SPDX-License-Identifier: Apache-2.0 | ||
| */ | ||
|
|
||
| package sds |
There was a problem hiding this comment.
I'm slightly confused about the split between the sds package and the edv package.
Aren't these models related to the edv portion of the sds spec?
There was a problem hiding this comment.
Indeed they are... that was an error on my part. I've moved models inside the edv package.
DRK3
force-pushed
the
EncryptedProviderSkeleton
branch
2 times, most recently
from
99c76a2 to
0746e1b
Compare
This new provider type allows for data to be stored in an underlying provider using the EDV document models. Signed-off-by: Derek Trider <Derek.Trider@securekey.com>
DRK3
force-pushed
the
EncryptedProviderSkeleton
branch
from
0746e1b to
563bb83
Compare
This new provider type allows for data to be stored in an underlying provider using the EDV document models.
Signed-off-by: Derek Trider Derek.Trider@securekey.com