Date
Attendees
- Nick Kolba - OpenFin
- Chuck Danielsson - OpenFin
- Johan Sandersson - Factset
- Jonathan Teper - JPM
- Rhyddian Olds - DB
- Slava Kryukov - DB
- Frank Tarsillo - IHS Markit
Goals
- Group met to begin putting together an outline for scope and structure going forward.
Key points of Consensus
- App Directory is not an App Store standard
- Discovery and Launching are the most important considerations
- Standards must address cross-financial-platform discovery and launching with a pragmatic approach that lets platforms control their own implementations
- Entitlements are out of scope
Diagrams
Open Questions (for next session)
- Where can we align with existing standards?
- Is OAuth2 an appropriate model for the authentication of an App by the directory?
- Is SRV Record the right standard to use for App Directory linking/addressing?
- How would App hierarchy be represented? Should it it?
- Should there be an App Manifest standard? How would this be applied to native apps?
- Should the directory support commercial browser targets?
Discussion items
Introduction
The app directory came to be for 2 key reasons
- Security - a way to provide strong app identity on the desktop. This would be analagous to SSL.
- Discovery - this isn't as much about having an app store model as it is about being able to define the intents an app supports as well as the contexts it supports as well.
To Date
We've provided some earlier specifications - essentuially create a connection to a directory, validate connection, grant an encrypted token to the app that communicating apps could send back to the directory to validate
Q (Frank) -> Would the authentication be around something like OAuthV2 or home grown?
A -> Home grown for now. We could specify oauth but further investigation is required.
Q (Rhyddian) -> One of the things we need to consider is the role of the launcher. i.e. if I'm @ bank A and want to launch an app from bank B, I'd likely be doing that through their launcher. This makes the launcher itself the actual key piece.
A -> Excellent point, TR is a good example of this.
Reviewed Early Stage Implementations of App Directory
Frank: For resolving app directores - SRV records on DNS to resolve. A lot of systems use SRV records to point to DNS services.
The big question there then becomes - (Nick) -
App Foo exists in FDC3 & the Eikon app store
How do you resolve across those?
At a more granular level - many applications are aggregators. If they do aggregate a number of apps together, how do you distribute across those? To date - thoughts are that these aggregators will be end points. That was the way TR designed it, but having it work that way became a problem as complexity & logic was dumped into the endpoint itself.
Frank -> can TR issue a description of those issues? So we can better understand the use case?
Nick -> Yes, they will. I did experience a similar problem in Eikon. For example - openf2 - enables communication between separate iframes. Those are addressable as their own endpoints.
Frank -> Right, namespacing type issues
Rhyddian -> would these be srv records on DNS?
Frank -> no, my point was to do that on resolving the directory
Rhyddian -> to back up a little bit, are you thinking about having one big app store with a UI/browsable or just launching apps via interop (i.e. via intents)
Frank -> yes, all about interop
Rhyddian -> if that's the case, it's more driven by the intents group. For example, autobhan - an execution app with RFQ - it's up to the launcher to pass in those intents
Nick -> possible there isn't too much we need to define & launcher play a huge role. But we still do need a way to provide identity to the application.
Rhyddian -> Agree, and we are doing that now for our launcher via digital signatures, etc. How do we do this with plexus?
Slava -> We don't. There are 2 ways we coudl - one would be providing a key per app. The 2nd mechanism would be one where the central broker actually provides application tokens.
Nick -> We are more aligned with the 2nd so far in the FDC3.
We have put in work on the existing app directory @ OpenFin, are we interested in there being one main directory to share?
Yes
Jonathan -> 2 implementations we need to focus on from my team's persective
1) Non functional requirements around the handshake & its impact on performance
2) Entitlements - when you just don't have those permissions
=> Our position today is not in scope. How can you standardize entitlements systems in a meaningful?
Rhyddian - this would be handled by relevant launcher
Slava -> the other things to consider is a large use case of non-web based applications that would need to be handled as far as handshakes, etc.
The current app directory is focused on web/OpenFin apps - as there is a concept of a manifest. But a manifest could be a universal thing. Native applications could store a public key that is verified against the signature of the native application.
Nick -> Should there be a standard manifest? There's an opportunity to align with things like how PWA are handled. Does this make sense to included web apps running in a browser target?
Slava -> from our perspective, the standalone browser is very important to support.
Nick -> standalone browser would be using a REST API - possible to put a message bus into a browser, but...
Webapps could communicate using trusted intermediary via postmessage, etc.
Summary Caveat (Rhyddian) ->
We will need to coordinate with the interop standards. In terms of however we do create that identity standard