Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
Trust is the measure to which one believes that another entity (being a person, an organization or a support system) is willing and able to fulfill an agreement. Measures can be in place to increase trust. For instance, encryption, signing certificates and the Public Key Infrastructure (PKI) are in place to increase trust in a message exchange over the internet.
The BDI is mainly concerned with trust at the business level, i.e. trust between parties in a business transaction. However, as data exchange over a network is crucial for the BDI, we make extensive use of tools and techniques to increase trust at a technical level.
The Trust KIT is inspired by the iSHARE Trust Framework, and uses some of the concepts and components from iSHARE. However, the BDI is not identical to iSHARE.
At its core, the Trust KIT encompasses vital building blocks, including IAA functions that provide the necessary identity and access management capabilities. The Association Register and Authorization Registers enable the secure recording of membership and authorization rights. Discovery and Onboarding processes ensure that members can be seamlessly integrated into the BDI, guided by clearly defined Terms & Conditions and structured process flows. Furthermore, Policy Agreements and Edge Agreements provide the necessary governance framework to ensure that all data interactions comply with agreed-upon standards and regulations.
The Trust KIT comprises the following building blocks:
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).
The purpose of this building block is to support the framework for trust in Boundary Management, where humans are acting as a representative of a legal entity by means of (digital) devices and telecommunication.
Boundary Management for humans relates to:
This building block ensures that the digital identity of the human involved in (digital) interactions can be authenticated. In addition, it ensures a relation between the digital identity and
the Representation evidence, i.e. in what role and capacity, on behalf of which legal entity, with a specific mandate
the Professional Qualification evidence, i.e. evidence of professional qualifications
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.
Identity is a legal concept defined by a nation state and assigned to a human by that nation state. Nation States issue Passports and ID-cards to humans which they can use to "prove" their identity. Driving licenses are also used in some states (e.g. the Netherlands) as a proof of identity.
Digital identities are related to that core identity by Identity Providers which are used in B2B processes.
Identity Providers can choose to increase the assurance level of an identity, for example by requesting live verification of an identity paper. This can be done face-to-face or remote. Typically, this is executed once at the initiation of a new identity.
Identity Providers can also provide additional assurance at the (continuous) use of the identity, e.g. when a managed boundary must be crossed. The human user can be authenticated by a username, password and an additional 2FA / MFA. More advanced devices can also use biometric identification parameters. Biometric identification can also be used for accessing a physical location. One such example is using the Secure Logistics smart card to access a Terminal.
Identity Providers typically use an internal numbering scheme for identifying users which are enriched with more public identifiers like email addresses and telephone numbers. Some details regarding different identifiers are given below.
As mentioned, identity is a legal concept defined by a nation state and assigned to a human by that nation state. State issued identifiers (e.g. 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 they have access to the number. At a later moment, the user can once again demonstrate the access to this number.
B2B Identity Providers identifies a human user in the context of an organization. Additionally, the role/mandate of the user can be defined at the Identity Provider so it can be used in all connected services. An alternative is that the service itself has local authorizations which must be managed by an administrator of the organization.
Users could represent more than one organization, and there are several approaches Identity Providers can take to manage this scenario. They could for example assign different identities for each of the represented organizations (e.g. applying different business email addresses or issuing separate secure cards per organization). An alternative is that the human user selects the represented organization in each specific use case.
In many cases the human needs to have adequate professional qualifications for the task at hand, such as a professional drivers license, safety training or dangerous goods handling. The B2B Identity Provider could store and share these professional qualifications of the user, for example in an electronic wallet. The qualifications are typically represented as verifiable credentials.
Some possible risks that are important to consider for this building block, are the following:
An insufficient framework for digital identity might lead to a lower level of trust among parties and will harm the overall trust in BDI.
Non-compliance to applicable privacy laws (e.g. GDPR, AVG) can hamper the implementation or adoption of services and can cause reputation risks or fines.
The related building blocks are:
The most important related Kits and concepts are:
Please note the following design decisions:
Parties choose their Identity Providers fitting to the requirements.
The BDI adds the link to representation and professional qualifications.
In Europe the eIDAS regulation is a solid foundation for the identity ecosystem.
See Digital Identity M2M and Digital Identity H2M
Terminology in the field of digital identity can be confusing as different sources use terms in slightly different meaning. To deal with this confusion, we define some terms that are used in the description of the BDI Digital Identity.
The physical world is populated by persons and objects that can be recognized and distinguished from one another by their Physical Identity. Although the notion of physical identity is heavily debated in philosophy, we will not discuss this further beyond the observation that identities are unique and constant over time. In a sense, a physical identity determines the "sameness" of a person or object over time.
Although persons and objects are of course entirely different categories, much of what is written here about persons also holds for objects.
A person that is identified through its physical identity can have many attributes such as a name, date of birth, address, eye color and so on. Some of these attributes are unique for a given person and hence can be used for identification. It is however important to note that a physical identity is not the same as this unique set of attributes. A Digital Identity is a record in an information system, describing certain attributes of a person in the physical world. The digital identity can be used by information processing systems to determine e.g. access rights.There are several issues that must be dealt with when managing digital identities:
At creation time of the digital identity it must be certain that it indeed corresponds to the right person (the onboarding problem)
It must not be possible to use the digital identity for any purpose without the explicit consent of the holder of the physical identity.
The digital identity must contain sufficient information to uniquely identify the person.
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 an asset (cargo) and/or liabilities for the asset between the two legal entities
For example: picking up cargo by a transporter
This building block supports trust among participants by defining how digital identities play a role in BDI in machine-to-machine (M2M) interactions. The digital identifiers for natural persons are described in Digital Identity (H2M).
In its implementation, BDI aligns with iSHARE's implementation of digital identities, preferring PKI (public key infrastructure) certificates issued by a reputable identity provider as digital identity of parties like Service Providers. In Europe the eIDAS regulation is a solid foundation for the identity ecosystem.
The purpose of this building block is to support the framework for trust among parties, by ensuring that parties can provide and receive a verified digital identity. An authenticated digital identity is the prerequisite for determining trust and subsequent authorization.
The building block ensures that interactions within BDI (onboarding, offboarding, data exchange, service consumption, etc.) will take place between identified and authenticated parties.
The following concepts (from the BDI Glossary), all regarding legal entities, are particularly relevant in this building block:
The figure below shows how a business partner from another BDI association can become a preferred Business partner of a BDI association.
An insufficient framework for digital identity might lead to a lower level of trust among parties and will harm the overall trust in BDI.
This building block describes the BDI principles for digital identity for M2M interactions.
The related building blocks are:
The most important related Kits and concepts are:
A digital identity has to be linked with the legal identifier of the legal entity that controls and takes responsibility and accountability for the IT-process that uses the digital identity in interactions with other IT processes.
A digital identity has to be linked with the legal identifier of the legal entity that controls and takes responsibility and accountability for the IT-process that uses the digital identity in interactions with other IT processes. For more details about possible identifiers, view the information below.
The 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 has also introduced an "EUID". This identifier is based on the local European Business Registries and 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 following should be noted regarding identifiers in the BDI:
The BDI prefers PKI certificates issued by a reputable identity provider as digital identity of parties like Service Providers.
In Europe the eIDAS regulation is a solid foundation for the identity ecosystem.
Self-signed certificates for digital identities are a low-barrier entry level solution, with serious limitations on trust, federation and scaling
This building block guides organizations to establish a form of governance for their data exchange activities in accordance with the BDI framework. This building block provides reasons and options to establish this governance.
Some relevant concepts for the BDI onboarding are given below.
The BDI framework emphasizes perimeterless trust, allowing each data owner to determine who they trust. Trust registers and identity mechanisms are both 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 a beneficial option to consider.
A BDI Association is a local entity formed by a group of participants within the framework. The legal structure of an Association can vary, as it could for example be a foundation or cooperative. Irrespective of its legal structure, the Association serves as the operational anchor for both federated trust/authentication and local onboarding within the BDI Framework. Members of a BDI Association can engage in multiple sectors and data exchanges, participating in dynamic virtual networks composed of members from different Associations. These networks operate on zero-trust principles (see ...), treating members from other Associations as untrusted by default until trust is established.
The local nature of BDI Associations is important, but associations are not by definition local. Some arguments for the importance of this local nature are the following:
Trust and reputation are often tied to proximity and frequency of interaction. The economic gravity-effect shows that geographical proximity has a causal relationship with the level of trade.
Legal systems tend to be national or trade-bloc dependent, making localized Associations more effective in managing trust and reputation within these frameworks.
The local BDI Association can be the foundation of effective and efficient trust management in a perimeterless, zero-trust environment.
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.
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,
It is recommended that an onboarding mechanism is introduced for new members, if the Association desires to raise the standards for its members.
The following aspects can be taken into consideration:
vetting the member
checking roles the member wants to fulfil
verifying credentials and certificates (trust chain)
The result of onboarding is an entry in the local Association Register.
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.
Prepare
A complete set of attributes is prepared; for updates, this includes all data in the registration (including any attributes that haven't changed).
During preparation attributes can be added, removed and modified freely. Ideally, there is a way to validate the dataset during preparation, but it must be possible to work with intermediate/incomplete data until submitting for verification
Verify
Shared terms and conditions, data access policies, and data licenses are essential for enhancing interoperability within the BDI Framework.
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.
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
The purpose of the Association Register is to automate and facilitate trust assessments of entities in the sequence of Authentication – Trust Assessment – Authorization as performed by a Zero Trust endpoint.
A shared Association Register reduces costs and combines experiences in shared dynamic reputation scores.
A shared Association Register in a legal entity (BDI Association) can be augmented by onboarding procedures, including the signing of legal documents, including terms and conditions.
A federated Association Register automates the basic trust checks of entities that claim to be a Member of another BDI Association, by verifying the other BDI Association and verifying the membership.
A federated Association Register automates the registering of preferred Business Partners: members of other BDI Associations that have a special status.
An Association Register is considered a technological solution to facilitate the role of the Association Administrator.
The following concepts (from the BDI Glossary) are particularly relevant in this building block:
An Association Register is a core part of automated trust assessment. This requires both:
Rigorous design and testing for IT-security weaknesses (cryptographic libraries, protocols, penetration testing, supply chain attacks etc.)
An operational security process that minimizes the risk of humans as attack vector (social engineering, pressure) to compromise the integrity of the register
The human attack vector is considered to be the most risky: onboarding should therefore be a one-way automated process in three separate steps (see also onboarding T&Cs Association articles):
Collecting information (automated and/or manual)
Verifying information and test trust chain (automated)
Committing to the register (manual action by functionary)
Modification of information should only be possible by deleting or deprecating information, followed by a new onboarding process.
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.
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.
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.
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.
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.
This building block has been derived but modified from the following sources, that provide opportunity for further reading:
Policies in the BDI are common agreements about authorization of access to data elements. Friction, management costs, delays and (legal) uncertainty can be reduced by a standardization of the following elements:
Common roles
Data access policies
“Need-to-know” limitations
Rights and obligations on how the data may be used
Common roles define operational responsibilities within supply chains, helping to create standardized policies — particularly Data Access Policies. Each specific sector (type of cargo, modality) has common roles that are well understood and recognized. The same applies to the data elements that a role needs to have access to in order to be able to perform a task.
Defining these common roles — e.g. truck driver, customs agents, inspection agent, forwarder, terminal planner, etc. — reduces the cost of interactions between entities. An undefined role needs custom definitions for the combination role-data access policy, which may be a labor-intensive action. Managing access rights is simplified by standardization.
Data access policies define who or which role can access specific data elements under what conditions. Common roles are linked to common data access policies, and a data access policy can be linked to a person: this is a specific authorization.
Data licenses define the rights and responsibilities of a party that gains access to data. These licenses address whether the data can be retained, reused, or shared with third parties. For example, in the e-commerce sector a data license might stipulate that a transporter delivering packages cannot store, reuse, or resell the recipient’s personal information, including their name, address, email, phone number, or the type of goods delivered. Data licenses regulate the permissible actions and behaviors related to the use of the accessed data to ensure that control over the data is maintained even after it has left the trust boundaries of the data owner.
For a specific sector or geography one can either develop specific data licenses, or reuse common global data ones.
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:
One can utilize the standardized set of edge agreements available in the BDI repository. For instance, the set of data licenses which are described by iShare.
iSHARE Framework documentation, specifically on the topic of identities
Business Partners
Members of other BDI Associations than the “home” BDI Association
Preferred Business Partners
Outsiders who have agreed to the specific terms and conditions of the local BDI Association, which maintains its own Business Partner Reputation Model
Outsider
Anyone who is not a member of a BDI Association
Visitor
Outsider with a better reputation score than a set minimum
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.
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.
Association
Legal entity that serves as a 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, realtime accessible by associated data provider(s): the 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" association. 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 that the member is a part of.
Visitor
Outsider with a better reputation score than a defined minimum.
See Authentication M2M and Authentication H2M
In the context of the BDI, the user is a representative of a legal entity (organization). Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases.
other (sister-)associations can have a trust score, starting with verification of public key ownership of the sister-association.
verifying the compliance and security of the IT applications they use (conformity tests)
Once submitted for verification the dataset is kept immutable; it must not be possible to change datasets during or after verification. If changes have to be made they will be fully re-submitted and follow the full prepare/verify/commit process.
Once the verification stage is completed, it can be queued for commit.
Commit & sign
Once verified, the Association Functionary will also do any non-automated checks, for instance checking the (digital) signature on any signed documents provided.
The Association Functionary cannot change the submission. The only possible actions are "reject" or "commit" or “deprecate” an already committed submission.
It is a requirement that non-repudiation of the action taken by the Association Functionary is supported.
Only a commit will add, update or modify the registration in the Association Register. If changes are not committed, they do not affect the Register.
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.
defining a standard for discovery using the DNS Protocol.
In the BDI, the discovery process is recommended for enabling connections between data providers and consumers. Unlike traditional data marketplaces, where the primary focus is on matching providers with potential consumers to establish new data-sharing relationships, BDI focuses on optimizing existing data exchanges. These exchanges often support operational logistics in the supply chain, where different parties are already connected but more efficient methods for data exchange are required.
Option 1: 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.
Option 2: Discovery using the iShare specifications
iSHARE and thereby the BDI provide a framework for the discovery of:
(Data) Services. All participants providing services must provide a , as defined in the developer documentation. This endpoint provides information on the available BDI supported service offerings.
Participants of a data space. Participants of an association (in iSHARE known as a data space) are optionally discoverable through the of any Association Register (in iSHARE known as iSHARE Satellite).
Data spaces. Associations (data spaces) are optionally discoverable through the
When implementing DNS for service discovery in BDI, several factors need to be considered:
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.
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.
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.
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.
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.
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.
Key Fields:
target (hostname/IP)
port (service port number)
priority
weight (used to select the best service endpoint if multiple are available)
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.
DNSSEC provides security for DNS by enabling the validation of DNS responses. This is crucial for preventing attacks — e.g. cache poisoning — ensuring that data consumers receive accurate and trustworthy information during the discovery process.
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.
Ensure that BDI users (M2M) are recognized and identified to prevent misuse of services and data. The automatic authentication of a BDI user in a federated perimeter-less architecture (see DNS-based Discovery as option) relies on a (delegated) Trust Anchor for Identity.
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.
Incorrect authentication could result in data breaches and / or the unavailability to data for legitimate data consumers.
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.
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.
The eIDAS regulation and infrastructure is EU-specific. Outside of Europe other trust anchors could be used (to be investigated).
Certificates are quite expensive
Certificates need frequently to be rotated
The procurement, setup, testing and acceptance of certificates is not trivial.
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
Non-EU trust anchors (outside of eIDAS).
The use of association issued certificates instead of eIDAS certificates
Alignment with DSSC. The DSSC Blueprint v1.0 is referring to “Identity and Attestation Management” which is based of verifiable credentials, DID’s and OpenID for verifiable credentials. These has been defined out of scope for the current release of DIL / BDI.
In the BDI network, a within a BDI Association is integral for assessing the trustworthiness of visitors or outsiders: members of another BDI Association. While the BDI facilitates digital communication among a network of BDI Associations, establishing trust within a BDI Association through mutual agreements is relatively straightforward. However, evaluating the trustworthiness of participants in other BDI Associations can pose a challenge.
A federation trust is designed to enable efficient and secure online transactions between business partners. Trust to engage between parties is most often based on more attestations agreed between parties and/or assocation they are member of. The service provider can then make decisions based on te information on behalf of the data owner.
When a requests from a member of association A is directed to access data of a member of association B the request is redirected to the association's B attestation service to validate the federated trust artifacts available with the requestor association. These attestations help decide the authentication response of the data provider and authorization conditions applied on behalf the data owner. Note: Emphasizing 'helps decide' as the Trust Sovereignty principle is kept by allowing the assessment against the policies of the data owner to determine authorization. The owner might want to provide the data service as requested even if the Identity does not provide all the required attestations or limit the authorization provided by the assessment policies of the presented attestations.
The concept for the is to adopt the framework standards with it's members to achieve a goal (benefits outweigh the costs). Add local specifics, ratify common standards across associations, evolve and so on.
Above options could be combined; e.g. .
OAuth2:
OAuth 2.0 Mutual-TLS:
iSHARE:
Authentication is the process of proving that the user (human or IT process) with a digital identity is the rightful owner of that identity (definition from IDpro).
Authentication is required in both H2M (Human to Machine) and M2M (Machine to Machine) use cases. In this page, the focus is on H2M use cases: the human interacts with a machine by means of an IT-process under its direct control (device, IT-process, wallet etc.), or by digital data (e.g. QR code). Authentication precedes verification of Representation and subsequent Authorization.
The complexity of H2M Authentication is increased by privacy regulations: authenticating a human reveals their identity.
The purpose of this building block is the following:
Ensure that BDI users (H2M) are recognized, identified as a person and in a specific role on behalf of a legal entity in order to prevent misuse, fraud, theft of data, services and physical goods.
Enable smooth, efficient and secure Boundary Management.
Ensure that privacy leaks as a result of authentication are limited.
The use cases relate to Boundary Management:
The building block ensures that the digital identity of the human involved in (digital) interactions can be authenticated. This authentication precedes verification of Representation. In the context of the BDI, the human is a representative of a legal entity (organization): the legal entity assumes accountability and liability for the actions of the representative, limited to the mandate of the representative. A human can have multiple roles for multiple legal entities simultaneously.
The Identity Provider chosen by the parties/Association provides the authentication. A local cache of trusted identities may be operated by an Association as a register.
Representation evidence may be stored in a register by an Association, or transmitted between parties in a nested Jason Web Token or a Verifiable Presentation of Credentials.
The BDI uses the OAuth2 protocol and OpenID Connect protocol for H2M interactions. Identities are managed by an Identity Provider (also called an OpenID Provider).
The , in abstract, follows these steps:
End user navigates to a website or web application via a browser.
End user clicks sign-in and types their username and password.
The RP (Client) sends a request to the OpenID Provider (OP).
Organization can use (1) an internal Identity Provider, (2) an exclusive external Identity Provider and (3) a mix of an internal Identity Provider and (federated) external Service Provider (see the Federation Kit).
In the BDI users are typically acting as a representative for a legal entity and not as an individual person. Therefore, the OpenID Connect UserInfo endpoint must contain a organizational identifier of the legal entity.
eIDAS is short for ‘Electronic Identification, Authentication and Trust Services’ and was launched to help remove digital borders between countries in the EEA. eIDAS ensures the security of digital systems and protects people’s privacy. Besides eIDAS, there are also various national eID schemes. For example, in the Netherlands the national eID for persons is called DigiD and the eID for persons representing a legal entity is called eHerkenning.
There are strict regulations on the use of eIDAS. DigiD cannot be used for most private use cases. There are less limitations for eHerkenning. However, a very limited set of European countries have a similar B2B eID scheme.
Once a national electronic identification scheme has been recognized at European level, it can be used in other EEA countries. This is set out in the EU’s eIDAS Regulation.
These can be used for access to a location and/or transferring assets.
eIDAS2 introduces new trust services and EU Digital Identity Wallets (EDIW) for the use by citizens in both public and private domains. eIDAS2 also includes Organizational Digital Identity Wallets (ODIWs) [].
This building block interlinks with:
This building block describes how to assess trustworthiness of parties involved in a transaction.
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:
Insufficient authorization may cause data leaks to parties that are not trusted.
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.
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:
, one of it’s parent Associations or the root BDI Network.
of the digital identity of the party.
as provided by the Reputation Model.
The four inputs for decision making are supported by the BDI trust input elements as follows.
Trust based on association membership
Information gathering
This input element uses input from the building block . This building block provides insight into what association and (optionally) what parent associations a participant is a member of.
Information processing
To facilitate easier processing of the acquired information, a party can:
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.
Example of a Data Service Provider
Consider the situation where a Data Service Provider is being requested for data by a Data Consumer. The Data Service Provider could use the following information in its decision to trust the Data Consumer:
Is the Data Consumer member of my Association, a parent Association or the root BDI Network? [BDI input element 1]
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 organizations / users have access to which data. These authorizations can be registered in an Authorization Register of the Data Service Provider.
The sharing of data between organizations 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 organizations. For example: the permission of a Terminal to share all container shipment related data with CBS.
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 a local 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 Authorization Register at runtime during a data request to check the permission. In more complicated scenario’s Authorization Registers could refer to other Authorization Registers validating the chain of permission to it’s source.
It could be helpful to create a trust decision matrix, to improve manageability of decision rules. The approach would be:
classify data with a required assurance level (for instance low, medium, high),
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 data classification
Location of a container -> low
Contents of a container -> medium
Personal data of shipper -> high
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
This building block has been drafted using the following sources, that provide opportunity for further reading:
The use of (other) PKI schemes.
The use of Decentral Identifiers.
Federated Authentication through OAuth 2.0 Attestation-Based Client Authentication
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.
DNS Subdomain
A standardized subdomain
("_bd1.[ url] ") improves discoverability, reduces the risk of interference with existing DNS records for the domain name already in possession of an organization.
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.
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.
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. For a visual explantion, see Figure 1.
The OP responds with an Identity Token and usually an Access Token.
The RP can send a request with the Access Token to the User device.
The UserInfo Endpoint returns Claims about the End-User.
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
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.
Trust based on the level of assurance of the digital identity of the party
Information gathering
This input element uses input from the/ building block Authentication M2M. This building block provides insight into the level of assurance of the party.
Information processing
To facilitate easier processing of the acquired information, a party can:
Choose to follow Association business logic, in this case the Association has defined how to translate Association membership into trust levels.
(If allowed by the Association) choose to follow it's own logic.
Trust based on reputations
Information gathering
The Business Partner Reputation Model forms the basis for acquiring reputation information. It is not yet defined how information on reputation of a party can be acquired.
Information processing
Assuming that information on the reputation of a party is available, a party can:
Choose to follow Association business logic.
(If allowed by the Association) choose to follow it's own logic.
Trust based on (granular) authorizations
Authorizations provide a way for a Data Owner to specify in great detail which Data Consumer is allowed to consume data on its behalf at a Data Service Provider. From a data sovereignty perspective, Authorizations provide the highest level of 'trust' and best basis to enter into a transaction up, when transactions are happening between Service Consumers and Data Service Providers.
Information gathering
In terms of the technical specifications for Authorizations, the BDI Framework is inspired on the iSHARE Trust Framework. The iSHARE Trust Framework uses the term “delegations” for the concept that in BDI is called Authorizations.
The framework defines
Entitled Parties are enabled in exercising data sovereignty by providing delegations (as described in the ) to parties to use their data
specify the legal boundaries for the usage of data by a Data Consumer
The evidence is defined in the framework and the technical requirements for APIs providing delegation evidence on the .
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.
What is the reputation of the Data Consumer? [BDI input element 3]
Can the Data Consumer provide Authorizations given to him by a Data Owner? [BDI input element 4]
Is the Data Consumer a legal entity based in the EU? [specific criterion, which can optionally be encapsulated in the (granular) Authorization [BDI input element 4] as a condition
Based on both this information and the nature of the data that the Data Service Provider is requested for (for instance the confidentiality or privacy aspects), the Data Service Provider can make a business decision to provide or not provide the data.
Yes
Synchronization
No performance loss at data request.
No additional delay for polling data.
Setup of synchronization process (polling or event processing)
Embed in Data Request
No performance loss at data request.
No additional delay for polling data.
No setup of synchronization required.
Data Consumer must retrieve authorization evidence.
Authorizations needs to be signed / sealed so it can be verified by the Data Service Provider.
Polling at Request
Most up to date information is always used.
Data Service Provider is dependent on (a) the performance (b) the additional delay (c) the availability of the external Authorization Register.
Low
Medium
No
No
Medium
Medium
Medium
No
High
High
Authorization
Authorization ensures that the authenticated entity, person or Process has been granted permission to gain access to the specific (data) resource requested.
Trust
Trust is the design and implementation of measures that evaluate the chain of trust per presented credential by any party; the decision to accept a certain level of trust is dependent on the risk of making a mistake.
Data owner
Has control over data and access to data,
Controls decisions on Data Sovereignty and Trust Sovereignty
Controls authorization policies, representation rules, professional qualification verification of staff and contractors
Data Consumer
Requests access to data and/or Representation Register and/or Professional Qualification Register of the Data Owner
Controls discovery and endpoints
Requests subscription to Event Pub/Sub Service of the Data Owner, receives and evaluates events
Data Service Provider
A Service Provider that acts under supervision and on behalf of the Data Owner
High
One can identify three types of “edges” or boundaries. Consider the three types below.
These boundaries arise from specific agreements in groups that all use the BDI framework but have different agreements per group.
The principle of subsidiarity of governance will lead to many “soft” boundaries: specific rules, roles and regulations that are common within a sector but differ from the equivalent agreements in other sectors.
These boundaries are the boundaries that are to be crossed when “non-BDI” actors are part of a specific operational network and need to be incorporated in the digital data exchange.
An example is the delivery of a shipment to a car manufacturing company. While the Shipper and transporter might be part of the BDI-network, the car manufacturer could be part of a different network, such as an industry data-sharing one. Both networks have different rules of participation but still need to be able to cooperate with each other in the operational process.
The clearest example is the delivery of a shipment to a receiving party. The receiving party may very well not be a member of a BDI association, unaware of the BDI framework and may have less Logistics IT maturity. The shipper and transporter would like to maintain the benefits of the automated controlled digital data exchange in such a case, without reverting to the default paper-based process.
This boundary has both technological and legal aspects that interact with each other. The shipper, receiver and transporter execute two commercial transactions at the same time. The shipper executes the delivery of the goods sold to the receiver by means of a transport order which is another commercial transaction between the transporter and the shipper.
Edge agreements are standards for interactions on a boundary. This standard may apply to a single group (or Association) or extend across several groups. The BDI has a listing available of a set of potential agreements that can be used in such a process. This listing also indicates which agreements are obligatory and which are not.
Transport is a consequence of trade. A purchase agreement between buyer and seller contains, among other things, who should take care of the transport of the shipment. In international trade, sellers and buyers can use the Incoterms 2020: standardized agreements covering 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).
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.
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.
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.
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.
They agree that Lets-B-chemical will hire De Snelle Visser for transport
It is known that Acme Inc. does not use any IT.
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.
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.
The driver working for De Snelle Visser delivers the goods to Acme Inc. and takes a picture of the delivered hydrofluoric acid.
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.
Agree on a set of accepted edge interactions such as:
A picture of the freight taken by the driver,
SMS confirmation between the buyer and seller,
Signature on tablet by the driver and buyer
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:
Controls discovery and endpoints
Controls roles assumed by entity
