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.

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

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.

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:

Further reading

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.

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

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.

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.

8. Further reading

1. Summary

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

Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases. In this page 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.

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

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

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

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:

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

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 and

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:

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:

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

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

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

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.

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:

See and

The Logistics Events KIT is an essential component of the Basic Data Infrastructure (BDI), specifically designed to enable the exchange of logistics events and associated data across the BDI ecosystem. This KIT is vital for organizations that require real-time visibility and coordination within their logistics operations. Building on the secure foundation provided by the TRUST KIT, it utilizes the BDI control plane and Identity, Authentication, and Authorization (IAA) functions to ensure that event data is exchanged securely and efficiently.

The core building block of the Logistics Events KIT is the Pub/Sub service, which allows for the publication and subscription of logistics events. This service facilitates the timely and reliable distribution of event-related information, ensuring that all relevant parties receive critical updates as they happen. By integrating with the BDI control plane, the Logistics Events KIT ensures that all data exchanges comply with established security protocols and governance frameworks set by the TRUST KIT.

Implementing the Logistics Events KIT enables organizations to streamline their logistics processes, improve real-time decision-making, and enhance overall supply chain efficiency. It is a crucial addition for any BDI deployment that involves dynamic and event-driven logistics operations, ensuring that data flows seamlessly and securely throughout the system.

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

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

This page contains references to demo projects and their lessons learned where the Semantics 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.

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.

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.

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.

Channels

Principals and their subcontractors communicate through channels (a.k.a. topics in a pub/sub setting). There are two 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 exist 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.

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.

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.

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.

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.

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.

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

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

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

Creating a 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.

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.

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.

Further relevant documents

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.

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

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

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

Relevant standards to consider or adopt for the BDI are:

Future topics

Further reading

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.

Purpose of the building block

‘Event-driven’ communication is a way of restructuring the logistics of the information exchange between the IT systems of companies. Instead of a data owner sending messages when something of importance needs to be communicated (‘fire and forget’, ‘messaging’), all parties involved receive a signal (‘notification’) from the data owner that something relevant has happened (‘publish event to subscribers’).

That event contains metadata and a link to the source of the data. The receiving party evaluates the metadata and decides whether to follow the link to the source and access the data.

The Event Pub-Sub Service handles the centralized parts of this event-based communication. The actual data exchange happens directly between the parties in a federated manner.

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.

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.

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.

Interlinkages with other building blocks

There are links with the following building blocks:

• Semantics

• Data model

• Data format

• Data protocol

• Zero Trust Check

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.

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.

Further reading

• EPCIS (ISO/IEC 19987:2024) https://www.iso.org/standard/85557.html

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

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

Summary

The Representation Chain is a building block that lets other entities verifiy mandates.

The Representation Chain is a method to show verifiable mandates given to natural persons, legal entities or governmental bodies that act on behalf of the entity that issues the mandate. A mandate is a record of representation by an (mandator) provided to whom a mandate is assigned (mandatee). The mandate transfers accountability and liability to the mandator for acts done by the mandatee.

The Representation Chain consists of a Representation Evidence (nested or embedded JWT's) that can be verified offline and/or online by a check at the issuer that the token is still valid .

Purpose

The Representation Chain is a method to show verifiable mandates given to natural persons, legal entities or governmental bodies that act on behalf of the entity that issues the mandate. A mandate is a record of representation by an (mandator) provided to whom a mandate is assigned (mandatee). The mandate transfers accountability and liability to the mandator for acts done by the mandatee.

This covers H2M and M2M (process acting on behalf of a legal entity) use cases.

The Representation Chain is the Building Block to facilitate Boundary Management, especially for Physical Acces Boundaries

and Legal Asset Boundaries.

Relationship to other Building Blocks

The Representation Chain is (directly or indirectly) related to the following Building Blocks:

• Authentication

• Authorisation

• Digital Identity:

• Common Roles:

• Professional Qualification Chain : this is a similar methode to show proof of the professional qualifications of Natural Persons acting on behalf of the issuing entity.

• Verifiable Credentials: (future work)

Elements & core Functions

A Representation Chain is not a central register but a method.

The Representation Chain holds the relationship between

• the (digital identity of the) mandator

• the digital identities of mandatees

• the scope of the mandate

  • role based

  • optionally order related (transient)

• other relevant data

The Representation Evidence is in the form of a nested JWT including additional information as desired. The JWT is transferred to the mandatee (H2M use case Physical Asset Boundary Management) for temporary use. The mandatee show/transfers the JWT as Representation Evidence to third parties, online or offline. These parties can verify the (nested) JWT and optionally follow the link's in the JWT's to the respective issuers to check to validity of the tokens.

The third party does not need to be Member of an Association, lowering the barriers for implementation.

Documents

Further Reading

• Verifiable Credentials

• E-Herkenning

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.

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

This page contains references to demo projects and their lessons learned where the Representation 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

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

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

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

Development Stack and Libraries

Selecting a secure development stack involves careful consideration of programming languages, frameworks, and tools with a strong track record in security. It's essential to keep libraries and dependencies up to date to address potential security vulnerabilities.

Especially when the functionality is needed for secure operation the implementation should use well-tested and maintained components and libraries in favor of implementing functionalities from scratch. This applies specifically to:

· JWT parsing & handling

· Certificate parsing & handling

· Input validation

· Authentication

· Authorization

· Database interactions (e.g. an ORM framework)

· Output escaping in user interfaces (e.g. templating frameworks)

· Cryptography, including password storage

The development stack should be chosen accordingly.

Secure Code Design

Secure code design encompasses foundational principles, including rigorous input validation, output encoding, and error handling. Implementing security design patterns, such as the Principle of Least Privilege or Fail-Safe Defaults, is crucial for minimizing potential vulnerabilities. Practical code examples demonstrate how to apply these principles effectively.

· Version Control: Use version control to manage code changes.

· Validate Inputs: Always validate API inputs, operator inputs, and data from peer services. Use standardized mechanisms like OpenAPI specifications for validation.

· Certificate and JWT Validation: Validate certificates and JWTs for format, validity period, and other parameters using standard components.

· Secret Management: Keep operational secrets secure and separate from source code repositories.

· Access Restrictions: Limit access to production machines, automate software deployment, and log all access and deployments. Restrict the number of users with production access.

· Code Review: Ensure all code changes are reviewed by a second developer before merging.

· Enforce access control service-wide: API and operator endpoints must have access control applied. This should be designed into the service architecture and “fail closed” so that endpoints must have explicit access restrictions – access control must not rely on ad-hoc checks per action/endpoint that may be omitted or have logic errors.

Strict checks that “fail closed”

When validating requests and comparing registrations, the implementation should be strict; incomplete data (including failure to request required information from third parties) is not acceptable and should prevent requests from completing.

The goal is to prevent leaking sensitive information and erroneous positive statements about parties (I.e., “Party X is an active member of an association”) due to misconfiguration, bugs, and deliberate attacks.

The core principle is that access is denied except for complete and valid requests.

The above principle must also be applied to the service’s implementation; any path + request method combination not explicitly allowed with specified access controls must be denied.

In addition to the above section on strict checks that “fail closed”, centralize the access control mechanisms so no endpoints can be accidentally exposed without correct controls.

Centralize input validation

Input validation on endpoints must be centralized so no endpoints can be accidentally exposed without correct input validation. Apply the “fail closed” principle.

Automated tests & CI/CD

The development process must use automated tests to check regressions and validate new functionality. The automated deployment mechanism should ensure that new releases pass all automated tests before deployment. Releases must be tracked in the audit log.

Besides unit tests and regressions tests the CI/CD pipeline can also be employed to perform:

· Dependency scanning

· Static Application Security Testing (SAST)

· Dynamic Application Security Testing (DAST)

Logging and Monitoring (Audit log)

Comprehensive logging is a cornerstone of application security, capturing user actions, system events, and critical security data. Log analysis tools and intrusion detection systems are essential for identifying and responding to security incidents. Log format examples and recommendations for logged information assist in maintaining robust security practices.

Logs should be able to be combined, sourced from separate entities that interact. This requires standardization of a minimum data set in the logs.

Committed changes must be logged with details such as date/time, operator identity, and other relevant information. The audit log should be append-only, read-only, and accessible only by the Security Officer. To ensure integrity, consider logging to a separate component or isolated system. must also be tracked in an append-only log.

Input data must not be logged “as is” without either validation or encoding; logs should have a reliable format.

When the system is operational in production, system status, load, request rates, errors etc must be logged and monitored. Alerts and notifications will be configured so that problems are detected quickly and can be resolved as soon as possible.

Logging and monitoring may be partially implemented in an additional gateway/proxy services and must be in place in production.

Logs should be exportable in a portable format (to be determined) for investigations of suspicious events, when sharing of logs between parties is necessary.

Escaping (or encoding) is not just relevant when logging data. In general any ‘sink’ could be, for example an SQL-context, an HTML-context or an URL-context.

The principle of escaping at the leaves means that escaping is applied at the last moment, when the context in which data is being used is known. Logging data is an example of such a ‘leave’.

Access to logs must be restricted to authorized roles (CISO).

Incident Response

Incident response involves a structured approach to handling security incidents, encompassing detection, containment, eradication, recovery, and post-incident analysis. A well-prepared incident response team and communication plan are paramount to address and mitigate security events effectively.

Operational security is critical to ongoing protection. Access controls and permissions are vital for restricting employee access to sensitive resources. Regular access reviews and audit trails ensure accountability and security maintenance.

No manual editing possible in Association Register

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.

Roles and access

Define roles for actors and restrict access to relevant actions or endpoints based on these roles. This ensures that users only have access to the functionalities necessary for their roles, reducing the risk of unauthorized access.

Security Testing

Security testing involves systematic (and automatic) assessments to uncover vulnerabilities. This includes penetration testing, vulnerability scanning, and code reviews. Integrating security testing into the development lifecycle is critical for identifying and rectifying security weaknesses.

Keep components up-to-date

For this process it is helpful to have an inventory of all software (and software dependencies), sometimes referred to as a software Bill of Materials. This could be integrated in the CI/CD pipeline.

During development and operations should have processes in place to keep the system’s dependencies up to date and to make sure dependencies are still supported by the vendor. CVEs should be monitored for issues and workarounds.

The development cycle should make it possible to release bugfixes and security-fixes on a fast schedule.

Backups

Backups to recover from crashes and/or data loss must be in place. Access to backups must be restricted to the CISO.

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

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 Security has been used.

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

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

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

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.

JWT types of claims

There are two types of JWT claims:

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

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

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

HTTP processing; rate limiting, buffering, other limits

The system should mitigate denial of service scenarios:

Rate limiting to prevent overloading the service

Request/response buffering to ease handling of slow clients

Header size limits.

Prevent caching for endpoints (Cache-Control: no-store unless explicitly allowed for an endpoint)

Set charset on endpoints (including application/json endpoints)

Some of these mitigations may be implemented in an additional gateway/proxy service and should be in place in production.

Exposed endpoint protection

Endpoints that are exposed to the Internet are a prime attack surface. One of the options to reduce the attack surface is to limit access to a specific port in the firewall only to authenticated systems, for a limited period of time (“port-knock” service). This has been investigated by the BDI

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

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.

The security of a BDI implementation builds upon common security practices that every entity should put in place. Specific attention must be given to:

• Software design of components

• Emergent security (the security of the interacting components as an ensemble)

• Provisions to detect anomalies and perform autopsies after incidents

• Operational security