Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Attendees

NameOrganisation
Frank TarsilloIHS Markit
Leslie SpiroGlue42
Jorge SantosRefinitiv
Jonathan TeperJPM
Namit
Nimit ShahOpenfin
Riko EksteenJP Morgan
Tosha EllisonFINOS
Rob UnderwoodFINOS


Discussion items

TimeItemWhoNotes
 10min

Review minutes/actions from last discussion.

 All

Tosha Ellison from FINOS performed scribe duties.

Action items were reviewed and new owners identified for three. No previous actions closed.

5minUpdates on ratifying proposals & specifications in the FDC3All

FDC3 Community - Proposals and specifications go through process of consensus for ratification, if not concencus then vote.

Once agreed by WG it is sent to the community (any global FINOS group) for a period then back to PMC to be approved. Still some mechanics (e.g. email and confluence group distribution). Then it's ratified

Commentary on proposals should be done in confluence or github

Announcement on email of decisions.

20minReview any comments to latest specification and associated updates (eg. Intents definition).  Frank

The basic ratification steps are as as follows:

  • Proposals and specifications must be agreed within the Working Group, ideally through consensus but if this is not possible then through a vote.
  • Once agreed within the WG they are made available to the wider FINOS community (specific mechanics TBD, likely a combination of email and confluence)
  • Following suitable feedback period the proposals/specifications are presented to the PMC to be approved.
  • PMC approval results in ratification.
20minStart the conversation on identity management and authorizations - collect feedbackAll

All specifications in progress should be clearly marked as “not ratified”.

To update the specifications going forward please submit a pull request (rather than updating directly). The pull request needs review and comment by another member of the group before being committed. (All “watchers” will receive the pull request notifications.)

It will be important for the proposal to be turned into a formal specification, particularly to catch some of the nuance that continues to be identifed.

The majority of the meeting was spent reviewing the Application Specification. Specific items discussed include:

  • AppID must be unique and will be allocated by the app directory but a typical format might be api/appd/v1/app1@appd.foo.com where the version references the interface version (not app version). The point of using the @ model is to make the lookup to the specifical application data more portable.
  • AppID supersedes Name (agreed by the group) and is a mandatory field
  • Version should be a mandatory field (agreed by the group)
  • Whether two different implementations of an app (e.g. launched via exe or browser) should be held in the appDirectory as two records or as one. Addressing entitlements also has bearing on this discussion. The group agreed that it would be necessary for two records to be captured.
  • Discussions to continue on where the manifest should live and on AppExe, AbbBrowser, etc.

20min

Start the conversation on identity management and authorizations - collect feedback

All

There was little time left for this section but Frank proposed using JWT bearer tokens to identify users that come into the AppDirectory and requested that the group review this.

5min


AOBAll

Tick42 indicated that they expected to have demo versions to show at the next meeting.

Action items