Collecting metadata at registration?

[sgrannan]

Suppose a company has a registration page that includes some additional information they want to collect from the user. Things like desired product, number of items, and other preferences are included on the registration page. There would be a need to collect and use this information just once, for a downstream process.

Ideally, the metadata_public seems like a good place to put this data, as the data is not relevant nor sensitive much further past registration. Additionally, we don't want to have a multi-step process that feels cumbersome to the user with too many clicks. Ideally just one page to collect everything. Unfortunately it seems like designing a trait appears to be only way to persist this data considering that the metatdata fields cannot be accessed by the "self-service" client APIs. The user would not necessarily be authenticated at that point; so we don't have access to our server API that could send payloads to /admin/identities endpoints.

Do you have any suggestions on how to get this information into the identity profile other than as a trait? Is there something I'm missing with the implementation of metadata_public that might allow us to ingest this information through the client APIs?

[vinckr]

Hello @sgrannan
I would say best practice is to only put "authentication relevant" data in the identity and save all "business relevant" data in your application backend.
You can use webhooks for that.
So you save this additional data in your backend and use the id to associate it with the identity. There are multiple ways to solve it, it depends on your exact use case how you do it.

See here as well: https://www.ory.sh/docs/kratos/manage-identities/best-practices

I use this webhook payload for example to create a new user in my business logic backend when there is a registration:

function(ctx) {
  id: ctx.identity.id,
  created_at: ctx.identity.created_at,
  name: ctx.identity.traits.name,
}

[sgrannan]

Hi @vinckr

We actually already do just that. However, we are refactoring our Sign Up process and need to collect a few more bits of information up front that are only relevant to the product offerings seen at registration. Because its during the registration flow and before verification, the user is not authenticated so this information cannot be passed to our backend API. We must avoid having to allow unauthenticated access to our backend API, specifically just for this metadata.

So that is why I thought it really only leaves us with one option, place the data into a trait of type Object, with certain properties. However, that makes it part of our identity at that point. I was hoping to make use of the metadata_public but I could not see a path forward due to that field only being accessible from the /admin/identities endpoint, which is only accessible via our internal network.

If there was another path forward to get metadata into our system during the registration process and before verification, without making it a trait any additional suggestions would be welcomed!

Thanks for the quick response