Abusing/overusing FDC3 ?

[jfbaro]

Hello everyone!

We’re in the process of considering adopting FDC3 for our internal applications and are looking for insights on best practices for deciding when to use FDC3 for front-end information sharing versus relying on traditional back-end APIs when appropriate.

Here’s what we currently consider a reasonable approach as a decision tree for using FDC3 and APIs:

Guidelines for Using FDC3 vs. APIs in Internal Applications

Purpose:

FDC3: Best for real-time, front-end interactions that don’t need data persistence, security, or audit tracking (e.g., context switching between apps).
APIs: Ideal for secure data transfer, persistence, and complex processing, especially for sensitive or auditable information like PII.

Decision Guide:

• Use FDC3 if data is session-based, non-sensitive, and only needed for immediate front-end interactions.
• Use APIs if data requires persistence, security (e.g., PII), or needs back-end processing or audit tracking.

Guardrails:

• Limit FDC3 to non-sensitive, session-based data.
• Avoid FDC3 for PII or data needing encryption, persistence, or audit tracking.
• Define specific FDC3 contexts and avoid overuse.

Examples:

• FDC3 Use Case: Front-end context updates, like switching a selected client between apps (this is challenging, as typically this involves PII information).
• API Use Case for PII: Secure, encrypted PII transfer between systems.
• API Use Case for Auditing: Logged data flows between applications for compliance.

Best Practices:

• Use FDC3 only for immediate, non-sensitive context sharing.
• Reserve APIs for sensitive or auditable data transfers.
• Regularly review FDC3 usage to avoid overuse and ensure it enhances user experience.

I’d love to hear if the community agrees with this approach or has additional recommendations, decision trees, or guardrails to guide our developers effectively. We especially want to avoid overusing FDC3 and apply it in the right scenarios.

Any advice or examples would be greatly appreciated!

Thank you!

[robmoffat]

I'm interested to hear what some of the other FDC3 experts say on this! I just wanted to drop in a couple of points about where I come from on this:

1. FDC3 workflows involve the user and the user's particular application state. All of which is not really available to APIs on the back-end. The binding is at runtime.

2. We are addressing security in FDC3, but you're right to point this out. The roadmap is currently looking like sending secured messages via FDC3 will be addressed in 2.3 and we have a proof-of-concept here and a presentation here

[kriswest]

I'd suggest that there are two additional variables that you need to consider in your analysis/guard-rails, when it comes to protecting and auditing PII transfer:

• The specific implementation of an FDC3 Desktop Agent that you use
  • A cloud-based implementation will transfer the information off-device and possibly off-network, which would need to be allowed by your GDPR or similar data-processing policy, where most container-based implementations communicate on the local device only.
  • A Desktop Agent can offer logging and auditing capabilities - these are not defined by the Standard, but can be implemented, as can controls to secure which applications can send or receive communications to others.
• How you use FDC3 in your applications
  • User channels are intended for open context sharing, but you can also make use of:
    • Targetted intents (allowing you to preauthorize which apps can receive data - you can implement that in your own application nor a DA can offer features to control resolution as stated above)
    • Private Channels made available only to specific other applications
    • Encrypted or signed context (as Rob mentions above there is work ongoing to standardize an approach and envelope format etc., however, it's implementable without).

What I'm saying with all this is that you can use FDC3 to handle sensitive information, but you have to consider how you use FDC3 to communicate (i.e. who will be able to see the communication) and what the properties of the FDC3 implementation you are using are (how does it transmit the data, how can it control transmission, whether it can provide auditable logs).

When it comes to overuse of FDC3 I agree that FDC3 is best used for immediate context sharing and invoking functionality - i.e. tied to user interfaces and interaction (where it can make it faster and less error-prone than when manually conducted by the user). It is not intended to replace transactional APIs or any interaction between systems that would not normally be handled by a user directly.

FDC3 can enable the decomposition of complex apps into smaller, more maintainable micro-frontends. These will need to communicate with each other more often - and you may need to consider how and over what implementation that communication is performed as described above.

Finally, I would watch out for the proliferation of context and intent definitions:

• You only get interoperability where apps use the same types. Hence, you should use standardized types wherever possible and let the community know if you are missing types that you think would be relevant to others.
• You should only put the minimum you need to communicate into a context object - the principle of least privilege applies!