Hi, We are facing interesting OIDC challenges regarding sparsely featured OIDC implementations. One RP has an oAuth2 based implementation that never accesses the UserInfo endpoint because (I freely quote the code comment) "They already have everything they need to know from the id_token". It turns out, Google bloats their id_token with claims so they reduce (effectively prevent) requests on the UserInfo endpoint. It seems more and more RP's start to assume the token endpoint will deliver everything they need or at least enough in the id_token. We have decided to go along with the Googles of this planet and bend. Now, pyop doesn't normally enrich the token endpoint id_token, but has a parameter to consume extra_id_token_claims, just like the authhorizatoin enpoint. From a satosa endpoint however, I have no access to the interal_resp from the user to enrich the token endpoint. sastosa handle_authn_response does set the authz database with the extra claims (consumed by userinfo endpoint I guess) but I have no way to know the key (userid) to reliably access these claims on the token endpoint and pyop doesn't have a authz code to userid converter, as far as I know? The best way I see, would be to modify pyop to enable internal (Provider scope) extra_id_token_claims in the token endpoint. But we don't want to maintain yet another fork in our deployment. This means that I'm allowed to make a PR, but only if I have IdPy's commitment to merge the changes back upstream. Question: did I miss an option in pyop config that already does this? Or has somebody already started an effort to implement this? If not: is IdPy willing to merge this enhancement if I created a PR? Best regards, Martin