One request is to allow for a single QDL script to be used in place of all token configurations.
Rather than have the cfg attribute of a client configuration be something like this (in HOCON/JSON):
tokens{
identity{
type=identity
qdl{
load="bgsu/idtoken.qdl"
xmd={exec_phase="post_token"}
}// end qdl
} //end identity token
access{
type=wlcg
issuer="https:cilogon.org"
audience="https://bgsu.edu/jwt/v1/any"
lifetime=3600000
qdl{
load="bgsu/at.qdl"
xmd={exec_phase=["post_token","post_refresh","post_exchange"]}
args=["USER_ID", "PASSWORD"]
} //end QDL
} // end access token
refresh{
issuer="https:cilogon.org"
audience="https://bgsu.edu/jwt/v1/any"
lifetime=3600000000
qdl{
load="bgsu/rt.qdl"
xmd={exec_phase=["post_token","post_refresh","post_exchange"]}
} //end QDL
}// end refresh
} //end tokens
You could have a driver script that is loaded for all phases and allow the script to dispatch the execution. The plus with this is, obviously, you manage the script and once set the client configuration never need be touched. The most important point is that the client cfg then is a single QDL invocation element:
qdl{
load="bgsu/driver.qdl"
xmd={exec_phase="post_all"}
}// end qdl
In this case, the driver script might start like
if[
exec_phase=='post_auth'
][
script_load('bgsu/idtoken.qdl');
];
if[
exec_phase == 'post_token'
][
// ... etc.
];
What this does under the hood is create a handler (id token, access and refresh with gerenic defaults) and sets the script to the single driver.
Each invocation of QDL requires marshalling resource, starting an interpreter etc., so while you may certainly request that the exec_phase be "all", there is apt to be an awful lot of extra work done
In the driver, load scripts do not run them, since the ambient scope contains all access tokens, claims etc. and script_run creates a new clean scope with none of that.