It only makes sense when there is a receiver who sets up a receiving policy \rho. In the kudos design, for transferring with conditional receive and the kudos-to-anything cases (which both use signatures, I think).
Sorry, that was a typo. I meant the generation of \sigma happens offline. (e.g. the generation of the signature). For signatures, it is not enforced that the signature is generated correctly. But for the PRF it is (it is a side effect: the verification of the authorization consists in verifying a zkp of correct generation. But not that I wanted to enforce correct generation explicitly).
For example, the receive authorization logic of the proposal. I presume it will be a circuit or a SNARK verifying key. In order to pass it through a PRF (or sign it) it needs to be interpreted as a bunch of bits/bytes. The bitlength of the circuit/verifying key must fit in the domain of the PRF (or in the domain of the messages to be signed).
This has to do with this issue. Therein, I think you were concerned about re-using signatures of policies with the same public key. Like re-using the signature of a revoked policy. Translating to the PRF, re-using an evaluation eval = PRF_s(\rho_{rvk}) for the same address addr = Commit(s;r).
For signatures, putting \sigma (the signature) as part of the instance leaks the policy \rho that is signed: just try to verify the signature using different policies until a match is found.
For PRFs, putting \sigma = PRF_s(\rho) in the instance does not leak \rho, because \sigma is pseudorandom as long as s is not known. So, we can revoke policies by including \sigma in a public list, and during verification check \sigma is not in that list.