This is not application-specific and defined on the resource machine instantiation level.
For example, in Taiga the nullifier key is randomly generated. The user generates a nullifier key, computes the nullifier public key and shares the nullifier public key with the solver so that the solver can create resources for the user.
I think you can implement kudos as both shielded or transparent application, “lower security” mostly refers to the way you instantiate the resource machine, not the way you develop your application, because with a higher security properties instantiation you still can write both transparent and shielded applications, which is not the case for purely transparent instatiations
So there are some resource fields that can be related to the application (e.g., logic, label, value, quantity) and some fields that don’t make that much sense in that context (e.g., npk, eph, rseed). The nullifier public key in particular is independent of the application logic and its distribution is not fixed in the protocol (the user might publish their npk once, might change it every 5 minutes, might deliver different npks to different solvers, combine all of these options, etc), so this is not something to rely on designing the application logic
For simplicity I would see as resource fields that make sense to consider writing the application:
- logic: constraints
- label: fixed per kind data
- value: volatile data
- quantity: either by having variable quantities as a meaningful part of the application or just employing the balance mechanics to enforce constraints
- eph: for balancing and ephemeral resources - the ones we create and consume in the same transaction
The rest (nonce, rseed, npk) - not really. Some applications designed for a concrete RM instantiation might take advantage of those in some way, but I don’t think this is something we need to think about