-
Notifications
You must be signed in to change notification settings - Fork 208
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
feat: OOB public did #930
feat: OOB public did #930
Conversation
@TheTreek @JamesKEbert Please take a look at this PR |
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.
Thanks for this @Iskander508! Left some notes / comments on how we may approach it a bit differently, but overall I like the direction of this.
const invitationRecipientKeys = outOfBandRecord | ||
.getTags() | ||
.recipientKeyFingerprints.map((fingerprint) => Key.fromFingerprint(fingerprint)) |
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.
I think we should store the invitation recipient keys with public did keys from the start rather than in the .
My proposal would be to move the recipientKeyFingerprints
from the default tags (generated on save) to custom tags that we must set ourselves. When processing the invitation we can set all recipient keys. The advantage is that we only need to do it once for both connection and didexchagne protocol, and we also don't need this or functionality (we now only add the did recipient keys if we don't have any inline didcomm service keys).
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.
Yes, I get the point and fully agree that it would be better to store the recipient keys at the start of the connection process. However I'm not sure where exactly to do that. To get the recipient keys, we need to run the did resolution for services from the ledger (which is quite costly operation).
I thought of 2 options:
- Either to do it right when creating the OOB record in
OutOfBandModule.receiveInvitation
. Which would mean to run an additional resolution. Also I'm not sure what to put there in case when we are creating the invitation (OutOfBandModule.createInvitation
) - Store the recipientKeys into the record once we have already resolved them (when sending the connection request message in
MessageSender.retrieveServicesByConnection
): https://github.com/hyperledger/aries-framework-javascript/blob/49f8a1b9f9e1c9223755f39f5445ff2fc89e8627/packages/core/src/agent/MessageSender.ts#L363)
I'm also not familiar with the concept of the custom/default tags to be honest. Currently the recipientKeyFingerprints are retrieved from the OOB invitation object: https://github.com/hyperledger/aries-framework-javascript/blob/49f8a1b9f9e1c9223755f39f5445ff2fc89e8627/packages/core/src/modules/oob/repository/OutOfBandRecord.ts#L69 Does it mean they are not saved as tags? Or am I missing something?
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.
Which would mean to run an additional resolution
Where would we need the additional resolution for?
I'm also not familiar with the concept of the custom/default tags to be honest. Currently the recipientKeyFingerprints are retrieved from the OOB invitation object:
We have two types of tags in AFJ; default and custom. Default tags are set in the getTags
method on a record. This can contain derived properties (such as the recipientKeysFingerprints, but can't be async. This worked with inline services, but if we want to get the recipientKeyFingerprints for the public dids we need to do the async resolving. What we can do is remove it from the default tags (so we're not setting it anymore in the getTags method), and rather set it manaually using
record.setTag('recipientKeyFingerprints', theKeys)`.
You would have to create a new type CustomOutOfBandRecordTags
type, and add it here: https://github.com/hyperledger/aries-framework-javascript/blob/49f8a1b9f9e1c9223755f39f5445ff2fc89e8627/packages/core/src/modules/oob/repository/OutOfBandRecord.ts#L26-L33
type DefaultOutOfBandRecordTags = {
role: OutOfBandRole
state: OutOfBandState
invitationId: string
}
type CustomOutOfBandRecordTags = {
recipientKeyFingerprints?: string[]
}
export class OutOfBandRecord extends BaseRecord<DefaultOutOfBandRecordTags, CustomOutOfBandRecordTags> {
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.
Great, thank you for the explanation of the tags.
Which would mean to run an additional resolution
Where would we need the additional resolution for?
I meant if we now additionally run a resolution right in the beggining when creating the oob record, that would be the additional resolution. I'll try with the approach n°2, to set the recipientKeyFingerprints after sending the credential request message (for the case of public did invite), otherwise set it immediately when creating the oob record from the invitation's inline services.
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.
I have added the filling of the recipientKeyFingerprints
as custom tags.
For inline services it is stored immediately when creating the oob record. For public did services this is done later in the flow inside the MessageSender
(when resolving the public did from the ledger)
packages/core/src/modules/connections/services/ConnectionService.ts
Outdated
Show resolved
Hide resolved
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
217eaeb
to
44e0783
Compare
Codecov Report
@@ Coverage Diff @@
## main #930 +/- ##
==========================================
- Coverage 88.18% 88.13% -0.05%
==========================================
Files 488 492 +4
Lines 11552 11613 +61
Branches 1921 1933 +12
==========================================
+ Hits 10187 10235 +48
- Misses 1305 1317 +12
- Partials 60 61 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
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.
Really nice improvements @Iskander508! I left some additional comments.
It would be good to add some more tests, but otherwise this is close to being ready to merge. Did you make any breaking changes in this PR? If we can avoid any breaking changes and postpone that to 0.3.0 we can get this in 0.2.x and have it released a lot sooner
const invitationRecipientKeys = outOfBandRecord | ||
.getTags() | ||
.recipientKeyFingerprints.map((fingerprint) => Key.fromFingerprint(fingerprint)) |
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.
Which would mean to run an additional resolution
Where would we need the additional resolution for?
I'm also not familiar with the concept of the custom/default tags to be honest. Currently the recipientKeyFingerprints are retrieved from the OOB invitation object:
We have two types of tags in AFJ; default and custom. Default tags are set in the getTags
method on a record. This can contain derived properties (such as the recipientKeysFingerprints, but can't be async. This worked with inline services, but if we want to get the recipientKeyFingerprints for the public dids we need to do the async resolving. What we can do is remove it from the default tags (so we're not setting it anymore in the getTags method), and rather set it manaually using
record.setTag('recipientKeyFingerprints', theKeys)`.
You would have to create a new type CustomOutOfBandRecordTags
type, and add it here: https://github.com/hyperledger/aries-framework-javascript/blob/49f8a1b9f9e1c9223755f39f5445ff2fc89e8627/packages/core/src/modules/oob/repository/OutOfBandRecord.ts#L26-L33
type DefaultOutOfBandRecordTags = {
role: OutOfBandRole
state: OutOfBandState
invitationId: string
}
type CustomOutOfBandRecordTags = {
recipientKeyFingerprints?: string[]
}
export class OutOfBandRecord extends BaseRecord<DefaultOutOfBandRecordTags, CustomOutOfBandRecordTags> {
public getRecipientKeys(): Key[] { | ||
return this.services | ||
.filter((s): s is OutOfBandDidCommService => typeof s !== 'string' && !(s instanceof String)) | ||
return this.getInlineServices() | ||
.map((s) => s.recipientKeys) | ||
.reduce((acc, curr) => [...acc, ...curr], []) | ||
.map((didKey) => DidKey.fromDid(didKey).key) | ||
} |
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.
We should probably remove this method as it only takes into account inline didcomm services.
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 is still used on a few places. I'm not sure if it makes sense to remove it at this moment. What would be the replacement for the few spots, where it is used?
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.
Where is it used? The reason I'd like to remove it is that we should be taking into account public dids everywhere now. This methods makes it quite easy to forget the public did recipient keys, which can cause issues later
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.
Maybe it's better if you check for yourself:
DidExchangeProtocol.processResponse
: https://github.com/hyperledger/aries-framework-javascript/blob/main/packages/core/src/modules/connections/DidExchangeProtocol.ts#L303 (not sure how to deal with this one)OutOfBandRecord
initial tags in constructor: Here we store the recipient keys from the inline services (this we could probably refactor by expanding the function in place)migrateToOobRecord
: https://github.com/hyperledger/aries-framework-javascript/blob/main/packages/core/src/storage/migration/updates/0.1-0.2/connection.ts#L315 (here it looks like we have to deal with inline services only as well, so probably easy to expand)
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.
Ok so I think we can remove / refactor them all:
- This checks if the response is 'authorized' by the keys from the invitation. I think we can use the recipientKeyFingerprints from the tag for this and transform it into keys (
recipientKeysFingerprints.map(fingerprint => Key.fromFingerprint(fingerprint).publicKeyBase58)
) - I think we can remove the default tags assignment in the constructor. We should just set in once with the processing of both the dids and the inline services (it's redundant to set it in the constructor I think?)
- You're right we only have to deal with inline services here. Maybe we can copy the implementation directly to the migration file.
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.
I have removed the getRecipientKeys
method and refactored the 3 cases
All of this looks really good to me. |
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
I plan to take a look at the tests to increase coverage of the new cases. (EDIT: some additional unit-tests added) |
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
// store recipientKeyFingerprints in the oob record | ||
const oldRecipientKeyFingerprints = outOfBand.getTag('recipientKeyFingerprints') as string[] | ||
if (!oldRecipientKeyFingerprints?.length) { | ||
const allRecipientKeys = didCommServices.reduce<Key[]>( | ||
(aggr, { recipientKeys }) => [...aggr, ...recipientKeys], | ||
[] | ||
) | ||
outOfBand.setTag( | ||
'recipientKeyFingerprints', | ||
allRecipientKeys.map((key) => key.fingerprint) | ||
) | ||
await this.outOfBandRepository.update(outOfBand) |
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.
Did you place this here to prevent needing to resolve the did(s) multiple times? If so we should probably add some priority to caching
It feels like this maybe better placed inside the createInvitation method. What do you think?
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.
yes, it feels unclean to put it here, but this is the actual place where the service did resolution is performed currently. Caching somewhere in the resolver might be a viable solution. But it is always tricky to say when the cache should get invalidated.
const invitationRecipientKeys = outOfBandRecord | ||
.getTags() | ||
.recipientKeyFingerprints.map((fingerprint) => Key.fromFingerprint(fingerprint)) | ||
const invitationKey = invitationRecipientKeys[0]?.publicKeyBase58 |
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 will transform all keys, but we'll only use the first one. Is there a reason for this change?
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.
reverted
const key = keyReferenceToKey(didDocument, recipientKeyReference) | ||
if (key.keyType === KeyType.X25519) { | ||
// try to find a matching Ed25519 key (https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html#did-document-notes) | ||
const matchingEd25519Key = didDocument.verificationMethod | ||
?.map((method) => | ||
recipientKeyReference !== method.id ? keyReferenceToKey(didDocument, method.id) : null | ||
) | ||
.find((matchingKey) => { | ||
if (matchingKey?.keyType !== KeyType.Ed25519) return false | ||
const keyX25519 = Key.fromPublicKey(convertPublicKeyToX25519(matchingKey.publicKey), KeyType.X25519) | ||
return keyX25519.publicKeyBase58 === key.publicKeyBase58 | ||
}) | ||
if (matchingEd25519Key) return matchingEd25519Key | ||
} | ||
return key |
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 is great! Some small notes on the implementation:
- I think the
verificationMethod
as well as thekeyAgreement
can contain x25519 keys - Maybe we can extract this into a separate util in the didcomm module so its' easier to test and keeps the
resolveServicesFromDid
"simple"
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.
lookup extracted, keyAgreement
and authentication
references added
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
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.
Some final remarks. What is the status of the did exchange intergration. Is that something we want to add in a separate PR?
} | ||
} | ||
|
||
public getTags() { | ||
public getTags(): Tags<DefaultOutOfBandRecordTags, CustomOutOfBandRecordTags> { |
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 inferred I think. Is it giving issues?
public getTags(): Tags<DefaultOutOfBandRecordTags, CustomOutOfBandRecordTags> { | |
public getTags() { |
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.
explicit types removed
this._tags = props.tags ?? { | ||
recipientKeyFingerprints: props.outOfBandInvitation | ||
.getInlineServices() | ||
.map((s) => s.recipientKeys) | ||
.reduce((acc, curr) => [...acc, ...curr], []) | ||
.map((didKey) => DidKey.fromDid(didKey).key.fingerprint), | ||
} |
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.
I'm not sure we want to set this here. It doesn't take the public dids into account and will only be set if no custom tags were provided. I.e. If I create the record like this:
const record = new OutOfBandRecord({
anotherTag: '10'
})
It won't set the fingerprints , which I think is not desired.
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.
The resolution of recipient key fingerprints moved out of the constructor, and now the values are passed on each spot a new OOB record is created.
didCommServices = await this.didCommDocumentService.resolveServicesFromDid(service) | ||
|
||
// store recipientKeyFingerprints in the oob record | ||
const oldRecipientKeyFingerprints = outOfBand.getTags().recipientKeyFingerprints |
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 will only be set if the recipientKeys haven't been set yet, however the recipient keys are set in the out of band record constructor. Does this mean it will only work if there is only a did in the service array? If we have one inline service and one did this won't work I think.
If possible I'd like to make sure we're covering all cases. After thinking about it a bit more this probably isn't the best place to store this, and maybe we're better off doing it in the out of band module and take our loss with doing two resolves of the dids for now? (so method no 1 you described). If we want to keep it this way we should somehow take into account a mix of dids and inline services
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 part is now removed. The recipient keys are resolved already when creating the OOB record as suggested. No caching for the resolved services is done now. Maybe it can be added later as an optimisation.
Signed-off-by: Pavel Zarecky <[email protected]>
I guess so. I don't know how to test the didexchange protocol. So I cannot verify if it's already working or what needs to be done. |
SonarCloud Quality Gate failed.
|
@TheTreek has done some testing with this branch & ACA-Py, and everything is working as expected (using connections v1), except that there is a minor version mis-match between AFJ & ACA-Py (1.1 vs 1.0). IIRC you had an idea to solve this in mind @TimoGlastra? I think it probably falls outside of the scope of this PR, but it is definitely related. |
Can you characterize the 1.0/1.1 issue? Which library is doing what? At the Interop-a-thon, we should come out of it with all of the OOB-DID Exchange tests working between AFJ and ACA-Py, and perhaps some new tests added -- or at least defined. |
Is the version mismatch causing issues? AFJ should just allow the different version, as should ACA-Py. |
Fair point. Let's merge this and add support for public dids in didexchange later on |
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.
LGTM
Yeah, here's my best understanding of the issue @swcurran, as described in RFC 0003. According to my testing--the behavior is:
Here are the error logs from ACA-Py when performing connection reuse with the OOB minor version mismatch:
|
Dang -- that's not good. I'll get someone looking at this ASAP. I'll open an issue in ACA-Py. For RFC 0003, if ACA-Py doesn't support OOB 1.1, it should be respond with an OOB 1.0 handshake-reuse-accepted message, perhaps with a warning (but not likely). However, I would expect that ACA-Py should support OOB 1.1, but perhaps not. The only thing I wonder is since AFJ received an OOB 1.0, should it respond with an OOB 1.0? That would require that a protocol be able to support all "less than current" minor versions, and know what to do for each one. Basically, that would be -- in the final processing of the message, dropping fields corresponding to each lower version. Perhaps too much, but this conversation may happen. |
That's a good point, according to the RFC,
Fortunately I think the changes from 1.0 to 1.1 are fairly straightforward in OOB, although I had to hunt them down in the commit history (hyperledger/aries-rfcs@4a57f66) |
Re: hunting down the changes. I've had on my list for a while to update that RFC to put a proper change log in it. 😞 |
That would be a lot more complex than just responding with a 1.1 oob message (so we don't have to support multiple versions). As it's allowed I think it as nice way to keep interoperabillity without overly complicating the protocol implementation |
Wohoo! Thanks for this great contribution @Iskander508!! Let's try to get a new release out this week |
Signed-off-by: Ariel Gentile <[email protected]> fix: expose oob domain (openwallet-foundation#990) fix: some changes based on feedback Signed-off-by: Ariel Gentile <[email protected]> docs: a few clarifications and TODOs Signed-off-by: Ariel Gentile <[email protected]> feat: combine features Signed-off-by: Ariel Gentile <[email protected]> test(credentials): fix flaky tests with events (openwallet-foundation#966) Signed-off-by: 2byrds <[email protected]> feat: OOB public did (openwallet-foundation#930) Signed-off-by: Pavel Zarecky <[email protected]> feat(routing): manual mediator pickup lifecycle management (openwallet-foundation#989) Signed-off-by: Ariel Gentile <[email protected]> docs(demo): faber creates invitation (openwallet-foundation#995) Signed-off-by: conanoc <[email protected]> chore(release): v0.2.3 (openwallet-foundation#999) Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> fix: disclosures message fields and optional thid Signed-off-by: Ariel Gentile <[email protected]> fix(question-answer): question answer protocol state/role check (openwallet-foundation#1001) Signed-off-by: Ariel Gentile <[email protected]> refactor: move feature registration to module Signed-off-by: Ariel Gentile <[email protected]> fix: dependency manager test Signed-off-by: Ariel Gentile <[email protected]> fix: feature registry instance Signed-off-by: Ariel Gentile <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
* feat: OOB public did (#930) Signed-off-by: Pavel Zarecky <[email protected]> * feat(routing): manual mediator pickup lifecycle management (#989) Signed-off-by: Ariel Gentile <[email protected]> * docs(demo): faber creates invitation (#995) Signed-off-by: conanoc <[email protected]> * chore(release): v0.2.3 (#999) Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * fix(question-answer): question answer protocol state/role check (#1001) Signed-off-by: Ariel Gentile <[email protected]> * feat: Action Menu protocol (Aries RFC 0509) implementation (#974) Signed-off-by: Ariel Gentile <[email protected]> * fix(ledger): remove poolConnected on pool close (#1011) Signed-off-by: Niall Shaw <[email protected]> * fix(ledger): check taa version instad of aml version (#1013) Signed-off-by: Jakub Koci <[email protected]> * chore: add @janrtvld to maintainers (#1016) Signed-off-by: Timo Glastra <[email protected]> * feat(routing): add settings to control back off strategy on mediator reconnection (#1017) Signed-off-by: Sergi Garreta <[email protected]> * fix: avoid crash when an unexpected message arrives (#1019) Signed-off-by: Pavel Zarecky <[email protected]> * chore(release): v0.2.4 (#1024) Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * style: fix some lint errors Signed-off-by: Ariel Gentile <[email protected]> * feat: use did:key flag (#1029) Signed-off-by: Ariel Gentile <[email protected]> * ci: set default rust version (#1036) Signed-off-by: Sai Ranjit Tummalapalli <[email protected]> * fix(oob): allow encoding in content type header (#1037) Signed-off-by: Timo Glastra <[email protected]> * feat: connection type (#994) Signed-off-by: KolbyRKunz <[email protected]> * chore(module-tenants): match package versions Signed-off-by: Ariel Gentile <[email protected]> * feat: improve sending error handling (#1045) Signed-off-by: Ariel Gentile <[email protected]> * feat: expose findAllByQuery method in modules and services (#1044) Signed-off-by: Jim Ezesinachi <[email protected]> * feat: possibility to set masterSecretId inside of WalletConfig (#1043) Signed-off-by: Andrii Uhryn <[email protected]> * fix(oob): set connection alias when creating invitation (#1047) Signed-off-by: Jakub Koci <[email protected]> * build: fix missing parameter Signed-off-by: Ariel Gentile <[email protected]> Signed-off-by: Pavel Zarecky <[email protected]> Signed-off-by: Ariel Gentile <[email protected]> Signed-off-by: conanoc <[email protected]> Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: Niall Shaw <[email protected]> Signed-off-by: Jakub Koci <[email protected]> Signed-off-by: Timo Glastra <[email protected]> Signed-off-by: Sergi Garreta <[email protected]> Signed-off-by: Sai Ranjit Tummalapalli <[email protected]> Signed-off-by: KolbyRKunz <[email protected]> Signed-off-by: Jim Ezesinachi <[email protected]> Signed-off-by: Andrii Uhryn <[email protected]> Co-authored-by: Iskander508 <[email protected]> Co-authored-by: conanoc <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Niall Shaw <[email protected]> Co-authored-by: jakubkoci <[email protected]> Co-authored-by: Timo Glastra <[email protected]> Co-authored-by: Sergi Garreta Serra <[email protected]> Co-authored-by: Sai Ranjit Tummalapalli <[email protected]> Co-authored-by: KolbyRKunz <[email protected]> Co-authored-by: Jim Ezesinachi <[email protected]> Co-authored-by: an-uhryn <[email protected]>
* feat: OOB public did (openwallet-foundation#930) Signed-off-by: Pavel Zarecky <[email protected]> * feat(routing): manual mediator pickup lifecycle management (openwallet-foundation#989) Signed-off-by: Ariel Gentile <[email protected]> * docs(demo): faber creates invitation (openwallet-foundation#995) Signed-off-by: conanoc <[email protected]> * chore(release): v0.2.3 (openwallet-foundation#999) Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * fix(question-answer): question answer protocol state/role check (openwallet-foundation#1001) Signed-off-by: Ariel Gentile <[email protected]> * feat: Action Menu protocol (Aries RFC 0509) implementation (openwallet-foundation#974) Signed-off-by: Ariel Gentile <[email protected]> * fix(ledger): remove poolConnected on pool close (openwallet-foundation#1011) Signed-off-by: Niall Shaw <[email protected]> * fix(ledger): check taa version instad of aml version (openwallet-foundation#1013) Signed-off-by: Jakub Koci <[email protected]> * chore: add @janrtvld to maintainers (openwallet-foundation#1016) Signed-off-by: Timo Glastra <[email protected]> * feat(routing): add settings to control back off strategy on mediator reconnection (openwallet-foundation#1017) Signed-off-by: Sergi Garreta <[email protected]> * fix: avoid crash when an unexpected message arrives (openwallet-foundation#1019) Signed-off-by: Pavel Zarecky <[email protected]> * chore(release): v0.2.4 (openwallet-foundation#1024) Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * style: fix some lint errors Signed-off-by: Ariel Gentile <[email protected]> * feat: use did:key flag (openwallet-foundation#1029) Signed-off-by: Ariel Gentile <[email protected]> * ci: set default rust version (openwallet-foundation#1036) Signed-off-by: Sai Ranjit Tummalapalli <[email protected]> * fix(oob): allow encoding in content type header (openwallet-foundation#1037) Signed-off-by: Timo Glastra <[email protected]> * feat: connection type (openwallet-foundation#994) Signed-off-by: KolbyRKunz <[email protected]> * chore(module-tenants): match package versions Signed-off-by: Ariel Gentile <[email protected]> * feat: improve sending error handling (openwallet-foundation#1045) Signed-off-by: Ariel Gentile <[email protected]> * feat: expose findAllByQuery method in modules and services (openwallet-foundation#1044) Signed-off-by: Jim Ezesinachi <[email protected]> * feat: possibility to set masterSecretId inside of WalletConfig (openwallet-foundation#1043) Signed-off-by: Andrii Uhryn <[email protected]> * fix(oob): set connection alias when creating invitation (openwallet-foundation#1047) Signed-off-by: Jakub Koci <[email protected]> * build: fix missing parameter Signed-off-by: Ariel Gentile <[email protected]> Signed-off-by: Pavel Zarecky <[email protected]> Signed-off-by: Ariel Gentile <[email protected]> Signed-off-by: conanoc <[email protected]> Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: Niall Shaw <[email protected]> Signed-off-by: Jakub Koci <[email protected]> Signed-off-by: Timo Glastra <[email protected]> Signed-off-by: Sergi Garreta <[email protected]> Signed-off-by: Sai Ranjit Tummalapalli <[email protected]> Signed-off-by: KolbyRKunz <[email protected]> Signed-off-by: Jim Ezesinachi <[email protected]> Signed-off-by: Andrii Uhryn <[email protected]> Co-authored-by: Iskander508 <[email protected]> Co-authored-by: conanoc <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Niall Shaw <[email protected]> Co-authored-by: jakubkoci <[email protected]> Co-authored-by: Timo Glastra <[email protected]> Co-authored-by: Sergi Garreta Serra <[email protected]> Co-authored-by: Sai Ranjit Tummalapalli <[email protected]> Co-authored-by: KolbyRKunz <[email protected]> Co-authored-by: Jim Ezesinachi <[email protected]> Co-authored-by: an-uhryn <[email protected]>
Signed-off-by: Pavel Zarecky [email protected]
First attempt to add support for receiving OOB invitations with public did.
Currently this is working together with the aca-py agent, when oob invitation is created using:
OutOfBandInvitation.services
to tackle the issues withString
coming from the transformer. Exposing only a gettergetServices
method to get simplified representation.MessageSender
into theDidResolverService
as it needs to be performed when sending the connection request as well as handling the connection responserecipientKey
lookup procedure had to be adjusted, to work together with aca-py. There's a strange Ed25519/X25519 key specification historical convention (https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html#did-document-notes)TODO:
didexchange
protocol