Issuing of the new (requested) token

The new token is generated.

Procedure

Use the default Implementation.
The default implementation of token exchange generates an opaque access token, and a refresh token (optional). To execute the default implementation, at the end of pre-mapping rule execution, ensure that access_token context attribute type, urn:ibm:names:ITFIM:oauth:response:attribute does not exist.
Note: Since the subject_token can be any kind of token (SAML, IvCred, JWT, opaque, STSUU, LTPA), the default implementation will require you to extract and set the username that will be associated with the issued access token. This username will be the sub of the opaque access token. Do the following:
```
var username=<extracted from subject_token>;

stsuu.addContextAttribute(new com.tivoli.am.fim.trustserver.sts.uuser.Attribute("username", "urn:ibm:names:ITFIM:oauth:rule:decision", username)); 
```

Use the STS Chain to issue token.

Use the STS Chains to issue many kind of tokens. Verify Access supports issuance of token like IvCred, SAML, STSUU, JWT. For more information about creating STS Chain, see Configuring STS modules.

To use the STS Chain to issue the token, refer to the following example:

var rsp = LocalSTSClient.doRequest("http://schemas.xmlsoap.org/ws/2005/02/trust/Issue",
    requested_token_type, // Based on the 'requested_token_type'
    target, // Based on the 'audience' or 'resource' requested
    base_element, // claims for the issued token
    null);

You can determine the issuer and appliesTo of the STS Chains as required. You can set the issuer as the input requested_token_type and set the appliesTo as the `audience` or resource input parameter.

After you issue the new token, set the following context attributes so that the default implementation will not be executed and uses the issued token in Javascript.

stsuu.addContextAttribute(new Attribute("access_token", "urn:ibm:names:ITFIM:oauth:response:attribute", issuedToken));
stsuu.addContextAttribute(new Attribute("issued_token_type", "urn:ibm:names:ITFIM:oauth:response:attribute", requested_token_type)); // set it to appropriate value
stsuu.addContextAttribute(new Attribute("token_type", "urn:ibm:names:ITFIM:oauth:response:attribute", "Bearer"));
stsuu.addContextAttribute(new Attribute("expires_in", "urn:ibm:names:ITFIM:oauth:response:attribute", "3600"));

Optional: Persist issued token into Token Cache table.
By default, if you issue a token in the pre-token mapping rule, it is not stored in the token cache table. The main reason is that the token that is produced might not be OAuth/OIDC token. Since it is not an OAuth/OIDC token, OAuth/OIDC will not support such token introspection or revocation, so there's no point to store it into token cache.
However if you choose to do so, you can do the following:
```
stsuu.addContextAttribute(new Attribute("urn:ibm:ITFIM:oauth20:custom:token:access_token", "urn:ibm:ITFIM:oauth20:custom:token", issuedToken));
stsuu.addContextAttribute(new Attribute("urn:ibm:ITFIM:oauth20:custom:token:access_token", "urn:ibm:ITFIM:oauth20:custom:token:persistent", "true"));
stsuu.addContextAttribute(new Attribute("issued_token_type", "urn:ibm:names:ITFIM:oauth:response:attribute", requested_token_type)); // set to appropriate value
```
This way, the default implementation will be executed, however it will not generate opaque access token, but use the custom token provided.
Note: The token cache table column size may not fit to store a lengthy token. You can workaround it by enabling the hashing when storing the token.
Optional: Issue the refresh token as result of token exchange.
This is a unique scenario, when the requested_token_type is urn:ietf:params:oauth:token-type:refresh_token, it is not advisable to generate your own refresh token in the Javascript. What you can do here is to let the default implementation to be executed but then you need to set the following context attribute to generate refresh token.
```
stsuu.addContextAttribute(new Attribute("issued_token_type", "urn:ibm:names:ITFIM:oauth:response:attribute", requested_token_type));
```
Track actor information.
As part of the delegation scenario, we need to track the chain of actors for the issued token. Some token like JWT or SAML can easily contain such information inside the token itself. However for the opaque token, it is tracked inside the EXTRA_ATTRIBUTE table. The tricky part is this actor information can be nested, and EXTRA_ATTRIBUTE column size is only 256 characters. So, when storing the actor information, it will be stored as multiple indexed keys act:<idx>.
For example, the "act" claims is:
```
{
    "act": {
        "sub": "https://service16.example.com",
         "act": {
             "sub": "https://service77.example.com"
         }
     }
}   
```
The oauth20_token_extra_attribute will be stored as:

state_id attr_name attr_value

id act:0 https://service16.example.com

id act:1 https://service77.example.com

Verify Access provides a special utility to store and retrieve actor information from EXTRA_ATTRIBUTE table.

See: OAuthMappingExtUtils.storeJwtActor(String act, String stateId) and OAuthMappingExtUtils.retrieveActor(String stateId). However the support currently limited for JWT token.

For other token type, the specification does not clarify how the actor is going to be represented. For token type like IvCred, for example, which is only key value pair, probably you can represented is just like using indexed keys as well.

`state_id`	`attr_name`	`attr_value`
`id`	`act:0`	`https://service16.example.com`
`id`	`act:1`	`https://service77.example.com`