Based on the knowledge sources provided, I don't have specific information about referencing an identity's

metadata_public

field in Ory's permission model. The knowledge sources show that Ory identities have a

metadata_public

field which is described as: > "Store metadata about the identity which the identity itself can see when calling for example the session endpoint. Do not store sensitive information (e.g. credit score) about the identity in this field." This field is available in identity objects and can be modified through various APIs including: - Creating identities - Updating identities - Using webhooks to modify identities - Setting metadata during social sign-in with data mappers However, the provided knowledge sources don't contain information about whether or how this metadata can be referenced in Ory's permission model specifically. If you need to know if and how

metadata_public

can be used in permission models, I would recommend checking Ory's documentation about Ory Permissions or Ory Keto, which are their products for fine-grained access control.

Based on the knowledge sources, I can provide information about what's available in the

Context

object within Ory's permission model. In the Ory Permission Language (OPL), the

Context

object is used in permission functions and primarily contains the

subject

of a permission check. This is evident from several examples in the documentation:

typescript permits = {   view: (ctx: Context): boolean =>     this.related.viewers.includes(ctx.subject) ||     this.related.parents.traverse((p) => p.permits.view(ctx)), }

The

ctx.subject

represents the entity (like a user) for which you're checking permissions. This is used in permission functions to determine if the subject has a specific relation to an object, often through

includes()

checks like:

typescript this.related.viewers.includes(ctx.subject)

From the [Ory Permission Language blog post](https://www.ory.sh/blog/what-is-the-ory-permission-language), we can see that the

Context

is imported from the Ory namespace types:

typescript import { Namespace, SubjectSet, Context } from "@ory/permission-namespace-types"

The documentation doesn't explicitly list all properties available in the

Context

object beyond

subject

, but all examples consistently show

ctx.subject

as the primary property used in permission checks. When writing permission rules, you use this context to check if the subject has certain relationships with objects, which determines whether permissions are granted or denied. If you need more detailed information about other properties that might be available in the

Context

object, you might want to check the Ory Permission Language specification or the API reference documentation. [Ory Permission Language blog post](https://www.ory.sh/blog/what-is-the-ory-permission-language) [Ory Permissions documentation](https://www.ory.sh/docs/keto)

Based on the knowledge sources, I don't have specific information about handling custom roles defined at runtime in Ory Permissions. The documentation primarily focuses on defining permission models using the Ory Permission Language (OPL), which is a TypeScript-based configuration language. The Ory Permission Language allows you to define namespaces, relationships, and permission rules in a type-safe manner. For example:

typescript import { Namespace, Context } from "@ory/keto-namespace-types"      class User implements Namespace {}      class Document implements Namespace {     related: {       editors: User[]       viewers: User[]     }        permits = {       write: (ctx: Context): boolean => this.related.editors.includes(ctx.subject),       read: (ctx: Context): boolean => this.permits.write(ctx) || this.related.viewers.includes(ctx.subject),     }   }

However, the knowledge sources don't specifically address how to handle customer-defined custom roles at runtime without modifying the permission model itself. What we do know from the documentation is that Ory Permissions provides: 1. A flexible data model that can be customized to fit various use cases [Ory Permissions documentation](https://www.ory.sh/docs/keto) 2. APIs for reading and writing relationships [API overview](https://www.ory.sh/docs/keto/concepts/api-overview) 3. The ability to manage configuration through GitOps [GitOps guide](https://www.ory.sh/docs/guides/gitops) One potential approach might be to design your permission model to accommodate dynamic roles by creating appropriate namespaces and relationships, then use the Write APIs to manage these relationships at runtime. However, without specific documentation on this use case, I can't provide a definitive recommended approach for handling custom roles defined at runtime. For a more specific answer to your question about handling custom roles at runtime, you might want to check additional Ory documentation or reach out to the Ory community through their [Slack channel](https://slack.ory.sh/) mentioned in the knowledge sources. [Ory Permission Language blog post](https://www.ory.sh/blog/what-is-the-ory-permission-language)