From 0ba37ca27ff672756a2dfba0efb95d110509bd49 Mon Sep 17 00:00:00 2001 From: Evan Corkrean <62527488+corkrean@users.noreply.github.com> Date: Thu, 2 Jan 2025 15:29:05 -0700 Subject: [PATCH 1/8] initial pass at attribute docs --- pages/spicedb/modeling/_meta.json | 3 +- pages/spicedb/modeling/attributes.mdx | 84 +++++++++++++++++++++++++++ 2 files changed, 86 insertions(+), 1 deletion(-) create mode 100644 pages/spicedb/modeling/attributes.mdx diff --git a/pages/spicedb/modeling/_meta.json b/pages/spicedb/modeling/_meta.json index 2399c7c..5601156 100644 --- a/pages/spicedb/modeling/_meta.json +++ b/pages/spicedb/modeling/_meta.json @@ -6,5 +6,6 @@ "protecting-a-list-endpoint": "Protecting a List Endpoint", "migrating-schema": "Updating and Migrating Schema", "access-control-management": "Access Control Management", - "access-control-audit": "Access Control Audit" + "access-control-audit": "Access Control Audit", + "attributes": "Attributes" } diff --git a/pages/spicedb/modeling/attributes.mdx b/pages/spicedb/modeling/attributes.mdx new file mode 100644 index 0000000..23c67bd --- /dev/null +++ b/pages/spicedb/modeling/attributes.mdx @@ -0,0 +1,84 @@ +import { InlinePlayground } from '@/components/playground'; +import { Callout } from 'nextra/components' + +# Attributes + +Attributes are a deeply embedded concept in many authorization systems. If you are migrating to SpiceDB from a pre-existing authorization system, it's likely that attributes play a part in your authorization evaluations. + +SpiceDB is a Relationship Based Access control system. This gives SpiceDB the flexibility to evaluate attributes for access control alongside more complicated access control logic like roles or relationships. + +The sections below will provide practical examples for implementing various kinds of attributes in the SpiceDB schema language. Before reading this guide, it's recommended that you have some familiarity with the SpiceDB schema language. [These documents](/spicedb/modeling/developing-a-schema) are a good place to start. + +## Boolean Attributes + +A boolean attribute is an attribute on an object that effects authorization by enabling or disabling something. Boolean attributes can often be thought of as a toggle. Feature flag authorization can be enabled with boolean attributes. + +### Wildcards + +[Wildcards](/spicedb/concepts/schema#wildcards) are a way to implement boolean attributes. Wildcards modify a type so that a relationship can be written to all objects of a resource type but not individual objects. + +In the example below, the schema enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document. + +In the example below, editing is disabled by default. To enable editing for a document, a wildcard relationship that relates all users to the document with the wildcard relation, ```edit_enabled```, must be written. A user will have ```edit``` permission on the document if they are related to the document as an ```editor``` and they relate to the document through ```edit_enabled```. Both are required because ```editor``` and ```edit_enabled``` are [intersected](/spicedb/concepts/schema#-intersection) at the ```edit``` permission definition. + + + + + Wildcards are adequate for most binary attribute scenarios; however, wildcards are not currently supported by [Authzed Materialize](/authzed/concepts/authzed-materialize). Those who plan to use Materialize, should use self relationships for binary attributes. + + +### Self Relationships + +Self relationships are another way to implement boolean attributes. Self relationships relate an object to itself. A self relationship is walked with an [arrow](/spicedb/concepts/schema#--arrow) back to an object's self. In practice, relating something to itself toggles something on. + +In the example below, there is a schema that enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document. (this is the same authorization logic used in the wildcard example above) + +In the example below, editing is disabled by default. To enable editing for a document, a self relationship using the ```edit_enabled``` relation must be written. When a ```document``` is related to itself with the ```edit_enabled``` relation, that relation can be walked (with the arrow) to determine who relates to the document as an ```editor```. + +In summary, a ```user``` has permission to edit a ```document``` if they are related to that document as an ```editor``` and that document is related to itself with ```edit_enabled```. + + + + + There is no mechanism in the SpiceDB schema language that enforces that a relation be used as a self relation. In order to avoid accidentally misusing a self relation (e.g. relating an object to a different instance of the same type) it is recommended to implement client side logic that enforces only using the self relation for it's intended purpose. + + +## Attribute Matching + +For this guide, attribute matching is defined as scenarios where a user or group of users needs to have an attribute (or set of attributes) required by a resource in order to perform a specific action on the resource. + +### Match at Least One Attribute of a Single Type + +Attribute matching can be achieved by relating a user to an attribute as a "member" and relating a resource to it's required attribute objects. + +In the example below, users must match **at least one** of the document's country attributes in order to view the document. + +Countries are represented with the ```country``` object and every user that has a specific country attribute is related to the specific country. When a ```document``` has a country attribute that can grant ```edit``` permission for a user, it is related to that country. + + + +### Match all Attributes of a Single Type + +It's possible to specify that ***all*** attributes must be satisfied by using an [intersection arrow](/spicedb/concepts/schema#all-intersection-arrow). + +In the example below, users must match **all** of the document's country attributes in order to view the document. + +This example is similar to the one above, except it requires that all attributes are satisfied instead of at least one attribute. + + + +### Match at Least One Attribute from Each Type of Attribute + +When you have several types of attributes, it's recommended that you have an object definition for each type of attribute and that you use [subject relations](/spicedb/concepts/schema#subject-relations) to connect resources to the required attribute. + + + +### Match All Attributes from Each Type of Attribute + +To do this, you can define multiple types on the same relation and use intersection arrows. + + + +## Caveats + +In almost all cases, [caveats](/spicedb/concepts/caveats) should only be used when the data needed to evaluate the request is only available at the time of the request (e.g. user's current location or time of day). Using caveats for static data (e.g. a user's home country) can have negative performance impacts. Static attribute data should always be modeled in the schema using patterns similar to those described above. \ No newline at end of file From 96c3af4efd2f41c9f8036603ede49193e5403732 Mon Sep 17 00:00:00 2001 From: Evan Corkrean <62527488+corkrean@users.noreply.github.com> Date: Fri, 3 Jan 2025 10:30:49 -0700 Subject: [PATCH 2/8] addressing linter for attr guide --- pages/spicedb/modeling/attributes.mdx | 49 +++++++++++++++++++-------- 1 file changed, 34 insertions(+), 15 deletions(-) diff --git a/pages/spicedb/modeling/attributes.mdx b/pages/spicedb/modeling/attributes.mdx index 23c67bd..45fcf6f 100644 --- a/pages/spicedb/modeling/attributes.mdx +++ b/pages/spicedb/modeling/attributes.mdx @@ -3,49 +3,65 @@ import { Callout } from 'nextra/components' # Attributes -Attributes are a deeply embedded concept in many authorization systems. If you are migrating to SpiceDB from a pre-existing authorization system, it's likely that attributes play a part in your authorization evaluations. +Attributes are a deeply embedded concept in many authorization systems. +If you are migrating to SpiceDB from a pre-existing authorization system, it's likely that attributes play a part in your authorization evaluations. -SpiceDB is a Relationship Based Access control system. This gives SpiceDB the flexibility to evaluate attributes for access control alongside more complicated access control logic like roles or relationships. +SpiceDB is a Relationship Based Access control system. +This gives SpiceDB the flexibility to evaluate attributes for access control alongside more complicated access control logic like roles or relationships. -The sections below will provide practical examples for implementing various kinds of attributes in the SpiceDB schema language. Before reading this guide, it's recommended that you have some familiarity with the SpiceDB schema language. [These documents](/spicedb/modeling/developing-a-schema) are a good place to start. +The sections below will provide practical examples for implementing various kinds of attributes in the SpiceDB schema language. +Before reading this guide, it's recommended that you have some familiarity with the SpiceDB schema language. [These documents](/spicedb/modeling/developing-a-schema) are a good place to start. ## Boolean Attributes -A boolean attribute is an attribute on an object that effects authorization by enabling or disabling something. Boolean attributes can often be thought of as a toggle. Feature flag authorization can be enabled with boolean attributes. +A boolean attribute is an attribute on an object that effects authorization by enabling or disabling something. +Boolean attributes can often be thought of as a toggle. +Feature flag authorization can be enabled with boolean attributes. ### Wildcards -[Wildcards](/spicedb/concepts/schema#wildcards) are a way to implement boolean attributes. Wildcards modify a type so that a relationship can be written to all objects of a resource type but not individual objects. +[Wildcards](/spicedb/concepts/schema#wildcards) are a way to implement boolean attributes. +Wildcards modify a type so that a relationship can be written to all objects of a resource type but not individual objects. -In the example below, the schema enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document. +In the example below, the schema enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document. -In the example below, editing is disabled by default. To enable editing for a document, a wildcard relationship that relates all users to the document with the wildcard relation, ```edit_enabled```, must be written. A user will have ```edit``` permission on the document if they are related to the document as an ```editor``` and they relate to the document through ```edit_enabled```. Both are required because ```editor``` and ```edit_enabled``` are [intersected](/spicedb/concepts/schema#-intersection) at the ```edit``` permission definition. +In the example below, editing is disabled by default. +To enable editing for a document, a wildcard relationship that relates all users to the document with the wildcard relation, ```edit_enabled```, must be written. +A user will have ```edit``` permission on the document if they are related to the document as an ```editor``` and they relate to the document through ```edit_enabled```. +Both are required because ```editor``` and ```edit_enabled``` are [intersected](/spicedb/concepts/schema#-intersection) at the ```edit``` permission definition. - Wildcards are adequate for most binary attribute scenarios; however, wildcards are not currently supported by [Authzed Materialize](/authzed/concepts/authzed-materialize). Those who plan to use Materialize, should use self relationships for binary attributes. + Wildcards are adequate for most binary attribute scenarios; however, wildcards are not currently supported by [Authzed Materialize](/authzed/concepts/authzed-materialize). + Those who plan to use Materialize, should use self relationships for binary attributes. ### Self Relationships -Self relationships are another way to implement boolean attributes. Self relationships relate an object to itself. A self relationship is walked with an [arrow](/spicedb/concepts/schema#--arrow) back to an object's self. In practice, relating something to itself toggles something on. +Self relationships are another way to implement boolean attributes. +Self relationships relate an object to itself. +A self relationship is walked with an [arrow](/spicedb/concepts/schema#--arrow) back to an object's self. +In practice, relating something to itself toggles something on. In the example below, there is a schema that enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document. (this is the same authorization logic used in the wildcard example above) -In the example below, editing is disabled by default. To enable editing for a document, a self relationship using the ```edit_enabled``` relation must be written. When a ```document``` is related to itself with the ```edit_enabled``` relation, that relation can be walked (with the arrow) to determine who relates to the document as an ```editor```. +In the example below, editing is disabled by default. +To enable editing for a document, a self relationship using the ```edit_enabled``` relation must be written. +When a ```document``` is related to itself with the ```edit_enabled``` relation, that relation can be walked (with the arrow) to determine who relates to the document as an ```editor```. In summary, a ```user``` has permission to edit a ```document``` if they are related to that document as an ```editor``` and that document is related to itself with ```edit_enabled```. - There is no mechanism in the SpiceDB schema language that enforces that a relation be used as a self relation. In order to avoid accidentally misusing a self relation (e.g. relating an object to a different instance of the same type) it is recommended to implement client side logic that enforces only using the self relation for it's intended purpose. + There is no mechanism in the SpiceDB schema language that enforces that a relation be used as a self relation. + In order to avoid accidentally misusing a self relation (e.g. relating an object to a different instance of the same type) it is recommended to implement client side logic that enforces only using the self relation for it's intended purpose. ## Attribute Matching -For this guide, attribute matching is defined as scenarios where a user or group of users needs to have an attribute (or set of attributes) required by a resource in order to perform a specific action on the resource. +For this guide, attribute matching is defined as scenarios where a user or group of users needs to have an attribute (or set of attributes) required by a resource in order to perform a specific action on the resource. ### Match at Least One Attribute of a Single Type @@ -53,7 +69,8 @@ Attribute matching can be achieved by relating a user to an attribute as a "memb In the example below, users must match **at least one** of the document's country attributes in order to view the document. -Countries are represented with the ```country``` object and every user that has a specific country attribute is related to the specific country. When a ```document``` has a country attribute that can grant ```edit``` permission for a user, it is related to that country. +Countries are represented with the ```country``` object and every user that has a specific country attribute is related to the specific country. +When a ```document``` has a country attribute that can grant ```edit``` permission for a user, it is related to that country. @@ -61,7 +78,7 @@ Countries are represented with the ```country``` object and every user that has It's possible to specify that ***all*** attributes must be satisfied by using an [intersection arrow](/spicedb/concepts/schema#all-intersection-arrow). -In the example below, users must match **all** of the document's country attributes in order to view the document. +In the example below, users must match **all** of the document's country attributes in order to view the document. This example is similar to the one above, except it requires that all attributes are satisfied instead of at least one attribute. @@ -81,4 +98,6 @@ To do this, you can define multiple types on the same relation and use intersect ## Caveats -In almost all cases, [caveats](/spicedb/concepts/caveats) should only be used when the data needed to evaluate the request is only available at the time of the request (e.g. user's current location or time of day). Using caveats for static data (e.g. a user's home country) can have negative performance impacts. Static attribute data should always be modeled in the schema using patterns similar to those described above. \ No newline at end of file +In almost all cases, [caveats](/spicedb/concepts/caveats) should only be used when the data needed to evaluate the request is only available at the time of the request (e.g. user's current location or time of day). +Using caveats for static data (e.g. a user's home country) can have negative performance impacts. +Static attribute data should always be modeled in the schema using patterns similar to those described above. From c0e94fadd85bdb930d7b7657687adb683f0a472d Mon Sep 17 00:00:00 2001 From: Evan Corkrean <62527488+corkrean@users.noreply.github.com> Date: Fri, 3 Jan 2025 13:42:39 -0700 Subject: [PATCH 3/8] updates to attr guide --- pages/spicedb/modeling/attributes.mdx | 28 +++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/pages/spicedb/modeling/attributes.mdx b/pages/spicedb/modeling/attributes.mdx index 45fcf6f..1f7a4ac 100644 --- a/pages/spicedb/modeling/attributes.mdx +++ b/pages/spicedb/modeling/attributes.mdx @@ -3,18 +3,17 @@ import { Callout } from 'nextra/components' # Attributes -Attributes are a deeply embedded concept in many authorization systems. If you are migrating to SpiceDB from a pre-existing authorization system, it's likely that attributes play a part in your authorization evaluations. SpiceDB is a Relationship Based Access control system. -This gives SpiceDB the flexibility to evaluate attributes for access control alongside more complicated access control logic like roles or relationships. +This gives SpiceDB the flexibility to evaluate attributes for access control alongside more complicated access control logic like roles and/or relationships. The sections below will provide practical examples for implementing various kinds of attributes in the SpiceDB schema language. Before reading this guide, it's recommended that you have some familiarity with the SpiceDB schema language. [These documents](/spicedb/modeling/developing-a-schema) are a good place to start. ## Boolean Attributes -A boolean attribute is an attribute on an object that effects authorization by enabling or disabling something. +A boolean attribute is an attribute on an object that effects authorization by enabling or disabling an authorization setting. Boolean attributes can often be thought of as a toggle. Feature flag authorization can be enabled with boolean attributes. @@ -24,9 +23,7 @@ Feature flag authorization can be enabled with boolean attributes. Wildcards modify a type so that a relationship can be written to all objects of a resource type but not individual objects. In the example below, the schema enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document. - -In the example below, editing is disabled by default. -To enable editing for a document, a wildcard relationship that relates all users to the document with the wildcard relation, ```edit_enabled```, must be written. +To enable document editing in the example below, you need to establish a wildcard relationship that connects all users to the document using the ```edit_enabled``` wildcard relation. A user will have ```edit``` permission on the document if they are related to the document as an ```editor``` and they relate to the document through ```edit_enabled```. Both are required because ```editor``` and ```edit_enabled``` are [intersected](/spicedb/concepts/schema#-intersection) at the ```edit``` permission definition. @@ -46,9 +43,8 @@ In practice, relating something to itself toggles something on. In the example below, there is a schema that enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document. (this is the same authorization logic used in the wildcard example above) -In the example below, editing is disabled by default. -To enable editing for a document, a self relationship using the ```edit_enabled``` relation must be written. -When a ```document``` is related to itself with the ```edit_enabled``` relation, that relation can be walked (with the arrow) to determine who relates to the document as an ```editor```. +In the example below, to enable editing for a document, a self relationship using the ```edit_enabled``` relation must be written. +When a ```document``` is related to itself with the ```edit_enabled``` relation, that relation can be walked to itself (with the arrow) to determine who relates to the document as an ```editor```. In summary, a ```user``` has permission to edit a ```document``` if they are related to that document as an ```editor``` and that document is related to itself with ```edit_enabled```. @@ -69,7 +65,7 @@ Attribute matching can be achieved by relating a user to an attribute as a "memb In the example below, users must match **at least one** of the document's country attributes in order to view the document. -Countries are represented with the ```country``` object and every user that has a specific country attribute is related to the specific country. +Country attributes are represented by the ```country``` object definition and every user that has a specific country attribute is related to the specific country. When a ```document``` has a country attribute that can grant ```edit``` permission for a user, it is related to that country. @@ -78,7 +74,7 @@ When a ```document``` has a country attribute that can grant ```edit``` permissi It's possible to specify that ***all*** attributes must be satisfied by using an [intersection arrow](/spicedb/concepts/schema#all-intersection-arrow). -In the example below, users must match **all** of the document's country attributes in order to view the document. +In the example below, users must match **all** of the document's ```country``` attributes in order to view the document. This example is similar to the one above, except it requires that all attributes are satisfied instead of at least one attribute. @@ -92,12 +88,16 @@ When you have several types of attributes, it's recommended that you have an obj ### Match All Attributes from Each Type of Attribute -To do this, you can define multiple types on the same relation and use intersection arrows. +It's possible to specify that ***all*** attributes must be satisfied by using an [intersection arrow](/spicedb/concepts/schema#all-intersection-arrow). + +In the example below, users must match **all** of the document's ```country``` and ```status``` attributes in order to view the document. + +This example is similar to the one above, except it requires that all ```country``` and ```status``` attributes are satisfied instead of at least one attribute of each type. ## Caveats -In almost all cases, [caveats](/spicedb/concepts/caveats) should only be used when the data needed to evaluate the request is only available at the time of the request (e.g. user's current location or time of day). -Using caveats for static data (e.g. a user's home country) can have negative performance impacts. +In almost all cases, [caveats](/spicedb/concepts/caveats) should only be used when data required to evaluate a CheckPermission request is only available at the time of the request (e.g. user's current location or time of day). +Using caveats for static data (e.g. a document's status) can have negative performance impacts. Static attribute data should always be modeled in the schema using patterns similar to those described above. From 15d52afa3027f771f88031b2eaeb398eb68bf091 Mon Sep 17 00:00:00 2001 From: Evan Corkrean <62527488+corkrean@users.noreply.github.com> Date: Fri, 3 Jan 2025 15:25:18 -0700 Subject: [PATCH 4/8] Update pages/spicedb/modeling/attributes.mdx Co-authored-by: Sam Kim --- pages/spicedb/modeling/attributes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/spicedb/modeling/attributes.mdx b/pages/spicedb/modeling/attributes.mdx index 1f7a4ac..14156f5 100644 --- a/pages/spicedb/modeling/attributes.mdx +++ b/pages/spicedb/modeling/attributes.mdx @@ -13,7 +13,7 @@ Before reading this guide, it's recommended that you have some familiarity with ## Boolean Attributes -A boolean attribute is an attribute on an object that effects authorization by enabling or disabling an authorization setting. +A boolean attribute is an attribute on an object that affects authorization by enabling or disabling an authorization setting. Boolean attributes can often be thought of as a toggle. Feature flag authorization can be enabled with boolean attributes. From 393f22373e6acd476d4732b360fc74c940d319a7 Mon Sep 17 00:00:00 2001 From: Evan Corkrean <62527488+corkrean@users.noreply.github.com> Date: Fri, 3 Jan 2025 15:25:26 -0700 Subject: [PATCH 5/8] Update pages/spicedb/modeling/attributes.mdx Co-authored-by: Sam Kim --- pages/spicedb/modeling/attributes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/spicedb/modeling/attributes.mdx b/pages/spicedb/modeling/attributes.mdx index 14156f5..135ec2c 100644 --- a/pages/spicedb/modeling/attributes.mdx +++ b/pages/spicedb/modeling/attributes.mdx @@ -31,7 +31,7 @@ Both are required because ```editor``` and ```edit_enabled``` are [intersected]( Wildcards are adequate for most binary attribute scenarios; however, wildcards are not currently supported by [Authzed Materialize](/authzed/concepts/authzed-materialize). - Those who plan to use Materialize, should use self relationships for binary attributes. + Those who plan to use Materialize should use self relationships for binary attributes. ### Self Relationships From d2a9ff14e92451153dc828ed0c5e07507bf4f6f6 Mon Sep 17 00:00:00 2001 From: Evan Corkrean <62527488+corkrean@users.noreply.github.com> Date: Fri, 3 Jan 2025 15:25:37 -0700 Subject: [PATCH 6/8] Update pages/spicedb/modeling/attributes.mdx Co-authored-by: Sam Kim --- pages/spicedb/modeling/attributes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/spicedb/modeling/attributes.mdx b/pages/spicedb/modeling/attributes.mdx index 135ec2c..2edd0c8 100644 --- a/pages/spicedb/modeling/attributes.mdx +++ b/pages/spicedb/modeling/attributes.mdx @@ -41,7 +41,7 @@ Self relationships relate an object to itself. A self relationship is walked with an [arrow](/spicedb/concepts/schema#--arrow) back to an object's self. In practice, relating something to itself toggles something on. -In the example below, there is a schema that enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document. (this is the same authorization logic used in the wildcard example above) +In the example below, there is a schema that enforces the following authorization logic: a user can only view a document if the user is related to the document as viewer and editing is enabled for the document (this is the same authorization logic used in the wildcard example above). In the example below, to enable editing for a document, a self relationship using the ```edit_enabled``` relation must be written. When a ```document``` is related to itself with the ```edit_enabled``` relation, that relation can be walked to itself (with the arrow) to determine who relates to the document as an ```editor```. From c9137982150c78b5d09334cae3acd31fcb4a3f4a Mon Sep 17 00:00:00 2001 From: Evan Corkrean <62527488+corkrean@users.noreply.github.com> Date: Fri, 3 Jan 2025 15:25:47 -0700 Subject: [PATCH 7/8] Update pages/spicedb/modeling/attributes.mdx Co-authored-by: Sam Kim --- pages/spicedb/modeling/attributes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/spicedb/modeling/attributes.mdx b/pages/spicedb/modeling/attributes.mdx index 2edd0c8..33521e3 100644 --- a/pages/spicedb/modeling/attributes.mdx +++ b/pages/spicedb/modeling/attributes.mdx @@ -61,7 +61,7 @@ For this guide, attribute matching is defined as scenarios where a user or group ### Match at Least One Attribute of a Single Type -Attribute matching can be achieved by relating a user to an attribute as a "member" and relating a resource to it's required attribute objects. +Attribute matching can be achieved by relating a user to an attribute as a "member" and relating a resource to its required attribute objects. In the example below, users must match **at least one** of the document's country attributes in order to view the document. From 25053a0cfd991fd2109ccab00fff6f28216cb560 Mon Sep 17 00:00:00 2001 From: Evan Corkrean <62527488+corkrean@users.noreply.github.com> Date: Fri, 3 Jan 2025 15:25:59 -0700 Subject: [PATCH 8/8] Update pages/spicedb/modeling/_meta.json Co-authored-by: Sam Kim --- pages/spicedb/modeling/_meta.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/spicedb/modeling/_meta.json b/pages/spicedb/modeling/_meta.json index 5601156..8af4f25 100644 --- a/pages/spicedb/modeling/_meta.json +++ b/pages/spicedb/modeling/_meta.json @@ -7,5 +7,5 @@ "migrating-schema": "Updating and Migrating Schema", "access-control-management": "Access Control Management", "access-control-audit": "Access Control Audit", - "attributes": "Attributes" + "attributes": "Incorporating Attributes" }