The format for the claim value, with $VAR or ${VAR} substitutions. JENKINS_URL is always defined; in builds, see environment variable reference. Example: jenkins:${BRANCH_NAME}:${BUILD_NUMBER}

Warning: think carefully about which claims you are offering and why. If a relying party is making access control decisions based on claims, you should ensure that the values cannot be spoofed by a malicious impostor. For example, ${JOB_NAME} is defined by Jenkins and cannot be overridden by a pipeline, so a JWT claim using this variable indeed proves that the JWT was issued by Jenkins for that job. For example, you might permit deployments from the repo/main branch project but not feature/PR branches, and the claim value can be used to enforce that. (${BRANCH_NAME} for a multibranch pipeline is also defined by Jenkins and cannot be overridden by a pipeline, though on its own it does not prove that the pipeline is running in a specific repository—just the branch name.) SCM-specific variables such as ${GIT_BRANCH}, by contrast, are set while the build runs according to actual source code checkouts. Thus any build of any job could check out the main branch of some other repository and receive a JWT claim with ${GIT_BRANCH}, ${GIT_URL}, etc. set to whatever the pipeline author picked. Such claims may be useful for troubleshooting or (under certain circumstances) auditing, but they should never be used for access control.