Policy Authorization Time Intervals
In working with policy authorizations, four distinct time intervals must be considered. These are implied by various sections of the specification but not specifically delineated:
• Build Entity Policy time: The time interval when the authPolicy used to create an entity is built. There are two ways to create this authPolicy:
• Software can replicate the policy calculations done by the TPM.
• A trial policy session can be created. The policy commands used to generate the policyDigest are sent to the TPM. During a trial policy session, all assertions pass; the purpose of the trial policy session is to generate the policyDigest as if all the assertions passed. After all the policy commands are sent to the TPM, the policyDigest can be read from the TPM using the TPM2_GetPolicyDigest command.
■ Note policies may be, and often are, reused for creating multiple entities and for authorizing many actions.
• Create Entity time: The time when the entity is created. If the entity will use an authPolicy, the policy digest created at Build Entity Policy time is used to create the entity.
■ Note Because an entity's name is created at Create entity time, the policy digest input when creating the entity (for example, authDigest) can't include the entity's name.
• Build Policy Digest time: After a policy session is started, during this time interval, policy commands are sent to the TPM in preparation for a command to be authorized. These commands cause the session's policyDigest, which is maintained inside the TPM, to be hash-extended with policy command-specific values.
• Authorization time: The time when the command to be authorized is sent to the TPM. At this time the session's policyDigest must match the entity's authPolicy, and any deferred assertions must pass.
To summarize, a policy calculation is usually performed twice—once at Build Entity Policy time and once at Build Policy Digest time: 
• The first time is to create a policy hash used as the authPolicy
when creating an entity.
• The second time occurs before authorizing an action on an entity: a policy hash is built up in the session context inside the TPM. When the command to be authorized is executed, the session's policy hash is compared to the authPolicy of the entity. If they match, the authorization is successful.
All policy commands do two or three things, and they do these things at the following time intervals:
• They check a condition or conditions (the assertion). This
is done at Build Policy Digest time (immediate assertion) or Authorization time (deferred assertion), or some combination of the two (combined assertion).
• They hash-extend the current session policy digest with policy command-specific data. This is done at Build Entity Policy time and Build Policy Digest time.
• They may update other session state. This session state is used for deferred or combined assertions to indicate what deferred conditions should be tested at authorization time. These updates are done at Build Policy Digest time.
Now that you understand the various time intervals, let's look at a typical policy session lifetime.
-  It should be noted that in some cases, a single real policy session can be used to generate the policy for both the creation of the entity and authorizing actions within the session; in this case, the policy digest is calculated only once. For instance, the following sequence would work: start a real policy session, send the TPM2_PolicyLocality command, get the policy digest, create the entity using the policy digest, and authorize a command using the policy session. This reverses the usual order of creating the entity and then starting the real policy session. It probably isn't very useful for most normal uses, but an understanding of this provides insight into how policy sessions operate. This only works for cases where the policy assertions can be can be satisfied before the entity is created.