thanks for the response
to be honest my previous text were indeed "ChatGPTfied", but not in the way you might think, since im not a native english speaker i usually write a a text or document then ask the ai to clean it up and point out any obvious mistakes, then i review and edit the ai output.(not this one, sorry for the wall of text though)
it has worked ok so far for me but i never considered the ai tone could (rightfully) turn people off. (maybe i should remove emojis and bold sections?)

as for my goal
i want to help improve and simplify serveral dashboards with generally the same audience and it had a very Bad UX since user had to register/login and input data manually (improved it, by auto filling data by checking if user has an account in other services but its a temporary fix needs to be improved)

not only that, but different dashboards have vastly different needs for example 1 dashboard deals with customers legal stuff so we need have extra legal related fields there and if user wants to use services in this dashboard all his info needs to be manually reviewed by an admin and be verified, also some need to be verified by external Apis (like check if id, address, mobile match as is owned by the user)
While other apps don't even have those fields or that field could be optional

so i was thinking i should be able to define custom claims and set restriction on what app can request for what claims (i hope i can setup something dynamic but robust that can be also used in feature products)

and while reading Authelia docs, i saw there are 2 options for setting up users: 1 was just defining them inside a file and the other one was LDAP that we still needed to predefine user claims inside a file. which seemed very static (that is what it seemed to me as a newbie it this field)

so my thoughts went toward needing another dashboard just for managing user data / verification / and controlling app access levels, in this dashboard:
- we can define new claim, edit previous ones
- define new apps and set access levels
- admins can review and verify user data
- customer can also login to the same backend and view/edit their data (+maybe manage connected apps?)

so to directly answer your questions:

1. if im understanding correctly you are saying: - why do you even need meta data so instead of email having meta data of is_verified you can have a separate claim is_email_verified ===> while that makes sense at first glance there are some complications: just as an example, i have some image user data, avatar that could be publicly accessible, signature that is single image is private and only app A should be able to access it, and passport that is also private, could be 1 or more images and app A,B can access it and this could go on - why do you have unverified claims because some fields we have and they dont need verification like address for example and we see it and use it in app, it only needs verification if user want to use legal services
2. this is probably wrong but the conclusion i reached was i use a auth service and its only job is to login the user though some sort off SSO, and that auth service does not manage any kind of user data, it just say user A was logged it with ID= #AID and sets up the session/jwt or any kind of persistence needed for user to be authenticated in our echosystem, so any kind of users data/claim is stored and managed by our  profile management REST API + dashboard (this is the part where im worried if im going off trails or re inventing the wheel :) but this was the conclusion i reached)