In what's turning out to be the third in an unplanned series on Geneva-related terminology, I'll describe what a bootstrap token is. You are likely to come across this term as soon as you try to delegate identities from front-end services or Web sites to back-end systems. When a request containing a SAML token is handled by a front-end Web site that has been configured to use Geneva, the framework will convert that token into claims and put them in a cookie (or cookies), allowing them to be reused during the session. Similarly, when a request is presented with a SAML token to a front-end WCF service that uses Geneva FX, the framework will convent the SAML token into claims and put them in a Secure Context Token (SCT) to be used for the lifetime of the session. With these claims, the front-end Web app or service (RP) can make authorization decisions about whether or not the caller is allowed to perform an operation, see a particular page element, or whatever.
This is good enough until the front-end has to call a back-end system as the original user. To do this, the front-end needs to provide an STS with the original caller's token. Unlike the claims implementation initially provided with WCF, the Geneva Framework keeps the original SAML token around for just this purpose. When the front-end RP needs to retrieve a delegation token or ActAs token, as it is also called, it switches from the role of the RP and takes on that of the subject in the familiar WS-Trust communication triangle. When it does this, it needs to provide the STS with the token of the original caller in the RST sent to the STS. The original token that the front-end received is what is referred to as a bootstrap token because it is sent later to the STS to get an ActAs token when bootstrapping the delegation process. This process is shown in the following sketch.