Hello. Is there reasoning behind the recommendation that Kratos schemas include "significantly less" than 15 properties? I assume this is some sort of indexing or mapping limitation? Also does it apply to sub-properties or just top-level properties? https://www.ory.sh/docs/kratos/manage-identities/best-practices#keep-your-data-lean

I guess the reason is that you usually want to introduce as little friction as possible into the registration process. Also Ory Kratos is not really intended as a "datastore" - so if you find yourself adding all sorts of "non-authN" related data to the schema it would be better if you safe that outside of Kratos in a real database. Once the user is authenticated you can fetch other profile information from an app database - that is much faster and easier to manage and wrestling the data out of the identity schema. The number 15 is more or less arbitrary - actually I would recommend you only have the email and credentials in the identity schema unless there is a good reason to add more. Does that explanation make it clearer?

@magnificent-energy-493 It does, but I find this a bit counter-intuitive. We're working on standardizing our schema, and adding some basic demographics to match what's normally in OIDC userinfo (e.g. phone, name, email, birthdate, gender..) . Nothing too crazy. Would you really suggest that we need to create a separate datastore for such basic identity information? I guess from the perspective of "do AuthN/AuthZ" and nothing else that makes sense, but it complicates architectures significantly

Do you ask all this information in the registration process (e.g. phone, name, email, birthdate, gender..) ? So do I need to input this all to create an account? Or is it added in a second step? What you listed there seems reasonable, you could definitely also put that into Ory. However one common problem is that the search functionality right now is limited - we are working to expand this so you can also search through traits and so on. But right now if you for example want to find all users who have a birthday in May, you would have to get all the users full identities from Ory and search through those - there is no API that lets you search through traits at the moment. Again improved search APIs are on the roadmap, but it might take a while until its available for you in prod.

No they are not required at registration, in fact we use a subset of these properties for each project (tenant). But they will be required for a users profile. If we're building a UI for that profile, we then have to make 2 different requests to get that information. The searchability is a challenge for sure, but isn't as large a concern for us at the moment. We're just trying to pin down the MAXIMUM set of data we would store in the schema, then pare it down from there. Things like addresses are hard (since they are multi-field, etc), and would be a candidate for a secondary storage for sure.

I see - afaict traits would all show up in the registration form unless you build a custom UI that does this in multiple screens.

If we're building a UI for that profile, we then have to make 2 different requests to get that information.

I think in the end you do have to make 2+ requests anyway, if you store e.g. the address somewhere else? Maybe I am missing some details here - but the info you shared (phone, name, email, birthdate, gender) you can put that in the Ory Identity schema for sure, that is very basic stuff 🙂

Ah ok, so even though birthdate/gender is not really auth related, it's still "OK" as long as the dataset is smallish? I'm trying to avoid writing another service to manage the user data is all. Thanks for clarifying, I guess I took the initial comment a little to the extreme 😄

No problem 😄 In the end it's all "OK", the schema is super flexible after all. The biggest constraint is the searchability - that alone is often a reason not to put something like birthdate/gender in the identity schema. If you don't see any problems with not being able to do DB operations on this sort of data easily, then go ahead!