docs.twinsphere.io ↗ RSS
twinsphere · Engineering Blog
General ABAC · IDTA

twinsphere ABAC vs. IDTA ABAC: two approaches to access control for digital twins

The IDTA published an ABAC specification for the AAS. Our first implementation takes a simpler approach to drive early adoption. Here is how the two compare and how we see the future.

BY
D. Biondić
PUBLISHED
READING
~ 10 minutes

Access control for digital twins is a hard problem.

A single Asset Administration Shell can contain a Digital Nameplate with public manufacturer information, Handover Documentation with service-restricted maintenance procedures, and Technical Data with supplier-confidential engineering parameters — all in the same shell. Different consumers need different slices, and the boundaries between “public” and “confidential” shift depending on who is asking and in what context.

The Industrial Digital Twin Association (IDTA) recognised this and published a specification for Attribute-Based Access Control (ABAC) tailored to the AAS. twinsphere implements its own ABAC system that takes a fundamentally different approach. This post compares the two.

What ABAC means in this context

Both systems are attribute-based, meaning access decisions are made by evaluating attributes of the subject (who is requesting), the resource (what is being requested), the action (read, write, delete), and the environment (time, network, tenant context). This is in contrast to role-based access control (RBAC), where permissions are attached to predefined roles.

The difference between twinsphere and IDTA is not whether to use ABAC — both agree on that — but where policies live, how they are evaluated, and what the policy language looks like.

IDTA ABAC

The IDTA specification (IDTA-01004) defines a standalone Access Rule Model with its own BNF (Backus-Naur Form) grammar and JSON schema.

The key design decisions:

  • Standalone policy model: Access rules are defined in a dedicated Access Rule Model, separate from the AAS metamodel. Rules can target API routes, identifiables (AAS, submodel), referables (submodel elements), descriptors, or fragments of any of these. The model uses ABAC with subject attributes drawn from JWT access token claims, global attributes like timestamps, and object attributes from the AAS data itself.
  • Shared grammar with the AAS Query Language: The formula expressions in access rules use the same BNF grammar as the AAS Query Language defined in Part 2 (v3.1). This means the same comparison operators, string operations, and $match expressions work in both contexts.
  • Exchangeable rules: The Access Rule Model can be serialised as JSON and stored in a submodel (as a blob or file element) for exchange between business partners. A robot manufacturer, for example, can ship suggested access rules alongside the AAS for their product — the operator can import and adjust them. However, evaluating the access rights based on the provisioned ABAC rules is subject to the recipient and cannot be enforced by the provider.

The strength of this approach is its expressiveness. The shared grammar with the AAS Query Language means access rules can use the full power of a query language — nested boolean expressions, regex matching, datetime extraction ($dayOfWeek, $month), type casting, and recursive $match over SubmodelElementCollections and Lists. A single rule can express conditions like “allow READ if the requesting user’s role claim matches a pattern AND the current time is within business hours AND a specific property value in a related submodel equals a certain state.” That level of expressiveness covers edge cases that simpler systems cannot.

The weaknesses are complexity and the risk it creates:

  • The query language can target anything, which makes rules hard to reason about. A rule can reference JWT claims, global timestamps, arbitrary submodel property values, regex patterns, and nested list elements — all in one expression. When you have dozens of such rules interacting, understanding the effective access for a given principal on a given resource requires mentally evaluating all of them. This is where security gaps emerge: not from missing rules, but from rule interactions that nobody fully understands.
  • The spec does not define where rules are stored. There is no new field in the AAS metamodel for security-relevant data. The spec suggests that rules “may even” be stored in submodel elements as blob or file, but this is optional and not standardised. Implementations are left to decide storage, enforcement, and distribution on their own. This means two systems implementing IDTA ABAC may have no interoperable way to actually exchange or enforce each other’s rules in practice.
  • Maintaining consistency at scale is an operational challenge. Rules reference objects by identifier or pattern, and changing who can access a class of data means updating the rule model and distributing it to every system that holds a copy. With complex formula expressions, validating that a change does not accidentally grant or revoke access elsewhere requires careful analysis that grows harder as the rule set grows.

twinsphere ABAC

twinsphere separates policies from data almost entirely. Access policies are managed through a dedicated API (/sphere/api/v1/access-policies), independent of the AAS data itself. The connection between policies and resources is made through security attributes — key-value pairs attached to Shells and Submodels via the AAS extensions array using the twinsphere.io/security-attribute/ prefix.

The key design decisions:

  • Security attributes on resources: The AAS metamodel does not have dedicated fields for security-relevant metadata like location, confidentiality level, or data classification. Neither does the IDTA ABAC spec introduce any. twinsphere solves this by using the AAS extensions mechanism to attach security attributes directly to Shells and Submodels (e.g., twinsphere.io/security-attribute/location: berlin, twinsphere.io/security-attribute/confidentiality: high). These attributes give resources a security classification that policies can match against.
  • External policy store: Policies are defined separately and map principals (users, service accounts, groups) and actions (READ, WRITE, DELETE) to resource attribute combinations.
  • Strict exact matching: A policy matches a resource only if they have the exact same set of attribute keys and all values match (with wildcard support). A policy with two attributes will never match a resource with one or three attributes. This prevents accidental access grants from partial matches.

The strength of this approach is operational simplicity. Adding a security classification to a class of resources means attaching the same attributes to each Shell or Submodel, then creating one policy that governs access for that attribute combination. Changing who can access “high confidentiality” resources across an entire tenant is a single policy update — no per-resource modifications, no rule re-serialisation.

The weakness is that policies do not travel with the data. When you export a Shell from twinsphere, the security attributes are preserved in the extensions, but the policies that interpret them are not included. The receiving system needs its own policy configuration. For cross-organisational data exchange, this means access semantics must be agreed upon out-of-band. In practice, we do not see this as a significant limitation. When shells cross organisational boundaries, a transfer of ownership occurs — the receiving organisation imports the data into their own platform and defines their own security context for it. Carrying over the supplier’s access rules verbatim rarely makes sense when the user base, roles, and compliance requirements are entirely different.

Where they converge

Both approaches agree on several fundamentals:

  • Fine-grained control is necessary. Shell-level or submodel-level access control is not sufficient. Real-world use cases require element-level granularity.
  • Attributes beat roles. The combinatorial explosion of roles in a multi-tenant digital twin platform makes RBAC impractical. ABAC scales.
  • Context matters. The same user requesting the same data should get different results depending on whether they are accessing it as an auditor, a supply chain partner, or an internal engineer.

Looking ahead

We will continue working on implementing the IDTA 3.1 ABAC specification for our services. We expect to offer both solutions in the future — configurable per deployment — so that teams can start with twinsphere’s simpler ABAC model today and adopt the full IDTA Access Rule Model when their use case requires it.

For details on configuring twinsphere ABAC, see the twinsphere documentation.

// RELATED — 1 ENTRIES