Hey folks,
Let me add a link to the previous request just for the record: Classic confinement request for TSCR
As you said, I already granted use of the org.tscr.TSCR well-known d-bus name, as it matches the current policy. The snap now passed automatic review and is published to the store.
First of all, if TSCR is a commercialized by a registered company, I would encourage you to apply for Verified Accounts. It will grant you the green tick icon on all your snaps, so that your users can know that they are consuming the snap from the authoritative source. In addition it will help the reviewers to weight for on some of the auto-connections requests.
password-manager-service
This exposes all credentials stored in the session keyring and therefore auto-connection is (almost) never granted. As per your description, TSCR includes a Secret Vault / credentials and secrets management subsystem and uses the system keyring/Secret Service for secure local storage., my understanding is that TSCR only needs to access credentials that TSCR created previously. In this case, the Secret portal would be the right solution.
If you can clarify whether my assumption is right and the programming language you are using for the interaction with the Secrets store I might be able to provide further insights.
mount-observe
This is most likely required and acceptable. It would be really helpful if you would be able to provide the apparmor denials you observe when running the application with this interface disconnected.
removable-media
As per the Process for aliases, auto-connections and tracks - Snap documentation, users tend to store sensitive information in external devices. Thus, auto-connection is frequently reserved for a reduced range of application (mostly media players, recorders, etc.).
Assuming that TSCR is a desktop application, maybe File Chooser - XDG Desktop Portal may be helpful in this case.
Thanks!