draft: DidDocument integration #864
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## main #864 +/- ##
==========================================
- Coverage 48.96% 47.96% -1.01%
==========================================
Files 429 462 +33
Lines 34225 35414 +1189
Branches 7594 7749 +155
==========================================
+ Hits 16759 16985 +226
- Misses 12208 13139 +931
- Partials 5258 5290 +32
Flags with carried forward coverage won't be shown. Click here to find out more.
|
mirgee
force-pushed
the
integration/did-doc
branch
6 times, most recently
from
32e32ff
to
b4452fe
Compare
mirgee
commented
May 31, 2023
| { | ||
| controller: '2RjtVytftf9Psbh3E8jqyq', | ||
| id: '1', |
There was a problem hiding this comment.
The problem here is 1 is not a valid DidUrl, so the deserialization fails with this value. The correct value here would be did:sov:2RjtVytftf9Psbh3E8jqyq#1.
mirgee
commented
May 31, 2023
| @@ -62,7 +63,7 @@ export const ARIES_CONNECTION_REQUEST = { | |||
| { | |||
| id: 'did:example:123456789abcdefghi;indy', | |||
| priority: 0, | |||
| recipientKeys: ['2RjtVytftf9Psbh3E8jqyq#1'], | |||
There was a problem hiding this comment.
Currently, after converting from the new to legacy DDO format, resolving key by reference fails. Since this is a field specific to the Sovrin DID method, the dereferencing should probably be responsibility of ExtraFieldsSov and is not implemented currently.
mirgee
force-pushed
the
integration/did-doc
branch
3 times, most recently
from
2b618c9
to
b72de4b
Compare
|
Postponed until
|
Signed-off-by: Miroslav Kovar <miroslav.kovar@absa.africa>
mirgee
force-pushed
the
integration/did-doc
branch
from
b72de4b
to
3388483
Compare
Patrik-Stas
changed the title
Patrik-Stas
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Replaces the use of
diddoc_legacy::aries::diddoc::AriesDidDocwithdid_doc::schema::did_doc::DidDocument, anddiddoc_legacy::aries::service::AriesServicewithdid_doc::schema::service::Serviceacross the aries-vcx codebase.
Integration with mediated connection is skipped and
diddoc_legacywill be removed along withmediated_connection.The method specific fields of the service struct are now set via a type associated with the
DidResolvabletrait, where only fields specific to the sovrin method are used in the codebase for now. This choice impacts the current implementation of the resolver registry, which needs to be reconsidered.Moreover, currently, the service type is set manually during the construction of the
DidDocument, and theacceptfield is not set at all. However, as per the Sovrin DID method specification, the value of those two fields is implied by the composition of / fields included in the service. This suggests that potentially we might want to wrap theDidDocumentBuilderin some kind ofDidDocumentBuilderSovresponsible for this method-specific logic in the future.This would be also useful because the extra fields are defined in
did_resolver_sov. In some use-cases, the entire resolver is imported only for the extra fields needed in order to name theDidDocumentorServicetype.The DID parser fails to parse any did which is not fully qualified. This is desirable in cases where fully qualified DID is required as it forces early failure. But in situations where the method is implied, an unqualified DID may also be valid and usable. Therefore, perhaps a separate type should be created to be used in these cases.
As it stands, this integration is a breaking change as it changes the format of the
did_docfield in the serialized connection state machines in both non-backwards-compatible and non-forwards-compatible way (e.g. some fields optional in the legacy format are now required andpublicKeyused in the legacy format is not a valid DDO field - it can probably be mapped to another valid field when deserializing, but currently isn't).