Skip to content
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

Merged
merged 19 commits into from
Aug 29, 2022

Conversation

Iskander508
Copy link
Contributor

@Iskander508 Iskander508 commented Jul 5, 2022

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:

POST /out-of-band/create-invitation
{
  "handshake_protocols": [
    "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0"
  ],
  "use_public_did": true,
  ...
}
  • refactored OutOfBandInvitation.services to tackle the issues with String coming from the transformer. Exposing only a getter getServices method to get simplified representation.
  • resolving public DID services procedure moved from the MessageSender into the DidResolverService as it needs to be performed when sending the connection request as well as handling the connection response
    • We should maybe think about some caching to not run the resolution multiple times
  • The service recipientKey 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:

  • check OOB invitation with didexchange protocol
  • fix tests

@TimoGlastra
Copy link
Contributor

@TheTreek @JamesKEbert Please take a look at this PR

Copy link
Contributor

@TimoGlastra TimoGlastra left a 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.

packages/core/src/agent/MessageSender.ts Show resolved Hide resolved
Comment on lines 70 to 77
const invitationRecipientKeys = outOfBandRecord
.getTags()
.recipientKeyFingerprints.map((fingerprint) => Key.fromFingerprint(fingerprint))
Copy link
Contributor

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).

Copy link
Contributor Author

@Iskander508 Iskander508 Jul 16, 2022

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:

  1. 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)
  2. 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?

Copy link
Contributor

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> {

Copy link
Contributor Author

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.

Copy link
Contributor Author

@Iskander508 Iskander508 Jul 19, 2022

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/oob/OutOfBandModule.ts Outdated Show resolved Hide resolved
packages/core/src/modules/oob/OutOfBandModule.ts Outdated Show resolved Hide resolved
packages/core/src/modules/oob/OutOfBandModule.ts Outdated Show resolved Hide resolved
packages/core/tests/oob.test.ts Outdated Show resolved Hide resolved
Pavel Zarecky added 2 commits July 16, 2022 16:11
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
@codecov-commenter
Copy link

codecov-commenter commented Jul 16, 2022

Codecov Report

Merging #930 (54ab182) into main (f90a27b) will decrease coverage by 0.04%.
The diff coverage is 86.71%.

@@            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     
Impacted Files Coverage Δ
packages/core/src/agent/helpers.ts 100.00% <ø> (ø)
...es/core/src/decorators/service/ServiceDecorator.ts 100.00% <ø> (ø)
.../connections/handlers/ConnectionResponseHandler.ts 82.35% <ø> (ø)
...c/modules/dids/domain/createPeerDidFromServices.ts 96.55% <ø> (ø)
packages/core/src/types.ts 100.00% <ø> (ø)
packages/core/src/utils/validators.ts 44.44% <0.00%> (ø)
packages/core/src/modules/oob/OutOfBandModule.ts 85.17% <67.56%> (-2.52%) ⬇️
...re/src/modules/oob/messages/OutOfBandInvitation.ts 93.82% <80.00%> (-2.43%) ⬇️
packages/core/src/agent/MessageSender.ts 85.88% <84.61%> (-1.49%) ⬇️
...ore/src/modules/connections/DidExchangeProtocol.ts 87.26% <100.00%> (-0.06%) ⬇️
... and 8 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Pavel Zarecky added 2 commits July 16, 2022 18:14
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
Copy link
Contributor

@TimoGlastra TimoGlastra left a 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

packages/core/src/agent/MessageSender.ts Show resolved Hide resolved
Comment on lines 70 to 77
const invitationRecipientKeys = outOfBandRecord
.getTags()
.recipientKeyFingerprints.map((fingerprint) => Key.fromFingerprint(fingerprint))
Copy link
Contributor

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> {

packages/core/src/modules/oob/OutOfBandModule.ts Outdated Show resolved Hide resolved
Comment on lines 102 to 107
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)
}
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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

Copy link
Contributor Author

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:

  1. 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)
  2. 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)
  3. 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)

Copy link
Contributor

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:

  1. 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) )
  2. 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?)
  3. You're right we only have to deal with inline services here. Maybe we can copy the implementation directly to the migration file.

Copy link
Contributor Author

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

packages/core/tests/oob.test.ts Outdated Show resolved Hide resolved
packages/core/tests/oob.test.ts Outdated Show resolved Hide resolved
packages/core/tests/oob.test.ts Outdated Show resolved Hide resolved
packages/core/tests/oob.test.ts Outdated Show resolved Hide resolved
@TheTreek
Copy link
Contributor

@TheTreek @JamesKEbert Please take a look at this PR

All of this looks really good to me.

Pavel Zarecky added 2 commits July 19, 2022 15:47
@Iskander508 Iskander508 marked this pull request as ready for review July 19, 2022 14:12
@Iskander508 Iskander508 requested a review from a team as a code owner July 19, 2022 14:12
@Iskander508
Copy link
Contributor Author

Iskander508 commented Jul 19, 2022

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

I plan to take a look at the tests to increase coverage of the new cases. (EDIT: some additional unit-tests added)
I don't think there are any breaking changes in the API, unless we count the changes in the tags.

Pavel Zarecky added 2 commits July 19, 2022 16:47
Signed-off-by: Pavel Zarecky <[email protected]>
Signed-off-by: Pavel Zarecky <[email protected]>
Comment on lines 369 to 380
// 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)
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Comment on lines 290 to 293
const invitationRecipientKeys = outOfBandRecord
.getTags()
.recipientKeyFingerprints.map((fingerprint) => Key.fromFingerprint(fingerprint))
const invitationKey = invitationRecipientKeys[0]?.publicKeyBase58
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reverted

Comment on lines 50 to 64
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
Copy link
Contributor

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 the keyAgreement 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"

Copy link
Contributor Author

@Iskander508 Iskander508 Jul 21, 2022

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

@Iskander508 Iskander508 requested a review from TimoGlastra July 30, 2022 14:12
Copy link
Contributor

@TimoGlastra TimoGlastra left a 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> {
Copy link
Contributor

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?

Suggested change
public getTags(): Tags<DefaultOutOfBandRecordTags, CustomOutOfBandRecordTags> {
public getTags() {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

explicit types removed

Comment on lines 63 to 69
this._tags = props.tags ?? {
recipientKeyFingerprints: props.outOfBandInvitation
.getInlineServices()
.map((s) => s.recipientKeys)
.reduce((acc, curr) => [...acc, ...curr], [])
.map((didKey) => DidKey.fromDid(didKey).key.fingerprint),
}
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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

Copy link
Contributor Author

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.

@Iskander508
Copy link
Contributor Author

What is the status of the did exchange intergration. Is that something we want to add in a separate PR?

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.

@sonarqubecloud
Copy link

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 7 Code Smells

No Coverage information No Coverage information
18.2% 18.2% Duplication

@JamesKEbert
Copy link
Contributor

@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.

@swcurran
Copy link
Contributor

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.

@TimoGlastra
Copy link
Contributor

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?

Is the version mismatch causing issues? AFJ should just allow the different version, as should ACA-Py.

@TimoGlastra
Copy link
Contributor

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.

Fair point. Let's merge this and add support for public dids in didexchange later on

Copy link
Contributor

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@JamesKEbert
Copy link
Contributor

Can you characterize the 1.0/1.1 issue? Which library is doing what?

Yeah, here's my best understanding of the issue @swcurran, as described in RFC 0003.

According to my testing--the behavior is:

  • That AFJ is able to process an OOB 1.0 invitation
    • We may want to send a warning problem report version-with-degraded-features).
    • We also could have responded with a version-not-supported problem report if the mismatch was critical (not so in this case)
  • We then use connections v1, which is support as expected within AFJ & ACA-Py.
  • Upon processing an OOB 1.0 invitation that we already have a corresponding connection for, AFJ attempts to perform a handshake reuse using an OOB 1.1 handshake-reuse.
  • ACA-Py receives this and throws an error due to not being OOB 1.0. We would expect that ACA-Py would either need to:
    • Respond with an OOB 1.1 handshake-reuse-accepted message (if implemented in ACA-Py)
    • Respond with a warning problem report fields-ignored-due-to-version-mismatch and respond with an OOB handshake-reuse-accepted message (although it's not clear to me in the 0003 RFC whether this should be a 1.0 or 1.1).

Here are the error logs from ACA-Py when performing connection reuse with the OOB minor version mismatch:

demo-agent-alice-1   | 2022-08-26 19:43:46,429 indy.crypto DEBUG unpack_message: <<< res: b'{"message":"{\\"@type\\":\\"https://didcomm.org/out-of-band/1.1/handshake-reuse\\",\\"@id\\":\\"e95b89c6-6fdc-45f0-bb8b-9c4c3117f76d\\",\\"~thread\\":{\\"thid\\":\\"e95b89c6-6fdc-45f0-bb8b-9c4c3117f76d\\",\\"pthid\\":\\"6cca1b0b-4f00-436b-8550-a18d382365d8\\"}}","recipient_verkey":"9KDHrCvstES8ia4hUL4tinX6r61qWDN74v9wu8PreHMH","sender_verkey":"2sZHisiyu4SzTyzih9ziJKcRdxE37otXnj918jGx9Cp3"}'
demo-agent-alice-1   | 2022-08-26 19:43:46,429 aries_cloudagent.transport.pack_format DEBUG Expanded message: {'@type': 'https://didcomm.org/out-of-band/1.1/handshake-reuse', '@id': 'e95b89c6-6fdc-45f0-bb8b-9c4c3117f76d', '~thread': {'thid': 'e95b89c6-6fdc-45f0-bb8b-9c4c3117f76d', 'pthid': '6cca1b0b-4f00-436b-8550-a18d382365d8'}}
demo-agent-alice-1   | 2022-08-26 19:43:46,430 aiohttp.access INFO 172.19.0.3 [26/Aug/2022:19:43:46 +0000] "POST / HTTP/1.1" 200 174 "-" "okhttp/3.12.12"
demo-agent-alice-1   | 2022-08-26 19:43:46,430 aries_cloudagent.core.conductor ERROR Exception in message handler:
demo-agent-alice-1   | Traceback (most recent call last):
demo-agent-alice-1   |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/core/dispatcher.py", line 142, in handle_message
demo-agent-alice-1   |     message = await self.make_message(inbound_message.payload)
demo-agent-alice-1   |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/core/dispatcher.py", line 234, in make_message
demo-agent-alice-1   |     message_cls = registry.resolve_message_class(message_type)
demo-agent-alice-1   |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/core/protocol_registry.py", line 170, in resolve_message_class
demo-agent-alice-1   |     return ClassLoader.load_class(msg_cls)
demo-agent-alice-1   |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/utils/classloader.py", line 97, in load_class
demo-agent-alice-1   |     if "." in class_name:
demo-agent-alice-1   | TypeError: argument of type 'NoneType' is not iterable
demo-agent-alice-1   | 2022-08-26 19:43:46,433 aries_cloudagent.core.conductor ERROR DON'T shutdown on TypeError argument of type 'NoneType' is not iterable
demo-agent-alice-1   | 2022-08-26 19:43:46,434 aries_cloudagent.core.dispatcher ERROR Handler error: Dispatcher.handle_message
demo-agent-alice-1   | Traceback (most recent call last):
demo-agent-alice-1   |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/core/dispatcher.py", line 142, in handle_message
demo-agent-alice-1   |     message = await self.make_message(inbound_message.payload)
demo-agent-alice-1   |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/core/dispatcher.py", line 234, in make_message
demo-agent-alice-1   |     message_cls = registry.resolve_message_class(message_type)
demo-agent-alice-1   |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/core/protocol_registry.py", line 170, in resolve_message_class
demo-agent-alice-1   |     return ClassLoader.load_class(msg_cls)
demo-agent-alice-1   |   File "/home/indy/.venv/lib/python3.6/site-packages/aries_cloudagent/utils/classloader.py", line 97, in load_class
demo-agent-alice-1   |     if "." in class_name:
demo-agent-alice-1   | TypeError: argument of type 'NoneType' is not iterable

@swcurran
Copy link
Contributor

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.

@JamesKEbert
Copy link
Contributor

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, message types received with a minor version at or higher than the minimum supported and less than the current minor version are processed (AFJ's minimum version is 0 and our current version being 1), and that's followed by:
ideally with a response using the same minor version of the received message, which would indicate yes, we should be responding with a 1.0 in AFJ.

However, I would expect that ACA-Py should support OOB 1.1, but perhaps not.

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)

@swcurran
Copy link
Contributor

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. 😞

@TimoGlastra
Copy link
Contributor

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 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

@TimoGlastra TimoGlastra merged commit c99f3c9 into openwallet-foundation:main Aug 29, 2022
@TimoGlastra
Copy link
Contributor

Wohoo! Thanks for this great contribution @Iskander508!! Let's try to get a new release out this week

@Iskander508 Iskander508 deleted the oob_public_did branch August 29, 2022 20:03
genaris added a commit to 2060-io/aries-framework-javascript that referenced this pull request Sep 2, 2022
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]>
genaris pushed a commit to 2060-io/aries-framework-javascript that referenced this pull request Sep 16, 2022
TimoGlastra added a commit that referenced this pull request Oct 11, 2022
* 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]>
genaris added a commit to 2060-io/aries-framework-javascript that referenced this pull request Oct 13, 2022
* 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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants