A transaction includes commitments of created resources and nullifiers of consumed resources. If we have access to the transaction data, we know the nullifier. More than that, the party that creates logic proofs, also creates compliance proofs. One of the checks included in the compliance proof is the proof of the correct nullifier computation, which requires the knowledge of the nullifier key. So from the perspective of knowledge it is sorted.
Another question is the function signature. From the specification perspective it isn’t a problem as it currently defines the resource logic inputs as:
Resource Logic Public Inputs:
- nfs \subseteq nfs_{tx}
- cms \subseteq cms_{tx}
- tag: \mathbb{F}_{tag} — identifies the resources being checked
- extra \subseteq tx.extra
Resource Logic Private Inputs:
- input resources corresponding to the elements of nfs
- output resource corresponding to the elements of cms
- custom inputs
which certainly allows to pass some private data securely, if we are talking about the shielded case. And whatever works in the shielded case must work in the transparent case as well