I'm not following how that would address the concern here?
CA Access Gateway is controlling the user info and token exchange endpoints. So it's reliant on (1) CA Access Gateway being able to require a layer in addition to just a bearer token [all it needs oob is the access token], and (2) the client app/RP to have a valid issued client-auth certificate [with appropriate policy OIDs].
Layering a bearer token on top of another bearer token (i.e., SMSESSION + OIDC) is still all bearer tokens with no specific verification of the calling client. So the concern around passing back higher rated user information by simply having that token is still not addressed; especially when considering exposing it externally. Also the userinfo endpoint just needs the access_token, don't think it knows anything about SMSESSION.
Intention here would be that a compromised OIDC access_token would not provide any specific access to the userinfo endpoint on the CA Access Gateway. Since if TLS client-cert auth is required, to compromise that they'd have to get hold of the private key (which could be stored in an HSM etc) in addition to the bearer token; either one by itself would do no good.
Overall the goal, for us at least, is to lock down as much authentication as possible to client-cert auth (or at minimum short-lived PKI cert signed requests). That includes touch points to APIs, users to authentication services, etc.
At the very least if I could require the UserInfo endpoint to need both the (1) access_token granted by the user and (2) client id + client secret, that would probably be adequate enough. Based on the documentation, I didn't see that even this was possible and the currently accepts just the access_token. Having only the access_token doesn't authenticate the client sending it.