Communicating Securely with signed and encrypted contexts

[Yannick-Malins]

Enhancement Request

Use Case:

Problem Statement

Certain applications or firms require additional protection against data leakage, so want to be able to control which apps they share information with - so they need to confirm the identity of counterparty applications and use this to permit sharing with them.

Even something as simple as a trader performing a research query could be considered proprietary information, since the interest in a certain topic or security could in of itself be an indication of internal strategy.

These parties might not even trust the Desktop Agent to relay confidential communications - an application running in an FDC3 context has no proof of whether the desktop agent exposing that context is reliable or trusted. Therefore any solution should require no trust in the agent

FDC3 being based on the idea of open and agnostic context sharing, with a Desktop Agent in the middle routing in-clear messages, this level of control is not possible using a standard implementation today.

@Yannick-Malins insert usecases A-D here

Proposed Solution

To provide this level of control we need to introduce three notions to the standard:

• Signed Contexts (I have proof that a context was sent by a specific party)
• Encrypted Channels (I have proof that only certain parties can read the contexts I emit)
• A means of performing the discovery of applications supporting encryption as well as establishing an encrypted channel with one or more of these applications, with appropriate key exchange

These concepts, used in conjunction with Private Channels, allow two or more applications to share information with strict guarantees that no other parties, including the Desktop Agent itself, can read it.

@Yannick-Malins insert sequence diagrams for usecases A-D here

https://github.com/finos-labs/fdc3-security/blob/main/README.md

Proposed Changes to the Standard

• new optional field to end of context: Signature
• new context: EncryptedContextWrapper
• new optional field to appD entry: jwks (@Yannick-Malins find official name) endpoint
• contexts/intents for establishing encrypted channel
• documentation: discovery (find intent of certain types that return encrypted contexts)
• documentation: flow

Open Questions

• Should encrypted context contain wrapped type?
• Establish encryption on the channel: any simplification of the flow possible?