Assuming that a client always uses the email scope (for context).
The OIDC's ID Token documentation lists some claims that are used within the ID Token, like iss, sub, aud, exp, iat, but email and email_verified are not among the listed claims. However, it also notes that ID Tokens MAY contain other Claims.
Many services implementing OIDC, include the email and email_verified claims in the ID Token (like Google) when using the email scope. However, I would like to know if this is actually part of the standard, which would mean that OIDC providers are expected to always include the email and email_verified claims in the ID Token when using the email scope.
Or, if this is not really part of the standard, since the client could always ask the provider for the email claims using the userinfo endpoint (which lists email and email_verified as part of the standard claims).
So, is it mandatory for an OIDC compliant provider to always include the email and email_verified claims in the ID Token or is it sufficient to include them in the userinfo response?
Ideally the implementation should give control to the customer as described below.
RESOURCE ACCESS
If I use a scope of openid email then my access token can be sent to the OpenID Connect userinfo endpoint and receive the email and email_verified values in the response.
FRONTEND CLAIMS
I should be able to decide what goes into the ID token and optionally add email claims there when the email scope is used. There can be disadvantages to doing so:
The client gets more up to date information from the userinfo endpoint, eg if the email changes, rather than requiring the user to re-authenticate.
The client can unintentionally leak personally identifiable information, like the email, eg if it sends an id_token_hint in an RP-initiated logout (in which case the email is written to server logs and the browser history - unless you use encrypted ID tokens in the JWE format).
My preference is therefore to use the ID token only as proof of the authentication event, to describe how and when authentication occurred.
SUMMARY
The standard defines what is allowed, eg you can get email data when you use the email scope. How you receive that data should be up to you. Some authorization servers may give you better control than others.