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.

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.

1. Summary

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

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

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

2. Purpose of the building block

3. Concepts

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

4. Risks

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

5. Interlinkages with other building blocks

This building block interlinks with:

• Digital Identity & Identifiers

• Authorizations

• Discovery

• Federation

6. Core design decisions

6.1. OAuth2.

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

• Shared secrets

• Private keys (certificates).

The use of private keys is preferred within the BDI.

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

6.2. eIDAS.

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

• Mutual TLS - Qualified Web Application Certificate (QWAC)

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

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

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

6.3. Non-European trust anchors.

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

6.4. Drawbacks of certificates

• Certificates are quite expensive

• Certificates need frequently to be rotated

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

6.5. Certificate based authentication

Guidance on (to be done):

• Mapping certificates to identifiers (within the association)

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

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

7. Future topics

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

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

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

4. Alignment with IDSA. To be defined.

5. The use of (other) PKI schemes.

6. The use of Decentral Identifiers.

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

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

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

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

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

Above options could be combined; e.g. https://dhs-svip.github.io/requirements-for-decentralized-identity/TrustArchitecture/.

8. Further reading

OAuth2: IETF RFC 6749

OAuth 2.0 Mutual-TLS: IETF RFC 8705

iSHARE: Authentication

1. Summary

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

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

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

2. Purpose of the building block

3. Concepts

The use cases relate to Boundary Management:

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

  • For example: login to an application

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

  • For example: entering a protected zone

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

  • For example: picking up cargo by a transporter

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

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

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

4. Core design decisions

4.1. OAuth2 & OpenID Connect

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

The OpenID Connect protocol, in abstract, follows these steps:

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

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

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

4. The OP authenticates the User and obtains authorization.

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

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

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

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

Organization can use (a) an internal Identity Provider (b) an exclusive external Identity Provider (c) a mix of an internal Identity Provider and (federated) external Service Provider (see the Federation Kit).

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

4.2. eIDAS

eIDAS is short for ‘Electronic Identification, Authentication and Trust Services’. eIDAS was launched to help remove digital borders between countries in the EEA, while ensuring the security of digital systems and protecting people’s privacy.

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

There are strict regulations on the use of eDIAS. DigiD can't be used for most private use cases. There are less limitations for eHerkenning however a very limited set of European countries have a similar B2B eID scheme.

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

4.3. Smart Cards / Pyhisical Access Passes

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

5. Future Work

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

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

6. Interlinkages with other building blocks

This building block interlinks with:

• Digital Identity & Identifiers

• Authorizations

• Discovery

• Federation

1. Summary

2. Purpose of the building block

3. Concepts

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

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

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

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

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

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

3.1. BDI Association

A BDI Association is a local entity formed by a group of participants within the framework. The specific legal structure of an Association can vary—it might be a foundation, cooperative, or any other form. The Association serves as the operational anchor for both federated trust/authentication and local onboarding within the BDI Framework.

Members of a BDI Association can engage in multiple sectors and data exchanges, participating in dynamic virtual networks composed of members from different Associations. These networks operate on zero-trust principles, treating members from other Associations as untrusted by default until trust is established.

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

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

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

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

  • UK Law and NL/EU law as an example

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

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

3.2. Efficient trust management

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

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

• Members of the same association are considered trusted insiders.

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

  • a shared reputation scheme builds experience with outsiders;

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

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

3.3 Onboarding

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

The following aspects can be taken into consideration:

• vetting the member

• checking roles the member wants to fulfil

• verifying credentials and certificates (trust chain)

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

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

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

3.4. Coherent Security

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

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

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

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

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

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

5. Core design decisions

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

6. Interlinkages with other building blocks

• Terms and Conditions

• Policies

• Edge Agreements

• Data Licenses

1. Summary

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

See and

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:

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

1. Summary

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

• https://digitalshipmentdata.org/

• https://www.evofenedex.nl/kennis/internationaal-ondernemen/incoterms/de-11-incoterms-2020

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:

• ​DSSC Blueprint building block “Participation Management”​

• ​iSHARE Framework documentation​

• ​iSHARE Developer Portal documentation

1. Summary

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

Utilizing discovery-aspects of the iSHARE Trust Framework.

or

Defining a standard for discovery using the DNS Protocol.

2. Purpose of this building block

Option 1: Discovery using the iSHARE specifications

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

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

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

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

Option 2: Discovery using DNS

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

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

3. Concepts

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

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

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

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

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

4. Implementation Considerations

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

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

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

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

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

5. Elements and Their Key Functions

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

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

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

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

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

Introduction

Demo Phase 1

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

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

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

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

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

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

Demo Phase 2

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

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

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

Documentation in GitHub

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

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​