Tls cert authentication and token renewal

I’ve been using vault tls cert authentication for a good long while, but always in a situation where the client retains the logic cert/key for the duration of the transaction. Recently I was playing with some different workflows and I discovered that the api for /auth/token/renew-self and /auth/token/renewwhen used to renew a token issued from the tls cert auth backend REQUIRE that the client is in possession of a cert/key pair that is valid.

AFAIK this is the only backend which requires, what amounts to, re-authentication in order to renew an already issued token. Is this intentional? I can’t find any mention of this behavior in the documentation.

Presuming that this behavior is intentional can someone explain the rationale for this? Can we get some documentation updates to reflect this behavior?

It seems weird to me that I could authenticate with approle and pass off the token as a bearer credential to some other process and that token could be renewed as needed/allowed without also giving my approle secret to the subprocess, but if I want to do the same thing with tls cert authentication I cannot pass off the token and presume the subprocess can renew it regardless of the settings on the token, acl policy associated with it and configuration of the cert authentication backend.

TIA for any response

This is not the only auth method that has “re-authentication” requirements for renew - another example is LDAP, where renewal triggers an attempt to rebind to the LDAP server using the password that Vault stashed away internally at initial login.

I do agree with you, though, that this functionality is both inconsistent and severely under-documented.