Require propagation of originating application identity on context/intent handlers

[symphony-adnane]

Enhancement Request

As of today, when an application listens to intents or context change, there is no information related to the identity of the originator in the context data

Use Case

• Audit logging : For example, an application generates a SendMessage Intent in order to send a message on behalf of the user, we need a way to identify the source of the message
• Communication boundaries: An admin should to be able to block intents/context broadcasts coming from a specific set of apps for compliance purposes (same goes for preventing some apps from receiving raised intents)

Solution Proposals

• Enrich the current context interface to introduce "sourceMetadata:AppMetadata",
• Wrap context data in a higher level object to introduce a metadata section -> But would introduce a breaking change

Open question

Would it be of interest to introduce the boundaries concept in the agent through FDC3?

[kriswest]

I would suggest that rather than altering or wrapping context objects that we consider adding a second argument to context and intent handler functions instead that would allow them to receive this info alongside messages. E.g. update:

type ContextHandler = (context: Context) => void;

to:

type ContextHandler = (context: Context, sourceMetadata: AppMetadata) => void;

(The changes to the proposed IntentHandler type would be the same)

I believe this would be tidier and a non-breaking change to existing (javascript) implementations.

Its also worth noting that there have, historically, been objections to making such changes (I've previously proposed much the same) - particularly as this exposes the information on whats running on the desktop, and potentially control of comms, to the applications rather than the owner of the desktop. Whereas, controls at the desktop agent level instead are in the hands of the desktop owner.

[thorsent]

I think we should be concerned about future-proofing compatibility of the function signature. This alternate signature would allow future expansion without breaking changes:

type ContextMetadata : {
   sourceMetaData ?: AppMetadata
}

type ContextHandler = (context: Context, meta?: ContextMetadata) => void;

[kriswest]

@bingenito Let me know if you're going to be able to have a go at this before the meeting next week (Thurs 28th April). If not we can find another contributor to give it a go.

[bingenito]

@kriswest I kept trying to believe I could juggle it and wanted to do it, but I should have admitted lack of time much earlier as to not put it too far behind in scheduling. Sorry. Please see if we can line up someone else to do the PR.

[kriswest]

No problem @bingenito, we'll get it done ;-)

[kriswest]

I think we should be concerned about future-proofing compatibility of the function signature. This alternate signature would allow future expansion without breaking changes:

type ContextMetadata : {
   sourceMetaData ?: AppMetadata
}

type ContextHandler = (context: Context, meta?: ContextMetadata) => void;

@thorsent seems a reasonable suggestion, can you suggest any additional metadata that we might want to return in future (to provide a use-case for wrapping the source metadata)?

[robmoffat]

Is there an argument that the intent handler would also want to know about the user that created the original intent? If so, this information could also be contained in @kriswest 's ContextMetadata type.

#684.

[kriswest]

@robmoffat FDC3 only contemplates interop between apps for a single user, even if you are using an intent like StartEmail or StartChat. It would deliver the raised intent and context from the raising app to the resolving app on that user's machine, then the actual email or chat produced passes out of the realm of FDC3 to go to the other user.

If there's a use case for identity on intent handlers, it would only be through desktop agent bridging, and then only to confirm that its the same user on each of the bridged desktop agents (which is limiting rather than enabling, but may be desired by some vendors ¯\_(ツ)_/¯ ).