Tickets are acquired by a *trusted agent* (TA)[, [i.e.]{},]{}the user of a ticket system and associated services operating with his trusted platform, from the PCA. They are then redeemed at the *(ticket) receiving system* (RS). In both processes, a *charging provider* (CP) may occur as a third party, depending on application architectures. We now describe how these operations proceed.

Note that we do not distinguish between public and private key portions of a certificate establishing a credential. As a notation, the credential of some certified entity $\text{Cert(\textit{entity}, \textit{certificate})}$ means the union of the public key $\text{Pub(\textit{certificate})}$ and the entity signed with the certificate’s private key, $\textit{entity}_{\text{Priv}(\textit{certificate})}$. Verifying a credential means to check this digital signature.

An interesting option is that the credentials issued by the PCA for a AIKs can be designed as *group credentials*[, [i.e.]{},]{}they do not identify a single AIK *viz* ticket but rather its price or value group $g$ chosen from a predetermined set indexed by the natural numbers $g\in\{1,\ldots,G\}$. The group replaces an individual identity of a platform and many TAs will get the same group certificate. Only the PCA can potentially resolve the individual identity of a platform. This allows for the combination of a 