Dive into a broad update on FDC3 aimed at a less technical audience with a video of the recent General Meeting held on May 7th, 2024 or check out the transcript. Led by Kris West, this meeting provided a comprehensive overview of the latest developments, announcements, and ongoing initiatives within the FDC3 community.
Recap
The FDC3 general meeting on May 7th, 2024, chaired by Kris West, provided a comprehensive update on the consortium's recent activities and developments. Attendees were briefed on the release of the finalized FDC3 2.1.0 NPM module and the introduction of a .NET binding, enhancing accessibility across different platforms. Additionally, a revamped FDC3 website was unveiled, showcasing training courses and certification programs aimed at both developers and business stakeholders. Updates from various discussion groups highlighted ongoing initiatives, including efforts to improve identity and threat modeling and facilitate desktop agent bridging. The meeting concluded with a call for community contributions to further advance FDC3's interoperability standards and initiatives.
TRANSCRIPT
Kris West: [00:00:00] So hello everybody and welcome to the FDC3 general meeting on this the 7th of May 2024. Today's meeting is a summary of activity going on in FDC3 over the last, usually the last quarter. We didn't have a general meeting in February so we're covering about the last six months of what's been going on in FDC3 and what's coming up next.
Here are the standard FINOS meeting notices, which I will skip reading today, but please do have a look. One thing to note is that today's is a recorded meeting, but we'll have an unrecorded Q&A session at the end. So please do hold your questions till the end of the session, and we'll make some time for them.
And if you're attending in person today, please head on over to the agenda on issue 1205 and just add your name and affiliation to help track attendance.
Okay in [00:01:00] today's meeting, we'll be covering a number of announcements and reminders of resources that are available to you. We will cover updates on current activities in the FDC3 discussion groups and standards working group meeting, a bit more info on how to get involved. And then we will move on to a Q& A section which will not be recorded.
So to kick us off with the announcements first, the FDC3 2.1.0 NPM module has finally been released. If you've been following What we've been doing you will note there are various beta versions of the module that have been coming out over the past few months as we've merged things and made various changes.
We have the final module released now, which means you have access to all the 2. 1 intents and contacts, including a number of transactional intents. things that intended to be CRUD operations or to have result types. There's a lot more in the chat intents and contexts that we're planning to add in.
We also added some [00:02:00] experimental order trade and product context types to start those off. We are expecting feedback on those. And as they're experimental, you can expect there to be some changes, potentially breaking changes to them in future releases as we flesh them out. Further, we've also made some changes to give you some inline documentation of the context objects and their properties as you use them.
So developers in standard ID, IDEs like VS code with its IntelliSense will now tell you about the context types as you develop with them, we also include the for those implementing bridging, both in a, in a desktop agent or a bridge we have IntelliSense for a number of different things principally Intents and context types so different from the documentation I mentioned before but rather intent IntelliSense on the type names to help people auto complete those as well as some util functions to help you work out if you're working with the standard type or not [00:03:00] and finally the module was reworked with a new build system thanks to a contribution from Juliana Langston which got us away from TSC, which is a now unmaintained tool for building boilerplate.
TypeScript projects that was used to generate the module, the first build system for the module. So that's got us updated. It means we now have no vulnerable dependencies used to build the module. Although it should be noted that past module versions are still secure. The vulnerabilities were largely at development time, but it is important to get a clean audit of an MPM module.
To make it easy for people to adopt and use so do have at it Go and have a go at the 2. 1 module up on npm We have also released through a lot of work hard work by FDC3 mainnet maintainer brian ingenito a dot net binding for FDC3 so this has [00:04:00] been voted in by the board By the standards working group as the standard binding for.
net for FDC3. So it's a translation. of the API and context objects concrete types for intents, etc. Over there that's released its first stable version for FDC3 2. 0 up on NuGet. So you'll find it's got all of the API functionality there as 2. 1. It didn't vary that over 2. 0. The next step for them is to include all the types that were created in 2.
1 for new intents and contexts. The .net standard 2. 0 package consists of core interfaces and utility helper classes intended to help you implement your own .net desktop agent. I know a couple of significant vendors in the space have already adopted these types for their own. Desktop agents have been working with them from the Morgan Stanley package for some time, but [00:05:00] it should also help you leverage FDC3 from your dot net applications in a somewhat more standard way.
Being able to work with wealth wage and implementations is a bit more difficult in dot net than it is in, for example, JavaScript, where we often inject the API. But this should help make it more standard and easier to use as well as providing a whole load of utilities and concrete context objects to make your code easier to write in the applications.
Contributions to that project from all things from reviewing to actual work on the code base. Are very welcome and you can go and check it out over on the finos FDC3 hyphen.net repository or the package itself up on Newgate. We also through a lot of hard work from our colleagues at Finos and specifically from Rob, have a new look to the FDC3 website which is intended to help us market [00:06:00] FDC3 more efficiently.
Describe its use cases, et cetera, and some of the other activity that we've got going on and also provide links to resources like the upcoming sorry, the recently released training and certification programs. Rob, is there anything you'd like to add to that? No, you're all good. Excellent. In which case I will say thank you again for the contributions from FinOps towards marketing our project and from yourself for implementing all the changes.
With that, I will go back to a reminder that the FDC3 training courses have now been have been released. These are updated training courses covering FDC3. They include a free introduction to FDC3, which is at most semi technical. It's intended to help support not just developers getting started, but also business stakeholders, project managers and others to help to understand the core concepts behind FDC3.
And then it's followed by a second [00:07:00] paid course which is for developing solutions with FDC3, which takes you through everything you need to know to write the code and add it to your applications, et cetera. Both courses are also available to FinOps Golden Platinum members as a member benefit. So do check out the blog article about that or head straight on to the courses on the Linux Foundation website.
You'll also find a link from the New Look FDC3 homepage. And once you've taken those courses and mastered all things FDC3, you can take the FDC the Finos, I should say OS certified FB C3 practitioner certification to get yourself a badge to display through Credly and LinkedIn. and demonstrate that you understand the key considerations in FDC3, the rationale behind the FDC3 standard, and how to use it at an expert level.
So again, this is available to Gold and Platinum members of FINOS as a member's benefit, but [00:08:00] is also open to anyone in the community for a small fee to cover the exam costs. Again thank you very much to FINOS and various contributors amongst the FDC3 maintainers and others who helped to produce the certification exam.
It really does take a village to produce one of these. So there was a good 10 or so people writing and reviewing questions there from across the community. And lastly, we have, of course, the FDC3 conformance framework is out there. So for any firms that are implementing their own desktop agents or needing to confirm the conformance of the desktop agent that they have from a vendor, you can look to that testing framework to give you a set of applications.
And test runner that can confirm that you are conformant to either 1.2 or 2.0 versions of the FBC three standard. And you can contact Rob to arrange a formal certification round, which again [00:09:00]comes with it, the conformance badge he can use in marketing and other things to tell the world that you conform to that particular version of FDC3.
And with that, I will move us on to a summary of recent activity in the FDC3 discussion groups. So those. Those meetings that are working on extending or improving FDC3 in some way to handle new use cases, be they technical or workflow related. We'll start off with FDC3 for web browsers.
Just let a couple of other participants in here. Which is about supporting new FDC3 use cases. Thanks. On the technical side this time where there already exist a number of vendor products out there that offer FDC3 and other proprietary interop APIs in web browsers. But there's a bit of a catch they can't inject the FDC3.
When API when working in a browser, as we [00:10:00] normally do in a container, it's usually picked up at a particular location. And therefore, app implementations can only support specific desktop agents by incorporating their libraries perhaps detecting whether they're present and running them. This makes it much more difficult to implement an app once and have it run anywhere in an FDC3 conformum.
desktop agent, which really is one of the main reasons for having an interop standard. It's to help us build that ecosystem of applications that can run in any conformant agent. So that is a relatively severe limitation for the standard. That's not a problem if you're building a platform just with your own apps, but with many of us, most of us are doing this so that we can interrupt with third party applications, which currently would then have to do a specific integration.
And make a bilateral agreement on which desktop agent that they are working with. The solution to that is an open standard for [00:11:00] an FDC3 wire protocol, something we've talked about for a number of years, that would be for use inside a web browser. There's two parts to that. First, we're calling the FDC3 web connection protocol, which is a protocol for establishing a connection To a desktop agent, be that one in an existing style container that is injecting it or establishing that you were started in a browser by a desktop agent and should connect back to that.
And then the communication protocol, this being the real wire protocol that defines all the interactions with the desktop agent. In normal, in normal use. So something representing each API call, each response that is possible, any events that occur, et cetera, that in turn will then be implemented in an updated version of the FDC3 NPM module if the proposal is accepted via a new get agent function, which should allow for a single line retrofit of existing FDC3 [00:12:00] applications or build of new applications that simply make one API call on one line and can then connect to any type of desktop agent, be it in a browser or a container.
So a simple retrofit it's intended to support either use case and hence is non breaking existing apps working with containers will continue to work in the same way that they do. But if you switch to the get agent function, it will look for the container injected one under the hood or the parent desktop agent and do the appropriate thing.
When connecting in a browser, it's going to return something we're currently calling a desktop agent proxy that will act like an implementation of a desktop agent and handle communication back to the desktop agent in another window. Okay. Hence, you can have a third party app that is just plugged into the FDC3 library, and it should drop in alongside your own applications, which may use the same approach, or a vendor library, however [00:13:00] you prefer.
We have discovered through those meetings, though, that working in a browser requires a number of things, one of which is better app identity validation. For example, in web browsers applications could refresh or navigate, and it's hard to pick up the exact URLs that they've gone to. Thanks. As the browser rightly protects protects that information so other apps can't get at it.
You might be able to find out the domain of an application that you're talking to, but not its actual full path. And as soon as you've got multiple applications on the same origin, you have a problem. So if they navigate between each other, change identities, et cetera, You we need to know about that and validate it better And we also need in some cases handling for intent resolvers and channel selector uis Depending on how the desktop agent was built so we're currently exploring a number of options for how to handle that and of course health For how the desktop agent can provide its own user interface [00:14:00] for those things With that, I'll move us on to the FDC3 Use Cases group which is working more on the fun functional use cases.
I think Vinnie hasn't managed to join us just yet but this is Vinay Mistry's group who are Essentially helping to build us a roadmap for future additions to FDC3 by working with business stakeholders to explore what things are handled for them, what use cases what user roles, and hence what actions that they need to take.
It was based on a relaunch of the context data and intents group, but shifting towards the business stakeholders. Who will be providing the the needs the FDC3 needs to solve for. We hosted our third meeting of that on the 2nd of May with participation from many external contributors, which was great.
We're using a design thinking approach based on [00:15:00] breaking down the personas. So who are the target end users for FDC3? breaking down their typical workflows, their day to day tasks, which I'll show you an example of shortly, and then requirements for the interop steps within those workflows. So that's all being collated into a spreadsheet that there's a link for.
where you can start to view those things that will be created. And then we can get back to the technical process of defining the context objects and the fields that they contain for all these different types. So an example of breaking down the user role might be breaking down the different types of people that you want to support with an FDC3 desktop.
And if we take one of those as was contributed by a member of the FDC3 community, they might undertake sort of three main tasks. types of tasks pre trade workflows, trade execution workflows, and post trade workflows. And then they have a various different [00:16:00] types of activity within that. So for example, in a pre trade workflow, they may wish to view news or check liquidity.
Later on they may need to complete some historical analysis, et cetera. These might create intent for us. I wish to view an historical analysis. I wish to view news, et cetera. I wish to create a trade or start a chat. And similarly, they then need to be supported with appropriate context objects, which we may already have.
Or we may need to define.
Then on to identity and threat modeling. This is chaired by, this group is chaired by Yannick Malins, also from Symphony. Where they are looking specifically at the technical issues particularly the identity and security issues behind enabling more transactional use cases in FDC3. These need work because FDC3 was founded on the idea [00:17:00] of open interop.
Typically inside of a container, which does a couple of things for us. One is that inside that container, it tended to be the case that the app identities have been bundled with the container with an in house app directory. This may not have been quite the original intention with app directories where we thought we might see them springing up across the industry for vendors who are pushing out applications.
But in reality, it's tended to be an adopting firm with a desktop agent, populating their own directory of apps. They're then sharing context in between potentially their own applications, but also vendor applications. And FDC3 has traditionally provided very little detail. on who the other participants are.
Where are you receiving a request from? Where are you receiving a message from? Et cetera. We did add the, an optional ability to get originating app metadata in FDC3 2. 0. But again, this is only [00:18:00] as trustworthy as the desktop agent is. And as FDC3 is an open standard, a desktop agent can be implemented by anyone.
Meaning we have a further identity problem there, not just of the apps, but also of the desktop agent that's facilitating them. And then finally FDC3 has always involved advertising capabilities like intents through the app directory that can then be invoked by other applications. Again, this is one of those areas where you didn't necessarily know who was asking you to perform an action which has proven to be a problem.
For some of the organizations starting to implement cross firm interoperability, for example, bringing their applications into another firm's desktop. So those deeper transactional integrations which may be indicative of buy side and sell side collaboration, for example, sell side applications.
Being made available to buy side organizations to run on their desks. Those need stronger identity and security [00:19:00] solutions. Not least because they could be exposing different types of trading activity, pricing, etc. And they'll very much want to know who they are exposing those to. Now, part of the solution to doing that, to making this more secure, will be Moving to having more vendor controlled app directories.
These might be instead of some of the applications. Going into an in house directory or they might be in addition to just providing support for their identity confirmation But some features will be needed within those app directories in order to help identify the apps and connect them to their actual implementations so for example public key could be given in an app directory record that an application then needs to use And then when it starts up, it may need to use its private key associated with its implementation to then identify itself and confirm its identity.
So we'll have some [00:20:00] form of identity validation procedures on connection, perhaps also in web applications when they navigate or refresh. As we saw with FDC3 for the web, and we might also be able to sign messages confirming where they came from, for example, requests for information or responses with that information.
And lastly, we're looking at techniques for encrypted communications that would be facilitated by, but potentially even protected from the desktop agent, helping to solve some of those information leakage concerns. Today, the FDC3 specification doesn't provide a standard way to implement these trust levels, hence the work in the meetings.
And this can be a barrier to adoption for those high trust use cases. That in turn brings a risk of fragmentation to the ecosystem due to vendor specific solutions, which most of us involved would wish to avoid. And as noted the FDC3 for the WebQt use cases [00:21:00] bring about a few additional complexities.
So the two groups are exchanging information and looking to coordinate on eventual solutions. Ultimately, the objective is to define ways for applications to trust the information they're receiving, and to ensure the information they send can only be read by the in The intended recipient app that may mean things like signing intent messages or even being able to encrypt the contents of a context sent with an intent or context sent over a channel.
For example, there's been an interesting conversation recently on using private channels to implement to emulate the setup of a TLS connection. Used to, for secure web browsing by negotiating a key for the session and then being able to encrypt traffic over that channel without constantly having to go to the back end to actually encrypt or sign the messages.
And that [00:22:00] brings me on to the desktop agent bridging discussion group, which is all about connecting different desktop agents, different platforms together. Bridging actually became part of FDC3 in 2. 1. It's an experimental part which we are continuing to work on. As it gets implemented, it's intended to allow whole desktop agents to interrupt with each other.
So that their apps underneath can do so seamlessly. The applications don't need to know anything about the bridge that is allowing the desktop agents to communicate with each other. They can simply work with the same channels, or even raise intents that cross the bridge and are handled on the other side in another desktop agent.
The meetings on this topic continue in support of implementers. A little bit more on that Your second, but if you are working on a desktop agent that needs to implement this, or your firm wishes to implement a bridge and adopt bridging with your in house platform or vendor platforms, then please do come along and talk to us about what you're [00:23:00] doing.
We can provide you with some support. And we are currently reviewing a set of tests that conforms with the standard that were contributed by the Interop IO team to help bridge implementers. And that one of those one of the significant implementers for bridging is, of course, the FDC3 backplane project.
Which was a technology base developed at NatWest as a bridging solution. They use that currently in production to bridge a couple of different vendor containers. It's now open source and contributed to FINOS, but work is ongoing to align it with the standard and implement all possible workflows.
Contributors to that project are most welcome. It's currently recruiting for more maintainers. And it ships with a desktop service implementing a bridge that can accept plugins. So for example, if you want to do multi machine interop, it can also bridge containers running on different machines [00:24:00] and can accept plugins for your firm's own IT setup to discover those machines for the same user.
It's also intended to ship with a couple of clients to to the bridge that can be used by desktop agents to implement access to it or by monolithic desktop applications to integrate with the bridge instead of having them broken up and integrated into a desktop agent directly. So it's a use case we've heard about a number of times where and a monolithic desktop application.
Scheduled for replacement someday could be integrated with other more modern solutions working with FDC3 directly through the bridge, thereby saving on development on that platform while you're building out a newer set of applications to replace it in a micro front end style. So hopefully a useful bit of tooling for some out there whether they're working in desktop agents themselves or in monolithic [00:25:00]applications that you want to connect to one and Finally, we have the standards working group Where we are typically talking about the FDC3 API and overall governance.
This is the meeting where or proposals from any of the other groups which are known as discussion groups, they prepare proposals and they have to bring them along to the standards working group to be ratified and included in FDC3 finally. We will also then deal with any additional issues along the way.
That pop up that don't conform to one of the other groups. There's not currently a main API group. So small API issues are a common thing to crop up there. For example, we have, I think for the third time, had the use case of being able to reset context on a channel. raised with very clear description of the use case.
So this will be one we will be re exploring at our next meeting. So clearing [00:26:00] context often used to, for example, clear filters on a blotter or similar application. And these can be the solution we currently have for this works well if you've only got one type of filter, but if you could say filter by organization, instrument and something else, it gets a bit more difficult to handle.
And the suggestion is we need to do something with the channel API to make that a bit clearer. There is a another topic with a temporary title here that's going to be updated or superseded shortly but is for tracing API calls, which has use cases in terms of analytics. So if you had one customer interaction that related to several different API calls, it would be useful to be able to link those together for analytics purposes.
So for example, in everything that related to handling one RFQ, You could attach some additional data to broadcasts or intents that [00:27:00] helped an analytic system to link those back together. That is information that's solidly outside of the domain of the desktop agent and within the app, individual applications.
So they need a way of expressing this back that could then be picked up by a feature of the desktop agent or another system. For example Open telemetry being used to logs and data from the application itself to a, to an analytics platform to tie those together, you could then get a sense of the journey and the activity related.
There's a couple of other smaller use cases. For example occasionally you can create loops of context where it translates from one type to the next and therefore a desktop agent can't spot the loop very easily. Or I think it's previously been raised by another team who were looking to add some additional details about where an API call came from.
Not necessarily. to handle it, but [00:28:00] maybe to handle some downstream responses, et cetera, something that didn't fit, felt, didn't feel fitted within the context itself. As I said, these are fairly minor use cases compared to our primary run here, which has been agreed as tracking and analytics. And then lastly, we are also looking at adding event listeners or a pattern for event listeners for non context events to the desktop agent.
Obviously, you can already add handlers for intents. And context broadcasts, those two being absolutely critical functions of the desktop agent. But a number of people brought up use cases for other types of event. For example, knowing if the user has changed your user channel. This can sometimes crop up if an application and a desktop agent both have controls for it.
Or an application which is to act differently if it's been joined to a channel. And there's currently no way of knowing that other than polling the API, [00:29:00] which isn't a great solution. Also, the FDC3 for participants in the FDC3 for the web meetings have pointed out that they'd like to see some connection events as well.
So that would be another topic that has. I think just gone to PR was actually, I think I saw a contribution from the community this morning on writing up that PR. So that'll be one that comes back for discussion on a concrete set of changes. There are as always, a number of contribution opportunities out there, though.
We try and mark these with things like good first issue or help wanted in the FDC3 issues. So there's a list of interesting topics up there that range from maintenance of the FDC3 website. For example we could improve our open API or REST documentation within the website with some plugins, or we could be working on linking apps within the directory, et cetera.
These are things that we agreed were useful. But somebody hasn't yet [00:30:00] jumped on to actually do something about. So if you are looking to get involved, are looking to start contributions to open source, please do take a look at what we've got here and see what you or your team could address.
But similarly, if you have. Issues that you wish to discuss. You can of course, always raise those and bring them to a meeting for discussion. And they would of course be very natural topics for you to contribute some work to add in. The FDC3 maintainers and our editor, Hugh between us will be always be keen to give people a getting started guide for adding stuff to FDC3.
Just get in touch with us at FDC3 hyphen maintainers. at thenos. org. And with that, a bit more detail on the meetings you can get involved in. So we have upcoming meetings for all of the groups. Thursday the 9th of May will be our next identity and security meeting. In fact, this is the next FDC3 meeting.
Then [00:31:00] followed weekly by FDC3 for the web. Desktop agent bridging group, which this month fall on the same week and then The FDC3 use cases meeting again on the 6th of june If you'd like to have those added to your calendar please email help at FINOS. org and let one know which Meetings you'd added in and then you will see them.
Otherwise, you can finish visit the FINOS community calendar You which you can Google or follow the link in the presentation when we release it. And finally, the the FINOS Open Source and Finance Forum, OSFF, is coming up on the 26th of June. That will be at Park Plaza Westminster Bridge, and there are a couple of QR the full agenda.
And note, there are still sponsorship opportunities and tickets left to register. So do get your spot if at the conference for all [00:32:00] things FINOS and FinTech open source. There is a track on interoperability where there will be a number of presentations notably on things like security and FDC3 for the web.
So if you'd like a bit more detail than we had today on what is being proposed for change. Do come along to that talk or indeed any of the others at OSFF.
And finally we are always grateful for the support we receive in FDC3 from FINOS. It has been voted in by the FINOS board as a strategic initiative again this year, and hence we are receiving lots of help from Rob again this year, which we, as I've said, we're very grateful for. He's been working on the website, but he's also doing a huge amount of proof of concept work with us on FDC3 for the web.
Investing plenty of time on moving us forward, but like most open source projects the project itself is supposed to be run by volunteers. We have participants who are encouraged to raise issues, [00:33:00]participate in meetings, talk about their use cases, even raise PRs to make changes directly in FDC3.
We currently have one editor who reviews PRs for quality. So that's Hugh Troger, who we're very grateful for. Does great work to ensure that we not only produce quality documentation, but also that matches the decisions of the standards working group. And then lastly, we have the maintainers who do organizing activities, for example, chairing meetings like this one.
We have governance roles and general maintenance roles for the software that is delivered as part of FDC3. So we're maintaining the project infrastructure, code documentation, et cetera. And we are always looking looking forward to recruiting for all of these roles as they are what make FDC3 happen.
And particularly as we've taken on some new goals and some new use cases, we're in need of as much support as we can get. Hence if you or If [00:34:00] you'd like to nominate yourself or a colleague to take part in maintenance, or indeed any info on any of the roles, please contact FDC3 maintainers at FINOS.org.
And we will arrange to meet up with you. and give you some more details. You can also check out the FDC3 readme for more info on what it means to be a participant, editor, or maintainer.
