...
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.