-
Notifications
You must be signed in to change notification settings - Fork 204
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
Add support for RFC 0434: Out-of-Band #344
Comments
I wrote down a few notes I would like to share with you here. Inbound Message processing rules
Implementation IdeasI started with an idea to create a separate OOB module which would create and process OOB messages. The problem is that I needed to copy-paste a lot of code from MessageReceiver
OOB
Currently, we assume there are three types of messages. The connection invitation which we pass to agent.connections.receiveInvitation(invitation: InvitationJsonMessage)
agent.receiveMessage(message: PackedMessage | DecoratedJsonMessage) To me, it makes sense to have just one method which would accept all agent.receiveMessage(message: OobMessage | PackedMessage | JsonMessage) The problem is that I suggest to implement OOB as part of connections.receiveOobInvitation(message: OobMessage)
connections.receiveInvitation(message: OobMessage | InvitationJsonMessage)
connections.createOobInvitation(...)
oob.receiveMessage(OobMessage)
messageReceive.receiveMessage(PackedMessage | JsonMessage+service) This allows us gradual update according to Aries RFC 0496: Transition to the Out of Band and DID Exchange Protocols, create a new connection, call |
I found a problem with processing the connection request when the connection already exists. The OOB spec says: “if a connection they have was created from an out-of-band invitation from the same services DID of a new invitation message, the connection MAY be reused. The receiver may choose to not reuse the existing connection for privacy purposes and repeat a handshake protocol to receive a redundant connection.” Let’s say that a connection request is sent from Bob (invitee) to Alice (inviter), encrypted with Alice’s key (recipientKey), signed by Bob’s key (senderKey). Current implementation finds a connection based on Alice’s key (recipientKey) and because Bob is trying to make a new connection (by sending packed Connection Request message) with a different key (senderKey), it fails with the following error:
I guess we should not throw an error and pass the message forward. If the new connection is successfully made, the previous connection became stale. I’m not sure how to handle that. I tried to change the logic in if (senderKey && recipientKey) {
connection = await this.connectionService.findByTheirKey(senderKey)
} But there are failing mediation tests with that. I’m digging into it and trying to understand what’s the problem, but I just wanted to share it with you here if you have any ideas. |
I'm not following you 100%. When alice receives the request the connection doesn't have |
Yeah, sorry I didn't explain it well. I try it again :) Let’s say that there is an existing connection between Alice (A.pk1, B.pk1) and Bob (B.pk1, A.pk1).
|
Aha, if I remove the condition |
I understand now. Let's talk about it during the WG call. There are some things to consider here, but I think we could loosen the restriction a bit and allow it to pass through as you said. I think this is related to the work we will need to do for connections using public dids, as it would also create the scenario where the same key is used for multiple connections. Difference is that we would still like to create a new key for each interaction, we just associate it with the public did. If we loosen the restrictions, it will work something like: Alice receives a connection request. We look at the We could still check then if the request is valid based on the following checks (in the connection response handler):
In general protocol implementation themselves check whether a connection is attached and whether that connection is complete. This can be easily done using |
As a practical note. We can remove the check, but need to modify the connection assignment a few lines above to only be assigned to the upper scope So something like this: let connection: ConnectionRecord | null = null
// Only fetch connection if recipientKey and senderKey are present (AuthCrypt)
if (senderKey && recipientKey) {
connection = await this.connectionService.findByQuery({ verkey: recipientKey, theirKey: senderKey })
} |
Spec: https://github.com/hyperledger/aries-rfcs/blob/b3a3942ef052039e73cd23d847f42947f8287da2/features/0434-outofband/README.md
The text was updated successfully, but these errors were encountered: