Description
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.
Use Case A: “Look up public information”
Persona: Buy-side investor
From: In-house platform
To: Market data app
Flow: From within their in-house platform, the user requests the latest news items concerning a public company, using a context broadcast or a direct intent
Risks: There is no proprietary information sent, however the fact that the investor is looking at this information is in itself confidential
Use Case B: “Look up internal information”
Persona: Buy-side investor
From Market data app
To: In-house platform
Flow: Whilst browsing public information, an investor wants to check the current firm position on a security
Risks: Again, no proprietary information is sent over FDC3 (only a request to display whatever internal information may or may not exist). But again, the fact that the investor wants to look at this information is in itself confidential
Use Case C: “Request pre-trade information”
Persona: Buy-side trader
From: In-house platform
To: Multiple Single-dealer platforms
Flow: Buy-side trader requests margin requirements on an instrument from multiple sell-side platforms. Information is sent back through intent replies
Risks: From the buy-side perspective, they expect the same level of confidentiality as cases A/B - none of their data is shared, but the fact that they want to see this data is in of itself confidential. From the sell-side perspective they cannot risk this information leaking to anyone except the buy who requested it.
Use Case D: CRUD with sensitive information
Persona: Analyst
From: In-house platform
To: CRM
Flow: Log a client call
Risks: Similar to use-case B, but with two differences: sensitive information is transmitted over FDC3, and this is a “write” operation, not read
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.
Signed Contexts - To prove authorship of a message without relying on desktop agent
sequenceDiagram
participant AppA
participant AppASecurityLayer
participant DesktopAgent
participant AppBSecurityLayer
participant AppBIntentHandler
AppA->>AppASecurityLayer: View Orders Intent containing Contact Context
note right of AppASecurityLayer: Sign Context with AppA private key
AppASecurityLayer->>DesktopAgent: Send Intent with Signed Context
DesktopAgent->>AppBSecurityLayer: Deliver Intent
note right of AppBSecurityLayer: Verify signature with AppA public key
AppBSecurityLayer->>AppBIntentHandler: Deliver Intent with Contact Context and AppA metadata
Encrypted Channels - To communicate securely between apps with no trust in the desktop agent
sequenceDiagram
participant AppA
participant AppB
AppA->>AppB: View Orders Intent
note right of AppB: Generate random symmetric key K
note right of AppB: Create private channel C
AppB->>AppA: Intent Reply: Private Channel C
note left of AppA: Subscribe to Channel C
note right of AppB: I have a new order!
note right of AppB: Encrypt Order Context with K and sign it with AppB private key
AppB->>AppA: Broadcast Encrypted Context
note left of AppA: Context is encrypted!
note left of AppA: Verify signature of context with AppB public key
note left of AppA: Signature valid, I need the channel key
AppA->>AppB: Key Request Intent for Channel C
note right of AppB: Wrap K with AppA public key
AppB->>AppA: K wrapped in AppA public key
note left of AppA: Unwrap with AppA private key
note left of AppA: I now have K, I can decrypt encrypted contexts on this channel :)
note left of AppA: Decrypt encrypted context with K
note right of AppB: I have a new order!
note right of AppB: Encrypt Order Context with K and sign it with AppB private key
AppB->>AppA: Broadcast Encrypted Context
note left of AppA: Context is encrypted!
note left of AppA: Verify signature of context with AppB public key
note left of AppA: Decrypt encrypted context with K
Application Directory
Optional JWKS endpoint URL (e.g. https://loginservice.symphony.com/login/idm/keys ) on each app
Proposed Changes to the Standard
- new optional field to end of context: Signature
- new context: EncryptedContextWrapper
- new optional field to appD entry: jwks 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?