The dbus interface is intended for you to create a dbus service so that other applications (or the shell) may interact with your application via dbus. It is not used for granting permissions for your application to communicate with other dbus services.
This message:
"
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.186" (uid=1000 pid=23518 comm="/snap/superpaper/x7/usr/bin/python3 /snap/superpap" label=“snap.superpaper.superpaper (enforce)”) interface=“org.kde.PlasmaShell” member=“evaluateScript” error name="(unset)" requested_reply=“0” destination=":1.21" (uid=1000 pid=2059 comm="/usr/bin/plasmashell " label=“unconfined”)
"
indicates that your snap is trying to use the “evaluateScript” method of a process that provides the org.kde.PlasmaShell interface. It would be clearer if you provided the denial from journalctl, but this appears to be https://userbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting and something that has come up before with snaps: https://lists.ubuntu.com/archives/snapcraft/2017-April/003820.html. There are no snapd interfaces that support this and the snap would need to use classic confinement.
Since my response in 2017, we’ve refined our thinking around interfaces like this and classic. The requested access would have your snap send a script over dbus for PlasmaShell to execute. Since plasma shell runs the script in the context of plasma (ie unconfined), this would allow breaking out of application confinement (similar requests came up recently for gnome extensions and nautilus extensions). To prevent sandbox escape, plasma would have to be rearchitected to support running scripts under a different security context. The requirements for classic are understood, but per recent discussions with @pedronis for the analogous gnome extension request, this snap’s use of evaluateScript means it is unfortunately not a candidate classic.
If there was another wallpaper API you could use instead of org.kde.PlasmaShell.evaluateScript, then we could consider adding an interface to snapd for that API so your snap could work with strict confinement.