|PolicyKit Library Reference Manual|
Typically the entities that a Mechanism cares about can be split into three groups:
Subject: the entity requesting the Action; ie. an unprivileged application. To make a decision about whether to carry out the Action, the Mechanism needs to know as much about the Subject as possible, e.g. UNIX user id, UNIX process id, possible security attributes (such as SELinux security context) and other data such as if the Subject is a participant in a local or remote desktop session, whether said desktop session is currently active and so forth.
Object: some canonical representation of the Object; some Objects represent tangible things such as a UNIX device file, other Objects can be more abstract and represent e.g. a network connection to a specific destination, a reference to the power management subsystem, a reference to a piece of software tracked by the native package manager.
Action: what the Subject is attempting to do to the Object; this depends of the nature of the Object and examples include mounting a block device, formatting a block device with a file system, establishing a dial-up connection to connect to private or public networks, putting the system into a suspended state, installing an unsigned piece of software, updating the system with signed software, changing the timezone, gaining access to a webcam and so forth.
One way to think about a Mechanism is that the Mechanism is split into an enforcer and a decider component. When an application attempts to access the Mechanism, the enforcer component will only carry out the Action if the decider component (supplied with the appropriate input parameters about the Subject, Object and Action) says it's OK.