Spike: Ability for enrolling app to know which apps can approve new enrollments

[murali-shris]

Is your feature request related to a problem? Please describe.

• Currently apkam approvals happen through already enrolled apps which have enrollment widget implemented.
  There are few drawbacks of this approach

1. User needs latest app version which has approval feature
2. User has to remember previously enrolled apps inorder to approve new enrollment request

Describe the solution you'd like

1. Enrollment listing and approval feature from registrar/admin web application.
2. Explore design and implementation approach in this ticket

Describe alternatives you've considered

No response

Additional context

No response

[gkc]

@murali-shris I've had some conversation with @cconstab about this over the weekend. We should discuss again in architecture call, ideally tomorrow (Tuesday)

[murali-shris]

These are the possible solutions we have discussed so far

1. Store enrollment details in public hidden key. Enrolling app will lookup this public hidden key to view list of apps that has approving privilege.

   On enrollment approval, store enrollment details in a public hidden key.
   On enrollment revoke, remove the enrollment entry from the value using enrollmentID

   e.g
   Key : public:_enrollments@ alice
   Value: // each value in list will contain enrollment id, app name , device
   name

   Pros:

   • Simple to implement
   • User doesn’t have to remember already enrolled/onboarded apps

   Cons:

   • Internal enrollment details exposed via a public key
   • If there are no prior approved enrollments, then this key will be empty. This scenario will arise when an approving app
     has not updated to latest version which has enrollment widget functionality.

2. Approve enrollments through registrar web application

   Use the existing registrar web application (my.atsign.com) to view/approve/revoke enrollments. This requires use of an
   intermediary secondary server @ registrar to notify the web application and communicate with @ alice

   Pros:

   • Single web application to control enrollments, onboarded apps, etc.
   • User doesn’t have to remember already enrolled/onboarded apps

   Cons:

   • Complex to implement. Have to introduce @ registrar secondary. Changes in client and server code
   • Passing of encryption keys required for new enrollments through @ registrar is complicated.
   • Additional entry point to access @ alice secondary

3. An existing onboarded/enrolled app with enrollment widget uptake can approve enrollments

   After user enrolls a new app, display a message to user e.g “Use one of the onboarded/enrolled apps”

   Pros:

   • Simple to implement.App that needs to approve enrollments has to uptake enrollment widget

   Cons

   • User has to remember already enrolled/onboarded apps
   • Already onboarded app may not have updated to latest version and cannot see enrollment notifications
   • Already enrolled app, may not have sufficient privilege to approve new enrollment

4. Headless app that auto approves enrollment

   Every atsign will have a headless app running somewhere which can auto approve enrollments

   Pros:
   * No need of additional mobile app and also no manual intervention by user to approve enrollments

   Cons:
   * Where to run this headless app? On atsign infra or client side.. If on client side, will be a challenge to run headless
   app in mobile devices.

5. New admin mobile app

   Admin app will have features of registrar web app plus approve/deny/revoke enrollments

   Pros:
   * Single to manage atsigns, reset atsign, manage enrollments
   * User has full control over atsigns and enrollments

   Cons:
   * Additional mobile app to be installed and managed by the user

[cconstab]

Another idea...

Store the list of M/APKAM devices+apps in a self-key

Then if someone does not know what device to approve the enrollement in then any atKeys for the atSign can be used to share that list.

This reduces the attack surface to just devices/apps that have any set of keys for the atSign and gives the person some good clues as to which app/keys they can use to approve the M/APKAM request with.

We could also add this functionality to the CLI tools...

Pros:

• all done in atSign space and should be simple

Cons

• Perhaps some cognitive load for people but also lots of flexibility.

[murali-shris]

Discussion from arch call:
Consider combination of approach 6 and additional atsign manager app

[murali-shris]

Moving to backlog since it is not actively worked on. Will revisit once APKAM widget changes are complete