Yes, and this should be the default. Most applications only need enough information to sign a user in and create the correct application context.
For ordinary sign-in, request only ordinary scopes. The existing guidance recommends openid profile email alias:read:public for the great majority of applications.
A user can sign in through an alias. In that case, your application does not receive the user’s Core ID. It also does not receive the KYC status or trust score attached to that Core ID.
Sensitive information requires a separate permission. Reading KYC status and trust score requires core:read:sensitive. It must be requested explicitly and granted by the user.
Do not request sensitive access “in case it becomes useful.” Every additional permission can reduce trust and creates information that your company must protect. Ask for it only when a real product, regulatory or risk requirement exists.
Design for the privacy-preserving route first. If your application can work with an alias and a portable badge, avoid requiring the Core ID. This gives the user a clearer privacy boundary and gives your business less sensitive data to manage.
The practical test: If you cannot explain to a user why the application needs a sensitive permission, the application probably should not request it.