-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change: simplify didcore components, did-exchange protocol #1075
Conversation
476d5e8
to
53f3a26
Compare
1caf5e1
to
33e34cd
Compare
33e34cd
to
6442acc
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1075 +/- ##
======================================
Coverage 0.05% 0.05%
======================================
Files 473 476 +3
Lines 24239 24137 -102
Branches 4492 4498 +6
======================================
Hits 13 13
+ Misses 24226 24124 -102
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
d15cdcb
to
3e42245
Compare
f9f8e2c
to
daff7fb
Compare
5fc1905
to
a00160a
Compare
784828a
to
dc17346
Compare
8fdd9c6
to
f1af5c5
Compare
d0fdfcd
to
7d5a064
Compare
354362b
to
4a3a300
Compare
5dcd014
to
e0c163e
Compare
e0c163e
to
79fadb5
Compare
87a5de5
to
43be694
Compare
43be694
to
ea718f8
Compare
ff3bc02
to
4e99c35
Compare
87e13ab
to
560a143
Compare
69d80d3
to
80dc4d7
Compare
Signed-off-by: Patrik Stas <[email protected]>
80dc4d7
to
053055e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Skimmed thru aries changes. nice stuff
The changes in this PR are primarily stemming by removing generics on
DidDocument
andService
data structures. This change trickles-up significantly all the way to did-exchange implementation. This enable many simplifications and removal of lots of code. Some other improvements has been done on the way as well.I recommend start looking at the PR from top down to understand public API effect of the changes.
Demo
aries/aries_vcx/tests/test_did_exchange.rs
is the top-most level of changesSimplified
DidExchangeRequester
construct_request
which simple accepts aDid
as input - can be any resolvable DID. This means it's also possible to establish didcomm any 2 entities which have DID - be itdid:peer
,did:sov
or any other DID.services
VSfrom
) aries-rfcs#802. We can implemented later if desired by any vcx users, but solution is ugly - it would be needed to convert Service object to Did Document which doesn't make sense.These changes also lead to internals simplification where bunch of transformation code could been removed
Simplified
DidExchangeResponder
DidExchangeRequester
(inviter) needs to provide their pairwisePeerDid
for the counterparty upon constructingResponse
message. This means that currently the responder always rotates their DID, regardless of what kind of DID they used in invitation. Making rotation optional will be addressed in the future.invitation_id
fromreceive_request
method signature. Also, don't keep this information in SM state - the responder might receive request which is not constructed on basis of any invitation - but rather simply on basis of knowing responder's public DID. Invitation might not exist in a first place, so it doesn't make sense to store its ID.DidCore
Removed generics
The main goal of the PR was simplification of DidCore components - mainly removing generic type parameters from
DidDocument<E>
andService<E>
. This lead to many changes, but in scope of DidCore components:DidDocument
can represent any valid Did Document with any extra fields. Instance ofService
can represent any Service object, with any extra fields.routingKeys
,recipientKeys
,accept
etc. Given the "extra" typing we dropped, the current typing design has following considerations:did_doc
crate wants to support, work with. Hence it's up to applications to decide either work withDidDocument
/Service
as their are, or convert these to custom types in runtime, if typed environment for extra fields is needed.struct ServiceDidCommV1
,struct ServiceDidCommV2
. These tend to be useful when the user wants to construct particular service type themselves. Equally, as mentioned in the previous pointi., user can also choose to convert
Serviceto more explicit types such as
ServiceDidCommV1upon resolution. However, in practical terms so far in
aries_vcx`, this was not really needed.New features
get_service_of_type, get_key_agreement_of_type
to support data lookups within did documents.Refactoring
url::Url
crate indid_doc
crateError handling
DidDocumentBuilderError
now has only singleKeyDecodingError
variant, which itself hold further more details about particular decoding issuedid_doc
crate, such asJsonWebKeyError
,MultibaseWrapperError
,KeyDecodingError
and others to avoid misusingDidDocumentBuilderError
in contexts where we are not in fact using did document builder.Other changes
Testing
pretty_assertions
https://github.com/rust-pretty-assertions/rust-pretty-assertions#usage as dev dependency to some of the crates and testsLogging
Display
for more structsRefactoring
aries-vcx-agent
did-exchange service is generating invitation withdid:peer
as value ofservices
, rather than inlining service object.MakeDidPeer<Numalgo2> --- DDO
user friendlier. Instead of calling "util" functionresolve_numalgo2(did PublicKeyEncoding::Base58)
this is now donedid.to_did_doc(PublicKeyEncoding::Base58)
EncryptionEnvelope
)DidDocument
structures. Noteworthy is thatkey_agreement
is used for encryption rather thanrecipientKeys
"extra field". The thing is,peer:did:2
doesn't even define howrecipientKeys
should be abbreviated, I believe it assumes it wouldn't be used anymore.Fix
did:peer:3
validation regex did not allow DIDs which contains Service only. But all fields in Did Document are optional - except id, did:peer:3.S.* is valid DID too.Note