The Core Principles

Based on these observations, seven principles were formulated to guide the design of the architecture. These are:

1. Support of operational activities in the physical economy

2. Time-sensitive event-driven coordination between entities

3. Zero Trust

4. Dynamic Data Life Cycle

5. Data sovereignty by maintaining data at the source

6. Subsidiarity of governance

7. Coherent security

Principle 1: Support operational activities in the physical economy

The BDI Framework is optimized to support value creation in the physical economy. The focus is on the data exchanges necessary for operational activities of (multiple, specialized) entities that:

• need to coordinate and report their activities to fulfill their commitments to their principal(s)

• need to perform a public task, like verifying compliance to regulations of activities of others

In the physical economy legal entities are represented by both IT-systems/processes and natural persons. To be able validate the mandate and if necessary the professional qualifications of the representatives is imperative, as the legal entities assume the liability and accountability for actions of the representatives.

Principle 2: Time-sensitive event-driven coordination between entities

Coordination of operational activities is time-sensitive and drives a large part of data exchanges between entities, even if these entities have no direct contractual relationship. Data exchanges therefore cross organizational boundaries, between multiple entities, each with its own security policy and protective measures such as firewalls.

Data exchanges are triggered by events in the physical economy. Events may be relating to planning agreements and updates, payments, compliance, physical activities and the like.

Whenever an event occurs, a notification about this event can be generated. A notification is a digital message containing meta data about the event. This notification is distributed to a selective group of entities using a publication/subscription based technology.

Notifications are published on a channel and parties may choose to receive notifications on a channel (subscription). The set of channels and the rules on allowed subscriptions (defining who is able to subscribe on a channel) must be defined before hand.

Note that data associated with an event is not included in the notification. Authorised parties can retrieve data at the source.

Principle 3: Zero Trust

Trust is an important issue in doing business. However, trust is not easily established. Each entity in a cooperative network may have its own policy to assign trust to its business partners, which may even vary between interactions. To support these flexible trust policies, the BDI framework is based on perimeter-less, zero trust principles.

Zero Trust:

• doing business in a global economy requires flexibility in choosing business partners.

• entities have to be able to deal with previously unknown sub-subcontractors that pop-up when they are subcontracted by another entity in the same virtual instance.

• each entity is autonomous in deciding what an acceptable risk/reward trade-off is, per transaction.

Perimeter-less Trust:

• trust is not delegated to a Trust Anchor or an Authority

• authentication does not equal trust

• trust is contextual and situational: for instance on how sensitive the data-element is

• reputation is an important aspect of assessing trust

• federation of trust information exchanges between entities or groups of entities

Principle 4: Dynamic Data Life Cycle

Data relevant for operational activities has a dynamic life cycle: from proposed, planned, to in transit, modified, to registration of as executed.

The BDI acknowledges the stadia and fluidity of coordination in real life.

Principle 5: Data sovereignty by data at the source

Data sovereignty requires control of data access by the data owner.

Notifications of events are generated by the “owner” of an event and the corresponding data, and distributed to a selective group of entities . Notifications communicate meta-data of an event to a selection of stakeholders, and allow them to link back to the data source to request specific data of the event.

The request itself allows the data owner to:

• Track what entity has requested access

• Authenticate the entity

• Asses the trust in this context

• Authorize selective access

Principle 6: Subsidiarity of governance

It is common practice in most business sectors to have specific sector agreements (legal, organizational, semantic) such as:

• standards

• regulations

• rules of engagement

• processes

• roles and responsibilities

Standardization and generalization is a means to improve efficiency and reduce costs. But innovation and competitiveness depends on differentiation, specialization and the freedom to invent new offerings.

Subsidiarity is a principle of organization that states that issues should be dealt with at the most immediate or local level that is consistent with their resolution.

The governance recommendations of the BDI Framework follow the subsidiarity principle rooted in associations: common agreements between entities need to fit the structure of the market, legal frameworks and local habits and should not be defined at higher overarching levels.

Principle 7: Coherent security

The (IT- and operational) security of the data exchanges relies on the coherence of:

• the individual components and protocols as implemented by each entity in the association

• the interaction of components and protocols

• the interoperability of logging and other security audit trails

• operational security and governance measures

The BDI provides for a coherent security framework among these disparate entities

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 which play a role in the design of the architecture. We start with some observations about data in a logistic 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 bdinetwork.org for a full account of these concepts.

Observations

• The data exchange patterns in typical operational networks are a result of “doing business” have specific characteristics:

  • The network of involved parties is driven by the fulfillment of an assignment - these networks are temporary and fluid, that is, members are added whenever necessary and the network is dissolved when the job is done.

  • Data exchanges are between members of a closed group, i.e. the members are vetted in advance.

  • There can be time constraints on the exchange of data.

• A common data exchange infrastructure for operational networks should support:

  • Dynamic instances

  • Multiple concurrent instances

  • Controlled event-driven exchange

• Event-driven exchange of operational data within an instance must be:

  • Efficient: no polling, no unnecessary retrieval

  • Effective: easy distribution to multiple parties simultaneously

  • Controlled:

    • Limited exposure to malicious actors.

    • Only authorized parties can retrieve information.

    • Role based data access.

    • The Data Owner tracks access, providing a clear audit trail.

• The value of data:

  • Data has value

  • Data owners want to protect and monetize this value

• The importance of trust in global business networks

  • Identification authentication and authorization play an important role in establishing trust.

  • Zero trust - do not trust anyone before trust is established.

  • Perimeterless trust - do not base trust on membership of a closed group of trusted parties

BDI Stack and KITs

To assist the creation of applications according to the architectural principles, BDI defines many building blocks, where 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 funtionality later as the need for it arises.

Summary

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.

Purpose of this building block

Concepts

Implementation Considerations

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

Interlinkages with other building blocks

• Digital Identity

• Authentication

• Authorisation

• Association Register

• Zero Trust Check

Core design decisions

The iSHARE Trust Framework provides a comprehensive description of what iSHARE calls Certified Roles. The Common Roles of the BDI are derived from these descriptions, such as:

• The role of an Authorisation Registry

• The role of Identity Provider

Further reading

https://framework.ishare.eu/is/framework-and-roles

https://dssc.eu/space/BVE/357075333/Data+Sovereignty+and+Trust

https://framework.ishare.eu/is/functional-requirements-per-role

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 establishing agreements, coordinating actions and handovers, controlling access to resources and data, and ensuring compliance with authorities. The challenge is to increase effectiveness by automating these exchanges and increase operational visibility and transparency.

Resilience, efficiency, dealing with scarce resources and transparency require more, better and timely information. In order to keep the administrative burden acceptable (especially for SMEs that carry out many of the operational activities) despite the call for more information, more automation is needed: automation of the exchange of information.

The Basic Data Infrastructure Framework (BDI) is an infrastructure framework for controlled data sharing, supporting automated advanced information logistics between entities acting in the physical economy.

The BDI is a principles-based framework (as opposed to rule-based). Adoption is voluntary, there is no minimum or compliance treshold, the transition towards adoption of principles, components and Kits is a business decision.

To file a change request, submit an issue here: https://github.com/Basic-Data-Infrastructure/BDI-change-requests

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 that is subject to continuous change:

• Legislative and regulatory changes

• Technological advances

• Emergence of new application areas

• Previous experience and lessons learned from previous projects

• Changes in business processes

Such environmental changes may call for changes in the BDI Reference Architecture but as these changes may impact many stakeholders, they have to be managed carefully. The BDI Change Management and Release Management Processes are introduced for this purpose.

Scope

Change and Release Management applies to the following assets:

• The BDI Framework documentation

• The BDI Developer Portal, 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.

Core principles

The Change and Release Management Process must be transparent, predictable and fair, as described below.

The 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 (note, however, that associations, at their discretion, can decide not to comply with the new version but rather follow the old one).

Process for RFCs

The following diagram describes the process for managing RFCs.

Roughly the RFC transitions through the following phases:

1. Identification: a stakeholder (could be the BDI Product Owner itself) identifies a required change or opportunity for improvement.

2. Registration: the stakeholder (possibly supported by the Product Owner) describes the RFC and registers it.

3. Discuss: the Product Owner discusses the RFC with the Expert Group. The Expert Group and Product Owner formulate an advice on the RFC for the Architecture Board.

4. Decision: the Architecture Board decides whether or not to start impact analysis, using the advice received from the Expert Group and Product Owner.

5. Schedule for impact analysis: the Product Owner schedules the RFC for impact analysis.

6. Impact analysis: the Product Owner, supported by the community and the BDI organisation, performs an impact analysis.

7. Discuss: the RFC and the impact analysis are discussed with the Expert Group. The Expert Group and Product owner formulate an advice on the RFC and the impact analysis for the Architecture Board.

8. Decision: the Architecture Board decides whether or not to accept the RFC and schedule it for implementation.

9. Schedule for implementation: the Product Owner schedules the RFC for implementation.

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

Documents for RFCs

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]

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

• Minor other improvements

Process for Minor Changes

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

Roughly the MC transitions through the following phases:

1. Identification: a stakeholder identifies a potential change and notifies the Product Owner.

2. Describe and register: the stakeholder registers and describes the required MC.

3. Decision: the Product Owner decides whether or not to accept or reject the MC. An MC could be rejected for example because it does not meet the criteria for an MC and should be considered as RFC.

4. Schedule for implementation: the Product Owner schedules the MC for implementation.

Templates for MCs

The MC process is supported by the following templates:

• MC Description [to be drafted]

Release Management

The Change Management Process results in a backlog of RFCs and MCs that require implementation.

The Release Management Process is about selecting changes for implementation and bundling those in releases, called versions.

Version types

The following two types of versions are defined:

• Major new version: a version that contains changes with potential impact on stakeholders.

• Minor new version: a version that contains changes with no or very minimum impact on stakeholders.

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. Scoping: the Product Owner selects the initial scope for the major version, by selecting RFCs and MCs from the backlog. The product strategy and/or product roadmap are guidelines for selection.

2. Inform: the Product Owner informs stakeholders and the Expert Group and schedules the release scope as a topic for the Architecture Board agenda.

3. Final scoping: based on feedback from stakeholders, the Expert Group and the Architecture Board, the Product Owner selects the final release scope for the version and informs stakeholders and the Expert group about the scope.

4. Implement: the selected RFCs and MCs are implemented in the assets, leading to a staging version for the next release.

5. Decision: the staging version is scheduled for discussion in the Architecture Board. The Architecture Board decides to release the new major version, or decides that the release needs more work.

6. Release: The major version is released.

Timing requirements:

• The minimum time between step 3 (final scoping) and 6 (release) must be 3 months.

• In special circumstances the Product Owner can decide to follow a fast track process in which this minimum time requirement is not applicable. The Architecture Board must approve this fast track process.

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. Scoping: the Product Owner selects the initial scope for the minor version, by selecting MCs from the backlog.

2. Implement: the selected RFCs and MCs are implemented in the assets.

3. Release: The major version is released.

4. Inform: the Product Owner informs stakeholders about the release.

Release schedule guidelines

The release schedule guidelines for releases of major versions is:

• Maximum release frequency: quarterly

• A quarterly release may be skipped if there are no changes with potential impact on stakeholders are selected and implemented

In special circumstances the Product Owner can decide to create an extra major version release using a fast track release process.

The release schedule guidelines for minor versions is:

• The Product Owner can decide to release minor versions whenever deemed necessary

Version numbering

Versions are numbered as follows: x.y.z.

• With every major version, x or y is updated. Updates of x are reserved for major versions that touch the complete or most of the framework. Updates of y are used for other major versions.

• With every minor version, z is updated.

Version Deprecation Process

• Each major version is marked as deprecated upon the release of a new major version.

• During the 6-month deprecation period, the deprecated version remains available but is no longer actively maintained, except for critical security fixes if necessary.

• After 6 months, the deprecated version reaches End-of-Life (EOL) and is no longer supported.

• Users are encouraged to migrate to the latest major version as soon as possible to ensure continued support and compliance with the standard.

• The Product Owner is responsible for organising the Version Deprecation Process.

Roles and responsibilities

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

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.

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 Register 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.

By implementing the Trust KIT, organizations lay the groundwork for a secure, scalable, and interoperable BDI, making it the most crucial KIT within the BDI ecosystem.

The TRUST KIT is inspired by the iSHARE Trust Framework, and uses some of the concepts and components in iSHARE.

See Authentication M2M and Authentication H2M

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.

Digital identifiers for natural persons are described in Digital Identity (H2M).

In it's implementation, BDI aligns with iSHARE's implementation of digital identities, preferring 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.

2. Purpose of the building block

3. Concepts

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

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:

• Digital Identity H2M

• Authentication M2M

• Authentication H2M

• Authorization

• Association registe

• Zero Trust Check

The most important related Kits and concepts are

• Trust Kit

• Federation Kit

• Boundary Management

6. Core design decisions

A digital identity has to be linked with the legal identifier of the legal entity that :

• controls

• takes responsibility and accountability for the IT-process that uses the digital identity in interactions with other IT processes.

The EORI-identifier is the standard defined by the EC Customs for European entities. EORI stands for “Economic Operators Registration and Identification”. Not all European entities are required to register an EORI. Therefore, only a subset have registered an EORI.

Europe also introduced an EUID which is based on the local European Business Registries. This EUID will be used for the eIDAS 2 European Wallet.

VAT-numbers can also be used to identify organizations. European VAT-numbers can validated on a central site.

Other identifier standards that are in use worldwide are:

• LEI

• DUNS (Dunn and Bradstreet Unique Number System)

In practice it may be necessary for a party or an association to create a cross-reference register that relates an internal (unique) identifier with multiple external identifiers of a legal entity. One legal entity may have an EORI, LEI and DUNS identifier, or more.

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.

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

7. Further reading

• ​DSSC Blueprint building block “Identity and Attestation Management

• https://taxation-customs.ec.europa.eu/customs-4/customs-procedures-import-and-export-0/customs-procedures/economic-operators-registration-and-identification-number-eori_en

• ​https://e-justice.europa.eu/489/EN/business_registers__search_for_a_company_in_the_eu

• https://ec.europa.eu/taxation_customs/vies/#/vat-validation-result

• D-U-N-S Number Navigation Home – Dun & Bradstreet (dnb.com)

• https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei

• ​https://www.w3.org/TR/vc-data-model-2.0/​

• ​iSHARE Framework documentation, specifically on the topic of identities

• Identification by EORI​

• ​The role of Identity Provider​

• ​The acknowledgment of eIDAS

• The specifications for the Identity Provider role​

• ​iSHARE Developer Portal documentation​

See Digital Identity M2M and Digital Identity H2M

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

This building block interlinks with:

• Digital Identity & Identifiers

• Authorizations

• Discovery

• Federation

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.

4. Alignment with IDSA. To be defined.

5. The use of (other) PKI schemes.

6. The use of Decentral Identifiers.

7. Federated Authentication through OAuth 2.0 Attestation-Based Client Authentication

In the BDI network, a reputation system 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 authorization 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 association 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. https://dhs-svip.github.io/requirements-for-decentralized-identity/TrustArchitecture/.

8. Further reading

OAuth2: IETF RFC 6749

OAuth 2.0 Mutual-TLS: IETF RFC 8705

iSHARE: Authentication

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

3. Concepts

Boundary Management for humans relates to:

• A human, acting as representative for a legal entity desiring access to data or an application owned/controlled by another legal entity

  • For example: login to an application

• A human, acting as representative for a legal entity desiring access to a location owned/controlled by another legal entity

  • For example: entering a protected zone

• A human, acting as representative for a legal entity involved in transferring as asset (cargo) and/or liabilities for the asset between the two legal entities

  • For example: picking up cargo by a transporter

The building block ensures that the digital identity of the human involved in (digital) interactions can be :

• Authenticated

• Related to Representation evidence

  • In what role and capacity, on behalf of which legal entity, with a specific mandate

• Related to Professional Qualification evidence

  • Evidence of professional qualifications

The core concept is that identity is dynamically related to (potentially multiple concurrent) representations for (potentially multiple concurrent) legal entities: the legal entity assumes liability and accountability for actions of the human.

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) to "prove" their 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 instance by 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; e.g. 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. State issued identifiers (like the Dutch BSN) are often not allowed to be used outside the Government.

In B2B processes, business email addresses are preferred. These should be using an organizational domain name (e.g. @myorganization.com) and a personal prefix (e.g. piet.jansen@ or s.jones@). The use of shared email accounts must be avoided. Also the use of general domains (e.g. @gmail.com) should be avoided. Typically, the user must demonstrate during the setup of the account that she has access to the business email address. This provides additional trust that the user has a business relation with the organization which owns the domain name.

(Mobile) telephone numbers can also be used to identify / verify the user. During the setup the user demonstrates that she has access to the number. At a later moment, the user can demonstrate again that she still has access to this number.

The push for electronic Wallets provides a new means to store and show a digital identity that can be authenticated.

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 this 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. Identity Providers differ how the deal with this situation. They could assign different identities for each of the represented organizations (e.g. applying different business email addresses or issuing separate secure cards per organization). Al alternative is that the human user can select the organization she represents in a specific use case.

3.5. Professional Qualifications

In many cases the human needs to have adequate professional qualifications for the task at hand: professional drivers license, safety training, dangerous goods handling, etc.

The B2B Identity Provider could also store and share professional qualifications of the user. In a wallet this is typically stored as a verifiable credential.

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.

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

5. Interlinkages with other building blocks

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

The related building blocks are:

• Digital Identity H2M

• Authentication M2M

• Authentication H2M

• Authorization

• Association register

• Zero Trust Check

• Representation Register

• Professional Qualification Register

The most important related Kits and concepts are

• Trust Kit

• Federation Kit

• Boundary Management

6. Core 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.

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

Summary

Purpose of the building block

Concepts

Authentication, Trust and Authorization

The concepts Authentication, Trust and Authorization are closely related but not identical. To describe their relations, we assume that a party A wants to gain access to data owned by party B. During authentication, party A provides its identification and evidence of that identification. Such evidence could be passwords, two-factor id's, PKI-based certificates, or bio-metric data such as iris scans and finger prints. Party B evaluates the evidence and assigns a trust level to A. Based on this trust level, B assigns permissions to certain parts of the data. It will be clear that higher trust levels result in more permissions.

To assign a trust level, party B gathers data about party A. This data includes, but is not limited to, nature of the evidence (PKI certificates are trusted more than simple passwords). It can also include a reputation score built by A during previous interactions.

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

Risks

Insufficient authorization may cause data leaks to parties that are not trusted.

Inter-linkages with other building blocks

This building block has links to:

• Representation Chain

• Association Register

• Data Licenses

• Authentication M2M

The Authorization building block uses information from these related building blocks to make a decision whether or not to trust a partner in a transaction.

Elements and their key functions

While entering into a transaction, each participant involved in the transaction will decide if it trusts the other party.

To make a decision on trust, the party will use relevant and available information. The BDI provides a framework for four input elements for this decision:

1. Trust based on the membership of an Association, one of it’s parent Associations or the root BDI Network.

2. Trust based on the level of assurance of the digital identity of the party.

3. Trust based on the reputation of the Member as provided by the Reputation Model.

4. Trust based on (granular) Authorizations provided by a Data Owner.

Core design decisions

The four inputs for decision making are supported by the BDI trust input elements as follows.

1. Trust based on association membership

Information gathering

This input element uses input from the building block Authentication M2M. This building block provides insight into what association and (optionally) what parent associations a participant is a member of.

Information processing

To facilitate easier processing of the acquired information, a party can:

• Choose to follow Association business logic, in this case the Association has defined how to translate Association membership into trust levels.

• (If allowed by the Association) choose to follow it's own logic.

2. Trust based on the level of assurance of the digital identity of the party

Information gathering

This input element uses input from the/ building block Authentication M2M. This building block provides insight into the level of assurance of the party.

Information processing

To facilitate easier processing of the acquired information, a party can:

• Choose to follow Association business logic, in this case the Association has defined how to translate Association membership into trust levels.

• (If allowed by the Association) choose to follow it's own logic.

3. Trust based on reputations

Information gathering

The Business Partner Reputation Model forms the basis for acquiring reputation information. It is not yet defined how information on reputation of a party can be acquired.

Information processing

Assuming that information on the reputation of a party is available, a party can:

• Choose to follow Association business logic.

• (If allowed by the Association) choose to follow it's own logic.

4. Trust based on (granular) authorizations

Authorizations provide a way for a Data Owner to specify in great detail which Data Consumer is allowed to consume data on its behalf at a Data Service Provider. From a data sovereignty perspective, Authorizations provide the highest level of 'trust' and best basis to enter into a transaction up, when transactions are happening between Service Consumers and Data Service Providers.

Information gathering

In terms of the technical specifications for Authorizations, the BDI Framework is inspired on the iSHARE Trust Framework. The iSHARE Trust Framework uses the term “delegations” for the concept that in BDI is called Authorizations.

• The framework defines the role of an Authorization Registry

• Entitled Parties are enabled in exercising data sovereignty by providing delegations (as described in the generic use cases) to parties to use their data

• Licenses specify the legal boundaries for the usage of data by a Data Consumer

• The structure of delegation evidence is defined in the framework and the technical requirements for APIs providing delegation evidence on the iSHARE Developer Portal.

Functionally authorizations can:

• Be provided by the Data Consumer when requesting to consume a service at a Data Service Provider.

• Be requested by the Data Service Provider when a Data Consumer requests to consumer a service.

BDI does not define in what way an Authorization Registry needs to store policies regarding delegations.

Trust in case of a Data Service Provider acting on behalf of a Data Owner

A specific situation occurs when a Data Service Provider acts on behalf of a Data Owner. The Data Service Provider is assumed to have a business relationship with a Data Owner in which the rules for sharing data on behalf of the Data Owner are established. Beside the input elements that can be provided using the BDI Framework, a Data Service Provider and Data Owner can agree on other inputs used to make a trust decision.

Data Service Providers and Authorizations

Data Service Providers processes data on behalf of Data Owners. Data Owners should make a careful choice which Data Service Providers they use as they have to consent on the Terms & Conditions of the Data Service Provider. These could consists of generic Terms & Conditions of the Data Service Provider and additional Terms & Conditions for the specific data.

Data Service Providers should cater for adequate authorization capabilities to control which organisations / users have access to which data. These authorizations can be registered in an Authorization Register of the Data Service Provider.

Data Sharing Triggers

The sharing of data between organisations can be triggered by:

• Process steps which leads to the sharing of data. The data sharing is a side effect of the process flow. For example: a Transport Company receives a transport order from a Customer. Therefore the Transport Company needs access to the transport order data. The authorization for data sharing is an implicit result of the involvement in the business process.

• Providing explicit permission to share the data with another organisations. For example: the permission of a Terminal to share all container shipment related data with CBS.

Patterns for authorization evidence

Data Service Providers could use external information in an external Authorization Register (AR) under the control of the Data Owner to provide access. This external information can be retrieved using different patterns including:

• The permissions are synced between the AR and the Data Service Provider. The Data Service Provider holds alocal copy which is used to provide access. Synchronization can be done by frequent polling or event updates.

• The (signed/sealed) permission is included in the data request from the Data Consumer. The Data Consumer has retrieved this permission from the Data Owner. Signing/Sealing is required to verify that the permission has been given by the Data Owner.

• The Data Service Provider polls the external Authorisation Register at runtime during a data request to check the permission. In more complicated scenario’s Authorisation Registers could refer to other Authorisation Registers validating the chain of permission to it’s source.

Advantages and drawbacks

Guidance for trust decision making

It could be helpful to create a trust decision matrix, to improve manageability of decision rules. The approach would be:

1. To classify data with a required assurance level (for instance low, medium, high).

2. To assign required trust levels to an assurance level.

This could be done at a party's level or at an Association's level.

Example of a trust decision matrix:

Business rules could also consist of a combination of the various trust aspects. For instance that either medium association trust OR medium reputation trust is required.

Future topics

• For improved discoverability of the parents of a BDI Association, the BDI Association Register could be improved by returning this information for every party lookup directly as part of the party information.

• To improve interoperability between associations, BDI might consider to define standardized rules for service/data classification and a best-practice approach for trust processing.

Case Study

Further reading

This building block has been drafted using the following sources, that provide opportunity for further reading:

• DSSC Blueprint building block “Participation Management”

• iSHARE Framework documentation

• iSHARE Developer Portal documentation

• iSHARE Dataspace Template, section Access & usage policies and enforcement

1. Summary

2. Purpose of the building block

3. Concepts

3.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 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.

3.2. Data Access policies

Data access policies define who or what role can access specific data elements and under what conditions.

Common roles are linked to common data access policies.

A data access policy can be linked to a person: this is a specific authorization.

3.3. Data Licenses

Data licenses define the rights and responsibilities of a party that gains access to data.

These licenses address questions, such as 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, including regulate the permissible actions and behaviours related to the use of the accessed data, ensuring that control over the data is maintained even after it has left the trust boundaries of the data owner.

Common global data licenses may be re-used, or local specific data licenses may be developed that are specific for a sector or geography.

4. Interlinkages with other building blocks

• Digital Identity

• Authorization

• Authentication

• Onboarding, Terms and conditions

5. 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:

• Association-Specific: These agreements are tailored to meet the unique needs of the association, which may vary by sector, geographical location, or specific theme.

• Common: Utilize a standardized set of edge agreements available in the BDI repository. For instance, the set of data licenses which are described by iShare.

• Global: Seek to align these policies with those used in other sectors and standards whenever possible, promoting convergence and consistency.

6. Further reading

• https://dev.ishare.eu/reference/delegation-mask/policy-sets

• https://framework.ishare.eu/detailed-descriptions/functional/licenses

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 we focus 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.

The complexity of H2M authentication is increased by privacy regulations: authenticating a human reveals his/hers identity.

2. Purpose of the building block

3. Concepts

The use cases relate to Boundary Management:

• A human, acting as representative for a legal entity desiring access to data or an application owned/controlled by another legal entity

  • For example: login to an application

• A human, acting as representative for a legal entity desiring access to a location owned/controlled by another legal entity

  • For example: entering a protected zone

• A human, acting as representative for a legal entity involved in transferring as asset (cargo) and/or liabilities for the asset between the two legal entities

  • For example: picking up cargo by a transporter

The building block ensures that the digital identity of the human involved in (digital) interactions can be authenticated: 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 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 OpenID Connect protocol, 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).

4. The OP authenticates the User and obtains authorization.

5. The OP responds with an Identity Token and usually an Access Token.

6. The RP can send a request with the Access Token to the User device.

7. The UserInfo Endpoint returns Claims about the End-User.

Source: https://openid.net/developers/how-connect-works/

Organization can use (a) an internal Identity Provider (b) an exclusive external Identity Provider (c) 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’. eIDAS was launched to help remove digital borders between countries in the EEA, while ensuring the security of digital systems and protecting people’s privacy.

There are various national eID schemes. In the Netherlands the national eID for persons is called DigiD and eHerkenning is used for persons representing a legal entity.

There are strict regulations on the use of eDIAS. DigiD can't 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 recognised 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 / Pyhisical 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 Organisational Digital Identity Wallets (ODIWs).

Source: https://coe-dsc.nl/wp-content/uploads/2024/01/CoE-DSC-eIDAS-impact-on-data-spaces.pdf

6. Interlinkages with other building blocks

This building block interlinks with:

• Digital Identity & Identifiers

• Authorizations

• Discovery

• Federation

1. Summary

2. Purpose of the building block

3. Concepts

The BDI framework emphasizes perimeterless trust, allowing each data owner to determine whom they trust. Trust registers and identity mechanisms are local and adaptable, offering flexibility in interoperability and endpoint discovery.

There is no overarching Authority to enforce the certification of interfaces, manage onboarding processes, or ensure adherence to data licenses. Compliance within the BDI framework is entirely voluntary, motivated by the practical benefits and business value it offers. The framework supports varying global and local adaptations in identity verification and trust levels.

Registers of trusted entities are typically local or individual. For example, a platform or company may maintain its own register of trusted partners. If the need for interoperability within a group grows, a common register can be established, often through a BDI Association. (Association Register).

The BDI framework provides a federated mechanism for previously unknown entities to identify themselves to a data-owning party. This allows the data owner to verify the entity’s claims and decide whether sufficient trust exists to proceed with the interaction.

Although it is possible to start without any governance structure, it is recommended but not required to develop a formal governance structure per group of entities that share common agreements, terms and conditions, policies, data licenses, semantics of events, trust scores and so on.

A “Group of groups” as an overarching governance structure may also be beneficial, as an option.

3.1. BDI Association

A BDI Association is a local entity formed by a group of participants within the framework. The specific legal structure of an Association can vary—it might be a foundation, cooperative, or any other form. 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, treating members from other Associations as untrusted by default until trust is established.

The local nature of BDI Associations is important because trust and reputation are often tied to proximity and frequency of interaction. Additionally, legal systems tend to be national or trade-bloc dependent, making localized Associations more effective in managing trust and reputation within these frameworks.

The association is most likely (but not by definition) local because :

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

• Legal systems are national and/or trade-bloc dependent

  • UK Law and NL/EU law as an example

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.

3.2. Efficient trust management

The local BDI Association can be the foundation of effective and efficient trust management in a perimeterless, zero-trust environment. Zero-trust principles mean that BDI Associations do not trust anyone outside their own members and use all four pillars of trust to assess interactions with others outside of their community.

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;

  • outsiders that commit themselves to specific legally enforceable rules set by the association become preferred partners

  • other (sister-)Associations can have a trust score, starting with verification of public key ownership of the sister Association

3.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)

• verifying that legal contracts are signed by functionaries with a mandate

• verifying the compliance and security of the IT applications they use (conformity tests)

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

3.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.

• Terms and Conditions: These define standardized contractual clauses, such as Edge Agreements, which are localized terms that improve operational efficiency.

• Policies: Data access is authorized by the Data Owner based on the role of the requesting party. Standardizing these policies within a sector can reduce the management burden.

• Data Licenses: These define the rights and responsibilities of parties accessing data. For example, an e-commerce transporter may be prohibited from retaining or reusing receiver data. Data licenses can be legally enforceable if included in the onboarding process.

5. 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.

6. Interlinkages with other building blocks

• Terms and Conditions

• Policies

• Edge Agreements

• Data Licenses

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

• registering preferred business partners in a federated environment

2. Purpose of the building block

3. Concepts

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

Association - Legal entity that serves as trust anchor for both federated trust/authentication and local onboarding. A BDI Association is the “home Association” for its Members.

Association Administrator - Functionary responsible for operating the services of a BDI Association.

Association Register - Technological solution for the register of recognized legal entities, real time accessible by associated data provider(s) (Members)

Member - Legal entity as member of the BDI Association of its choice

Federation of Associations - A series of collaborating BDI associations

Outsider - Member of a different BDI Association than the "home" . Note: this a relative perspective, from the position of a Member of a given instance (BDI Association). Members of the same instance are “insiders”, anybody else is an Outsider and vice versa.

Preferred Business Partners - Outsiders who have agreed to specific terms and conditions of a local BDI Association that maintains its own Business Partner Reputation Model

Home Association - The association a member is part of.

Visitor - Outsider with a better reputation score than a defined minimum.

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, pentesting, 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.

• Members can use the Association Register to assess the trust level of another Member and to retrieve information about Members (in for instance what roles they fulfill).

• Members can use the Association Register to asses the trust level and reputation of Visitors and Preferred Business Partners

• Members can add to the Reputation score of registered entities.

• Members can use the Association Register to asses the reputation of a previously unknown Outsider: the Association Register queries the Association Register of the Outsider.

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.

  • This requires that an Outsider, Visitor or Partner identifies the URL of its root Association.

• An entity can choose to be Member of multiple Associations.

  • An example is an e-commerce retailer: one side of the company is dealing with shipping purchased goods by maritime transport (containers) to its local warehouses, the other side of the company is deeply involved in e-commerce retail and distribution. The large difference in semantics, terms and conditions, roles, and parties (including authorities) involved is visible in the different trade organizations (maritime container transport versus e-commerce retail). The difference may lead to the choice to be Member of two different Associations.

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:

This page contains references to demo projects and their lessons learned where the Trust KIT has been used (some documents are in Dutch).

1. Summary

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

Utilizing discovery-aspects of the iSHARE Trust Framework.

or

Defining a standard for discovery using the DNS Protocol.

2. Purpose of this building block

Option 1: Discovery using the iSHARE specifications

iSHARE and thereby BDI provide a framework for the discovery of:

1. (Data) Services. All participants providing services must provide a /capabilities endpoint, as defined in the developer documentation. This endpoint provides information on the available BDI supported service offerings.

2. Participants of a data space. Participants of an association (in iSHARE: data space) are (if they choose to) discoverable through the /parties endpoint of any Association Register (in iSHARE: iSHARE Satellite).

3. Data spaces. Associations (data spaces) are (if they choose to) discoverable through the /dataspaces endpoint of any Association Register (in iSHARE: iSHARE Satellite).

Option 2: Discovery using DNS

The Domain Name System (DNS) is a foundational protocol in internet infrastructure, serving as a directory that translates human-readable domain names into IP addresses. In the context of federative data sharing networks like the BDI, DNS plays a crucial role in enabling data consumers and providers to discover each other's service endpoints. By utilizing DNS for service endpoint discovery, organizations can publish and find endpoints, thereby facilitating data exchange within the network. This building block outlines the purpose, concepts, implementation considerations, key elements, and recommended standards for using DNS in the BDI discovery building block.

The purpose of using DNS in the BDI discovery building block is to provide a standardized method for publishing and discovering service endpoints. This allows data consumers to easily find the endpoints of data providers without the need of a common shared register, assess their trust level, and establish connections for data exchange. The use of DNS ensures that the discovery process is both scalable and compatible with existing internet infrastructure. Discovery based upon DNS allows for a perimeter-less federation of BDI users and Associations.

3. Concepts

1. DNS Overview: DNS is a hierarchical and decentralized naming system that translates domain names into IP addresses, enabling users to access websites and other resources on the internet. DNS is organized into zones, each managed by an organization that controls its own part of the DNS namespace.

2. DNS Subdomain: a standardized subdomain ( "_bd1.[ url] ") improves discoverability, educes the risk of interference with existing DNS records for the domain name already in possession of an organization.

3. Service Discovery: In the context of BDI, service discovery involves using DNS to locate the endpoints of parties involved. This is achieved by creating specific DNS records in a subdomain "_bdi" that describe the services and where they can be accessed.

4. DNS Records: Different types of DNS records serve various purposes. For service discovery in BDI, TXT and SRV records are particularly important. TXT records can store arbitrary text and are used to describe the services offered, while SRV records specify the hostname, port, and protocol for accessing a service.

5. Federation: The URL of the Association of a party (the "Home" of a party) can be used to discover the service endpoints of their Association. These services can be used to verify onboarding and membership of that previously unknown party. The DNS namespace is used as a shared register, suitable for perimeterless global interactions.

4. Implementation Considerations

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

1. Zone Management: Organizations must manage their DNS zones effectively to ensure accurate and up-to-date information is available for discovery. This involves maintaining the appropriate DNS records and ensuring that the DNS infrastructure is reliable and secure.

2. Security: To secure the discovery process, DNSSEC (DNS Security Extensions) should be implemented. DNSSEC adds a layer of security to DNS by enabling the authentication of DNS data, preventing tampering, and ensuring the integrity of the information provided in DNS records.

3. Scalability: DNS is inherently scalable, making it suitable for large, federated networks like BDI. However, organizations must ensure that their DNS infrastructure can handle the expected load, particularly as the network grows.

4. Standardization: To ensure interoperability within the BDI network, it is crucial to follow standardized naming conventions and DNS record formats. This includes using well-known subdomains { "_bdi.[url]"} and consistent formatting for TXT and SRV records.

5. Elements and Their Key Functions

1. Well-Known Subdomain: A predictable subdomain, such as _bdi.acme-corp.com, serves as a central point for service discovery. This subdomain is used to organize DNS records related to BDI services, making it easy for data consumers to find relevant endpoints.

2. SRV Records: SRV records are used to locate the actual endpoints where services are hosted. These records specify the hostname or IP address, port number, protocol, and other parameters necessary to connect to the service.

   1. Key Fields: target (hostname/IP), port (service port number), priority and weight (used to select the best service endpoint if multiple are available).

3. TXT Records: TXT records provide descriptive information about the services offered by a data provider. These records can include lists of services available under a specific subdomain, details about the protocols used, and any additional attributes required for service access.

4. DNSSEC: DNSSEC provides security for DNS by enabling the validation of DNS responses. This is crucial for preventing attacks like cache poisoning, ensuring that data consumers receive accurate and trustworthy information during the discovery process.

Introduction

Demo Phase 1

The "Trusted Goods Release" demo aimed to establish a secure process for the handover of high-value goods within a logistics network. This demonstration illustrated a streamlined approach using trust-based protocols, enabling seamless, authenticated, and authorized goods collection. It showed how essential logistics operations could be managed through digital verification, focusing on the Base Data Infrastructure (BDI) and iSHARE Trust frameworks for enhanced security and efficiency in goods transfer.

The demo illustrated a trusted goods release scenario, focusing on a high-value, business-to-business (B2B) shipment within a controlled logistics process. Key achievements included:

• Validating the iSHARE Trust framework and BDI components in a real-world setting.

• Demonstrating the secure handoff of shipments by incorporating "need-to-know" data-sharing practices.

• Establishing an efficient digital verification process to authenticate authorized personnel and vehicles for pickups.

Documentation in GitHub https://github.com/Basic-Data-Infrastructure/demo-vertrouwde-goederenafgifte/tree/fase-1

Demo Phase 2

The "Delegation Demo" (Demo 2) built upon the original "Trusted Goods Release" process by introducing a delegation mechanism. This extension demonstrated how the trusted goods release protocol can be further refined with subcontractor involvement, showing enhanced control and flexibility within the logistics process. This demo utilized iSHARE and BDI frameworks to incorporate delegated authority in a seamless and secure manner.

In Demo 2, the focus was on implementing a delegation framework, expanding on the core process demonstrated in Demo 1. Key elements included:

Documented lessons learned and areas for improvement are available (attached to this article), as well as illustration of proposed process flow.

Documentation in GitHub

https://github.com/Basic-Data-Infrastructure/demo-vertrouwde-goederenafgifte/tree/fase-2

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.

Why use event-driven coordination?

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

• It supports flexibility: Events help autonomous systems work together without direct coupling.

• It improves responsiveness: Early signals allow actors to adjust quickly and avoid bottlenecks.

• It fosters accountability: Shared events form a transparent timeline of what occurred.

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;

• What to do when an event seems to be missing or out of order;

• When a consumer should no longer expect events (see also Closing the Order and Dissolving the Network).

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.

• Create a JWT for the new subcontractor.

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 Channels) 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

Notifications trigger communication between decoupled services and are common in modern applications built with microservices. In the BDI, a notification corresponds to an event in the physical world.

Events occur in the physical world and are changes of state like a container being unloaded from a ship or a parcel delivered to its destination. Events can also be of a more administrative nature, such as the signing of a contract or the publication of a new expected arrival time.

Notifications may or may not carry data about the event (the item purchased, its price, or a delivery address).

Notifications are published to channels of the pub/sub service and are delivered to all subscribers on the channel.

A party that publishes a notification is called the producer, parties that receive the notification are called consumers.

The part of the infrastructure that is responsible for managing channels and notifications is called the router.

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:

• Efficiency:

  • No polling needed.

  • Low load on resources.

• Effectiveness:

  • Easy to distribute notifications to many involved parties.

  • ‘Single truth’ data at the source.

  • Synchronization of activities.

• Control:

  • Distributing notifications with metadata only reveals relatively little information that can be abused.

  • Data access requires authentication. This increases the control over valuable data.

  • Authorization rules define what data can be accessed by what role/party.

  • All access to the data can be logged.

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 page.

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?

• Why – the reason (and in which business activity exactly) that the event took place (goods receipt, freight collection, transport document definitively agreed, etc.).

• How – in what state (how) is or was the cargo being transported at the time of the event?

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:

• Semantics

• Data model

• Data format

• Data protocol

• Zero Trust Check

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.

• The owner can now do several checks to see if the data consumer is (still) allowed to access his data. In this case the owner agrees, and the data is sent as response to the query from the consumer.

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) https://www.iso.org/standard/85557.html

• DCSA: https://www.dcsa.org/standards/track-and-trace

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:

   • Implementation of Authorization and Assignment Registers to manage permissions and roles associated with each transport order.

2. Event Broker:

   • Use of Apache Pulsar as an event broker to handle event data propagation, allowing secure, role-based access to notifications.

3. Mockup Systems:

   • Simulated environments for ERP, Warehouse Management System (WMS), and Transport Management Systems (TMS) to incorporate event notifications and handle delegation to subcontractors.

4. Messaging and Events:

   • Focus on gate-out events, notifying the shipper when goods leave the distribution center. Events were managed through a dedicated topic per transport order, enhancing traceability and ensuring only relevant parties accessed event information.

5. Demonstration and Presentation:

   • The demo was presented in a series of project meetings, with discussions on implementation insights and future improvements.

6. Non-Functional Observations and Findings:

   • Insights from the demo led to suggested improvements in architecture, event handling, and component documentation.

   • Identified potential challenges, including scalability of the event broker, secure access to event data, and data protection strategies such as publishing only URLs to sensitive information instead of the data itself.

   • Explored alternative methods, such as webhooks and long polling, to further refine notification mechanisms.

The Event Demo demonstrated the feasibility of using real-time event notifications in logistics. By integrating event brokers and secure data-sharing protocols, this phase emphasized transparency and control in logistics processes, laying the groundwork for scalable, event-driven solutions in the industry.

You can find the document with lessons learnt attached to this article (in Dutch).

Summary

Over time, different sectors have developed their own ‘language’ to communicate about their activities. This is illustrated by the number of global and local standards. It is expected that data spaces should align with sectors and their standards, creating the need for tools for organizations that participate in multiple data spaces to switch between standards.

Purpose of the building block

The purpose of this building block is to describe the creation and usage of a light-weight common BDI format, called LEO (Logistics Event Ontology). The purpose of this format is to bridge the existing standards in the realm of logistics data sharing, like OTM, FEDeRATED, OneRecord, DCSA, GS1, UN/CEFACT, EDIFACT and many others. It is not the intention to fully map all details of all standards on a single model. Instead, the LEO format distils the minimal data needed to follow goods through the supply chain based on the perspective of the beneficial cargo owner (BCO).

Concepts

Three distinct levels or perspectives exists from which one can consider the logistics domain, based on the three layers of the DCSA model:

1. Transport: The movements of the transport means containing equipment which contains the goods. Like vessel, barge, ship, truck, airplane, etc.

2. Equipment: The movements of the actual equipment containing the goods. Like container, parcel, trailer, package, loading, pick up, delivery, eta, etc.

3. Shipment: The business transactions along the supply chain. Like bill of lading, airway bill, customs documents, clearances, certificates, etc.

The LEO format is primarily focused on the first two physical perspectives and builds on the semantic work done in de FEDeRATED projects.

Implementation Considerations

In creating this minilanguage, we should avoid reinventing the wheel. We achieve this by keeping close to existing standards. The most effective way to do this would be to pick a small number of modelling elements from a small number of carefully selected models.

These models should be widely used and well-understood, relatively simple, and, taken together, support the target use cases concerning supply chain visibility for BCOs. The challenge, however, is: how can we not only keep our minilanguage simple, but also ensure that mapping datapoints from existing messages in terms of dozens of languages is viable? The answer is to make pervasive use of code lists and thesauri.

Beneficial cargo owners (BCOs) greatly profit from this information allowing them to track and trace their cargo. Unfortunately, different subdomains in the logistics industry use vastly different languages to express such information. The unwanted result is that many BCOs suffer from an inadequate information position. Hence the need for an intermediary language as a solution.

Interlinkages with other building blocks

This building block is closely linked with the Event Publish-Subscribe Service. The LEO format is mostly geared towards the description of events and the minimal data needed to communicate between modalities and existing standards. It defines templates for often used common logistic events and their linkage to domain standards.

Elements and their key functions

According to EPCIS (ISO/IEC 19987) an Event contains at least the following 5 aspects: 'What, Where, When, Why and 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?

• Why: Why (in which business activity exactly) did the event take place (goods receipt, freight collection, transport document definitively agreed, etc.)?

• How: It may also include the 'How' aspect. In what state (how) are or was the cargo being transported at the time of the event?

The example figure above, brings together the ideas of Event-Driven as also used in FEDeRATED and the EPCIS standard (which is almost 20 years old and used in practice in transport, logistics and supply chain). The Event is central in the figure, it is linked to a location (Where), to a logistics service (Why) and to a (physical) object (What).

The semantic model of the Event, expressed in RDF in the figure, also has a date and time. Since there are also quite a few connections beyond the figure's boundary, it will be clear that the Event-Driven semantic model can be extended to any level.

Core design decisions

The LEO format is still under development.

Future topics

We are not the only party looking for minimalistic logistics formats to create multi-modal supply chain visibility in conjunction with the many logistic domain standards now in practice. There are several commercial platforms creating this function already.

Several of them are completely open and have published and maintained formats like this for years. Much like the successful creation of the OTM standard, they are based on operational pragmatism and have been tested in practice.

Further reading

The choices made for this building block are based on the following research:

• LEO: THE LOGISTICS EVENT ONTOLOGY. A generic “minilanguage” for sharing information across domains, BDI Architecture Board

• Selection of a base model for LEO, BDI Architecture Board

• Semantic model development, BDI Architecture Board

Further supporting documents

There is a growing demand from Beneficial Cargo Owners (BCO) to create more visibility in the supply chain: visibility of the operational planning and execution of all the steps between ordering goods and receiving the consignments in the distribution centre or warehouse of the BCO.

Each transport leg in the consignment journey results in one or more events which are to be communicated between parties directly involved in the transport leg. The event communication leads to data exchanges, typically using specific systems, platforms and data formats. The diversity of parties, systems and data formats are a barrier to automated exchanges.

The issue to be solved is the existence of a wide variety of data formats and semantic definitions in supply chains:

• beneficial cargo owners who want to track & trace their goods cannot adopt all the data standards in use;

• the logistics partners want to keep using their existing data standards;

• (global) unification of data standards is not a practical option for the near future.

The concept of an event envelope is introduced, named Logistics Event Ontology (LEO). The BDI framework separates the envelope from the payload, separating event data from other operational data. The BDI envelope is a notification of an event with additional data and meta-data, combined with a link to the endpoint of the data owner where more (sensitive) data about the event may be requested. The data owner evaluates the request and the party requesting access, and provides data on a 'need-to-know' basis.

The Logistics Event Ontology (LEO) is derived from existing standards, especially the GS1 EPCIS standard. OpenEPCIS is an open-sourced fully compliant implementation of the EPCIS standard, allowing for extensions on the standard to support future events.

LEO supports the use of standard operational trip data by operators (such as carriers) to generate notifications of events to cargo owners or authorities, leading to efficiency and productivity increases.

Documents

Purpose

• To assist by semantic translations and remapping of logistics domain standards centered around the needed data for logistic event communication. Needs the Trust and Event Kits.​

Building blocks

Summary

The Representation Chain is a building block in the BDI framework. It enables third parties to verify representation mandates — confirming whether a person, legal entity, or automated process is genuinely acting on behalf of another.

A mandate is a formal, authoritative assignment of responsibility from a mandator (the assigning party) to a mandatee (the acting party). It transfers accountability and liability for actions from the mandatee back to the mandator.

To function securely and flexibly across different contexts, the Representation Chain uses Representation Evidence — typically implemented using nested JSON Web Tokens (JWTs). These can be verified both online (e.g., via issuer services) and offline (e.g., on a warehouse floor via a QR scan).

Introduction

In today’s increasingly interconnected and regulated economy, businesses and authorities are facing a growing need for robust digital proof in everyday interactions. Whether it’s verifying that a subcontractor is authorized to collect a shipment, confirming a driver’s professional qualification, or demonstrating compliance with regulations during an inspection, organizations must often rely on people or systems that act on their behalf. In most cases, liability for these actions lies with the organization, not the individual. This creates a pressing demand for a mechanism that can reliably prove — both legally and practically — that the person or machine performing a task has been officially mandated to do so.

Traditional methods such as paper documents or verbal confirmations are no longer sufficient. A modern solution must be secure, flexible, scalable, and usable in low-tech environments by people with little IT training. It must also support dynamic staffing models and allow independent IT providers to build competitive solutions without vendor lock-in. The JSON Web Token (JWT) standard, originally designed for secure information exchange between systems, offers a strong foundation for such a solution. Its format allows for verifiable digital claims, time-bound validity, cryptographic integrity, and issuer authentication — all critical features for establishing trust in operational contexts.

What makes JWT particularly valuable in this setting is its ability to be embedded within other tokens. This “nesting” allows multiple layers of representation to be encapsulated in a single digital envelope — from a principal organization, through subcontractors, down to the individual or system actually performing the task. Combined with high-trust digital certificates like eIDAS, JWT-based evidence can meet the highest legal standards for electronic signatures while still being compact enough for mobile use.

The approach supports both high-security and user-friendly versions. For example, a delivery driver might receive a QR code and PIN via text, which they present at a loading dock. The system verifies their credentials — offline if necessary — with minimal friction. This combination of simplicity and cryptographic strength makes JWT-based representation not only viable but ideal for logistics, compliance, and other sectors where verifiable delegation and operational practicality must coexist.

Purpose

The Representation Chain supports both:

• Human-to-Machine (H2M) and Machine-to-Machine (M2M) delegation, and

• Real-time human access or authority validation, such as in logistics, compliance inspections, or cargo handovers.

It is crucial in:

• Physical Asset Boundary Management

• Legal Asset Boundary Management

It provides a verifiable, decentralised mechanism for confirming:

• Who gave the mandate

• To whom

• For what role or task

• For what duration

• With what professional qualifications (if applicable)

Relationship to Other Building Blocks

The Representation Chain is conceptually and operationally connected to:

• Authentication

• Authorisation

• Digital Identity

• Common Roles

• Professional Qualification Chain

• Verifiable Credentials (future support via vc and vp claims)

Elements & Core Functions

A Representation Chain maintains:

• The digital identity of the mandator

• The digital identity of the mandatee

• The scope of the mandate (role-based, order-based, or otherwise contextual)

• Timestamps (not-before, not-after)

• Professional qualifications

• Optional links to issuers for revocation or validation

The Representation Evidence is typically a nested JWT structure, passed to the mandatee. This token is then presented to a verifying party — such as a loading dock, customs authority, or inspection officer.

The verifier checks the signature chain, timestamps, and optionally contacts the issuer(s) to confirm current validity.

The third party verifier does not need to be a member of a BDI Association, which lowers the barrier for wide-scale adoption and integration.

Business Need for Digital Representation

Supporting business itneractions digitally, requires digital proof of authority, particularly in interactions between:

• Individual companies

• Companies and supervisory/government bodies

The most common scenarios include:

• Proof of representation (someone acts on behalf of an organisation)

• Transfer of cargo (pickup or delivery confirmation)

• Proof of qualifications (such as handling dangerous goods)

• Proof of compliance (laws and regulations)

People or systems acting on behalf of others must carry digital proof of their mandate. Traditional methods — paper slips, phone calls, or emails — are not scalable, secure, or auditable.

To meet modern requirements, we need a solution that is:

• Legally and practically robust

• Easy to use in varied operational environments

• Broadly applicable across sectors

• Open for implementation by multiple IT providers

JWT as a Representation Mechanism

After 2010, JSON Web Tokens (RFC 7519) became a widely adopted standard for representing verifiable claims digitally.

Each JWT contains:

• A payload with the actual claims (who, what, when, for whom)

• A hash to confirm that the payload hasn’t been tampered with

• A digital signature by the issuing party (e.g., via eIDAS or trusted cert)

Nested JWTs: The Representation Chain in Action

JWTs support wrapping (embedding), meaning one JWT can include another inside its payload. This enables building multi-level chains of delegation — for example:

There’s no formal limit to the number of layers. For legal-grade use (e.g., cross-border logistics or compliance), JWTs can be signed with high-quality certificates such as eIDAS seals.

Example: Machine-to-Machine Access to Sensitive Operational Data

This example demonstrates how a chain of representation and delegation is managed digitally when data, is the asset being accessed — and when systems, not people, are the ones performing the action.

Scenario: Delegated Data Access via a Subcontractor System

A company called SmartWater Solutions manages water quality sensors across industrial facilities. A major client, ChemCo Industries, contracts SmartWater to monitor chemical runoff levels at their facilities. However, SmartWater does not have a data analysis platform robust enough for ChemCo's specific requirements. To meet the SLA, SmartWater subcontracts DeepSignal Analytics, a specialized AI firm, to process and analyze the raw data streams.

Now, DeepSignal’s automated system (an API client) must retrieve sensitive sensor data from ChemCo’s secure telemetry endpoint. However, ChemCo’s API is configured to only accept requests from authorized systems — specifically those acting on behalf of contractual parties.

To make this delegation verifiable and non-repudiable, SmartWater issues a Representation JWT to DeepSignal. This token proves that DeepSignal has been delegated the right to act on SmartWater’s behalf. It includes an embedded JWT from ChemCo to SmartWater, establishing the upstream mandate.

JWT Chain Construction (M2M)

1. ChemCo Industries issues a JWT authorizing SmartWater Solutions to retrieve and process sensor data on its behalf. The token includes:

   • Scope (sensor IDs, data types)

   • Validity window (nbf, exp)

   • A jti (token ID) for revocation checks

2. SmartWater Solutions issues a second JWT to DeepSignal Analytics, embedding the ChemCo JWT. It contains:

   • DeepSignal’s system identifier (API client ID or server public key reference)

   • Constraints on data types, endpoints, or frequency

   • A clear mandate scope (e.g. "read-only access to zone A sensor logs")

The JWT is cryptographically signed by SmartWater and includes ChemCo’s original JWT inside its payload.

Machine Request and Verification

When DeepSignal’s system sends a request to ChemCo’s API, it attaches the nested JWT as its digital proof of mandate. ChemCo’s API performs the following checks:

• Validates both signatures (SmartWater and ChemCo)

• Verifies token expiry and start time

• Confirms that DeepSignal's system is the intended subject

• Parses the embedded JWT from ChemCo to SmartWater to confirm original authority

• Optionally, looks up the token's jti in ChemCo’s revocation list or representation register

If all checks succeed, the API grants access and returns the requested sensor data.

This JWT-based method ensures that:

• SmartWater retains liability for DeepSignal’s actions

• DeepSignal cannot misuse or forward the token, as the claims are specific and signed

• ChemCo has an audit trail of who requested what data and on whose authority

• Delegation can be revoked or changed with minimal friction

Example: Transporting Hazardous Materials Using JWT Representation Evidence

This example illustrates how a chain of representation is securely and digitally established using embedded JWTs in a real-world logistics setting.

Scenario: Chemical Pickup by a Subcontracted Driver

A large industrial buyer has purchased hydrofluoric acid and the supplier — Acne Inc. — arranges for the pickup to occur at Lets-B-Chemical. However, Acne does not have its own transport capacity and therefore contracts the trusted logistics firm Van Gend & Loos to execute the pickup and delivery.

Van Gend & Loos does not have a truck available on the required date. Instead, it chooses to subcontract the pickup task to De Snelle Visser, a regional carrier already scheduled to pass by Lets-B-Chemical. Dolly Driver, an employee of De Snelle Visser, is tasked with executing the collection.

Now Dolly must be able to prove the following:

• That she has a valid, authorized assignment from her employer De Snelle Visser.

• That De Snelle Visser was subcontracted by Van Gend & Loos.

• That Van Gend & Loos was originally contracted by Acne Inc.

• That she holds the correct qualifications to handle hazardous goods.

At the pickup location, Lets-B-Chemical needs to verify her mandate and qualifications before releasing the acid. This must be done quickly, securely, and ideally without needing complex systems or manual calls. To enable this, a chain of JWTs is created and passed down from Acne Inc. to Dolly Driver.

JWT Chain Construction

1. Acne Inc. issues a signed JWT that authorizes Van Gend & Loos to collect the hydrofluoric acid.

2. Van Gend & Loos issues a JWT to De Snelle Visser, embedding Acne's original JWT inside. This proves that Van Gend had authority to subcontract and passes the responsibility trace.

3. De Snelle Visser creates a JWT embedding both upstream tokens and includes Dolly's:

   • Identity details

   • Employment role

   • ADR (dangerous goods) certification

   • Device-specific metadata (e.g. IP address, vehicle license)

Field Presentation and Validation

Dolly arrives at Lets-B-Chemical and presents a QR code on her mobile phone. This QR code contains the fully nested JWT. The security officer scans it using a standard or BDI-enabled app.

The system:

• Verifies the cryptographic signature chain

• Checks timestamps (validity, expiry, issuance)

• Confirms Dolly’s identity and employer

• Detects ADR certification

• Optionally contacts the issuer (e.g., Acne or Van Gend) to verify token revocation status

If all criteria are met, the acid is released.

This chain-of-proof allows the liability and mandate to be fully tracked and provable, including post-facto audits. The information can be viewed via a link (e.g., "bdidrop.link/124V") or through integration with back-office systems.

The structure is robust enough for secure transport of sensitive cargo and simple enough to be used by temporary staff with minimal digital training.

Representation for transactions by IT-applications : DigiDrop

The most common transaction in logistics is the handover of goods (cargo on its way through the supply chain) between entities. Part of the handover is associated with trade (buyer-seller), part of the handover is about liability (transporter taking cargo on board of a vessel, plane, railcarriage or truck).

The "Digidrop" approach to executing transactions (such as transfer of goods) shifts the legal "signing" of a transaction to IT-systems on behalf of the companies involved. The human involvement is supportive and indirect, instead of acting as a representative of the entity. The IT-systems involved act as the representatives of the legal entities involved.

This approach circumvents the issues and obstacles that rise if humans need digitally "sign" a transaction. The Digidrop document outlines the approach.

Fallback

BDI’s method accounts for non-ideal environments — e.g., no internet, broken devices, or limited IT skills. Many (SME) actors in logistics are not yet able to integrate themselves in a more advanced IT-interaction framework such as the BDI.

In such a case the most valuable piece of information that needs to be digitally available is the visbility of a handover event. A fallback methode has been designed for such use cases, minimizing the requirements. Such a method is not a replacement of the traditional "paper-based" processes: it only creates more visbility in the supply chain.

High leven overview of DigiDrop fallback:

QR Code + PIN Workflow

• The driver receives a QR code and PIN via WhatsApp or SMS

• The warehouse scans the QR code using the DigiDrop app

• The driver verbally gives the PIN to authorize data viewing

• DigiDrop verifies the signature chain and displays details

• The warehouse confirms and releases the goods

This process:

• Works offline

• Prevents showing data without consent (PIN as consent barrier)

• Adds traceability

Short URL Fallback

If QR scanning fails:

• A short link is provided to the warehouse via text

• They can type this into a browser

• The PIN unlocks the relevant information

• Even if IT systems are temporarily down, the process continues via paper/PIN

No DigiDrop Provider Scenario

If a warehouse does not use DigiDrop:

• The driver presents the URL and PIN

• A trusted backend (e.g., TMSX) provides a basic web interface

• Security is reduced, but functionality is preserved

Summary

The Representation Chain provides a flexible, secure, and verifiable method for proving authority in business interactions — whether digital or physical. Its implementation via JWTs is:

• Scalable

• Legally robust

• Compatible with low-tech environments

• Designed for both machines and people

Combined with fallback workflows and hybrid adoption pathways, this method is ready for real-world logistics, compliance, and digital service chains.

Learn More

• RFC 7519 – JSON Web Token (JWT)

• VC Data Model 2.0

• BDI Edge Agreements

• IANA JWT Claim Registry

Documents

This page contains references to demo projects and their lessons learned where the Semantics KIT has been used.

Summary

The Professional Qualification Chain is a method that lets other entities verifiy if representatives of the entity that isses the evidence have the required qualifications.

The Professional Qualification Chain registers the relationship between

• the digital identity of the owner/controller

• the proof of relevant professional qualifications of humans or legal entities

  • for instance verifiable representations of verifiable credentials

• the digital identities of these humans or legal entities

The relationship is transient: as long as it is relevant, and only for relevant qualifications.

The legal implication is that the owner/controlling party assumes accountability and liability for the existence and verification of the relevant Professional Qailification of its representatvies.

Purpose of the building block

The purpose of the building block is to specify:

• the interface and structure to issue claims of Professional Qualification (Evidence)

• to allow automated verifications of the claim in the Evidence.

The building block is used in Boundary Management, especially Physical Asset Boundaries and Digital Asset Boundaries, for example:

• access to a location where specific safety training is required

• delivering services that require professional qualifications

• use of certified processes (ISO certifications of tools)

Concepts

Personal qualifications means criteria related to an individual's background, including completion of an approved educational program, satisfactory performance on an examination, work experience, testimonials and completion of continuing education.

Personal qualifications are issued by competent organizations to natural person. Examples include universities (education courses), former employers (work experience), governments (VOG statements, driving license), and terminals & chemical plants (health and safety courses).

Process qualifications means criteria related to a process, such as certification of compliance to an ISO standard.

Implementation Considerations

The traditional paper based approach is to collect and store a physical file of the professional qualifications and to present the applicable qualifications when required. This is a cumbersome process and sensitive to fraud as many copies are kept at multiple sources of which varying levels of controls are applied to validate authenticity and validity of the evidence.

A modern approach is to collect the qualifications in an mobile app or a secure card. On request the employee can share the qualifications. Examples include the Vakpaspoort of the Centraal Register Techniek and the XS-ID of Secure Logistics.

The drawback of the app approach is that the different implementations are not interoperable. For example the protocols for retrieving the qualifications from the sources are not standardized. Also the protocols for presenting the qualifications are not standardized.

The (open) European Wallet is an enticing prospect because it will standardize both the retrieving and the presentment of the qualifications as verifiable credentials in the personal wallet of the employee.

The Professional Qaulification Chain transmits only the verificanle representations of specific relevant qualifications.

The following is to be considered:

• the personal qualifications are personal data and most likely privacy sensitive. Sharing this data with other organizations is limited to its purpose meaning that anything else not trivial is to be masked.

• It requires clear authorization conditions to be provided to the association to ensure that the data is only made available to the organizations that can present clear evidence of the need need to access the data.

Interlinkages with other building blocks

This Building Block is linked with

• Trust KIT

  • Digital Identity

  • Authentication

  • Authorization

• Representation Chain

• Boundary Management

Elements and their key functions

Core design decisions

(EU) Wallets are under development. Large scale pilots have started, however focus initially has been on the natural person as civillian in relation to it's state authority and lesser on the 'role' of a natural person as a employee / staff in relation to a Legal Entity / business.

Relevant standards to consider or adopt for the BDI are:

• The Verifiable Credential Data Model (current v2.0). This defines the 'shape' of the claims and belonging metadata that cryptographically prove who issued it. Not the content of the credential itself. This is to be defined in large-scale pilots to strike consensus and find adoption.

• The VC can be stored in a Wallet. The BDI supports an exchange is through tokens (JWT's) where embedddd JWTs with VCs for representation evidence to provide a Chain of Trust. Specification of the application of the protocol and interfacing is work in progress

Future topics

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

2. Purpose of the building block

Example for digital shipment data

Transport is a consequence of trade. In the terms and conditions of a purchase agreement, the seller and buyer agree, among other things, who should take care of the transport of the shipment. In international trade, sellers and buyers can use the Incoterms 2020. These are standardized agreements about who arranges what (e.g. transport, but also insurance and customs formalities), payment and payment securities, at what point the responsibility is transferred (e.g. when a container is lifted over the railing of a ship), and the like.

Standardized terms and conditions have been developed to codify roles, responsibilities and liabilities between the seller, a carrier and the buyer. International treaties harmonize these conditions between countries. The aim is clear: this standardization and harmonization facilitates trade.

These conditions are specifically tailored to a modality. The CMR Convention, for example, was set up for international road transport. The CMNI Convention exists for inland navigation. In the maritime sector, the Hamburg Convention (United Nations Convention on the Carriage of Goods by Sea) is leading. The Montreal Convention sets out the liability of air cargo carriers, and IATA also has specific conventions for the carriage of dangerous goods and live animals by airplanes.

All these treaties have a main document that is intended for commercial agreements about transport in the context of a commercial transaction.

When the paper-based process is “digitized” the legal boundary interactions (“edge agreements”) have to be redefined. Suddenly questions arise on the legal status of digital “signatures”, i.e. signatures that in the paper process are a record of the handover moments.

Digitally recording a transaction is something that causes a lot of unrest and uncertainty for many entities. There are many technological variants and possibilities, each with their own advantages and disadvantages. And some technological secure variants do not resemble the tried and trusted 'wet' signature, and vice versa. A PDF with a pasted-in scan of a signature gives a familiar feeling but is a very weak method. A geo-tagged, time-stamped digital image of the delivered shipment at the desired location does not require digital infrastructure for the receiver, but can it be used as evidence in court if there is a conflict?

For many users, including authorities, digitized processes are an unknown field, and the risks and implications of the various variants are not immediately clear. There also exists doubt about what is required and enforced by law (fined when not complied with), what is a commercial business choice between parties, and how does that work out when a business conflict arises.

Edge agreements are a building block that helps parties to overcome this uncertainty, build and codify acceptable practices, standardize them and gain the benefits of digital transactions. Edge agreements are accepted by parties involved in any commercial transactions that take place within and on the edge of the BDI.

Implementation example

The boundaries that are to be crossed when “non-BDI” or “data-sharing network”

A practical implementation example might be constructed as follows.

A group of entities in a sector defines an enumerated list of practices, including roles, responsibilities and liabilities. The list spans a range of trade-offs between ease-of-use and levels of legal and IT-security. For example:

• “A handover is defined by the driver hitting a button, that records:

  • driver ID,

  • license plate

  • time,

  • geolocation

  • shipment ID”

• “A handover is defined by the driver taking one or more digital pictures of the shipment unloaded, geo-tagged, time-stamped”

• “A handover is defined by a qualified digital signature of the receiver and the driver”

The shipper identifies the acceptable practices for a specific transport order (“all acceptable” or “only qualified signature”) and makes them part of delivery conditions in the sale to the buyer. This gives clarity and certainty to all parties involved and gives legal (commercial) backing. In turn, other parties involved in this transaction, like a transportation company, now know what to do when delivering the goods to the buyer of the goods to confirm handover.

Implementation Considerations 

Edge interaction protocols are vital for a functioning supply chain. The definition and maintenance of these protocols are common pool resources. It is recommended that associations agree upon a set of protocols to deal with parties on the edges of the data-sharing network.

Use case scenario:

1. Acme Inc. buys a batch of hydrofluoric acid from its supplier Lets-B-chemical. Acme inc. agrees to the terms and conditions of delivery from Lets-B-Chemical including terms on proof of delivery.

2. They agree that Lets-B-chemical will hire De Snelle Visser for transport

3. It is known that Acme Inc. does not use any IT.

4. Lets-B-Chemical and De Snelle Visser are accustomed to working together according to the BDI framework where status updates on shipments are done through event-driven coordination.

5. Lets-B-Chemical informs the transport company De Snelle Visser that a digital confirmation of handover can be done by either a picture of the delivery or an SMS confirmation. This is also agreed upon in step 1 between Lets-B-chemical and Acme inc.

6. The driver working for De Snelle Visser delivers the goods to Acme Inc. and takes a picture of the delivered hydrofluoric acid.

7. The confirmation of delivery with the provided evidence will trigger a status update on the shipment from “in transit” to “delivered”.

In this scenario, the BDI supports both the shipper (Lets-B-Chemical) and the transportation company (De Snelle Visser). However, the buyer (Acme Inc.) is not part of the BDI or any other network due to its low IT maturity level. As a result, the BDI cannot directly assist the buyer, which reduces its effectiveness for both the shipper and the transportation company. Establishing a set of defined agreements to address situations like this would enhance overall digitization and provide clear legal backing for these handover moments. This case is not unique; many supply chains still rely on paper for such handovers.

Interlinkages with other building blocks

• Terms and Conditions

• Policies

Elements and their key functions

• Agree on a set of accepted edge interactions like (but not limited to)

  • Picture of the freight taken by the driver

  • SMS confirmation between the buyer and seller

  • Signature on tablet by the driver and buyer

Core design decisions

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

• Association-Specific: These agreements are tailored to meet the unique needs of the association, which may vary by sector, geographical location, or specific theme. For example, in bulk transport, the quantity delivered might differ depending on the customer or transport company due to factors like time delays or poor internet connectivity. An edge agreement could be established to define the correct weight of goods upon delivery.

• Common: Utilize a standardized set of edge agreements available in the BDI repository. For instance, an agreement could state that a picture of the delivered goods serves as sufficient proof of delivery.

• Global: Seek to align these edge agreements with those used in other sectors and standards whenever possible, promoting convergence and consistency.

Future topics

• Proving inclusion of the protocol in the proving grounds

• Further describe data exchange with non-BDI actors

• Further describe edges with BDI actors.

Further reading

Summary

This building block encompasses key points for effective interoperability and federation amongst associations.

Purpose of the building block

This block is vital in trust implementation within the Association and widening this scope to other associations. This helps create a network effect and federate the BDI Framework.

Concepts :

Implementation Considerations

The Discovery mechanism supports an open and loose model without a centralized register that could be searched for all existing BDI Associations. In theory a large number of independent BDI Associations could co-exist without further governance.

In practive it is expected that BDI Associations will form federations and voluntarily agree upon common standards, roles and semantics over a group of Associations.

Interlinkages with other building blocks

This building block complements the Zero Trust Check, Verifiable Credentials and Business Partner Reputation Model.

This building block is also related to Association Register and Onboarding T&C's Association articles.

Elements and their key functions

Federation of Associations creates:

1. Trust Assurance outside the association

2. A Perimeter-less network

The Association Admin is a key role in the Federation of Associations

Association Admin

• responsible for developing and maintaining as well as operating the established Association

• entails various functions, such as setting internal rules and policies, ensuring compliance with internal and external rules, and resolving conflicts that may arise.

• creates mechanisms for continuous improvement of the association, identity management, access controls and risk mitigation to build trust and quality within the association.

• Standardise credentials that are acceptable in the association and can also be agreed upon to be acceptable with other associations

Core design decisions

• Federation is key to expanding the scope and functional significance of local associations.

• Associations don’t function in silos and zero trust approach requires federation of key trust elements or credentials.

• As most organizations will be active in multiple sectors, the question of supporting interoperability between different sectors is a key challenge. Federation is finding common ground for trust among associations.

Future topics

• Credentials for Federation

• Interoperability of Associations

Documents

Further reading

• https://framework.ishare.eu

Purpose

The Discovery mechanism supports an open and loose model without a centralized register that could be searched for all existing BDI Associations. In theory a large number of independent BDI Associations could co-exist without further governance.

Identification, discovery, authentication, trust assesment and authorization in such a perimeter-less network on a global scale requires functions to deal with previously unknown parties.

The reality of business networks is that there is an inherent tension between interoperability on one hand and competition/innovation on the other hand. Standardization lowers costs, but differentiation creates value and competitive advantages: a dynamic trade-off, shifting over time.

Federation has to acknowledge this tradeoff. In practive it is expected that BDI Associations will form federations and voluntarily agree upon common standards, roles and semantics over a group of Associations.

It is expected that a number of frameworks for controlled data sharing wil co-exist. A minimal level of interoperability that reduces uncessary costs is desirable.

Summary

In the BDI network, a reputation system 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. Although the core trust framework in the BDI provides a foundation for determining trust, additional systems are necessary to enhance trust evaluation for external data sharing. Consequently, the BDI introduces a reputation system to enable more nuanced trust judgments.

Purpose of the building block

The local dataspace association can be seen as the “in-group” where proximity, high frequency of interaction and strong social control are dominant in how trust is founded. This is backed by legal enforcement (contracts), a neutral organization (association) and possibly government authorities.

Interactions with members of the “in-group” need relatively minor additional trust assessments per interaction. On the other hand, interactions with members outside the association require an additional layer to base trust upon since interaction is less frequent or incidentally.

Members that want to interact with “in-group” members are classified as either a “visitor”, where the member has frequent interactions with members of the associations or as a “outsider”, where the member only has occasional interactions with members of the association.

The Business Partner Reputation Model proposes a system where “in-group” members score members outside the association. Thus a reputation system is created that can help other members of the same association the better determine the trust of the relevant party.

“Visitors” can finally become members if they are allowed to by the association administer.

The association is the core neutral organization that supports the members of the “in-group” in dealing efficiently with trust-assessment in a perimeterless network. Trust Sovereignty means that the association does not make trust decisions for members, unless specifically tasked to do so. In principle, the Data Owner makes this decision (delegated or not to the data service provider).

Implementation Considerations

Interlinkages with other building blocks

• Authentication: Authentication out of group members

• Digital Identity: An additional layer to verify trust worthiness of digital identity

• Zero Trust Check: An additional layer to verify trust worthiness of digital identity

• BDI Roles:

• Federation of Associations: especially implemented when dealing cross associations

• Verifiable Credentials: this is future work;

Elements and their key functions

Reputation registers where the reputation of visitors and outsiders are stored and maintained.

Core design decisions

• Are the reputations stored decentrally or with a central party within the BDI Association?

• Optional component of a BDI Association?

• Are the ratings visible outside the BDI Association?

Future topics

This building block is still highly conceptual and gives a first consideration on how to implement a reputation system. Further things to consider are:

• How often can a member review a visitor or outsider?

• How are ratings automated?

• Is the rating system for data exchange with one BDI Association only or is it federated with other BDI Associations?

• Can organizations complain / request withdrawal of ratings & rating comments (e.g. based on false motives like competition libel

• Options for blacklist

Documents

Data licenses describe the terms and conditions for using data. BDI recognises a layered licensing structure. Licenses are used in authorisations for data transactions and are defined in this building block of the BDI framework.

Purpose of the building block

The purpose of the data licenses building block is to allow Data Owners to control what Data Consumers are allowed to do with their data by providing instructions on how a service may be consumed or under which conditions data may be exchanged.

Concepts

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

Risks

When not selecting the correct license, the Data Consumer might not be sufficiently legally bound to the right terms and conditions for using their data, which could result in data abuse and thereby in financial or reputational damage to the Data Owner, or (indirectly) the Data Service Provider.

However well the licenses are implemented, there is no technical guarantee that the data is used in conformance with the applicable licenses. The legal context of the framework mitigates this risk, but a residual risk remains.

Interlinkages with other building blocks

This building block is closely tied to Authorization, since a license may be part of an authorisation. The authorisation defines:

1. Which party

2. Is allowed to access which data attributes

3. (Optionally) at which Data Service Provider

4. (Optionally) with which terms and conditions for using the data (licenses)

Elements and their key functions

Licenses are defined in framework documentation (see below). In Authorisations, licenses are applied. As defined in Authorization, and particularly in the iSHARE data model for authorisations, one or more licenses ("stacking") can be applied to an Authorisation. Data Owners must make sure that when more then one license is used, the licenses must not be contradictory.

Core design decisions

Licenses are defined on three layers:

1. iSHARE layer. The available licenses are defined in the iSHARE Trust Framework.

2. BDI layer. The available licenses are defined in this building block.

3. Association layer. The available licenses are defined in the framework agreements of a BDI Association (when these exist).

BDI layer licenses

There are currently no specific BDI licenses defined.

Combined list of available licenses

Future topics

Future topics that are of interest to this building block are:

• Research how Incoterms can be applied in the context of licenses.

• Research which technical controls are available to enforce adherence to licenses.

• Align with other data spaces initiatives on the topic of policy enforcement.

• Contribute to iSHARE's licenses framework through the iSHARE's Change Management process, particularly through RFC037 (including improved specification on the usage of ODRL).

Further reading

This building block has been drafted using the following sources, that provide opportunity for further reading:

• DSSC Blueprint building block “Access and usage policies enforcement”

• iSHARE Framework documentation, specifically on the topic of licenses

• iSHARE Developer Portal documentation

This page contains references to demo projects and their lessons learned where the Representation KIT has been used.

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.

This page contains references to demo projects and their lessons learned where the Federation KIT has been used.

Purpose

• To use standard dataspace components and technology to exchange data sets using the BDI control plane functions and IAA solutions. Needs the Trust and Event Kits. Used to build Catena-X style Data Spaces based on IDSA standards.​

Building blocks

This page contains references to demo projects and their lessons learned where the Data Set KIT has been used.

The European Interoperability Framework: https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf

describes an interoperability model that is geared toward the public sector. Its describes a "stack" of interoperability subjects.

As a general model it is useful to describe issues and solutions.

The BDI has a focus on a wide generic technical interoperability between entities, supporting specialized/differentiated:

• semantic interoperability

• organisational interoperability

• legal interoperability

The world model is that market forces, geo politics, regulation, culture and innovation will create a dynamic universe of sectors/groups that have an interest in driving specilalized/differentiated interoperability within their group, at the expense of interoperability with other sectors.

Technical Interoperability

The design philisophy to enhance generic technical interoperability is based upon:

• No proprietary development of protocols

  • Reuse known, proven or emerging open standards in a specific configuration

• Rely on already supported digital identities and other digital proofs of claims

Purpose

• Usingverifiable credentials in conjunction with BDI functions for IAA purposes. Needs the Trust and Event Kits.​

Building blocks

Further reading

Summary

This building block provides guidance support provenance, traceability, logging, audits, etcetera, in a standardized way for the use cases it supports.

Some use cases need additional data over the actual data being shared. This additional data may need the same or different access and usage management than the actual data itself.

It must be defined which information about this transaction is stored and how the access and the usage are regulated and controlled.

The evidence itself is again data, which is shared among different participants. Therefore, many concepts applied to data can also apply to this evidence, e.g., syntax and semantics of the evidence, access & usage policies on multiple levels.

The amount and granularity of evidence should be reasonable and appropriate to balance between the requirements of the availability of evidence and the scalability of the solution. The advantages and disadvantages of different approaches like a centralised, a decentralised, or a distributed solution must be assessed and understood.

A solution needs to fulfil the requirements of the governance, legal and contractual requirements, as well as other policies requiring such evidence, and balance this with the technical requirements like resource management, scalability, consistency, availability, and others.

The requirement for observability, traceability and provenance tracking is usually found in highly regulated industries or in cases dealing with high-value data. Data being used for artificial intelligence is an example of a situation where such mechanisms can be required by law (in this case, the AI Act).

Purpose

The purpose of this building block is to provide approach for the provenance and traceability.

The forward-looking direction of a data value chain is referred to as traceability, i.e., a data provider can receive evidence of what was done with the data. The backwards-looking direction of a data value chain is referred to as provenance tracking, i.e., a data consumer can receive evidence on the origin of the data and the treatment of the data during its processing in the value chain. Both traceability and provenance are important functional requirements for each participant in such a data value chain, which can consist of multiple data transactions.

Implementation Considerations

This building block addresses the following capabilities:

Interlinkages with other building blocks

Federation of assoiciation

Events pub/sub

Elements and their Key Functions

Nonrepudiation provides proof of the origin (provenance) , authenticity and integrity. It provides assurance to the sender that its message was delivered, as well as proof of the sender's identity to the recipient. This way, neither party can deny that a message was sent, received and processed.​

Example usage: The proverbial use case: man at the gate and the security guard has to verify claims. The Warehouse stores and handles goods for the client. De charter needs to provide evidence of assignment of the transport and compliance to the needed professional qualification (ie ADR-certificate)​.

In the BDI stack, we refer to Registers with claim (Association-, Representation, Professional Qualification- and Business Reputation registers), however this does not mean ‘central’. Practical deployment is explored: The ‘Secure Issuance of Goods demo’ works, however many calls / interactions to federated infrastructure is needed not benefitting non-functionals and robustness of the solution in complex scenarios.​

Direction that is being explored now is by combining ‘Embedded JWTs’ with VC’s (Verfiable Credentials) for a powerful mechanism for secure, flexible, and privacy-preserving information exchange whilst providing a Chain of Trust (tracebility):​

• Enables multi party trust (Chain of Trust)​

• Captures needed delegation and mandates​

• Seperation of concerns – you only need to know what you need to know​

• Privacy preserving - Holder can choose which claims to reveal to a verifier​

• Nonrepudiation​

• Known and in use technology, well defined and accepted protocols for token creation and embedding​

Core Design Decissions

The following design decisions should be considered:

• How can the origin of the data be established?

• How can you find out how data has travelled through the chain?

• Can the data origin be trusted?

• Is there a way to find out what and where something went wrong in the chain of transactions?

• Can other participants store/keep logs of data sharing that I am part of?

• Will I be able to use traceability data?

• How can you ascertain who acted on the data and at which point?

Future topics

Future work: Claims need to be stored for usage in a transactions. Ideally the subject should ‘hold’ the claim (like EU Digital Wallets). This is the defined EU direction. Not immidiate needed to work within the BDI scheme.

• The BDI provides nonrepudiation across the supply chain through a Chain of Trust based on Embedded JWT’s combined with VC’s to create a powerful mechanism for secure, flexible, and privacy-preserving information exchange based on known technology. Reference to be developed​

• (EU) Wallet’s to be researched on readiness (ecosystem) and easy of implementation​

To be potentially covered in future versions.

• Examples of provenance data products

• Examples of traceability data products

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 humand 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.

Boundary Management relates to:

• Identity (M2M and H2M)

• Authentication (M2M and H2M)

• Authorisation

• Federation

This page contains references to demo projects and their lessons learned where the Verifiable Credentials KIT has been used.

Summary

The BDI provides security measures based o ISO 27001. This is an internationally recognized standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS).

In essence, ISO 27001 provides a framework for organizations to establish a robust and comprehensive information security management system that helps them protect their valuable assets and infrastructure. This page contains a breakdown of the key measures it encompasses.

Purpose of this building block

1. Information Security Policy:

• Foundation: The cornerstone of the ISMS.

• Scope: Defines the organization's commitment to information security, outlining its scope, objectives, and responsibilities.

• Key Elements:

  • Confidentiality: Protecting sensitive data from unauthorized disclosure.

  • Integrity: Ensuring the accuracy and completeness of information.

  • Availability: Guaranteeing timely and reliable access to information when needed.

  • Accountability: Assigning responsibility for information security to individuals and departments.

2. Risk Assessment and Treatment:

• Identification: Identifying potential threats to information assets (e.g., cyberattacks, natural disasters, human error).

• Analysis: Evaluating the likelihood and impact of these threats.

• Treatment: Implementing controls to mitigate identified risks. This can involve:

  • Risk Avoidance: Eliminating the risk altogether.

  • Risk Mitigation: Reducing the likelihood or impact of the risk.

  • Risk Transfer: Shifting the risk to another party (e.g., insurance).

  • Risk Acceptance: Accepting the risk based on a cost-benefit analysis.

3. Control Implementation:

• Selecting Controls: Choosing appropriate security controls from Annex A of ISO 27001. These controls address a wide range of security areas, including:

  • Access Control: Restricting access to information based on need-to-know principles.

  • Physical Security: Protecting physical assets such as servers, data centers, and mobile devices.

  • Cryptography: Using encryption to protect data in transit and at rest.

  • Incident Management: Establishing procedures for responding to security incidents.

  • Business Continuity Management: Ensuring the continued operation of critical business functions in the event of a disruption.

• Implementation and Documentation:

  • Implementing the selected controls and documenting their implementation.

4. Monitoring, Measurement, Analysis, and Improvement:

• Internal Audits: Conducting regular internal audits to assess the effectiveness of the ISMS.

• Management Reviews: Conducting periodic reviews by management to evaluate the overall performance of the ISMS and identify areas for improvement.

• Corrective and Preventive Actions: Implementing corrective actions to address identified nonconformities and preventive actions to prevent future problems.

• Continuous Improvement: Continuously improving the ISMS based on feedback from audits, reviews, and other sources.

Key Benefits of Implementing ISO 27001:

• Enhanced security posture: Reduces the risk of data breaches, cyber attacks, and other security incidents.

• Increased customer trust: Demonstrates a commitment to data protection and security.

• Improved operational efficiency: Streamlines security processes and reduces the costs associated with security incidents.

• Enhanced compliance: Helps organizations comply with relevant regulations and legal requirements.

• Competitive advantage: Differentiates the organization from competitors by demonstrating a strong commitment to information security.

Digital assets are:

- Applications and processes

- Data

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

This subject is well understood by most organizations and covered by the main parts of the Trust Kit:

- Digital Identification

- Authentication

- Authorization

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 reauires 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: has he/she indeed been sent by the OEM? And can he/she indeed be authenticated and verified as being mandated by the sub-contractor, and does he/she have the required professional qualifications? And can that mandate be verified in a non-repudiable manner?

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 is that the engineer presents an ID (proof for authentication) and a Representation Evidence.

The ID can be standard, fitted with additional safeguards such as biometrics, or digital (Wallet).

The Representation Evidence should be able to show:

- The chain of subcontracting, up to a level that is suitable for security reasons

It may be necessary to stop at an intermediate level, to protect the identity of the main principal on top of the chain from leaking

- The confirmation of the identity of the engineer, as a representative

- Time limitations on the validity of the representation (not before, not after)

- Links to issuers of subcontracting orders, to validate real-time is the representation is still valid and not revoked

- The non-repudiable evidence of the representation

For real-life applications it is necessary to be able to operate (temporarily) offline: the check of the Representation Evidence with delayed validation at the issuers should be possible. If a delayed verification is acceptable is up to the parties involved: in many cases this might be acceptable, for instance if a pre-notification is done to the party that is checking the Representation Evidence. The pre-notification data can be matched with the data in de Evidence.

Nested JWT as carrier of claims

JSON Web Token (JWT, RFC 7519) is a compact, URL-safe means of representing claim sets to be transferred between two parties. A claim set is just a set of claims, where each claim is a piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a claim name (always a string) and a claim value (can be any JSON value).

The use of JWT is ubiquitous: the support in tools and knowhow is well developed.

Unsecured JWTs are just standardized claim sets. However, many if not most JWTs need to be signed and encrypted. The claim set in a JWT can be used as the payload of a JSON Web Signature (JWS, RFC 7515) structure or as the plaintext of a JSON Web Encryption (JWE, RFC 7516) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

The result nesting of a JWT in a JWS or in a JWE (or both!) is called a Nested JWT. (Note that this is a different kind of nesting than the nesting/embedding of representation evidences that are the topic of this note). The resulting JSON object is encoded using a Base64URL encoding, which produces a URL-safe plain ASCII string.

Because JWTs are in the end just ASCII strings, they can be used as the value of a claim in another JWT. We will designate this kind of nesting as embedded JWTs. This feature is the basis for representation hierarchies, where a representation is based on another representation.

A draft JWT specification https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ defines how to implement selective disclosure of information. Selective disclosure would be a excellent feature in business environments.

JWT types of claims

There are two types of JWT claims:

· Registered: standard claims registered with the Internet Assigned Numbers Authority (IANA) and defined by the JWT specification to ensure interoperability with third-party, or external, applications.

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

The IANA "JSON Web Token Claims" registry https://www.iana.org/assignments/jwt/jwt.xhtml#claims lists the registered claims.

Verifiable Credentials https://www.w3.org/TR/vc-data-model-2.0/ (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.

Using JWT's as carrier of Representation claims

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

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

• idenity information of the Principal

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

• additional information (time limits, specific instructions, link to issuer)

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.)

• idenity information of the Subcontratcor)

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

• additional information (time limits, specific instructions, link to issuer)

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.

Further reading

https://bdinetwork.org/wp-content/uploads/2024/05/2024-BDI-Embedded-JWT-as-Representation-Evidence.pdf

Trade leads to transport

Transport is almost always a consequence of trade. In the delivery conditions of a purchase agreement, the seller and buyer agree, among other things, who must take care of the transport of the shipment.

In international trade, seller and buyer can use the Incoterms 2020. These are standardized agreements about who arranges what (for example transport, but also insurance and/or customs formalities), payment and payment guarantees, and the moment at which responsibility is transferred (for example when a container is lifted over the rail of a ship). Incoterms 2020 are mainly focused on the agreements between buyer and seller.

Transport agreement

As a result of the agreements in the purchase agreement, one of the parties gives one or more orders to arrange transport. In a more complex chain, forwarders often arrange the details on behalf of the client, but in the case of a relatively simple order this is usually done directly.

Digital transfer of accountability and liability

Paper documents have been the standard in the professional transport of goods for centuries. They serve as a basis for business agreements ('contracts': agreements, insurance, credits), as a means to coordinate activities ('coordination': coordination in the transport chain), and as a basis for declarations to and inspections by governments ('compliance' : demonstrate that one complies with the applicable legislation). Many laws, work processes and customs are based on this paper backbone.

The new standard is digital. Mutual agreements, planning, transactions, transfers and notifications are handled as much as possible by the IT systems of the companies and governments involved. Automated, with less and less human intervention, to facilitate:

Demonstrability: being able to show the origin of goods and the environmental effects of a supply chain.

Managing scarcity: scarce infrastructure, labor shortages, limited environmental space and shortages of raw materials, energy or products. The only way to make well-founded choices is to provide more information and insight.

Resilience: absorbing the consequences of disruptions and shocks in the global economy.

Preventing undermining: both cutting off opportunities for crime and fraud, preventing and detecting tax evasion.

Legal asset boundary management

Just like a stamp or a 'wet' signature on paper, it's all about the details that determine how much legal strength a digitally recorded transaction has. And on the other hand, the desire or necessity of the parties involved (client, transporter and recipient) to set high, low or no requirements at all: even not to build in digital transaction recording at all.

There are many more digital variants than 'analogue'. And all of them have their specific properties, advantages and disadvantages. The legal status of variants (other than high quality "digital signatures" for valuable transactions) is diffuse.

As there is no global accepted standard or legal franework for "fit for use" recordings of digital transactions, the BDI supports commercial agreements between parties, called Edge Agreements.

Standardized protocols with corresponding liability definitions can be referenced in general conditions of agreements, creating the legal basis for "fit for use" Legal Asset Boundary Management.

This page contains references to demo projects and their lessons learned where the Boundary Management has been used.