What you are describing @drehb was exactly what triggered some internal discussions when we came up with the authorisations pop-ups we currently have as we reviewed different types of flows and scenarios, so it seems we are on the same track. I’ll try to summarise some of the reasoning behind this.
We thought that having the same type of popup could be problematic since the user might not notice that the app is being re-authorised with a different set of permissions so we came up with the second type of pop-up I mentioned before, and I think we all agree on this.
Also, one important thing to consider is that authorising an app with a new/different set of permissions implies to automatically revoke the previous set of permissions to then create a new set of permissions (encryption keys etc.), which in turn might imply re-encrypting some data to be able to enforce the new set of permissions (I’m not sure if it’s only when the new permissions are more restrictive, or simply always).
Then, you have the case you mentioned of an app being upgraded, so a new set of permissions may be required in such a case, but not always. What the app is expected to do is to send a second request with
window.safeApp.authoriseContainer as soon as the app realises the set of permissions granted is not enough, and at this point the app can decide to still work and disable some new features, kinda fallback-ing to previous version’s set of functionalities.
It can otherwise decide to just stop working since it now requires the new set of permissions to be granted, or perhaps explain this to the user and perform a new authorisation attempt (again with
authoriseContainer) to give the user a new chance to approve it.
In any case that’s something to be defined by the app’s creator, and the list of permissions granted can be inspected by the app using
So what happens is that after an app gets more permissions granted with
authoriseContainer, the new set of permissions is stored in the account and any subsequent re-authorisation will provide the same set of permissions that were granted, allowing the app to go back to a normal flow after the upgrade was successful.
On the other hand, we also envision that we could have more granularity in the authorisation flows, i.e. the user could select a subset of permissions to be granted when an authorisation request is received; or even at later moment by going into the app’s details page in the Authenticator UI.
When you think of all these scenarios, you can quickly realise that the authorisation flows need to be distinguishable between the case of just re-authorisation (due to re-launching/re-opening an app) and the cases when new a new/different set of permissions is being explicitly requested by the app (e.g. due to an upgrade).
I hope this helps to understand the background; the current state is one solution to all this, there are/might be other alternatives but this is the one we thought was the simplest and the one that covered all cases quite well. Nevertheless, I love this was brought up since it’ll be good to hear other ways that could possibly be a better and simpler approach to all this.