FDC3
FDC3 copied to clipboard
finos
FDC3 Identity & Threat Modelling -11 April 2024
Group overview
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
Relevant issue tags
https://github.com/finos/FDC3/labels/identity-security
Meeting Date
Thursday 11 April 2024 - 3pm GMT
Zoom info
- Join Zoom Meeting
- Meeting ID: 969 4029 4948
- Passcode: 636931
-
Dial-in:
Country International Dial-in Toll-free Dial-in US +1 929 205 6099 (New York) 877 853 5247 UK +44 330 088 5830 0800 031 5717 France +33 1 8699 5831 0 800 940 415 Find your local number https://zoom.us/u/ad2WVnBzb8
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 [email protected] 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 & discuss recap of the 4 core usecases (15mins)
- [ ] Discuss signing (trust) and encrypting (privacy) (25mins)
- [ ] AOB & Adjourn (5mins)
Minutes
Presentation of the use-cases indetified during the last session: https://github.com/finos/FDC3/issues/1172
Discussion around the two main tools we can use:
- Signing enables trust
- Encryption enables privacy
Signing could be done by passing a signature in a standard part of each Context.
In order not to require changes in existing desktop agents, encryption could be deployed by using private channels:
sequenceDiagram
participant AppA
participant AppB
Note left of AppA: Generate random symmetric key K
Note left of AppA: Encrypt K with AppB public key
Note left of AppA: Create EncryptedChannelRequest Context, containing encrypted key, sign it with AppA private key
AppA->>AppB: Send Encrypted Channel Request Intent
Note right of AppB: Verify signature with AppA public key
Note right of AppB: Decrypt and store K using AppB private key
Note right of AppB: Create Private Channel with AppA and AppB
AppB->>AppA: Return private channel handler
AppA->>AppB: Encrypt all traffic on private channel with symmetric key K
AppB->>AppA: Encrypt all traffic on private channel with symmetric key K
this will not add more complexity to existing FDC3 implementations, nor require changes to existing DAs, whilst allowing two apps to set up trusted and secure communications
Both signing and encryption require apps to be able to verify signatures / retrieve public keys for other apps. In the next session we will discuss the best way to manage this (app directory? rolled into each app? combination of both?)
Regarding the diagram above:
The way to get hold of a PrivateChannel I think is limited to just raising an intent with an IntentResult that contains the private channel.
So, what you're saying is, when you raise the intent, the Context you send has to be this special type fdc3.encryptedChannelRequest?
The only fly in this ointment is that it reduced the expressivity of the raise, since you can't (say) raise "ViewNews" with an fdc3.instrument anymore.
Is there a way around that?
The only fly in this ointment is that it reduced the expressivity of the raise, since you can't (say) raise "ViewNews" with an fdc3.instrument anymore.
Is there a way around that?
Yes, that request context can wrap another, which could be any type of context. See fdc3.transactionResult for an example of an existing context that does that: https://fdc3.finos.org/docs/context/ref/TransactionResult