FDC3 revolves around several types of independent entities:
Applications
Desktop Agents
App Directories
Users
Each of these has an identity, and needs to know and trust the identities of several of the others in order to work seamlessly.However, at present there are few or no methods for them to validate those identities within the FDC3 Standard, meaning trust must be assumed. This comes with problems and risks : data loss, identity theft, oauth hell, or an inability to adopt interop via FDC3 - all of which are a threat to the FDC3 ecosystem’s continued growth. This complexity is multiplied by the different types of FDC3 setups now possible - desktop app interop, in-container interop, web interop, and interop between Desktop Agents (Bridging).
Over the past few years, various discussions, demos and roundtables have addressed this topic, but the outcome each time has been “what do our users need?”.
Therefore our first objective in this stream is to dig into what these risks and problems are, before we discuss and work on potential solutions
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard.
Agenda (50mn)
[ ] Convene & roll call, review meeting notices (5mins)
[ ] Present Rob's implementation proof of concept (15mins)
[ ] Discuss flow diagrams and how they relate to the core usecases (25mins)
Presentation of the flow diagrams corresponding to the demo implementation:
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
TBD: App Security Layer can be backend for max security, or leveraging browser APIs (but then trusting browser)
Note: in next diagram, App security layer and desktop agent are not shown for simplicity
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
Topic for next session: Ensure this can be done with minimal to no impact on existing desktop agents
Group overview
FDC3 revolves around several types of independent entities:
Each of these has an identity, and needs to know and trust the identities of several of the others in order to work seamlessly.However, at present there are few or no methods for them to validate those identities within the FDC3 Standard, meaning trust must be assumed. This comes with problems and risks : data loss, identity theft, oauth hell, or an inability to adopt interop via FDC3 - all of which are a threat to the FDC3 ecosystem’s continued growth. This complexity is multiplied by the different types of FDC3 setups now possible - desktop app interop, in-container interop, web interop, and interop between Desktop Agents (Bridging).
Over the past few years, various discussions, demos and roundtables have addressed this topic, but the outcome each time has been “what do our users need?”.
Therefore our first objective in this stream is to dig into what these risks and problems are, before we discuss and work on potential solutions
Relevant issue tags
https://github.com/finos/FDC3/labels/identity-security
Meeting Date
Thursday 13 June 2024 - 3pm GMT
Zoom info
Meeting notices
FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard.
Agenda (50mn)
Minutes
Demo of Rob's proof of concept implementation https://github.com/finos-labs/fdc3-for-the-web/tree/security-proxy-2
Presentation of the flow diagrams corresponding to the demo implementation:
TBD: App Security Layer can be backend for max security, or leveraging browser APIs (but then trusting browser)
Note: in next diagram, App security layer and desktop agent are not shown for simplicity
Topic for next session: Ensure this can be done with minimal to no impact on existing desktop agents