2018-08-29 FDC3 AppD WG Meeting notes

Review minutes/actions from last discussion.

Started with review of the current Standards Ratification Process proposal, something the group has discussed before.

The process is:

• WG creates the proposition,
• Proposition is ratified within the group itself by consensus or vote
• Feedback is accepted
• Proposed standard is presented to the FDC3 general group meeting
• There is a two week comment period for feedback.
• After two weeks it goes to the PMC for ratification, following similar process of consensus.

Frank suggested that the group could use the Apache proposal format. Nick said they should take this offline. Note that you can see this discussion in comments on  confluence in the  Standards Ratification Process.

The group was asked if there were any concerns on the approach and none were raised.

Frank asked why use cases need to be different - he thinks there should be one standard approach. Nick explained that they wanted a slightly more streamlined process without the PMC approval as they process a greater number of use cases, which makes sense. The process described previously is for FDC3 standards which have a higher bar since participants will be expected to be compliant with these and Use Cases falls outside of that scope.

NOTE: Everyone needs to be comfortable with the Standards Ratification Process so comment if you are not. Once this is agreed it will be sent for PMC approval.

Last meeting the WG also reviewed comments related to the intents definition, which Frank put into the specification as it was ratified by the intents WG. Last time we:

• Looked at spec changes
• Made sure we have a 4-eyes check on the pull requests coming into the specification
• E.g. Frank reviewed a pull request submitted by Leslie and team, which was to convert the spec to Open API v3.0 and also converted the libraries necessary to create the bindings of the stubs for the server side and the client.

As Above - particularly note the part in bold.

Leslie explained that they made the change to the code as discussed in a previous meeting to make a change to the YAML to deal with how they store the type of the application.

Nick showed the changes to appDetails, where basically depending on appType you have a reference of one of 4 appTypes (AppExe, AppBrowser, AppContainer, AppCustom) associated with that appDetail.

No other changes to discuss. Leslie mentioned that they did this as part of work on a toolbar that consumes this, which they intend to contribute in the next two weeks.

Nick asked how AppType will be used. Leslie explained that applications that you get back can be different types (browser, desktop, custom, etc.), and this allows any application consuming it to deal with different application types, because not every application is a container application.

Frank suggested going through an example to make it concrete. Leslie ran a demo and talked the group through it. Highlights/key points of the demo and subsequent discussion include:

• This is a launcher demo app for evaluating, testing, playing with app directoriesthat will be put into GitHub.  
• It is a JS application that shows creating a toolbar, which consumes items from the AppDirectory. It is designed to be used by developers and architects.
• It is a standalone Electron application that can do two things. It can start a URL using the standard desktop browser or start and executable because those are two of the application types.
• Regarding how appType and appDetails play into this, the launcher looks at appType and understands how to launch this based on the defined appType and appDetail (e.g. exe, container, custom)
• There was discussion around whether or not it was necessary to have the distinction of type rather than just two fields. Explanation is that there are different properties for different types of launchers/applications that will be launched and the idea is that we classify the obvious types and have a custom type to support any other custom implementations.
• There was further discussion about what detail is needed and where this is defined - in the appType or in the appManifest, and how much of it needs to be standardized. There was no clear conclusion.
• The, somewhat limited, group was not achieving consensus and Frank proposed putting this (whether to support appType or not) to a vote next time there is quorum, and potentially with the help of the demo once it is complete.

In terms of timing and comments on the pull requests, it is useful for members of the group to add themselves as a watcher of the project so you can comment in a timely manner.

Frank proposed that pull requests should be open for at least 24 hours before being accepted giving people a chance to review and comment. In future, the group may also want to review the pull requests as part of the WG discussions.

Leslie noted concern that 24 hours might not be enough and that there should be more discussion, including in comments, particularly if it is a more meaningful/substantial change.

Frank noted that the process will also need to be more stringent once the spec is actually ratified but at this stage (pre-ratification) it is better to move faster to get the POCs through before introducing a more rigorous review.

The group agreed that prior to ratification (i.e. now), the process will be that there is at least 24 hours for comment/review and that if the pull request looks reasonable Frank can accept it.

Regarding identity management Frank noted that he is putting into his POC bearer tokens as a requirement to access the directory. It is a standard JWT based token, well defined in the industry. As part of the POC you can register a user and generate a token with a standard login and password. (It can be made more complex later.) The bearer token will have an identifier in it (e.g. email) and that identifier will be authorised to access appDirectory entries that they submitted so they can be changed, updated, etc.

More work to be done after basic authentication but initial proposal is that we put in the spec the requirement to have a bearer token to be able to offer some security token required to access the appDirectory.

There are many use cases that can come from having a bearer token and there has to be some sort of identifier. This may be a different area of standardisation (access and controls) that sits outside of FDC3. For this case, where an implementation has a requirement to have an identifier, that identifier around users/apps will come through bearer tokens - and this is optional, if it’s not required it doesn’t need to be used. Agreed the bearer token will be in the current draft version of the spec.

10min

Where is the AppD POC??

All

In Frank’s POC you can create a user in the appDirectory and once the user created, you can use login and password to create the JWT token. You can then use the bearer token into the appDirectory to create/modify an entry in appDirectory. Once you create you essentially own the appDirectory. This is all in serialised files. It’s containerised so can run anywhere and wherever you want to point it.

Leslie's POC has previously been discussed.

The group discussed the process for creating a new project and where this should be stored.

• Nick noted that they still need to figure out (and within wider FDC3 context) where reference implementations live.
• For now the projects should be marked as demos (and as POCs) and should not use any proprietary technology or anything specific to a vendor.
• No PMC review is required before creating these POC projects at the moment and Frank will create a project for Leslie to use. A clear ReadMe must be included and it must be marked as POC.

There was some discussion around group membership as follows.

If you regularly participate and are missing on Confluence then send an email to Frank be added. Membership is really about participation. If you are in the google group and participating then that’s membership. Nick noted that Confluence should be set up so that if you are in the group you should show up in the list. We will fix if this is not the case.