To set an identity schema where the phone trait can be used for recovery and verification, you would need to define the phone trait in your identity schema and mark it as a verifiable address via the

verification

extension. You would also need to mark it for recovery via the

recovery

extension. Here's an example of how to define such a trait in the identity schema:

json {   "$id": "<https://schemas.ory.sh/presets/kratos/quickstart/phone-password/identity.schema.json>",   "$schema": "<http://json-schema.org/draft-07/schema#>",   "title": "Person",   "type": "object",   "properties": {     "traits": {       "type": "object",       "properties": {         "phone": {           "type": "string",           "title": "Phone number",           "format": "tel",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "verification": {               "via": "sms"             },             "recovery": {               "via": "sms"             }           }         }       },       "additionalProperties": false     }   } }

In this schema, the phone trait is marked for verification and recovery via SMS. Make sure to configure an SMS channel in the Ory configuration for this to work. You can refer to the [SMS documentation](https://www.ory.sh/docs/kratos/emails-sms/sending-sms) for more details on how to do this. Source: [Phone number verification](https://www.ory.sh/docs/kratos/self-service/flows/verify-email-account-activation#phone-number-verification)

The error message you're seeing suggests that the current configuration of Ory Kratos only supports "email" as a method for account recovery. This means that the "via" field under the "recovery" property in your identity schema must be set to "email". Currently, Ory Kratos does not support SMS as a method for account recovery out of the box. You might need to implement a custom solution for SMS-based account recovery. Here's how you would set the "via" field to "email" in your identity schema:

json {   "$id": "<https://schemas.ory.sh/presets/kratos/quickstart/phone-password/identity.schema.json>",   "$schema": "<http://json-schema.org/draft-07/schema#>",   "title": "Person",   "type": "object",   "properties": {     "traits": {       "type": "object",       "properties": {         "phone": {           "type": "string",           "title": "Phone number",           "format": "tel",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "verification": {               "via": "sms"             },             "recovery": {               "via": "email"             }           }         }       },       "additionalProperties": false     }   } }

In this schema, the phone trait is marked for verification via SMS and recovery via email. Please note that you would need to ensure that the phone trait can also accept email addresses for this configuration to work. For more information on identity schemas in Ory Kratos, you can refer to the [official documentation](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema).

To see the claims returned by an OpenID provider, you would need to enable debug logging in Ory Kratos. This can be done by setting the

LOG_LEVEL

environment variable to

debug

in your Ory Kratos configuration. Here's an example of how to set the

LOG_LEVEL

environment variable in a Docker Compose file:

yaml services:   kratos:     image: oryd/kratos:v0.7.6-alpha.1     environment:       - LOG_LEVEL=debug     # ...

Once debug logging is enabled, you should be able to see detailed logs from Ory Kratos, including the claims returned by the OpenID provider. Please note that enabling debug logging will also log other detailed information about the operation of Ory Kratos, which might include sensitive information. Therefore, debug logging should be used with caution and only in a secure environment. For more information on logging in Ory Kratos, you can refer to the [official documentation](https://www.ory.sh/docs/kratos/debugging).

If there's an error in the Jsonnet code, it might prevent the claims from being logged. However, you can create a Jsonnet snippet that simply outputs the claims as they are. This can be useful for debugging purposes to see what claims are being returned by the OpenID provider. Here's an example of a Jsonnet snippet that outputs the claims:

jsonnet local claims = std.extVar('claims');  claims

This Jsonnet code will output the

claims

object as it is, allowing you to see all the claims returned by the OpenID provider. Please note that this is a debugging technique and should not be used in a production environment, as it might expose sensitive information in the logs. For more information on how to use Jsonnet with Ory Kratos, you can refer to the [official documentation](https://www.ory.sh/docs/kratos/reference/jsonnet).

I apologize for the confusion. The Jsonnet snippet provided was intended for debugging purposes to see the claims returned by the OpenID provider. However, it does not set any identity traits, which is likely why you're encountering issues. To set identity traits, you would need to map the claims to the corresponding traits in your identity schema. Here's an example of how to do this:

jsonnet local claims = std.extVar('claims');  {   identity: {     traits: {       // Assuming the claim returned by the OpenID provider is named 'email'       email: claims.email,       // Add more claims as needed...     },   }, }

In this example, the

email

claim is mapped to the

email

trait in the identity schema. You would need to adjust this code to match the actual claims returned by your OpenID provider and the traits defined in your identity schema. For more information on how to use Jsonnet with Ory Kratos, you can refer to the [official documentation](https://www.ory.sh/docs/kratos/reference/jsonnet).

To display a page to get non-identity schema user data during the registration flow, you can use the

transient_payload

field. This field allows you to pass additional data to the flow without being persisted by Ory like identity traits do. Here's an example of how to include a

transient_payload

in the POST request payload when submitting the registration flow:

json {   "traits.email": "<mailto:user@example.com|user@example.com>",   "traits.tos": true,   "transient_payload": {     "additional_data": "your_additional_data_here"   } }

In this example,

additional_data

is a placeholder for the non-identity schema user data you want to collect. You would need to replace it with the actual data you want to collect. After submitting the registration flow, you can access the

transient_payload

in your application or in a webhook. For more information on how to configure and use a webhook, please refer to the [Webhooks documentation](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks). Please note that the

transient_payload

is not persisted by Ory and is only available during the current flow. If you need to persist this data, you would need to handle it in your application or in a webhook. For more information on how to submit the registration flow, you can refer to the [official documentation](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#submit-registration-flow).

To insert a step with a custom form to get user information during the registration flow, you would need to customize the registration flow in your application. Here's a general idea of how you can do this: 1. When the user starts the registration flow, your application sends a GET request to the

/self-service/registration/api

endpoint to get the registration flow. 2. Your application displays the registration form to the user. This form should include the fields defined in your identity schema. 3. After the user submits the registration form, your application sends a POST request to the

/self-service/registration

endpoint to submit the registration flow. This request should include the user's credentials and any other data from the registration form. 4. Your application then displays a custom form to collect additional user information. This form can include any fields you need that are not part of the identity schema. 5. After the user submits the custom form, your application handles the additional user information as needed. This could involve storing the data in your own database, sending it to a third-party service, etc. Please note that this is a general guide and the exact steps might vary depending on your application and your specific requirements. For more information on how to customize the registration flow, you can refer to the [official documentation](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#submit-registration-flow).

@chilly-king-10285 can I use return_to to redirect the registration flow to a custom user input page?

Yes, you can use the

return_to

query parameter to redirect the registration flow to a custom user input page. The

return_to

parameter is used to specify the URL to return the browser to after the flow is completed. Here's an example of how to use the

return_to

parameter when initializing the registration flow:

javascript const { flow, return_to = "" } = req.query;  const initFlowQuery = new URLSearchParams({   return_to: "<https://yourapp.com/custom-input-page>", });  const initFlowUrl = getUrlForFlow("registration", initFlowQuery);  if (!isQuerySet(flow)) {   res.redirect(303, initFlowUrl);   return; }

In this example, the

return_to

parameter is set to

<https://yourapp.com/custom-input-page>

, which is the URL of the custom user input page. After the registration flow is completed, the user will be redirected to this URL. Please note that the domain of the

return_to

URL must be whitelisted in your Ory Kratos configuration to prevent Open Redirect Attacks. You can do this by adding the domain to the

selfservice.allowed_return_urls

configuration option:

yaml selfservice:   allowed_return_urls:     - <https://yourapp.com/>

For more information on how to use the

return_to

parameter, you can refer to the [official documentation](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration#advanced-redirects).