Introduction This document explains the security of the Asset Administration Shell. This specification defines a model for access rules. Such model targets 2 purposes. Purpose 1 is to provide guidelines for implementations. Purpose 2 is to address the definition and exchange of access rules. The exchange of access rules is very useful for complex assets like robot or machine. A set of access rules is provided by the supplier of an asset and the operator adjusts the access rules to his needs. In case of switching between AAS implementations, an exchange of access rules is useful. AAS implementations (of non test systems) are supposed to consider relevant security standards and regulations, e.g. IEC 62443, ISO 27001, EU CRA or EU NIS2. This includes rules for the development process and for the written code. Section Requirements defines security requirements for AAS systems following the IEC 63443 series. Implementation specific security requirements are not part of this document. The Annex Requirements Mapping provides an overview on which requirements are addressed by this document and which are not. Typical scenarious for AAS include multiple stakeholders along the industrial value chain. This comes with the need for authentication and authorization of subjects, i.e., users and systems, accross different security domains. This is addressed by identity and access management (IAM). This document dicusses several patterns and examples for IAM in the context of AAS (Integration Patterns,External and Internal Identity Providers, Authentication Flows). However, this document does not mandate a specific solution for IAM. As a result of the subject identification and authentication process there is an Access Token that is evaluated by the AAS to authorize access to data and services represented by the AAS. An Access Rule Model is defined, which uses Attribute Based Access Control (Attribute Based Access Control (ABAC)) as underlying concept. Claims carried by the Access Token are used as attributes for the ABAC authorization. ABAC allows to consider additional attributes which go beyond subject identity or role for authorization decisions. Date and time of the requiest, current machine state, environmental conditions are examples for additional attributes. Access rules are defined for routes in the AAS API [2] (part 2), for Identifiables and Referables by reference or semanticId, or for certain assets. Types of AAS As introduced in AAS Part 2 API, Figure 1 shows 3 different types of information via the Asset Administration Shell. Type 1 is the exchange as an AASX file [3] (part 5). Such AASX file can include a Security Model to be passed to a business partner. Type 2 is the access to AAS by the API [2] (part 2) to a server. Such server can use and enforce the ABAC rules of the Security Model. The Security Model may be hosted as submodel by the server. The submodel for the Security Model is then itself subject to access control. Type 3 is the so called “Industrie 4.0 Language” with active AAS, which is similar to agents. Basically Type 3 is out of scope for this document, but the definitions of this document can also be used in the context of Type 3. Figure 1. Types of Information Exchange via Asset Administration Shells Services, Interfaces and Interface Operations AAS Part 2 API also introduces the Industrie 4.0 Service Model illustrated in Figure 2 for a uniform understanding and naming. It basically distinguishes between associated concepts on several levels (from left to right): technology-neutral level: concepts that are independent of selected technologies; technology-specific level: concepts that are instantiated for a given technology and/or architectural style (e.g. HTTP/REST, OPC UA, MQTT); implementation level: concepts that are related to an implementation architecture that comprises one or more technologies (e.g. C#, C++, Java, Python); runtime level: concepts that are related to identifiable components in an operational Industry 4.0 system. This document deals with the concepts of the technology-neutral and technology-specific level. However, to avoid terminological and conceptual misunderstandings, the whole Industrie 4.0 Service Model is provided here. The technology-neutral level comprises the following concepts: Service: a service describes a demarcated scope of functionality (including its informational and non-functional aspects), which is offered by an entity or organization via interfaces. Interface: this is the most important concept as it is understood to be the unit of reusability across services and the unit of standardization when mapped to application programming interfaces (API) in the technology-specific level. One interface may be mapped to several APIs depending on the technology and architectural style used, e.g. HTTP/REST or OPC UA, whereby these API mappings also need to be standardized for the sake of interoperability. Interface-Operation: interface operations define interaction patterns via the specified interface. The technology-specific level comprises the following concepts: Service Specification: specification of a service according to the notation, architectural style, and constraints of a selected technology. Among others, it comprises and refers to the list of APIs that forms this service specification. The service specification includes I4.0-defined standard APIs but also other, proprietary APIs. Note: such a technology-specific service specification may be but does not have to be derived from the “service” described in the technology-neutral form. It is up to the system architect and service engineer to tailor the technology-specific service according to the needs of the use cases. API: specification of the set of operations and events that forms an API in a selected technology. It is derived from the interface description on the technology-neutral level. Hence, if there are several selected technologies, one interface may be mapped to several APIs. API-Operation: specification of the operations (procedures) that are accessible through an API. It is derived from the interface operation description on the technology-neutral level. When selecting technologies, one interface operation may be mapped to several API-operations; several interface operations may also be mapped to the same API-operation. The implementation level comprises the following concepts: Service-Implementation: service realized in a selected implementation language following the specification in the Service Specification description on the technology-specific level. API-Implementation: set of operations realized in a selected implementation language following the specification in the API description on the technology-specific level. API-Operation-Implementation: concrete realization of an operation in a selected implementation language following the specification in the API-Operation description on the technology-specific level. The runtime level comprises the following concepts: Service-Instance: instance of a Service-Implementation including its API-Instances for communication. Additionally, it has an identifier to be identifiable within a given context. API-Instance: instance of an API-Implementation which has an endpoint to get the information about this instance and the related operations. API-Operation-Instance: instance of an API-Operation-Implementation which has an endpoint to get invoked. Figure 2. Services, Interfaces and Interface Operations One important message from the Industrie 4.0 Service Model is that it is the level of the interface (mapped to technology-specific APIs) that provides the unit of reusability, is the foundation for interoperable services, and provides the reference unit for compliance statements. Figure 3 shows AAS Services/Interfaces and an example sequence how they are called from a client application: At first a client application provides an asset ID (asset link) to the AAS Discovery Interface to retrieve the corresponding AAS ID or AAS IDs. By the AAS ID the related AAS Descriptor can be retrieved through the AAS Registry Interface. An AAS descriptor includes the endpoint of the AAS and of the related Submodels. AAS or Submodel are either hosted standalone or as part of a larger AAS or Submodel Repository. In Figure 3 the first submodel is accessed by the Submodel Interface and the second submodel is accessed by the Submodel Repository Interface. Figure 3. Sequence Diagram of AAS Services Use Case File Exchange Figure 4 shows an example use case of File Exchange between business partners as introduced by AAS Part 5 Package File. In the example a supplier sends AAS as AASX by email to an integrator. The integrator sends the AAS received from the supplier and additional own AAS to his customers. It is up to the integrator to forward only selected submodels from the supplier’s AAS to his customer. This use case is an example for the necessity of Signing, since it is desireable to check the integrity of the AAS originally provided by the supplier. Chapter Accountability for AAS Content and Digital Signatures discusses means of ensuring accountability of AAS data. Basic signing functionality for data retrieval from an AAS is defined in the REST API specification IDTA-01002. Figure 4. Use Case File Exchange between Value Chain Partners When having a look at the Use Case File Exchange in Figure 4 also security aspects have to be considered when transferring information from one value chain partner to the next. When AAS content is passed from one partner to another, this is typically related to a change in the access control domain of the partners involved (supplier, integrator, operator), i.e. the scope of the validity of access control policies. Therefore, for the example that the supplier passes on data to the integrator, the following typical steps are carried out: Step A1-A2: The supplier makes a choice which data is to be passed on, and thus determines which APIs are accessible to whom and/or the content of the AASX package. Step A2-A3: the AASX package is transferred to the integrator. With API this step is only needed, if the supplier pushes (POST, PUT) the AAS data to the integrator. Step A3-A4: The integrator receives the AAS by the API or receives the package and imports the content into his security domain. During this step, the integrator has to establish access rights according to the requirements in his own security domain. The exchange of access permission rules is described in Exchange of Access Rules. == Use Case AAS Servers with API Figure 5 shows an example of a User Application accessing 3 AAS Servers and a Registry. This example will be further detailed in Architecture Examples below. The User Application will access the registry by the Registry API to retrieve the endpoints of AAS and Submodels. It will then access the data on the different AAS servers by the related APIs. This use case is an example for the necessity of Authentication, Authorization and Signing. The AAS Servers provide data available to the public, i.e. anonymous users, or restrict the access of certain data to specific users. To gain access to restricted data, the User Application first authenticates (not in the figure) and gets an Access Token to supply its identity and further attributes to an AAS Server and also to the Registry. Access rules will be validated and enforced using the attributes in the Access Token. Figure 5. Example of a User Application accessing 3 AAS Servers and a Registry AAS Server means either an AAS Repository with multiple AAS or just an AAS endpoint with a single AAS. Further use cases are available at the Platform Industrie 4.0, e.g. Collaborative Condition Monitoring or Exchange of Engineering Data, and in IEC 63278-4 Use Cases. Repository and registry AAS Security applies to all AAS APIs, especially to both repositories and registries. In case of repositories the Access Rules define the access to the data in the repository itself. A registry only includes AAS descriptors or submodel descriptors. In that case the Access Rules define the access to the descriptors, i.e. by rules with semanticId, assetId or ID for identifiable. This gives the possibility to copy the related rules made for a repository also to a registry, either manually or even automatically. Architecture Examples Protecting an AAS Server Figure 6. Example of a possible AAS server implementation Figure 6 shows a possible AAS server implementation with security: A User wants to access AAS information from a Manufacturer using an AAS User Application. The Manufacturer hosts an AAS Server which is internally administrated by an AAS responsible. In step 1 the User Application authenticates at and receives an access token from the Identity Provider / Authorization Server. In step 2 the User Application looks up e.g. the aasId at the AAS Discovery/Registry Service and receives the related AAS endpoint for the AAS Server. In step 3 the User Application accesses such endpoints in the AAS Server. First such access will be handled by the API Gateway in the AAS Server. Such API Gateway will verify the signature of the access token by the Authentication Service, which uses the public key of the Identity Provider / Authorization Server. Second the AAS API verifies by the Authorization Service, that the requested API route is authorized. Access is determined by related ABAC access rules for that API route. Third the AAS API verifies by the Authorization Service, that the requested AAS element is authorized. Access is determined by ABAC access rules with IDs of Identifiables, Referables, Assets or semanticIds. Fourth the AAS API will access the Data Storage, but only in case of all the positive authorizations above. Business partners send proposed access rules to the AAS Responsible, e.g., a machine supplier proposes such rules to a machine operator. Whether such access rules are stored in a proprietary way by the AAS Server, or in the Data Storage in AAS format as received depends on the implementation. As described for the AAS Server, the AAS User Application will also provide the access token to the Discovery/Registry Service which can make the verification and authorization accordingly. Protecting an AAS Registry Figure 7. Example of a possible AAS registry implementation Figure 7 shows a possible AAS registry implementation with security: The same example as before is shown, but this time the Discovery/Registry Service is shown in more detail. Instead of AAS Data only AAS and Submodel descriptors are stored in the descriptor storage. Attribute Based Access Control (ABAC) The objective of access control is to protect system resources (here: AAS content) against unauthorized access. The protection measures are specified in access control policies whose scope of validity is defined by security domains dedicated to access control. AAS applications require effective management of data exposure. This is especially important if data is shared across multiple companies. Attribute based access control provides a means of addressing these requirements. Refer to [8] for further explanations of ABAC. Originally, ABAC relies upon the data-flow model and language model of the OASIS eXtensible Access Control Markup Language (XACML) specifications [9]. Many existing systems for access control in IACS apply role based access control (RBAC). RBAC employs pre-defined roles. Each subject (AAS user application or AAS user application user in case of AAS) is assigned one or several roles. Each role comes with a set of privileges. Before access is allowed to an AAS object (6.2.4.5) it is checked whether the role associated with the requesting subject has sufficient privileges. The role assigned to a subject represents one specific attribute of that subject. This attribute “role” is typically derived from the subjects identity (5.2.2.1). ABAC extents the traditional concept of RBAC. ABAC it allows to use additional attributes other than the subject’s role in the evaluation of an access decision. It is still possible to stick with a single attribute “role” to maintain interoperability towards an RBAC environment. Each access decision within ABAC is taken based on a set of access control rules based on ABAC attributes: Subject attributes, i.e., attributes of the subject requesting AAS information, e.g., identity, role/responsibility, affiliation of AAS user application or AAS user application user AAS object attributes, i.e., attributes of the AAS object (6.2.4.5) being requested, e.g., semanticId of a Submodel, SubmodelElement, or Property. Environmental conditions/global attributes, e.g., time at which an enquiry is made. A typical ABAC system is built around the following function blocks: Policy administration point (PAP): The system entity that creates a policy set. Policy decision point (PDP): The system entity that evaluates an applicable policy and renders an authorization decision. Policy enforcement point (PEP): The system entity that performs access control, by making decision requests and enforcing authorization decisions. Policy information point (PIP): The system entity that acts as a source of attribute values. The general request flow is depicted in Figure 8: A subject is requesting access to an object (1). In the context of an AAS, an object is for example a submodel or a property or any other submodel element. The implemented access control mechanism of the AAS evaluates the access permission rules (2a) that include constraints that need to be fulfilled w.r.t. the subject attributes (2b), the object attributes (2c) and the environment conditions (2d). After the evaluation a decision is taken and enforced upon the object (3), i.e. the access to the object is permitted or declined. Figure 8. Attribute Based Access Control In this document the concept of attributes is specialized for the application of ABAC in the context of AAS authorization. Attributes are claims from an access token (e.g. subject attributes), global attributes (e.g. environmental conditions) or attributes from AAS and submodel data (e.g. object attributes). Dataspaces A Dataspace facilitates the exchange of data between participants via a set of technical services. Each participant is capable of implementing and operating a set of services/agents that allows them to participate in data exchange. A Dataspace Authority manages the specifications and conventions for these interactions. Identity Providers issue identity tokes to the participants who can in turn decide which issuers to trust. AAS Part 2 defines interoperability on the level of standardized interfaces serving business objects leveraging the semantics of AAS Part 1. Neither specification makes normative statements about common mechanisms to establish authenticity, identification or authorization between consumers. This is however necessary to define the terms and conditions for secure access to the standardized AAS-interfaces. Interoperability across all layers of a Dataspace requires as answer a layered set of specifications with well-defined integrations among them. In a dataspace members can exchange data securely and interoperably. Such data exchange is always done in the same way, so that scalability and efficiency can be achieved. Millions of business partners are able to easily exchange data with each other in a dataspace. The data exchange can be with and without user interaction. To achieve interoperability, members of a dataspace agree on: Common models Common APIs Common security (e.g. credentials, authentication, authorization) For a dataspace with AAS there are already specifications available: AAS metamodel AAS API, including AAS Discovery and AAS Registry Many AAS Submodel Templates (e.g. Nameplate) conformant to the AAS metamodel AAS Security (i.e. this document) In addition, a dataspace with AAS needs to define: Further dataspace specific Submodel Templates Allowed concept repositories to be referenced by semanticIds Technology for identities, e.g. X509 or Verifiable Credentials Technology for identity providers, e.g. OAUTH, OIDC, Dataspace Protocol/Decentralized Claims Protocol Using central or decentral identity providers Claims used and allowed in JSON Web Tokens issued by identity providers Remark: Until now no common AAS specifications for the following concepts are published and need also to be defined in a dataspace with AAS: How to find AAS registries of the dataspace members? A solutions is to have a registry with registry endpoints or a naming convention like registry.company-domain.com. Also, an indirect registration via dataspace connectors that also support additional data exchange patterns besides AAS, e.g. simple bilateral file exchange, is possible. How to find concept repositories? A solution can be a registry of concept repository endpoints or a concept repository discovery service for semantic IDs. Additional discovery services if needed, for example for the company-domain etc. Integration Patterns With AAS many use cases between business partners are supported. In this chapter different integration patters, see Figure 9, are described, which are used in such use cases and how standardized AAS Security supports this. An integration pattern describes if an own AAS or an AAS of a business partner is used. if an AAS is hosted on a server internally or externally. if an AAS is copied. the requirements on Identity Providers. the requirements on access tokens and claims (as part of a JSON Web Token). the requirements on access rules. Figure 9. Integration patterns Integration Pattern “Build My Own” (IP1) Company A creates, manages and uses its own AAS. The AAS is not accessible from outside the Company. Everything can be decided internally by the company (Company A). Company hosts AAS on a server internally. The server software is open source, a commercial product or a software as a service. Company chooses an Identity Provider, that is aligned with company’s IT infrastructure. The chosen server software is configured to use this Identity Provider. Chosen server software either supports a set of predefined claims or is fully configurable for claims. Chosen server software either supports a limited set of build-in access rules or is fully configurable for access rules according standardized AAS security. For many internal Use Cases the security is expected to be complete company specific and does not depend on using the standardized AAS security. However, if the company decides later to make their AAS available to other companies (pattern “Access to External”) or the company chooses to use existing software to host their AAS, the company does still benefit from using standardized AAS security. Integration Pattern “Buy and Use” (IP2) Company A buys a product from Company B and uses and manages it internally. Company B has created the AAS and Company A copies the AAS. The AAS is hosted on a server of company A. Company A defines Identity Provider, access token and claims. Company B proposes a standard compliant AAS Access Rules to Company A, which Company A simply copies into his AAS Server. With respect to security this case is very similar to the “Build My Own” access pattern. Integration Pattern “Access to External” (IP3) Company A accesses an AAS on an external server of Company B. Company A accesses AAS from one business partner (bilateral) or accesses AAS from many different business partners (multilateral). The external business partner Company B hosts his AAS on his server. Company A accesses AAS by the API and uses it in its user applications. If the usage policy from Company B allows it, Company A copies the AAS and store it in its own systems. In case of bilateral access, Identity Provider, access token and claims are defined by Company B. In case of multilateral access, a common Identity Provider of a dataspace is used. The members of the dataspace have to define access token and claims. Access rules need to be defined by Company B to allow access by Company A. Integration Pattern “Sell But Still Access” (IP4) Company A sells a product to Company B. Company A has created the AAS and Company B copies the AAS. The AAS is hosted on a server of company B. Company B defines Identity Provider, access token and claims. Company A proposes a AAS Access Rules to Company B, which Company B simply copies into his AAS Server. With respect to security this case is similar to the bilateral “Access to External” access pattern. External and Internal Identity Providers A Secured System in AAS Security can be Discovery Service, Registry Service, AAS/Submodel Service or AAS/Submodel/ConceptDescription Repository Service. Figure 10 shows different alternatives of Clients, Identity Providers (IDP) and Secured Systems interacting. Figure 10. External and internal Identity Providers Unauthenticated Access AAS Security supports unauthenticated access to a secured system. A lot of information is publicly available to human users by web browsers. If such information is provided machine-readable as AAS, it is typically also public without authentication. Examples are the submodels Nameplate or TechnicalData. Single Identity Provider AAS Security supports company specific Identity Providers. In case an internal system is set up, an internal Identity Provider will be used, which can be used by internal user applications. This might even be used for external user applications, in case a company IT might not allow to support the federated identity providers below. In that case still AAS with AAS Security can be provided, but using a company specific Identity Provider. Federated Identity Provider AAS Security supports Identity Providers of dataspaces or of other multilateral company use cases. In that case, an External User authenticates to an External Identity Provider and receives an external token. This external token is provided to the Identity Provider of a company and the External User receives an access token. Such federation is possible, when an Identity Provider of a company can check the validity of the external token and trusts the External Identity Provider. Token Exchange In case of “Federated Identity Providers”, the external user has to be aware of the “Internal IDP” and has to process (store and forward) the token to the secured system. If the external user requires access to other resources, that are not secured by the “Internal IDP”, he has to deal with multiple access tokens. To overcome this complexity, RFC 8693 (https://www.rfc-editor.org/rfc/rfc8693) specifies a mechanism, where the external user is able to use its “natural / external” access token to communicate with a secured system under control of the “Internal IDP”. In cases where a shared AAS/SM Registry references identifiables from different providers, the token exchange protocol enables transparent access to resources of different secured systems under control of different Identity Providers, as long as the Identity Providers trust each other and are able to map the tokens as described in RFC 8693. From administration point of view, the Federated Identity Provider and the Token Exchange approach enable a system owner to fully control access to their secured systems, because the Identity Provider is managed by the system owner. Self-sovereign identity wallets provide a way to achieve a distributed identity layer. Authentication Flows AAS Security supports any authentication flow which provides signed JSON Web Tokens. Even other formats for Access Tokens might be used. An authentication flow can be with or without user interaction, depending on the dataspace or use case. Authentication flows like OAUTH 2.0 or OIDC can be used. Authentication flows as defined by a specific dataspace or by a specific dataspace protocol can be used. In any case a signed JSON Web Token is provided by the related Identity Provider. The following sections describe example flows that can be used.The following terms are used in the description: Resource owner: A logical entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user [RFC 6749]. In the context of AAS, the Resource owner is the AAS Responsible, or a user or organization that has been entitled by the AAS Responsible. In the OAuth 2.0 Client Credential Flow, the client acts on behalf of the resource owner and therefore receives permissions according to the rights of the resource owner. Resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. [RFC 6749] Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. [RFC 6749] Identity Provider: An entity (usually an organization) that is responsible for establishing, maintaining, securing, and vouching for the identities associated with individuals. [RFC 6973] Example: OAuth 2.0 Client Credential Grant The specification of the OAuth 2.0 Framework (RFC 6749) defines Client Credentials flow as: Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. The Client Credentials Flow involves an application providing its application credentials. The application credentials are client id and client secret. This flow is best suited for Machine-to-Machine (M2M) applications, such as CLIs, daemons, or backend services. The system authenticates and authorizes the application instead of a user. Figure 11. Authentication Flow OAuth 2.0 Figure 11 represents an OAuth 2.0 Client Credentials Grant flow that consists of the following steps: Client Requests Access Token: The client (Machine/Service A) sends a request to the Authorization Server (Identity Provider). This request includes the client’s credentials, specifically the client ID and client secret. Authorization Server Validates Credentials: The Authorization Server receives the request and validates the client’s credentials (client ID and client secret). Client secrets are usually long, random strings designed to be difficult to guess. It is commonly an alphanumeric string or Base64 encoded string. If the credentials are valid, the Authorization Server generates an access token. If not, an error is returned. Authorization Server Issues Access Token: After successful validation, the Authorization Server sends an access token back to the client. Client Requests Data with Access Token: The client uses the obtained access token to make a request to the Resource Server (AAS/SM/CD Repository). The access token is included in the request header for authentication and authorization. Resource Server Responds: The Resource Server validates the access token. If the token is valid and has the necessary permissions, the Resource Server processes the request and sends the requested data back to the client. The response contains the requested data (AAS/SM/CD). In the OAuth 2.0 Client Credentials Grant flow the client id and client secret can simply be any string. As per the official specification [RFC 6749] the client id and client secret is any visible (printable) ASCII character (*VSCHAR). The Resource server evaluates and checks the claims in the access token and validates it with the Access Rules, as specified later in this specification. Example: OpenID Connect ISO/IEC 26133:2024 defines OpenID connect as: OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. Client Credentials Flow in OIDC: While the Client Credentials flow is typically used for authorization (OAuth 2.0), OIDC can also be used in a similar manner but is more often used for scenarios involving (human) user authentication. However, the main distinction comes when OIDC is used in other flows, such as the Authorization Code flow, where it provides ID tokens to assert the identity of the end-user. ID Token: The ID token is a JSON Web Token (JWT) that contains user profile information (claims) and is signed by the identity provider. Instead of using user context, the client credential flow uses application context, and an ID token is not issued in this scenario. Only access tokens can be obtained by applications. The following sequence diagram explains the OpenID Connect in OAuth2 Authorization code grant flow: Figure 12. Authentication Flow OpenId Connect Here’s a step-by-step explanation of the flow depicted in Figure 12: Authentication and Authorization Request: The client application initiates an authentication and authorization request to the Authorization Server (Identity Provider). This request includes the openid scope, indicating that the client is requesting authentication using OpenID Connect. User Provides Credentials: The user is prompted to provide his credentials (e.g., username and password) to the Authorization Server. Authorization Code: Upon successful authentication, the Authorization Server issues an authorization code and redirects the user back to the client application with this code. Request Token with Authorization Code: The client application sends a request to the Authorization Server to exchange the authorization code for tokens. This request includes the authorization code received in the previous step. Access Token and ID Token: The Authorization Server validates the authorization code and, if valid, issues an access token and an ID token to the client application. Request Data with Access Token: The client application uses the access token to request data from the Resource Server (AAS/SM/CD Repository). The access token is a credential that allows the client to access protected resources on behalf of the user if authorized. Response: The Resource Server validates the access token and, if valid, responds with the requested data (AAS/SM/CD). Tokens: Authorization Code: A temporary code issued by the Authorization Server after the user successfully authenticates. It is used to obtain the access token and ID token. Access Token: A token that allows the authorized client to access protected resources on behalf of the user. ID Token: A token that contains information about the user (such as user ID, email) and is used to verify the user’s identity. AAS are used both in contexts with and without User, i.e. often in Machine-to-Machine (M2M) applications. For M2M typically only an Access Token and no ID Token is used. In both contexts the Authorization Server creates an Access Token with claims. The AAS server will evaluate and check these claims by the Access Rules as specified later in this specification. Example: DataSpace Protocol According to the Dataspace Protocol (DSP) [7], a Dataspace is “A set of technical services that facilitate interoperable Dataset sharing between entities.” The specification goes on to define interactions between a Data Provider and Data Consumer to expose metadata, agree on conditions for exchange and execute the transfer of Datasets. Asset Administration Shell resources can be such Datasets. A Dataspace decides which AAS Service Specifications of AAS Part 2 it wants to use, e.g. using both AssetAdministrationShellRegistryServiceSpecification and SubmodelRepositoryServiceSpecification together with AssetAdministrationShellDescriptors and included SubmodelDescriptors. Specific Dataspaces define conventions on the standardized exposure of these resources for Data Consumers to discover and retrieve. Figure 13. Dataspace Protocol negotiation with integrated SSI-based authentication flow for credential presentation A Provider will define access conditions encoded as ODRL-Policies that he expects a potential Consumer to comply with. To authorize against these Policies, a Consumer provides access to long-living claims signed by a commonly trusted party (Identity Provider, step 1). These claims will usually follow the Verifiable Credential Data Model embedded in a jwt (see Example Verifiable Credential for authentication and authorization against Dataspace Protocol endpoints): Example Verifiable Credential for authentication and authorization against Dataspace Protocol endpoints { "iss": "did:web:dataspace-identity-issuer.com", "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://w3id.org/dataspace-specific/credentials/context.json" ], "id": "1f36af58-0fc0-4b24-9b1c-e37d59668089", "type": [ "VerifiableCredential", "SpecificCredentialType" ], "issuer": "did:web:dataspace-identity-issuer.com", "issuanceDate": "2021-06-16T18:56:59Z", "expirationDate": "2022-06-16T18:56:59Z", "credentialSubject": { "id": "did:web:consumer.com", "holderIdentifier": "SomeUniqueIdentifier" } }, "jti": "ba1300d8-8a78-40b4-8749-60d84fc3ab97", "sub": "did:web:consumer.com", "iat": 1737276930, "nbf": 1737363330, "exp": 1768985730 } A Data Provider will verify those claims by validating the VC’s signature using the Identity Provider’s public key (step 5). This step ensures the authenticity of the claims. If the claims match the Data Provider’s expectation for a particular Policy Constraint, the Data Provider will return information about accessing the exposed AAS resources. This will usually include the URL and a short-living access token as well as a refresh token (step 6). The Tokens’ format is usually irrelevant for interoperability as it is issued and validated by the same Participant and remains opaque to the Consumer. Only scenarios where the Policy Decision Point and Policy Enforcement Point are implemented in separate runtimes, possibly from different vendors, require standardization of such tokens. Access concludes by presenting said short-lived token to the server hosting the AAS-resource (step 7). To strike a balance between granularity and public meta-data exposure, AAS resources are exposed in a granular manner masking implicit information like the number of Submodels or AAS-Descriptors. The AAS-Registry API completes the Data Consumer’s discovery-sequence by linking the Submodels from distributed data sources while at the same time protecting the AAS-Descriptor objects from the public. The AAS data server and the AAS registry will evaluate and check the claims in the token by the Access Rules as specified later in this specification. IEC 63278 Figure 14 shows a detailed overview of AAS as defined in IEC 62378-1. The yellow comments have been added and describe the scope of this document in relation to the defined entities in the standard. Signatures are defined in the REST API specification. Figure 14. Detailed overview of Asset Administration Shell and related entities. Based on Figure 4 of IEC 63278-1 (Reproduced by permission of DKE, German Member of IEC (www.dke.de). For the valid edition see the latest publication of IEC or DIN EN IEC and www.dke.de and www.vde-verlag.de)