Identity & Security Working group - 10 April 2025

[robmoffat]

---

name: 🤝 Identity & Security Working group about: Organisation for and reporting from a discussion group intended to inform the Standards Working Group

Group overview

Summary of the purpose and scope of the group

Relevant issue tags

If tags have been applied to relevant issues, provide details here.

Meeting Date

Thursday DD MMM yyyy - 10am (US eastern timezone EDT/EST) / 3pm (London, GMT/BST)

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.

Participation Requirements

Note: Meeting participants are expected to accept the terms of the FDC3 license (Community Specification License), understand the governance process and have a CLA in place.

Please click the following links at the start of the meeting if you have not done so previously.

• View the CSL
• View the GOVERNANCE of the Project
• Click here to start a PR.
  • Edit the page to add your details.
  • Hit the save button.
  • Click "Create Pull Request".
  • Click "Accept" on the EasyCLA dialog in the PR's discussion section.
• Click here to send email to become a voting participant on the FDC3 Project

Tracking Attendance

Note: Meeting participants are expected to add a comment to this GitHub issue in order that we can track attendance of FDC3 project meetings. Please do this at the start of the meeting.

Agenda

• [x] Convene & roll call, review meeting notices (5mins)
• [x] Review action items from previous meeting (5mins)
• [ ] FDC3 Security Metadata Discussion
• [ ] Update on Use Cases from Strategy Session
• [ ] AOB & Adjourn (5mins)

Minutes

• ...

Action Items

• [ ] ...

Untracked attendees

Full name	Affiliation	GitHub username

[novavi]

Derek Novavi / S&P Global

[paulgoldsmith]

Paul Goldsmith / Morgan Stanley

[awaiken]

Andrew Aitken - FINOS TOC Liaison

[hughtroeger]

Hugh Troeger / FactSet

[julianna-ciq]

Julianna Langston / interop.io

[robmoffat]

Review of Actions (from last month)

• PG to get someone in for this - whether a firm like MS could use an IDP for any operations.
• RM + KW: Someone to write up a multi-party use case

One thing I asked a couple of years ago is - how can we do this better than Symphony just setting themselves up as the de-facto IDP provider? We need to explore the use cases that make sense to solve in FDC3. Passing identities is one. Multiple apps using one IDP, might be good value.

• Can we do better than an OAuth + IDP / or Selection of IDPs.

Decisions

1. Build on top of #1290. So this is part of the critical path for S&I.
2. Provide a fallback for older desktop agents to support encryption
3. Keep as a decorator. Other Java/.Net implementations of the decorator may be written (or apps could provide their own implementation).
4. We might change the schema for context to allow __encrypted: { } and not change type of message.
5. API call (?) To add a decryption handler for contexts.

Implementation

1. KW - look at metadata types.
2. KW - Changes to DACP.
3. JL - further work on #1290
4. RM - Work on security libraries to work with #1290, add to monorepo.

[kriswest]

Kris West / NatWest 🚀

[kemerava]

Elizabeth Kemerava / BlackRock