Correct "trusted identity" statements in AppD overview, consider whether app authentication properties are needed

[kriswest]

Area of Issue

[x] App Directory

Issue Description:

The App Directory Overview makes the claim that AppD:

"...provides trusted identity for financial desktop apps."

However, this claim is hard to support under the current specification as the AppD doesn't obviously provide a lot of value in:

"preventing spoofing and man-in-the-middle attacks when apps communicate with one another and exchange data"

particularly where that exchange happens anonymously over context channels. The Application definition does not itself provide a mechanism to authenticate individual applications.

However, when an appD is accessed via HTTPS, SSL & DNS confirm for us that we are retrieving app definition data from the expected source. If we trust that source AND it is authoritative for the application (e.g. a domain owned by a vendor that publishes the app, or by one's own firm pointing to their own deployments of in-house or vendor apps), we can then use HTTPS URLs to launch and communicate with the (web) application, secure in the knowledge we are protected from spoofing or MITM attacks and are accessing the expected application.

Hence, there are ways that an AppD can provide a trusted identity (for a web app) - but the statement in the AppD overview is far too broad and doesn't acknowledge the above caveats and should be corrected.

Further, it should be considered whether the AppD's application definition schema should include properties that can be used to authenticate an application (for example a public key that could be used, in conjunction with an API call or other suitable mechanism) to verify an application's identity. Such a mechanism would also allow the AppD to provide a trusted identity for native applications that are not accessed via SSL/DNS.