Digital Product Passport (DPP)

The following claims are specific to these examples. Their names are case-sensitive and their values are strings. For example, DppUpdateAuthorized = "true" compares a string, not the JSON Boolean true. An implementation using different claim types or role representations adapts the rules accordingly.

The rule blocks refer to the following object groups with USEOBJECTS. Include the required definitions when assembling a policy from the examples. BatteryPassport-Submodels selects candidate Submodels for examples 1, 2, 4, 5, and 6; each rule’s FORMULA restricts them by semanticId. Example 3 instead addresses individual SubmodelElements with REFERABLE. Submodel-Repository-Routes selects the repository routes used in examples 7 and 8.

In each rule, ATTRIBUTES lists the inputs used for access control, RIGHTS lists the permitted operations, and OBJECTS selects the targets. FORMULA states the conditions under which ACCESS: ALLOW applies. Claims come from a validated access token. GLOBAL(ANONYMOUS) instead applies to calls without a token. An operation remains denied unless an applicable rule permits it.

The standard route literals are /submodels and /submodels/*. A deployment-specific tenant prefix belongs to the server base URL and is not part of these literals. The route definitions alone do not isolate tenants; scenario B explains the required partition selection.

A public user requests a DPP by product ID. The DPP service calls the AAS without an access token, as shown in Figure 2. This rule permits READ on Technical Data and Product Carbon Footprint Submodels, without an element filter. It grants no write permission or anonymous access to GetAllSubmodels; the DPP service reads addressed Submodels that match the allowed semantics.

An authenticated recycler requests the Battery Passport. The token contains Role = "recycler". This rule permits READ on Technical Data, Product Carbon Footprint, Product Condition, and Circularity Submodels. It does not grant update permission. The AAS authorization step in Figure 3 applies this rule when the requester is a recycler.

In this illustrative delegation, the economic operator authorizes a recycler to record the remaining capacity of one battery and the measurement timestamp. This is a deployment policy choice, not a general permission for every recycler. The Product Condition Submodel has the example instance ID urn:example:battery-123:condition. Replace that ID with the actual Submodel ID when configuring the policy.

The rule requires Role = "recycler" and DppUpdateAuthorized = "true". These deployment-defined claims are issued only for the approved delegation. The concrete REFERABLE targets define the Submodel and element scope in this example. The two REFERABLE objects permit UPDATE on RemainingCapacity.RemainingCapacityValue and RemainingCapacity.LastUpdate. The formula checks the Submodel type and the semantic identifier of the addressed element. The timestamp identifier is reused in other measurement collections, so its path is also needed to limit this grant.

The workflow in Figure 4 updates the values of these two existing elements. It does not grant updates to the whole Submodel, the containing collection, other measurements, or another battery. Read access is granted separately by example 2. A deployment using this restricted delegation must not also grant the recycler broader UPDATE access through another object or route rule. A read FILTER would not restrict writes. The server preserves the elements' semantic identifiers and structure and validates the new capacity value and timestamp. The diagram groups the two element updates without assuming an atomic multi-element API operation.

An authority requests Battery Passport information using a token with Role = "market-surveillance-authority". This rule permits READ on Digital Nameplate, Technical Data, Product Carbon Footprint, Product Condition, and Circularity Submodels. It grants no write permission. The exchange follows Figure 3, with the authority role selecting this rule instead of the recycler rule.

The economic operator hosts the AAS. An external DPP service provider reads the AAS data to compose a DPP, using a token issued by an IAM trusted by that AAS. This rule requires Role = "dpp-service-provider" and permits READ on the five illustrated Submodel types. It covers the read path in Figure 6. The separate update rule is example 6.

These permissions belong to the provider. For calls on behalf of a requester, the implementation also needs to preserve that requester’s restrictions. Delegating the requester’s token or appropriately scoped claims lets the AAS apply requester-specific rules instead.

In the same deployment as example 5, the provider updates Product Condition on the economic operator’s behalf. This rule requires Role = "dpp-service-provider" and DppUpdateAuthorized = "true". It permits UPDATE only on Product Condition and covers the update path in Figure 6. The deployment needs an object scope limited to the products covered by the delegation; the permission flag does not supply that scope. Unlike the element-level grant in example 3, this rule grants an update to the whole Product Condition Submodel and is appropriate only when the provider is authorized for that scope.

A DPP service provider hosts both the DPP service and the AAS for several economic operators. An operator creates, reads, or updates its own data through the provider’s DPP service, as shown in Figure 7. This rule requires Role = "tenant-economic-operator" and tenant = "example-tenant". It permits CREATE, READ, and UPDATE on the configured Submodel-repository routes; it grants no DELETE permission.

Before evaluating the route rule, the AAS maps the validated tenant claim to a trusted tenant-specific partition or object scope. Merely checking the claim does not provide isolation. The example is instantiated for the configured tenant and applies only within that partition.

An economic operator hosts its own DPP and AAS services. Its authenticated operator uses the DPP service to create, read, or update data, as shown in Figure 8. This rule requires Role = "self-hosted-economic-operator" and permits CREATE, READ, and UPDATE on its Submodel-repository routes. It grants no DELETE permission. Unlike examples 1 to 6, this is a repository-route grant, not a restriction to the listed Battery Passport semantic identifiers.

An AAS infrastructure used to provide DPP information can also support additional services. This example illustrates an optional battery diagnostics service that uses AAS access rules to distinguish basic access from paid access to additional information. The service offers a summary to registered customers. A customer can buy access to the detailed diagnosis and maintenance recommendations for a particular battery. Both requests read the same Submodel; the AAS filters its elements according to the customer’s entitlement, as shown in Figure 9. The commercial service manages purchases and entitlements; AAS access rules enforce the resulting permissions on the data. This is an additional AAS use case, not a DPP requirement. Required Battery Passport information is not subject to the payment condition, and payment does not establish regulatory access rights.

The example uses a custom diagnostics Submodel with instance ID urn:example:battery-123:diagnostics and semantic identifier urn:example:battery-diagnostics:1:Diagnostics. These identifiers and the element semantics below are illustrative, not published IDTA template identifiers. All three elements are top-level Properties with string values.

After authenticating the customer, the IAM checks the service’s entitlement records for the requested Submodel. It issues a token with Role = "customer", DiagnosticsSubmodelId identifying that Submodel, and DiagnosticsAccess = "basic" or "paid". These are deployment-defined claims, not customer-supplied payment assertions. The issuer limits token validity to the entitlement’s validity; payment processing is outside this example. After a purchase changes the entitlement from basic to paid, the customer obtains a new token carrying the updated claim. An existing basic token does not change when payment is completed.

FORMULA authorizes the customer for the addressed Submodel. FILTER then evaluates $sme#semanticId for each returned element. With basic access, only Summary remains. With paid access, all three listed elements remain; a purchase for another Submodel does not satisfy the scope check. Missing or unrecognized entitlement claims do not grant access. New elements are excluded until the filter explicitly permits their semantics.

The filter does not grant write access. Another rule granting an unfiltered read to the same customer would bypass this restriction and must not be combined with this policy. If the model is extended with nested elements, their parents also need to be visible; see Access Permission Rules.

Figure 5 shows a read by product ID and date. Its public path uses the read permission from example 1; its authenticated path can use example 2 or example 4, depending on the requester. The AAS authorizes access to the selected version. These examples do not define a separate policy for historical access.