For reasons not relevant here, I was asked to tweak an XFCE 20.04 installation to not ask for a password after the screen power-saver kicks in. There’s no need for a screensaver with an LCD panel, so this should be straightforward, as per the XFCE 18.04 setup:
Which had no effect.
For some reason, perhaps having to do with an upgrade from 18.04 to 20.04, Light Locker wasn’t actually handling the screen locking; some dedicated searching suggested this is a problem of long standing.
So tweak the Lock Screen settings of the screen saver that’s not in use:
If you’re doing this remotely, adding a stanza to ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-screensaver.xml should suffice:
<?xml version="1.0" encoding="UTF-8"?>
<channel name="xfce4-screensaver" version="1.0">
<property name="saver" type="empty">
<property name="mode" type="int" value="0"/>
</property>
<property name="lock" type="empty">
<property name="enabled" type="bool" value="false"/>
</property>
</channel>
The threat model for this particular installation is “minimal”.
The Smell of Molten Projects in the Morning 
Slackware uses XScreensaver in XFCE, which can work well. OTOH, letting it use varying savers in the random selection can have bad results. All of my Dell* Linux computers managed to get lockups when it was time to go to another saver and the switching routine failed. If it didn’t go completely toes up, it asked for a password which I never requested. [Sigh]
The usual remedy involved a reboot, with the long-term fix going to a single screensaver. Never tried remote login and kill of the screensaver.
(*) The 32 bit Sony Vaio (Pentium 4 and not enough RAM) never showed this problem. The Dells are 64 bit.
In theory, XFCE shouldn’t be using the old screensaver / locker, but there is was. I have no explanation for how anything works these days …