Hi Lyndsey! Sure, but first, it’s important to note that, even in the case of a long-lived periodic token, you wouldn’t want the TTL of the response-wrapping token to match it; this is one of the key benefits of response-wrapping, as outlined in HashiCorp’s documentation: regardless of the secret/token being wrapped, you can limit its lifetime in the event that it doesn’t reach its intended recipient.
So, as an example, I could create a periodic token for use as part of my automated Consul gossip key rotation, with the limited privilege of being able to read a secret from a specified path. As designed, this token should be used by consul-template to read the encryption key from Vault, and, if it’s changed, to add that key to Consul’s keyring, and remove all the old ones.
If my risk assessment suggested that passing that periodic token over the wire might put it at risk of interception, I would probably just configure TLS between all my nodes. But you can imagine a scenario where it might not be practical to have verifiable certificates at all endpoints. Response-wrapping that periodic token could be one solution, providing it cover (and tamper detection).
This is actually a point where your two-use token would not provide the same utility: there’s only one TTL associated with it, whereas, I could put a TTL of an hour on my periodic token, and then, regardless of how long it’s supposed to be valid, if consul-template doesn’t unwrap it and use it within an hour, it would expire.
Another example might be the DR operation token needed to promote a secondary cluster to primary in the case the latter’s total failure. In the wrong hands, this is a denial of service threat, and so you’d want to provide all the properties offered by response-wrapping in many environments.