Citi Hackathon FDC3 Use Case: Create an AppD reference implementation

[lucaborella89]

Create an FDC3 AppD reference implementation

Expected Features

There is no current reference implementation of an FDC3 App Directory (AppD) which makes it harder for firms (large and small) to host an appD describing their apps. This is set to become far more important when identity and security features are added to FDC3 in 2.3 when the AppD records will start including public keys for encryption.

See finos/FDC3#563

Useful info

Kris West is the maintainer of FDC3
Alexandru Dumitru is a contributor and Project Administrator to FDC3

An appD is a small REST server that serves records of applications that can be started by and used with an FDC3 Desktop Agent

• See https://fdc3.finos.org/docs/next/app-directory/overview for a description of what an appD does
• See https://fdc3.finos.org/schemas/next/app-directory.html for the OpenAPI specification of an AppD server
• See https://learn.openapis.org/introduction.html for an introduction to OpenAPI (a way of specifying the functionality of a REST server, with associated tools for generating either a REST Client or a skeleton for a REST server)

FINOS also has an AppD with a UI: https://directory.fdc3.finos.org/ But the author doesn't consider it a suitable reference implementation.

Example API response: https://directory.fdc3.finos.org/v2/apps/

Follow-on issues

1. Provide better documentation and examples for AppD auth support #559
2. Add /intents and /contexts endpoints to the AppD API #719

Citi's implementation already has these endpoints - useful for developers.

[kriswest]

To work on this use case create your own github repository to host your implementation. If you're successful the FDC3 maintainers can work with you to adopt it as a reference implementation and open source implementation of the AppD Part of the FDC3 Standard.

[Ts-A]

Hi @kriswest

I'm building the AppD RESTful server in node with ts.

In the existing appD implementation, I can notice that only some files from appD implementation are served such as adaptable demo, symphony, etc. but not the ones likes Conformance.json, IntentAppId.json in the example api response.

Is there any business logic why only certain files in _appD are served?

In my current implementation, I have cloned the _appD folder in my local repo and I serve 2 endpoints: GET by appId, GET all applications.
These 2 endpoints as the name suggests serves any matching file in _appD be it Conformance.json or Symphony.json.

for reference: https://github.com/Ts-A/AppD-Reference

[kriswest]

@Ts-A Great to hear you are working on this @Ts-A - apologies for the slow response, I didn't realise I wasn't getting notificaitons from these discussions.

In the existing appD implementation, I can notice that only some files from appD implementation are served such as adaptable demo, symphony, etc. but not the ones likes Conformance.json, IntentAppId.json in the example api response.

Well spotted! Yes, technically the FINOS appD is 3 different appDs, the main appD, one for v1.2 conformance testing of Desktop Agents and another for v2.0 conformance testing of Desktop Agents. The reason for that is that the conformance apps are not useful for demo or development, only testing purposes. Further the tests themselves rely on a constrained set of apps being available to a Desktop Agent (just those defined in the test) to ensure that they know exactly what output Desktop Agents running the test should produce.

There is a small error in the URL pattern used for the conformance appDs as they should conform to the URL patterns defined here: https://fdc3.finos.org/docs/app-directory/overview#fully-qualified-appid-namespace-syntax-host-resolution
i.e. <domain:port>/api/appd/(version)/apps
So to be absolutely correct they should really be hosted on different subdomains ;-)

Is there any business logic why only certain files in _appD are served?

Hopefully, the above explains why there are different subsets of apps served on each endpoint in the FINOS case. In production use cases appDs can technically still serve different subsets of apps to different users, by using authentication, see: https://fdc3.finos.org/docs/app-directory/overview#authentication-and-entitlements

Authentication in appD is basic in that a bearer token is supported. An appD implementation can verify the token (returning an error if it cannot do so) and use it to idnetify a user, then return an appropriate subset for that user. This would allow a single implementation to serve apps for different roles in an organisation or different subsets to different external client organisations as needed. Hence, if looking to take your implementation further and to make it useful in more cases, consider how it might support authentication, definitions of roles and linking into external auth systems or databases (perhaps through a plugin).

It looks like you've made a great start on an implementation, I'd consider looking at how you can support auth plugins or plugins to replace reading the data from file with reading from another source (e.g. a database).

I hope that helps - I believe we are planning for a office hours session tomorrow at 17:30 IST - happy to discuss this more there or in this discussion thread!

[Ts-A]

Thank you @kriswest
I'll go through the resources that you have pointed out!

[kushagraGit]

Hi @kriswest ,

We have a solution ready for an AppD reference implementation and we have made those implementation in our repository which is connected to the Citi.
We have the documentation available and you can start review of our solution. The solution is well documented in README.md file where you can get reference of what we have tried to implement.

Our team members are:
https://github.com/ThatNinjaGuy
https://github.com/Yousuf-Ejaz
https://github.com/kushagraGit

Our repository link: https://github.com/kushagraGit/finos_hackathon_citi_vikings
master branch is the default branch for our repository.

Thanks & Regards,
Kushagra