See Digital Identity M2M and Digital Identity H2M

The physical world is populated by persons and objects that can be recognized and distinguished from one another by their Physical Identity. Although the notion of physical identity is heavily debated in philosophy, we will not discuss this further beyond the observation that identities are unique and constant over time. In a sense, a physical identity determines the "sameness" of a person or object over time.

A person that is identified through its physical identity can have many attributes such as a name, date of birth, address, eye color and so on. Some of these attributes are unique for a given person and hence can be used for identification. It is however important to note that a physical identity is not the same as this unique set of attributes. A Digital Identity is a record in an information system, describing certain attributes of a person in the physical world. The digital identity can be used by information processing systems to determine e.g. access rights.There are several issues that must be dealt with when managing digital identities:

1. At creation time of the digital identity it must be certain that it indeed corresponds to the right person (the onboarding problem)

2. It must not be possible to use the digital identity for any purpose without the explicit consent of the holder of the physical identity.

3. The digital identity must contain sufficient information to uniquely identify the person.

​

1. Summary

This building block supports trust among participants by defining how digital identities play a role in BDI in human-to-machine (H2M) interactions.

Digital identifiers for IT-processes acting on behalf of an organization/legal entity are described in Digital Identity (M2M).

2. Purpose of the building block

The purpose of this building block is to support the framework for trust in Boundary Management, where humans are acting as a representative of a legal entity by means of (digital) devices and telecommunication.

3. Concepts

Boundary Management for humans relates to:

This building block ensures that the digital identity of the human involved in (digital) interactions can be authenticated. In addition, it ensures a relation between the digital identity and

• the Representation evidence, i.e. in what role and capacity, on behalf of which legal entity, with a specific mandate

• the Professional Qualification evidence, i.e. evidence of professional qualifications

3.1 Identity

Identity is a legal concept defined by a nation state and assigned to a human by that nation state. Nation States issue Passports and ID-cards to humans which they can use to "prove" their identity. Driving licenses are also used in some states (e.g. the Netherlands) as a proof of identity.

Digital identities are related to that core identity by Identity Providers which are used in B2B processes.

Identity Providers can choose to increase the assurance level of an identity, for example by requesting live verification of an identity paper. This can be done face-to-face or remote. Typically, this is executed once at the initiation of a new identity.

3.2 Authentication

Identity Providers can also provide additional assurance at the (continuous) use of the identity, e.g. when a managed boundary must be crossed. The human user can be authenticated by a username, password and an additional 2FA / MFA. More advanced devices can also use biometric identification parameters. Biometric identification can also be used for accessing a physical location. One such example is using the Secure Logistics smart card to access a Terminal.

3.3 Identifiers

Identity Providers typically use an internal numbering scheme for identifying users which are enriched with more public identifiers like email addresses and telephone numbers. Some details regarding different identifiers are given below.

3.4 Representation

B2B Identity Providers identifies a human user in the context of an organization. Additionally, the role/mandate of the user can be defined at the Identity Provider so it can be used in all connected services. An alternative is that the service itself has local authorizations which must be managed by an administrator of the organization.

Users could represent more than one organization, and there are several approaches Identity Providers can take to manage this scenario. They could for example assign different identities for each of the represented organizations (e.g. applying different business email addresses or issuing separate secure cards per organization). An alternative is that the human user selects the represented organization in each specific use case.

3.5 Professional Qualifications

In many cases the human needs to have adequate professional qualifications for the task at hand, such as a professional drivers license, safety training or dangerous goods handling. The B2B Identity Provider could store and share these professional qualifications of the user, for example in an electronic wallet. The qualifications are typically represented as verifiable credentials.

4. Risks

Some possible risks that are important to consider for this building block, are the following:

• An insufficient framework for digital identity might lead to a lower level of trust among parties and will harm the overall trust in BDI.

• Non-compliance to applicable privacy laws (e.g. GDPR, AVG) can hamper the implementation or adoption of services and can cause reputation risks or fines.

5. Interlinkages with other building blocks

The related building blocks are:

The most important related Kits and concepts are:

6. Core design decisions

Please note the following design decisions:

• Parties choose their Identity Providers fitting to the requirements.

• The BDI adds the link to representation and professional qualifications.

• In Europe the eIDAS regulation is a solid foundation for the identity ecosystem.

1. Summary

This building block defines how BDI supports organizations (Data Providers and Data Consumers) in discovering other organizations, services and endpoints by either

• utilizing discovery-aspects of the iSHARE Trust Framework, or

• defining a standard for discovery using the DNS Protocol.

2. Purpose of this building block

In the BDI, the discovery process is recommended for enabling connections between data providers and consumers. Unlike traditional data marketplaces, where the primary focus is on matching providers with potential consumers to establish new data-sharing relationships, BDI focuses on optimizing existing data exchanges. These exchanges often support operational logistics in the supply chain, where different parties are already connected but more efficient methods for data exchange are required.

3. Concepts

4. Implementation Considerations

When implementing DNS for service discovery in BDI, several factors need to be considered:

5. Elements and Their Key Functions

1. Introduction

Usually, many parties are involved in a logistic process. Each of these parties maintains a set of valuable assets that they needs to protect. In abstract terms, this protection is realized by creating an perimeter, a boundary around the assets that is controlled by the party. Other parties can not cross the boundary without permission of the owner, hence the value is protected. However it is often required that parties do cross the boundary to facilitate cooperation.

Three different kinds of assets and their associated boundaries are distinguished:

• Digital assets, such as IT systems (applications, processes) and data

• Physical assets, such as distribution centers and production facilities

• Legal (ownership, liability and accountability) assets, such as responsibilities for and ownership of cargo

The nature and implementation of the protecting boundaries is different for each kind of assets and each one requires specific measures to allow third parties to cross them in order to cooperate in a logistic process.

There are two reasons to allow others (representatives as in human and IT-processes) to cross a boundary:

• To allow them to use an asset

• To transfer an asset between parties

Boundary Management is about managing boundaries in practice.

2. Interlinkages with other building blocks

1. Introduction

The BDI framework includes support for the authentication of a representative (human or machine) and verification of their mandate, safeguarding the non-repudiation of the liability their principal (the entity who is represented) takes for their actions.

In the physical operation of our economy many activities are outsourced. Supplying services on-premise requires access to a guarded location. For example: a maintenance sub-contractor for a vendor of video security systems is commissioned to perform maintenance at a customer's site. The subcontractor is contracted to perform regular maintenance . At regular intervals a maintenance engineer shows up at the gate of the premises and claims access to the premises, to perform preventive maintenance on a security video system on behalf of the vendor that delivered the security system.

The security guard of the company where the security system is installed needs to verify the following:

1. Has this person indeed been sent by the OEM (original equipment manufacturer)?

2. Can this person be authenticated and verified as being mandated by the sub-contractor>

3. Does this person have the required professional qualifications?

2. User Journey

In the example of the engineer of the maintenance sub-contractor, the user journey starts when the engineer shows up to the gate. The security guard needs to be able to authenticate the person and verify the representation claim. The approach for this check is as follows:

For real-life applications it is necessary to be able to operate (temporarily) offline. It should be possible to verify the Representation Evidence, even when validation by the issuer is delayed. Whether a delayed verification is acceptable, depends on the involved parties. This could for example be acceptable when the party checking the Representation Evidence has already received a prior notification. The data in this pre-notification can then be matched with the data in the actual evidence.

3. Nested JWT as carrier of claims

The use of JSON Web Tokens (JWT, RFC 7519) is ubiquitous: the support in tools and knowhow is well developed. Expand the following elements to learn more about the different uses of JWTs.

3.1 JWT types of claims

There are two types of JWT claims:

1. Registered: standard claims registered with the and defined by the to ensure interoperability with third-party, or external, applications.

2. Custom: non-registered public or private claims. Public claims are collision-resistant while private claims are subject to possible collisions.

The lists the registered claims. (Claim Name “vc”) and Verifiable Presentations (Claim Name “vp”) are registered claims. The use of nested JWTs supports the future use of VC’s and VP’s. The JWT structure makes it therefore possible to include claims of Professional Qualifications.

3.2 Using JWT's as carrier of Representation claims

The most simple approach is that the Principal issues the JWT. The payload of the JWT is:

• identity information of the human (ID #, name, digital identity etc.)

• identity information of the Principal

• order information (order reference, type of activity, location, data)

The issuer of the JWT (Principal) can add a link to the payload. The link allows for a real-time confirmation that the claims in the JWT are still valid.

When the Principal commissions a subcontractor, the identity of the human is replaced by the identity of the subcontractor. The subcontractor creates a new JWT, with the payload:

• the JWT as sent by the Principal

• identity information of the human (ID #, name, digital identity etc.)

• identity information of the Subcontractor)

4. Application in practice

An embedded JWT claim can be created recursively by each layer of the (subcontracting) chain, starting with a Principal. This show the Representation chain.

The human requesting access can carry the JWT (for instance in a Wallet), or carry a link to an online API that can transfer the JWT to an evaluation service/application. The security guards use the service or application to evaluate the JWT, verify the signing of its claims and show the content to the guard. The guard can authenticate the human and verify the representation chain.

5. Further reading

1. Introduction

The following can be considered as Digital Assets:

• Applications and processes

• Data

Allowing humans to login to your IT systems (applications, processes), or allowing a process owned by another party to access (read and maybe modify) your data is the subject of Digital Asset Boundary Management.

2. Interlinkages with other building blocks

1. BDI Stack and KITs

To assist the creation of applications according to the architectural principles, BDI defines a set of building blocks. Each building block provides tools and guidelines to implement parts of the required functionality. The building blocks are shown in the BDI stack:

Implementation of the principles by means of parts of the stack is aided by the definition of KITs. A KIT is a subset of the BDI stack that forms a coherent capability. Implementing a KIT makes it easier to start with a minimal viable subset and add additional functionality later as the need for it arises.

1. Introduction

Based on the observations mentioned in the Introduction, seven principles were formulated to guide the design of the architecture. The seven principles are given below, and explained separately afterwards.

Principle 1: Connect Physical to Digital

Sharing data via the BDI allows for a direct connection between physical processes and digital information. Physical processes — such as the delivery of materials to a construction site, the processing of an agricultural product, the transport of raw materials, or the delivery of goods to a warehouse — are supported by data and information exchange. While such communication used to occur via manual registrations, phone calls or single documents, the BDI allows for it to be structured completely digitally through connected IT systems.

Principle 2: Event-driven Coordination

In many sectors, timing is of the essence. Whenever a schedule changes, a delivery arrives, a process step is completed or a malfunction occurs, the involved parties wish to be notified as soon as possible. With the use of the BDI, organizations and professionals are automatically informed via systems about events relevant to them, even when the parties do not have a direct contractual relationship. This can be referred to as event-driven coordination: the proactive, trusted and automatic sharing of information as soon as something happens that influences a process, schedule or result.

Principle 3: Dynamic Data

Static processes rarely occur. Instead, the status of activities, deliveries, measurements or maintenance is constantly changing. Consider a changed schedule, an accelerated or delayed process, or new measurements.

With the use of the BDI these changes are shared in real-time through dynamic data: small, up-to-date data packages that follows the real events. This ensures all relevant parties always have the most up-to-date view.

Principle 4: Zero Trust

Frequently, not all the parties involved in chains and networks are familiar with each other. This is the case for many sectors, including construction, industries, defense, governance, agri-food and logistics. Regardless, secure and responsible data sharing is important. Therefore, the BDI is based on the Zero Trust principle: trust is never automatically granted, but based on rules, context and control. Within the BDI, trust is not assumed, but a controlled and retraceable decision.

Principle 5: Data at the Source

Collaborating requires data sharing. This does not mean, however, that one must transfer their data to the other party. Within the BDI an organization remains the owner of their own data. This principle is also known as data sovereignty: the data stays at the source, under the owner's control.

Principle 6: Local Decision-making

Organizations, regions and sectors all differ from one another. Legislation, culture, processes and ways of working are not the same everywhere. Therefore, the BDI supports local decision-making within a common set of rules. This idea is based on the subsidiarity principle: decisions are made on the lowest possible, most involved level.

Principle 7: Coherent Security

In order to safely share data, technology, humans and processes should be coordinated. The BDI therefore focuses on Coherent Security: security on every single level and as a whole.

1. Introduction

This page describes the BDI Change and Release Management Process for maintaining the BDI Architecture Documentation. As BDI transitions into a maintenance phase, a thorough process for change and release management is becoming increasingly important.

Both the associations that follow the BDI and the BDI itself exist in an environment subject to continuous change due to:

• Legislative and regulatory changes

• Technological advances

• Emergence of new application areas

• Previous experience and lessons learned from previous projects

Such environmental changes may call for changes in the BDI Reference Architecture. However, as these changes could impact many stakeholders, careful change management is important. The BDI Change Management and Release Management Processes are introduced for this purpose.

1.2 Scope

The Change and Release Management applies to the following assets:

• , including example IT components provided by BDI

Explicitly out of scope are any third party IT components mentioned in the BDI Framework documentation or BDI Developer Portal. These components are subject to their own change and release management processes.

1.3 Core principles

The Change and Release Management Process must be transparent, predictable and fair. Each of these principles is discussed below.

Transparency

Predictability

Fairness

1.4 Change management process

A change can be either a Request for Change (RfC) or a Minor Change, the difference being the impact of the change to the community. An accepted RfC requires BDI-based associations to take action to remain compliant with the new BDI version, whereas Minor Changes do not. However, associations, at their discretion, can decide not to comply with the new BDI version but rather follow the old one.

1.4.1 RfCs

1.4.1.1 Process for RfCs

The following diagram describes the process for managing RfCs.

Roughly the RfC transitions through the following phases:

The result of this process is an accepted RfC, with a clearly described impact on the reference architecture.

1.4.1.2 Templates

The RfC process is supported by the following templates:

• RfC Description Template [to be drafted]

• RfC Impact Analysis Template [to be drafted]

The decision making process is supported by:

• RfC Decision Guidelines [to be drafted]

1.4.2 Minor Changes

Minor Changes (MCs) are defined as changes in the managed assets that do not impact the community. These changes can for example be:

• Spelling mistakes

• Text improvements

• Reordering of information

• Other minor improvements

1.4.2.1 Process for Minor Changes

The following diagram describes the process for Minor Changes (MCs).

Roughly the MC transitions through the following phases:

1.4.1.2 Templates

The MC process is supported by the following templates:

• MC Description [to be drafted]

1.4.3 Release management

The Change Management Process results in a backlog of RfCs and MCs that require implementation. To process this this backlog efficiently, the Release Management Process was created. This process defines the procedures for selecting changes to be implemented and for consolidating those changes into releases (versions).

1.4.3.1 Release process for major versions

The following diagram describes the process for scoping and producing a major version.

The release process for major versions is as follows:

1.4.3.2 Release process for minor releases

The following diagram describes the process for scoping and producing a minor version.

The release process for minor versions is as follows:

1.4.3.3 Release and version guidelines

1.4.4 Roles and responsibilities

The following roles are recognized in the Change and Release Management processes:

Introduction BDI Reference Architecture

BDI: An Infrastructure Framework for Operations and Supply Chain Data Spaces

Operations and Supply Chain Management (OSCM) represents the science and expertise of value creation in the production and distribution networks of goods and services. Effective information sharing is an operational necessity within and across these networks for:

1. Introduction

The building block aims to define BDI's technical roles, including Identity Provider, Identity Broker, Association Administrator, Data Owner, Data Service Provider, and Data Consumer. Each role plays a crucial part in managing identity, data control, and service provision within BDI's framework.

2. Purpose of this building block

The purpose of this building block is to define the technical roles in BDI.

3. Concepts

The technical roles of the BDI are given and explained below.

4. Implementation Considerations

Implementation of the basic BDI mechanisms assumes the existence of these technical roles.

5. Interactions with other building blocks

6. Further reading

1. Summary

The building block Association Register has the basic function of registering:

• identities of recognized legal entities

• digital proof of the identity (credentials, for example certificates)

• the roles these entities can have

• the trust level of each entity

The Association Register is an operational building block that is called during the zero-trust authentication and authorization process.

The richness of the building block is governed by the subsidiarity principle: in its most simple and limited form an Association Register is maintained by and for a Data Service Provider, in its most rich form it is maintained by a BDI Association that federates with other BDI Associations.

Optional functions that are expected when a BDI Association administers their own Association Register are:

• keeping a reputation score per entity

• registering onboarding agreements

• perform federated verification checks of unknown legal identities that are Member of another BDI Association

2. Purpose of the building block

The purpose of the Association Register is to automate and facilitate trust assessments of entities in the sequence of Authentication – Trust Assessment – Authorization as performed by a Zero Trust endpoint.

A shared Association Register reduces costs and combines experiences in shared dynamic reputation scores.

A shared Association Register in a legal entity (BDI Association) can be augmented by onboarding procedures, including the signing of legal documents, including terms and conditions.

A federated Association Register automates the basic trust checks of entities that claim to be a Member of another BDI Association, by verifying the other BDI Association and verifying the membership.

A federated Association Register automates the registering of preferred Business Partners: members of other BDI Associations that have a special status.

An Association Register is considered a technological solution to facilitate the role of the Association Administrator.

3. Concepts

The following concepts (from the BDI Glossary) are particularly relevant in this building block:

4. Risks

An Association Register is a core part of automated trust assessment. This requires both:

• Rigorous design and testing for IT-security weaknesses (cryptographic libraries, protocols, penetration testing, supply chain attacks etc.)

• An operational security process that minimizes the risk of humans as attack vector (social engineering, pressure) to compromise the integrity of the register

The human attack vector is considered to be the most risky: onboarding should therefore be a one-way automated process in three separate steps (see also onboarding T&Cs Association articles):

• Collecting information (automated and/or manual)

• Verifying information and test trust chain (automated)

• Committing to the register (manual action by functionary)

Modification of information should only be possible by deleting or deprecating information, followed by a new onboarding process.

5. Interlinkages with other building blocks

This building block provides the technical implementation supporting the building block “Onboarding Terms and Conditions”, in which the operational processes and requirements regarding the onboarding of a BDI Association are described.

Furthermore, it particularly supports the building blocks “Authentication” and “Certified roles” (but not limited to) by providing trust about Members and their roles.

In fact most building blocks will have some form of link with this building block, since the Association Register is a core topic of the BDI.

Stages of implementation

In its most simple form a data service provider has its own private Association Register to recognize data consumers. The limitations of such an implementation are obvious, yet it may be a stage to reach the next level.

A shared Association Register adds the benefit of cost reduction, and trust/reputation sharing.

An Autorization Register may be shared as well.

A federated Association Register allows in principle an unlimited universe of parties that can check each other credentials as Member of their particular BDI Association, vice versa.

The principles of by discovery through a standard _bdi subdomain to facilitate federation are depicted below.

Extra function in existing trade body (Governance)

The benefits of shared services, shared standards, shared Terms and Conditions and increasing the negotiation power by coordinating as a group are known in the "analog" world. A large number of trade associations already exist, specific to a sector/region. These trade associations are natural hosts for Association Register functions. The assumption is that in most cases existing trade associations will upgrade their service offerings to include support for the BDI, instead of creating a new legal entity specifically for support of the BDI.

6. Elements and their key functions

An Association Register can have the following functions

• An Association Administrator can register Members after executing the onboarding process as defined by the particular Association

• An Association Administrator can deregister a Member, for instance when the Member requires it to do so, when a membership expires, or when a Member is to be excluded from membership due to a breach of terms and conditions.

• An Association Administrator can delete or deprecate the registration of a Member, to be superseded by an improved registration. Deprecation is preferred as the historical information may be useful in autopsies of security incidents.

7. Core design decisions

The following design decisions form the basis for this building block:

• An Association Register can operate standalone, without federation.

• An Association Register can be shared between parties in a BDI Association, or shared by multiple BDI Associations (database or shared ledger).

• An Association Register can be federated with other Association Registers, without being connected or known beforehand: there is no global register of Association Registers. The discovery mechanism is DNS based.

8. Future topics

To be discovered is how the Association Register can technically support the building block “Business Partner Reputation model”.

The federation of Association Registers might also be based on the proposals of Open-ID on federation.

The identification of Outsiders and its Root Association needs to be detailed.

Implications on trust when a member is a member of multiple associations.

9. Further reading

This building block has been derived but modified from the following sources, that provide opportunity for further reading:

• ​​

• ​​

• ​

1. Introduction

1.1 Purpose

This building block guides organizations to establish a form of governance for their data exchange activities in accordance with the BDI framework. This building block provides reasons and options to establish this governance.

2. Concepts

Some relevant concepts for the BDI onboarding are given below.

2.1 BDI Association

A BDI Association is a local entity formed by a group of participants within the framework. The legal structure of an Association can vary, as it could for example be a foundation or cooperative. Irrespective of its legal structure, the Association serves as the operational anchor for both federated trust/authentication and local onboarding within the BDI Framework. Members of a BDI Association can engage in multiple sectors and data exchanges, participating in dynamic virtual networks composed of members from different Associations. These networks operate on zero-trust principles (see ...), treating members from other Associations as untrusted by default until trust is established.

2.1.1 Local nature

The local nature of BDI Associations is important, but associations are not by definition local. Some arguments for the importance of this local nature are the following:

• Trust and reputation are often tied to proximity and frequency of interaction. The economic gravity-effect shows that geographical proximity has a causal relationship with the level of trade.

• Legal systems tend to be national or trade-bloc dependent, making localized Associations more effective in managing trust and reputation within these frameworks.

• The local BDI Association can be the foundation of effective and efficient trust management in a perimeterless, zero-trust environment.

2.1.2 BDI Framework

• The BDI Framework assumes that many associations are formed and changed, split or merged in a natural manner, as their members see fit.

• The BDI framework defines how federated trust, federated reputation and federated authentication are created spanning multiple associations.

2.2 Efficient trust management

The strong social control pillar is supported by a reputation scheme:

• Members of the same association are considered trusted insiders.

• Members of other associations are considered untrusted outsiders at the outset, but that position can change when:

  • a shared reputation scheme builds experience with outsiders,

2.3 Onboarding

It is recommended that an onboarding mechanism is introduced for new members, if the Association desires to raise the standards for its members.

The following aspects can be taken into consideration:

• vetting the member

• checking roles the member wants to fulfil

• verifying credentials and certificates (trust chain)

The result of onboarding is an entry in the local Association Register.

2.4 Coherent security

The registrations stored in the Association Register need to be secured against tampering. The process outlined in this section reduces the possibility of attack vectors directed to the staff of the Association Administration (social engineering, blackmail etc.), the most common attack vector in these cases.

The following steps apply to new registrations, updates to registrations and depreciation.

Shared terms and conditions, data access policies, and data licenses are essential for enhancing interoperability within the BDI Framework.

3. Core design decisions

The implementation of the BDI Framework should consider existing sector-specific terms, conditions, and practices. Many trade and standardization organizations are transitioning from paper-based practices to digital ones. It is recommended to build upon the existing body of knowledge and trade practices, per sector.

4. Interactions with other building blocks

See Authentication M2M and Authentication H2M

In the context of the BDI, the user is a representative of a legal entity (organization). Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases.

1. Introduction to the BDI Reference Architecture

The Basic Data Infrastructure Framework (BDI) is an infrastructure framework for controlled data sharing, supporting automated advanced information logistics in the physical economy. Departing from traditional messaging paradigms, the BDI shifts towards event-driven data collection at the source, fostering efficient and secure coordination through proven publish-and-subscribe architectures.

This introduction provides a short overview of some issues that play a role in the design of the architecture, starting with some observations about data in a logistics environment. These observations are used in the formulation of architectural principles which are in turn the basis of BDI building blocks. Finally, these building blocks are grouped in functional subsets called KITs.

See for a full account of these concepts.

2. Observations

Some observations about data in the logistics environment are given below:

1. Summary

This building block supports trust among participants by defining how digital identities play a role in BDI in machine-to-machine (M2M) interactions. The digital identifiers for natural persons are described in Digital Identity (H2M).

In its implementation, BDI aligns with iSHARE's implementation of digital identities, preferring PKI (public key infrastructure) certificates issued by a reputable identity provider as digital identity of parties like Service Providers. In Europe the eIDAS regulation is a solid foundation for the identity ecosystem.

2. Purpose of the building block

The purpose of this building block is to support the framework for trust among parties, by ensuring that parties can provide and receive a verified digital identity. An authenticated digital identity is the prerequisite for determining trust and subsequent authorization.

The building block ensures that interactions within BDI (onboarding, offboarding, data exchange, service consumption, etc.) will take place between identified and authenticated parties.

3. Concepts

The following concepts (from the BDI Glossary), all regarding legal entities, are particularly relevant in this building block:

The figure below shows how a business partner from another BDI association can become a preferred Business partner of a BDI association.

4. Risks

An insufficient framework for digital identity might lead to a lower level of trust among parties and will harm the overall trust in BDI.

5. Interlinkages with other building blocks

This building block describes the BDI principles for digital identity for M2M interactions.

The related building blocks are:

The most important related Kits and concepts are:

6. Core design decisions

A digital identity has to be linked with the legal identifier of the legal entity that controls and takes responsibility and accountability for the IT-process that uses the digital identity in interactions with other IT processes. For more details about possible identifiers, view the information below.

The following should be noted regarding identifiers in the BDI:

• The BDI prefers PKI certificates issued by a reputable identity provider as digital identity of parties like Service Providers.

• In Europe the eIDAS regulation is a solid foundation for the identity ecosystem.

• Self-signed certificates for digital identities are a low-barrier entry level solution, with serious limitations on trust, federation and scaling

7. Further reading

1. Summary

Authentication is the process of proving that the user (human or IT process) with a digital identity is the rightful owner of that identity (definition from IDpro).

Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases. In this page, the focus is on H2M use cases: the human interacts with a machine by means of an IT-process under its direct control (device, IT-process, wallet etc.), or by digital data (e.g. QR code). Authentication precedes verification of Representation and subsequent Authorization.

2. Purpose of the building block

The purpose of this building block is the following:

• Ensure that BDI users (H2M) are recognized, identified as a person and in a specific role on behalf of a legal entity in order to prevent misuse, fraud, theft of data, services and physical goods.

• Enable smooth, efficient and secure Boundary Management.

• Ensure that privacy leaks as a result of authentication are limited.

3. Concepts

The use cases relate to Boundary Management:

The building block ensures that the digital identity of the human involved in (digital) interactions can be authenticated. This authentication precedes verification of Representation. In the context of the BDI, the human is a representative of a legal entity (organization): the legal entity assumes accountability and liability for the actions of the representative, limited to the mandate of the representative. A human can have multiple roles for multiple legal entities simultaneously.

The Identity Provider chosen by the parties/Association provides the authentication. A local cache of trusted identities may be operated by an Association as a register.

Representation evidence may be stored in a register by an Association, or transmitted between parties in a nested Jason Web Token or a Verifiable Presentation of Credentials.

4. Core design decisions

4.1. OAuth2 & OpenID Connect

The BDI uses the OAuth2 protocol and OpenID Connect protocol for H2M interactions. Identities are managed by an Identity Provider (also called an OpenID Provider).

The , in abstract, follows these steps:

1. End user navigates to a website or web application via a browser.

2. End user clicks sign-in and types their username and password.

3. The RP (Client) sends a request to the OpenID Provider (OP).

Organization can use (1) an internal Identity Provider, (2) an exclusive external Identity Provider and (3) a mix of an internal Identity Provider and (federated) external Service Provider (see the Federation Kit).

In the BDI users are typically acting as a representative for a legal entity and not as an individual person. Therefore, the OpenID Connect UserInfo endpoint must contain a organizational identifier of the legal entity.

4.2. eIDAS

eIDAS is short for ‘Electronic Identification, Authentication and Trust Services’ and was launched to help remove digital borders between countries in the EEA. eIDAS ensures the security of digital systems and protects people’s privacy. Besides eIDAS, there are also various national eID schemes. For example, in the Netherlands the national eID for persons is called DigiD and the eID for persons representing a legal entity is called eHerkenning.

There are strict regulations on the use of eIDAS. DigiD cannot be used for most private use cases. There are less limitations for eHerkenning. However, a very limited set of European countries have a similar B2B eID scheme.

Once a national electronic identification scheme has been recognized at European level, it can be used in other EEA countries. This is set out in the EU’s eIDAS Regulation.

4.3. Smart Cards / Physical Access Passes

These can be used for access to a location and/or transferring assets.

5. Future Work

eIDAS2 introduces new trust services and EU Digital Identity Wallets (EDIW) for the use by citizens in both public and private domains. eIDAS2 also includes Organizational Digital Identity Wallets (ODIWs) [].

6. Interlinkages with other building blocks

This building block interlinks with:

1. Introduction

The Trust KIT serves as the foundational pillar of the Basic Data Infrastructure (BDI), ensuring secure and reliable data exchange within a BDI Association. As the core KIT, it integrates critical capabilities that empower organizations to establish and operate a BDI Association while leveraging the BDI Identity, Authentication, and Authorization (IAA) solution. The Trust KIT is essential for authorizing and delegating data access through established APIs, offering a robust framework for managing trust relationships and data governance.

1.1 Trust in the BDI

The BDI is mainly concerned with trust at the business level, i.e. trust between parties in a business transaction. However, as data exchange over a network is crucial for the BDI, we make extensive use of tools and techniques to increase trust at a technical level.

1.2 The Trust KIT

The Trust KIT is inspired by the iSHARE Trust Framework, and uses some of the concepts and components from iSHARE. However, the BDI is not identical to iSHARE.

At its core, the Trust KIT encompasses vital building blocks, including IAA functions that provide the necessary identity and access management capabilities. The Association Register and Authorization Registers enable the secure recording of membership and authorization rights. Discovery and Onboarding processes ensure that members can be seamlessly integrated into the BDI, guided by clearly defined Terms & Conditions and structured process flows. Furthermore, Policy Agreements and Edge Agreements provide the necessary governance framework to ensure that all data interactions comply with agreed-upon standards and regulations.

2. Building blocks

The Trust KIT comprises the following building blocks:

1. Summary

Authentication is the process of proving that the user (human or IT process) with a digital identity who is requesting access is the rightful owner of that identity (definition from IDpro). In the context of the BDI, the user is a representative of a legal entity (organization).

Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases.

In this page we will focus on M2M use cases where data is requested by a Data Consumer (e.g. another organization) via an API.

2. Purpose of the building block

3. Concepts

The Data Service Provider is responsible for authenticating the user; this is prerequisite for authorization, which will determine if the user can access the requested data.

4. Risks

Incorrect authentication could result in data breaches and / or the unavailability to data for legitimate data consumers.

5. Interlinkages with other building blocks

6. Core design decisions

6.1. OAuth2

The BDI uses the OAuth2 protocol. OAuth2 supports two types of client credentials for authentication:

• Shared secrets

• Private keys (certificates).

The use of private keys is preferred within the BDI.

A BDI association could decide to issue certificates itself as an association, or as a group of associations. The consequence is that the Association is its own Trust Anchor, making federation with other Associations harder or less trustworthy.

6.2. eIDAS

The European eIDAS regulation is a trust framework which (also) governs the issuance of certificates within Europe. Certificates can be used for:

• Mutual TLS - Qualified Web Application Certificate (QWAC)

• Digital Sealing of the message - Qualified Seal (QSEAL)

QWAC and QSEAL are different types of eIDAS certificates.The sealing provides the legal binding of the exchanged data.

The use of eIDAS digital certificates as private keys is recommended. The recommendation is to use eIDAS QWACs as well.

6.3. Non-European trust anchors

The eIDAS regulation and infrastructure is EU-specific. Outside of Europe other trust anchors could be used (to be investigated).

6.4. Drawbacks of certificates

• Certificates are quite expensive

• Certificates need frequently to be rotated

• The procurement, setup, testing and acceptance of certificates is not trivial.

6.5. Certificate based authentication

Guidance on (to be done):

• Mapping certificates to identifiers (within the association)

• Mapping to a well known identifier within the Data Service Provider

• Note on Mutual Authentication; also relevant for the Data Consumer

7. Future topics

1. Non-EU trust anchors (outside of eIDAS).

2. The use of association issued certificates instead of eIDAS certificates

3. Alignment with DSSC. The DSSC Blueprint v1.0 is referring to “Identity and Attestation Management” which is based of verifiable credentials, DID’s and OpenID for verifiable credentials. These has been defined out of scope for the current release of DIL / BDI.

In the BDI network, a within a BDI Association is integral for assessing the trustworthiness of visitors or outsiders: members of another BDI Association. While the BDI facilitates digital communication among a network of BDI Associations, establishing trust within a BDI Association through mutual agreements is relatively straightforward. However, evaluating the trustworthiness of participants in other BDI Associations can pose a challenge.

A federation trust is designed to enable efficient and secure online transactions between business partners. Trust to engage between parties is most often based on more attestations agreed between parties and/or assocation they are member of. The service provider can then make decisions based on te information on behalf of the data owner.

When a requests from a member of association A is directed to access data of a member of association B the request is redirected to the association's B attestation service to validate the federated trust artifacts available with the requestor association. These attestations help decide the authentication response of the data provider and authorization conditions applied on behalf the data owner. Note: Emphasizing 'helps decide' as the Trust Sovereignty principle is kept by allowing the assessment against the policies of the data owner to determine authorization. The owner might want to provide the data service as requested even if the Identity does not provide all the required attestations or limit the authorization provided by the assessment policies of the presented attestations.

The concept for the is to adopt the framework standards with it's members to achieve a goal (benefits outweigh the costs). Add local specifics, ratify common standards across associations, evolve and so on.

Above options could be combined; e.g. .

8. Further reading

OAuth2:

OAuth 2.0 Mutual-TLS:

iSHARE:

1. Purpose of the building block

Policies in the BDI are common agreements about authorization of access to data elements. Friction, management costs, delays and (legal) uncertainty can be reduced by a standardization of the following elements:

• Common roles

• Data access policies

• “Need-to-know” limitations

• Rights and obligations on how the data may be used

2. Concepts

2.1. Common Roles

Common roles define operational responsibilities within supply chains, helping to create standardized policies — particularly Data Access Policies. Each specific sector (type of cargo, modality) has common roles that are well understood and recognized. The same applies to the data elements that a role needs to have access to in order to be able to perform a task.

Defining these common roles — e.g. truck driver, customs agents, inspection agent, forwarder, terminal planner, etc. — reduces the cost of interactions between entities. An undefined role needs custom definitions for the combination role-data access policy, which may be a labor-intensive action. Managing access rights is simplified by standardization.

2.2 Data Access policies

Data access policies define who or which role can access specific data elements under what conditions. Common roles are linked to common data access policies, and a data access policy can be linked to a person: this is a specific authorization.

2.3 Data Licenses

Data licenses define the rights and responsibilities of a party that gains access to data. These licenses address whether the data can be retained, reused, or shared with third parties. For example, in the e-commerce sector a data license might stipulate that a transporter delivering packages cannot store, reuse, or resell the recipient’s personal information, including their name, address, email, phone number, or the type of goods delivered. Data licenses regulate the permissible actions and behaviors related to the use of the accessed data to ensure that control over the data is maintained even after it has left the trust boundaries of the data owner.

For a specific sector or geography one can either develop specific data licenses, or reuse common global data ones.

3. Interlinkages with other building blocks

4. Core design decisions

When starting an association, it is advisable to establish a set of policies beforehand. These policies should be developed across three layers, all of which need to be considered:

5. Further reading

1. Summary

Edges are the boundaries of an association. Edge Agreements define how members of the association can interact with non-members of the association.

1. Purpose of the building block

This building block describes how to assess trustworthiness of parties involved in a transaction.

2. Concepts

1. Introduction

In fast-moving, operational environments—whether in logistics, infrastructure, mobility, or beyond—effective coordination depends on timely and reliable information sharing between autonomous organizations. The Basic Data Infrastructure (BDI) supports this through event-driven coordination: a way for distributed parties to align their actions based on real-world events.

The Logistics Event Kit offers a reference pattern for applying this event-based approach in practice. It enables operational visibility, dynamic collaboration, and faster responses to change — without requiring tight system integration or centralized control.

At its core, the approach treats events — such as a delay, a delivery, or a status update — as signals that drive coordination. These events capture the operational reality as it unfolds. When shared with the right parties at the right moment, they enable each actor to make informed decisions, fulfill their role, and stay aligned with the broader process.

1.1 Event-driven coordination

Some benefits of event-driven coordination are the following:

• Reflects real-world dynamics. Plans often change; coordination must follow what’s actually happening.

• Supports flexibility. Events help autonomous systems work together without direct coupling.

• Improves responsiveness. Early signals allow actors to adjust quickly and avoid bottlenecks.

While event-driven models are well known, the BDI framework makes them usable within a federative network. It provides the trust, structure, and agreements needed for sharing event information across organizational boundaries — while preserving data ownership and system independence.

The pages that follow introduce the main components of this approach.

Choreography of Principals and subcontractors: balancing effectivity with security.

1. Choreography of event distribution

In supply chains the chain of business activities starts when a Seller and Buyer agree upon the transaction. This agreement typically includes terms related to transport, insurance, customs, the handover of responsibilities, and payments. The successful execution of this agreement often requires coordination among a large set of actors, including authorities and their subcontractors. This coordination is managed through a "choreography" of actions, where each action is triggered by planned or executed events.

2. Subcontractors and principals

In this context, the Seller and Buyer serve as the Principals, each responsible for their part of the agreement. Typically, each Principal selects preferred contractors to fulfil their portion of the agreement. These main contractors, in turn, become Principals to their own subcontractors, and this chain continues down the line.

The key challenge here is distributing notifications within this dynamic and temporary data exchange network, to ensure effective and efficient coordination of activities, without overburdening the network with traffic.

3. Provisioning an instance

The BDI framework assumes that commercial relationships between Principals and Subcontractors are established before any actual orders are placed. In this setup, URLs are known, and through the DNS discovery mechanism, the URIs of endpoints for each party are also known. Digital identity and trust are established within the respective associations of each party.

Each Principal is responsible for provisioning a temporary network of subcontractors associated with a specific order.

4. Channels

Principals and their subcontractors communicate through channels (a.k.a. topics in a pub/sub setting). There are three kinds of channels:

• Subcontractor specific - often a principal works for different orders with a limited set of partners (preferred suppliers). There is a private channel between the principal and each partner. These channels are bidirectional (both the principal and the subcontractor can post notifications). A subcontractor specific channel exists as long as the relation between principal and subcontractor exists and hence may exceed the lifetime of a specific order.

• Order specific - a principal creates a channel specific to the execution of a particular order. Such a channel is unidirectional: the principal is the only party who is allowed to post notifications, all involved subcontractors subscribe to this channel and are therefore notified of each message sent by the principal. Order specific channels exist for the duration of the order only.

• Subject specific - often orders get bundled and unbundled during transport, for instance, being added to a container or ship. In these cases, the subject of the events shift from order to container to ship and, eventually, back to container and order. These are unidirectional channels: the origin (transporter, terminal etc.) of the events is the only producer on these channels. It's up to the consumer of the events to switch channels when the subject shifts, for instance, when a container is loaded on a ship. The duration of the channel depends on the lifetime of the subject.

The latter subject specific channel may be considered a low-level channel. The events on these channels need more advanced tracking, due to the shifting subject, and may end up repackaged on the subcontractor / order specific channels.

5. Semantics and Lifecycle

In order to allow a consuming party to correctly interpret events, the publishing party must clearly document:

• Which events are published;

• When events are published;

• What it means when they are published;

• What sequences of events can be expected;

Translating, repackaging, and/or combining events for consumption by other systems will rely heavily on the above documentation and need documentation of their own. In addition these processes also need to document:

• What information is lost and what is the consequence of that loss;

• What information is added, for example, to fulfil a constraint to the target system.

6. Bootstrapping

The Principal publishes a specific notification to a subcontractor, with metadata on “Request order”. The data accessed by the subcontractor includes the details of the order request. The subcontractor responds with a notification containing metadata on order acceptance. The Principal then accesses the data to confirm the subcontractor's acceptance and any additional details provided.

7. Common Order Log

Upon confirmation, the Principal adds the subcontractor as a subscriber to the common Order Log and posts this event in the Common Order Log. The Common Order Log creates notifications to all relevant parties when an event is posted by (or on behalf of) the Principal.

8. Provisioning of Closed Network

To secure and streamline interactions within the temporary network, the Principal sends a JWT (JSON Web Token) to the subcontractor. This "Subco" JWT contains:

• Order Information: Specific details about the order.

• Role of the Subcontractor: Defining the subcontractor's role within the order.

• Data Access Rights: Permissions tied to the subcontractor’s role, aligned with an agreed-upon or standardized semantic model.

The subcontractor uses this JWT token when interacting with other subcontractors within the context of the order. This token allows other subcontractors to:

• Validate the Subcontractor’s Role: Confirming that the subcontractor is part of the temporary network set up by the Principal.

• Verify Access Rights: Ensuring that the subcontractor has the appropriate rights to access data associated with the order.

The Principal repeats this process with all subcontractors until the provisioning of the network is complete.

9. Dynamic modification

In real-world operations, it may become necessary to change subcontractors dynamically; removing one subcontractor from the network and replacing them with another.

To facilitate this, the Principal posts a notification of the change to the Order Log. This notification is then distributed to all parties involved in the network. The following steps are taken:

• Remove the old subcontractor: The old subcontractor is removed from the subscription lists, cutting off their access to further notifications and data.

• Revoke the old JWT Token: The JWT token that was issued to the old subcontractor is revoked, ensuring that they no longer have access to the network's resources.

• Add the new subcontractor: The new subcontractor is added to the network, receiving the necessary notifications and access rights.

10. Managing the number of interactions

One potential pitfall of distributing notifications of events is the exponential increase in the number of interactions (API-calls, identity checks, authorization checks) with the number of participants/subcontractors in the temporary network.

There are three strategies to manage the number and costs of interactions.

10.1. Star-like interactions with Principal

A subcontractor communicates most of the notifications to the Principal, one-on-one. The Principal filters notifications and posts only relevant events or notifications from all parties to the Common Order Log.

This limits the information overload while ensuring that all relevant parties are informed of relevant events.

10.2. Low-risk data in notification

Notifications are sent to a closed network of parties. Some data of an event may be low-risk and can be embedded in the notification within the closed network: for example "ETA delayed by 12 hrs". The straightforward embedding reduces the need to collect the information at the source.

In this strategy, the value of the data is used to simplify the process, increasing efficiency and reducing costs. It is a business decision to balance the loss of value of the data and the gains of increased efficiency.

10.3. Caching authorization results for common roles

Common roles have known authorization rules. The results of data selection for these roles may be cached near the BDI-API, reducing the need to evaluate policies in the Authorization Register.

10.4. Subject versus Order / Subcontractor specific channels

The use of subject specific channels (see also ) can drastically reduce the amount of events triggered because, for instance, an event about transport equipment relates to multiple orders and (in some cases) subcontractors.

11. Creating an auditable log

Once all tasks related to the order have been completed, the Principal generates a signed log. This log serves as an official record of all events and actions that took place during the order's execution.

• Notification of Log Availability: A notification is sent to all parties involved, informing them that the signed log is available.

• Access and Retention: Subcontractors can access this signed log and retain a copy for future reference, whether for compliance purposes or in the event of a dispute.

This structured audit trail ensures transparency, accountability, and the ability to review and verify all actions taken during the course of the order, providing a solid foundation for trust and compliance in the BDI framework.

12. Closing the Order and Dissolving the Network

Once all tasks related to the order have been executed, the Principal initiates the closure of the order by:

• Distributing a Closure Notification: Informing all parties that the order is complete.

• Removing Subscriptions: Subscriptions to the Order Log are removed after a specified period.

• Revoking JWT Tokens: Invalidating the JWT tokens to dissolve the temporary network.

This process ensures the temporary network is securely dismantled, preserving the integrity and confidentiality of the data exchanged during the order's execution.

13. Querying for missed events

Parties may be late subscribing to channels for different reasons or need to recover from system failures, in those cases these systems need to have access to earlier events they have missed to (re)build their state.

14. Audit trail

Event driven coordination requires a means to “go back in time”, inspect earlier events and have an audit trail. One obvious reason is when a subcontractor is changed: the new subcontractor has to be able to quickly come up to speed on the history of events. The second is to have a common reference for either compliance or settling of disputes.

1. Summary

Notifications of events are the digital representation of the result of events in the physical world: for example, ‘expected arrival time issued’, ‘container has been unloaded’. So, a notification of an event is the result of an event, not the event itself, events occur in the physical world, notifications of events occur in the digital world.

Notifications are published on channels (a.k.a. topics), to which all involved parties can subscribe. Following a publication of a notification, all subscribers will receive it.

Take the event that a full container has been loaded onto a container ship in China. All parties involved in the Netherlands, from the port authority, the container terminal, forwarders/processors, Customs, hinterland transporters to the shipper that ordered the goods, want to track the status of the ship and this container from that moment onward. And they create events because of this knowledge: a declaration, reservation of capacity, etc.

An important concept of the BDI is that involved parties can subscribe to channels and their ‘daughters’: they receive all notifications of events that are published to that channel. If required (and permitted) a party can request more data from the source. The concept of notifications of events and subscribing to them is broadly applicable: take the schedule for a building site for example. It is highly effective for all the suppliers and subcontractors if new things or changes to the schedule are automatically identified.

2. Purpose of the building block

3. Concepts

Consider the following concepts that play a role in the notification pub/sub service:

A producer publishes an event to the router, which filters and pushes the events to consumers. Producer services and consumer services are decoupled, which allows them to be scaled, updated, and deployed independently. This approach has many advantages, such as:

4. Choreography

In supply chains the chain of business activities starts when a Seller and Buyer agree upon the transaction. This agreement typically includes terms related to transport, insurance, customs, the handover of responsibilities, and payments. The successful execution of this agreement often requires coordination among a large set of actors, including authorities and their subcontractors. This coordination is managed through a "choreography" of actions, where each action is triggered by planned or executed events.

The choreography describes which channels there are and which parties can subscribe to them. As the design of an appropriate choreography can be challenging and has major impact on the efficiency of the pub/sub service, this subject is discussed in detail in a separate .

5. Implementation Considerations

According to EPCIS (ISO/IEC 19987), a notification contains at least the following four aspects: what, where, when, and why and an optionally fifth: how.

• What — to which object or entity does this event primarily relate (e.g. pallet, order, truck, wagon, etc.)?

• Where — at which location did the event take place (warehouse receipt door, terminal access)?

• When — on what date and time did the event take place?

However, in line with BDI federation rules, data on these aspects is not always added directly to the notification. In instead, only a link to the source may be included, and interested parties can get the necessary data at the source.

6. Interlinkages with other building blocks

There are links with the following building blocks:

7. Elements and their key functions

The following pattern describes the typical interaction with the Pub-Sub service. First, we enter a configuration phase:

• The data owner creates a new notification channel at the service. The channel name is the EventType, in this example, of the data the owner wants to share.

• A data consumer asks permission to subscribe to the channel “EventType from Data Owner” using the service. The data consumer will then be notified if the data owner triggers a signal on the event channel he is interested in.

• The request for subscription is communicated back to the data owner. The data owner decides if the request should be granted. Fi. based on several queries to the different registers part of the BDI like the Reputation and Qualification registers. Data and trust sovereignty means, in this case, that the owner always has control over who has access to his data.

In this case the data owner grants permission to the data consumer to subscribe to his EventType channel.

All is now setup for the actual event-based communication:

• An event occurs at the data owner, and he sends a trigger through the channel “EventType from Data Owner” to all his subscribers.

• The trigger is also sent to the data consumer who can use the embedded meta-data in the event trigger to decide if he wants to request the associated data of the event at the data owner.

• The data consumer decides to request the data at the owner’s location using the link sent along as part of the trigger.

8. Core design decisions

• Granularity of event channels: The granularity of the event channel is an important issue. Depending on the chosen strategy one would either create the need for extra filtering logic at the consumer or at the owner. The specific use case should be leading on how fine-grained the channels should be setup.

• Multiple event brokers in a network: It is yet unclear how multiple event brokers, from different suppliers, would work together in a decentralized network. Most available open and commercial solutions do support multiple brokers but typically only the ones from the same supplier.

9. Further reading

• EPCIS (ISO/IEC 19987:2024)

• DCSA:

1. Introduction

When interacting parties do not share an existing semantics standard, the use of LEO is required. Note, however, that it is possible for BDI parties to use any other framework.

For example, consider a multi-model trip from a manufacturer to the BCO that partly travels over sea. The parties involved in the sea trip may, in interactions with one another, make use of the DCSA standard. This is a well-known standard that has been in use for a long time. For the communication with other stakeholders, however, DCSA may not be the best standard, as these parties are not familiar with it or are not currently using it. Therefore, LEO may be required for the interactions with these stakeholders.

1. Introduction

Over time, different sectors have developed their own operational “languages” to describe and manage their activities. This fragmentation is evidenced by the multitude of global and local data standards across logistics, trade, and transport. The BDI explicitly recognizes this landscape and emphasizes that participants should:

1. Align with sector-relevant standards where possible, rather than duplicating efforts or creating isolated models. Examples of well known and governed standards are (non exhaustive):

The "Event Demo" (Demo Phase 3) further advanced the "Trusted Goods Release" process by integrating real-time event notifications. This phase demonstrated how event-driven updates, particularly gate-out events, could be leveraged to improve logistics transparency and coordination. Utilizing an event broker (Apache Pulsar) and building on the iSHARE framework, this demo highlighted the importance of timely, secure data sharing in logistics processes.

In Demo Phase 3, the focus was on implementing an event-based notification system to communicate critical logistics events. Key components included:

1. Setup and Registers:

1. Summary

BDI defines Common Roles as the standardized roles for activities in a specific sector or type of supply chain. They form the basis for standardized role-based authorizations, lowering the effort for maintaining authorization rules. .

This type of roles is sector specific, as opposed to BDI Roles that are part of the building blocks

See Policy Agreements.

Sector specific Common Roles

Common roles define operational responsibilities within supply chains, helping to create standardized policies, particularly Data Access Policies.

Each specific sector (type of cargo, modality) has common roles that are well understood and recognized. The same applies to data elements that a role needs to have access to, in order to be able to perform a task.

Defining these common roles (like truck driver, customs agents, inspection agent, forwarder, terminal planner, etc. etc.) reduces the cost of interactions between entities. An undefined role needs custom definitions for the combination role-data access policy: a labour-intensive action.

Managing access rights is simplified by standardization.

Members of different Associations that have different policies per common role, or different roles, will need to align these policies and roles to become interoperable. It is expected that a natural convergence on common roles in a sector will appear over time: Associations will agree upon shared common roles and policies if this benefits their business objectives.