...
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.
...
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 thoughtPrepare guidelines for the developers of consumer application and ask them to strictly adhere to the guidelines. Also, step-by-step instructions could be created for consumer to containerise and upload the application as well as security hash. | ||||||||||||||||||
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 | Effort is minimised for containerisation for the consumer. No need for a third party intervention and submission of code to someone else Easy integration of application into the ecosystem with other applications. Puts the onus on containerisation on consumer who may or may not have their own developer team. Consumer might not follow all the guidelines and hence could result in incompatibility of application with trusted connector | ||||||||||||||||||
Estimated Effort |
|
|
...
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
Outcome
Since we are working with only a few partners for the starting phase, Digital Green can act as the trusted third party. Another important aspect to think of while containerizing could be analytics and usage patterns of the applications.