There are many systems, especially STS/federation systems, that do it this way:
- one claim that describes the user uniquely
- assortment of claims describing general conceptual things they (and others) have access to
The user's "profile" data within the app may not translate to/from the authentication source you are using and you may not use the same endpoints at all times or all users.
If you were familiar with the old Forms authentication it is analogous to the username & roles model and a lot of the built-in stuff still looks like that if you use System.Security.Claims.ClaimTypes of name and role appropriately.
Neither the old or new model gave you much out of the box for claim or role inheritance, but that is not particularly difficult to implement and implementing it lets you cut down on the volume of claims or roles that you need to keep in play from request to request.
If your application needs to keep track of a birthday, but does not need to use it in a security mechanism then there really ins't any benefit in keeping it in the claim collection. Put it in a separate profile dataset or something.
If your application needs to get the birthday as a claim from another system then you are looking at something more like customizing the federatedAuthentication or allowing the extra claim to persist.