-
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
Did-exchange PR revival #1046
Did-exchange PR revival #1046
Conversation
a821d0e
to
e5eb72e
Compare
8d2c6cd
to
e433820
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## feature/did-exchange #1046 +/- ##
======================================================
Coverage ? 0.05%
======================================================
Files ? 471
Lines ? 24009
Branches ? 4307
======================================================
Hits ? 13
Misses ? 23995
Partials ? 1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
03c8f44
to
8c2fee1
Compare
23a4a2b
to
266ee29
Compare
e5eb72e
to
79cc60a
Compare
f4c5b78
to
60fd307
Compare
79cc60a
to
41f85b9
Compare
14096f3
to
5be1a4c
Compare
Signed-off-by: Patrik Stas <[email protected]>
41f85b9
to
dcd987c
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.
Just a couple of things I noticed on a quick skim, will do a more detailed review later
aries_vcx/src/protocols/did_exchange/state_machine/generic/mod.rs
Outdated
Show resolved
Hide resolved
// todo: no unwrap pls | ||
let service = did_document.service().first()?; | ||
// todo: will get cleaned up after service is de-generified | ||
Some(match service { |
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.
This should be performed by ServiceSov
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.
moved as helper to aries agent, will probably look different after de-generification of did document
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.
It will look different, but does your idea include abolishment of ServiceSov
?
5be1a4c
to
a9829b7
Compare
- Generalize did_resolver_sov - Move methods - Remove did-exchange send_message method - Address more code review comments Signed-off-by: Patrik Stas <[email protected]>
36e00a9
to
1439ee2
Compare
.base58(); | ||
EncryptionEnvelope::create( | ||
wallet, | ||
json!(message).to_string().as_bytes(), |
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.
It would be better to not use a potentially panicking macro
* Restore did-exchange * Address code review Signed-off-by: Patrik Stas <[email protected]>
main
since the original did-exchange PR DID Exchange Protocol #928oob
invitation fordid-exchange
, drop support for others - the protocol is not supposed to handle legacy connection pairwise or connection public invitationspub async fn send_message<T>(&self, wallet: &impl BaseWallet, message: &AriesMessage, transport: &T)
for did-exchange - this makes this a lot simpler in higher levels, eg. inaries-vcx-agent
mediator
agent, remove localoob2did
in favor of reusingaries_vcx
'soob_invitation_to_legacy_did_doc
aries_vcx/src/common/ledger/transactions.rs
move functions from this file to more appropriate filearies_vcx/src/handlers/out_of_band/receiver.rs
andaries_vcx/src/protocols/connection/invitee/mod.rs
ConstructRequestConfig
- given we are now using generics rather than trait objects, these objecs would now start involving generics, as you can use syntax such as&impl IndyLedgerRead
in struct definition. I have more arguments for the changerevoke_credential_local
- first of all, workflows should not do asserts; secondly, the asserts didn't really make sense and was probably originating from lot older code after rounds of refactoringNext steps:
aries_vcx
into/aries
directory - before any new activity foraries_vcx
emerges in PRsDidExchangeRequester<RequestSent>
constructs requests messages - currently there's 2 functionsconstruct_request_pairwise
andconstruct_request_public
with different set of arguments and certain assumptions. To keep the interface simple, and given we operate in Aries paradigm, the input should be an OOB Invitation message. Then, this processing function should ideally support variety of DIDs which might appear in the inivtation - for starter:did:peer:4
anddid:sov
.