§7.2 of CIBA draft in bitbucket and §4.2 of the published version have the following text regarding validating the provided hint in the authentication request.
The OpenID Provider MUST validate the hint provided (login_hint, login_token_hint or id_token_hint). e.g.: If a signature is provided it MUST be checked. If a validity date is provided it MUST be checked. If the hint is not valid or if the OP is not able to determine the user then an error should be returned to the Client as per section Authentication Error Response.
Such validation doesn't really make sense for login_hint so it should probably be omitted for the MUST here. Perhaps it could by said elsewhere that if the login_hint value isn't recognized by the AS/OP then return an error. But I think the requirements for checking each different hint type should be have separate treatment in the draft.
For id_token_hint in particular this validation requirement is very problematic as an ID Token is issued for a different context to a different audience and typically with a shortish validity period. Whereas a CIBA client might reasonably want to use an ID Token received days or weeks or more ago as an id_token_hint value. Such an ID Token would be expired and not have the AS/OP as an audience. It's possible that, due to key rotation, the AS/OP doesn't even have access to the the keys to check the signature. OIDC core kind of touches on the issue by saying the AS need not be listed as an audience of the ID Token when used as an id_token_hint value. The id_token_hint from OIDC core isn't the most clearly defined parameter to begin with and while CIBA defers to OIDC for it's definition the usage is somewhat different. But potentially more important to a CIBA flow. As it is, consistent, interoperable, or useful treatment of id_token_hint seems unlikely. I believe that the id_token_hint should be considered simply a hint only and that it should not be validated.
Validating the login_hint_token does make sense as it is presumably issued for this purpose. That requirement should just be stated separately from the other hints.
I just noticed that the text quoted above uses login_token_hint while the rest of the document uses login_hint_token, which should be fixed.
It would also be nice for implementations and profiles other than MODRNA that want to use CIBA, if the login_hint_token was defined more generally as a JWT that's content identifies the end user whom to authenticate in the background rather than deferring to OpenID Connect MODRNA Authentication Profile 1.0. I think, after reading the login_hint_token text from that profile, that the login_hint_token can be a plain old JWT. But I think its use in CIBA would be easier to understand if the text in CIBA said something to the effect that it is a JWT/token used to pass a hint about the user into the authentication process and then point to the MODRNA profile as one example of such.