FDC3 Identity & Threat Modelling - 8 Feb 2024

Yannick-Malins commented 7 months ago

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 8 Feb 2024 - 11am (US eastern timezone EDT/EST) / 4pm (London, GMT/BST)

Zoom info

Join Zoom Meeting
Meeting ID: 969 4029 4948
Passcode: 636931

Dial-in:	Country	International 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 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 (30mn)

[ ] Convene & roll call, review meeting notices (5mins)
[ ] Discuss recruiting additional firms to participate (20mins)
[ ] AOB & Adjourn (5mins)

Minutes

Summary Attendance and Introductions Community code of conduct

The discussion revolved around limitations in the current FDC 3 standard when it comes to higher trust operations such as sending orders between applications. The need for greater trust levels within applications was emphasised by various speakers.

We kicked off the conversation with the question of trust levels for applications receiving data, involving considerations about authenticating sender identity and ensuring data integrity. The role of different entities like users, applications themselves, application directories, and desktop agents in establishing trust was discussed at length.

The group discussed recommendations regarding high-trust activities within applications using FDC3 standard. It was suggested that sensitive actions should always require manual user confirmation before execution within an application.

There is also the question of authorisation within the context of implementing actions and making decisions. It would enable varying levels of activity, such as filling out a form or directly executing an action, each requiring different levels of trust. Of course this requires identity verification. The conversation delved into authentication versus authorisation and how applications determine authorisation rules based on permissions roles assigned to identities.

The next point was encryption. We discussed encryption methods for sending information between applications via FDC3, emphasising concerns about data security and potential vulnerabilities when sharing information across applications. We explored scenarios involving intent-based communication as well as channels, seeing how asymmetric encryption schemes could guarantee confidentiality

There was an exploration into potential challenges associated with web-based desktop agents operating within the FDC3 framework. Concerns were raised regarding security controls for interactions with desktop agents on web platforms, particularly in scenarios where third-party vendors are involved or when users engage with suspect agents through URLs.

One interesting point raised is that although user identity may be needed for securing actions, it could also exposing this to malicious applications

Regarding trust of the desktop agent, the general consensus was that not trusting the agent means pushing that need for trust to yet another service, unless heavier techniques are used (full encryption/decryption of payloads, with signed acks etc). We then segued onto using encryption keys inaccessible to the agent, using tokenisation for sensitive information like payment details, distributing keys securely when removing agents from certain processes, adopting web authentication capabilities for end-to-end security measures etc..

In any case, we all agree that we need to focus on concrete problems that need solving before selecting specific solutions. Hence the action items for all industry participants requesting concrete examples that require trust levels between applications, so that we can debate the various solutions together

This will then allow us to find the correct balance between security and implementation simplicity, publishing the use-cases and proposed solutions as a form of documentation