In its role definition, Scrum establishes the classic product management distinction between what and how.
The product owner says what to build and the developers decide how to built it.
As important as it is to separate what to build from how to built it, there is often a very fine line between what and how.
Let me give you a really simple example.
Suppose a product owner tells the developers that users need to be able to reset their passwords.
That is what is needed.
The productowner has left it entirely up to the developer how do that.
Now, suppose instead that the product owner tells the developers that users need to be able to reset their passwords by answering a security question.
The productowner has just dipped down into the how.
In doing so, the Product Owner has shrunk the solution space.
There are now fewer ways in which the Developers can achieve the Project Owner's goal of enabling users to Reset their Passwords.
It can be okay for a product owner to dip down into the how.
If how a solution works is vital to whether a project owner will consider the solution acceptable, then the productowner needs to specify that.
So if it's critical in this mythical product that passwords are reset by answering a security question rather than in some other way,
than the projectowner is allowed to say so.