Implementation for Access management to Digital Twins (via EDC extension)

[RazvanZmau]

Purpose: to maintain the access to digital twins via EDC brings enhancements over the Access Management on single digital twins.

[thomas-henn]

Copyright (c) 2024 Robert Bosch Manufacturing Solutions GmbH

EDC-based Access Control for Asset Administration Shells and Submodel Server

This document describes scalable access control to Asset Administration Shells and Submodel Servers based on EDC in the Catena-X context.

Table of Content

1. Introduction
2. Motivation
3. Solution Proposal
4. Example
5. Conclusion
6. Impact

1. Introduction

Extension of reference implementation of Digital Twin Registry (DTR) in Catena-X for scalable access management to Asset Administration Shells (AAS) and adhering Submodel server(s).

2. Motivation

Prior to Catena-X R23.09, a hotfix fulfilling the rudimentary access control requirements (e.g. compliance to antitrust law) has been implemented. It is currently used in all AAS-based Catena-X usecases. To succeed long-term, Data Providers require more flexibility, maintainability, and scalability than the current solution delivers. An architecture concept for this is proposed here.

3. Solution Proposal

The following components play a role in this access control concept:

1. Data Consumer EDC
2. Data Provider EDC and EDC-Extension as policy enforcement
   • Contract Digital Twin Registry (DTR)
   • Contract Submodel Server
3. Digital Twin Registry (DTR) with
   • Policy enforcement
   • Policy decision
   • Asset Administration Shells
4. Submodel Server, e.g. aspect API for product carbon footprint (PCF)

These components are displayed in the

Request Sequence (A) to API /lookup/shells

1. Data request from consumer EDC to provider EDC (A1)

   • Data request from outside with Business Partner Number (BPNL) membership credential for authentication, and specific asset identifiers (specificAssetIds) as search parameter.
   • Negotiation of DTR contract between consumer and provider EDC, and verification of credentials.

2. API request by consumer EDC to DTR via provider EDC (A2)

   • BPNL is forwarded by the provider EDC in the header to DTR API /lookup/shells.
   • DTR evaluates and matches BPNL to access rule(s).
   • Request parameter by consumer EDC contains specific asset identifiers (visible specificAssetIds from matching access rule(s) are enforced to be used; see Example).
   • These specific asset identifiers from consumer EDC are applied to the access rule definition of subset(s) of all Asset Administration Shells.
   • These specific asset identifiers from consumer EDC are allowed to define further subset(s) with respect to the definition of the access rule(s) (i.e. visible specific asset identifiers).
   • The access rule(s) are enforced by the DTR.
   • Note: The APIs of the DTR remain unchanged. An additional API (outside of the definition of the Asset Administration Shell) is required to maintain access rule(s).

3. DTR receives request and sends response to consumer EDC (A3)

   • Corresponding specific asset identifiers (specificAssetIds) are looked up in DTR and decoded as AAS identifiers.
   • List of AAS identifiers is sent back to consumer EDC.

Request Sequence (B) to API /shell-descriptors/{aasIdentifier}

1. Data request from consumer EDC to provider EDC (B1)

   • Data request from outside with Business Partner Number (BPNL) membership credential, and AAS identifier (aasIdentifier).
   • Negotiation of DTR contract between consumer and provider EDC (if not yet negotiated in (A1)), and verification of credentials.

2. API request by consumer EDC to DTR via provider EDC (B2)

   • BPNL is forwarded by the provider EDC in the header to DTR API /shell-descriptors/{aasIdentifier} with AAS identifier (aasIdentifier) as request parameter.
   • DTR evaluates and matches BPNL to access rule(s).
   • Request parameter by consumer EDC contains AAS identifier (aasIdentifier) as request parameter.
   • The access rule(s) are enforced by the DTR.
   • Note: The APIs of the DTR remain unchanged. An additional API (outside of the definition of the Asset Administration Shell) is required to maintain access rules.

3. DTR receives request and sends response to consumer EDC (B3)

   • Corresponding AAS identifier (aasIdentifier) is looked up in DTR if overall access granted with respect to BPNL and matching access rule(s).
   • Content of Asset Administration Shell, i.e. specificAssetIds and semanticIds (→ Submodel server endpoints) is filtered with respect to BPNL and matching access rule(s).
   • Filtered content of requested Asset Administration Shell with respect to AAS identifier (aasIdentifier) is sent back to consumer EDC.
   • If requested Asset Administration Shell with respect to AAS identifier (aasIdentifier) is not matching to the mandatory access rule definition of subset(s) of all Asset Administration Shells, the response is empty.

Request Sequence (C) to Submodel Server

1. Data request from consumer EDC to provider EDC (C1)

   • Data request from outside with Business Partner Number (BPNL) membership credential, and Submodel server endpoint.
   • Negotiation of contract on Submodel server between consumer and provider EDC, and verification of BPNL.

2. API request by consumer EDC to DTR for check on access (C2i)

   • Requested Submodel server endpoint is forwarded to DTR altogether with BPNL to match access rule(s).
   • If requested Submodel server endpoint is within an Asset Administration Shell, which matches the applicable access rule(s), the DTR responds with True otherwise False
   • If a requested Submodel server endpoint is not part of any Submodel descriptor of any registered Asset Administration Shell the response of the DTR is True.

3. API request by consumer EDC to Submodel server via provider EDC and EDC Extension (C2ii)

   • If response from (C2i) is True the API request from consumer EDC is forwarded to Submodel server.

4. Response from Submodel Server to consumer EDC via provider EDC(C3)

   • If API request is forwarded (→ C2ii) to Submodel Server, the consumer EDC receives Submodel data via provider EDC.

4. Example

Access Rules

Business Partner Number (BPNL) of the defined data consumer where an access rule applies to	(Ω): Definition of subset of Asset Administration Shells via specific asset identifier(s) which are overall allowed to be requested by the defined data consumer (→ BPNL)	(σ): Definition of visible specific asset identifier(s) within the predefined subset of Asset Administration Shells (Ω), which are allowed to be filtered by and visible to the defined data consumer (→ BPNL)	Definition of Submodel(s) which are visible to the defined data consumer (→ BPNL) via semantic identifier(s)
ACME_A	[manufacturerPartId = 4711, customerPartId = ACME_A111]	[manufacturerPartId, customerPartId, partInstanceId]	[ProductCarbonFootprintv1.1.0]
ACME_B	[manufacturerPartId = 4711, customerPartId = ACME_B222]	[manufacturerPartId, customerPartId, partInstanceId]	[ProductCarbonFootprintv1.1.0]

Asset Administration Shells

AAS Identifier	Specific Asset Identifier(s)	Semantic Identifier(s)
10001	[manufacturerPartId = 4711, customerPartId = ACME_A111, partInstanceId = abc001, nameAtManufacturer = ESPv9]	[SerialPartv1.1.0 → https://edc.dataplane/TRACE/4711-abc001, ProductCarbonFootprintv1.1.0 → https://edc.dataplane/PCF/4711-abc001]
10002	[manufacturerPartId = 4711, customerPartId = ACME_A111, partInstanceId = abc002, nameAtManufacturer = ESPv9]	[SerialPartv1.1.0 → https://edc.dataplane/TRACE/4711-abc002, ProductCarbonFootprintv1.1.0 → https://edc.dataplane/PCF/4711-abc002]
10004	[manufacturerPartId = 4711, customerPartId = ACME_B222, partInstanceId = abc003, nameAtManufacturer = ESPv9]	[SerialPartv1.1.0 → https://edc.dataplane/TRACE/4711-abc003, ProductCarbonFootprintv1.1.0 → https://edc.dataplane/PCF/4711-abc003]

Request Sequence (A) "API /lookup/shells"

1. Input Assume a data consumer with

   • BPNL = ACME_A (membership credential)
   • and the search parameters, i.e. specificAssetIds = [manufacturerPartId = 4711, customerPartId = ACME_A111, partInstanceId = abc002]

2. Output These input parameters lead to the

   • Asset Administration Shell identifier = 10002

The user BPNL = ACME_A is with repsect to the access rules allowed to access Asset Administration Shells with the specificAssetIds being manufacturerPartId = 4711 and customerPartId = ACME_A111. This matches to the Asset Administration Shells with identifiers 10001, and 10002. The further filtering by the data consumer is partInstanceId = abc002, which excludes the Asset Administration Shell with the identifier 10001.

Request Sequence (B) "API /shell-descriptors/{aasIdentifier}"

1. Input Assume a data consumer with

   • BPNL = ACME_A (membership credential)
   • to call the API /shell-descriptors/10002 from Asset Administration Shell 10002

2. Output The response by the Digital Twin Registry is a pre-filtered content of

   • Asset Administration Shell 10002 with

AAS Identifier	Specific Asset Identifier(s)	Semantic Identifier(s)
10002	[manufacturerPartId = 4711, customerPartId = ACME_A111, partInstanceId = abc002, nameAtManufacturer = ESPv9]	[SerialPartv1.1.0 → https://edc.dataplane/TRACE/4711-abc002, ProductCarbonFootprintv1.1.0 → https://edc.dataplane/PCF/4711-abc002]

The actual request by the data consumer BPNL = ACME_A to the content of the Asset Administration Shell with the identifier 10002 is further filtered by the matching access rule. This matching access rule specifies manufacturerPartId, customerPartId, and partInstanceId as enabled parameters for filtering and display to the data consumer. Therefore, any further filtering parameter by the data consumer is suppressed and not displayed. In this case here, it means, the nameAtManufacturer = ESPv9 from Asset Administration Shell with iedntifier 10002 is suppressed. Furthermore, the access rule grants access to Submodel server endpoints, which follow the aspect model ProductCarbonFootprintv1.1.0. This as a consequence suppresses the display and access to the second Submodel server endpoint from Asset Administration Shell with identifier 10002, namely SerialPartv1.1.0.

Request Sequence to Submodel Server (C)

1. Input

   • BPNL = ACME_A (membership credential)
   • API call to https://edc.dataplane/PCF/4711-abc002

2. Output (C2i) Since access is granted to Submodel server endpoints, which follow the aspect model ProductCarbonFootprintv1.1.0 in Asset Administration Shell 10002, the API call to https://edc.dataplane/PCF/4711-abc002 is granted and the Digital Twin Registry responds with

   • True for the given input parameters.

3. Output (C2ii)

   • Aspect with product carbon foorprint

5. Conclusion

In conclusion the concept enables scalable access control to Asset Administration Shells (AAS) and its adhering Submodel servers in the context of Catena-X.

Since the enforcement point for access to AAS is close to the Digital Twin Registry the same concept will also work with adaption in a context outside of Catena-X.

The AAS APIs of the DTR will remain unchanged within this concept. In addition to the AAS APIs of the DTR, two additional APIs are needed within this concept. One API for maintenance of the access rules, and another (purely machine-to-machine API) to check if access to a Submodel server endpoint is granted.

An extension to the Eclipse Dataspace Components is needed to serve as a gateway to the Submodel servers. This requires the here mentioned machine-to-machine API at the DTR. This extension enables the access enforcement to the Submodel servers endpoint(s).

6. Impact

An EDC-extension as policy enforcement is needed to properly treat these access rules.

Two additional APIs in the Digital Twin Registry, beside the API definition of the Asset Administration Shell, are needed. One CRUD-API for the management of the access rules, and another purely for machine-to-machine communication between the Digital Twin Registry and this EDC-extension.

Data providers, who use this scalable access management to Asset Administration Shells and adhering Submodel server(s) can make use of this. The former access managament to Asset Administration Shells remains optionally available.

Additional information

• [x] I'm willing to contribute to this feature