Allow sender to include additional message metadata to the mediator

[TimoGlastra]

Currently this patch is present in DIDComm Mediator Credo that allows a sender to include the message type in the forward message, enabling the mediator to send more informed push notification.

I think we should allow this behaviour by default in credo, and we should optionally extend the forward message definition in DIDComm / Aries RFCS to allow inclusion of such metadata. I think metadata about the type of the message can be useful, without exposing any potential PII, but this can be enabled by the sender based on the need for that specific use case

cc @sairanjit

[sairanjit]

@TimoGlastra This will be a great addition I will discuss this in the upcoming DIF DIDComm User Group meeting and share the updates here.

[TheTechmage]

Discussed in the APAC-EU DIDComm Users Group 2025-02-10. I will be bringing this up during the US DIDComm Users Group today where we generally have the Chair of the working group in attendance.

Thank you for bringing this to our attention!

[KimEbert42]

I would be somewhat concerned about sharing these in plaintext. Developers may accidentally send PII or leak information to the mediator or other agents that is undesirable. This may weaken the DIDComm protocol overall.

I would recommend setting up a separate set of keys to encrypt the message. The separate set of keys could be stored outside of the wallet, as it shouldn't protect PII, but would continue to help maintain the security of the messages being transmitted.

With the keys being stored outside of the wallet, the app could in the background decrypt the message without needing wallet access. This could then be displayed as notification to the user.

Steps

1. After connection is establish, a push notification encryption key could be configured over DIDComm

2. The encryption key would be stored outside of the wallet, or inside the wallet, but without needing the wallet to be decrypted to access the key.

3. The sending agent would then add the notificationMessage to the outbound DIDcomm message envelope, including each of the layered envelopes ( for mediators ). This would allow each layer to potentially send a push notification to the end user.

4. The mediator, or cloud agent, could then send the mobile agent the encrypted push notification.

5. The mobile agent receives the push notification

6. The app decrypts the message in the background, and displays a notification to the user.

[genaris]

What a nice discussion here! For some reason I haven't noticed this issue before today's meeting (now I understand why I was a bit lost 😄).

I'm reluctant on adding into Credo features that are not present in the specs, but I do understand that this is a common problem that is not easy to implement by using DIDComm routing protocols exactly as they are defined right now. I think the best way to add this flexibility (without going into advanced Push notification management on client side) would be to create a DIDComm extension that coordinates the way a new notification_metadata (or similar) field is created and interpreted by sender, mediator and recipient, encouraging security best practices as @KimEbert42 explained (e.g. establish a push notification key at connection completion or by using a protocol).

In Credo we can help the process of supporting such DIDComm extensions by adding the possibility of defining "outbound message middlewares" (not sure if that's the right naming) that can slightly modify certain (or all) outbound messages as required. For example, adding timing decorators, language preferences or this forward message metadata.

Of course, we will start testing this new Credo feature with the messageType used currently in didcomm-mediator-credo, which is the reason we started this great and productive discussion.