| Info |
|---|
Add your comments directly to the page. Include links to any relevant research, data, or feedback. |
| Page Properties | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||
|
Background
The usage policy class “Restrict: for specific purpose” constraints data to be transferred if the containerised application is verified to not have changed. The change in the containerised application is detected by comparing its hash at run time with the hash at the time when connector was configured. It was assumed in the product design that the containerised application in the choice of programming language (node/python/ruby etc) can be created in a no code manner through the click of a button referring to the github repository. It was realised that this is not possible in a no code way and therefore the flow and user actions need to change.
Relevant data
The sequence for creating a containerised application as thought earlier:
Consumer can share a github or similar repository of a node/python application for review to provider
Provider can verify the repository and approve
Consumer can containerise the approved application repository
Hash of the container is logged by FS at this point and stored at provider’s end as well
Provider shares data through connector and the exchange takes place only when hash has not changed
Issues:
How does the repository approval take place?
Single click containerisation not possible implying the consumer needs to create the container outside FS environment and therefore can change the repository after approval.
Options considered
Option 1: | Option 2: | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | Trusted third party is where application repo is uploaded by the consumer with provider’s address and once provider approves the same, trusted third party creates a containerised application | To be thought. | ||||||||||||||||||
Pros and cons |
Takes away the effort to containerise application from consumer Can scale in future with service provider acting like a “play store” and also as approver for advanced applications
Need to publish/ show code to trusted third party (similar to Android application) Another actor in the ecosystem - governance needs to be sorted out |
| ||||||||||||||||||
Estimated Effort |
|
|
Action items
Following action items to take decision:
- Mayank (Unlicensed) Come up with further options if possible
- Mayank (Unlicensed) What would be the long term implications for purely third party player instead of FS?
- Mayank (Unlicensed) Input for UI design based on the decision