AIK has actually been generated by the particular TPM in question. Upon success, the PCA generates the credential $\text{Cert}(\text{AIK},g)$ certifying that the AIK belongs to group $g$. The credential is transferred back to TA, where finally the `TPM_ActivateIdentity` command is executed to enable subsequent usage of this AIK. The process is shown on the left hand side of Figure \[fig:Ticket\_Acquisition\_Redemption\].

Redeeming a ticket is now very simple, as shown on the right hand side of Figure \[fig:Ticket\_Acquisition\_Redemption\]. TA has first to generate a CSK[, [i.e.]{},]{}a public/private key pair and the credential $\text{Cert}(\text{CSK},\text{AIK})$ for it according to the process described in Section \[sec:AIKTickets\]. He then signs a certain payload, $P$[, [e.g.]{},]{}describing a service request, with CSK to obtain $\text{Cert}(\text{P},\text{CSK})$. The payload and the credential chain $\text{Cert}(\text{P},\text{CSK})$, $\text{Cert}(\text{CSK},\text{AIK})$, $\text{Cert}(\text{AIK},g)$ is then transferred from TA to RS and this set of data embodies the ticket proper (we do not discuss a particular data format for the ticket). RS verifies this chain and makes an authorisation decision, for instance to implement a protection against multiple spending. Finally, RS acknowledges receipt of $P$ and optionally initiates another charging operation (ex post charging) via PCA.

A Generic Architecture for Service Access {#sec:GenArc}
-----------------------------------------

The embedding of 