Should the desktop agent support both unqualified appIds and fully qualified ones?

[Charlotte981]

Question Area

• App Directory
• API
• Context Data
• Intents
• Use Cases
• Other

Question

Our desktop agent implementation currently only supports fully qualified appIds when opening apps from its directory in order to ensure all appIds are unique within the directory. However, when running the fdc3 conformance tests this has caused issues since some of the tests attempt to open apps with unqualified appIds. We were wondering whether the desktop agent is supposed to support both qualified and unqualified appIds, and if so, how is it supposed to distinguish between multiple apps with the same appId in different app directories?

[kriswest]

Hi @Charlotte981, first off the unqualified appIds are expected to be unique within a single directory, so you don't need to fully qualify to ensure that "all appIds are unique within the directory". However, you are absolutely right that it's necessary to fully qualify to "distinguish between multiple apps with the same appId in different app directories".

In my experience, most desktop agents treat appIds as if they are globally unique identifying strings, but their developers start to use full qualification when they implement support for retrieving app directories as this is when they first encounter an issue with uniqueness. This situation has probably come about as the App Directory part of the FDC3 Standard was less often used than the API part, with many implementations working with a configuration file instead of an actual app directory - a situation that has been changing and is expected to change further (due to anticipated proposals from the Identity and Threat modelling discussion group).

Regarding the conformance framework, we didn't think about or discuss this issue during its build and maintenance - I'm glad you've raised the question as it does need consideration. Further, if you take a close look at the App Directory and API parts of the standard, its only the App Directory that defines fully qualified IDs, while the only mention of them in the API part is:

An FDC3 Standard compliant Desktop Agent implementation SHOULD:
...

• Qualify appId values received from an app directory with the hostname of the app directory server (e.g. [email protected]) as defined in the app directory standard.

https://fdc3.finos.org/docs/api/spec#desktop-agent-api-standard-compliance

Hence, there is no behaviour defined for mapping between qualified and unqualified appIds in the API and, based on its current implementation, you'd only be able to complete all the conformance framework tests if you do NOT fully qualify the appIds as it uses unqualified ids to open apps and to target raised intents at them. E.g. https://github.com/finos/FDC3-conformance-framework/blob/main/src/test/common/control/open-control.ts#L21
This is not correct IMHO and it should support full qualification.

The quickest fix here would be to find and fully qualify all appIds in the conformance framework codebase. However, that will mean DA's that don't qualify them will then fail and as a SHOULD requirement that is optional. Hence, to make this work for you we either need to add a switch to the conformance framemwork to turn full qualification on or off OR you need to implement behavior in your DA that will detect an unqualified appId in an API call and attempt to map it to a qualified one (and hope there are not multiple that match - if they do perhaps default to the same appD as the app making the call?).

To properly move forward and negate the need to implement unstandardized behaviours we need to propose and adopt API requirements regarding full qualification. Personally, I believe we (as a community) need to be using the App Directories more, particularly as we look to secure communication between apps and improve identity validation of apps by Desktop Agents. To do so we will need to address full qualification of appIds in the API part of the standard.

I'd be happy to add this to the agenda for the next SWG meeting in January for discussion. I'd also like to get @robmoffat's view as FINOS maintains the conformance framework (and I know Rob's thinking about work on it needed in the future).

[Roaders]

Thanks for the very detailed and full reply (as usual) @kriswest. Yes I think that this certainly needs some discussion so please add it to the agenda. I think even if no changes are made some more detail around this in the docs would be a good idea.

We could do a best effort conversion from unqualified to qualified app ids but I think that we probably want to write our agent so that it requires fully qualified everywhere so we probably don't want to allow this best effort approach.

I think that for now we can probably update the tests locally to convert all the appIds to be fully qualified.

[Charlotte981]

Yes thank you for the comprehensive reply @kriswest

[kriswest]

@Roaders and @Charlotte981 if you do update the framework please shoot us PR with your changes and we'll get it merged onto a branch of the repository.

The files you need to update are (I think):

• https://github.com/finos/FDC3-conformance-framework/blob/main/src/test/v1.2/support/intent-support-1.2.ts#L14-L16
• https://github.com/finos/FDC3-conformance-framework/blob/main/src/test/v2.0/support/intent-support-2.0.ts#L200-L213
• https://github.com/finos/FDC3-conformance-framework/blob/main/src/test/common/fdc3.open.ts#L22
• https://github.com/finos/FDC3-conformance-framework/blob/main/src/test/common/control/open-control.ts#L18-L41
• https://github.com/finos/FDC3-conformance-framework/blob/main/src/test/v2.0/support/channels-support-2.0.ts#L72

There may be others...

[Roaders]

that's great. Thanks Kris. We will certainly do a PR.

If we were to implement a switch to run in either mode do you have any suggestions how we would do that?
I've not actually run the tests myself so am not very familiar with how they work.

A switch on the launch page perhaps?

[kriswest]

It'll take some small refactoring to achieve a switch... probably starting with moving any appIds directly in the code refs above to variables (most are already in imported variables, but some aren't) and then converting variable use into static functions. If you do that, then a switch on the launch page is achievable.

The architecture used in the tests could do with work so if it looks too involved, then I'd suggest starting by just adapting a branch to to use fully qualified IDs and we'll address this more fully after we've discussed it in Jan for the FDC3 2.3 scope.