Browser flow: how to register identity with different traits

ORY Kratos
#1

My application require user with different role to access the application. Kratos documentation states that Kratos support identity roles with traits feature, which mean identities can have different traits. (public, staff, admin, etc)

Current Admin API support creating identity with different traits by using “traits_schema_id” parameter on identity creation endpoint.
Since currently impossible to create identity with credential using Admin API, the only way to create identity with credential is through browser flow registration, but it seems browser flows registration endpoint didn’t allow us to choose “traits_schema_id”, it always use theidentity.traits.default_schema_url

Is there any solution to create identity with different traits (role) using browser flows?

#2

Good question! That is indeed currently not possible. The problem is that we don’t want users to be able to choose their schema, because a user could maliciously say: “oh yeah I am support staff!”. We haven’t figured out how to make this flow secure while also allowing different traits, but it’s definitely on the radar. If you want, you can create an issue on github so this problem is also tracked there!

#3

I see, Admin API prevent us to register user with credential, while Public API prevent us to choose trait for registration. I think the solution is to allow Admin API to create user with credential or maybe just a temporary credential.

#4

Yes, that will be the case in future versions of ORY Kratos!

#5

Anyway, what is the real usage of request code in browser flow registration? CMIIW, I see it sole purpose is to allow server-side application to request registration context payload from Kratos Server based on that request code.

If it so, I think could move that feature to Admin API, and the browser flow will be like this:

  1. Browser initiate registration process by visiting server side application path (not directly to Kratos server) for example : www.serversideapp.com/registration
  2. Server-side application, using Admin API, send registration/login request to Kratos Server and get the request code.
  3. Using the request code, server-side application can get form data from Kratos server.
  4. Server-side application render the form data and display it to browser.
  5. Browser POST the form to Kratos server
    (we can merge step 2 and 3 into one step)

This way, server-side application can decide which trait to use before sending registration request to Kratos server (step 2), and Kratos server can response with proper form data based on requested trait.

We can also use that server-side application path (step 1) as invitation link by adding invitation code parameter for example www.serversideapp.com/registration?invitation_code=xxxx, which in turn it will be used by client application to decide which trait to be use before request registration to Kratos server.

#6

Yup that sounds like a great idea! I think that presenting some type of verifiable token at the Registration Initialization Endpoint would be the right choice!