A more general question; if you can create custom IDs also with verification information, and use encryption outside of the database, would that also be an option? It would be a longer process but it might be easier for your use case in the end.

… use encryption outside of the database …

Are you suggesting to encrypt the trait values before they get to Kratos, and decrypting when after fetching the identity? (just jumping in here because I’m also interested in security features)

Kratos secret usage and rotation isn't (IIRC) the same kind that you'd typically use for this and I don't think they'd want to write their own version of vault or whatever. Nothing would stop you from storing "someSecretId" in your traits and then fetching an encrypted secret from some managed secret service in your own app: vault / aws secret manager / gcp secret manager / etc.

Great point @white-lighter-75036. Since heading down the path of Kratos I’ve come to find we had a lot of junk hanging off the User model. Not everything needs to be in the Kratos identity.

I think what you're suggesting is: • in a before or after registration hook, store the customer data • update the kratos traits (cant use hooks to manipulate/mutate the flow data) • when obtaining traits youd need to always request this extra data separately I think this would be a bit pointless as it would be easier to just request user data via user ID after and not have any in traits. That's unfortunately what I'm considering but with the data being in traits would be really useful (first/last name for sure, email not necessarily) as it's rendered on every page in my SPA. I'm also considering adding an extra cookie but unsure if that's possible via hooks. Regardless, if I have multiple registration fields and I want to split them across tables, right now it looks like partial data is saved if any hooks fail to save the data, but an account is created if kratos does store the account details. If kratos provided an optional url to allow us to store data as we see fit (and if identities arent saved correctly that's our fault) it would provide much more flexibility and robustness. RE encryption with secret managers, I wouldn't want any UI being able to request keys to decrypt data themselves. It makes me uncomfortable; doing it in the backend for a logged in identity for their own traits makes much more sense to me since it's their data - the encrpytion is a) a last line of defense against db compromise b) providing limited data visibility to staff. I hope this all made sense? Full data: Registration form is for companies It includes company name/number customer first/last names customer email (also log in identifier) marketing acceptance registration is manually verified - we check the company is not only legit, but suitable for our application. we also check a few other things for pre-approval checks to connect with other companies one form should easily save data to tables: company, identity (account info), customer Right now, traits have to be json in the identities table. if instead kratos offered post/get functionality it would make things far cleaner: I could store company_id, first_name, last_name, company_name and then would not need to request this on every SPA load up. Further, I wouldnt have to add hooks for registration, settings & profile management.

Hey @adorable-byte-96872 I love your ideas here. Would you be open to start a discussion on GitHub with the ideas from this thread? https://github.com/ory/kratos/discussions/new On Slack these things tend to get lost after a while and I think this could be valuable input for the maintainers and community in general!

Hi Vincent, yeah sure I'll do that now. It