Question: Desktop Agent in iframes and popup windows about fdc3

[kriswest]

Should the Desktop Agent API (window.fdc3) be injected into pages running in iframes and windows opened with window.open?

Currently, the standard documentation doesn't take a view on this and it is therefore largely an implementation decision for a DA. I have seen solutions that can and do make FDC3 available in both cases - but not in a standard form.

However, this is something that the "FDC3 for the Web" discussion group has addressed as a use case. In web browser, windows opened via a Desktop Agent would almost always be opened via window.open or embedded in iframes and the current proposal to support includes a step requiring them to self-identify themselves (by referring to an appD record) with a reasonable, if minimal, validation step that confirms that identity (at least as far as confirming a matching domain). This is expected to be replaced in future with more detailed validation based on what the "Identity & Threat modelling" discussion group proposes and is eventually adopted.

The proposed procedure is also usable in a Desktop container and would allow those to also support these cases, by identifying genuine FDC3 applications and associating them with a configuration.

Yes, if they are from the same origin. Arbitrary web pages should not be considered to be FDC3 apps, therefore the Desktop Agent APIs should not be available for them unless they were opened through the FDC3 API.

This is the simplest solution with the current version of the FDC3 standard.

If so, should they 'inherit' the instanceId of the parent window?

No. Shared instanceIds would make it impossible to implement intent resolution or any other API where an instanceId is provided by the caller, because the Desktop Agent could not decide which window to communicate with.

I agree, they absolutely should not inherit instanceIds. The FDC3 for the Web proposal goes to some length to ensure that this does not happen, accidentally or otherwise. SessionStorage (used in the proposal to store instance details) gets cloned during a window.open to the same domain, so we've had to come up with a procedure that's not vulnerable to that. It is based on the use of BOTH an instanceUuid (a shared secret associated with the instance Id, saved in SessionStorage) and the comparison of WindowProxy objects (the window object proxy returned by calls to window.open). Each procedure has an edge case (cloning of storage, windows that have navigated to a different path or subdomain) - but combined they provide a reliable check for whether a window represents the same instance of an app as seen previously.

Does that answer your question?

[kriswest]

Closing due to inactivity. Feel free to re-open or convert to discussion if you have further questions on this topic